PDA

View Full Version : Representing a float w/ 3 color channels



maximian
02-11-2005, 12:35 PM
I need to represent a float value, that ranges from some alpha to beta, w/ 4 bytes of precision using opengl coloring, that only allows for 3, 8 bit channel colors. Any ideas,

Naive approach:
I originally though about breaking up [alpha,beta], into 3 segments,delta = (alpha-beta)/3.
(alpha, alpha+delta), (alpha+delta, alpha+2*delta), and finally, (alpha+2*delta, beta).

Then assigning each range a color channel. But there are nasty discontinuities at the breaks. I could overlap ranges, but that would reduce precision.

Any ideas. I am sure someone has encoutered a problem similar to this before.

The hardware I have available is a bit old, so no 128 bit, color support.

mikael_aronsson
02-12-2005, 12:45 AM
If you can live with software rendering you could use Mesa, Mesa supports >8 bit color channels

ZbuffeR
02-12-2005, 04:56 AM
From you post it is not clear whether by "represent" you mean for the human eye (2) or for hardware operations (1).
The latter case should be doable with plain rgba 8 bit opengl.

(1)
The way I would do that :
Lets assume we have an opengl pixel :
--RRGGBBAA--

and an unsigned integer value v, ranging from
0x00000000
0xFFFFFFFF

so whith C simple masking and bit shifting is should not be too hard :
r= (v >> 24) & 0x000000FF;
g= (v >> 16) & 0x000000FF;
b= (v >> 8) & 0x000000FF;
a= (v >> 24) & 0x000000FF;

then use these color values with glColor4ub(r,g,b,a); and read with readpixels and such. You need to request an RGBA framebuffer though.

(2) Color space is inherently 3D, it will be hard to make it look 1D to the eye without discontinuities and without loosing precision.
Have a look at 3D scientific packages, they mainly use the single rainbow color range :
google image cfd 3D (http://images.google.com/images?hl=en&lr=&q=cfd+3d)
That sort of rainbow can done like this :

alpha-------beta
r: 0--1--0
g: 0 0--1--0
b: 0 0--1--0The 0--1 mean interpolate between min and max color value. Maybe the black at both start and end is not a good idea, anyway I hope you get the idea.

maximian
02-15-2005, 12:43 PM
I did not know Mesa could do that. Maybe, as a last resort I might consider it. Performance, however is awful, not that I blame the developer.

As for splitting, that would only work for integer 32 bit. You cannot split a float that way and still retain the meaning of the parameter.

Thanks for your responses.