2005.04.29 23:16 "Re: [Tiff] Color TIFF/JPEG compression questions", by Joris Van Damme

Jason,

Without viewing the image, I'm guessing the YCbCr subsampling is the problem...

It's in the file twice, redundantly. It's in a tag value. But, since the strip is supposed to make sense as a jpeg as a whole, it's in there too. And even if it wouldn't, the actual compressed data does not make sense to a jpeg decompressor given wrong YCbCr subsampling values, so in that sense, from an information point of view, it's in there...

This is all for good reason... We learned the hard way it's best for individual strips/tiles to make sense as a valid jpeg all by themselves. But to set up needed decoding steps, knowledge about the YCbCr subsampling values are needed... So this is a good scheme, but, sure enough, if any given piece of data is in there twice or more, one vendor sooner or later will manage to muck up...

Technically, it's most often a seperate jpeg codec that is responsable for the complete jpeg tile/strip decompression/compression. So, it makes sense to assume the YCbCr subsampling values inside the jpeg data are most likely to be the correct ones, when contradicated by the values in the TIFF IFD. So, at one time, Frank decided to add support for this type of invalid files by scanning the first strip/tile in a very early stage, and correcting the values read from the TIFF IFD from that.

This explaines the warning messages...

JPEGPreDecode: Warning, Improper JPEG sampling factors 2,1 Apparently should be 1,1..
JPEGPreDecode: Warning, Decompressor will try reading with sampling 2,1..

Is that all there is to it? No, I don't think so... I see that the YCbCr subsampling tag is in the tag dump produced by tiffinfo, but not in the output of tiffdump, unless I missed it somehow... Possibly the tag isn't even there, and some resorting to default values takes place at some stage.

TIFFReadDirectory: Warning, 1.tif: unknown field with tag 513 (0x201) encountered.

This is the JpegInterchangeFormat tag. See http://www.awaresystems.be/imaging/tiff/tifftags/jpeginterchangeformat.html. It was used in old-style jpeg compression, compression value 6. It's not recognized by LibTiff, since it's considered a 'compression dependent' tag, that only is recognized in combination with compression 6 (which I personally don't think is a good idea, but hey).

My guess is that Snowbound writes files that are not just a bit invalid. Did they decide to just pick some elements of compression 6, and some of compression 7, and call that jpeg-in-tiff?

Segmentation Fault

Of course, there's no excuse, this isn't Snowbound's segmentation fault.

The biggest issue I have is that I can't find a viewer that I know supports color tiffs correctly. If someone has a recommendation there, I'd be very grateful.

Good, valid, compression 7, new-style jpeg-in-tiff, is supported by almost every mainstream viewer, including the one you refered to. Another option is to forget about jpeg compression inside tiff alltogether, and use LZW or Deflate. But of course, that's not a substitute if you need to good compression ratio of lossy compression.

Is the image invalid? Do I need to talk to Snowbound?

Definitely. Refer them to Technote2, that is also absorbed in Specification Supplement 2.

Technote2:
http://www.remotesensing.org/libtiff/TIFFTechNote2.html
Specification supplement 2:
http://partners.adobe.com/public/developer/en/tiff/TIFFphotoshop.pdf

Should I try to get a stack trace on the SEGV?

Andrey will I think appreciate that, together with a good bugzilla entry.

Should I try to hack up a program to change the sampling factors internally and see if I can then process the file?

LibTiff already does that, all by itself, as explained above.

Joris Van Damme
info@awaresystems.be
http://www.awaresystems.be/
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html