On 3/1/22 07:55, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> ...
>> What particular commands and versions of TCL and Tcllib are you using?
> 
> (typed)
> 
> % set tcl_version
> 8.6
> % package require crc32
> % package require png
> % png::addComment foo.png theTag theValue
> 
> and using a 'tcllib1.18' (though mean to upgrade to 1.19).
> 

Thanks.

Forgot TCL breaks the patch level out... What does the shell command:

echo 'puts [info patchlevel];exit 0' | tclsh

give you?

> 
>> It's been maybe 4-5 years since I played in the tcl/png sandbox but, not
>> too long after tcl 8.6 was first released, I found the png support from
>> within tcl/tk/tcllib buggy. Supposing you are finding it better?
> 
> guess so, cannot recall any problem(s) with 'image' and 'photo' etc.
> 
> 
>> I was primarily trying to load/create/modify/save actual image channel
>> data but, I don't recall even the particular 'TCL' packages and commands
>> I tried at the moment...
> 
> fwiw 'df3util' can split PNGs into rgba (and stored in a DF3, but there's the
> 'export' command).
> 

Thanks for the reminder. At the time I was aiming for a set of new 
commands in my TCL SDL wrapper.

Aside: I found out at some point the netpbm pam RGBA format is, less the 
short pam header and the addition of a short DF3 header, an exactly DF3 
equivalent file layer/plane. This means you can create / manipulate DF3s 
quickly with that tool set too.

> hope to post a 'compare(1)' image in the next days, showing some/much difference
> for the sphere_sweep between 'povr' and stock POV-Ray.  will need to
> systematically try with 'sturm' and 'tolerance' etc first though.
> 

I'm interested in the results you see from compare. I'm not a big 
imagemagick user.

--- sphere_sweep...

The povr sphere_sweep is substantially different in implementation being 
one of the shapes which leans on the generic inbuilt solvers. I did a 
large amount of work on those solvers some years ago.

There are at least a dozen numerical and control issues in that shape 
alone in POV-Ray proper. Much fixed or made much better in povr - but 
issues remain. Ultimately, I believe the code for sphere_sweeps needs to 
be completely re-written!

With sphere_sweep 'tolerance' my recollection is it does nothing in povr 
because in POV-Ray proper results are unstable due - another half dozen 
reasons.

First up, being the sphere_sweep is one our shapes where transforms get 
flattened (removed) if possible to improve performance. However, you 
cannot always flatten depending upon the particular transforms. This 
means the 'numerical meaning' of the 'tolerance' values (also things 
like no_bump_scale) are not themselves stable depending upon user scene 
transformations. Yep, this might be why the tolerance value was brought 
out as a control originally.

...And sturm...

In official POV-Ray releases, across many shapes, you are not always 
truly turning the sturm based solver on and off!

IIRC. The sphere_sweep sturm is always on internally (the polynomial 
orders are beyond 4) - excepting linear sweeps where it's hard coded 
always off (an unfortunate choice).

There's a general issue in official POV-Ray where, for auxiliary 
internal polynomials (ie inside tests), POV-Ray isn't changing to a 
sturm solver in a way aligned with the mainstream ray-surface solvers 
for some shapes - and sphere_sweep is one. Probably done for better 
performance too or, maybe believing the fixed solvers are 'always' the 
better choice. In any case, mixing solver approaches is not the best for 
'numerical alignment.'

In general! With povr, sturm off always uses a fixed solver where 
polynomial order allows it. Where sturm on, povr's version of the sturm 
solver is always used or, if the order is >4 'sturm on' will sometimes - 
as with sphere_sweeps(1) - mean use a 'better' sturm based solver.

(1) IIRC. It's currently doing order reduction after each root is found.

The takeaway is sturm behavior in sphere_sweeps is mostly fixed in 
official POV-Ray. In povr 'sturm on' always means "use a better sturm 
based solver."

Encyclopedia sets worth of detail when you get into the solvers... My 
head spins round and round! :-(

Bill P.

Post a reply to this message