Grayscale subset of RGB?
Jerry Burnett
the use of a pseudo-grayscale in the definition
of vertices? You can, of course, use 00-ff for
each color (rgb), and get 256 levels of gray,
but it seems there is a way to get many more
levels of gray by slightly varying colors
around each nn:nn:nn value. What I am looking
for is an algorythm that suggests a maximum
level of strict grayscales that can be depicted
with 24-bit rgb (should be thousands), and some
way to order the rgb values by level of
"whiteness". So that, for example, if I
want to specify a gray value, say, 1000 of 8000,
(assuming 8000 is max - solid white), then
I should be able to convert 1000 to rr:gg:bb
that would be seen on the screen as the correct
level of gray.
Maybe I am not explaining this well - I want to
work strictly with grayscale, and I am hoping
to get much higher than 255, and be able to
see it on my monitor.
Help.
Jerry Burnett alc...@neto.com
------------------------------------------------------------------------
Add a Message
Werner Dian
Grey = 0.3*R + 0.59*G + 0.11*B
This is important for choosing the righ error-correction color.
First you have to decide how many values you want to have, the
higher the more values are not grey, but a bit colorfull, coz you mix
a little bit of color into the grey. Lets stick with max=8000.
Now you have to choose the closest real grey to x=1521, (better example)
realgrey = x*255/max = 48.
But we have a rest of luminance to put into the colors:
rest = x - (realgrey*max/255) = 16 (its 16 in the 8000 unit greyscale)
one Red unit is "worth" 0.3*255/max greyscale units = 9.5625 greyscale units
" Green " 0.59 " = 18.80625 "
" Blue " 0.11 " = 3.50625 "
Red+Green = 28. ...
Red+Blue = 13. ...
Green+Blue = 22. ...
Now you choose the combi nearest to rest=16, would be Green unit with 18.8
-> increment green (if you had Red+Blue, you increment both R and B)
So you have: R=48 G=49 B=48
I think it can be made easier, but didnt come into my mind ;)
Werner Dian
its only 32kB memory, and its much faster for big data...
(use RGB + dummy-byte coz of alignment, else its slower)
Phil Frisbie, Jr.
>
> Is there a table or algorythm that allows
> the use of a pseudo-grayscale in the definition
> of vertices? You can, of course, use 00-ff for
> each color (rgb), and get 256 levels of gray,
> but it seems there is a way to get many more
> levels of gray by slightly varying colors
> around each nn:nn:nn value. What I am looking
> for is an algorythm that suggests a maximum
> level of strict grayscales that can be depicted
> with 24-bit rgb (should be thousands),
If you want 'strict' gray colors, then you can only get 256 with 24 bit
RGB. If each R and G and B value are not the same, then it will not be
gray, but have a slight tint to it.
You have two choices that I see.
First, you can get a high end workstation that supports 36 bit
(12,12,12) or 48 bit (16,16,16) color depth. That will get you either
4096 or 65536 gray colors, respectively.
Or second, you can dither those 256 gray colors to emulate more.
Depending on the dithering pattern you use, you can get 4096 or more
gray colors. Of course, that would rule out using a standard OpenGL
driver, and you would need to either write your own software rasterizer,
or modify Mesa to do what you want.
Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com
Stefan Fiedler
Fischer) wrote:
>> each color (rgb), and get 256 levels of gray,
i know what you mean. maybe the follwing information can help you:
when you want to reduce a rgb color to an grayscaled value you must do
this calculation:
float grayscaled=0.3f*color.red+0.59f*color.green+0.11f*color.blue;
ok. maybe you want 4096 colors. create an array that can take
4096 rgb values, each stay for a color thats nearly gray. the field
with the index 0 contain the perfect black, the field 4095 contain the
perfekt white, all others scale between this two values.
the first step is to fill the array with default values for all
colors. this step is just for our security, to be sure that we have no
unknown colors in our table.
---snip---
typedef struct TColor {r,g,b : unsigned short};
table TColor[4096];
void main()
{
// init
for (int i=0; i<4096; i++)
table[i].r=table[i].g=table[i].b=ceil(0.3f*i/16+0.59f*i/16+0.11f*i/16);
}
---snap---
the second step: we say, we allow a maximum difference from an real
gray-value (r=g=b), maybe 1. our gray universe includes now all
r+-1:g+-1:b+-1 colors. that means you have now not only 256 exact
gray-values ... you have 3^3 (3 combinations per color channel, 3
channels (rgb)) for each gray value. that increase you grayspace by
factor 27 (ok, our table only takes 16 combinations from each
gray-value, but thats ok).
write 3 nested loops to calculate for all possible "nearby gray"
rgb-colors the brightness-float with a possible range from 0 to 255,
muliply that by 16, round it down... thats out table-index where we
store our "nearby gray" rgb-color in the array table[0..4095].
ok... that was the whole precalc- offset.
step three: runtime.
you want to get a perfect "nearby gray" rgb-color for an rgb-color? do
that:
--snip--
unsigned int tableindex;
TColor color, graycolor;
tableindex=ceil((0.3f*color.r+0.59f*color.g+0.11f*color.b)*16);
graycolor=table[tableindex];
--snap--
thats not fast... but i think you dont want to write a grayscale based
3d shooter. :)))
i hope i this can help you. excuse my loosy english. :(
fps.
btw: iam loking for a free 3d-designer with a author that gives me the
format description for the scene files (i want to use that for my
opengl "engine")
Stefan Fiedler
tableindex=ceil((0.3f*color.r+0.59f*color.g+0.11f*color.b)*16);
graycolor=table[tableindex];
--snap--
stefan