Xref: utzoo comp.graphics:3914 comp.windows.x:6768
Path: utzoo!utgpu!watmath!onfcanim!dave
From: dave@onfcanim.UUCP (Dave Martindale)
Newsgroups: comp.graphics,comp.windows.x
Subject: Re: Luminance from RGB
Message-ID: <16929@onfcanim.UUCP>
Date: 16 Dec 88 20:34:27 GMT
References: <8241@pasteur.Berkeley.EDU> <518@midgard.Midgard.MN.ORG>
Reply-To: dave@onfcanim.UUCP (Dave Martindale)
Organization: National Film Board / Office national du film, Montreal
Lines: 27

In article <518@midgard.Midgard.MN.ORG> dal@midgard.Midgard.MN.ORG (Dale Schumacher) writes:
>
>The point of my "round-about" method is performance.  It's much easier to
>replicate bits and do shifts than to divide by 7.

But it's faster to *implement* almost any function using table lookup.
Even the naive and inaccurate shift-n-bits is faster when performed using
table lookup than the hardware shift instruction on some hardware.

Once you are using table lookup to do the pixel-by-pixel "computations",
it really doesn't matter how expensive the code that initializes the table
is - you only do it once.  So you might as well use multiply and divide,
and do the calculations in a way that someone else can read, and can see
by inspection is correct.

You can even use non-linear pixel encodings to avoid losing shadow detail
when the output pixel is narrow.  For example, my standard way of storing
12-bit linear data from a scanner into 8 bits is:

	outpix = 255 * ((inpix/4095.0) ** (1/2.2))

using floating point where needed, and rounding the result to an integer.
(The magic number 2.2 happens to be the standard value of "gamma correction"
that the NTSC television standard uses, so this can be sent to a frame
buffer and turned into NTSC without further gamma correction, but the
technique is worthwhile on its own even if the image will never appear
on video.)