Warp schrieb:
>> As I've pointed out to Warp about half a dozen of times, it is the
>> /input file/ gamma handling that's broken indeed.
> 
>   If the output of POV-Ray is perfect, then why does POV-Ray produce
> *different* results when outputting to TGA or BMP than it does when
> outputting to PNG?
> 
>   You have yet not answered that question (nor the others I have made).

It seems we can't reach common ground where I could actually explain 
that to you. I don't know whether it's me or you, but we obviously can't 
seem to. I tried to answer those questions half a dozen times if not 
even more by now in good faith, only to get responses from you asserting 
that I didn't answer anything, so something must be going terribly wrong 
with our communication.

Let me try once again:

The whole idea of gamma handling is to get output right: To have the 
monitor reproduce exactly (or as exactly as possible) what was 
originally recorded in the image file.

Obviously, for non-CGI files, what was originally recorded in an image 
file is physical brightness (of R, G and B component). This is what the 
monitor must therefore reproduce.

Now one might think that encoding the physical brightness linearly in 
the image file would be the most straightforward solution to this. 
However, early file formats started out differently.

First thing is that displays were invariably CRT (unless output was 
printed), and that display and graphics hardware was simple. Now this 
has the following implications:

- In CRT displays, the energy of the electron beam (and therefore the 
resulting brightness of the phosphor) is /not/ linear proportional to 
the input signal voltage, but roughly square: CRT displays have an 
inherent /display gamma/.

(Technically, this means that the output brightness is a function of the 
input signal voltage of the form f(x)=x^gamma.)

- Graphics adaptors, however, as soon as they became able to display 
more than just two brightness levels (on/off), used more or less 
straightforward linear digital-to-analog conversion to convert frame 
buffer data to signal voltage levels. Thus, the display system as a 
whole exhibited that same inherent gamma as the CRT display that 
happened to be connected.

The exact value of that gamma, however, depended (and still depends 
today) on the exact combination of display and and graphics adaptor, and 
therefore especially in the IBM-PC world differs to this day between 
individual computers.

---
This is where POV-Ray's "Display_Gamma" kicks in: It informs POV-Ray 
about the display gamma of the system on which the preview window is to 
be displayed, so that POV-Ray can pre-correct the image data before 
writing it to the frame buffer (or passing them to the operating system 
for that purpose).
---

Now when graphics file formats emerged, the first ones in common use 
were mere dumps of the display framebuffer; often, files would even 
store the data into separate bit planes, just as it was organized in 
some display adaptors' framebuffers. Therefore, of course, they implied 
a certain display gamma: They were /gamma pre-corrected/.

As the fidelity of graphics displays was still low anyway, nobody cared 
about the precise value of the gamma at that time. Virtually nobody was 
even aware that it was there.

This is how older file formats like TIF or BMP started out: They relied 
on every display having an inherent gamma, and the file data therefore 
pre-corrected. However, they did not specify exactly what gamma was to 
be expected, and each file would be pre-corrected to match the display 
gamma of whoever happened to have created that particular file.

---
This is where POV-Ray's "File_Gamma" kicks in: It informs POV-Ray about 
the display gamma of the system on which the file is to be viewed or 
post-processed, so that POV-Ray can pre-correct the output file to match 
that display.
---

Some file formats, however, have addressed the problem of gamma varying 
between different computers, by using linear encoding. To display such a 
file, the decoding software must apply gamma correction itself, before 
passing the data to the graphics hardware. Of course, in this case the 
displaying software must be aware of the system's inherent display gamma.

Other file formats are kind of "logically linear" despite using an 
/encoding gamma/ to preserve a higher "depth" at lower brightness. To 
display such a file, the decoding software must "un-apply" the encoding 
gamma first, then apply any display gamma correction; in practice, this 
can be done in one step by applying

   f(x)=x^(1/(encoding_gamma*display_gamma))

PNG belongs to this group of file formats, provided that a gAMA chunk is 
present.

---
This is where POV-Ray's "File_Gamma" kicks in again, this time in a 
slightly different role: It informs POV-Ray about the encoding gamma to 
be used, as the PNG format leaves this choice up to the creator of the file.

Or, to be more precise, it informs POV-Ray about the /inverse/ of that 
encoding gamma. This has the benefit of being more intuitive, because 
the values will be in the same domain as for the parameter's classic role.

There is also a rationale why this parameter isn't just hard-coded into 
POV-Ray, and why to use File_Gamma and not yet another parameter: 
Sometimes, software handling a PNG file may not be able to process the 
gAMA chunk, and will silently assume the file to be encoded with gamma 
pre-correction, i.e. encoding_gamma = 1/display_gamma. In that case, 
File_Gamma automatically takes back its classical role of specifying the 
target system's display gamma.
---


Does this answer your question of what exactly File_Gamma does, and why 
it has different effects on different file formats?

>   You will also have to explain

I have to explain nothing. (This is exactly the attitude that drives me 
berserk. It is not /my/ responsibility to make sure that you're 
well-informed.)


> why POV-Ray displays on screen an image
> which is different from what it writes to the PNG file, even though
> Display_Gamma and File_Gamma have been set to the same value.

As I mentioned before, this only happens if you set Display_Gamma wrong: 
In that case, POV-Ray will no longer be able to perform proper gamma 
correction on the image data it hands to the display hardware, and 
therefore what you see on-screen will no longer be what POV-Ray 
computed; is it any surprise to you that in that case what ends up in 
the file (which is supposed to be what POV-Ray computed) may differ from 
what you see in the preview?

Note that when I'm saying things like "what POV-Ray computed", I take 
gamma correction to /not/ be part of that computation; it is merely an 
additional transformation of the output data required to get the 
computed data through the display hardware onto your retina, unpertubed 
by the peculiarities of the hardware.

 > I'm not
> getting what I'm seeing. Coincidentally (not), when outputting to some
> other image file format, such as TGA, the resulting image is identical
> to what POV-Ray showed on screen.

Not much of a surprise that it looks the same with those file formats: 
Whether you fail to perform gamma correction before sending data to the 
framebuffer yourself, or fail to apply gamma pre-correction before 
writing output to a file format that is silently expected by all image 
display software to implicitly include gamma pre-correction, the effect 
is the same: Values originally implied to be linear brightness values 
will be written directly to the framebuffer without applying proper 
gamma correction first.

The fact that both look the same doesn't make any one of them right.


You're welcome of course to try shoving gamma-pre-corrected values into 
POV-Ray in the first place and hope that this will make up for the 
artificially forced lack of gamma-correction of the output. Be prepared 
however for this to not work: The render engine in POV-Ray is designed 
to operate on linear brightness values, and you'll end up with math 
where all of a sudden 0.5 + 0.5 = 2.3. You may not be able to put your 
finger on where exactly the output is wrong, but you may have a much 
harder time getting your shot to look realistic. And this is precisely 
why POV-Ray does not provide full support for such nonsense.

Post a reply to this message