LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
February 2009
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2009.02.13 16:58 "Re: Crosstesting request 12 bits per sample JPEG compressionin TIFF", by Edward Grissom
Wow. 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. -- ed grissom ed.grissom@intergraph.com -----Original Message----- From: tiff-bounces@lists.maptools.org [mailto:tiff-bounces@lists.maptools.org] 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 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