Return-Path: <tiff-bounces@lists.maptools.org>
Received: from inas031.isp.belgacom.be (localhost [127.0.0.1])
        by inav010.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-AV-3.00) with ESMTP id l0HIF2jD004734
        for <joris.at.lebbeke@skynet.be>; Wed, 17 Jan 2007 19:15:03 +0100
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from inmx020.isp.belgacom.be (inmx020.isp.belgacom.be [195.238.5.139])
        by inas031.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-AS-2.03) with ESMTP id l0HIEpxX028918
        for <joris.at.lebbeke@skynet.be>; Wed, 17 Jan 2007 19:14:52 +0100
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from duke.maptools.org (r153.dmsolutions.ca [209.217.116.153] (may be forged))
        by inmx020.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-2.32) with ESMTP id l0HIEfKq022401
        for <joris.at.lebbeke@skynet.be>; Wed, 17 Jan 2007 19:14:41 +0100
        (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 l0HI4oWZ010539;
	Wed, 17 Jan 2007 13:05:06 -0500
Received: from outmx025.isp.belgacom.be (outmx025.isp.belgacom.be
	[195.238.4.49])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id l0HI4lfk010536
	for <tiff@lists.maptools.org>; Wed, 17 Jan 2007 13:04:47 -0500
Received: from outmx025.isp.belgacom.be (localhost [127.0.0.1])
	by outmx025.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-OUT-2.22)
	with ESMTP id l0HI2Lqv003717
	for <tiff@lists.maptools.org>; Wed, 17 Jan 2007 19:02:22 +0100
	(envelope-from <joris.at.lebbeke@skynet.be>)
Received: from dfgrrxsknr4e (34.169-64-87.adsl-dyn.isp.belgacom.be
	[87.64.169.34])
	by outmx025.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-OUT-2.22)
	with SMTP id l0HI2IdG003685; Wed, 17 Jan 2007 19:02:18 +0100
	(envelope-from <joris.at.lebbeke@skynet.be>)
Message-ID: <001301c73a61$d4e0ced0$22a94057@dfgrrxsknr4e>
From: "Joris" <joris.at.lebbeke@skynet.be>
To: "Gerben Vos" <Gerben@zylab.com>,
        "TIFF mailing list" <tiff@lists.maptools.org>
References: <200701170225.l0H2PhRY014173@tux.cubewerx.com><Pine.SOC.4.60.0701162049080.13644@blade.simplesystems.org><000701c73a0e$958b8390$70c9f451@dfgrrxsknr4e><AA6DDFA4E046A24585BC828A78155B470146027D@US-MAIL.ingrnet.com><001701c73a4f$e9e40250$22a94057@dfgrrxsknr4e>
	<FC840EC0BF7BFA45A0F94548AF36920D020CA6FA@zynlms01.ZyLAB.WAN>
Subject: Re: [Tiff] Elevation Data
Date: Wed, 17 Jan 2007 19:03:13 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1807
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896
Cc: Craig Bruce <csbruce@cubewerx.com>
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.00001f9b
X-MSP-STORE: Wed, 17 Jan 2007 19:15:11 +0100
Status:   

Gerben,

Gerben Vos wrote:
> It seems to me Craig's data doesn't really have a photometric
> interpretation, since it isn't really an image. So he should just use
> something reasonable (min-is-black I would say), and use SampleFormat
> to indicate what the data really means.

I am confused about this. If we're talking about an ExtraSample, then
clearly there is more freedom, but if the data is encoded in a main
image color channel, covered by any photometric at all, we need to be
consistent with the normal usage and the encoding that applies.
Grayscale data, be it MinOrBlack or MinOrWhite, is grayscale data, and
you may know it's elevation but if you write it as grayscale data, it's
grayscale data. So the needs of renderers, and the encoding of
grayscale, do come into play.

> As for SMin/MaxSampleValue, Joris wrote:
>
> > If the spec were clear and binding on this, maybe things would have
> > been different. But it isn't.
>
> I don't see where the TIFF6 spec says they're just statistical. It
> doesn't specify sanctions for when they're wrong, but the text seems
> quite clear that if the tags are present, they are to contain the
> real bottom and top of the value range. An application rejecting a
> TIFF because it finds a sample value outside the defined range would
> be in its right based on the text.

You're absolutely correct. Ed pointed this out already. I was confusing
my memory of Min/MaxSampleValue tags with SMin/SMaxSampleValue tags. I
stand corrected.

So that leads me to think my proposal for a recommendation as specified
in http://www.asmail.be/msg0055261416.html
a) agrees with the spec
b) agrees with needs like elevation encoding
c) agrees with graphic rendering needs

Would you agree?


Best regards,

Joris Van Damme
info@awaresystems.be
http://www.awaresystems.be/
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html

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