2009.02.12 10:45 "[Tiff] Crosstesting request 12 bits per sample JPEG compression in TIFF", by

2009.02.13 11:21 "Re: [Tiff] Crosstesting request 12 bits per sample JPEG compression in TIFF", by

Bob,

Previously the test file in this package was contributed:

ftp://ftp.graphicsmagick.org/pub/outgoing/mandrill-12bit-JPEG-TIFF.zip

That seems to do fine, in my decoder, except for the last IFD in mandrilrgb_12.tif.

All IFDs in both files except this last IFD in mandrilrgb_12.tif contain YCbCr data. They do not include an YCbCrSubsampling tag, meaning the assumption that works most of the time is that the writer probably feels subsampling should not apply to 12 bit per sample data. I dissagree, but I do decode fine. In the end, it's the subsampling value auto-correction that always saves the day, as it turns out the JPEG data in these files actually do have subsampling [2,2].

It's a mess. The cause of the mess is that the default value of the tag is not [1,1], which means the absence of the tag means different things depending on whether you believe subsampling applies, and the latter is open for discussion. We had a similar situation when combining JPEG compression with colorspaces like ITULAB.

The best thing a writer can do is avoiding the ambigiouty by always including the subsampling tag in these cases, using values [1,1] if it feels subsampling doesn't apply, making all perfectly and unambigiously clear to anyone.

The best thing a reader can do, is assuming [2,2] if the tag is absent and we've 8 bit per sample YCbCr, and assuming [1,1] if the tag is absent and any color space like ITULAB and/or bitdepth like 12 bits per sample is used, because in those cases the absence of the tag likely means the writer feels subsampling doesn't apply. I find this is the option that works best, on most files, but not on all. It would not have worked on these madrill files. It can and should be improved by adding an auto-correction feature double-checking these values if compression scheme allows such a double-check as is the case with compression scheme JPEG (scanning the compressed data of the first strip/tile to the SOF marker and retrieving the subsampling values from this marker) and NONE (deriving the subsampling values from the strip/tile bytecounts). It's this auto-correction that allows my decoder to render these madrill files that would otherwise be problematic.

The situation with the last IFD in mandrilrgb_12.tif is different. The photometric in this case is actually RGB. Subsampling cannot ever apply to RGB, whatever way you feel about subsampling. So, subsampling values are the no-subsampling ones [1,1]. There ought to be no need to double-check. Yet, the JPEG compressed data is subsampled [2,2]. This cannot be interpreted as even remotely correct, no matter what, and I don't support it.

It's very interesting to view this situation in the current discussion about error/warning handling/recovery. mandrilrgb_12.tif contains old-style tile-pyramid storage, meaning the main linked list of IFDs are all the same image at different resolutions. What should an application do if an image interpretation or image rendering level 'critical' error occurs when accessing a particular 'tile pyramid' layer with particular resolution? Right, it should interpret this as IFD-rendering error, which is different from page-rendering error, as its proper attempt at recovery should be trying to access and render the IFD representing the next bigger pyramid layer, which in this case does actually yield a full recovery and correct rendering of the page.

Best regards,

Joris