POV-Ray : Newsgroups : povray.beta-test : Re: Differences from 3.6 to 3.7 =3D> gamma .. clarification sought Server Time
27 Dec 2024 14:04:52 EST (-0500)
  Re: Differences from 3.6 to 3.7 =3D> gamma .. clarification sought (Message 1 to 1 of 1)  
From: Simeon
Subject: Re: Differences from 3.6 to 3.7 =3D> gamma .. clarification sought
Date: 10 Apr 2006 09:00:00
Message: <web.443a55d3827e9ea1c20a78eb0@news.povray.org>
"Chris Cason" <nos### [at] deletethispovrayorg> wrote in message
news:43ea602c@news.povray.org...
> Chambers wrote:
>> 1) The scene renders much too brightly in version 3.7
>
> this is because display gamma correction is on by default in 3.7, and your
> scene is designed for no correction. add a #version 3.6 or assumed_gamma 2.2
> to your scene to avoid this issue (though it is better to change the scene to
> look correct with gamma correction on since it will be more portable).
>
> see the release notes for more information on the way gamma works now.

Re gamma change in 3.7,

I found the readme a little confusing
http://povray.org/beta/

Is the actual handling of gamma changing, or simply the point at which we
can specify to povray what the gamma is? Or just the default gamma when none
is specified?

It seems to me the default should be something like using gamma 1.0 in the
trace, and storing that info in the image file, which can be done for png,
then the client viewer make whatever adjustment is desireable for the
client.

I would personally set as 1 for 'good copies' and then use GiMP etc to clone
a low-res copy for the web etc with appropriate gamma for whatever output ..
I'd rather reserve the highest fidelity for print output where the natural
gamma is 1, and allow some degredation when shrinking to web page size,
since there is plenty of degredation there anyway, noone will notice the
few lost bits due to gamma conversion!

I thought povray had sensible gamma handling already .. now I am really
confused.

The word "assumed" in "assumed_gamma" should give away that it is an
assumption ... the argument about rendering on a machine seperate from the
front-end doesn't seem valid .. the assumed gamma is what you assume your
audience is going to use when viewing the image, no? And by storing it in
the .pov file, everyone who tries to render your file can see what you were
aiming for and because it is 'assumed' understands that they can tweak it.
As far as the front-end/back-end thing, isn't it up to the artist to set up
their viewer to preview correctly ... not for the povray to try to
second-guess? What is important is for the povray user to be able to
understand the system and not be confused further .. I'm not sure that
changing the system helps with that.

I am sure I'm getting something wrong here, but I wonder why someone thinks
it needs changing? Has there been complaint or discussion? I would like to
understand this. The default I would set is probably not what others would
choose, will I still be able to configure it correctly after 3.7?

I think it *is* useful to be able to specify the gamma in the .pov file, in
order to be able to handle the files that were rendered for a gamma that
you don't have and where the user didn't understand gamma and therefore it
renders badly on your own system, without having to tweak your global
settings.

Seems to me we need three gamma settings for a given source file being
traced at a given time.

1) system gamma of the PC seeing the preview output of PoVRAY so PoVRay can
adjust the preview to look correct
2) target gamma of the output image file, eg 2.2 for web, 1.0 for non-sRGB
print etc
3) hack gamma, to adjust a file that looks wrong because the author didn't
set the gamma correctly

I am not sure now which of these are provided for in the new scheme, and
which they correspond to.

I would see 2 as being the one that one would set on the command line and
would if omitted default to 2.2 or 1 or whatever is configured at compile
time, or some default in an ini file set by the user; and 3 being the one
from the file that you are eradicating? -- With 1 being system-dependent
and set in the global ini file of the front-end povray that is being used
to control the trace and used to adjust the preview image.

Without all three of these available, if I want to adjust gamma of a pic
that I know will be viewed at say 2.2, and using assumed_gamma 2.2 doesn't
give the correct output, then I have to put assumed_gamma different to 2.2
to obtain an image viewable at 2.2 .. and when I or someone or me reads the
source and my notes later, they will not only be confused, they will
probably get the wrong output because they will think I was actually
rendering for some gamma other than 2.2 and they will adjust it back. ???
Or am I now expected to individually hand-correct each texture in the
scene?

But maybe I should download the beta and play with it to try to see what you
mean .. however being beta perhaps it may not work as you intend, so I would
rather understand what you are trying to do, than look at what you have
done. :)

Simeon


Post a reply to this message

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