Kalles Fraktaler 2

[ellarien]

I hate to be the bearer of bad news, but something doesn't seem right. I did a zoom-out with v2.4 and got glitches in fairly simple cases that I wouldn't have expected (top). Sure enough, the glitches got auto-fixed when using the previous version (bottom).
(Zoom level 3.82e140, but that's not the only case.)

[Kalles Fraktaler]

I hate to be the bearer of bad news, but something doesn't seem right. I did a zoom-out with v2.4 and got glitches in fairly simple cases that I wouldn't have expected (top). Sure enough, the glitches got auto-fixed when using the previous version (bottom).
(Zoom level 3.82e140, but that's not the only case.)

Thanks a lot.
2.4 replaced the glitch detection completely but since the location from hapf in the other thread I have already considered a combination.
So there will be a new version soon
Again, thanks for testing.

[Kalles Fraktaler]

I have made a new version, Kalles Fraktaler 2.4.1
It is now using a combination of Pauldelbrot's glitch detection and my own color-area detection.

Any location that is not handled is not bad news, since it will make me able to improve KF

[SeryZone]

I have made a new version, Kalles Fraktaler 2.4.1
It is now using a combination of Pauldelbrot's glitch detection and my own color-area detection.

Any location that is not handled is not bad news, since it will make me able to improve KF

And I can't zoom my e8000 location again

[Kalles Fraktaler]

And I can't zoom my e8000 location again

Oh no... I should have tested also your location.

But guess what, there's a version 2.4.2 now with this fixed.
Thank for your notice

[panzerboy]

I seem to be getting visible frames using 2.4.2 (64 bit).

<a href="http://www.youtube.com/v/_12DlRDID7M&rel=1&fs=1&hd=1" target="_blank">http://www.youtube.com/v/_12DlRDID7M&rel=1&fs=1&hd=1</a>

I see rectangular "frames" at ...
1:31 1.87e050
1:43 9.8e055
2:16 4.41e071
2:36 4.74e080
2:48 1.24e086
2:56 6.36e088
2:58 2.54e089
3:00 2.03e090
3:16 2.13e096
3:22 5.46e098
3:38 5.73e104
3:46 2.93e107
4:02 7.69e112
4:05 6.15e113
4:07 2.46e114
4:24 6.45e119

I've attached the first visible frame as a picture below.
Its created from the saved JPGs, shrinking 00285_1.49e051 and overlaying it on 00286_7.48e050 to show the discontinuity.
Examining the zoom sequence and mousing over the top left corner (0,0) of 285_1.49e51 gave a slightly different  i:3759 s:66 compared position (320,180) of 286_748e50 i:3758 s:66.
Perhaps there is a difference in the iteration and smoothing values between frames?
I could upload the 2 kfb files to my mediafire account if you'd like to inspect (uploading all 12.4Gb would take forever and be over 1/2 my Internet cap).
I've also attached the kfr and kmm files needed to re-create this zoom, should you wish.
(nice palette in the .kfr, created solely with the Set Colors dialog using the L wave on an 8x8 colour combo)

[SeryZone]

Yes, I have some problem!

[Kalles Fraktaler]

Thanks panzerboy and SeryZone.
Yes, i have seen that myself and mentioned it before.

Even though the high bailout makes beautiful smooth coloring and actually makes it easier to identify glitches automatically, it can produce slightly different colors on "empty" areas for different reference points.

Very annoying... I am wondering if any of the others programming perturbation (Botond, pauldelbrot, hapf) are experiencing the same?

Did you changed the main reference on that frame?
To solve this - never use the set main reference function when solving glitches manually.

If not, hmm... Then I currently do not know. Would be sad if I had to recommend you to only use bailout=2 when making movies...

[Kalles Fraktaler]

I think I found a solution for this, or, a workaround.
The reference parameters needs to be stored and not calculated between frames, since the empty areas are so sensitive with high bailout.
I just want to test it before a upload a new version.
Sorry for the time wasted on glitchy renders. KF is still experimental
I think your colors were beautiful!

[Kalles Fraktaler]

And no, my thought about this did not solve this problem

The only way currently to make flawless movies with high bailout smooth coloring is to use the "Reuse reference" function to create all frames from one reference, and then correct all glitches manually with the "Examine Zoom Sequence" function...

[Pauldelbrot]

Thanks panzerboy and SeryZone.
Yes, i have seen that myself and mentioned it before.

Even though the high bailout makes beautiful smooth coloring and actually makes it easier to identify glitches automatically, it can produce slightly different colors on "empty" areas for different reference points.

Very annoying... I am wondering if any of the others programming perturbation (Botond, pauldelbrot, hapf) are experiencing the same?

Nanoscope does not have that problem. I even examined a region at the boundary between where two different reference points were used looking for even the subtlest seams, with a proverbial magnifying glass, and could not see the boundary.

Nanoscope does two things specially, though, that might matter here:

1. It computes reference points with an exceedingly high bailout of one googol (10¹⁰⁰).

2. The bailouts I've been doing test renders and other work with tend to be either 10⁵ or 10⁷. I think I read somewhere here than you were using lower bailouts, around 10²-10³. Those cause curves of constant smooth iterations to have big enough deviations from exact equipotential curves as to potentially induce distortions that don't noticeably mar the smoothing but do differ visibly when different reference points are used.

Also, if KF is checking the magnitude of delta rather than the magnitude of (ref pt plus delta) for bailout, the discrepancy might impact things. I found a way to optimize the delta calculations that calculates (ref pt plus delta) incidentally along the way, used for both enhanced glitch checking and bailout tests.

[Kalles Fraktaler]

2. The bailouts I've been doing test renders and other work with tend to be either 10⁵ or 10⁷. I think I read somewhere here than you were using lower bailouts, around 10²-10³. Those cause curves of constant smooth iterations to have big enough deviations from exact equipotential curves as to potentially induce distortions that don't noticeably mar the smoothing but do differ visibly when different reference points are used.

Thanks Paul, this is exactly the information I need
Maybe this explains why mandel machine stops at 2^1900 already since I use double to e600 which is ok with my 10² bailout. I will try a higher bailout which probably require this limit to be decreased.

[Botond Kósa]

Maybe this explains why mandel machine stops at 2^1900 already since I use double to e600 which is ok with my 10² bailout. I will try a higher bailout which probably require this limit to be decreased.

The bailout value used in Mandel Machine is only 32, so the bailout criteria is: re²+im²>1024. (I am not sure if the 10⁵, 10⁷ and 10¹⁰⁰ values mentioned by Pauldebrot are bailout or bailout squared.) In order to speed up the calculation, the bailout criteria is evaluated in every 4th iteration only, so the absolute value of the orbit can be in the range of 2⁵ to over 2⁸⁰. I experienced no noticeable glitches so far with this method.

BTW, Kalle's guess was correct, the zoom limit of 1900 in MM is also caused by this. Evaluating bailout in every iteration allows me to zoom up to 2000, but with the current method the orbit can grow beyond 10³⁰⁸ above 1900, causing an overflow to infinity and corrupting the image.

[Pauldelbrot]

The bailout value used in Mandel Machine is only 32, so the bailout criteria is: re²+im²>1024. (I am not sure if the 10⁵, 10⁷ and 10¹⁰⁰ values mentioned by Pauldebrot are bailout or bailout squared.) In order to speed up the calculation, the bailout criteria is evaluated in every 4th iteration only, so the absolute value of the orbit can be in the range of 2⁵ to over 2⁸⁰. I experienced no noticeable glitches so far with this method.

BTW, Kalle's guess was correct, the zoom limit of 1900 in MM is also caused by this. Evaluating bailout in every iteration allows me to zoom up to 2000, but with the current method the orbit can grow beyond 10³⁰⁸ above 1900, causing an overflow to infinity and corrupting the image.

The numbers I cited are for bailout, not bailout squared.

Nanoscope does not have the zoom limit, either, as it uses some trickery with rescaling dx and dy when below 10^-308. I've generated a test image at 10⁷⁶⁸ successfully -- one with solid-blob glitches, as a matter of fact, which Nanoscope had no trouble detecting and fixing way down there.

[Kalles Fraktaler]

Nanoscope does not have the zoom limit, either, as it uses some trickery with rescaling dx and dy when below 10^-308. I've generated a test image at 10⁷⁶⁸ successfully

That's very interesting, if you are able to do so without losing too much speed by e.g. separating mantissa from exponent as I do in KF, beyond e4900 and long double, which make it 10 times slower.
Because I think it is possible to use only the range e-308 - e308, i.e. e616 with doubles?