> Alain <aze### [at] qwertyorg> wrote:
>> On my system, ALL the starfields looks the same.
> 
>   I don't understand how that is physically possible. The starfield image
> as rendered by pov3.6 has completely different pixel values than the one
> rendered by pov3.7. For example, the upper left pixel of the starfield area
> in the pov3.6-rendered image has a pixel value of (0A, 0D, 20), while the
> one in the pov3.7-rendered image has a pixel of (3A, 41, 63).
> 

The first time i visited, the starfields where identical, except for the 
surrounding backgrounds.

This time, they are not.
The "original" and the 3.6.1 are identical.
The 3.7 is MUCH brighter. It shows details that are NOT visible in the 
other images even with the brightness cranked to the max for the firsts, 
with the brightness at it's lowest setting for 3.7.

Whatever my settings, the top and bottom parts of the rendered images 
never match.
Notably darker with 3.6.1, much lighter with 3.7.

On the other hand, I get no undesirable effects when I use a POV-Ray 
generated image as an input in another one. Brightness, saturation and 
colour balance don't change. I normaly use PNG as file format.


Alain

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Tell me, in all honesty, what do you /want/ those "'raw', 
> non-gamma-corrected pixels" for in the first place?

  What does it matter why I want them?

  If I want a program to write the value 12345 to a file, then I expect
the program to write 12345 to the file, not some other value. Why should
the program try to guess what I "really want"?

  One reason can be that I want to match exactly the image pixel values with
HTML colors. If I want the color scheme of an image to match, for example,
the background color of a HTML page, I should be able to do that.

  If POV-Ray outright refuses to do that no matter what you do, then
outputting to PNG is a complete waste of time. Outputting to an image
format where POV-Ray does not force some gamma metadata (for the simple
reason that the image format does not support that) will in this case be
more productive.

  Tell me the reason why Display_Gamma=1.0 and File_Gamma=1.0 must produce
different results. What is shown on screen does not match what is written
to the PNG file. Why not? If I specified the same value for both, I expect
both things to be identical. Now they are not.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   One reason can be that I want to match exactly the image pixel values with
> HTML colors. If I want the color scheme of an image to match, for example,
> the background color of a HTML page, I should be able to do that.

  Consider, for example, this:
http://warp.povusers.org/pov_imagemap_test/index2.html

  When outputting to PNG, File_Gamma has basically no effect. While the
pixel values written to the file are different, POV-Ray still manages to
make the PNG behave exactly as if a File_Gamma of 2.2 was always defined.
It doesn't matter if File_Gamma is 1.0 or 2.2, the result will always look
the same.

  If the user really wants the output file to look the same as what
POV-Ray displayed on screen when Display_Gamma was set to 1.0, he has
to either use some other image format (eg. TGA) or he has to manually
remove the gamma metadata from the PNG file.

  So I have a few questions:

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

  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?

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

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

  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?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   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?

Why do you not look for yourself? After all, you are a capable programmer
and you have no problem following the existing code.

	Thorsten

Post a reply to this message

Alain schrieb:
> On the other hand, I get no undesirable effects when I use a POV-Ray 
> generated image as an input in another one. Brightness, saturation and 
> colour balance don't change. I normaly use PNG as file format.

POV-Ray's input file gamma handling appears to be more reliable for PNG 
than for JPG.

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> Warp wrote:
> >   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?

> Why do you not look for yourself? After all, you are a capable programmer
> and you have no problem following the existing code.

  With that question I didn't mean "where in the source code"?

  Substitute the word "where" with the word "why" in my original question
to get the more accurate meaning.

-- 
                                                          - Warp

Post a reply to this message

*Wham!* *Wham!* *Wham!* (*bangs head on table*)

Are you /deliberately/ not following me?

So before I continue trying to answer your questions (I think I have 
answered them at least half a dozen times over), let's try to get this 
step by step:

(Chapter 1)

At the heart of POV-Ray, there is a rendering core designed to operate 
on /linear/ brightness values in three distinct spectral bands (R,G,B). 
Can we agree on this as a given fact?

If that is so (please interrupt me in case of any disagreement), then 
that core(!) rendering algorithm can be expressed as a function 
R(X,P)=Y, where X is the set of linear input brightness values, Y is the 
set of linear output brightness values, and P is the set of other 
core(!) parameters (such as scene geometry).

Let's also give a name to gamma-related transformations: Let's denote 
gamma pre-correction as g(Y)=Y', with Y in this case being a set of 
linear brightness values, and Y' being the corresponding gamma 
pre-corrected color values; let's likewise denote the inverse 
transformation as G(Y')=Y.

To finish up this chapter, can we agree that the rendering algorithm 
doesn't work properly for gamma pre-corrected values, i.e. that 
g(R(X,P)) != R(g(X),P)?

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> *Wham!* *Wham!* *Wham!* (*bangs head on table*)

  Yes, rather than answering my questions, just keep up your condescending
attitude.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   1) What exactly is the purpose of File_Gamma, given that it makes no
> difference (when creating a PNG file)?

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

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

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

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

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

  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?

  If the answer to that is "yes", then that brings up question #1 above.

  That answer also implies the same answer for question #3: That the image
preview is currently broken. If this is so, then what purpose does
Display_Gamma serve?

  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.
Wouldn't this kind of defeat the entire purpose of gamma correction in the
first place (in other words, that the image could be created in hardware
which has a gamma correction different from 2.2, and thus you should have
a way of specifying what that gamma is)?

  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.

  If the output to PNG is currently broken, it should be fixed.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   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?

  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.

-- 
                                                          - Warp

Post a reply to this message