Warp schrieb:

>>   1) What exactly is the purpose of File_Gamma, given that it makes no
>> difference (when creating a PNG file)?

Specifying the encoding gamma for file formats that leave this up to the 
creator of the file; pixel values will be transformed by 
f(x)=x^encoding_gamma before writing to the file, where encoding_gamma = 
1/File_Gamma. The decoding software is expected to invert this 
transformation as appropriate and then apply display gamma correction 
itself. As AFAIK support for the gAMA chunk is not mandatory, some 
decoding software may however interpret this encoding gamma as a display 
gamma pre-correction

For file formats with no explicit gamma handling, this corresponds to 
the gamma pre-correction, which should be f(x)=x^(1/target_gamma), where 
target_gamma is the total gamma of the target system (often equal to its 
display hardware gamma), so File_Gamma should be set to target_gamma in 
this case.


2) Where is POV-Ray conjuring a gamma setting of 2.2 even though neither
>> Display_Gamma nor File_Gamma were even close to that value?

It is not POV-Ray that is conjuring up this gamma, but the viewing 
software: It is the presumed display hardware gamma, which it will 
compensate for.


>>   3) Why do Display_Gamma and File_Gamma produce different results even
>> if they are set to be the same (when creating a PNG file)?

Because they are meant for slightly different purposes.


>>   4) Why does POV-Ray produce different results depending on the output
>> image format? For example, rendering to a TGA file results in a different
>> result than rendering to a PNG file when File_Gamma = 1.0 (the pixels are
>> the same, but the gamma metadata makes the PNG different from the TGA).

Because the TGA file format is not gamma-aware, and therefore must be 
created with a gamma pre-correction to match whatever target system it 
is to be displayed on. Getting this wrong will result in different output.


>>   5) How do I make POV-Ray 3.7 to produce a PNG which looks the same as
>> what it displayed on screen and as it produces when outputting to a TGA
>> file?

Set Display_Gamma to whatever your display hardware gamma is (typically 
something around 2.2), and set File_Gamma to the same value. (Not so 
difficult, is it?)


>   Why is it so hard to answer these questions? I think the questions are
> rather simple and straightforward.

They are simple, and they are simple to answer, but you keep asking them 
again and again, with virtually no variations, with no sign that any 
attempts to answer them are actually being read, which is perfectly 
frustrating.


>   I'm especially interested in question number 4. If the PNG file that
> POV-Ray 3.7 currently writes is always correct, as seems to be the claim,
> then why is POV-Ray 3.7 writing an "incorrect" result to eg. a TGA file?
> Does that mean that outputting to a TGA file is currently broken?

The output should look identical. Provided that you have set both 
Display_Gamma and File_Gamma properly - which not only means that they 
should be set to the same values (which is rather a coincicence, because 
the target system happens to be your own), but more importantly that 
they match the actual display hardware gamma.

Setting any of them to 1.0 will defy their purposes.


>   It also implies something else: That POV-Ray 3.7 should always force a
> gamma correction of 2.2 regardless of what Display_Gamma and File_Gamma are.

This is an incorrect observation, based on the hard fact that your 
viewing software implies a display hardware gamma of 2.2. If you had a 
mac, you would probably get the impression that there was some part in 
the software forcing a gamma correction of 1.8 (or whatever the Mac 
typically uses - don't know by heart).


>   However, if the output to TGA is *not* broken, that means that the output
> to PNG *is* broken because POV-Ray 3.7 is currently writing different things
> to these two image formats.
> 
>   You can't have it both ways (ie. the output to PNG and TGA being both
> correct at the same time). Either one or the other is broken. If your
> opinion is that the output to TGA is broken, that raises a whole lot of
> issues, as I wrote above.

Oh yes, you can: The simple explanation being that your Display_Gamma is 
"broken" when you set it to 1.0 instead of whatever value matches your 
system, and that File_Gamma is likewise "broken" when you set it to 1.0 
instead of whatever gamma pre-correction the target system silently 
expects for file formats not carrying any gamma information.

Post a reply to this message

Warp schrieb:
>   I have demonstrated this phenomenon here:
> 
> http://warp.povusers.org/povray_gamma_issue/index.html

Which perfectly supports my claim that you should set Display_Gamma and 
File_Gamma according to their technical purpose, not according to your 
artistic taste. Note that with File_Gamma=2.2, all is well with the 
world. On a different system (e.g. Mac), the value where all three look 
the same is likely to be different (and may even require different 
settings for File_Gamma and Display_Gamma, in case the viewing software 
happens to expect TIF files to be pre-corrected for a PC-typical display 
gamma).

Post a reply to this message

On Thu, 03 Sep 2009 15:36:49 +0200, Warp <war### [at] tagpovrayorg> wrote:
>
>   I have demonstrated this phenomenon here:
>
> http://warp.povusers.org/povray_gamma_issue/index.html
>
>   The PNG basically ignores File_Gamma (as a net effect), while a TGA
> doesn't, and thus the latter matches the preview window.

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.

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.

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



-- 
FE

Post a reply to this message

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

Warp <war### [at] tagpovrayorg> wrote:
>   However, there are situations where you precisely *don't want* that.
> You want raw pixel values, and nothing else, as I exemplified above.

  I just figured out the *perfect* example of a situation where you want
raw, linear pixel values which are *not* gamma-corrected: When you are
rendering an image which will be used as input to create a heightfield.

  There 0.5 should mean exactly half height, not a height of 0.73.

  clipca asked some time ago *why* one would ever want linear, uncorrected
pixel values. There you have your perfect example.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:

>   I just figured out the *perfect* example of a situation where you want
> raw, linear pixel values which are *not* gamma-corrected: When you are
> rendering an image which will be used as input to create a heightfield.
> 
>   There 0.5 should mean exactly half height, not a height of 0.73.
> 
>   clipca asked some time ago *why* one would ever want linear, uncorrected
> pixel values. There you have your perfect example.

I think 3.7 needs a simple flag: Gamma_Correction on will apply gamma 
correction to the file, off will not apply gamma correction to the file 
(and will not write a gAMA chunk to PNG files)



-- 
~Mike

Post a reply to this message

Warp schrieb:
>   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).

For such purposes, what you need to do is to simply convert the HTML 
colors to linear values, and go with those. The output (PNG, or any 
other file format with File_Gamma=2.2, which is the de-facto internet 
standard) will then automatically match those HTML colors.

Is that so difficult?


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

It is practical insofar as it would be difficult for POV-Ray to figure 
out automatically whether a color value supplied by the user is 
gamma-corrected already or not.

For instance, a user may have defined a light source and be quite happy 
with it, but now decide to split it up into two light sources set a bit 
apart and with slightly different hues.

So with linear color values, he can just write:

     light_source {
         MyLightPos - MyLightSpacing/2
         color (MyLightColour/2 + MyLightTweak)
     }
     light_source {
         MyLightPos + MyLightSpacing/2
         color (MyLightColour/2 - MyLightTweak)
     }

and get exactly the same overall scene brightness, with just a somewhat 
more lively illumination.

Would you want to do that with gamma pre-corrected values?


I do agree that it is somewhat impractical to not be able to use colors 
picked from, say, Photoshop directly in POV-Ray. But as far as that is 
concerned,

- You can easily write a macro to "gamma-un-correct" colors.

- My suggestion would be to provide a dedicated syntax for specifying 
gamma pre-corrected color values, such as:

     color rgb <0.6,0.3,0.6> gamma 2.2

(or, alternatively, a predefined macro in colors.inc or some such to 
achieve that same effect).


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

That is true indeed, and if the day had 36 hours I would be the first to 
implement a feature like this:

     http://bugs.povray.org/task/10

Post a reply to this message

Warp schrieb:
>   I just figured out the *perfect* example of a situation where you want
> raw, linear pixel values which are *not* gamma-corrected: When you are
> rendering an image which will be used as input to create a heightfield.
> 
>   There 0.5 should mean exactly half height, not a height of 0.73.
> 
>   clipca asked some time ago *why* one would ever want linear, uncorrected
> pixel values. There you have your perfect example.

Note that I deliberately put parentheses around that "linear, 
uncorrected pixel values" (quoting from your posting) when I asked that.

PNG files as output by POV-Ray *are* linear uncorrected in effect (and, 
if File_Gamma is chosen to be 1.0, also in encoding). It's just the 
viewing software that, by /knowing/ them to be effectively linear and 
therefore performing display gamma correction itself, gives you the 
wrong impression that they were gamma pre-corrected already.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
>      http://bugs.povray.org/task/10

  I suppose something like that could work. One question is, however,
whether the gamma assumption will be done when reading the image file
(ie. the pixel colors will be changed immediately when reading them
from the file), or only when they are needed to calculate a color (ie.
when evaluating the pigment).

  I actually don't know if POV-Ray internally stores images in memory as
bytes (like in the input image itself) or as floats. If it stores them
as bytes then pre-correcting the values will potentially lose some
information. On the other hand, post-correcting them (ie. correcting
them on the fly only when they are required for color calculations) might
make the evaluation of the pigment slightly slower.

  You might also end up having a conflict of interest: If the exact same
image map is used to both create a heightfield and as a pigment, you may
want non-corrected pixels in the first case and corrected pixels in the
latter. (Of course this could be solved just by loading the image twice.)

-- 
                                                          - Warp

Post a reply to this message

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