compiling Kalles Fraktaler with mingw

[Kalles Fraktaler]

Hello claude.

I found an issue and was able to store it, so that you can have a look.
The approximation yields no skipped iterations in version 2.12.3

When I try it in the second latest version I have on my machine, build at 22nd August, 91029 iterations are skipped

[claude]

The approximation yields no skipped iterations in version 2.12.3  When I try it in the second latest version I have on my machine, build at 22nd August, 91029 iterations are skipped

I think I know what the issue is caused by - there are 9 probe points instead of 8, with the extra one near the center.  This changed when I was experimenting with many more probe points to reduce overskipping in some locations (but that just caused underskipping instead).  I can try to fix it tomorrow (not at home right now).  Thanks for the bug report!

[CFJH]

Hallo,
I've downloaded kf from here: https://mathr.co.uk/kf/kf.html
running version 2.12.3.

Now i am makeinmg a zoomout-sequence starting from file Z000006.kfr (see attachment). Around zoomfactor E600 I am getting a coloring error. It seems, that there is a "jump" in the colormapping (see attachment kf_error.jpg).

How can I solve this ?

ps: I am running kf on Linux with wine (exists there a native Linux-version of kf).

Jürgen

[Kalles Fraktaler]

Hallo,
I've downloaded kf from here: https://mathr.co.uk/kf/kf.html
running version 2.12.3.

Now i am makeinmg a zoomout-sequence starting from file Z000006.kfr (see attachment). Around zoomfactor E600 I am getting a coloring error. It seems, that there is a "jump" in the colormapping (see attachment kf_error.jpg).

How can I solve this ?

ps: I am running kf on Linux with wine (exists there a native Linux-version of kf).

Jürgen

Hello Jürgen

Unfortunately this is a common issue that the series approximation makes too many iterations to be skipped.
I have described this situation here (as Glitch type 1): http://www.chillheimer.de/kallesfraktaler/tutorial.htm

[claude]

ps: I am running kf on Linux with wine (exists there a native Linux-version of kf).

KF2 will always be Windows-only, the whole thing (GUI, threads, ...) is based around Windows APIs.  But it works fine in WINE (after working around some WINE issues with multithreading and bitmap size) so that's ok I think.

[claude]

I think I know what the issue is caused by - there are 9 probe points instead of 8, with the extra one near the center.

This wasn't it   Debugging continues...

[CFJH]

Hello Jürgen

Unfortunately this is a common issue that the series approximation makes too many iterations to be skipped.
I have described this situation here (as Glitch type 1): http://www.chillheimer.de/kallesfraktaler/tutorial.htm

I've tested the "no approximation" issue, but it doesn't work. The colors are still different/false. The images are absolute identically, independent the option with/no approximation. This continues on all following images (see attachment above).

[Kalles Fraktaler]

Yes, you are right.
This seems to be an issue with the transmission from double to long double, which happens at e600.
The issue seems to have been introduced in the build from 2017-07-14 and does not occur in earlier versions.

[claude]

How can I solve this ?

I did some bisection of versions with your test file (thanks for attaching it):
kf-2.11.1+gmp.20170508 is the last version with good output
kf-2.11.1+gmp.20170703 crashes/hangs on loading the file (some calculations seem to happen but GUI is frozen)
kf-2.11.1+gmp.20170710 is the first version with bad output

$ git diff --stat kf-2.11.1+gmp.20170508 kf-2.11.1+gmp.20170710
 119 files changed, 5198 insertions(+), 64974 deletions(-)
Very big changes there, between deleting old arbitrary precision floating point implementation and making formulas be preprocessed from XML.  Will be hard to find the probably small change that caused the bug...

The current issue is that the colours for "long double" are wrong.  See attached - there will probably be another glitch around e4800 (not sure of the exact threshold) where it switches between "long double" and "floatexp".  Looking at the palette, with iterdiv 0.03, setting offset to 993 = 1024*(1.0-0.03) makes it look better with "long double", but that makes the other types look wrong again.  Still, it's a hint as to what might be wrong internally...

So there are some possible solutions:
* use 20170508 version with good output (slower, misses some features that might not be important)
* with 2.13.3 version, if your zoom starts before e4800 (ie, it never uses floatexp), you could check "use long double always" in the "special" menu, it will be slower and have wrong colours for the whole zoom out sequence, but no visible glitch
* with 2.13.3 version, if your zoom starts deeper than e4800 (ie, it uses floatexp), you could check "use floatexp always" in the "special" menu, it will be a lot slower but have correct colours for the whole zoom out sequence, with no visible glitch
* with 2.13.3 version, adjust the palette with offset 993, render using "long double always" until past the glitch, reset the palette offset and resume without "long double always".  BUT this might just be a cosmetic fix that doesn't work with the movie makers using the kfb data directly.
* wait for 2.12.4 version (hopefully this week) which fixes the bug (hopefully, if I can find exactly what is causing the error)

There was this code in the long double perturbation post processing, deleting two lines solves the problem.  I don't know why that code was there...

Code:

-               if (m_nPixels[x][y]<m_nMaxIter)
-                       m_nPixels[x][y] += 1;

[CFJH]

Thanks for the info.

I've tested some versions from https://mathr.co.uk/kf/kf.html with the following result:
version         result
20170710    still buggy
20170703    crash after loading the .kfr-file
20160508    ok

[Kalles Fraktaler]

I did some bisection of versions with your test file (thanks for attaching it):
kf-2.11.1+gmp.20170508 is the last version with good output
kf-2.11.1+gmp.20170703 crashes/hangs on loading the file (some calculations seem to happen but GUI is frozen)
kf-2.11.1+gmp.20170710 is the first version with bad output

$ git diff --stat kf-2.11.1+gmp.20170508 kf-2.11.1+gmp.20170710
 119 files changed, 5198 insertions(+), 64974 deletions(-)
Very big changes there, between deleting old arbitrary precision floating point implementation and making formulas be preprocessed from XML.  Will be hard to find the probably small change that caused the bug...

The current issue is that the colours for "long double" are wrong.  See attached - there will probably be another glitch around e4800 (not sure of the exact threshold) where it switches between "long double" and "floatexp".  Looking at the palette, with iterdiv 0.03, setting offset to 993 = 1024*(1.0-0.03) makes it look better with "long double", but that makes the other types look wrong again.  Still, it's a hint as to what might be wrong internally...

So there are some possible solutions:
* use 20170508 version with good output (slower, misses some features that might not be important)
* with 2.13.3 version, if your zoom starts before e4800 (ie, it never uses floatexp), you could check "use long double always" in the "special" menu, it will be slower and have wrong colours for the whole zoom out sequence, but no visible glitch
* with 2.13.3 version, if your zoom starts deeper than e4800 (ie, it uses floatexp), you could check "use floatexp always" in the "special" menu, it will be a lot slower but have correct colours for the whole zoom out sequence, with no visible glitch
* with 2.13.3 version, adjust the palette with offset 993, render using "long double always" until past the glitch, reset the palette offset and resume without "long double always".  BUT this might just be a cosmetic fix that doesn't work with the movie makers using the kfb data directly.
* wait for 2.12.4 version (hopefully this week) which fixes the bug (hopefully, if I can find exactly what is causing the error)

There was this code in the long double perturbation post processing, deleting two lines solves the problem.  I don't know why that code was there...

Code:

-               if (m_nPixels[x][y]<m_nMaxIter)
-                       m_nPixels[x][y] += 1;

I was just going to write that I had had an issue with one iteration in long double in that gcc dll...

[claude]

The approximation yields no skipped iterations in version 2.12.3  When I try it in the second latest version I have on my machine, build at 22nd August, 91029 iterations are skipped

I found the issue.  0.0 was not being handled correctly in floatexp.h.  For example, setting xr = xi = 0 really gave xr = xi = 1e-308 or so, which is significantly different from 0.0 at the zoom depth of that location.  I made align() set the exponent to -SOMETHINGBIG when val is 0.0, and added more align() everywhere (instead of _ALIGN_(val, exp)).

With these fixes (to be released in 2.12.4 this week) your location skips 91029 iterations with the primary reference, as before.

The extra checks may make kf slightly slower, but that's better than being fast and wrong!

[claude]

kf-2.12.4 released, download available at the homepage https://mathr.co.uk/kf/kf.html

changes since 2.12.3:
- "glitch low tolerance" checkbox that can be enabled to detect glitches more aggressively (enabling it allows "Olbaid-ST-023.kfr" to render correctly, but taking 16x longer than with it disabled) (incorrect render reported by Kalles Fraktaler)
- updated program icon with transparent background and large version, and use it for child windows too
- long double off-by-one bug fixed (incorrect render reported by CFJH)
- floatexp implementation bug fixes (0.0 was implemented incorrectly) (caused a series approximation underskipping failure that was reported by Kalles Fraktaler)
- fix distance colouring grid artifacts with small zoom size by disabling "reuse center" when zoom size is not an integer (reported by gerrit)
- fix some iteration band edge artifacts (with external postprocessing of kfb map files) by increasing the smooth bailout radius from 100 to 10000 (reported by gerrit)
- ensure added references fix their corresponding pixel (suggested by Pauldelbrot) (prevents loop in auto solve glitches whereby a reference was repeatedly being added at the same location without progress being made)
- disabled "guessing" (was causing occasional randomly bright single pixels at low zoom levels, possibly a race condition?)
- build against an installed libjpeg instead of each time after clean
- fix broken complex formula reference calculations
- fix compilation warnings (now almost clean with -Wall -Wextra)
- compile as C++17 (should also still work as C++11 and C++14)
- delete bitrotten code paths for SetEvent()-based multithreading
- delete unused thread affinity setting code
- parameter data is saved as comment in image files (both PNG and JPEG)
- can load parameters from image file comments (both PNG and JPEG)
- delete obsolete VS build system
- fix "infinite waves" colouring (reported by gerrit)

[Olbaid-st]

Hi Claude.
Thank you for a great update!
I re-rendered Olbaid-ST-023 with "Glitch low tolerance" on.
https://olbaid-st.deviantart.com/art/Deep-Mandelbrot-Set-023-10-1086-695492737

Most glitches have been removed, but fine ones are still left.
The attched image compares the rendering result of Kf 2.12.4 and MandelMachine.
I have marked conspicuous ones.

[claude]

Thanks for testing!

Most glitches have been removed, but fine ones are still left.

I think this is caused by not enough references being used (the default limit is 69, your location needs more than that even at small image sizes).
You should increase the limit in the iterations dialog (but this restarts rendering, unfortunately - I will add it to the todo list to make it carry on where it left off).
The limit for the limit is currently 10000 (used to be 199), it should be possible with some code restructuring to make it truly unlimited.
My old slow computer is still rendering your location at 8192x8192, around 7000 references so far, over 5 days of calculations.
I attached a cropped downscaled portion of the image, as you can see there are no visible glitches.

To export a PNG while it is still rendering (normally it waits for the image to finish rendering completely) I employ a small workaround:
* save a map file to 00001_1.kfb, save the location kfr to the same directory - this fakes a zoom out sequence
* open another separate instance of kf.exe
* in the new kf.exe load the location kfr with examine zoom sequence
* in the new kf.exe now you can adjust colours if necessary, and Save PNG works immediately