I'm pretty sure that I am not, and will not be, the only one who gets
confused about the new (I suppose better) approach at gamma correction in
POV-Ray 3.7, which differs from the way 3.6 did it, and which results in
images looking different, and different approaches having to be used.
This will create a lot of questions related to this subject, repeated
over and over, especially when the final 3.7 is published.

  Thus I think it would be a great idea if we created a concise, clear and
easy-to-understand section to be included in the official documentation so
that we can simply direct people to it rather than having to explain things
over and over again. I was hoping we could come up with something in this
thread.

  Preferably this tutorial would be somewhere in the documentation that makes
it prominent and visible, rather then buried under hundreds of similar
subsections.

  My ideas about what this section should have:

  1) A simple and clear explanation behind the reasoning and motivation behind
the new gamma correction approach, why it makes sense and why it's better
than what POV-Ray 3.6 did.

  Also: Why POV-Ray 3.7 will render scenes differently than 3.6, when using
default settings and "#version 3.6" is not used.

  2) Why "Display_Gamma" and "File_Gamma" should always have the correct
values for the user's system (ie. usually 2.2, or in some Macs 1.8) and
why they shouldn't be abused for visual effects (because that's not their
purpose).

  3) The difference between PNG and other output image file formats in this
regard.

  4) How to render an old 3.6 scene using POV-Ray 3.7 so that it will look
the same (basically, by adding "#version 3.6" to the scene file; I also hope
that the small problem of the gamma metadata being written to the PNG file
regardless of that #version directive being used gets fixed, for full
backwards "emulation").

  5) How to pre-gamma-correct input images (if and when this feature is
implemented in POV-Ray 3.7) and why this has to be done (and why it doesn't
need to be done for input PNG images which already have a proper gamma
metadata in them). Likewise, how to pre-gamma-correct color values from
other programs (such as color pickers).

  Might not be the proper place for this, but perhaps also:

  6) If the user needs to do it, how to create an image which has no gamma
correction at all, only non-corrected raw pixels. The example of rendering
an image to be used for creating a heightfield could be mentioned.

-- 
                                                          - Warp

Post a reply to this message

On 6 Sep 2009 08:02:40 -0400, Warp <war### [at] tagpovrayorg> wrote:

>  I'm pretty sure that I am not, and will not be, the only one who gets
>confused about the new (I suppose better) approach at gamma correction in
>POV-Ray 3.7

You're not the only one and I think that it is a good idea.
Onwards and upwards. :)
-- 

Regards
     Stephen

Post a reply to this message

Absolutely correct! Imo, this should be placed in the section "Getting 
started" of the "Introduction to POV-Ray"

Thomas

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message 
news:4aa3a4e0@news.povray.org...
>  Thus I think it would be a great idea if we created a concise, clear and
> easy-to-understand section to be included in the official documentation so
> that we can simply direct people to it rather than having to explain 
> things
> over and over again.

Agreed! If you'll gather the information and get it all polished up, then 
post your final on a talk page (on the Wiki) where it should be included, 
I'll make sure it get's in the next gen documentation!

Jim

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Likewise, how to pre-gamma-correct color values from
> other programs (such as color pickers).

  About that... I wonder if POV-Ray should offer some kind of function to
do that, for convenience. In the same way as eg. degrees() and radians()
exist for convenience, even though they don't really save a whole lot of
work compared to if they didn't exist.

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
>> Likewise, how to pre-gamma-correct color values from
>> other programs (such as color pickers).
> 
>   About that... I wonder if POV-Ray should offer some kind of function to
> do that, for convenience. In the same way as eg. degrees() and radians()
> exist for convenience, even though they don't really save a whole lot of
> work compared to if they didn't exist.

I think that definitely yes, POV-Ray should have such a feature. It is 
perfectly possible to roll your own macro to do that, but if POV-Ray is 
going the full way for proper gamma handling, it should - I'd even say 
/must/ - provide some standard procedure to do it, if only to make a 
clear statement along the lines of "yes, /this/ is the right way to deal 
with it". And I'd go as far as to say that it should work without having 
to include a particular file, so it should be a built-in language 
contruct, not just a macro.

Post a reply to this message

"clipka" <ano### [at] anonymousorg> schreef in bericht 
news:4aa43552$1@news.povray.org...
>
> I think that definitely yes, POV-Ray should have such a feature. It is 
> perfectly possible to roll your own macro to do that, but if POV-Ray is 
> going the full way for proper gamma handling, it should - I'd even say 
> /must/ - provide some standard procedure to do it, if only to make a clear 
> statement along the lines of "yes, /this/ is the right way to deal with 
> it". And I'd go as far as to say that it should work without having to 
> include a particular file, so it should be a built-in language contruct, 
> not just a macro.

Sven Littkovski's neat little "POV-Ray Color Picker" (2006; version 2.0) is 
a good example of such a picker. I use it quite a lot and I recommend it 
warmly. Built into POV-Ray would be a nice addition.

Thomas

Post a reply to this message

Thomas de Groot schrieb:
>> And I'd go as far as to say that it should work without having to 
>> include a particular file, so it should be a built-in language contruct, 
>> not just a macro.
> 
> Sven Littkovski's neat little "POV-Ray Color Picker" (2006; version 2.0) is 
> a good example of such a picker. I use it quite a lot and I recommend it 
> warmly. Built into POV-Ray would be a nice addition.

Well, I wasn't thinking about a built-in color picker, but a built-in 
language syntax for gamma conversion.

Of course having its own built-in color picker would be a neat feature 
(and I do second this idea), but for instance on Unix systems, where 
POV-Ray does not come with an "IDE", a feature built into the SDL to 
perform gamma conversion math would still be required.

Post a reply to this message

Thomas de Groot wrote:
> Sven Littkovski's neat little "POV-Ray Color Picker" (2006; version 2.0) is 
> a good example of such a picker. I use it quite a lot and I recommend it 
> warmly. Built into POV-Ray would be a nice addition.
> 

Are you aware that this tool (like most others) will not apply the 
required inverse gamma correction and will result in the usual washed 
out colors similar to jpeg image maps when used with 3.7 or 
assumed_gamma 1.0 ?
And to mention it again: wrong gamma correction does not only give wrong 
brightness intensities, it changes also the hue.

-Ive

Post a reply to this message

"Ive" <"ive### [at] lilysoftorg"> schreef in bericht 
news:4aa4f79e@news.povray.org...
> Thomas de Groot wrote:
>> Sven Littkovski's neat little "POV-Ray Color Picker" (2006; version 2.0) 
>> is a good example of such a picker. I use it quite a lot and I recommend 
>> it warmly. Built into POV-Ray would be a nice addition.
>>
>
> Are you aware that this tool (like most others) will not apply the 
> required inverse gamma correction and will result in the usual washed out 
> colors similar to jpeg image maps when used with 3.7 or assumed_gamma 1.0 
> ?
> And to mention it again: wrong gamma correction does not only give wrong 
> brightness intensities, it changes also the hue.
>

Ah... yes...? I had not really/consciously thought of that... This means 
that picking a color from a RGB/HSL color chart in any paint application 
will show this problem?

Thomas

Post a reply to this message