And lo on Wed, 07 Jul 2004 16:14:53 -0500, Christopher James Huff  
<cja### [at] earthlinknet> did spake, saying:

> In article <opsaret2miefp2ch@news.povray.org>,
>  "Phil Cook" <phi### [at] nospamdeckingdealscouk> wrote:
>
>> Well commenting out assumed_gamma produces a darker image on the 'gate'
>> with no Display_Gamma set, so default gamma correction of 2.2 is in use.
>
> No, gamma correction is off by default. (At least, it's supposed to be.)
> It gets turned on when you include assumed_gamma in the global settings.

Yes sorry quite right.

>> Just to check this I changed the two planes in "Magic Gate2.pov" to the
>> same colour as that in "Magic Gate1.pov" and ran it both ways, without
>> assumed_gamma produces a noticeable difference.
>> I've posted a tiny file in p.b.images to show the differences.
>
> Weird. If you want the rendered image to appear the same as the original
> map, you obviously don't want any gamma correction to be done...the
> corrected version won't be the same. Your image doesn't show the
> original map, so I can't compare...but the fact that it shows up
> differently from the surrounding scene, which should be the same color
> pre-correction, is very odd.

Which is what I thought both images should have either none or the same  
correction applied

> What formats are you using? It may be an artifact of however POV and
> your other image software handles gamma values in PNG images. You should
> get the effect you want if you render the map without an assumed_gamma
> value, and the final image with assumed_gamma 1.

Magic Gate2:PNG read by Magic Gate1 with again PNG output that's runnng  
both files with assumed gamma 1. That's interesting, running MG2 with  
gamma 1 and MG1 *without* matches fine, reversing it is still darker.

So to summarise:

MG1 without gamma, MG2 without gamma: MG2 darker image within MG1
MG1 with gamma, MG2 without gamma: MG2 darker image within MG1
MG1 without gamma, MG2 with gamma: Match colours
MG1 with gamma, MG2 with gamma: Match colours.

Okay might have it switched to using bmp instead of png:

MG1 without gamma, MG2 without gamma: Match colours
MG1 with gamma, MG2 without gamma: Match colours
MG1 without gamma, MG2 with gamma: MG2 lighter image within MG1
MG1 with gamma, MG2 with gamma: MG2 lighter image within MG1.

What fun! Oh well I've got it to match so I'm not too fussed still  
interesting.

>> > Anyway, in addition to setting ambient to 1, you should set diffuse to
>> > 0, so light from scene illumination won't wash out the image.
>>
>> diffuse 0 doesn't seem to make a difference but of course might once I
>> start changing the landscape.
>
> Try shining a bright light on the gate.

Well once I start to work on the landscape I'll see how it goes.

--
Phil Cook

-- 
All thoughts and comments are my own unless otherwise stated and I am  
happy to be proven wrong.

Post a reply to this message

In article <opsas96dogefp2ch@news.povray.org>,
 "Phil Cook" <phi### [at] nospamdeckingdealscouk> wrote:

> MG1 without gamma, MG2 without gamma: MG2 darker image within MG1
> MG1 with gamma, MG2 without gamma: MG2 darker image within MG1
> MG1 without gamma, MG2 with gamma: Match colours
> MG1 with gamma, MG2 with gamma: Match colours.

I think I see what's going on...POV writes the gamma value to the PNG 
file and applies it to the read files, whether gamma correction is used 
or not. Also, the value it writes is 1.0/opts.DisplayGamma, which I'm 
pretty sure is not what it should write...I think opts.GammaFactor 
(assumed_gamma/display_gamma) would work better, but I'll have to look 
into it further.

Also, it appears to be doing gamma correction within pnglib, which only 
uses limited-precision fixed point color values. I'm pretty sure it 
would be better to do it on the native floating point colors.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

And lo on Thu, 08 Jul 2004 09:20:57 -0500, Christopher James Huff  
<cja### [at] earthlinknet> did spake, saying:

> In article <opsas96dogefp2ch@news.povray.org>,
>  "Phil Cook" <phi### [at] nospamdeckingdealscouk> wrote:
>
>> MG1 without gamma, MG2 without gamma: MG2 darker image within MG1
>> MG1 with gamma, MG2 without gamma: MG2 darker image within MG1
>> MG1 without gamma, MG2 with gamma: Match colours
>> MG1 with gamma, MG2 with gamma: Match colours.
>
> I think I see what's going on...POV writes the gamma value to the PNG
> file and applies it to the read files, whether gamma correction is used
> or not. Also, the value it writes is 1.0/opts.DisplayGamma, which I'm
> pretty sure is not what it should write...I think opts.GammaFactor
> (assumed_gamma/display_gamma) would work better, but I'll have to look
> into it further.
>
> Also, it appears to be doing gamma correction within pnglib, which only
> uses limited-precision fixed point color values. I'm pretty sure it
> would be better to do it on the native floating point colors.

Ah well heading off into unknown terrority for me :)

After much head-racking I've discovered the problem with making the magic  
gate square up to the objects behind it, perspective! So darn simple if I  
rotate the gate to always face the camera than the objects square up, if I  
don't then the edge furthest from me is subject to perspective and narrows  
meaning that although one side might match the other never will; duh to  
me. I can think of one to cheat this so I'm going to have a fiddle and see  
what happens.

--
Phil Cook

-- 
All thoughts and comments are my own unless otherwise stated and I am  
happy to be proven wrong.

Post a reply to this message