Am 27.06.2010 08:59, schrieb Gyscos:

> On 3.6, I would get the result I was looking for. In 3.7, with the now-real
> gamma computation, the light rays are too bright. So I tried to set a lower
> color for the media (0.01 instead of 0.1), but I can't get as much contrast as I
> did in 3.6...
> The workaround I use is to use type 3 instead of type 2, wich is more directive,
> and then gives more contrast...

Yes, having had a look at the scene I guess that's the way to go indeed. 
(Apparently, type 2 was the wrong model for your purposes.)

> When're you're talking about the computed file, is it the colors of the pixels
> stored ? Or after the gamma correction ?

Neither. I mean the brightness levels computed; the "idea" of the image, 
rather than its actual binary representation.

When an output file is actually written, there is a mapping applied from 
the (simulated) physical brightness levels to the binary representation 
values. With most file types, this mapping includes some gamma-encoding, 
and in POV-Ray is governed by the FILE_GAMMA parameter.

Likewise, when a file is read and displayed by a viewing software, there 
is a mapping applied from the binary representation values back to 
(real) physical brightness levels, via the viewing software, operating 
system API, graphics drivers, graphics card, display controller, and 
(typically) LCD panel. With most file types, this mapping is fixed and 
out of POV-Ray's control.

Last not least, when POV-Ray outputs to the preview window, there is a 
mapping applied directly from the /simulated/ physical brightness levels 
to /real/ physical brightness levels, via the OS API, graphics drivers, 
graphics card, display controller, and (typically) LCD panel. This 
mapping, in all cases, is governed by the DISPLAY_GAMMA parameter.


> Cause if the gamma correction is set to linear, then a linear preview in POV-Ray
> wouldn't be wrong, would it ?...

I think you're approaching the problem wrong, and it's difficult (though 
not impossible) to argue against it, so I prefer to try and lead you to 
the conclusion via a different path. Forget for a moment how you /think/ 
FILE_GAMMA and DISPLAY_GAMMA are related - because as a matter of fact 
they're not: They're serving independent purposes.

Let's have a look at DISPLAY_GAMMA:

This is the parameter that controls how /simulated/ physical brightness 
levels (as computed by the POV-Ray rendering engine) are mapped to 
/real/ physical brightness levels emitted by your display.

I think it should be obvious that you want a direct 1:1 mapping between 
these two: You want your display to show what POV-Ray calculated.

However, the pipeline from the operating system to the emitted light has 
some non-linearities in it: Rather than a 1:1 mapping, it is 
approximately a f(x)=x^GAMMA mapping, with some system-specific fixed 
value for GAMMA; so in order to achieve the net 1:1 mapping, POV-Ray 
must compensate for that before handing the data over to the OS, by 
applying another g(x)=x^(1/GAMMA) mapping.

Evidently, in order to do so, POV-Ray needs to know the value of GAMMA, 
which is exactly what you specify with DISPLAY_GAMMA. If you get this 
wrong, you'll retain non-linearities in the mapping between simulated 
and real light intensities, and the preview will /not/ show what was 
computed.

Post a reply to this message