2005.01.14 02:22 "Re: [Tiff] JPEG (T.30-E, fax) in TIFF", by Joris Van Damme

Lee,

Okay, following your advice as best as I can I have come up with:

http://gateway.howardsilvan.com/fax000003470.tif

It took a while, but I was finally able to decode the TIFF with code that does not depend on LibTiff, for crosstesting. I'll privatly send you a reduced resolution ordinary YCbCr jpeg of the result in the copy to you, for checking.

** StripOffsets/StripByteCounts **

The count of these tags is wrong, but you already knew.

** FillOrder **

This value is wrong. It should instead be default, or not be there at all. LibTiff might be forgiving of this wrong value, but that's a flaw rather then a feature - I suspect it just doesn't care when combined with JPEG compression, and it should, because the fillorder handling is a step in the decoding process that is theoretically completely independent, even if some of the decompressors can more optimally handle it together with decompressing.

** YCbCrSubsampling **

This value is wrong. In JPEG-style notation, the subsampling is 2:1:1, and that corresponds to the TIFF-style YCbCrSubsampling values 2,2. This is the default, so if you're sure that all your source JPEGs will have the same subsampling, you could just ignore this tag and not set it at all.

** Decode **

I haven't (yet) been able to check whether the source JPEG contains the APP marker used to specify Decode parameters other than the ITULAB default, because I seem to have misplaced the spec that explained that APP marker and can't find any old code and can't remember, either. But, using the default to decode your image yields visually pleasing results, and I know from past experience that non-default Decode parameters are rare at best. So I guess we now know reasonably sure that you can probably ignore the Decode tag, too.

** More general **

Unless, of course, you are set out to build yourself a solution that works for *any* ITULAB color-fax-jpeg, as opposed to the ones from the same single source, in that case you'll probably have to detect proper values for the YCbCrSubsampling and Decode tags from your JPEG stream. Let me know if that is the case, and I shall try and find time to help out if I may, this is all very interesting...

Plus, I'm still keen on the general JPEG to JPEG-in-TIFF converter... I'm thinking of a general scheme, something like

sequentially add blocks of JPEG data to the single strip (so that the scheme fits a slow JPEG reception without temp buffer, like you want it)
while doing so, also sequentially feed these blocks to LibJpeg, which should be linked in LibTiff anyway, so as to read all relevant properties like color space, subsampling, etc, from the JPEG stream. At this stage, also especially note DNL, and if so, remember position to write fix-up and count lines
when that's done, fill in the tags with the info read from the JPEG stream.
also do the DNL fix-up now, if necessary

I'm unsure, however, how much of tag setting LibTiff allows to be postponed untill after the strip writing stage.

I you or anyone on this list wishes to join in to explore this further, now would be a good time to say so.

In any case, please keep us informed whatever happens next. It's not the first time ITULAB related stuff comes up in this list, so it would be nice to see and archive where this is going.

Like you, I'm also hoping to hear from anyone who wishes to extend tiffcp to be able to deal with these ITULAB tiffs. It should be possible to build a new testfile that is more correct, since the FillOrder and YCbCrSubsampling mistakes should be easy to correct, and Decode should be as easy to ignore as before. All that remains is the Strip tags count bug, but we could even work and extend tiffcp from a TIFF testfile that is buggy in that regard, since LibTiff seems to automatically compensate by 'trimming' those tag values.

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