Xref: utzoo comp.graphics:4029 comp.windows.x:7066
Path: utzoo!attcan!uunet!lll-winken!lll-lcc!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: <7187@venera.isi.edu>
Date: 4 Jan 89 18:22:30 GMT
References: <23105@apple.Apple.COM> <2263@eos.UUCP> <83604@sun.uucp>
Sender: news@venera.isi.edu
Reply-To: raveling@vaxb.isi.edu (Paul Raveling)
Organization: USC-Information Sciences Institute
Lines: 55

In article <83604@sun.uucp> falk@sun.uucp (Ed Falk) writes:
>In article <2263@eos.UUCP>, jbm@eos.UUCP (Jeffrey Mulligan) writes:
>> From article <23105@apple.Apple.COM>, by turk@Apple.COM (Ken "Turk" Turkowski):
>> > Y = (R + 2G + B) / 4
>> Y = 2R + 5G + B

	[The latter should really be Y = (2R + 5G + B) / 8, right?]
>
>Yeesh, you people.  Why do you need to simplify it?  Are you going to be
>doing these calculations by hand?  Get a calculator or something.
>
>If you *must* do it in integer for speed reasons, do it this way:
>
>    out = (77*r + 151*g + 28*b)/256 ;	/* NTSC weights (.3,.59,.11)*/
>
>The results are correct to four decimal places and the divide is replaced
>by a right-shift in a decent compiler and a byte-move in a good compiler.

	... because sometimes speed is lots more important than 4
	significant digits of accuracy, and multiplies are slow.

	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

	For a rough cut at comparing timings, adding up the number
	of clocks for each instruction for each of the 3 cases given
	in the gospel according to Motorola, assuming the work's done
	in registers and the result is stored with a (An)+  reference,
	gives:

			Best Case	Cache Case	Worst Case
			---------	----------	----------
	
	a)		   5		   14		    18
	b)		   6		   20		    25
	c)		  83		   93		    99


	Which makes the accurate variant a whale of a lot slower
	than the others.  This sort of thing gets fairly noticable
	if you're massaging a megapixel image.

	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.


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