Am 30.01.2016 um 17:42 schrieb Stephen:

>> I tend to render with gamma 2.2, but that is not hard and fast,
>> especially when
>> using brighter lights, and some of the images were colour corrected
>> afterwards
>> anyway. From looking at other conversations here concerning gamma, I
>> get the
>> impression that it is a contentious issue. (And I didn't know that
>> 3.7.1 was in
>> the works - excellent news).
> 
> Yes Clipka and Cousin Ricky have a holy mission. :-)

It's not contentious anymore -- see? Nobody has contradicted my Words of
Holy Wisdom for years :P

> I don't care that much myself. As long as it looks fine. :-)

That might be because you're not a developer having to put up with
people claiming that what you're doing and officially recommending is
wrong ;)

I hope that by now there is some sort of mutual consensus that...

- "assumed_gamma 1.0" is indispensible to get physically correct results
(which in my humble experience makes it easier to design materials and
set up lighting);

- any side effect of "assumed_gamma 1.0" that stands in the artist's way
is not to be seen as a shortcoming of "assumed gamma 1.0", but as a
shortcoming of POV-Ray's feature set in general (*), that just has been
hidden until now because "assumed_gamma 2.2" /happened/ to compensate
for it; and

- any artist is of course free to use their own choice of
"assumed_gamma", at their own risk.


(*) A few such shortcomings that have been identified in the past:

- entering colours from 3rd party tools (the "srgb" keyword has been
taking care of this for a while);

- getting perceptually pleasing brightness gradients (the "blend_mode"
and "blend_gamma" mechanism now provides for this); and

- tonemapping for purely artistic reasons (this hasn't been addressed yet).


Some people had (somewhat correctly) observed that these problems do not
appear with an "assumed_gamma" of their choice, and from there
(incorrectly) jumped to questioning the legitimacy of the "assumed_gamma
1.0" in its entirety. My take on it has been -- and will always be --
different: /Knowing/ for a fact that "assumed_gamma 1.0" is the one and
only right (read: phyiscally realistic) way, I must concldue that
"assumed_gamma 2.2" /cannot/ be the /proper/ solutions to these
problems, and instead just obscures them, and that therefore I need to
find a different solution to these problems.

Obviously, that's a different perspective as that of the artist: The
artist needs to take what's available, and make the best of it to
achieve the desired result. So what's utterly wrong from the perspective
of the software developer may still be sufficiently legitimate for the
artist.

Post a reply to this message