Received: from inav035.isp.belgacom.be (localhost.localdomain [127.0.0.1])
	by inav035.isp.belgacom.be (Postfix) with ESMTP id B1AB937B4D
	for <joris.at.lebbeke@skynet.be>; Wed,  6 Dec 2006 03:50:13 +0100 (CET)
Received: from inas016.isp.belgacom.be (inas016.isp.belgacom.be [195.238.4.244])
	by inav035.isp.belgacom.be (Postfix) with ESMTP id A540437B4C
	for <joris.at.lebbeke@skynet.be>; Wed,  6 Dec 2006 03:50:13 +0100 (CET)
Received: from inmx019.isp.belgacom.be (inmx019.isp.belgacom.be [195.238.5.138])
        by inas016.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-AS-2.03) with ESMTP id kB62o5qw016825
        for <joris.at.lebbeke@skynet.be>; Wed, 6 Dec 2006 03:50:05 +0100
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from duke.maptools.org (r153.dmsolutions.ca [209.217.116.153] (may be forged))
        by inmx019.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-2.32) with ESMTP id kB62ntMX031705
        for <joris.at.lebbeke@skynet.be>; Wed, 6 Dec 2006 03:49:56 +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 kB624inj026688;
	Tue, 5 Dec 2006 21:05:29 -0500
Received: from mail03.yourhostingaccount.com (mail03.yourhostingaccount.com
	[65.254.254.71])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id kB6238ZD026678
	for <tiff@lists.maptools.org>; Tue, 5 Dec 2006 21:03:09 -0500
Received: from scan06.yourhostingaccount.com ([10.1.1.236]
	helo=scan06.yourhostingaccount.com)
	by mail03.yourhostingaccount.com with esmtp (Exim)
	id 1Grm7l-0002bv-IX
	for tiff@lists.maptools.org; Tue, 05 Dec 2006 21:03:05 -0500
Received: from authsmtp03.yourhostingaccount.com ([10.1.18.3] ident=exim)
	by scan06.yourhostingaccount.com with spamscanlookuphost (Exim)
	id 1Grm7l-0003ii-Lh
	for tiff@lists.maptools.org; Tue, 05 Dec 2006 21:03:05 -0500
Received: from authsmtp03.yourhostingaccount.com ([10.1.18.3]
	helo=authsmtp03.yourhostingaccount.com)
	by scan06.yourhostingaccount.com with esmtp (Exim)
	id 1Grm7l-0003if-4a
	for tiff@lists.maptools.org; Tue, 05 Dec 2006 21:03:05 -0500
Received: from cust3861.vic01.dataco.com.au ([202.164.193.21] helo=[10.0.0.1])
	by authsmtp03.yourhostingaccount.com with esmtpsa (TLSv1:RC4-MD5:128)
	(Exim) id 1Grm7i-0007JW-5x
	for tiff@lists.maptools.org; Tue, 05 Dec 2006 21:03:02 -0500
Message-ID: <457623C5.90603@argyllcms.com>
Date: Wed, 06 Dec 2006 12:58:29 +1100
From: Graeme Gill <graeme2@argyllcms.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: tiff@lists.maptools.org
Subject: Re: [Tiff] Re: Tiff Digest, Vol 31, Issue 3
References: <200612051704.kB5H4sEL015586@duke.maptools.org>
	<4575F91A.9090504@swiftview.com>
In-Reply-To: <4575F91A.9090504@swiftview.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-EN-UserInfo: 4278ddcaa0afbc5edf619268be555fc4:fcefc52a98eff5eb12ac042c4438d4fd
X-EN-AuthUser: graeme@argyllcms.com
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.4
Precedence: list
Reply-To: graeme@argyllcms.com
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.00001e1f
X-MSP-STORE: Wed, 06 Dec 2006 03:50:13 +0100
Status:   

Glenn Widener wrote:

> We (SwiftView) used to obey the spec regarding a default gamma of 2.2.  But we 
> found no one else that does, so we can't either, and we changed the default to a 
> straight linear device RGB.  "No one else" includes at least.Microsoft Office 
> Document Imaging and Paint Shop Pro 6.

There seems to be lots of confusion involving the words "linear" and "gamma"
in these discussions.
To me, the sections of the spec. that Joris quoted means that grey should
not be gamma encoded (ie. it can't be fed straight into a CRT monochrome
display), but has to be linear light encoded, in contrast to the RGB data
which does have a default gamma of 2.2

You're paragraph above seems very confusing to me. You're saying you
obeyed the spec. default gamma of 2.2, except that from what Joris
quoted, there is no default gamma of 2.2 for grey in the spec.!

Then you say you switched to straight linear, but then you say
you switched to device RGB - which contradict each other.
"straight linear" I interpret to mean "linear light", ie. gamma = 1.
Typical "device RGB" is sRGB like, and is not linear, it has
a gamma somewhere around 2.2, which is what Microsoft Office
etc. use.

Either we're interpreting "straight", "linear" and "gamma" differently,
or perhaps you are confusing the processing applied, with the state
of encoding ?

> Linear means literally read, write and send the values to your display unchanged 
> - "linear device values".  If you don't know what the correction is, or haven't 
> been told, don't do any.

It's very confusing to to talk about processing steps. Processing
steps get inverted when you change the direction you're going,
or change the destination encoding you are transforming to,
while an encoding state is a constant frame of reference, from
which you can figure out what processing steps to use.

So while you might use "linear processing" to transport gamma 2.2
encoded grey value to a device that expect gamma 2.2 encoded
grey values, it doesn't make the the encoding "linear".

> The standard conversion from RGB to gray, documented in the textbooks, is grey 
> level =  .33R+.5G+.17B.  So a unitary conversion back to RGB is fine.  

And of course this equation is acknowledged to be wrong - you can't
combine gamma encoded values like this to give a correct greyscale.
To do it properly, you have to turn the values into linear light
encoding, then weighted sum them, and perhaps re-encode with
gamma again. The NTSC system adopted the above simply for expedience -
it's tricky to decode into linear light and back again using vacuum
tubes - so they compromised on the monochrome reproduction.

If you have a full characterization of your grey space (say an ICC profile
that gives a mapping from device space to CIE values), then you
can use (and may or may not want to use) other than a unitary
conversion to a 3 color space. If the grey process gave (for instance)
a sepia response, then for proofing you may want to reproduce the sepia tones
in RGB. Of course I agree that most of the time something simpler is
expected, so converting to the correct gamma encoding and then duplicating
is channel is the usual process.

Graeme Gill.

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