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

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

Le lundi 15 décembre 2014 20:53:40, Joris Van Damme (AWare Systems) a écrit:

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.


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.

  1. 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.

  1. 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.


Spatialys - Geospatial professional services