Xref: utzoo comp.graphics:4060 comp.windows.x:7125
Path: utzoo!utgpu!attcan!uunet!lll-winken!ames!elroy!orion.cf.uci.edu!paris.ics.uci.edu!venera.isi.edu!raveling
From: raveling@vaxb.isi.edu (Paul Raveling)
Newsgroups: comp.graphics,comp.windows.x
Subject: Re: Luminance from RGB
Message-ID: <7201@venera.isi.edu>
Date: 6 Jan 89 16:54:30 GMT
References: <23105@apple.Apple.COM> <2263@eos.UUCP> <83604@sun.uucp> <7187@venera.isi.edu>
Sender: news@venera.isi.edu
Reply-To: raveling@vaxb.isi.edu (Paul Raveling)
Organization: USC-Information Sciences Institute
Lines: 33

In article <7187@venera.isi.edu> raveling@vaxb.isi.edu (Paul Raveling) writes:
>
>	Consider a 68020 running code for these operations:
>
>	a)	Y = (R + G+G + B) >> 2
>	b)	Y = (R+R + G<<2+G + B) >> 3
>	c)	Y = (77*r + 151*g + 28*b) >> 8
>
>	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.


	It's time to eat some of my own words...  I admit to taking
	my brain out of gear too soon on this one.
	
	As Bob Webber pointed out in an email message, a good candidate
	for the best approach of all is likely to be:

	d)	Y = (times77[R] + times151[G] + times28[B]) >> 8


	If R, G, and B are 8 bits this only requires 768 bytes of
	table space and it should be about as fast as alternative b.
	This is easily worth it for having both good speed and good
	accuracy.


---------------------
Paul Raveling
Raveling@vaxb.isi.edu