Xref: utzoo comp.graphics:4036 comp.windows.x:7079
Path: utzoo!utgpu!watmath!watcgl!ksbooth
From: ksbooth@watcgl.waterloo.edu (Kelly Booth)
Newsgroups: comp.graphics,comp.windows.x
Subject: Re: Luminance from RGB
Message-ID: <7559@watcgl.waterloo.edu>
Date: 5 Jan 89 15:50:26 GMT
References: <23105@apple.Apple.COM> <2263@eos.UUCP> <83604@sun.uucp> <7187@venera.isi.edu>
Reply-To: ksbooth@watcgl.waterloo.edu (Kelly Booth)
Organization: U. of Waterloo, Ontario
Lines: 24

In article <7187@venera.isi.edu> raveling@vaxb.isi.edu (Paul Raveling) writes:
>	... because sometimes speed is lots more important than 4
>	significant digits of accuracy, and multiplies are slow.

. . . (stuff deleted) . . .

>	BTW, this is an example of a function that couldn't easily
>	be accelerated by table lookup unless R, G, and B have very
>	few bits.  Even then 3D subscript computation puts the table
>	lookup in the same speed range as the faster 2 of these
>	alternatives.

Huh?  Table look up can be used to replace each of the three multiplies
in aR+bG+cB so that the code becomes something like

	a[R]+b[G]+c[B]

if R-G-B are bytes (the usual case and what most of the previous postings
have assumed -- for up to 12 bits table look up is still reasonable).  This
leaves just the adds and the divide (not shown at the end), which for the
posting that suggest this was still a factor of two (in fact 256) so the
byte swap/move or shift tricks all still work.  There is no need to tabulate
the entire function.  [See previous postings on table look up in this
news group about 1-2 weeks ago.]