[gdal-dev] [Tiff] Unnecessary bigger JPEG-compressed TIFF

[Even Rouault]

Le lundi 15 décembre 2014 20:53:40, Joris Van Damme (AWare Systems) a écrit :
> Even,
> 
> > Note however that this complicates the case where one updates an existing
> > JPEG-compressed TIFF.
> 
> I'm not sure I completely understand every detail of the complicated
> path in implementing these things in the LibTiff/LibJpeg combo. Here's
> just a few thoughts of mine, for you to evaluate whether or not they
> are even relevant.

Joris,

thanks for you thoughts.

> 
> 1) The JpegTables tag data can be present, even when JPEG tables are
> included in some or all of the JPEG compressed strips or tiles. If
> this is the case, the JPEG tables included in the JPEG compressed
> strip or tile, overrides the global JpegTables tag data for this
> particular strip or tile. Therefore, updating a single strip or tile
> should actually not be that hard. If the encoder is unwilling to go
> through the trouble of "adopting" the JpegTables tag data, it's
> perfectly free to locally override with whatever tables it sees fit,

Hum http://www.remotesensing.org/libtiff/TIFFTechNote2.html mentions "An image 
segment may not redefine any table defined in JPEGTables.", so my understanding 
is that a strip/tiff that would want to have custom tables should use different 
table numbers.

> for whatever strips or tiles it wishes to update, but still leave the
> tag as is to apply to any other strip or tile that may not override
> it.

Yes I agree the JPEG-in-TIFF specification allows this, but my understanding 
libtiff has never really supported this. It would require comparing the tables 
generated with the current quality setting with the ones in JpegTables tag, 
and if they do not match, install new tables and reference them in the libjpeg 
component definition.

> 
> 2) Any codepath that depends on notions like LibJpeg quality, better
> be optional. The quality concept in LibJpeg is an implementation
> detail, not a part of the JPEG specification. The same goes for the
> default tables that correspond to different quality settings. Other
> TIFF/JPEG combo codecs are very likely to come up with default tables,
> if any, that do not match any LibJpeg quality setting. If what you aim
> to do depends on correctly deriving LibJpeg quality settings, from
> files produced by other codecs, it will likely fail.

Yes I'm well aware that my current solution does not cover all cases. Doing 
the right thing with only libtiff + libjpeg itself was already tricky enough. 
My motivation was mainly to fix the size regression, and ensuring that 
reasonably simple update use cases would still work.

Even

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