2014.12.15 17:49 "[Tiff] Unnecessary bigger JPEG-compressed TIFF", by Even Rouault

Hi,

Just to notify that I've just fixed in libtiff HEAD a regression dating back from 2010 (libtiff 3.9.3 and 4.0.X) that caused JPEG quantization tables to be unnecessarily emitted in each strip/tile, even in the JPEGTABLESMODE_QUANT mode where they are supposed to be only emitted in the global TIFFTAG_JPEGTABLE tag.

Note however that this complicates the case where one updates an existing JPEG-compressed TIFF. One advantage of the previous behaviour is that it made that relatively safe. Now, one must properly set the JPEG quality to be the one used when generating TIFFTAG_JPEGTABLE. I've implemented in GDAL the logic to retrieve the quality fom the JPEGTABLE (quite ugly: by iterating from 1 to 100 until the computed table and serialized tables match), and if no match (shouldn't happen if the file has been created with libtiff), I go in TIFFTAG_JPEGTABLESMODE = 0 mode where tables will be emitted for each tile/strip. Probably this should be done in libtiff itself, when one detects a switch between TIFF directories (or at the first write in a directory), and by using the libjpeg decompressor so as to retrive the tables directly, without needing the quality value, but this didn't really seem straightforward to do in libtiff the compressor and decompressor structures being exclusive. Hum...

So, hopefully the new situation is better in the nominal case where one just create a JPEG-compressed file without updating it, by going back to the libtiff 3.8.X behaviour. And in the update scenarios, one must be careful of setting TIFFTAG_JPEGQUALITY to the right value.

Even

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