Return-Path: <tiff-bounces@lists.maptools.org>
Received: from inas031.isp.belgacom.be (localhost [127.0.0.1])
        by inav009.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-AV-3.00) with ESMTP id k93BfN6U030889
        for <joris.at.lebbeke@skynet.be>; Tue, 3 Oct 2006 13:41:42 +0200
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from inmx010.isp.belgacom.be (inmx010.isp.belgacom.be [195.238.4.73])
	by inas031.isp.belgacom.be (Postfix) with ESMTP id 0066117404D
	for <joris.at.lebbeke@skynet.be>; Tue,  3 Oct 2006 13:41:41 +0200 (CEST)
Received: from duke.maptools.org (r153.dmsolutions.ca [209.217.116.153] (may be forged))
        by inmx010.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-2.32) with ESMTP id k93BfdAr024688
        for <joris.at.lebbeke@skynet.be>; Tue, 3 Oct 2006 13:41:40 +0200
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from duke.maptools.org (duke.maptools.org [127.0.0.1])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id k93BRXRL008565;
	Tue, 3 Oct 2006 07:28:31 -0400
Received: from hermes.culture.fr (hermes.culture.fr [143.126.201.210])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id k93BRTI8008562
	for <tiff@lists.maptools.org>; Tue, 3 Oct 2006 07:27:30 -0400
Received: by mta.culture.fr with id k93BRS2f029420
	for <tiff@lists.maptools.org>; Tue, 3 Oct 2006 13:27:28 +0200
Received: from archives.culture.fr (archives.culture.fr) by 
	pasteur.culture.fr (Content Technologies SMTPRS 4.3.17) with ESMTP id 
	<T7b1ac447588f7ec9dc360@pasteur.culture.fr>; Tue, 3 Oct 2006 13:27:28 
	+0200
Received: by archives.culture.fr with ESMTP id k93BRS1t002751; Tue, 3 Oct 
	2006 13:27:28 +0200
Date: Tue, 3 Oct 2006 13:26:21 +0200
From: Jean-Yves Le Ridant <jean-yves.leridant@culture.gouv.fr>
X-Mailer: The Bat! (v3.0.1.33) Professional
Organization: Archives Nationales - CHAN
X-Priority: 3 (Normal)
Message-ID: <1853383234.20061003132621@culture.gouv.fr>
To: "Joris" <joris.at.lebbeke@skynet.be>
Subject: Re[4]: [Tiff] Status of ISO JBIG and CIELAB JPEG support
In-Reply-To: <000701c6e3c5$d591ea50$e3b6f551@dfgrrxsknr4e>
References: <1158887258.4513375a610fc@www.paypc.com> 
	<001101c6de38$45955ff0$86aff651@dfgrrxsknr4e> 
	<1159253318.4518cd4660fb1@www.paypc.com> 
	<00a001c6e233$851f0550$2abdf651@dfgrrxsknr4e> 
	<1159386162.451ad432d99a3@www.paypc.com> 
	<001301c6e275$129ce140$eaabf551@dfgrrxsknr4e> 
	<1396982621.20060929103020@culture.gouv.fr> 
	<000701c6e3c5$d591ea50$e3b6f551@dfgrrxsknr4e>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: LibTIFF Mailing List <tiff@lists.maptools.org>
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: Jean-Yves Le Ridant <jean-yves.leridant@culture.gouv.fr>
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=subscribe>
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org
X-UIDL: 000000000023ceae.00001b57
X-MSP-STORE: Tue, 03 Oct 2006 13:41:51 +0200
Status:   


> Now as to the content... I'm not going to add my usual lengthy analysis
> for every file, since that would make this a multipage post, but
> enumerate only the few problem areas.


> ** dad_cie.tif **

> This uncompressed 8bit CIELab file seems perfectly fine.

> I note that you don't specify the Subsampling tag, and don't use
> subsampling inside the data. The combination of this should mean that
> you have the 'strict' view on subsampling, i.e. that it only applies to
> YCbCr.

> ** dad_icc_jpeg.tif **

> This JPEG compressed 8bit ICCLab file seems perfectly fine.

> I note that you DO specify the Subsampling tag, and the JPEG compressed
> data is indeed subsampled. The combination of this should mean that you
> have the 'wide' view on subsampling, i.e. that it applies to any color
> space with a first brightness channel and two chroma channels (YCbCr,
> CIELab, ICCLab, ITULab).

> I'm not saying either of the above is incorrect, I'm not qualified to
> sort this out. But I am saying this is a problem area in TIFF, and your
> choice is not consistent.

I agree and its for parts a result, when trying to add some general
support for lab/jpeg/tiff files, of dealing with specs, some "state of
art" of libtiff 3.7.3 ( don't know if things have changed ), tifftools
( mainly  tiffcp ), photoshop, and ... my own user's requests.
;-)
For what I remember, ( I have done this job in 06/2005), a problem
for example, rely on default 2,2 subsampling ( when you enter "wide
view" of subsampling).
NB : photoshop handle jpeg/cielab ( with progressive in jpegtiff ?)
and when saving an uncompressed cielab file, do not write a subsampling tag 1,1 ...

It's an example, there's a lot of others, which all rely at some point,
to a very strong binding in "(lib)tiff world" of YCbCr/downsampling/Jpeg,
so a lot of assertions made in calculations of image/tile/strip size,
that have to be "fixed" in some core modules of libtiff.

And I no more qualified than you to affirm what is "correct",
nor say how things should be "fixed".
But, IHMO, as soon as this is not fixed, one can't expect have
a correct processing of lab/jpeg files by the readwrite
scanlines, strips, tiles interface, easy to maintain with a
system libtiff, and thru releases of libtiff.
That's why I said to Wandering of rather consider using libtiff
to manage tags and coded data, and use libjpeg to process
compression/decompression.


> This is a JPEG compressed 16bit YCbCr file. That's no good. JPEG
> compression can be combined only with 8bit and 12bit per channel data. I
> feel the correct decoding response to this is an error message, and
> that's exactly what my decoder is doing.

Note that if you "hard tag" the file to 12 bits data in place of 16,
things come correct, and yatiffcp will decompress a packed 12 bits
samples file ... then recompress it, then you hard tag to 16 bit,
the decompressed .... ;-)))
Shortly, a lot useless manipulation of unusable 12 bits files.
lol

A brief word : all those conversions are handled at a low level,
( some by jpeglib ), with respect of scale or shift depending
of color space. A Tiffcp have not to know about this.

> Funny, though, you seem to have a JpegTables tag in this file, and yet
> have JPEG tables in the single strip JPEG stream. That's OK, of course,
> the latter just override the first, but it's funny nonetheless seeing
> the detailed quality in your other files.

Argh !
Perhaps something to deal with communication tif_jpeg/jpeglib
about 'write tables' in relation with 'optimize' flag ...


[...]

> The colors are off, this is likely not ICCLab at all. Inside the single
> strip JPEG stream, there's an APP1 marker that should not be there, as
> well as a DNL marker. Despite of the DNL marker, the image length seems
> to be properly encoded inside the SOF0 marker.

> Thus, this file much ressembles the fax000... bugzilla attachement that
> we started out with in this lengthy thread. I guess you're probably
> aware of that? Just make sure people don't mistake it for a valid
> testfile.

I do not intend these file to be "valid testfile". I only say that for
people interested by jpegintiff, particularly lab in tiff, they are
well handled by photoshop, structure and colors(1), that they perfectly
match the requests of a "colorblind" jpeg codec without some problems
relying to the signed cielab in jpegfiles.
(1) has long as one agree as you and marti ( and me )  that'all D50,
and the good way for D50 ....

And of course, Fax..., on the directory "Wanderer fax" is the file
submitted by Wandering.
About DNL, while my JpegLib is seriously reworked ( 8/12/16 bits at
runtime, nothing about dnl ), I can link the same libtiff with original V6b,
and I never had to worry about DNLs.
Image height and width ( frames in turn from jpeglib point of view )
are at the end initialized from tiff's header image/strip/tile size,
and dnl ignored by jpeglib.
So if a problems of to few to many scanlines occurs ...,
its libtiff as usual ;-)

--
Jean-Yves



_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
