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

2009.02.15 10:53 "Re: [Tiff] Crosstesting request 12 bits per sample JPEG compressionin TIFF", by

Ed,

As it turns out, I am pretty sure that particular test image was generated by my (non-LibTIFF based) software.

Can your software read (part of) my testimage suite at http://www.awaresystems.be/imaging/tiff/12bpsjpegintiff.zip?

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?

That's a difficult question, because the spec as I mentioned before does not anticipate a lot of our needs in this 12 bits per sample JPEG compressed subsampled YCbCr area. Us 'interpolating' it does not necessarilly lead to anything even remotely official and it's possible we don't all agree on some topics. Though we can, of course, do our very best to 'interpolate lineairly'.

  1. I believe today's software should use the "new" tile pyramid scheme. In other words, don't put all IFDs in the main linked list, make the lower-resolution ones SubIFDs of the main IFD instead. That's cleaner in that it allows to have a logical distinct hiërarchical structure of 'pages' of different images on the one hand, and images encoding the page at different resolutions on the other hand. It is also more robust when faced with 'dumb' TIFF splitters and other operations of IFD linking and unlinking, these need not try and interprete the NewSubfileType tag and hope that a NewSubfileType value 'reduced resolution image' still means reduced resolution version of the previous IFD despite of any 'dumb' TIFF IFD linking and unlinking that might have gone before.
  2. I strongly recommend including the YCbCrSubsampling tag in any IFD that even a single person can interpret as potentially having subsampling applying to it. If you feel it doesn't apply, then use the value [1,1]. Codecs who agree it doesn't apply will/should ignore the tag, and all will be fine. Codecs who dissagree, will read [1,1] meaning there's no subsampling, and that's also the correct interpretation of your IFD then. Clearly, your software, as does mine, feels that subsampling *does* apply, and uses the default [2,2]. But write the tag making this unambigiously clear.
  3. The final problem you know about already:

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.

Yes, there's a weird problem here. All your strips and tiles include DHT markers defining the huffman tables. That's fine, the JPEG specification does not have default huffman tables for 12 bits per sample data, nor does LibJpeg, and thus optimized huffman tables need to be used unless you've somehow derived your own set of suitable defaults. Personally, my own encoder also includes the quantization tables in each strip/tile, as they don't take up too much space and it seems clean to follow the same logic for all tables. Your encoder seems to prefer using the JpegTables to group the quantization table definitions, and that's fine too. So, in the JpegTables tag, I'd expect a SOI, DQT, DQT, EOI sequence or similar.

Instead, in your first IFD JpegTables tag, I see a SOI, DQT, DQT, DHT, DHT, DHT, DHT, EOI, SOI, DQT, DQT, DHT, DHT, DHT, DHT, EOI, SOI,... etc sequence. In other words, you've not a single tables-only jpeg there, but you've 8 concattenated tables-only jpegs there, and they don't just include the quantization markers but the huffman table markers too.

The situation should indeed still be unambigious for all reading software. Anything after the first EOI marker in the JpegTables tag should be ignored. The definition of huffman tables in the JpegTables tag, should get overwritten by the definition of the huffman tables in the each strip/tile.