Return-Path: <tiff-bounces@remotesensing.org>
Received: from xserve.flids.com (adsl-065-083-169-202.sip.mco.bellsouth.net [65.83.169.202])
        by inmx005.isp.belgacom.be (8.12.11/8.12.11/Skynet-IN-2.32) with ESMTP id j3QHQq6P012190
        for <joris.at.lebbeke@skynet.be>; Tue, 26 Apr 2005 19:26:53 +0200
        (envelope-from <tiff-bounces@remotesensing.org>)
Received: from adsl-065-083-169-202.sip.mco.bellsouth.net (localhost [127.0.0.1])
	by xserve.flids.com (Postfix) with ESMTP
	id 69E5F227C1AA; Tue, 26 Apr 2005 13:26:29 -0400 (EDT)
X-Original-To: tiff@remotesensing.org
Delivered-To: tiff@remotesensing.org
Received: from mail.gmx.net (imap.gmx.net [213.165.64.20])
	by xserve.flids.com (Postfix) with SMTP id D63E1227C19A
	for <tiff@remotesensing.org>; Tue, 26 Apr 2005 13:26:26 -0400 (EDT)
Received: (qmail invoked by alias); 26 Apr 2005 17:26:25 -0000
Received: from p213.54.213.211.tisdip.tiscali.de (EHLO sirius.rasena)
	[213.54.213.211]
	by mail.gmx.net (mp030) with SMTP; 26 Apr 2005 19:26:25 +0200
X-Authenticated: #2969065
Received: by sirius.rasena (Postfix, from userid 500)
	id B2EB412808F; Tue, 26 Apr 2005 19:26:52 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by sirius.rasena (Postfix) with ESMTP id A139912808E;
	Tue, 26 Apr 2005 19:26:52 +0200 (CEST)
Date: Tue, 26 Apr 2005 19:26:52 +0200 (CEST)
From: Kai-Uwe Behrmann <ku.b@gmx.de>
X-X-Sender: kuwe@sirius.rasena
To: Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
Subject: Re: [Tiff] TIFF Technote 3, draft 2
In-Reply-To: <Pine.SOC.4.60.0504261141010.2735@blade.simplesystems.org>
Message-ID: <Pine.LNX.4.61.0504261908130.9046@sirius.rasena>
References: <p05210601be84e3c5e927@153.32.48.223>
	<29bcc0df050415010624d8a2b4@mail.gmail.com>
	<p05210602be85bba58203@[153.32.48.223]>
	<Pine.SOC.4.60.0504151402410.14145@blade.simplesystems.org>
	<p05210603be85c3bd67a1@[153.32.48.223]>
	<Pine.LNX.4.61.0504261808590.9046@sirius.rasena>
	<Pine.SOC.4.60.0504261141010.2735@blade.simplesystems.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Y-GMX-Trusted: 0
Cc: Tiff List <tiff@remotesensing.org>
X-BeenThere: tiff@remotesensing.org
X-Mailman-Version: 2.1.2
Precedence: list
List-Id: TIFF and libtiff discussion  <tiff.remotesensing.org>
List-Unsubscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=unsubscribe>
List-Archive: <http://xserve.flids.com/pipermail/tiff>
List-Post: <mailto:tiff@remotesensing.org>
List-Help: <mailto:tiff-request@remotesensing.org?subject=help>
List-Subscribe: <http://xserve.flids.com/mailman/listinfo/tiff>,
	<mailto:tiff-request@remotesensing.org?subject=subscribe>
Sender: tiff-bounces@remotesensing.org
Errors-To: tiff-bounces@remotesensing.org
X-UIDL: 000000000023ceae.00000150
X-MSP-STORE: Tue, 26 Apr 2005 19:27:09 +0200
Status:   

Am 26.04.05, 11:56 -0500 schrieb Bob Friesenhahn:

> On Tue, 26 Apr 2005, Kai-Uwe Behrmann wrote:
> > > > Is it possible to provide recommendations for this without
> > > > stepping on
> > > > someone's toes?
> > > 
> > > I can provide a recommendation about range for viewing - but that's
> > > about all
> > > it is.
> > > 1.0 should be diffuse white in the scene, specular highlights can go
> > > over --
> > > this matches typical camera behavior and provides a useful image to
> > > preview
> > > using a trivial (1.0 -> 255, 0.0 -> 0) mapping.
> > > 
> > > Converting is another story, and optimal conversions are VERY image
> > > dependent
> > > when dealing with HDR data.
> > 
> > To make floating point a more meaningful format within the tiff spec, it
> > would be nice to shift away from the simple 0.0 -> 1.0 mapping approach
> > to
> > a real world scene reference.
> > 
> > Most floating point data have some kind of reference to what 1.0 means,
> > or
> > simply expect the data representing some physical unit (cd/sqr meter or
> > the like). The stonits tag make sense with unconverted XYZ data, while
> > XYZ
> > data are not covered directly by the current tiff spec. Alternatively the
> > range description, suggestion by Bob, can be extended to add a physical
> > value to the lower and upper 'normal' bounds.
> 
> The physical units often have no relationship to ideal default "viewing"
> parameters for a computer display.  For RGB data it is useful to know a
> recommended "black point" and "white point" for the image.  It is also useful
> to know the normal range of the data.  The image data is scaled for display so
> that values under the black point are "black" and values over the white point
> are "white".  This is of course only a crude approximation but it is better
> than nothing.

The word 'Alternatively' used by mine was somewhat missleading.

I want suggest an additional information, providing a physical unit for 
all those image values. Maybe gradiation information is needed then as 
well if the image is not linear.

Applications, which dont know how to handle physical units in this 
context, can simply ignore and use instead "black point" and "white 
point", which referes to 'image values used as black' and 'image value 
representing diffuse white'.

Thanks for pointing out.

regards
Kai-Uwe Behrmann
                                + development for color management 
                                + imaging / panoramas
                                + email: ku.b@gmx.de
                                + http://www.behrmann.name

_______________________________________________
Tiff mailing list
Tiff@remotesensing.org
http://xserve.flids.com/mailman/listinfo/tiff
