Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-m.b-one.net (mx-m.one.com [91.198.169.60])
	by mail9.b-one.net (Postfix) with ESMTP id D12DA400125
	for <info@awaresystems.be>; Fri, 13 Feb 2009 09:46: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-m.b-one.net (Postfix) with ESMTP id 30BDF189FE08
	for <info@awaresystems.be>; Fri, 13 Feb 2009 09:46:37 +0100 (CET)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id 52FCC1D9A6800;
	Fri, 13 Feb 2009 03:46:07 -0500 (EST)
Received: from csmtp3.b-one.net (csmtp3.one.com [195.47.247.213])
	by lists.maptools.org (Postfix) with ESMTP id 3657E1D202AA7
	for <tiff@lists.maptools.org>; Fri, 13 Feb 2009 03:35:02 -0500 (EST)
Received: from awarec74cb3e1c (78-21-195-67.access.telenet.be [78.21.195.67])
	by csmtp3.b-one.net (Postfix) with ESMTP id EF758240D29C;
	Fri, 13 Feb 2009 09:35:01 +0100 (CET)
Message-ID: <6525B1FB1C884C6AAC34176ECDFCB958@awarec74cb3e1c>
From: "Joris Van Damme \(AWare Systems\)" <info@awaresystems.be>
To: <pwatkins@crawfordtech.com>,
	"'Frank Warmerdam'" <warmerdam@pobox.com>
References: <20090212230702.1D9AA1D202630@lists.maptools.org>
Date: Fri, 13 Feb 2009 09:34:22 +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@lists.maptools.org
Subject: Re: [Tiff] warning and errors
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

Philip,

> We want to use Libtiff in a production evironment. We don't want
> warnings/error messages unless there is a critical error (the image is
> corrupt).

What means 'critical'?

In my own proprietary codec, I separate error logic that applies to the 
system level, the IFD level, any particular tag, the image interpretation, 
and the image rendering. For example, corrupt JPEG data in one tile/strip, 
is not even visible on the IFD level, applications can still 
link/unlink/browse through the IFD list. It doesn't apply to the tag level 
either, and the image interpretation is still possible. However, it does 
'critically' impact part of the image, and in my codec it translates to that 
part being rendered in a consistent 'error color'. A totally different 
situation arises when an IFD has an EXIF tag whose value points beyond EOF. 
IFD reading and handling of the IFD that contains the EXIF tag is fine, so 
is image interpretation and image rendering. Tag reading on the EXIF tag is 
what logically contains the error. A totally different situation arises when 
the system is short of memory at some point.

I've found that the only way to always fully 'contain' the error and recover 
on the correct level, fully exposing all possible functionality that is not 
impacted, is a bit of a brainteaser and can only safely be provided by a 
TIFF codec that separates all different structures involved and consistently 
links errors to the exact structure they apply to. In LibTiff, you've no 
such functionality and you must choose to either minimize recovery, doing 
things like immediatelly backing out of the complete file whenever anything 
goes wrong, or minimize safety, doing things like continuing processing on 
other IFDs when the error returned might actually indicate system-wide 
failure like memory shortage.


Best regards,

Joris

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