Am 11.09.2011 13:40, schrieb Warp:
> Ive<ive### [at] lilysoftorg>  wrote:
>> Am 11.09.2011 10:14, schrieb Thomas de Groot:
>
>>>> If you want the color<213, 127, 79>/255 to correspond to the on-screen
>>>> pixel value<213, 127, 79>, you'll have to use an assumed_gamma of 2.2
>>>> (which is the default).
>>>>
>> Nonsense!
>
>    It isn't. This is actually very easy to verify. Just use a very simple
> scene like this:
>
>      global_settings { assumed_gamma 2.2 }
>      background { rgb<213, 127, 79>/255 }
>
>    When I rendered that, the image file ended up full of pixels with the
> value (214, 128, 78) (granted, not *exactly* the original values, but a
> difference of one isn't exactly large, and accounted for by rounding errors).
>
>    In contrast this:
>
>      global_settings { assumed_gamma 1.0 }
>      background { rgb<213, 127, 79>/255 }
>
 > produces an image full of pixels with the value (253, 187, 151).
 >
 >    Gamma correction is a bit wonky like that.
 >

I'm really tired of this. When you wish to feed POV-Ray with sRGB values 
then use srgb <whatever color> no need to *try* it.

>>> Display_Gamma = sRGB
>>> global_settings {assumed_gamma 1.0}
>>>
>> Yes. Thats definitely how it should be when you are aiming for a
>> (photo)realistic render.
>
>    It's just that if you do that, you'll have to pre-gamma-correct all your
> input colors if you are choosing them from an external program. The external
> program will use raw pixel values, and they will have to be pre-gamma-corrected
> with the gamma factor 2.2 if you want them to look the same in povray with an
> assumed gamma of 1.0.
>
You do not have to *pre*-gamma-correct you have to *de*-gamma-correct 
and this is not nitpicking, this is a completely different meaning.

As I've already have stated: when you wish to feed POV-Ray with sRGB 
values then use srgb <whatever color> and POV-Ray will de-gamma-correct 
it for you.
I for one do *never* use (and I do not think) in 8bit gamma-corrected 
values, I'm a human and I do not see any reason to imagine colors in a 
way that was practical for computers in the 90ies of the last century.

And, more important, I like to mix colors (like e.g. rgb Pink*0.9 + 
Skyblue*0.1) and this works only (as I do expect it to work) when colors 
are linear defined otherwise the result of this kind of calculation is 
already mathematical wrong - and looks wrong.
If you do not know what I mean:
0.3 + 0.5 = 0.8
BUT
pow(0.3, 2) + pow(0.5, 2) != pow(0.8, 2)
And (again) the argument that human perception is not linear is 
completely irrelevant because we're talking about a raytracer that tries 
to simulate the real world and light intensities there behave linear.
And I like to use color macros (like e.g. lightsysIV) and they also 
expect *linear* colors (again otherwise already the math would be wrong).
And I own a spectrophotometer for measurement of diffuse reflectance and 
this gives me colors in linear space (actually it gives me a spectrum 
but this does not matter here).
And my Photoshop (CS5) setup is done in a way that it shows rgb values 
in linear space (internal P'shop works in linear space anyway).

But well, maybe I *am* the only one who prefers it this way...


>    Also, linear gradients won't look linear (at least not currently).
> (They are linear in terms of the energy they emit, but not in their
> perceived brightness.) This can be a bit of a problem when designing
> textures which should have a certain *look*, rather than having a certain
> emission function. (The relationship between emitted energy and perceived
> brightness is roughly logarithmic, and the exponent is approximately 2.2,
> which happens to coincide with most displays.)
>
>> Don't do this. Actually this isn't a complicated matter. What makes it
>> appear complicated is the amount of wrong informations and even worse
>> half true statements as sadly frequently given within this newsgroup.
>
>    It *is* a complicated subject, and there indeed is a lot of misinformation
> out there. A common misunderstanding is the relationship between absolute
> brightness (the amount of energy that a pixel with a certain value emits,
> mesured in watts) and the *perceived* brightness (which is what it looks
> like to the human eye). This relationship is far from linear.
>
>    The question is: Do you want "rgb 0.5" to emit half of the energy than
> "rgb 1.0" (in which case you should use assumed_gamma 1.0), or do you want
> "rgb 0.5" to *look* half as bright as "rgb 1.0" (in which case you should
> use assumed_gamma 2.2)?
>
>    You can make "0.5" to look half-gray even with an assumed_gamma of 1.0
> by pre-gamma-correcting it (in which case you would have to use
> pow(0.5, 2.2) = 0.218), and in theory all the surface lighting will be
> more accurate (because they will deal with the absolute light energy,
> rather than perceived brightness), but as said, you will stumble across
> problems when designing textures (eg. because linear gradients won't look
> linear) and other such things related to colors.
>

This is all irrelevant. How something *looks* has to do with the 
lighting condition. Without lights everything *looks* black.
And when you prefer to use POV-Ray as a "painting-tool" where you expect 
50% gray to be half as bright as white feel free to do so, I do this 
also sometimes, with ambient set to 1 and diffuse to 0, BUT THIS IS A 
DIFFERENT MATTER. Yes this has to be shouted.
When you use POV-Ray to simulate real world lighting where (simplified) 
a color is the result of the diffuse reflection of light the whole talk 
about *perceived* brightness simply does not matter.

Finally, it is NOT complicated:
For anything that tries to be photo-realistic use assumed_gamma 1.
Feed POV-Ray with *linear* values or when you prefer to do so use sRGB 
values and define colors with the srgb keyword. Since version 3.7 there 
is no more need to care about image maps, they work like a charm.
Thats all.

-Ive

Post a reply to this message