Return-Path: <tiff-bounces@lists.maptools.org>
Received: from inas006.isp.belgacom.be (localhost [127.0.0.1])
        by inav005.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-AV-3.00) with ESMTP id k8Q6vhnK027408
        for <joris.at.lebbeke@skynet.be>; Tue, 26 Sep 2006 08:57:43 +0200
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from inmx009.isp.belgacom.be (inmx009.isp.belgacom.be [195.238.5.146])
        by inas006.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-AS-2.03) with ESMTP id k8Q6vXTp028380
        for <joris.at.lebbeke@skynet.be>; Tue, 26 Sep 2006 08:57:36 +0200
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from duke.maptools.org (r153.dmsolutions.ca [209.217.116.153] (may be forged))
        by inmx009.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-2.32) with ESMTP id k8Q6vUVv008975
        for <joris.at.lebbeke@skynet.be>; Tue, 26 Sep 2006 08:57:30 +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 k8Q6mgn0017068;
	Tue, 26 Sep 2006 02:49:00 -0400
Received: from mithrandir.paypc.com (mithrandir.paypc.com [66.186.24.2])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id k8Q6mesd017065
	for <tiff@lists.maptools.org>; Tue, 26 Sep 2006 02:48:40 -0400
Received: from mithrandir.paypc.com (IDENT:60@localhost [127.0.0.1])
	by localhost (8.13.7/8.13.2) with ESMTP id k8Q6mcNn021875
	for <tiff@lists.maptools.org>; Mon, 25 Sep 2006 23:48:38 -0700
DomainKey-Signature: a=rsa-sha1; s=mithrandir; d=paypc.com; c=nofws; q=dns;
	h=received:message-id:date:from:to:subject:references:
	in-reply-to:mime-version:content-type:
	content-transfer-encoding:user-agent;
	b=MHAzZxO2zgq+BOZ8SggKc83Wd6Ks+427uUMoaVUC82i5BoUhJYcl964w7pe59csYx
	WHOwEclLSrNWKa3YbtHFQ==
Received: (from www@localhost)
	by mithrandir.paypc.com (8.13.7/8.13.2/Submit) id k8Q6mcFF021874
	for tiff@lists.maptools.org; Mon, 25 Sep 2006 23:48:38 -0700
Message-ID: <1159253318.4518cd4660fb1@www.paypc.com>
Date: Mon, 25 Sep 2006 23:48:38 -0700
From: A Wandering LibTIFF User <tifflist@r.paypc.com>
To: LibTIFF Mailing List <tiff@lists.maptools.org>
Subject: Re: [Tiff] Status of ISO JBIG and CIELAB JPEG support
References: <1158887258.4513375a610fc@www.paypc.com>
	<001101c6de38$45955ff0$86aff651@dfgrrxsknr4e>
In-Reply-To: <001101c6de38$45955ff0$86aff651@dfgrrxsknr4e>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.x-RMSv9
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.4
Precedence: list
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.00001b00
X-MSP-STORE: Tue, 26 Sep 2006 08:57:44 +0200
Status:   


> I'll state the obvious that nobody seems to notice, first. The LibJpeg
> library includes a definition for any 'unknown' color space. 

You're right, I didn't notice this.

> Only to next find that a prior convertion from A to B, to
> next convert from B to C to suit your purposes, accumulates convertion
> errors, where a direct convertion from A to C would do a lot better?

No, I understand.

> When adding support for ITULAB to 10 of these 27 codecs, are you
> planning to do 10 separate difficult jobs? Only to next find it hard to
> maintain as these 10 are modifications to open source libraries and
> you'll need to merge your changes and the public changes time and time
> again?

I should ask Lee what his intentions were with these patches to
libjpeg/libtiff.  It sounds like building colour conversion code into his
end-client (Hylafax) was the correct place to make changes, and to make only
minimal changes to the lib[jpeg|tiff] to ensure they didn't reject the
datastreams.

> It seems clear that color convertion isn't really correctly placed
> inside a codec. Instead of having 27 such color convertion modules,
> codecs should normally be made to return exactly what is there, and any
> convertion should be managed by the image processing layer.

I have no argument with any of this.  Typically the application author "knows"
the end destination and what colourspace he wants to end up with, and so
having a library do as little "processing" outside of the formats it's
designed to support is a prudent one.  I've seen numerous examples of
well-intentioned mistakes that the driver authors make when trying to be
"helpful".

> I've some, or at the very least I had some... I'll try and find them and
> get back to you later today.

I would love to get them, still.  Thanks!

> It is dangerous trying to build support for something based on bugzilla
> attachment, as many a bugzilla attachment is totally bazurk. Here's a
> tagdump.

Yeah, I know it was very much a risky concept...  on many levels.

> LibJpeg doesn't support the DNL scheme, and it's not valid inside JPEG
> compressed data inside TIFF anyway. What Howard did at the time, was
> 'patch up' the SOF marker to include the proper image length. Strictly
> speaking, this is now a totally invalid JPEG stream. But most
> implementations, LibJpeg included, can interpret the stream just fine
> and simply ignore the bazurk DNL marker.

Gack.  OK.

> This confirms my memory that Howard patched up the Y member of the SOF
> marker. It also indicates that subsampling is indeed used, and the
> subsampling values in the IFD are correct.

What a mess.  In my naivete, I'd thought that JPEG handled "true colour" data
as tri-planar data, but I suppose the temptations to use subsampling for the
colour component was too irresistable.

> I'm unable to answer these questions, best I can do is provide
> theoretical background and file analysis. I will also try and find the
> ITULAB JPEG images that at least at one time were part of my testimage
> library.

I would appreciate links to what are hopefully "reference" images that reflect
the correct output according to spec.

> I hope was somewhat helpful though. Perhaps someone else will jump in to
> answer your bottom-line questions.

Your answer was much more than I'd hoped, actually, and I appreciate its
thoroughness and attention to technical details.

Thanks again, Joris.  Your reply was useful, interesting, and provided the
detailed background which resolved my questions about the matter.

=R=

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