Path: utzoo!utgpu!watserv1!watmath!att!emory!wuarchive!uunet!island!hue
From: hue@island.uu.net (Colonel Panic)
Newsgroups: comp.graphics
Subject: Re: RGB to gray
Summary: Know what numbers you're plugging into a formula
Message-ID: <2242@island.uu.net>
Date: 28 Nov 90 23:15:49 GMT
References: <9011200035.AA21751@lilac.berkeley.edu> <406@lysator.liu.se>
Organization: Island Graphics Corp., San Rafael, CA
Lines: 31

In article <406@lysator.liu.se>, zap@lysator.liu.se (Zap Andersson) writes:
> 
>   Gray = 0.39 * Red + 0.50 * Green + 0.11 * Blue...
> 
> ...says the NTSC spec. I _*NEVER*_ got this to look goot, coz to my mind the
> blue turns out WAY to dark. Perhaps my eyes aren't NTSC standard, right? I use
> a beefed 0.30 Red + 0.50 Green + 0.20 Blue coz i like it better...

The reason it didn't look right is because you probably just took your R, G,
and B pixel values and plugged them into the formula.  When you calculate Y,
it's a weighted sum of the intensities of R, G, and B.  However, your pixel
value probably does not represent a linearly encoded intensity, but something
more like intensity^(1/gamma), where gamma is some number usually between
2.2 and 2.7.  So the formula should really be something like:

Y = (.299 R^gamma + .587 G^gamma + .114 B^gamma)^(1/gamma)

Obviously, when your pixel value is linearly encoded intensity, gamma is 1
and it simplifies to the formula everyone uses.  The results you describe
("blue turns out WAY to [sic] dark") are exactly what you get when treat
pixel values as linearly encoded intensity, but in reality they are
exponentially encoded (to the 1/gamma power).

I don't think this is a bad thing, as it allows you to get the most out of
8-bit/component pixel data, but you do need to be aware of what you're doing.

--
Only in Marin:  Sign next to Sony waterproof cordless phone in department
store calls it "Marin Hot Tub model"

Jonathan Hue	Island Graphics Corp.	uunet!island!hue   hue@island.com