2024.02.05 19:49 "[Tiff] error reading linearRaw subIFD from a TIFF file with libtiff built with libjpeg-turbo?", by Ellen Johnson

2024.02.06 20:47 "Re: [Tiff] error reading linearRaw subIFD from a TIFF file with libtiff built with libjpeg-turbo?", by Bob Friesenhahn

(I'm copying Even's reply in this thread, and adding Darrell from libjpeg-turbo after consulting with him).

Thank you for confirming libtiff does not support 16-bit JPEG.

This is very puzzling to me. I think it means that before I built libtiff v4.6.0 with libjpeg-turbo v3.0.0, we must have had a patch or modification in our libtiff version or our old libjpeg v6b version that allowed us to read the 16-bit linearRaw subimage in the TIFF file.

Something I find interesting is that in GraphicsMagick, the JPEG reader is not using the libjpeg/libjpeg-turbo dual/triple mode with its added per-depth APIs (which seemed to originally be added for libtiff to use). The approach currently used by GM worked with some other older libjpeg's, including one which supported 16-bit samples.

The approach used is this:

           if (jpeg_info.data_precision > 8)
             {
               unsigned int
                 scale_short;

               scale_short=65535U/MaxValueGivenBits(jpeg_info.data_precision);
               for (x=0; x < (long) image->columns; x++)
                 {
                   q->red=ScaleShortToQuantum(scale_short*GETJSAMPLE(*p++));
                   q->green=ScaleShortToQuantum(scale_short*GETJSAMPLE(*p++));
                   q->blue=ScaleShortToQuantum(scale_short*GETJSAMPLE(*p++));
                   if (jpeg_info.output_components > 3)
                     q->opacity=ScaleShortToQuantum(scale_short*GETJSAMPLE(*p++));
                   else
                     q->opacity=OpaqueOpacity;
                   q++;
                 }
             }

This assumes that the size of JSAMPLE will be sufficient for the range supported by jpeg_info.data_precision. For example, JSAMPLE could be based on uint16_t, or the macro could be smart enough to form a uint8_t or uint16_t based on a stream of octets.

I do need to personally re-test with recent libjpeg-turbo to make sure that the approach works properly, but others have reported success.

Bob

Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt