hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> I'm interested in the results you see from compare. I'm not a big
> imagemagick user.

unarchiving the attached will create a (sub)directory 'wfp' (;-)) with a bunch
of files.  check the assumptions made (eg povray == stock POV-Ray) in the
'run-sh' file, then run that, ie 'sh run_sh', to render the images.  the compare
output will be in sub-dir 'c'.  cheers.


regards, jr.

Post a reply to this message

Attachments:
Download 'sweep.tar.xz.dat' (2 KB)

"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.

Post a reply to this message

Attachments:
Download 'wfp_cmp.png' (69 KB)

Preview of image 'wfp_cmp.png'

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

On 3/5/22 05:45, William F Pokorny wrote:
> (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.

OK. Still busy with other things, but had the bright idea to compare an 
image with itself and see what 'compare' does when images match. It's 
not doing a strict difference compare on the channel values (as you 
probably know). In other words, it always creates a faded image where 
things compare.

Further figured out it's using a high light color where things don't 
compare (to some threshold maybe? Per channel? Grey Composite?) and this 
happens to default to red. This why the missing red differences are 
showing up as I happen to expect the channel differences to show up on a 
channel difference compare.

So, compare fine for what it does. In fact, it looks to have some cool 
options and relatively easy defaults. It just isn't doing what I 
expected for image comparisons.

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 3/5/22 05:45, William F Pokorny wrote:
> > (d) - Yes. Even if the sRGB block being there and not the 'reason'

if you ever recall why, please tell.  now that I know about it, I do wonder what
the rationale/potential benefit is when the chunk is not written.


> > ...
> So, compare fine for what it does. In fact, it looks to have some cool
> options and relatively easy defaults. It just isn't doing what I
> expected for image comparisons.

(sorry about red-red colour clash)  the excellent documentation
('/usr/doc/ImageMagick-6/www/' on my box) uses '#rrggbb' notation but you can
use the the X ('rgb.txt') colour names (like!).  re the faded image, if you
supply both lowlight and highlight colour options only the actual differences
show.

somewhat unrelated, I cannot understand why the difference in Y-axis translates,
is this a POV-Ray bug?  (attached, thank you)


regards, jr.

Post a reply to this message

Attachments:
Download 'xlates.tar.xz.dat' (2 KB)

"jr" <cre### [at] gmailcom> wrote:
> ...
> somewhat unrelated, I cannot understand why the difference in Y-axis translates,
> is this a POV-Ray bug?  (attached, thank you)

uh, oh, belay that..  found my thinking cap.  :-)


regards, jr.

Post a reply to this message

On 3/6/22 08:35, jr wrote:
> if you ever recall why, please tell.  now that I know about it, I do wonder what
> the rationale/potential benefit is when the chunk is not written.

OK. Found my related debugging newsgroup post.

Much more detail on the v3.8/v4.0 sRGB block issue being written nor not 
can be found in a Mar 20, 2021 post to povray.beta-test. "File png/ppm 
gamma issues. v3.8." See:

http://news.povray.org/povray.beta-test/thread/%3C60563168%241%40news.povray.org%3E/

or

Message: <60563168$1@news.povray.org>

The thread started after questions from ingo related to pgm/ppm file 
output. I stumbled across the png sRGB block issue during that work. 
Look for "---  png gamma issue.' for the parts of the original post 
related to png input/output.

The bug amounts to POV-Ray not being consistent with 'itself' with 
respect to png sRGB handling.

Looks like in reading the thread again I never did the detailed work to 
figure out what all changed to cause the sRGB block to be dropped on 
default writes though 'srgb' is our default output/input png gamma 
handling profile.

I'd spent many days understanding what was happening in detail and 
didn't want to spend hours to days more trying to run down the commit(s) 
where the post v3.7 srgb png output file gamma handling broke. I just 
fixed the issue - which explains why I couldn't remember the detailed 
causes(a)!

(a) This time it might not have been my old failing brain! Of course, I 
didn't remember I hadn't dug enough to determine exactly how we got into 
the buggy state... ;-)

I know clipka worked quite a bit on the image file handling code over 
years while working toward v3.71/v3.8(v4.0). It was likely broken 
sometime during those changes.

Aside: Because broken v3.71/v3.8/v4.0 versions do still write a gamma 
2.2 chunk, the differences visually be will be small / hard to 'see' - 
they're at the dark end. This probably why the bug went years not 
getting picked up. It's one of those insidious subtle bugs that cause 
confusing / hair pulling results when they do bite.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> Aside: Because broken v3.71/v3.8/v4.0 versions do still write a gamma
> 2.2 chunk, the differences visually be will be small / hard to 'see' -
> they're at the dark end. This probably why the bug went years not
> getting picked up. It's one of those insidious subtle bugs that cause
> confusing / hair pulling results when they do bite.

Interesting.

Do you think there's a shell command that will output some unique result to
distinguish between the two types of gamma encoded png files?

If there is, maybe someone can demonstrate how to run a pre-parse/render command
to write that to a file, and then have a macro parse that and set the png read
parameters to properly/consistently adapt to however any given file is written?
(perhaps sending a message to the debug stream to ID which gamma type the file
is...)

I see that as being the best workaround for the time being.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 3/6/22 08:35, jr wrote:
> > if you ever recall why, ...
>
> OK. Found my related debugging newsgroup post.
>
> Much more detail on the v3.8/v4.0 sRGB block issue being written nor not
> can be found in a Mar 20, 2021 post to povray.beta-test. "File png/ppm
> gamma issues. v3.8." See:
> [snip]

thanks (very much).  so recent, yet, I've no memory of reading the thread.  :-(

> ...
> Aside: Because broken v3.71/v3.8/v4.0 versions do still write a gamma
> 2.2 chunk, the differences visually be will be small / hard to 'see' -
> they're at the dark end. This probably why the bug went years not
> getting picked up. It's one of those insidious subtle bugs that cause
> confusing / hair pulling results when they do bite.

guessing that you "look closer" than I do.  also, I "misuse" gamma perhaps,
mixing sRGB light_source and rgb[ft] colours routinely, bad either the result is
ok-ish or my eyes are not up to it (anymore) :-).


regards, jr.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ... It's one of those insidious subtle bugs that cause
> confusing / hair pulling results when they do bite.

may have run into one those with 'povr' yesterday.  been using it while playing
with the USaF (see p.b.a) code since it's quicker to render.  all ok for the 500
frame tests, but when I went to do a "final" render, it crashed
("uncategorized", from memory) at the 3048th frame.  (sorry, bearer of bad news
and all that)


regards, jr.

Post a reply to this message