Am 05.03.2012 18:44, schrieb Warp:
> clipka<ano### [at] anonymousorg>  wrote:
>> ... choosing more saturated colors (might be difficult for the yellow
>> ball, but you can probably do something about the marble floor; a good
>> bet might be using "srgb" wherever the material currently uses "rgb";
>> you might need to copy the materials from the default .ini files for this);
>
>    The thing about assumed_gamma 1.0 is that while it may produce more
> physically correct results in terms of lighting calculations, it's
> unintuitive with respect to defining colors.

That's only true if you define colors the old way, using "rgb" rather 
than the new "srgb". With POV-Ray 3.7, it's not a matter of which 
assumed_gamma setting gives you a more intuitive way to specify colors, 
but a matter of choosing between intuitive ("srgb") and physical ("rgb") 
colors.

Fun fact: "srgb" does take into account what assumed_gamma you choose, 
so e.g. "srgb <0.1,0.5,1.0>" gives the same hue regardless of that setting.

> For instance, with that
> assumed_gamma something like "color 0.5" will *not* be 50% gray (instead
> being something like 73% gray IIRC). The reasons for this are complicated.
> (Basically, it's the difference between radiant energy and the brightness
> perceived by the human eye.)

You remember correctly. Though I'd phrase it differently: What is 
/perceived/ as (and frequently labelled) "73% gray" actually corresponds 
to a physical brightness of 50% (=0.5).

>    If you want to, for example, specify 50% gray, you have to indeed use
> the 'srgb' keyword (in other words, define your color as "srgb 0.5").

Which is exactly the reason why the "srgb" keyword was introduced.

>    It becomes a bit more problematic when you are not defining the colors
> yourself, but are using a pre-defined texture (eg. from an include file).
> Now, I don't remember if something was added to POV-Ray 3.7 to "convert"
> such a pre-defined texture into 'srgb' on the fly.

No, indeed not. I guess the proper solution there is to overhaul the 
standard include files to use "srgb" throughout.

>    Another problem is that currently there's no way to define linear
> gradients that would remain linear regardless of assumed_gamma (in other
> words, if you define assumed_gamma 1.0, your gradients will not look
> linear). Some work will be done in the future to remedy these shortcomings.

I strongly disagree with you about the use of the term "linear gradient" 
here. "linear-/looking/" would be a better choice of words, as from a 
/physical/ perspective it's the "assumed_gamma 1.0" gradient that is linear.

It should also be noted that while "assumed_gamma 2.2" does give 
superior-looking /brightness/ gradients, it gives poor results for 
/color/ gradients ("assumed_gamma 1.0" gives very good results there), 
so the issue of gradients does /not/ generally speak in favor of any 
particular "assumed_gamma" setting. Instead, the results simply indicate 
that what we really need is a much smarter handling of gradients.

Post a reply to this message