[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