![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"jr" <cre### [at] gmail com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: William F Pokorny
Subject: Re: A quick povr branch micro normal image.
Date: 7 Mar 2022 07:42:58
Message: <6225fdd2$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
William F Pokorny <ano### [at] anonymous org> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
hi,
William F Pokorny <ano### [at] anonymous org> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
hi,
William F Pokorny <ano### [at] anonymous org> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: William F Pokorny
Subject: Re: A quick povr branch micro normal image.
Date: 16 Mar 2022 17:25:38
Message: <623255d2$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 3/13/22 04:34, jr wrote:
> hi,
>
> William F Pokorny <ano### [at] anonymous org> 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.
>
This with the Real_Time_Capture=true|false (+-rtc) capability for the
real time rendering mode (.pfm output) or with traditional animation?
Is the fail easily repeatable?
Bill P.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
hi,
William F Pokorny <ano### [at] anonymous org> wrote:
> This with the Real_Time_Capture=true|false (+-rtc) capability for the
> real time rendering mode (.pfm output) or with traditional animation?
regular animation, running from an ini.
> Is the fail easily repeatable?
not sure, happened late in the animation[*], had no stomach to try + repeat,
sorry. the code in question is the 'usaf' animation posted same time (March
13th).
[*] as I wrote, I was v surprised because 'povr' run the (shorter) test segments
without hassle, and fast.
regards, jr.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: William F Pokorny
Subject: Re: A quick povr branch micro normal image.
Date: 17 Mar 2022 06:54:22
Message: <6233135e$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 3/17/22 02:04, jr wrote:
>> Is the fail easily repeatable?
> not sure, happened late in the animation[*], had no stomach to try + repeat,
> sorry. the code in question is the 'usaf' animation posted same time (March
> 13th).
No problem. The flaky issues / bugs are always the hard ones to run down.
Did you continue the animation successfully starting from frame 3048?
Or, is it an animation where each frame depends on information from
previous frames(s) such that starting at frame 3048 not possible?
I might try running valgrind looking for memory leaks with your
particular animation as a shot in the dark. But, that's not something
I'll get to for a while.
Wondering too if the regular animation mechanisms can develop the memory
bubbles seen with RTR. My guess is the frame rates with regular
animation always too slow for it to happen - and as a light user of
regular animation I've never noticed a (povms) memory bubble effect but,
never gone looking for it, so who knows.
Bill P.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
hi,
William F Pokorny <ano### [at] anonymous org> wrote:
> On 3/17/22 02:04, jr wrote:
> >> Is the fail easily repeatable?
> > not sure, ...
> No problem. The flaky issues / bugs are always the hard ones to run down.
took copy of code posted + tried again, several times, every time the run (now)
crashes at frame 2800; have tried to remember which if any changes I made, but
can only think of quality + dimensions in ini file. attached excerpt from
'povr' build-log, libraries in use, and the animation state at the time.
> Did you continue the animation successfully starting from frame 3048?
> Or, is it an animation where each frame depends on information from
> previous frames(s) such that starting at frame 3048 not possible?
no, did not. simply switched to POV-Ray proper, wanted "it" (the anim) out of
my hair :-).
> I might try running valgrind looking for memory leaks with your
> particular animation as a shot in the dark. But, that's not something
> I'll get to for a while.
running with 480x360 and aa threshold .3 should do.
> Wondering too if the regular animation mechanisms can develop the memory
> bubbles seen with RTR. My guess is the frame rates with regular
> animation always too slow for it to happen - and as a light user of
> regular animation I've never noticed a (povms) memory bubble effect but,
> never gone looking for it, so who knows.
sorry, no ideas at all. (it's as if the 'tmp_' dictionary is not updated in
time for next access)
regards, jr.
Post a reply to this message
Attachments:
Download 'frame_2800.txt' (4 KB)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: William F Pokorny
Subject: Re: A quick povr branch micro normal image.
Date: 17 Mar 2022 17:41:22
Message: <6233ab02$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On 3/17/22 11:19, jr wrote:
> Degenerate cylinder, base point = apex point.
> Fatal error in parser: Uncategorized error.
> Render failed
The three lines above come from a test during parsing while additional
internal data for the cone/cylinder is being done using a function
within cone.cpp. The tests is finding that the base and apex are <1e-10
(a) apart - and throwing an error rather than issuing a parse error via
message(b). The same code exists in POV-Ray proper v3.7 onward and povr
(c).
(a) - The cone code hasn't been reworked as yet in povr to remove
'EPSILON' use. The test value there should be ~4.4e-8 or povr's
gkMinIsectDepthReturned. FWIW.
(b) - The particular test could be done completely inside the parser I
think. Not sure why it's done in the cone/cylinder shape code.
(c) - There has long been a TODO note in the code suggesting that
particular throw should be a 'possible error' instead - with execution
continuing. I don't agree with the TODO note. Where base and apex are
too close, it's an error in cone/cylinder specification.
---
The puzzle for me at the moment is I have no idea why those parsed base
and apex vectors would be different between any versions of POV-Ray.
Best guess. It's due some indirect difference where I've moved to
'double' from 'float' in povr and the previous 'snap' of the vector
components to floats rounded length 'up' in a way not tripping the
throw. In other words, values previously rounded such that the base to
apex length is 'long enough'.
Bill P.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |