Le Forgeron <jgr### [at] freefr> wrote:
>
> Beware of gamma... W3C probably has not the same gamma as povray now.
> Things are fine for <1,0,0> / #FF0000, but #C00000 might be only
> <0.5,0,0>, while #7F7F7F being only <0.25,0.25,0.25>
> (fictional numbers here, check your gamma curves!)
>
> To sum up, conversion from W3C colorspace might not be linear for a
> povray include.
>
> Getting colour which change from version is also a bad idea: you are not
> parsing it each time you need it, but usually only once... what about
> scenes with some parts in 3.6 and other parts in 3.7 ? How would you
> handle that ?

Thank you for your comments.
Gamma correction: Alas, I am not sufficiently prepared on this subject.

However ...
I have a Windows system, and my assumed_gamma is 2.2 by default.
If I want with POV-Ray a background Coral, and I put my picture in a HTML file
with the background of CSS set to Coral, I know with certainty that the two are
the same background.

Sure, maybe it's not correct to change the colors of the old colors.inc.
Perhaps a better solution would be then to add, for example:

X11_Coral = ... ?

I would be happy to your further clarification.

Greetings

Post a reply to this message

Le Forgeron <jgr### [at] freefr> wrote:
> Beware of gamma... W3C probably has not the same gamma as povray now.

  I thought the whole idea of gamma correction was that you *don't* have
to worry about whether <.75, .75, .75> "looks right". In other words,
<.75, .75, .75> should always look the same in all systems, assuming those
systems have a proper gamma correction set up. In other words, you don't
have to be modifying that value depending on which "gamma" is being used
but you are able to always use the same absolute value and let the target
system do the necessary corrections. Which is the whole idea of gamma
correction.

  You are reversing the situation completely and basically saying that
because of gamma correction you *must* always fine-tune that color value
by hand. I think that would completely nullify the whole idea of gamma
correction.

  Besides, if you want to change the gamma of the colors used in POV-Ray,
the correct place is not the color definitions themselves, but the assumed
gamma setting of POV-Ray ('assumed_gamma' global setting in pov3.6).

-- 
                                                          - Warp

Post a reply to this message

>  I thought the whole idea of gamma correction was that you *don't* have
> to worry about whether <.75, .75, .75> "looks right". In other words,
> <.75, .75, .75> should always look the same in all systems, assuming those
> systems have a proper gamma correction set up.

POV works in linear colour space though, not gamma corrected.  So when you 
supply colours or textures to POV, you need to inverse gamma correct them 
first, to get correct results.

IMO POV should have an option to do this automatically, as people are used 
to knowing what <0.75,0.75,0.75> looks like on their desktop (eg by using 
Paint or HTML).  <0.75,0.75,0.75> in a POV colour statement or a texture 
used by POV means something different currently.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> IMO POV should have an option to do this automatically

  It has had that for a long time: assumed_gamma.

-- 
                                                          - Warp

Post a reply to this message

>> IMO POV should have an option to do this automatically
>
>  It has had that for a long time: assumed_gamma.

That only works at the output of the rendering engine though, it needs to 
also apply the inverse to any colours/textures at the input of the rendering 
engine.  Otherwise you need to do the inverse-gamma hack to images and 
colours to make things look right.

eg try rendering background{ color rgb <255,128,64>/255}

If the user has chosen that colour to match something else outside of POV, 
it's not going to work unless you turn off gamma correction in POV, which 
would then mean any lighting in your scene will be wrong.

The point is, most users expect that entering a colour value or supplying an 
image_map to be in their desktop colour space (ie already gamma corrected), 
but POV treats these things as being in linear colour space.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> >> IMO POV should have an option to do this automatically
> >
> >  It has had that for a long time: assumed_gamma.

> That only works at the output of the rendering engine though

  No, assumed_gamma is used for all the input values. To modify the
output image, the display gamma command-line option is for that (this
is, AFAIK, what gets written to the PNG file when outputting to one).

-- 
                                                          - Warp

Post a reply to this message

>  No, assumed_gamma is used for all the input values.

My experiences lead me to believe that isn't the case.

Please tell me what settings to use to render this correctly then:

#default {finish{ambient 0}}
background{ color rgb <255,128,64>/255 }
light_source { <0,0,-1> 1 parallel point_at <0,0,0>}
box{ 0 1              translate <   0,0,2> pigment{color rgb 1} }
box{ 0 1 rotate y*-60 translate <-1.5,0,2> pigment{color rgb 1} }

The output file should consist of orange background pixels of 255,128,64, 
and the right box should be twice as bright as the left box *on my monitor* 
(ie utilising whatever gamma setting I have, could be 1.8 for mac or 2.2 for 
PC).  This is the expected output.

If I render with no gamma correction, I get the expected result: correct 
background colour, and the actual pixel values of the right box are twice 
the left box.  But how to apply gamma correction without screwing up the 
background colour?  Currently the only solution I see is to apply 
anti-gamma-correction to the rgb values in the source file (and to any 
texture files used), which isn't ideal as the exact same source files will 
then render differently depending on that users output gamma setting.

Post a reply to this message

"scott" <sco### [at] scottcom> wrote:

> The output file should consist of orange background pixels of 255,128,64,
> and the right box should be twice as bright as the left box *on my monitor*
> (ie utilising whatever gamma setting I have, could be 1.8 for mac or 2.2 for
> PC).  This is the expected output.
>
> If I render with no gamma correction, I get the expected result: correct
> background colour, and the actual pixel values of the right box are twice
> the left box.

I assume you mean, when using no assumed_gamma at all?

On a PC with a default 'system' gamma-correction of 2.2, and with POV for
Windows' display_gamma also set to 2.2, my understanding is (and visual results
indicate) that using assumed_gamma of 2.2 or leaving it out entirely produces
the same rendered image (a .jpeg or Windows-specific .bmp image, with no
'embedded' gamma information.) That would be correct behavior, if I understand
POV's gamma documentation. Most problems with erratic color and 'washed-out'
appearance come from changing the assumed_gamma, so that it no longer matches
the rest of the set-up. The 'old' POV documentation, with its near-insistance
on using an assumed_gamma of 1.0, is misleading in that regard. (I believe that
the documentation concerns two things: for letting others render your scene file
on their own systems --although I still don't understand using assumed_gamma of
1.0 for that--and for rendering your own POV scene as a .png image, thus
embedding a necessary(?) assumed_gamma of 1.0 into it. I never use .png for my
own output, so I don't know for sure.)

Ken W.

Post a reply to this message

Kenneth wrote:

> The 'old' POV documentation, with its near-insistance
> on using an assumed_gamma of 1.0, is misleading in that regard.

There is nothing misleading and this "near-insistance" had and has
its good reasons. You should (re)read the list of changes for
POV 3.7 about gamma correction and assumed_gamma. An example why it
is a good idea to use assumed_gamma 1.0 with 3.6 is posted in p.b.i
(and this antialiasing issue has nothing to do with the fact that
the images are in PNG format, it just compresses this kind of images
very well)

-Ive

Post a reply to this message

Ive <"ive### [at] lilysoftorg"> wrote:
> Kenneth wrote:
>
> > The 'old' POV documentation, with its near-insistance
> > on using an assumed_gamma of 1.0, is misleading in that regard.
>
> There is nothing misleading and this "near-insistance" had and has
> its good reasons. You should (re)read the list of changes for
> POV 3.7 about gamma correction and assumed_gamma. An example why it
> is a good idea to use assumed_gamma 1.0 with 3.6 is posted in p.b.i
> (and this antialiasing issue has nothing to do with the fact that
> the images are in PNG format, it just compresses this kind of images
> very well)
>
> -Ive

Yes, I probably *should* re-read the 3.7 changes--always a good thing to
revisit-- although I will probably continue with my own gamma 'philosophy.' :-)

A long while ago, I posted a discussion about using assumed_gamma 1.0 vs. *other
values,' which elicited many arguments on both sides of the fence. (Gamma
correction has a 'long and venerable history' in the POV newsgroups!) In the
final analysis, my own choice of assumed_gamma came down to what my eyes tell
me, vs. what the POV documentation recommends. I could *still* be wrong about
it all, but IMO, using assumed_gamma 2.2 (on my PC) better 'matches' the visual
imagery I see from digital cameras, on the web, in Photoshop, etc. I *do*
understand that my choice goes against the 'physically correct' lighting
behavior of assumed_gamma 1.0--but I had to trust my eyes.

Ken W.

Post a reply to this message