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

[Even Rouault]

Hi Matt,

> I'm seeing some errors reading reduced-resolution buffers from the
> alpha band of an RGBA image.
> 
> Code and link to raster to reproduce:
> https://gist.github.com/perrygeo/07ce04fe886d1c8090ab1b22d7579396
> 
> 
> The original raster is 4 bands, 1223x1223. If I attempt to read a
> 734x734 buffer (or any smaller resolution) from the alpha band
> 
>     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

> 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). This was OK for  
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.

> Before I
> dig in, does anyone have any theories about what's going on here?

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 

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com