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
