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

On Thu, 03 Sep 2009 16:42:46 +0200, Warp <war### [at] tagpovrayorg> wrote:
> 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.

Which is exactly what you should get if you use a gamma-aware image  
format, regardless of what you set File_Gamma to.



-- 
FE

Post a reply to this message

Fredrik Eriksson <fe79}--at--{yahoo}--dot--{com> wrote:
> On Thu, 03 Sep 2009 16:42:46 +0200, Warp <war### [at] tagpovrayorg> wrote:
> > 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.

> Which is exactly what you should get if you use a gamma-aware image  
> format, regardless of what you set File_Gamma to.

  No, because gamma correction will change the actual values of the
pixels before they are used/displayed. Thus, for example, a pixel which
in the image file has values <0.5, 0.5, 0.5> will be converted to
<0.73, 0.73, 0.73> before being displayed on screen, for a gamma correction
value of 2.2.

  However, when you are using an image to generate a heightfield, you are
not *displaying* the pixels. It's actually not an image supposed to be
shown on screen. It's just an image file being used to represent height
values. (One could say that an image file is being "abused" for a different
purpose than it was originally intended.) However. this is a very common
technique because image files are both very common with a lot of support,
and a practical way of storing height information.

  In this situation gamma correction makes no sense because the image file
does not actually contain an image.

-- 
                                                          - Warp

Post a reply to this message

Fredrik Eriksson <fe79}--at--{yahoo}--dot--{com> wrote:
> >   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.

  Saying that v3.6 did it wrong is not very helpful for someone who is
trying to render a 3.6 scene using POV-Ray 3.7.

> >   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 kind of color correction do I need when I'm rendering an image to
be later used to generate a heightfield?

  The answer is: None. When I specify a color of 0.5, I expect a value
which is exactly half of the pixel component value range to be written
to the image file so that when the image is later used to create a
heightfield, that pixel will produce a height which is exactly half of
the maximum height.

  Having to "pre-correct" the value 0.5 in order to counter the gamma
correction in order to get what I want is unfeasible and doesn't make
too much sense. It's much more reasonable to be able to turn all gamma
corrections off.

-- 
                                                          - Warp

Post a reply to this message

On Thu, 03 Sep 2009 17:54:17 +0200, Warp <war### [at] tagpovrayorg> wrote:
> Fredrik Eriksson <fe79}--at--{yahoo}--dot--{com> wrote:
>> Which is exactly what you should get if you use a gamma-aware image
>> format, regardless of what you set File_Gamma to.
>
>   No, because gamma correction will change the actual values of the
> pixels before they are used/displayed. Thus, for example, a pixel which
> in the image file has values <0.5, 0.5, 0.5> will be converted to
> <0.73, 0.73, 0.73> before being displayed on screen, for a gamma  
> correction value of 2.2.

When used as input, the pixel with the (gamma-corrected) value <0.73,  
0.73, 0.73> will be converted back to <0.5, 0.5, 0.5> *if you use a  
gamma-aware image format*.



-- 
FE

Post a reply to this message

On Thu, 03 Sep 2009 18:02:46 +0200, Warp <war### [at] tagpovrayorg> wrote:
>   Saying that v3.6 did it wrong is not very helpful for someone who is
> trying to render a 3.6 scene using POV-Ray 3.7.

One could argue that using "#version 3.6" should completely mimic the  
behaviour of v.3.6, but that does not mean v3.7 should behave the same by  
default.


>   What kind of color correction do I need when I'm rendering an image to
> be later used to generate a heightfield?
>
>   The answer is: None. When I specify a color of 0.5, I expect a value
> which is exactly half of the pixel component value range to be written
> to the image file so that when the image is later used to create a
> heightfield, that pixel will produce a height which is exactly half of
> the maximum height.
>
>   Having to "pre-correct" the value 0.5 in order to counter the gamma
> correction in order to get what I want is unfeasible and doesn't make
> too much sense. It's much more reasonable to be able to turn all gamma
> corrections off.

The whole point of using a gamma-aware image format is that you do not  
need to counter the gamma correction; it is handled correctly by default.  
The problems arise only when using gamma-unaware formats.



-- 
FE

Post a reply to this message

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

Because it would be impractical to distinguish between different /use/ 
of the image data (e.g. what about an image used to create a pigment, 
which is then in turn to define a function?) from a logical point of 
view values would have to be converted when reading the file. From an 
algorithmic point of view, however, the encoding used in the file could 
be preserved, and gamma computations performed whenever the pixel data 
is actually evaluated (for whatever purpose).

For high-resolution texture images, on-the-fly evaluation would be the 
ideal way to go (saves memory, and the number of queries per pixel are 
smaller, maybe even <1 per pixel, in which case the computational 
overhead would even be lower than with (A)), while for low-res an 
on-load computation would obviously better.

A lossy transformation is definitely /not/ the way I'd want to go, so in 
case of an on-load transformation, an 8-bit image would have to be 
converted to 16-bit (which is about sufficient for gamma values around 
2.0) or single-precision floating point on that occasion (half-precision 
float would theoretically be an alternative, but I wouldn't want to go 
for that due to lack of hardware support on most systems).


>   I actually don't know if POV-Ray internally stores images in memory as
> bytes (like in the input image itself) or as floats.

Various. I haven't found the time to look at it in detail, but the image 
container provides support for 8-bit, 16-bit, and single-precision float 
data.

Post a reply to this message