Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-i.b-one.net (mx-i.one.com [91.198.169.56])
	by mail9.b-one.net (Postfix) with ESMTP id 1D601400125
	for <info@awaresystems.be>; Fri, 13 Feb 2009 12:48:44 +0100 (CET)
X-Virus-Scanned: by one.com
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=0 required=6 tests=[none]
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4
Received: from lists.maptools.org (lists.maptools.org [65.39.174.144])
	by mx-i.b-one.net (Postfix) with ESMTP id 772C69025
	for <info@awaresystems.be>; Fri, 13 Feb 2009 12:48:41 +0100 (CET)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id 047A51D19C709;
	Fri, 13 Feb 2009 06:47:16 -0500 (EST)
Received: from csmtp2.b-one.net (csmtp2.b-one.net [195.47.247.206])
	by lists.maptools.org (Postfix) with ESMTP id 098B51D19C70C
	for <tiff@lists.maptools.org>; Fri, 13 Feb 2009 06:21:36 -0500 (EST)
Received: from awarec74cb3e1c (78-21-195-67.access.telenet.be [78.21.195.67])
	by csmtp2.b-one.net (Postfix) with ESMTP id 0DA92160006E1;
	Fri, 13 Feb 2009 12:21:35 +0100 (CET)
Message-ID: <9D795A6977C64C13B27814419E781B10@awarec74cb3e1c>
From: "Joris Van Damme \(AWare Systems\)" <info@awaresystems.be>
To: "Bob Friesenhahn" <bfriesen@simple.dallas.tx.us>
References: <E82C9F92AF7B4B2A9B4B643E2E6E9D12@awarec74cb3e1c>
	<Pine.SOC.4.64.0902121014220.1127@freddy.simplesystems.org>
Date: Fri, 13 Feb 2009 12:21:33 +0100
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Cc: TIFF mailing list <tiff@lists.maptools.org>
Subject: Re: [Tiff] Crosstesting request 12 bits per sample JPEG compression
	in TIFF
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.9
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

Bob,

> Previously the test file in this package was contributed:
>
> ftp://ftp.graphicsmagick.org/pub/outgoing/mandrill-12bit-JPEG-TIFF.zip

That seems to do fine, in my decoder, except for the last IFD in
mandrilrgb_12.tif.

All IFDs in both files except this last IFD in mandrilrgb_12.tif contain
YCbCr data. They do not include an YCbCrSubsampling tag, meaning the
assumption that works most of the time is that the writer probably feels
subsampling should not apply to 12 bit per sample data. I dissagree, but I
do decode fine. In the end, it's the subsampling value auto-correction that
always saves the day, as it turns out the JPEG data in these files actually
do have subsampling [2,2].

It's a mess. The cause of the mess is that the default value of the tag is
not [1,1], which means the absence of the tag means different things
depending on whether you believe subsampling applies, and the latter is open
for discussion. We had a similar situation when combining JPEG compression
with colorspaces like ITULAB.

The best thing a writer can do is avoiding the ambigiouty by always
including the subsampling tag in these cases, using values [1,1] if it feels
subsampling doesn't apply, making all perfectly and unambigiously clear to
anyone.

The best thing a reader can do, is assuming [2,2] if the tag is absent and
we've 8 bit per sample YCbCr, and assuming [1,1] if the tag is absent and
any color space like ITULAB and/or bitdepth like 12 bits per sample is used,
because in those cases the absence of the tag likely means the writer feels
subsampling doesn't apply. I find this is the option that works best, on
most files, but not on all. It would not have worked on these madrill files.
It can and should be improved by adding an auto-correction feature
double-checking these values if compression scheme allows such a
double-check as is the case with compression scheme JPEG (scanning the
compressed data of the first strip/tile to the SOF marker and retrieving the
subsampling values from this marker) and NONE (deriving the subsampling
values from the strip/tile bytecounts). It's this auto-correction that
allows my decoder to render these madrill files that would otherwise be
problematic.

The situation with the last IFD in mandrilrgb_12.tif is different. The
photometric in this case is actually RGB. Subsampling cannot ever apply to
RGB, whatever way you feel about subsampling. So, subsampling values are the
no-subsampling ones [1,1]. There ought to be no need to double-check. Yet,
the JPEG compressed data is subsampled [2,2]. This cannot be interpreted as
even remotely correct, no matter what, and I don't support it.

It's very interesting to view this situation in the current discussion about
error/warning handling/recovery. mandrilrgb_12.tif contains old-style
tile-pyramid storage, meaning the main linked list of IFDs are all the same
image at different resolutions. What should an application do if an image
interpretation or image rendering level 'critical' error occurs when
accessing a particular 'tile pyramid' layer with particular resolution?
Right, it should interpret this as IFD-rendering error, which is different 
from page-rendering error, as its proper attempt at recovery should be 
trying to access and render the IFD representing the next bigger pyramid 
layer, which in this case does actually yield a full recovery and correct 
rendering of the page.


Best regards,

Joris

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