2021.06.17 16:34 "[Tiff] IJG libjpeg-9d breaks libtiff JPEG-in-TIFF compression", by Even Rouault

2021.06.18 15:00 "Re: [Tiff] IJG libjpeg-9d breaks libtiff JPEG-in-TIFF compression", by Guido Vollbeding

Hi Even

Thank you for feedback.

It is not a bug, it's a feature! It was found that jpeg_set_defaults() is the wrong place to create default Huffman tables:

  1. We don't want to create tables for chrominance channels when monochrome output is requested. (You are doing something similar in your prepare_JPEGTables() function...)
  2. We don't want to create default tables when Huffman optimization is requested.
  3. We don't want to create ANY Huffman tables when arithmetic coding is requested.

The configuration of these options is done AFTER calling jpeg_set_defaults() and BEFORE calling jpeg_start_compress(). That's why jpeg_start_compress() is the right place to create the tables, when all compression parameters are properly set, NOT jpeg_set_defaults().

We have found a workaround in the meantime with https://gitlab.com/libtiff/libtiff/-/merge_requests/255, by manually creating the default Huffman tables, but it is a bit unfortunate that we have to do that.

It may be unfortunate if you think that you have to do that. The truth is that you don't have to do that! Another corresponding new feature of libjpeg 9d is that the decoder creates default Huffman tables "on the fly" if they are missing in the datastream (see the second item in change.log). So if you are using libjpeg 9d for compression with your unmodified code (thus omitting default Huffman tables), it should be no problem to decode the files if you are also using libjpeg 9d for decompression. I recommend that you try this out and confirm the assumption. Note that it is now general consensus for JPEG decoders to work with undefined Huffman tables for compatibility with Motion-JPEG streams.

The behaviour is as described perfectly consistent. The problem only arises if you expect an older decoder to work with files created by recent encoder (in your specific case - the default tables will still be created by jpeg_start_compress() for normal use). That is the question that you have to ask yourself. My answer would be to rely on the consistency within either the recent or the older codecs. You need a workaround only if you still want to support older decoders with your recent encoders. Let me know what your answer is. I would have a suggestion for solution in your code which would be a bit less unfortunate than your actual workaround.

Regards
Guido Vollbeding
Organizer Independent JPEG Group


Editor's note: This mail was not originally archived, and has been reconstructed from quotes.