On Thu, 03 Sep 2009 16:32:40 +0200, Warp <war### [at] tagpovrayorg> wrote:
> However, my point is that there are situations
> where you are not rendering for your display, but for something else
> (for example to match HTML colors, or the colors of an existing image).

Either way, Display_Gamma should always be set to match your display.


>   As it is now, there's no "official" way of making 3.7 to create a PNG
> file which is the same as what 3.6 creates. Even "#version 3.6" won't do
> that (because 3.7 will still write the gamma info to the PNG file, making
> it look different). The only way to achieve that is to "abuse"  
> side-effects of other file formats not having support for gamma
> information.

I would argue that v3.6 did it wrong, and the only way to get that result  
then was to "abuse" the system.

Keep in mind that images without embedded gamma information are generally  
assumed by most applications to be pre-corrected for a gamma of 2.2.


>   I do understand the motivation of making the image always look the
> same regardless of what were the gamma settings of the system where the
> image was rendered and the gamma settings of the system where the image
> is displayed.
>
>   However, there are situations where you precisely *don't want* that.
> You want raw pixel values, and nothing else, as I exemplified above.

In which case the colours must be corrected on input. Rendering in a  
non-linear colour space gives the wrong *colours*, not just the wrong  
brightness.


>> What you seem to want is to use colour values that look a certain way  
>> in a gamma-2.2 environment and have them look the same in the output
>> *and* have the same numerical value in the output as they did on input.
>> To the extent that I understand these things, the correct way is to
>> alter the colour values on input, because POV-Ray expects linear
>> colours on input.
>
>   It might be the "most correct" way, but it might not always be  
> practical.

Currently, no.


>   The basic example is, as said, when trying to render a scene designed
> for POV-Ray 3.6: It's a bit unreasonable to expect you to go and change
> all the colors used in the scene just to match the new approach in 3.7.

Going on the premise that v3.6 did it wrong, I do not find it unreasonable  
to have to "abuse" the system a little to match that behaviour.

In this case, if you want to render in non-linear colour space, you could  
set File_Gamma to 1.0 and output to a gamma-unaware format (or  
strip/replace the gAMA chunk from the PNG file). Optionally, temporarily  
set Display_Gamma to 1.0 to make the preview match what the ultimate  
output will look like.


>   Also, as demonstrated earlier, input images are currently not
> gamma-corrected properly, which makes them look too bright. While this
> problem will surely be fixed at some point, there are also other sources
> of color than just image files. For example one could use a graphical
> color picker to choose colors, and if they are written as-is into a
> POV-Ray 3.7 scene, they will not look the same as in the color picker
> application. It seems that the ideology in POV-Ray 3.7 color handling
> is that the user must always pre-correct all color values by hand, as
> POV-Ray itself offers little help in this. Is this practical?

No. It would certainly be convenient if POV-Ray provided some means of  
having it done in the program itself.


>> This is handled automatically for input images in PNG-format if they
>> have a correctly set gAMA chunk, but other inputs must be corrected
>> "by hand".
>
>   It's absolutely unreasonable for POV-Ray to not to offer any way of
> automatically gamma-correcting input images which do not have gamma
> information in them.

Agreed.



-- 
FE

Post a reply to this message