Mandel Machine

[Botond Kósa]

Finally rendered a somewhat bigger picture without crashes or freezes:

Nice image, but this was rendered without perturbation. When the precision (displayed under Statistics) is double or extended, that is below zoom level ~52, perturbation method is not used. If you set the precision on your location manually to bignum03, you can see how much faster the perturbation algorithm is. The center becomes flat though, this is a bug I am currently working on.

When automatic glitch correction is ready, I will turn on perturbation at all precision levels.

[Kalles Fraktaler]

D_n+1 = 2X_nD_n + 2A_nC_n + B_n²
E_n+1 = 2X_nE_n + 2A_nD_n + 2B_nC_n

I had some time to test this, and it works - beyond expectation! I am able to use all 5 terms and approximate even a few more iterations than you do. I need to use my 'floatexp' class that use a double as mantissa and the exponent as a separate integer, since the exponents exceeds far beyond e300 but still have impact.
Instead of comparing the term 5 with others, as you explained you do, I compare the result from approximation with the pertubation function for a couple of pixels, and if bailout is large I can allow up to 1% difference.
Next time I have time I will test even more terms...

[Botond Kósa]

Mandel Machine v1.0.3 is now available, containing mainly bugfixes in the SSE codepaths. Users with no AVX-capable CPUs should see improved speed and fewer crashes.

• FIXED: Small addends are never ignored when using perturbation method with scaled double and SSE2/SSE3 codepaths
• FIXED: Application crashes when using perturbation method with scaled double, SSE2/SSE3 codepaths and pixel grouping of at least 6
• IMPROVED: Detailed history labels when zooming in/out or panning

Glitch correction is in the works, stay tuned! 

[Botond Kósa]

Mandel Machine v1.0.4 is available, with an experimental manual blob correction function. KFR palettes and many-core systems are now better supported.
Full list of changes:

• NEW: Correct blobs manually by right clicking inside the blob to add a new reference point (experimental)
• CHANGED: Initial reference point is the center pixel; hillclimbing algorithm for finding a reference with highest iteration count is no longer used
• FIXED: Image becomes distorted when approaching a minibrot using perturbation method with scaled double
• IMPROVED: Maximum number of working threads increased from 8 to 32
• IMPROVED: Palette size increased from 4K to 1M to support KFR files with a high number of key colors
• IMPROVED: Minimum color density extended from -300 to -400 to support KFR files with high iteration division
• IMPROVED: Fractal window can be iconified to eliminate repaint overhead when rendering with high supersampling

[Dinkydau]

On my laptop it crashes at startup but on my desktop it doesn't, apparently, so I'm gonna check it out right now.

[youhn]

The latest version 1.0.4 crashes more often than the previous version. But I have to say I use the palette extraction tool more often. Not sure if this is related with the crashes though.

Last crash was while I was dragging the color offset slider.

Next crash was while dragging the internal image window.

When the program has a good way to recover from crash, I don't mind the instability. Autosave param function easier than improved stability?

[Dinkydau]

The program is very sensitive to doing things while it is computing, such as changing the resolution. Sometimes it doesn't work, other times the program crashes.

The extra long gradients are awesome, I think that's just what is needed to make beautiful images. The image tool is very nice.

It would be nice to be able to zoom with the mousewheel when the render is not finished yet. Zooming with double-click or the frame already works all the time. The short zoom-animation between each performed zoom is very useful; it helps to keep track of where you are and where you're going.

When rendering large images the program almost doesn't respond. It responds normally again when the render is finished. Then it can even change the gradient offset and speed in realtime while dragging the sliders. That's very good. Fractal extreme experiences that as tough operations and lags a lot.

[Botond Kósa]

Mandel Machine v1.0.5 is available (http://web.t-online.hu/kbotond/mandelmachine/, refreshing the page might be required). It is now a standalone application, no install procedure required. (The old version can be uninstalled from Control Panel.) The JNI calling framework is completely revamped, the program should crash less frequently.

From now on I will provide two packages: a full package containing the whole application that can be extracted anywhere, and an upgrade package containing the changed files only. The upgrade package can be used to overwrite files previously extracted from the full package.

[Botond Kósa]

When rendering large images the program almost doesn't respond. It responds normally again when the render is finished.

The image refresh interval is increased from 0.1 to 1 second when supersampling is turned on. The reason behind this is to reduce the repaint overhead during a computation. Currently the program downsamples the full supersampled image at every refresh, not just the parts that changed since the last refresh. This area still needs some improvement.

Maybe this is why you feel the program lagging when rendering large images. Or is the handling of mouse events lagging as well?

[hapf]

Hello Botond.
This looks like a real nice program. 
Blindingly fast.
Can you tell us how exactly you decide what reference(s) to use when perturbation
is active?
The center pixel it you said, right? What if it escapes before most of the rest of the image?
I have tested the program with one of my test regions and all I get is one big blob with perturbation.
No perturbation looks fine. It seems pixels are guessed but wrong. When I try to turn pixel guessing off the program locks up and no more rendering happens. Have to shoot it down.

[Botond Kósa]

Currently the center pixel is the reference. All pixels that would escape later get the same iteration count as the center, so large blobs can appear if the image is not centered on a minibrot or Misiurewicz point. This won't be a problem as soon as automatic blob correction is ready. Until then you can manually enter a new reference by right-clicking inside a blob, preferably in its center.

Could you post the coordinates for your test location? Does the program lock up with both perturbation and pixel guessing off?

[hapf]

Currently the center pixel is the reference. All pixels that would escape later get the same iteration count as the center, so large blobs can appear if the image is not centered on a minibrot or Misiurewicz point. This won't be a problem as soon as automatic blob correction is ready. Until then you can manually enter a new reference by right-clicking inside a blob, preferably in its center.

Could you post the coordinates for your test location? Does the program lock up with both perturbation and pixel guessing off?

position.re=-0.742930911953482867009836919181955123556848082588456919
position.im=-0.290570984967522148371001605993216722722946314930253398
position.magnification=181

It locked when perturbation was on and guessing off.
New references with right clicking helps. How do you decide which pixels to update? All that got stuck when the previous reference escaped?

[Kalles Fraktaler]

How do you decide which pixels to update?

All pixels that would escape later get the same iteration count as the center, so large blobs can appear...

As Botond Kósa write - all pixels in the blob get the same iteration count.
But - But!!!!!
This is only a special case, when only the main Mandelbrot have influence, i.e. no minibrot.
If your zoom path pass close to one (or several...) minibrot there are many variations:
* The blobs can contain a couple of iteration values, randomly spread through the blob
* The blobs can contain an iteration count value that is lower than other ares in the same view
* The blobs can have gradient content
* The blobs can have structured pattern
* etc etc etc

Botond Kósa I have a question for you - do you use only double datatype for calculating the pixels? It seems you use more precision than what is possible with the double datatype, since Mandel Machine get fewer glitches than Kalles Fraktaler when one reference only is used...

[hapf]

As Botond Kósa write - all pixels in the blob get the same iteration count.

Yes. Only updating these is an option. Use a second reference and update all these pixels with the same iteration count. Again
some will likely hit the ceiling if the reference is not in the set. If it is, none will unless they are in the set too (ignoring potential issues with insufficient iteration limit for the image). Repeat and rinse. Only:
- there is no guarantee whatsoever that the pixels not hitting the ceiling in any iteration of the procedure (reference in the set or not) are correct
- there is no guarantee whatsoever that pixels hitting the ceiling (reference in the set or not) do so correctly
If one considers not just updating the pixels that hit the ceiling but all others that reach (for example) a higher escape iteration value then again
- there is no guarantee that this higher value is (more) correct (than the value before).

Basically, blob detection and blob busting is a bitch, even when done manually with human intelligence orchestrating the efforts.
More so leaving it to machine intelligence. The deeper one zooms potentially the worse it gets with corruption stacked within corruption etc. I have not found so far a solid mathematical (or even only ad hoc practical) foundation for identifying ALL corrupted pixels with certainty (not some likelyhood). But I'm no mathematician. It may exist after all. Lacking one everything is on shaky grounds.

[knighty]

Looks good!
Any 32bit version? please.