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! _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
