Am 20.12.2010 12:38, schrieb Kenneth:

> I think it's presumptuous to assume that I (and undoubtedly others) who use this
> 2.2 method are simply 'not getting it' or that we're 'abusing' gamma for
> artistic purposes simply out of ignorance (or whatever.) Personally, I give this
> topic *much* thought--always comparing what I see in real-life to what I see (or
> think I should see) on a computer screen and in images that I make. It's an
> on-going process for me--and I'm still open to 'correcting' my behavior...but in
> the final analysis, it's my *eyes* that I trust, not technical jargon or dogma.

A similar on-going process happens on the other side of the fence, btw.

Fact is, the pre-3.6 gamma handling (which was actually a non-handling, 
based on pure naive ignorance of the issue) was physically wrong, with 
no way whatsoever to get it right; "assumed_gamma" was an approach to 
fix that (and its intentions were no more than that; it always was 
intended as a technical tool, not an artistic one).

Fact is also, the 3.6 assumed_gamma mechanism got deprecated not (or at 
least not primarily) because it was wrong (it wasn't; it was incomplete, 
and the implementation was partially inconsistent, but as a concept it 
would have been a step in the right direction) or still allowed for 
"abuse", but due to internal architectural changes - the separation into 
a "front-end" and a "back-end", which is a necessary step towards 
networked rendering (and also greatly helped to implement multithreaded 
rendering). The separation between the two ends was deemed to run right 
through the assumed_gamma mechanism.


Another fact is that 3.7 gamma handling originally started out as indeed 
effectively forcing "assumed_gamma 1.0" on all new scenes, plus a 
differentiating between the File_Gamma and Display_Gamma keywords. That 
was all 3.7 gamma handling originally did.

Since then, shortcomings of this approach have been identified and 
addressed, such as how to deal with gamma pre-corrected input image 
files (which are by far the majority), and how to make life easier for 
people who prefer to enter colors in gamma pre-corrected format because 
it feels more natural.

Other objective or subjective shortcomings have been identified by now 
which will /not/ be addressed in 3.7.0 proper:

- Even with the "gamma" keyword, entering gamma pre-corrected colors is 
more cumbersome than would be appropriate (my personal opinion is that 
they should be just about as easy to enter as linear colors). However, 
they /can/ be entered by now using what I deem a pretty good syntax, so 
it was decided to not do anything about this for 3.7.0 (which we can 
realistically hope to release soon), and postpone the issue to a later 
version.

- Gradients have been on my agenda for quite a while already, but I 
hadn't found the time to investigate; nor was I aware that more 
"natural-feeling" gradients can be achieved using "poly_wave 2.2". While 
being more cumbersome than I'd like, again it /can/ be done, and I still 
have it on my personal agenda for a later version.

- Spotlights are another topic, but with those I presume that the 
tightness parameter provides enough artistic freedom already.

- Likewise, the smoothness of diffuse illumination on curved surfaces 
can be enhanced beyond what's typically realistic simply by using the 
brilliance keyword. In a similar manner, the appearance of highlights 
can be adjusted via the roughness and phong_size parameters.

- Using gamma adjustment to simulate photographic film non-linearity is 
also on my agenda, and for this there is indeed no replacement ATM; but 
this clearly falls into the category of post-processing steps, for which 
POV-Ray currently has a policy of not doing those. (There are currently 
signs that this position may be given up, but in that case there will be 
a mechanism to which gamma tweaking is just one of many uses.)

What I'm saying here is that the advocates of the old pre-3.6 model are 
not forgotten, and some of their points are (and have already been) 
taken quite seriously. The direction will not be to retain assumed_gamma 
though, but rather to complement the new gamma handling model with 
features to easily achieve the effects asked for.


Finally, here is one more fact: For some file formats (like PNG, OpenEXR 
and Radiance HDR), it is to the best of my knowledge /impossible/ to 
achieve a well-defined behaviour regarding gamma that suits both 
technical and artistic use of a single gamma-handling mechanism. Thus we 
/need/ a purely technical gamma handling mechanism if we want to support 
physical realim at all, and where this does not fit the needs of people 
who prefer artistic freedom we need to find other ways to give back that 
freedom.

Post a reply to this message