RFR: 8352407: PixelInterleavedSampleModel with unused components throws RasterFormatException: Incorrect pixel stride [v2]
Nikita Gubarkov
ngubarkov at openjdk.org
Wed Apr 2 12:44:24 UTC 2025
On Wed, 2 Apr 2025 12:25:52 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:
>> Or maybe we should modify the code that relies on the current size?
>>
>> Why does our code work fine when skipping the end of the scanline in cases where there is a gap, but it cannot skip the pixelStride when there is a gap as well?
>
>> why we can't use the first component instead of the last one
>
> We definitely cannot do that because of the band-interleaved case: imagine if there are like 10000 bytes of red samples followed by another 10000 bytes of green samples - with `pixelStride=1` and `scanlineStride=100` if we take the first component offset (0), our calculated size would only fit the red channel.
>
> In your calculations using "starting offset + pointer to the last pixel + pixelStride", you assume only pixel-interleaved variant, but this calculation would break with other interleaving modes. Actually, for pixel-interleaved layout there is a simple commonly-used formula, like: `size = startingOffset + scanlineStride * height`. But the problem is that we don't really know the `startingOffset`, we only know offsets of the individual components, which leads to the other issue...
>
>> the size is not necessarily aligned to pixelStride because scanlineStride may include a gap larger than pixelStride at the end.
>
> Good point, and because of the way `pixelStride` and `scanlineStride` are formulated (offsets between same-band samples of the adjacent pixels/scanlines), they don't tell us anything about the alignment. And moreover, in the case of unused components, where our `bandOffsets` don't fully fill the `pixelStride`, there is an ambiguity:
> Consider `bandOffsets = {1, 2, 3}` and `pixelStride=4`, is that a `xRGB` layout with `startingOffset=0`, or `RGBx` with `startingOffset=1`? The answer is - we don't have enough info as far as I'm concerned...
I see a way to deal with this problem though - we don't have to deal with the ambiguity, but just allocate enough memory to be on the safe side no matter the interpretation of the layout - with the example I provided earlier `bandOffsets = {1, 2, 3}` and `pixelStride=4`, just allocate 1 extra byte at the end to prevent out-of-bounds access in any case.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24111#discussion_r2024744939
More information about the client-libs-dev
mailing list