2009.02.13 16:58 "RE: [Tiff] Crosstesting request 12 bits per sample JPEG compressionin TIFF", by Grissom, Edward
As it turns out, I am pretty sure that particular test image was generated by my (non-LibTIFF based) software. Luckily, my software is rarely used to write out untiled imagery, and the tiled version seemed to be a bit better -- at least all the overviews (IFDs) were PhotometricInterp=YCbCr, which is what I thought I was asking libJPEG to create for me.
Given that the last IFD is really supposed to be YCbCr data, and supposed to be marked as such in the IFD, what else needs to be done to have a fully interchangeable file? (I am wondering if the fact that the image size is less than one MCU has something to do with this change)
Finally, I note that the JPEG tables tag in the first IFD is much bigger than is necessary, but is seems that does not bother your software? That has been a hard bug to track down, especially since it does not seem to cause any problems for 3rdparty code.
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Joris Van Damme (AWare Systems)
Sent: Friday, February 13, 2009 5:22 AM
To: Bob Friesenhahn
Cc: TIFF mailing list
Subject: Re: [Tiff] Crosstesting request 12 bits per sample JPEG compressionin TIFF
Previously the test file in this package was contributed:
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 situatio