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

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

  If you are creating an image which will later be used to generate a
heightfield, why would you want the pixels to be gamma-corrected? That
will only destroy some of the information.

  For example, if you have a linear gradient 0, 1, 2, 3, ..., 255, and
then you gamma-correct them, write them to a file, then later read the
file and gamma-uncorrect them, the resulting values will not be the same
as originally. Some of the values will have been changed. There will be
some repeated values and gaps.

-- 
                                                          - Warp

Post a reply to this message

On Thu, 03 Sep 2009 20:09:27 +0200, Warp <war### [at] tagpovrayorg> wrote:
> Fredrik Eriksson <fe79}--at--{yahoo}--dot--{com> wrote:
>> 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*.
>
>   If you are creating an image which will later be used to generate a
> heightfield, why would you want the pixels to be gamma-corrected? That
> will only destroy some of the information.
>
>   For example, if you have a linear gradient 0, 1, 2, 3, ..., 255, and
> then you gamma-correct them, write them to a file, then later read the
> file and gamma-uncorrect them, the resulting values will not be the same
> as originally. Some of the values will have been changed. There will be
> some repeated values and gaps.

Not if you set File_Gamma to 1.0.



-- 
FE

Post a reply to this message

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

  I agree, but my point is that at least the current 3.7 beta doesn't fully
emulate 3.6 in the way it creates the PNG file. (It does work when rendering
to other image formats.)

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

  It can be a problem if rgb 0.5 does not write (127,127,127) to the file
but something else. The problem is that if you really need a linear
relationship between colors and pixel values, doing any kind of gamma
transformation is going to destroy some of that information.

  In other words, if you were creating a linear gradient from left to right
on a 256-pixel wide image, what you want is

    (0,0,0)(1,1,1)(2,2,2)(3,3,3)(4,4,4)(5,5,5)...(255,255,255)

to be written to the file. What you *don't* want is that after a gamma
correction and uncorrection process you end up having something like

    (0,0,0)(2,2,2)(2,2,2)(3,3,3)(5,5,5)(5,5,5)...(255,255,255)

-- 
                                                          - Warp

Post a reply to this message

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

And here's where you're getting the gamma correction concept wrong:

With PNG (in the presence of a gAMA chunk), it is up to the /displaying/ 
software to apply a gamma correction, for the /sole/ purpose of showing 
it on a system with an inherent display gamma.

Hence, if the image is used for anything other than immediate display 
(i.e. writing it to the framebuffer of a graphics card), gamma 
correction will /not/ be applied, and the image data is left in the 
linear domain.


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

... which is exactly why in such a situation gamma correction will 
indeed not be performed.

The trick here is that in contrast to older file formats, PNG contains 
all information to reconstruct the original linear data, whether an 
encoding gamma has been applied or not - which allows the /reading/ 
application to decide whether a gamma correciton is to be performed or not.

This is a stunt that older file formats cannot achieve.


There is /one/ use case though where it /might/ make sense to tamper 
with output file gamma - and that is if the output file would be 
intended to be used as a heightfield (or similar) in a program that does 
/not/ use linear (= brightness) values, /nor/ the actual encoded pixel 
values stored in the file, but rather categorically expects height to be 
proportional to "framebuffer colors" [*] (which are /not/ linear, but 
gamma pre-corrected for a typical display with a gamma of 2.2), 
regardless of the image file format used.

[* i.e. the values typically ending up in the graphics hardware 
framebuffer, on which not only the HTML colors are based, but also the 
Windows color picker, and the values dispayed in most image editing tools.]

However, POV-Ray itself is not of this kind; furthermore, I would 
consider such software broken, and recommend deliberately feeding it 
input files in a format that is /not/ gamma-aware, so that the software 
is not bothered with ambiguities about whether heights are properly 
encoded based on brightness, "framebuffer colors", or whatever.

Note that with respect to use for height fields, the PNG file format 
with a gAMA chunk is /always/ inherently ambiguous regarding the 
representation if heights: The brightness will /never/ match the 
"framebuffer colors" (except for values 0.0 and 1.0), and there is 
nothing that POV-Ray could possibly do to avoid this mismatch: It's 
rooted in the definition of the "framebuffer colors", which equal the 
brightness values raised to the power of 1/gamma, to compensate for the 
hardware gamma. So a PNG file that works for a program interpreting 
height to be proportional to brightness will never work for a program 
interpreting height to be proportional to "framebuffer colors".

With non-gamma-aware file formats, this ambiguity is more easily 
resolved, as the values can mean just about /everything/, so chances are 
a software interpreting the file as a height field will use the values 
stored in the file, without paying a single thought about whether they 
would normally denote brightness, "framebuffer colors" or 
what-have-you-nots.

Post a reply to this message