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] >> <mailto:[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] <mailto:[email protected]> >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > > -- > Larry Gritz > [email protected] <mailto:[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
