[gdal-dev] Unnecessary bigger JPEG-compressed TIFF

Even Rouault even.rouault at spatialys.com
Mon Dec 15 09:49:41 PST 2014


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


More information about the gdal-dev mailing list