Xref: utzoo comp.graphics:3876 comp.windows.x:6636
Path: utzoo!attcan!uunet!ncrlnk!ncrcae!hubcap!gatech!cwjcc!hal!nic.MR.NET!shamash!nis!ems!questar!midgard!dal
From: dal@midgard.Midgard.MN.ORG (Dale Schumacher)
Newsgroups: comp.graphics,comp.windows.x
Subject: Re: Luminance from RGB
Summary: Good upward extrapolation
Keywords: Luminence, RGB, Extrapolation
Message-ID: <517@midgard.Midgard.MN.ORG>
Date: 9 Dec 88 17:55:18 GMT
References: <8811042303.AA21505@dawn.steinmetz.GE.COM> <8811070533.AA08904@vector.sun.com> <8811080030.AA14681@EXPO.LCS.MIT.EDU> <76649@sun.uucp> <6698@watcgl.waterloo.edu> <964@bacchus.dec.com> <7162@watcgl.waterloo.edu>
Reply-To: dal@syntel.UUCP (Dale Schumacher)
Organization: The Midgard Realm, St Paul MN
Lines: 44

In article <7162@watcgl.waterloo.edu> srneely@watcgl.waterloo.edu (Shawn Neely) writes:
[...discussion of RGB->Grey conversion and "shifting" to higher precision...]
|
|The interval is consistent with the design of a number of colour spaces,
|and is correct when data is taken to higher significance. The same is
|not true of the wrong (often implicit using bit shifts) use of
|the open interval [0..1).
|
|For example, a one-bit image in the [0..1) model allows only
|the intensity values 0.0 and 0.5, and not "full on".
|
|The required multiplications and divisions for the correct approach
|can often be performed by table lookup.

Over the last couple of weeks I've been working with the PBM code posted to
(i think) comp.source.misc, expanding it to handle 8-bit greyscale and
24-bit color images.  In the process, I've run into some of the problems
being discussed here.  Following are some of my solutions.  I think they
work as well or better than what I've seen posted so far, but if I'm
missing some glaring deficiency, I'd like to have it pointed out to me.

RGB to Greyscale:
  I use the formula GREY = ((76 * R) + (150 * G) + (29 * B)) >> 8;
where R, G and B are 24-bit color components [0..255] and the result
is a greyscale value [0..255] with intermediate values in the formula
not exceeding 16 bits (ie. int).  This gives a good approximation of
the 29.9% red, 58.7% green, 11.4% blue luminence contributions.

Extrapolation to more significance:
  I have only 3-bits per gun (RGB) on the Atari-ST, and want to expand those
color values to their 8-bit equivalents.  As was mentioned, simply doing
a left-shift is not sufficient.  The method I use is to start at the MSB
of the source and destination values, copy bits from the source proceeding
toward the LSB, if you reach the end of the source before filling the
destination, start over at the beginning of the source.  This works for
both imcreasing and decreasing significance (equivalent to right-shift for
decreasing).  Example: 101 --> 10110110, 000->00000000, 111->11111111, etc.
It seems to work for all cases, even wierd things like 7-bits -> 13-bits.

One problem I have yet to solve it analyzing a picture to choose N colors
out of a (larger) palette of M colors that best represent a given image.
For example, I can only use 16-colors out of a palette of 512, so which
are the "best" 16 to use.  I already have color dithering algorithms, but
I need to decide which colors to dither WITH.