Hopefully this is enough for you to go on (I don't remember the effect itself very well but I can have a look if something is missing).

If you want the full source code, I can e-mail it to you.

Regards.

Eric

EDIT: Just remembered that this actually more than you need ! This piece of code also interpolates between the greyscale version and the colored one according to the alpha value of GL_CONSTANT_COLOR1_NV... Anyway, you should be able to remove the useless part !

Is this some magical gray-scale conversion numbers that some genius devised one day or something?

NitroGL

03-07-2002, 08:13 AM

Originally posted by Nutty:
Where does 0.3, 0.59, and 0.11 come from?

Is this some magical gray-scale conversion numbers that some genius devised one day or something?

Pretty much...

Shag

03-07-2002, 08:17 AM

Yeah - it's magic. I spent the last few weeks devising a method to accurately describe the luminunce value from an RGB input.

OK, I lied. I saw it in a post in here http://www.opengl.org/discussion_boards/ubb/smile.gif

Apparently it's used to convert colour TV signals etc to B&W.

[This message has been edited by Shag (edited 03-07-2002).]

Eric

03-07-2002, 11:51 PM

I don't think you can find a method that would actually prove that these values are correct: they just reflect how each component (R,G,B) is seen in terms of luminance by the human eye.

Basically, green is the brightest, then comes red, and then blue.

I have searched the web for a scientific explanation but I suppose the guy who defined those values did a good old "trial'n'error" experiment !

Regards.

Eric

Relic

03-08-2002, 01:30 AM

Aren't these constants derived from the behaviour of an NTSC (Never The Same Color) scheme. (A happy PAL user http://www.opengl.org/discussion_boards/ubb/wink.gif)

Well, Roy Hall "Illumination And Color In Computer Generated Imagery" names a few other constants too, but in Section 5.2 "NTSC and RGB Video" footnote 15 you'll find
Y = 0.299 * R + 0.587 * G + 0.114 * B.
which is one of the three components YIQ (cite) "used in some broadcast components and recording formats such as Betacam".
For people interested in the two other components they are
I = 0.877 * (R-Y)
Q = 0.493 * (B-Y)

[This message has been edited by Relic (edited 03-08-2002).]

Humus

03-08-2002, 02:57 AM

A sidenote .. you don't need register combiners to do this, the GL_ARB_texture_env_dot3 extension is sufficient and allows it to work on many cards, including the Radeon/GeForce/Kyro series.

Not true, the dot3 extension doesn't allow you to disable the implicit scale and bias of [0,1] to [-1,1].

- Matt

Humus

03-08-2002, 10:06 AM

Heh, reminds me I've done the same mistake once before on this forum proposing the same nonworking solution to the very same problem. http://www.opengl.org/discussion_boards/ubb/smile.gif You can make it work though with the dot3 extension, but you'll burn another texture unit and loose some precision.

Can't wait to get 64bit rendering so we can just store stuff and their real values instead of squeezing it into [0,1].

davepermen

03-08-2002, 11:06 AM

can't wait for floatingpoint textures and pixelshaders.. (even if they would only be 16bit floats.. is there an IEEE standart for 16bit floats around?!)

as far as i can see, no.. only 4 standarts, single (ext single), double (ext double)
double is 64bits and ext-double 80bits as far as i know.. single 32bits, and what about single-ext?40?