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