AFAIK: There are two parts: the assumed_gamma and the display_gamma.
Assumed_gamma is used internally during the raytracing, which is the reason
why it should be set to 1.0: so that the internal calculations are done in
the correct, linear colorspace.
Display_gamma is applied *after* the raytracing, and is meant to ensure that
when *rendering* the image on different PCs with different gamma, the output
*looks* the same.

To get no gamma-correction whatsoever, use the same assumed_gamma as
display_gamma.

Curiously, I checked what happens with PNG, as they have
"inbuilt"-gamma-values. When using assumed_gamma of 1 and display_gamma of
2.2, the image looks the same *for most parts*, but some darker areas get
color-banding. If I use assumed_gamma=display_gamma=2.2, the input-image
looks like the output image. I assume that's due to the internal PNG-gamma
correction and the usual floating-point accuracy (which I often would rather
call "floating-point inaccuracy" ;-P).

Now, as for making use of image-maps in assumed_gamma=1 and
display_gamma=2.2 scenes, I'm wondering if it shouldn't be possible somehow
to use functions to add an inverse gamma-correction to the image-map, so
that even though POV-Ray gamma-corrects, the image-maps will look the same.
I would have use for this for my next short, so maybe I'll have to tackle
that problem some time in the future. Again, this would only take care to
look proper on a certain system with specified gamma, but then again,
everyone is working with *his* system as reference and just wants it to look
the same on other's systems.

Anyways, I'm not 100% sure if I'm correct or make sense, so if any of the
more insightful people wants to correct me, I'm all ears. :-)

Regards,
Tim

-- 
aka "Tim Nikias v2.0"
Homepage: <http://www.nolights.de>

Post a reply to this message