I hadn't seen that otherwise-excellent page before, but I agree about the
strange "Remove assumed_gamma" statement. I have two theories about this: 1) The
statement may be outdated, from a time before v3.7x became more 'astute' about
handling legacy scenes. 2) Possibly it's CORRECT (?)-- maybe older v3.6 scenes
ARE just so out-of-whack re: 3.7x that *any* assumed_gamma would be wrong. But
that causes the 'no assumed_gamma' error, so *something's* not correct there.

Mention is made that older scenes will probably require lots of work of various
kinds anyway, to bring them fully up to date. That being the case, it would seem
logical to start with assumed_gamma 1.0 as the first 'fix.'

Something else I noticed...

-----
'Gamma Settings:'
 POV-Ray's gamma handling is governed by the following parameters:

 The 'gamma' scene file keyword applied to color values, which forces POV-Ray to
apply gamma decoding to individual colors.
-----
(No mention is made  of using 3.7x's 'srgb' colors-- as of version
3.7.0.beta.41-- instead of adding the 'gamma' keyword)

And in...

-----
'Getting Individual Colors Right:'
If you frequently pick colors, or feel more at home with defining colors by
pixel values rather than physical brightness levels, you can use the gamma
keyword to have POV-Ray do the computations automatically for you, e.g.:

#local MyColor = color rgb <255,128,0>/255 gamma 2.2;

This syntax also allows for using the sRGB transfer function; as the sRGB color
space has become quite widespread through the influence of the World Wide Web,
where it is the official standard, it is probably an even better bet than a
power-law function with a gamma of 2.2:

#local MyColor = color rgb <255,128,0>/255 gamma srgb;
-----

(These examples likewise don't mention 3.7x 's 'srgb' colors, so should another
example be included? Like so...)

#local MyColor = color srgb <255,128,0>/255 ; // As of version 3.7.0.beta.41

Post a reply to this message