Warp schrieb:
>> That's not POV-Ray, it's the display software.
> 
>   What are you talking about? Are you mad?

*Sigh*

Maybe I'm perfectly hopeless at explaining things. It has always seemed 
the contrary to me, but I can't seem to get this through to you.

>   How is it "the display software" if I want POV-Ray to output a pixel
> value of (127,127,127) for rgb .5, without any correction of any kind?

Then you just pick File_Gamma=1.0, and you /will/ get that pixel value 
of 127,127,127 in the file.

But POV-Ray will also (correctly) write into the PNG file that no gamma 
correction was applied whatsoever (or, probably, that a gamma of 1.0 was 
applied), because that's just how the PNG file format gamma handling is 
supposed to work. Not an invention of the POV-Ray developers, but part 
of the PNG specification.

Which most modern image viewing software will take to imply that /it/ 
should do the gamma correction, because it will assume your display 
hardware to have a gamma of around 2.2, and therefore require a gamma of 
1/2.2 to be applied to the image data first.


Let me repeat it: *This is proper behaviour!* Not because I say so, but 
because the PNG specs say so.

If you do not want this, pick a file format that allows you to screw up 
gamma - or find a software that lets you mess with an image's gamma. 
POV-Ray is a raytracing software, not an image post-processing tool.


I know you don't like the results and think they're wrong, and that is 
actually the case - but as I have been repeating over and over again, 
this is *not* a problem of the *output* file gamma, but a problem of the 
*input* file gamma. And it doesn't make any sense to modify output gamma 
file handling to fix problems with input file gamma, does it??!

>   If I want the exact values (127,127,127) to be written to the file,
> what exactly is the reason why POV-Ray would refuse to do so?

 From here on I'm taking your question to actually be "If I want the 
voltage levels of (50%,50%,50%) to be sent to the monitor...", although 
that's a totally different thing.

The reason for POV-Ray to refuse to do so in PNG files is simple: 
Because the aim is to get /correct/ file output, i.e. if a brightness 
level of 50% is computed, the aim is to generate an output file that, 
when displayed, will cause a brightness level of 50% on the output hardware.

Consider this a "what you see is what POV-Ray computed" policy. It makes 
the best effort to ensure that others will see just the same thing; that 
the output is realistic; and that you know sure as hell that if it looks 
crappy on your display, it is your scene illumination or texturing that 
needs work [*], not your output gamma settings.

[* Thus the theory; at present, it can also mean that input file gamma 
handling issues need woring around.]


With file formats that do not define gamma handling, this can only be 
achieved by making known to POV-Ray what gamma pre-correction the 
software "downstream" in your image processing pipeline expects, and 
this what File_Gamma is designed to do. POV-Ray will then encode the 
image to match that software's expectations.

With file formats that are designed to unambiguously address gamma 
handling, this task is much simpler: Just comply to the file format. No 
need for File_Gamma at all. Some file formats may demand colors to be 
encoded fully linearly (I guess OpenEXR is such a case), while others 
will allow a gamma transformation to be applied before encoding pixel 
values, but require that the gamma parameter is stored in the metadata, 
and that software reading such files must apply the inverse 
transformation after decodig the pixel values before processing or 
displaying them. In any case, such file formats by design make it the 
viewing software's responsibility to perform any necessary gamma 
pre-correction to compensate for the display hardware's gamma.

PNG does unambiguously address gamma handling with the gAMA chunk, and 
is therefore designed to preserve the actual brightness information in 
the image - although in this case the File_Gamma may also still be 
required for interoperation with older software down the pipeline that 
happens to be ignorant about gAMA chunks.


Now if I understand you right, you want to apply an additional gamma 
transformation to the final image, because

(A) you want to make your "rgb <127,127,127>/255" look like HTML color 
#7F7F7F, and

(B) you want to make gamma pre-corrected JPG input files pass through 
the whole rendering process "unharmed".

Aside from these, you didn't bring up any complaints about POV-Ray's 
gamma handling, so I assume these are the only purposes why you would 
want such a post-render gamma transformation step (except maybe for 
nostalgic reasons).

Note however that in both cases, applying a gamma transformation /after/ 
the rendering is the wrong solution to this problem: The proper solution 
is to apply this very same transformation /before/ the rendering.

Look at this simple example:

Let's say you have a white plane illuminated by two spotlights of 50% 
intensity. Areas hit only by one light should obviously give you a 
brightness of 50%, while the region illuminated by both spotligts should 
obviously give a brightness of 100%. In the linear domain this is no big 
deal: 0.5 + 0.5 = 1.0.

Now let's do these computations in the gamma-precorrected domain: There, 
50% brightness equals a value of 0.73. In the areas illuminated by only 
one spotlight, this gives you a total "illumination value" of 0.73, 
which we have just seen to equal 50% brightness. Fine, no harm done 
here. But the area where the spotlights intersect will give you an 
illumination value of 0.73 + 0.73 = 1.46; in the gamma-precorrected 
domain, that would equal a whopping 230% of brightness!

As you may see even from this simple example, for the math it /does/ 
make a difference whether you transform your input colors to the linear 
domain /before/ or /after/ performing the computations. The latter won't 
properly remedy the errors introduced by failing to do the former, even 
for comparatively simple situations.


Your test-pattern image has clearly shown that output gamma as such is 
handled properly (otherwise the black-and-white stripes wouldn't match 
the rgb 0.5). So if there's a problem with the images (and do I agree 
that this is definitely the case for the image map, and I do agree about 
the "#7F7F7F" thing to the extent of calling it an "issue"), then any 
proper remedy must tackle them /before/ the computations.

Post a reply to this message