Le 04.12.2008 17:10, clipka nous fit lire :

> Just wanted to point out that the current approach is too limited in my opinion.
> There should be separate (!) options to gamma-correct (or reverse
> gamma-correction) for...
> 
> - preview output window (to adjust for the PoV-ray user's display of course, if
> necessary)

I'm a strong believer that the combination of graphic cards and display
should provide a gamma of 1.0: linear curve;
CRT with 2.2 imply a correction at the graphic cards of 0.45; from there
  the system then has a 1.0 display subsystem and all should be linear.
Opposite of <1.0, 0.5, 0.0> should be <0.0, 0.5, 1.0>, whatever the
number of bits per channel (I like 8, but you need a CRT; LCD do not
have so much bits for all colour... and they might not be linear)

> 
> - image output file (to adjust for the "end viewers'" displays, or
> post-processing steps that may expect a certain gamma correction)
> 
And for image format which support exposing gamma, another one ?
Picture_gamma & Correction_gamma... well find a pair of better names.

> - image input file, on a per-image(!) basis (to compensate for input files that
> may (or may not!) be gamma-corrected for different viewing conditions)

That's a post load gamma correction (beware, PNG for instance already
have one factor from picture: do you want to be able to ignore it ?)

> 
> - color literals, (a) on a scene-global scale and (b) on a per-color basis
> (maybe using macros; to compensate for colors "picked" in an image processing
> software from gamma-corrected pictures)

Global scene should remains linear.
A function/macro for gamma-correction of a colour might be interesting.
(given the computation, a function might be better, but I'm biaised)

> 
> Also note that *all* these settings shold allow for *arbitrary* corrections, not
> just the choice of either "no gamma correction" or "corrected for a gamma of
> 2.2".

Of course!
And please, by default, have a 1.0 everywhere.

Post a reply to this message