2005.01.08 23:03 "Re: [Tiff] JPEG (T.30-E, fax) in TIFF", by Joris Van Damme

Lee,

I strongly feel that you really should state the correct information in the Compression, Photometric, SamplesPerPixel, YCbCrSubSampling, and StripOffsets/StripByteCounts tags. If not, you might be able to build a file that some tool might be able to handle, but that's really an anomaly, you're building an incorrect file really, and in five years from now even that some tool might not be able to handle anymore. Whereas, building the file correctly, and maybe convincing Andrey to help out extending tiffcp and the like, if he wants to, could be a much more promising road for us all.

** Compression **

Compression is set to 7 (COMPRESSION_JPEG)

I guess we're clear on that one

** PhotometricInterpretation **

PhotometricInterpretation is set to 10 (PHOTOMETRIC_ITULAB)

> had been testing with PHOTOMETRIC_RGB

Ed Grissom suggested that I try PHOTOMETRIC_YCBCR

Both are incorrect. You should really use PHOTOMETRIC_ITULAB, because the Photometric is ITULAB.

Using YCbCr might get you passed tiffcp. But besides being a mistake, it will solve nothing, because then next your ITULAB data will be interpreted as being YCbCr, which it is not, and for instance convertion from YCbCr to RGB will be applied in order to display, which will yield funny stuff but not a correct image.

However, viewing the JPEG-in-TIFF image there was a very noticeable blue tint,

Yes, this is the sort of funny stuff I'd expect. The ITULAB data is interpreted under the incorrect impression that it is YCbCr, which the viewing software correctly gets from your incorrect Photometric setting.

much like viewing the JPEG I linked before directly in Mozilla.

This is another but related issue. Very few JPEG viewers are build to deal with ITULAB. What most do, due to historical reasons (late arrival of JFIF standard, poor color space specification in JPEG before that time), is simply assume a JPEG they can't really make sense of to contain YCbCr. So, for different reasons, these JPEG viewers are making a mistake, which is the same but correct mistake to make for the TIFF viewers if you specify Photometric YCbCr.

** YCbCrSubSampling **

> > > 4:1:1 Chrominance subsampling
> >
> > You'll also need to set the YCbCrSubSampling tag, since your subsampling

values are not the default.

YCBCRSUBSAMPLING left at the 2:2 default

At one time, Frank was asked to have LibTiff deal with TIFFs that had incorrect YCbCrSubSampling tag values. This SubSampling information is redundant, in that it is also present inside the JPEG compressed data. But it is needed, in that it enabled LibTiff (and any logical TIFF codec design) to set up proper decoding structures before starting to handle the JPEG compressed data.

What Frank did, is add code to the IFD reading/initializing section that actually decompresses the first JPEG compressed strip/tile with LibJpeg, only to read that SubSampling information from the JPEG compressed data, and overwrite the value specified by the tag if necessary. This is part of the IFD reading/initialization section, a second round of LibJpeg decompression on the same first strip/tile is used when you call the necessary Strip/Tile reading functions.

It might seem horrible, and it is, but it works, and solves the problem of reading TIFFs with incorrect YCbCrSubSampling information, which aren't very uncommon.

This explains why your bad information is forgiven by a reader. It also explains some of the warning messages, like

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

...and it might also be related to...

JPEGLib: Warning, Application transferred too many scanlines.

...but I'm not entirely sure about the last one.

You should really specify correct YCbCrSubSampling values though, really.

** RowsPerStrip **

and rows per strip needs to equal ImageLength.

I can't use unlimited (-1)?

Yes, you can, -1 should be perfectly fine.

** StripByteCounts/StripOffsets **

single value of StripOffsets and StripByteCounts

fax000003467.tif: Warning, incorrect count for field "StripOffsets" (3, expecting 1); tag trimmed.
fax000003467.tif: Warning, incorrect count for field "StripByteCounts" (3, expecting 1); tag trimmed.

It seems to be affected by the SAMPLESPERPIXEL tag. If I change the SAMPLESPERPIXEL tag to 1 I only get one single value of StripOffsets and StripByteCounts. If I just change the SAMPLESPERPIXEL tag to 3 then I get three values in each of StripOffsets and StripByteCounts. I don't know if I'm doing something wrong or if there is a libtiff bug in this.

This may be related to the PlanarConfiguration setting, if SamplesPerPixel influences this. Have you tried setting PlanarConfiguration, even though you've found LibTiff to use the proper default?

Just guessing, though.

** Decode **

Now, for the less obvious. You might need to set the Decode tag

depending on whether the ITULAB data in the JPEG has default range or not.

Aha! Well, this probably explains why my image appears blue.

I wouldn't be so sure. Past, long forgotten experience with ITULAB color-fax-for-internet-JPEGs lead me to believe that non-default values for the Decode information are quite rare.

The cause of your image appearing blue is most probably it is interpreted as YCbCr instead, see above.

If your JPEG uses non-default values, they should be in that JPEG file somewhere. It's an APP marker, but I can't remember which one or how the data was labeled and structured... It's in a spec, somewhere, though...

** More general **

Unfortunately, the YCBCRSUBSAMPLING tag appears to be ignored by tiffcp when the photometric tag is not set for YCbCr.

In my opinion, you should give up on trying to build your files such that they are handled by tiffcp, in this first stage. If this attempt involves 'forging' the Photometric indication, it's bound to lead to trouble later in the process, anyway, and it build you incorrect TIFF files that you cannot hope will ever get supported any better.

Instead, try to build a correct TIFF. You seem to have been on that track before, (almost?) successfully. Next, try extending tiffcp, possibly Andrey might be persuaded to help you in that area. Then, all will be well, and your files wil be correct.

If you want, I can maybe help out by double-checking a correctly build TIFF with independent non-LibTiff software. That's only going to be an additional indication of the TIFF being valid, not a defenite proof, and I'll need to extend that independent software to deal with it. But at least it is an additional indication. Let me know.

If LibTiff doesn't write TIFFTAG_FAXRECVPARAMS and TIFFTAG_FAXRECVTIME tags for you, I believe this too, you'll probably need to ask Andrey's help.

** The code **

The repeated calling of TIFFWriteRawStrip seems very extremely weird. Could you try changing the DNL issue correction stuff to work on your JPEG data buffer, before calling TIFFWriteRawStrip, and next making one single TIFFWriteRawStrip call instead of the current three calls and the TIFFSetWriteOffset call.

** The link **

The HylaFAX links page still links to libtiff.org. Can you change that, or point me to someone who can? The correct LibTiff URL is, instead, http://www.remotesensing.org/libtiff/.

Oh, and yes, I am one of the webmasters. I've updated the link on the HylaFAX HOWTO, which I believe is the only relevant one. It may take a while to propagate to the live-side, though, so you may not see a change immediately.

Darren Nickerson changed the libtiff.org links on the HylaFAX links page, almost immediatelly after I posted this note. (Thanks, Darren!) Is probably why you couldn't find them. However, it seems you found another one. Thank you!

What happened to libtiff.org, may I ask?

Got hijacked...

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