Kalles Fraktaler 2

[Pauldelbrot]

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?

It loses very little speed -- it may actually gain speed, because on most iterations that deep the delta squared term can be ignored as it's another 10^-308 smaller still; except when either the reference orbit is very close to zero or the delta term computed without delta squared is. The reason is that Nanoscope doesn't work with the exponent on most iterations -- there's a rescaled delta, stored in doubles, and an exponent value, but the new rescaled delta can be computed from just the old rescaled delta and the reference point on most iterations. When delta squared is needed, or after about 500 iterations, one iteration is done using precision-16 java.math.BigDecimals -- that one iteration is slow, even with the precision limited to a double's, but has unlimited exponent width. The "after about 500 iterations" is because on most iterations delta roughly doubles and at most grows by a factor of four (given the reference point hasn't escaped!), and 500 quadruplings will take a rescaled delta close to 1 up to near 2¹⁰⁰⁰ ~ 10³⁰⁰, putting it in spitting distance of exponent overflow. It seems to work in practice.

At some point I'll post actual code.

[Kalles Fraktaler]

New version uploaded, 2.4.3

I haven't had time to test all locations but I have made some great findings

First, my optimization on loop expansions and not checking bailout on every iteration did improve render with double speed but introduced the bug on difference reference gave different result. I have removed these optimizations, so it is 2 times slower now (still twice as fast as 2.2 though)

I could of course have fixed the bug and kept the optimization, but I removed it, because...
When checking bailout on every iteration, I found that pauldelbrot's glitch detector is bullet proof!
Even with series approximation!!
The intervals where the glitch is detectable can be very short and then disappear again, so it is important to check every iteration. Really good news is that SA doesn't prevent glitches from being detected!
Kalles Fraktaler now handles flake and the locations from ellarien and hapf without problem, even when SA skips most iterations.

Manual glitch solving is now history, just a vague memory from the past! Even one-pixels sized glitches are discovered and solved automatically. One click and all frames on a zoom sequence are rendered flawless without manual intervention!

Pauldelbrot, I am glad that I once again need to say to your that, I was wrong you are right!

[Pauldelbrot]

New version uploaded, 2.4.3

I haven't had time to test all locations but I have made some great findings

First, my optimization on loop expansions and not checking bailout on every iteration did improve render with double speed but introduced the bug on difference reference gave different result. I have removed these optimizations, so it is 2 times slower now (still twice as fast as 2.2 though)

I could of course have fixed the bug and kept the optimization, but I removed it, because...
When checking bailout on every iteration, I found that pauldelbrot's glitch detector is bullet proof!
Even with series approximation!!
The intervals where the glitch is detectable can be very short and then disappear again, so it is important to check every iteration. Really good news is that SA doesn't prevent glitches from being detected!
Kalles Fraktaler now handles flake and the locations from ellarien and hapf without problem, even when SA skips most iterations.

Manual glitch solving is now history, just a vague memory from the past! Even one-pixels sized glitches are discovered and solved automatically. One click and all frames on a zoom sequence are rendered flawless without manual intervention!

Pauldelbrot, I am glad that I once again need to say to your that, I was wrong you are right!

Thanks. But we'll just see, in the fullness of time. It's still early yet. I wouldn't bet 100% on my glitch detector unless years go by without anyone finding a case where a noisy glitch sneaks past it.

[Dinkydau]

I'm currently trying to make a decision what to do. I have a complete render of a new video which is full of glitches, some of which are not blobs. Should I re-render with the latest version, or solve the glitches manually?

[Kalles Fraktaler]

Thanks. But we'll just see, in the fullness of time. It's still early yet. I wouldn't bet 100% on my glitch detector unless years go by without anyone finding a case where a noisy glitch sneaks past it.

It won't be the first time I have to take such statements back, but I keep on being optimistic.

I'm currently trying to make a decision what to do. I have a complete render of a new video which is full of glitches, some of which are not blobs. Should I re-render with the latest version, or solve the glitches manually?

I am sorry, and I am currently rerendering a zoom myself.
And it takes if course longer time with new version and auto-glitch for every frame.
I guess it depends on how long your render took...?

I am only rerendering the shallower half of my sequence though. I deleted half of the frames and resumed...
Carefully checked that the joint weren't visible, in kfmm

Addition:
It might be an idea that always use the "Reuse reference" with only one full precision calculation and no glitch solving on the deepest parts of hard zoom sequences. And then, when glitches start to get visible, stop the render, lower the Max iteration value and turn auto-glitch correction on, and resume again.

[Dinkydau]

I just noticed that the tool to check for glitches now has a button to auto-correct glitches. Is it able to use pauldelbrot's method?
Edit: it doesn't detect the glitches. I ask too many questions.

[Kalles Fraktaler]

I just noticed that the tool to check for glitches now has a button to auto-correct glitches. Is it able to use pauldelbrot's method?
Edit: it doesn't detect the glitches. I ask too many questions.

Hm... Yeah, with pauldelbrot's glitch detection I removed the old detection to avoid unnecessary processing...

[ellarien]

Excellent! The first location I tried ended up with a rather boggling 30-40 references around the final minibrot, but they don't all do that, and the resulting images look very nice.

I have one small remaining issue with 2.4.* as compared with earlier versions; on zoom-in, the automatic maximum iteration estimate doesn't seem to be working quite as well as it used to, meaning that I have to manually increase the maximum by a factor of at least 4 instead of 2 to see the shape of the final minibrot, and also I'm more likely to see black areas off-center in the early stages of a zoom-in. Is this a necessary trade-off for the better glitch-fixing? If so, I can learn to live with it. 

[kjknohw]

Amazing program . Fractal Extreme once held the undisputed "fastest" champion. Now we have something that is 10-100 times faster in most situations and deep zoom. But it is still arough draft, and here are some improvements (from high priority to low priority).

Make Glitch correction earlier. Don't wait for the fine-resolution image to be calculated/guessed before those ugly splotches get corrected. If the coarse passes detect significant glitches, deal with them now, not later. Even when the coarse check doesn't pick up anything, you can still run a final glitch detection during the high resolution images at the end just to be sure (although that shouldn't be necessary in most cases, the algorithm is spotless so would still be very good on a coarser grid).

Add a 4X4 coarse render pass: it gives a preview at up to a 16 fold speedup (apart from calculating the initial references), instead of just 4 fold.

Colors: Allow us to specify the frequency of the "waves" when we generate them. This allows more control over getting the coloring to work. Also, we should be able to specify sqrt and log to be from the lowest iteration in the image, this makes for better coloring in most cases.

Other optimizations: Even with the expensive "reference" calculations, the image itself usually takes up most of the time. Periodicity checking, solid guessing (you already seem to have this), etc are all still useful for the image calculation. Fractal Extreme can render the mandelbrot set with a million iterations in under one second at the default size and zoom level, due to these optimizations. Xaos is also really fast at low zooms.

Movement: Can we be able to pan the view or zoom in/out by a tiny amount to get that perfect "shot" (without guessing what numbers to type in) as well as keep the current way of exploring?

Max iteration auto (this could be hard): This is the best I've seen but it still doesn't work in many cases. Improvement is needed. However, disabling it and setting max iterations now seems to work (not to confuse low max iterations black regions with non-black glitches). It is most likely to fail deep in the cusps of baby mandelbrot sets. One strategy might be to look for how "bulby" the regions are.

If you implement these simple improvements the program will be very solid as well as technically astounding.

[SeryZone]

Amazing program . Fractal Extreme once held the undisputed "fastest" champion. Now we have something that is 10-100 times faster in most situations and deep zoom. But it is still arough draft, and here are some improvements (from high priority to low priority).

Make Glitch correction earlier. Don't wait for the fine-resolution image to be calculated/guessed before those ugly splotches get corrected. If the coarse passes detect significant glitches, deal with them now, not later. Even when the coarse check doesn't pick up anything, you can still run a final glitch detection during the high resolution images at the end just to be sure (although that shouldn't be necessary in most cases, the algorithm is spotless so would still be very good on a coarser grid).

Add a 4X4 coarse render pass: it gives a preview at up to a 16 fold speedup (apart from calculating the initial references), instead of just 4 fold.

Colors: Allow us to specify the frequency of the "waves" when we generate them. This allows more control over getting the coloring to work. Also, we should be able to specify sqrt and log to be from the lowest iteration in the image, this makes for better coloring in most cases.

Other optimizations: Even with the expensive "reference" calculations, the image itself usually takes up most of the time. Periodicity checking, solid guessing (you already seem to have this), etc are all still useful for the image calculation. Fractal Extreme can render the mandelbrot set with a million iterations in under one second at the default size and zoom level, due to these optimizations. Xaos is also really fast at low zooms.

Movement: Can we be able to pan the view or zoom in/out by a tiny amount to get that perfect "shot" (without guessing what numbers to type in) as well as keep the current way of exploring?

Max iteration auto (this could be hard): This is the best I've seen but it still doesn't work in many cases. Improvement is needed. However, disabling it and setting max iterations now seems to work (not to confuse low max iterations black regions with non-black glitches). It is most likely to fail deep in the cusps of baby mandelbrot sets. One strategy might be to look for how "bulby" the regions are.

If you implement these simple improvements the program will be very solid as well as technically astounding.

Hey, for calculate millions iterations, we need to rewrite loops and complex calculations on assembler language. I leard SIMD-instructions as hard, but my strides equal zero. Okay, what can do lonely 17-year guy? I do not have goal in life, I must to find myself! I must strive for perfection! But I still strange!

And Fractal eXtreme is not calculation champion! People on fasm forum can write programms, faster than FX in more times! And, mercator maps make rendering faster.
Fractal eXtreme, 8-cores used: 2 minutes
Me little program with SIMD, mercator map, 1-core: 1:30 minutes, and it is without guessing!!! Imagine, what's fractal monster we can write if we combine:
1) Mercator map
2) Full Guessing (Minibrots and dwell bands)
3) Multi-core rendering
4) High-precision math
5) Perturbation Theory
6) SIMD instructions (for my AMD only AVX, but for Intels - AVX2).
7) All write on FASM
Imagine!!! People have many differences unlike animals. One of them - imagination. I dream and see, that I write and use this 'monster'.
7 optimizations...

[youhn]

Colors: Allow us to specify the frequency of the "waves" when we generate them. This allows more control over getting the coloring to work. Also, we should be able to specify sqrt and log to be from the lowest iteration in the image, this makes for better coloring in most cases.

Yeah, please this one! Combine the current stuff with the features of MDZ palette editor:



I really miss the offset function for the palette, which makes it possible to very precisely position the stripes (which also use the manual adjustable bands).

[Pauldelbrot]

Hey, for calculate millions iterations, we need to rewrite loops and complex calculations on assembler language. I leard SIMD-instructions as hard, but my strides equal zero. Okay, what can do lonely 17-year guy? I do not have goal in life, I must to find myself! I must strive for perfection! But I still strange!

And Fractal eXtreme is not calculation champion! People on fasm forum can write programms, faster than FX in more times! And, mercator maps make rendering faster.
Fractal eXtreme, 8-cores used: 2 minutes
Me little program with SIMD, mercator map, 1-core: 1:30 minutes, and it is without guessing!!! Imagine, what's fractal monster we can write if we combine:
1) Mercator map
2) Full Guessing (Minibrots and dwell bands)
3) Multi-core rendering
4) High-precision math
5) Perturbation Theory
6) SIMD instructions (for my AMD only AVX, but for Intels - AVX2).
7) All write on FASM
Imagine!!! People have many differences unlike animals. One of them - imagination. I dream and see, that I write and use this 'monster'.
7 optimizations...

1) Nanoscope has this
2) Not sure it's worthwhile, especially with smoothed iterations, likes to chop off the ends of minibrot valleys
3) Nanoscope has this
4) Nanoscope has this
5) Nanoscope has this
6) Nanoscope has this if the JIT in your JVM does
7) Nanoscope has this if the JIT in your JVM does

What's Kalle's Fraktaler doing in these areas? As far as I'm aware it uses keyframe interpolation, so not 1, and obviously yes to 4 and 5 ...

[youhn]

Is the nanoscope GUI ready for us to be used ... ?   :

[Pauldelbrot]

Is the nanoscope GUI ready for us to be used ... ?   :

No, not yet. Work on it is momentarily stalled due to external factors beyond my control.

[kjknohw]

Question: once we make a zoom out sequence how do we extract the raw iteration data (if we have written our own program insted of using the movie maker)?

Noobish question: Is there any real difference between Nanoscope and Kalles Fraktaler 2? KF works under wine (except the cursor feature, which is really minor), making it cross-platform in a sense. Any other advantages of Nano?