2021.06.18 15:11 "Re: [Tiff] IJG libjpeg-9d breaks libtiff JPEG-in-TIFF compression", by Even Rouault

Guido,

thanks for your answer.

The way JPEG-in-TIFF works is a bit different than just a JFIF file, and libtiff certainly use the libjpeg API in some unusal way. JPEG-in-TIFF requirements are described in https://www.awaresystems.be/imaging/tiff/specification/TIFFTechNote2.txt. There are several modes possible for JPEG-in-TIFF, and one of those modes (which is the default currently used by libtiff) is when each independently compressed TIFF tile or strip doesn't include itself the Huffman tables but uses common tables contained in the JpegTables TIFF tag that apply to all TIFF tile/strip. With previous versions of IJG libjpeg or libjpeg-turbo, we could call jpeg_set_defaults(), do some manual tweaking of which table we wanted to output by setting sent_table to TRUE/FALSE, and finally call jpeg_write_tables() to extract a JPEG codestream with only the Huffman and/or quantization table, that we put in the JpegTABLES TIFF tag, even before to have pixels to compress with jpeg_start_compress().

If we use the JPEG-in-TIFF mode where each tile/strip uses its own Huffman tables, things still work fine with libjpeg 9d.

Regarding being dependent on specific behavior of libjpeg 9d on the decoding side, we cannot do this. libtiff is typically built against other implementations of libjpeg (libjpeg-turbo being quite popular). We have also to output something that is conformant with the TIFFTechNote2 and any library (possibly not even using libtiff) implementing it should be able to decode what libtiff outputs. This is all about interoperability: there isn't much place for innovation, or it must carefully fits into the degree of freedoms permitted by the specification.

I'd be curious to hear your suggestion for a prettier alternative to my workaround though.

Even

http://www.spatialys.com
My software is free, but my time generally not.