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