I didn't understand all of that, but I'll try to explain my understanding of 
gamma:

1/ Your monitor & computer do not display linearly scaled brightness values. 
i.e. if you write a value to a pixel on the screen, then double that value, 
it won't get exactly twice as bright. Normally, nobody cares about this, you 
draw a picture using a value of 100, and that looks more or less the same on 
everybody's machines because a value of 100 on their screens looks roughly 
like a value of 100 on your screen.

2/ The first problem comes when you find someone with a computer/monitor 
that makes everything brighter or darker than yours. It's possible to gamma 
correct for the difference, but in general you should make images that will 
look right on most people's PCs (probably windows PCs, probably gamma around 
2.2).

3/ Some image viewing/editing programs do the phenominally irritating thing 
of "correcting" this, meaning that although the file says "100" they'll 
actually draw it as 125 or something, and then you wonder why you have 
uneven colour banding in the dark colours. I'm looking at you, photoshop. If 
you like seeing colours as numbers (and if you're using pov or picking 
colours for websites I think maybe you do), find the option to turn this 
"feature" off in that program. If you want to gamma correct an image there's 
another menu option to do it anyway.

4/ And finally, why is any of this relevant to povray? Well pov has 2 
numbers:
       (i) in the ini file, pov has a setting for your display gamma. This 
is NOT your display gamma! If, like all of us, you want to render pictures 
for everyone to see, you should pick a gamma setting that everyone else 
uses. Apparently (I'm told) this is about 2.2.
       (ii) assumed_gamma 1 tells povray that the colour space for your 
scene has a gamma of 1. THIS IS IMPORTANT! When twice as much light hits 
something, it is twice as bright, because there's twice as much energy.
Povray will always internally compute the same lighting calculations on the 
assumption that you're working in a linear colour space (i.e. when you shine 
2 lights on something, you add them together, pov always does this). Pov 
will then gamma correct the final image from the assumed_gamma space to the 
display_gamma space.


IN CONCLUSION:
You want to tell pov to gamma correct the image for your monitor (or the 
monitor of whoever's looking at it), so you do the following:

assumed_gamma 1 - tells pov to calculate the scene in linear colour 
(scientifically correct)

display_gamma 2.2 - (or whatever your PC/monitor use) tells pov to take the 
scientifically calculated image and adjust it, like a photograph, to fit the 
colour-space of your screen.


I have no idea why pov has 2 numbers, because it only gamma corrects once, 
using the ratio of those numbers.

-- 
Tek
http://evilsuperbrain.com

P.S. sorry for the ranting, but it's taken me 5 years to understand I should 
have always used assumed_gamma 1, so I kinda want to make sure everyone else 
knows that too.
P.P.S. to answer the original question: the colour looks different because 
pov is gamma-correcting, so if you want it to look the same you need to 
reverse gamma-correct the colour before giving it to pov. pow( colour, 2.2 ) 
should do it. Telling pov not to gamma correct will make the colour look 
right, but the lighting will become wrong.
P.P.P.S. if you build a scene without assumed_gamma 1, it will usually look 
fine anyway, so this is all academic. Ah the irony.



"Patrick Elliott" <sha### [at] hotmailcom> wrote in message 
news:MPG.1dded66182699b08989e4d@news.povray.org...
> In article <437420f7$1@news.povray.org>, tek### [at] evilsuperbraincom says...
>> You'll see exactly the same thing if you take a photo of an orange, then
>> load it into your favourite paint program and gamma correct it.
>>
>> Gamma effectively adjusts the brightness of the midtones and leaves 0 and 
>> 1
>> in the same place, so if your orange colour is <1,0.5,0> then with
>> assumed_gamma it will look more like <1,.73,0>, which is
>> <1,pow(0.5,1/2.2),0> because your monitor gamma is probably 2.2ish.
>>
>> If you want to pick a colour in a paint program and have it look the same 
>> in
>> pov then you need to gamma correct it from your monitor's gamma space 
>> (the
>> space you picked it in) into the assumed_gamma space you've told pov to 
>> work
>> in. Usually that means applying pow(<colour>, 2.2) to it.
>>
>> Personally I find it's just easier to always work with assumed_gamma 1
>> turned on, and pick numbers in pov that look right, and forget about 
>> gamma
>> space altogether.
>>
> The assumption, (or at least how I assume its supposed to work), is that
> they set your assumed gamma to what your display actually is, so that if
> someone looks at it on one with a 1.0, it looks the same as on a 2.2, or
> the same on a 2.2 as it did on your 1.0 display, etc. What people are
> screwing up is that they are setting the gamma to something that has
> *nothing* to do with their displays actual gamma, so when they load it
> one something else, it looks wrong. In the case of programs that
> correctly handle the setting in the file, *they* are assuming the 'real'
> gamma is different that your monitor and are dropping or increasing the
> image colors to 'match' what they 'think' your display uses, which is by
> default 1.0, not 2.2. In other words, those programs are doing exactly
> what they are told and compensating for *their* assumed gamma of 1.0, by
> shifting everything to 2.2, when in fact the display is the same one as
> used to produce the image, so 'should' have the same 'real' gamma.
>
> Basically, if you use the damn thing wrong, its your own fault when it
> doesn't work, which is imho a real good reason to leave it at 1.0, then
> let those application, if they are set up correctly, adjust things to the
> gamma or the display, not the other way around. Its like manufacturing
> something that uses AA batteries, then 'suggesting' in the manual that
> they try to cram a 9V battery into it. Of course its going to go wrong.
>
> -- 
> void main () {

>    call functional_code()
>  else
>    call crash_windows();
> }

Post a reply to this message