Warp schrieb:
>   Or if I try to express myself more clearly: Could it be that this
> precise test (the horizontal lines) gives you the wrong impression of
> what the proper gamma setting for your monitor would really be, this
> visual impression being biased by the brightness setting of the monitor?
> 
>   If you used a completely different test, eg. physical pieces of paper
> colored appropriately, would you end up with the same gamma setting?

Speaking of pieces of paper, try this:

Display that image on your screen, and hold a thin piece of paper 
against it to cover the whole image. This will physically blur the black 
and white lines, eliminating visual perception issues.

On a CRT, in which each scanline is produced independently, this should 
give /exactly/ 50% brightness (of what comes through the paper of course)

I didn't think this through for LCDs; there might be some side effects 
of light scattering between pixels and being affected by the other 
pixel's liquid crystal, but if one considers this an issue, the sheet of 
paper should allow to make the test with a coarser pattern. (Dynamic 
backlight arrays might really make things complicated though.)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> That's what happens when one gets annoyed by the other one not 
> listening, alleging that one is "explaining nothing at all", and being 
> extraordinarily demanding: It drastically reduces the motivation to 
> invest time into it.

  You didn't explain anything. All you did was present claims. You did not
answer my questions nor explained anything.

-- 
                                                          - Warp

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Warp schrieb:
> >   (Btw, IMO there still should be a way of telling POV-Ray to not gamma
> > correct anything if that's what the user wishes. Currently it seems to
> > be difficult, as POV-Ray seems to be writing a gamma value of 2.2 to the
> > output PNG file regardless of what File_Gamma is. I don't even understand
> > where it's getting that 2.2 value from.)

> That's not POV-Ray, it's the display software.

  What are you talking about? Are you mad?

  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?

  What you said is as silly as saying that if write a C++ program which
writes the byte value 127 to a file, and instead it writes some other
value, the "fix" to this problem would have something to do with the
"display software". That's just nonsensical.

> Encoded pixel data and 
> the embedded gamma information together allow the viewing software to 
> reconstruct the linear values, and it will then convert this to whatever 
> it assumes the actual display hardware gamma to be.

  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?

-- 
                                                          - Warp

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> On a CRT, in which each scanline is produced independently, this should 
> give /exactly/ 50% brightness (of what comes through the paper of course)

  You assume that on a CRT pure white pixels have the exact same size as
pure black pixels, ie. that there's no color bleending at all happening
on the fluorescent surface.

-- 
                                                          - Warp

Post a reply to this message

>   Are you also seriously claiming that the starfield image in the pov3.7
> rendered image looks just fine? Does that mean that the original looks like
> a black square with some tiny white pixels here and there in your monitor?
> 
> 
On my system, ALL the starfields looks the same.


Alain

Post a reply to this message

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

-- 
                                                          - Warp

Post a reply to this message

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

Warp schrieb:
>   You assume that on a CRT pure white pixels have the exact same size as
> pure black pixels, ie. that there's no color bleending at all happening
> on the fluorescent surface.

No, I just assume that the the phosphors react sufficiently linear with 
respect to electron beam intensity vs. emitted light intensity, as well 
as interaction with scattered light. If that is given (and as of now I 
have not heard of anything to the contrary), it does not matter how much 
the beam widens at high intensities, or how much optical scattering 
occurs in the phosphors: Both effects then just change the distribution 
of the light emission, but preserves the overall brightness.

If you doubt this presumption, you can still try with a coarser pattern 
and a diffusor like a sheet of paper.


Also note that if there was a nonlinear effect of color bleeding on the 
overall brightness acting in favor of the 3.7 gamma, then the same 
effect would have been present in the checkerboard pattern as well, 
partially countering the black/white transition nonlinearities in there 
that favored the 3.6 settings.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> 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.

  Except that it isn't. If you specify Display_Gamma=1.0 and File_Gamma=1.0,
POV-Ray will display non-gamma-corrected pixels on screen, and write the
exact same non-gamma-corrected pixels into the PNG file, but then it
specifies a gamma metadata of 2.2 in the PNG file (where is it getting
the 2.2 from anyways?) which causes the PNG to show *differently* than
what POV-Ray showed on screen.

  If you then manually remove the gamma metadata from the PNG file, *then*
the PNG and what POV-Ray showed on screen will match, because only then
will no extraneous gamma correction be applied (as was the original intent
when the gamma settings were both set to 1.0).

  Can you explain where the extranous 2.2 gamma setting is coming from,
when both Display_Gamma and File_Gamma are set to 1.0? Is there a third
setting somewhere? Is it hard-coded into the POV-Ray source code?

  I think that it's a bit ridiculous that if I want POV-Ray to produce "raw",
non-gamma-corrected pixels, I have to go through manual post-processing
trickery to achieve that (or, I assume, use an image format which does not
support gamma metadata). If I say that gamma is 1.0, in other words,
completely unmodified pixels, then I mean that.

-- 
                                                          - Warp

Post a reply to this message

Warp schrieb:
>> Consider this a "what you see is what POV-Ray computed" policy.
> 
>   Except that it isn't. If you specify Display_Gamma=1.0 and File_Gamma=1.0,
> POV-Ray will display non-gamma-corrected pixels on screen, and write the
> exact same non-gamma-corrected pixels into the PNG file, but then it
> specifies a gamma metadata of 2.2 in the PNG file (where is it getting
> the 2.2 from anyways?) which causes the PNG to show *differently* than
> what POV-Ray showed on screen.
> 
>   If you then manually remove the gamma metadata from the PNG file, *then*
> the PNG and what POV-Ray showed on screen will match, because only then
> will no extraneous gamma correction be applied (as was the original intent
> when the gamma settings were both set to 1.0).

(1) Note that specifying a Display_Gamma does /not/ change what POV-Ray 
/computes/; so if you specify a wrong Display_Gamma (and 1.0 /is/ a 
wrong value for your system), what you see during preview is /not/ what 
POV-Ray computed either.

(2) Are you /sure/ that what you observe is a gAMA chunk specifying an 
encoding gamma of 1/2.2 (i.e. encoded for direct display on a gamma 2.2 
display)? I pretty much doubt it:

- If POV-Ray writes linear color values into the PNG file, it must write 
a gAMA chunk specifying a gamma of 1.0 to produce a properly encoded PNG 
file.

- If the file contained a gAMA chunk specifying a precorrection for a 
gamma of 2.2 (i.e. an encoding gamma of 1/2.2), then AFAIK stripping 
that gAMA chunk would not change the way most image vewers display the 
image, because they will by default assume exactly that encoding gamma.

- If, however, POV-Ray does write linear color values into the PNG file, 
accompanied by a gAMA chunk specifying an encoding gamma of 1.0, then 
indeed stripping that gAMA chunk will cause image viewers to presume an 
encoding gamma of 1/2.2 (which will then be /not/ what POV-Ray used), 
and therefore not perform any additional gamma-correction, because it 
cancels out with their assumed display hardware gamma of 2.2 - and this 
would indeed have the same effect as the wrong Display_Gamma=1.0 
settings (which tells POV-Ray to not perform gamma-correction on the 
preview, by forcing it into assuming that the display hardware has a 
gamma of 1.0).


So to sum it up: Specifying Display_Gamma=1.0 does not change what 
POV-Ray /computes/, only what it shows in preview; and I expect the 
gamma 2.2 gAMA chunk in the File_Gamma=1.0 to be a misinterpretation of 
your observations.

>   I think that it's a bit ridiculous that if I want POV-Ray to produce "raw",
> non-gamma-corrected pixels, I have to go through manual post-processing
> trickery to achieve that (or, I assume, use an image format which does not
> support gamma metadata). If I say that gamma is 1.0, in other words,
> completely unmodified pixels, then I mean that.

Tell me, in all honesty, what do you /want/ those "'raw', 
non-gamma-corrected pixels" for in the first place?

I actually find it ridiculous that you /ask/ for it, that being 
essentially /messed-up/ gamma in what will ultimately be visible 
on-screen; if you do not recognize this fact, then you haven't 
understood gamma handling yet (and I'm not talking about POV-Ray in 
particular here, but the general concept), and might want to do a bit of 
googling on the topic.

Post a reply to this message