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

2014.12.15 19:53 "Re: [Tiff] Unnecessary bigger JPEG-compressed TIFF", by Joris Van Damme


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.

  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, 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.
  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.
  3. Please ignore me if this is not relevant to your situation right now.

Best regards,