[gdal-dev] IReadBlock fails on alpha band, GDAL 2

[Matt Perry]

Even,

Thanks for the fix, the workaround and the detailed explanation. I
knew there must be a reason for the strange threshold.

>>     hBand = GDALGetRasterBand( hDataset, 4 );
>>     pafScanline = (int *) CPLMalloc(sizeof(int) * 734 * 734);
>>     GDALRasterIO( hBand, GF_Read, 0, 0, 1223, 1223,
>>                     pafScanline, 734, 734, GDT_Byte, 0, 0 );
>>
>
> Note. You have a few inconsistencies here : pafScanline is supposed to mean
> array of float, but you do a sizeof(int), and finally you request GDT_Byte ;-)
> But the issue is different. See below

Sorry, that was lazy transcription on my part. The actual code at
https://gist.github.com/perrygeo/07ce04fe886d1c8090ab1b22d7579396
doesn't have the same problem. But as you said, the issue is
elsewhere...

>
>> I'm curious why it there appears to be a buffer size threshold, why it
>> only affects alpha bands and why only GDAL 2.x is affected.
>
> Since GDAL 2.0, the GTiff driver can take advantage of the fact that JPEG
> compression naturally contains easily decodable subsampled images at factors
> 2, 4 or 8 to speed-up RasterIO() requests involving subsampling (and the
> threshold from which overview of factor ovr_factor are used is size below
> full_res_size * 1.2 / ovr_factor. 1223 * 1.2 / 2 = 733.8).

Thanks, that makes sense now.

> this wasn't indeed ready for RGBA JPEG-in-TIFF, which is an odd (not to say
> probably illegal, or at the very least non-standard, since I guess 4 band JPEG
> should be in CMYK colorspace) formulation.

Are there any other problems that you anticipate with using this
configuration? I see RGBA JPEG-in-TIFF quite often...


> Fixed per https://trac.osgeo.org/gdal/ticket/6493
> Use of implicit overviews can be disabled by defining the config option
> GTIFF_IMPLICIT_JPEG_OVR=NO

I can confirm that setting GTIFF_IMPLICIT_JPEG_OVR works and this will
suffice as a workaround until the next GDAL release. Thanks, Even!