Fredrik Eriksson <fe79}--at--{yahoo}--dot--{com> wrote:
> When you specify a Display_Gamma that does not match the actual gamma  
> response of your monitor, you are effectively lying to POV-Ray.  
> Consequently, POV-Ray shows a preview with incorrect brightness.

  I do understand that. 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).

  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.

> When you specify a File_Gamma, you are telling POV-Ray to apply that gamma  
> curve to the image data it produces on file. When you output to a  
> gamma-aware format like PNG the gamma value is recorded in the file so  
> other programs will know what gamma curve to apply in order to make the  
> image look right on a given display. Many modern image viewers perform  
> this gamma correction. When you output to a gamma-unaware format like TGA  
> there is no way to record the gamma value in the file. It is therefore up  
> to the user to remember the gamma value and apply gamma correction as  
> necessary. If you do not want to have to perform this gamma correction  
> yourself, you should use a File_Gamma that matches the gamma of the  
> intended output display.

  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.

  Also it could be advantageous if POV-Ray 3.7 could be used to render
POV-Ray 3.6 scenes to get the same result. Currently "#version 3.6"
almost does that, but not quite (not when outputting to PNG).

> 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.

  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.

  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?

> 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.

-- 
                                                          - Warp

Post a reply to this message