Hey Anders, We were inspired by what you did, and also decided to see if we can take this in a slightly different direction/ use cxx. If you're interested in discussing the wrapper more we can take it off the list.
On Sun, Oct 18, 2020 at 3:35 PM Anders Langlands <[email protected]> wrote: > I also have a rust binding here if you're interested: > https://github.com/anderslanglands/oiio-rs > > On Sun, 18 Oct 2020 at 04:43, Scott Wilson <[email protected]> wrote: > >> Awesome, thank you very much! I'll try this out and see how badly I break >> things. >> >> On Sat., Oct. 17, 2020, 1:02 a.m. Larry Gritz, <[email protected]> wrote: >> >>> If you know the true legal extent of the memory allocation in which that >>> data pointer is located (in this case, the beginning and ending of the >>> vector, if you are passing a pointer to one of the elements of that >>> vector), then I think you could certainly consider it an error if any of >>> these addresses lay outside that buffer: >>> >>> data + xstride*width - 1 >>> data + ystride*height - 1 >>> data + ystride*(height - 1) + xstride*width - 1 >>> data + zstride*depth >>> data + zstride*(depth - 1) + ystride*height - 1 >>> data + zstride*(depth - 1) + ystride*(height - 1) + xstride*width - 1 >>> >>> There may be a more succinct way to put that, but I think it covers all >>> the cases of + and - strides. >>> >>> >>> On Oct 17, 2020, at 12:42 AM, Scott Wilson <[email protected]> >>> wrote: >>> >>> Thanks! I guess to come from this at a different angle, let's say I'm >>> doing something like this: >>> >>> std::vector<uint8_t> pixels(10*10*3*1); >>> ImageInput.read_image(TypeDesc::UINT8, @pixels[0]) >>> >>> Would there be a case where I could pick a stride value that would fall >>> outside the pixels vector? >>> >>> PS: Thanks! I'm working on this with a friend, and hope to have >>> something released in the near future. >>> >>> On Fri., Oct. 16, 2020, 11:47 p.m. Larry Gritz, <[email protected]> >>> wrote: >>> >>>> Oops, my math was wrong (in an unimportant detail): If you are making a >>>> mosaic of 16x5 of these 10x10 images, it is 80 small images you are >>>> assembling in total, not 40. >>>> >>>> >>>> On Oct 16, 2020, at 11:43 PM, Larry Gritz <[email protected]> wrote: >>>> >>>> The strides don't describe the size of the image, they are the spacing >>>> in memory of where you want the values to be placed upon being read (or >>>> taken from in order to write). There is no invalid set of strides, because >>>> the caller might want them to end up anywhere in memory. >>>> >>>> Or am I misunderstanding? >>>> >>>> For a fully "contiguous" memory buffer where you intend for every >>>> plane, scanline, pixel, and channel immediately follows the previous one, >>>> then in our example the strides would be xstride=3, ystride=30, >>>> zstride=300. (Though for a 2D image, the zstride is not used.) >>>> >>>> Here's an example of where you might have a stride range that is wildly >>>> outside this: Let's say that you have 40 of these 10 x 10 x 3 x uint8 image >>>> files and you are trying to read them in and assemble them into a single >>>> RGBA mosaic image of 16x5 x 4 x uint8 (the additional channel is alpha, >>>> which you will separately fill in as 1.0 [or 255 uint8] because it's not in >>>> your RGB files). Here's a cartoon to illustrate this: >>>> >>>> +-----------------------------------------+ >>>> | | | | | | | | | | | | | | | | | | | | | | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| >>>> | | | | | | | | | | | | | | | | | | | | | | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| >>>> | | | | | | | | | |X| | | | | | | | | | | | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| >>>> | | | | | | | | | | | | | | | | | | | | | | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| >>>> | | | | | | | | | | | | | | | | | | | | | | >>>> +-----------------------------------------+ >>>> >>>> Each of my little grid cells is a 10x10 image. But that 10x10 image >>>> denoted by the "X" needs to be placed in memory in the right portion of the >>>> 16x10 x 5x10 mosaic. So what are the strides we use for the read? Well, the >>>> xstride is 4 because we're making room for an alpha channel that wasn't >>>> present in the file, the ystride is 640 (= 10*16*4), because each scanline >>>> of the little 10x10 image that you read needs to be placed on the proper >>>> scanline of the 160x50 mosaic you are assembling in memory. >>>> >>>> -- lg >>>> >>>> >>>> P.S. Woo-hoo for making a Rust wrapper. I think that's a totally great >>>> thing. >>>> >>>> >>>> >>>> On Oct 16, 2020, at 10:46 PM, Scott Wilson <[email protected]> >>>> wrote: >>>> >>>> I'm experimenting with a Rust wrapper for OIIO, and had some questions >>>> about the stride. >>>> >>>> Let's say I have an image that is 10x10 pixels, and 3 channels, and 1 >>>> byte per channel. What strides would be invalid for that image? I'm >>>> guessing that anything between -10 * 10 * 3 * 1 to 10 * 10 * 3 * 1 and the >>>> AutoStride would be valid, and everything else may try to access memory >>>> that isn't initialized. Is this assumption correct, or am I missing >>>> something? >>>> >>>> Thanks! >>>> _______________________________________________ >>>> Oiio-dev mailing list >>>> [email protected] >>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>> >>>> >>>> -- >>>> Larry Gritz >>>> [email protected] >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Oiio-dev mailing list >>>> [email protected] >>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>> >>>> >>>> -- >>>> Larry Gritz >>>> [email protected] >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Oiio-dev mailing list >>>> [email protected] >>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>>> >>> _______________________________________________ >>> Oiio-dev mailing list >>> [email protected] >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>> >>> >>> -- >>> Larry Gritz >>> [email protected] >>> >>> >>> >>> >>> _______________________________________________ >>> Oiio-dev mailing list >>> [email protected] >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >>> >> _______________________________________________ >> Oiio-dev mailing list >> [email protected] >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
