>  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