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

Post a reply to this message

Warp schrieb:
>   It was not, after all, a problem with my monitor gamma. It was a problem
> with the test being skewed by how CRT works.

That does explain the whole smash then. I didn't expect it to make that 
much of a difference (I'm using an LCD myself).

>   There's still the problem of the image map incorrectly brightening, though.

Input file gamma issues. POV-Ray, as mentioned already, is currently 
pretty poor about this (and has always been, by the way).

Post a reply to this message

Nicolas Alvarez schrieb:
> I have an LCD monitor, and the checkerboard looked *green*. Quite strange.

Do you use an analog or digital connection?

Post a reply to this message

Warp schrieb:
>   On the other hand, I'm wondering how precise this test really is.
> Bright white lines stand out a lot more than black lines, and the brighter
> the white lines are, the more they tend to glow to the human eye. A bit
> like color bleeding. This would mean that if your monitor is set very
> bright, then the white lines will overwhelm the black ones, requiring
> a different gamma correction value than if your monitor was set to a
> very dim setting, in which case the white lines won't stand out that much
> compared to the black lines.

You can do the same test with a 0.0 / 0.5 checkerboard and 0.25 
background, for instance.

Indeed lighting conditions (of your room, not your scene ;-)) do 
influence the perception of brightness and mess with the gamma, so I'd 
assume display brightness possibly does as well.

Post a reply to this message

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