|
|
> The only thing I know for sure about gamma correction is that whenever
> it makes an appearance, it only causes problems and nothing else.
So let's simplify things for POV4:
Facts:
* A raytracer needs to work internally in linear colour space
* A monitor is a non-linear device (usually requiring a gamma correction of
1.8-2.2)
Assumptions:
* Most outputs from a raytracer will be in monitor colour space, not linear
space
--> raw output from the raytracer needs to be converted from linear space
* Most inputs to a raytracer will be in monitor colour space
--> User input needs to be converted to linear space
Default solution:
* One single system-defined Gamma value (default 2.2 for Windows, editable
by user)
* Gamma applied to all output from raytracer engine
* Inverse-gamma applied to all input to raytracer engine
* For #version <4.0 the old behaviour is set (ie no conversion for input
colours)
Options:
* User can change Gamma value for their system (in .ini file?)
* User can use SDL keywords to set if input values in that file are
specifically in linear space
eg: color rgb <1.0,0.5,0.25> will be the same colour as RGB 255,128,64 when
viewed on your monitor, no matter what gamma setting you have.
linear_color rgb <1.0,0,0> will be twice as bright as linear_rgb <0.5,0,0>.
Can be used when you want a linear mapping for physical reasons (eg one box
twice as bright as the other).
There could also be a linear_image_map keyword to work with texture files in
the same way.
Post a reply to this message
|
|