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
