Return-Path: <tiff-bounces@remotesensing.org>
Received: from inmx006.isp.belgacom.be (inmx006.isp.belgacom.be [195.238.2.106])
        by mailst035.isp.belgacom.be (8.12.11/8.12.11/Skynet-MAILSTORE-2.14) with ESMTP id j08N3BNo003291
        for <joris.at.lebbeke@skynet.be>; Sun, 9 Jan 2005 00:03:11 +0100
        (envelope-from <tiff-bounces@remotesensing.org>)
Received: from xserve.flids.com (adsl-065-083-169-202.sip.mco.bellsouth.net [65.83.169.202])
        by inmx006.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id j08N2j6H018772
        for <joris.at.lebbeke@skynet.be>; Sun, 9 Jan 2005 00:02:48 +0100
        (envelope-from <tiff-bounces@remotesensing.org>)
Received: from adsl-065-083-169-202.sip.mco.bellsouth.net (localhost [127.0.0.1])
	by xserve.flids.com (Postfix) with ESMTP
	id 0490159FB14; Sat,  8 Jan 2005 18:02:08 -0500 (EST)
X-Original-To: tiff@remotesensing.org
Delivered-To: tiff@remotesensing.org
Received: from outmx008.isp.belgacom.be (outmx008.isp.belgacom.be
	[195.238.3.235])
	by xserve.flids.com (Postfix) with ESMTP id D281959FAED
	for <tiff@remotesensing.org>; Sat,  8 Jan 2005 18:02:05 -0500 (EST)
Received: from outmx008.isp.belgacom.be (localhost [127.0.0.1])
	by outmx008.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with
	ESMTP id j08N23rA007472
	for <tiff@remotesensing.org>; Sun, 9 Jan 2005 00:02:03 +0100
	(envelope-from <joris.at.lebbeke@skynet.be>)
Received: from dfgrrxsknr4e (29-175.245.81.adsl.skynet.be [81.245.175.29])
	by outmx008.isp.belgacom.be (8.12.11/8.12.11/Skynet-OUT-2.22) with SMTP
	id j08N20tX007456; Sun, 9 Jan 2005 00:02:00 +0100
	(envelope-from <joris.at.lebbeke@skynet.be>)
Message-ID: <003c01c4f5d6$4b84fe30$1daff551@dfgrrxsknr4e>
From: "Joris" <joris.at.lebbeke@skynet.be>
To: "Lee Howard" <faxguy@howardsilvan.com>
References: <20050107201814.GI21464@bilbo.x101.com><000d01c4f52a$d9634650$53adf551@dfgrrxsknr4e>
	<20050108163638.GK32383@bilbo.x101.com>
Subject: Re: [Tiff] JPEG (T.30-E, fax) in TIFF
Date: Sun, 9 Jan 2005 00:03:38 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
Cc: tiff@remotesensing.org
X-BeenThere: tiff@remotesensing.org
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: TIFF and libtiff discussion  <tiff.remotesensing.org>
List-Unsubscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=unsubscribe>
List-Archive: <http://xserve.flids.com/pipermail/tiff>
List-Post: <mailto:tiff@remotesensing.org>
List-Help: <mailto:tiff-request@remotesensing.org?subject=help>
List-Subscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=subscribe>
Sender: tiff-bounces@remotesensing.org
Errors-To: tiff-bounces@remotesensing.org
X-UIDL: fce894673a0a2ac69bd13382e4974871

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

_______________________________________________
Tiff mailing list
Tiff@remotesensing.org
http://xserve.flids.com/mailman/listinfo/tiff
