POV-Ray : Newsgroups : povray.beta-test : Same scene renders different in v3.7beta34 versus v3.62 : Re: Same scene renders different in v3.7beta34 versus v3.62 Server Time
5 Oct 2024 18:25:07 EDT (-0400)
  Re: Same scene renders different in v3.7beta34 versus v3.62  
From: Warp
Date: 31 Aug 2009 11:20:19
Message: <4a9bea33@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:
> Warp schrieb:
> >   In fact, it seems that POV-Ray is not ignoring the File_Gamma setting,
> > as it apparently affects the pixels of the resulting PNG image. However,
> > it seems that the incorrect gamma metadata setting is written to the PNG
> > file so that when it's viewed with some program (which obeys that setting),
> > it looks different from what POV-Ray itself showed on screen (with
> > Display_Gamma being set to 1.0).

> And that's *exactly* how it should work.

  No, it isn't, because as far as I can tell, there's no way of specifying
what the gamma metadata value should be, and the image ends up wrong. It
doesn't correspond to the original image map, nor to what povray showed on
screen.

  How is doing something I *don't want* it to do "how it should work"?

> >   If the gamma metadata is removed from the PNG file (eg. by converting it
> > to another format, ignoring that gamma setting), then it shows ok.

> No, it does not. That's the definition of the metadata. If it looks 
> crappy with the metadata, your scene is crappy.

  Then tell me exactly how do I get the correct pixel values and metadata
so that the image map will look in the rendered image in the same way as
the original jpeg image.

> (1) HTML colors follow the tradition of specifying color values in a 
> non-linear encoding subject to display gamma. #7F7F7F therefore does 
> /not/ correspond to 50% of actual brightness, but to 50% of /voltage/ on 
> the VGA connector, which on a typical 2.2 gamma display corresponds to a 
> mere 22% of brightness. (Which in turn happens to roughly correspond to 
> a grey /percieved/ to be halfway between black and white, but that's a 
> different matter.)

  And exactly how is this useful to me? If I specify 7F as the brightness
of the background in HTML and 0.5 as the brightness of the background in
POV-Ray, the most useful thing for me is for those two values to match
each other. One being significantly brighter than the other is completely
useless for me.

  If I want to tell POV-Ray "I want (127, 127, 127) as the pixel for the
background, don't gamma-correct them", exactly how do I do that?

> (2) POV-Ray colors are genuine linear brightness values, so rgb 0.5 
> /does/ correspond to a 50% of brightness. Which should obviously be 
> brighter than 22% of brightness.

  Just to prove you wrong, I remade the web page:
http://warp.povusers.org/pov_imagemap_test/index.html

  Now the lower half of the rendered images is a checkerboard pattern of
alternating black and white pixels.

  Granted, the perceived brightness of this checkerboard pattern does not
match the 0.5 grey of the POV-Ray 3.6 image. However, neither does it match
the one rendered with POV-Ray 3.7. In fact, the latter deviates *more* from
that perceived brightness than the former. It's way too bright. At least on
my screen.

> With these facts in mind, your experiment in fact proves POV-Ray /3.6.1/ 
> output to be wrong (and Display_Gamma=1.0 preview of POV-Ray 3.7 as 
> well, which comes as no surprise because your display will typically 
> have a gamma of somewhere beteen 1.8 to 2.4).

  Please explain to me, once again, how a background which is way too
bright (even compared to a black/white checkerboard pattern), and especially
the *image map* being way too bright, is the correct behavior.

  Also explain to me how I would go matching HTML colors with POV-Ray
colors. As it is now, even if I do specify File_Gamma=1.0, POV-Ray 3.7
will nevertheless write a gamma metadata which will make the PNG to render
way too brightly. There's no way of matching the HTML colors nor the
original image map than to deliberately go and remove the gamma metadata
from the PNG file.

> Now given that 
> output gamma handling is obviously right for 3.7 defaults

  I have to disagree. "rgb 0.5" in 3.7 (with default settings) does *not*
match the half-brightness of a black/white checkerboard pattern.

  Granted, neither does the one in 3.6, but at least with 3.6 I get to
match colors with every other program in existence.

> >   Please explain to me, once again, why the default output of POV-Ray 3.7
> > beta is the correct one and the others are incorrect.

> Done.

  You didn't actually explain anything. You basically just said "it's
correct because I say so", without any true explanation. You even claimed
how my example images actually demonstrate that 3.7 is doing the right
thing, while to me it's glaringly obvious that this isn't so.

  I find it completely counter-productive to have to go and manually remove
the wrong gamma metadata in the PNG file produced by POV-Ray 3.7 if I want
it to match eg. HTML colors and the colors of image maps, even if I had
specified a File_Gamma of 1.0

-- 
                                                          - Warp


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.