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 0ECAA400125
	for <info@awaresystems.be>; Fri, 13 Feb 2009 17:12:59 +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 3B2B49025
	for <info@awaresystems.be>; Fri, 13 Feb 2009 17:12:58 +0100 (CET)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id 82AE71D19C779;
	Fri, 13 Feb 2009 11:12:24 -0500 (EST)
Received: from mail.sidefx.com (mail.sidefx.com [38.99.137.163])
	by lists.maptools.org (Postfix) with ESMTP id 5060D1D19C703
	for <tiff@lists.maptools.org>; Fri, 13 Feb 2009 10:57:34 -0500 (EST)
Message-ID: <4995986D.5040802@sidefx.com>
Date: Fri, 13 Feb 2009 10:57:33 -0500
From: Edward Lam <edward@sidefx.com>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: 'Tiff List' <tiff@lists.maptools.org>
References: <20090213151552.1C29F1D1AEEB4@lists.maptools.org>
In-Reply-To: <20090213151552.1C29F1D1AEEB4@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

Personally, instead of an option to suppress certain warnings, I would 
rather see two enums created: one for errors, the other for warnings. 
These enums are then used to index into a string table.

eg.
TIFFWarningExt(tif->tif_clientdata, module,
	    TIFF_WARN_UNKNOWN_FIELD,
	    dp->tdir_tag, dp->tdir_tag);
where TIFF_WARN_UNKNOWN_FIELD indexes into a string table with the 
string literal "Unknown field with tag %d (0x%x) encountered".

There are two advantages to this method:
1. This allows the client to filter out specific errors/warnings without 
resorting to string matching.
2. It allows the possibility for localization of errors/warnings.

Of course, this is not a small effort albeit simple.

-Edward

Philip Watkinson wrote:
> Guys,
> 
> Let me explain my situation. Our company provides automated document factory
> (ADF) solutions to many large financial institutions. For one client, they
> receive logos from their clients in TIFF files. There are thousands of
> files. When they run the application, they see warnings which scares them
> and they shut down thinking there is an error. The common warning is
> "unknown field with tag ... ". If this warning has nothing to do with the
> core functionality of encoding and decoding images, it would be nice to have
> a switch to suppress these types of warnings.
> 
> Regards,
> Philip 
> 
> -----Original Message-----
> From: Joris Van Damme (AWare Systems) [mailto:info@awaresystems.be] 
> Sent: Friday, February 13, 2009 3:21 AM
> To: Bob Friesenhahn; Philip Watkinson
> Cc: Tiff List
> Subject: Re: [Tiff] warning and errors
> 
> Bob,
> 
>> TIFF is a very flexible format.  There are proprietary usages of TIFF 
>> which require special tags in order for the proprietary software to be 
>> able to read the file correctly.  If a program using libtiff opens one 
>> of these files then the result may be gibberish.  However, the user is 
>> likely to see a wrong looking image.
> 
> I humbly dissagree. TIFF only works if you separate the 'nominal' layer from
> the 'proprietary extension' layer. For example, say some app needs to store
> elevation data with a map encoded in normal RGB. What it should do is not
> apply some proprietary photometric RGBE, nor should it revert to a complete
> proprietary set of tags that totally excludes interchange. Instead, it
> should recognise that the 'nominal' and interchangeble way to communicate
> this is a normal TIFF with photometric RGB and four channels, the fourth
> channel being indicated as 'undefined'. Next, it might add an additional
> 'proprietary extension' adding a proprietary tag that fully defines the
> 'undefined' channel in a proprietary way. Unsuspecting software/users
> render/see the nominal RGB image. The specially aware software/user can make
> sense of the extra channel.
> 
> In short, 'extra' stuff should never obscure the 'standard' stuff, but fully
> and only build on from the latter. This way and only this way can an unknown
> tag and unknown channels always be safely ignored, and that is requirement
> for the extensibility of TIFF to actually work.
> 
> 
> Best regards,
> 
> Joris
> 
> _______________________________________________
> Tiff mailing list: Tiff@lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/tiff
> http://www.remotesensing.org/libtiff/

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