Kalles Fraktaler 2.13

  • 90 Replies
  • 4133 Views

0 Members and 1 Guest are viewing this topic.

Offline claude

  • *
  • 3f
  • ******
  • Posts: 1272
    • mathr.co.uk
« on: March 30, 2018, 02:29:21 PM »
kf-2.13 available now from https://mathr.co.uk/kf/kf.html

Main bug/feature compared to kf-2.12 is derivative calculations for analytic DE.  Feature: it's way better than numerical DE. Bug: derivatives are still calculated even if you don't care about DE, plus some unfinished aspects.  So for this reason I'll probably release a few more in the 2.12 series with minor enhancements, at least until the 2.13 bugs/misfeatures are ironed out.


Linkback: https://fractalforums.org/kalles-fraktaler/15/kalles-fraktaler-2-13/1123/

Offline gerrit

  • *
  • 3f
  • ******
  • Posts: 1840
« Reply #1 on: March 31, 2018, 05:34:05 AM »
Something seems not right for this one: see ADE and NDE and SMB.
Those bands should not be there I think, maybe escape radius is messed up?

Added:
Open k2.13, load kfr, change to 1280 resolution gets the bug.

Open k2.13, change to 1280 resolution, load kfr,  is fine.
« Last Edit: March 31, 2018, 05:46:59 AM by gerrit »

Offline gerrit

  • *
  • 3f
  • ******
  • Posts: 1840
« Reply #2 on: April 01, 2018, 07:05:26 AM »
Attached location looks normal with NDE but white screen with ADE. Something to do with zoom depth E6700? Never seen this at lower depths.


Offline claude

  • *
  • 3f
  • ******
  • Posts: 1272
    • mathr.co.uk
« Reply #3 on: April 01, 2018, 01:15:57 PM »
Open k2.13, load kfr, change to 1280 resolution gets the bug.
Does pressing F5 to refresh fix it?  Looks like an incomplete render (grid artifacts)....

Something to do with zoom depth E6700?

Does forcing "use floatexp always" fix it?  Could be an issue with "scaled long double" (derivative) overflow perhaps.

Offline gerrit

  • *
  • 3f
  • ******
  • Posts: 1840
« Reply #4 on: April 01, 2018, 08:33:37 PM »
Does pressing F5 to refresh fix it?  Looks like an incomplete render (grid artifacts)....

Does forcing "use floatexp always" fix it?  Could be an issue with "scaled long double" (derivative) overflow perhaps.
I can't reproduce the first problem anymore after rebooting.

Yes second problem fixed by "use floatexp always".

Offline gerrit

  • *
  • 3f
  • ******
  • Posts: 1840
« Reply #5 on: April 02, 2018, 01:07:56 AM »
I'm getting some strange runtimes: with same settings 2.13 is faster than 2.12 despite having to calculate ADE.
And not just a little bit, up to 5X faster on some images!

Offline claude

  • *
  • 3f
  • ******
  • Posts: 1272
    • mathr.co.uk
« Reply #6 on: April 02, 2018, 02:58:11 PM »
up to 5X faster on some images!

good news!  no real clue why, though... this is probably down to the gerrit/knighty derivative-based glitch detection method, after pauldelbrot first-pass.  So fewer pixels will be recalculated as glitches.
« Last Edit: April 02, 2018, 04:59:06 PM by claude, Reason: remembered maybe why »

Offline gerrit

  • *
  • 3f
  • ******
  • Posts: 1840
« Reply #7 on: April 03, 2018, 05:43:18 AM »
Some comments on kf.txt:

> - non-responsive GUI when entering "simple" locations (eg -2.0 0.0, doesn't
> depend on zoom level) (reported by Foxxie)

Never seen this, works fine.

>- "iteration count resets to 1000" (reported by CFJH and gerrit)

Haven't seen that in a few releases.

>- "Save Settings" browser has .kfr extension instead of .kfs

Fixed.

>- default settings are best-quality by default

Seems using "guessing" with ADE sometimes causes more than just some small imperfections, resulting in completely corrupted image.

>- Laplacian numerical differences (suggested by gerrit)

I didn't suggest that really, but fine to have of course, but it doesn't look particularly good. Does it also adapt to jitter?

>- known bug: calculated even if not needed for colouring

Seems even if you want no DE at all it still boosts speed considerably to allow better glitch detection.
 

Offline claude

  • *
  • 3f
  • ******
  • Posts: 1272
    • mathr.co.uk
« Reply #8 on: April 03, 2018, 06:29:29 AM »
Thanks for this, I'll update it:

Some comments on kf.txt:

> - non-responsive GUI when entering "simple" locations (eg -2.0 0.0, doesn't
> depend on zoom level) (reported by Foxxie)

Never seen this, works fine.

Same here, but it was reported nonetheless.

Quote
>- "iteration count resets to 1000" (reported by CFJH and gerrit)

Haven't seen that in a few releases.

>- "Save Settings" browser has .kfr extension instead of .kfs

Fixed.

Good to know these two are fixed.

Quote
>- default settings are best-quality by default

Seems using "guessing" with ADE sometimes causes more than just some small imperfections, resulting in completely corrupted image.

Yes, that is true - sorry for not flagging it more prominently.  I still need to update the guessing code to interpolate the DE values, right now it just ignores the DE plane, meaning guessed pixels have bad DE (either 0, -1, or random values from whatever was left over last time, not sure what happens exactly).

Quote
>- Laplacian numerical differences (suggested by gerrit)

I didn't suggest that really, but fine to have of course, but it doesn't look particularly good. Does it also adapt to jitter?

Not adapted for jitter yet, but maybe easier to find a suitable method than the other gradients.

Quote
>- known bug: calculated even if not needed for colouring

Seems even if you want no DE at all it still boosts speed considerably to allow better glitch detection.
 

Interesting!  The improved glitch detection is only for Power 2 Mandelbrot.  So it may still be advantageous to add ability to disable derivatives if you don't want ADE for other formulas...

Offline gerrit

  • *
  • 3f
  • ******
  • Posts: 1840
« Reply #9 on: April 04, 2018, 05:57:19 AM »
The improved glitch detection is only for Power 2 Mandelbrot.  So it may still be advantageous to add ability to disable derivatives if you don't want ADE for other formulas...
From a few tests it seems you'd save maybe 10% in computation time, which doesn't seem worth any effort.
Implementing the improved glitch detector for the other formulas seems like a more worthwhile effort. Probably easy for the holomorphic ones.
Is anyone ever using all those weird formulas? I'd be into M-set other powers but most pressing thing to add is IMHO NR zooming for those.


Offline gerrit

  • *
  • 3f
  • ******
  • Posts: 1840
« Reply #10 on: April 07, 2018, 07:24:46 PM »
Once in a while I get this error (this time when changing colormap).
Clicking "ignore" and program continues normally.

Offline claude

  • *
  • 3f
  • ******
  • Posts: 1272
    • mathr.co.uk
« Reply #11 on: April 09, 2018, 02:07:19 PM »
From a few tests it seems you'd save maybe 10% in computation time, which doesn't seem worth any effort.
Implementing the improved glitch detector for the other formulas seems like a more worthwhile effort. Probably easy for the holomorphic ones.
Ok. I still haven't worked through it for the irregular formulas, I found the notation was a bit confusing in your post and I need to unpack it myself to understand it...

Quote
Is anyone ever using all those weird formulas? I'd be into M-set other powers but most pressing thing to add is IMHO NR zooming for those.
I have generatlized NR zoom in 'et', porting it to KF may be possible, but not a high priority for me right now...

Once in a while I get this error (this time when changing colormap).
Clicking "ignore" and program continues normally.
I think this is a race condition between colouring in one thread and parameters being changed in another thread, so the "impossible" can happen.  I should be able to fix this without too much trouble.  Thanks for the report!

Offline gerrit

  • *
  • 3f
  • ******
  • Posts: 1840
« Reply #12 on: April 18, 2018, 07:45:11 PM »
Peculiar bug an all versions (2.11.1 and up I checked) attached.
z2 has im(c)=0 exactly but is wrong, adding a tiny offset as in z1 and it renders correctly.


Offline claude

  • *
  • 3f
  • ******
  • Posts: 1272
    • mathr.co.uk
« Reply #13 on: April 18, 2018, 10:56:28 PM »
That could be caused by a glitch not being detected, I suppose?  When offset the reference would escape forcing details to the left to be recalculated.  What are the reference counts like?  Maybe the assumption that |Z| reference is large when the glitch occurs is wrong?  In KF threshold*|Z|^2 is stored with double precision only...

Offline gerrit

  • *
  • 3f
  • ******
  • Posts: 1840
« Reply #14 on: April 19, 2018, 12:44:38 AM »
Maybe, I think it's not worth investigating except out of curiosity as offsetting the image by a pixel fixes the problem.


xx
Kalles Fraktaler 2 + GMP

Started by claude on Kalles Fraktaler

232 Replies
9938 Views
Last post September 12, 2019, 10:27:53 PM
by claude
xx
Kalles Fraktaler 2.14

Started by claude on Kalles Fraktaler

111 Replies
4811 Views
Last post December 05, 2019, 11:18:18 PM
by CFJH
xx
Another version of Kalles Fraktaler?

Started by greentexas on Kalles Fraktaler

9 Replies
942 Views
Last post September 22, 2017, 02:59:16 PM
by greentexas
xx
Kalles Fraktaler Movie Maker64

Started by Bill Snowzell on Fractal movie gallery

0 Replies
228 Views
Last post February 01, 2018, 09:29:04 PM
by Bill Snowzell
question
Kalles Fraktaler tiled rendering

Started by Chronicler1701 on Kalles Fraktaler

5 Replies
313 Views
Last post September 06, 2018, 07:43:16 PM
by gerrit