2009.11.30 05:05 "[Tiff] TIFFTAG_JPEGTABLES mandatory for JPEG-in-TIFF since 3.8.x ?", by Lee Howard

2009.11.30 09:05 "Re: [Tiff] TIFFTAG_JPEGTABLES mandatory for JPEG-in-TIFF since 3.8.x ?", by Lee Howard

Joris Van Damme (AWare Systems) wrote:

From a JPEG point of view, there roughly exists two options.

In this particular case I'm dealing with a JPEG image that is provided from a fax machine, and I'm merely wrapping it with TIFF in order to provide the application with multi-page color fax reception support in one file... as well as the ability to use other TIFF tags for data storage. So unless I intend to alter the image that is provided by the fax machine (and I don't), then I just will be dealing with the JPEG as-is.

This is complicated somewhat by two things: 1) fax machines generally omit image length from the SOF marker and instead use a DNL marker - I take the data from the DNL marker and "fix" the SOF marker because DNL is largely unsupported by JPEG viewers/processors other than fax machines, and 2) fax machines use ITULAB colorspace - and I am now using LittleCMS to convert the colorspace to sRGB because ITULAB is largely unsupported by JPEG viewers/processors. So those are two exceptions to the statement I made above.

The entire JPEG image is written in one strip with TIFFWriteRawStrip. So I don't think that there's any savings to be had in this option.

I can't speak to the optimization - I'd like to leave this as provided by the fax machine as much as possible although I am processing the image with LittleCMS - but this sounds like the case I am dealing with. I'd prefer to trust the fax machine (or LittleCMS) to be responsible for optimization.

I don't know exactly what "reasonably small" means, but I don't think that this is the case - see the sample to which I linked in the last mail. But since there is only one strip I don't think that this option is applicable.

As the strip data will contain the same JPEG table information as would be included in any JPEGTABLES TIFF tag, I don't think this option is applicable, either.

Since I need to make the application be compatible with libtiff 3.8.2 - if there's not a way to avoid writing TIFFTAG_JPEGTABLES with that version when writing JPEG-in-TIFF, then I'll probably just need to write TIFFTAG_JPEGTABLES properly... but I wanted to understand if this was intentional behavior by libtiff, or if this is a bug, or if I just don't know what I'm doing (likely).

Must be categorized as a bug.

In libtiff/tif_jpeg.c there is this code at the very bottom of the file:

        ** Create a JPEGTables field if no directory has yet been created.
        ** We do this just to ensure that sufficient space is reserved for
        ** the JPEGTables field.  It will be properly created the right
        ** size later.
        if( tif->tif_diroff == 0 )

            TIFFSetFieldBit(tif, FIELD_JPEGTABLES);
            sp->jpegtables_length = SIZE_OF_JPEGTABLES;
            sp->jpegtables = (void *) _TIFFmalloc(sp->jpegtables_length);
            _TIFFmemset(sp->jpegtables, 0, SIZE_OF_JPEGTABLES);

This code was added after 3.7.2 and before 3.8.2, and it is this code which is causing TIFFTAG_JPEGTABLES to be added to the created TIFF file. If I comment-out this code then the tag is not put there.

Unfortunately, without the tag there I'm still not out of the woods. For example, running the TIFF file through tiff2ps gives me...

JPEGPreDecode: Warning, Improper JPEG sampling factors 2,2 Apparently should be 1,1..

JPEGPreDecode: Cannot honour JPEG sampling factors that exceed those specified..

Does this mean that I should be setting YCBCRSUBSAMPLING?