On 3/5/22 02:49, jr wrote:
> "jr" <cre### [at] gmailcom> wrote:
> 
> forgot to say, using alpha.9945627 and most recent povr.
> 
> 
>> William F Pokorny <ano### [at] anonymousorg> wrote:
>>> ...
>>> I'm interested in the results you see from compare. I'm not a big
>>> imagemagick user.
> 
> same here, rarely need/use them, except 'identify'.  woke early, so made this.
> :-)
> 
> 
> regards, jr.

Somewhat busy with real life at the moment, but I did run your code 
yesterday evening and saw more or less what you just posted.

I won't be able to do more until later today at best, but the short of it:

- Where you set up sphere_sweeps with orthographic cameras (or rays say 
due parallel lights) is a worst case set up for sphere_sweeps because 
the initial ray-'virtual-surface' polynomial collapses to duplicate 
roots (at least it would always if we had infinite floating point accuracy).

- The above situation means you must use 'sturm' with the povr branch 
because povr's general solvers are all a lot more accurate(a) than the 
official POV-Ray solvers. :-) The detailed explanation is long...

- The color shift (the pink compare result) I'm pretty sure is due the 
povr fork restoring the sRGB block to png outputs. The sRGB block got 
dropped - due complicated reasons I forget at the moment - at some point 
during v3.71/v3.8 development. The sRGB png block is there in v3.7 png 
output and in recent povr(b) tarballs. My compares with netpbm - which 
default to bt709 gamma handling for both file outputs - show no color 
shift. There are other ways to test the png being missing being the 
reason for the pink 'compare(c,d)' result, but not done it and not sure 
I will.

Bill P.

(a) - The banding with linear sweeps (quadratic) comes from the povr 
default being the common quadratic solver which - like POV-Ray's version 
- has been hacked to return only one root on getting duplicate roots 
where it doesn't by numerical noise see or force two - and this happens 
in numerical bands with povr's more accurate quadratic solver. Where the 
less capable povr sturm solver used (povr's sturm off with >4 orders) we 
now get speckled results for similar, the solver is more accurate, 
reasons. (The duplicate roots are blinking in and out ray to ray)

(b) - Bring both your v3.8 and povr png files up in an editor and you'll 
see the text near the top 'sRGB' in povr (and v3.7) output. This test is 
missing in any more recent v3.8/v4.0 output.

(c) - Like the netpbm tooling there are probably ways to explicitly 
control gamma handling. Output and compare jpgs. Write linear output 
files and compare via linear gamma options...

(d) - Yes. Even if the sRGB block being there and not the 'reason' for 
the pink shift - how are we getting the grey-ish general background 
where both input images are completely black? My first guess is the 
actual pink/grey shift is a bug in 'compare' but, who knows. It might be 
some other reason like compare showing differences in value results as 
offsets from 50% grey or something, though the red differences within 
the sphere sweep I think right! (alpha channel assumptions in compare 
or?) No clue.

Post a reply to this message