Return-Path: <tiff-bounces@remotesensing.org>
Received: from xserve.flids.com (adsl-065-083-169-202.sip.mco.bellsouth.net [65.83.169.202])
        by inmx005.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id j3UFufew001238
        for <joris.at.lebbeke@skynet.be>; Sat, 30 Apr 2005 17:56:41 +0200
        (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 397D524E1724; Sat, 30 Apr 2005 11:56:01 -0400 (EDT)
X-Original-To: tiff@remotesensing.org
Delivered-To: tiff@remotesensing.org
Received: from mail.srcp.com (unknown [12.5.252.28])
	by xserve.flids.com (Postfix) with ESMTP id 0C58824E1700
	for <tiff@remotesensing.org>; Sat, 30 Apr 2005 11:55:59 -0400 (EDT)
Received: from CORPDALLMSG05.na.srcp.net ([10.150.10.111] RDNS failed) by
	mail.srcp.com with Microsoft SMTPSVC(6.0.3790.211); 
	Sat, 30 Apr 2005 10:55:55 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Tiff] Color TIFF/JPEG compression questions
Date: Sat, 30 Apr 2005 10:51:32 -0500
Message-ID: <741E24F735AED141B61948AC155E7DAA04EDDC@CORPDALLMSG05.na.srcp.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Tiff] Color TIFF/JPEG compression questions
Thread-Index: AcVNEZAksP3Wj3QjTF6Xed1tcCh2IgAiusDv
From: "Frank, Jason" <JasonFrank@srcp.com>
To: "Joris" <joris.at.lebbeke@skynet.be>, <tiff@remotesensing.org>
X-OriginalArrivalTime: 30 Apr 2005 15:55:55.0824 (UTC)
	FILETIME=[1806F300:01C54D9D]
Cc: 
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
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by inmx005.isp.belgacom.be id j3UFufew001238
X-UIDL: 000000000023ceae.0000017c
X-MSP-STORE: Sat, 30 Apr 2005 17:56:53 +0200
Status:   

Thanks, I agree with your analysis, I just didn't care to tell the vendor that they're wrong w/o having someone smarter than myself back me up..  I thought that Snowbound produced the code changes a little too quicly, and their first version didn't even change the compression type.  I'll forward your response on to them, and see what they say.  Thanks for looking that this for me.

The image has some slightly confidential information on it, enough that I want to get approval from the client, and I won't have that until Monday.  NP though, I"ll let Snowbound deal with it.

Thanks again for your help.

Jason


-----Original Message-----
From: tiff-bounces@remotesensing.org on behalf of Joris
Sent: Fri 4/29/2005 6:16 PM
To: Frank, Jason; tiff@remotesensing.org
Subject: Re: [Tiff] Color TIFF/JPEG compression questions
 
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

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

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

