Kalles Fraktaler 2

[Pauldelbrot]

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. So what is the advantage of Nano?

If you like the Mercator map method and/or multiwave coloring, it will have the edge. Anyway, the real advantage is just to have several people working on this stuff, each with somewhat their own approaches, that will eventually evolve a better product. KF has some features initially prototyped in Nanoscope, for example.

[Kalles Fraktaler]

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).

Thanks! Yes, KF is an experimental program and who knows, now when we have reliable glitch detection available, FX and others can make something much better and sell it to you. But I have had a lot of fun for a year at least

Make Glitch correction earlier. Don't wait for the fine-resolution image to be calculated/guessed before those ugly splotches get corrected.

I am not sure if it is possible, because only one reference is used at the time, since all zr and zi values for all iterations are stored and used in perturbation. Changing this reference on the fly would probably create new glitches and mixing them with correct pixels.
I think the splotches aren't ugly anymore, because now when all of them can be solved they are my friends now

Colors: Allow us to specify the frequency of the "waves" when we generate them.

Yes! And I am also elaborating with multiwaves inspired by Pauldelbrot. I will publish this soon

And all the rest of your suggestions are good, I will probably add them all eventually.
Main focus have currently almost only been on perturbation but it's getting close to something reliable now I think.

Yeah, please this one! Combine the current stuff with the features of MDZ palette editor:
<img>
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).

You can offset the palette. And I will make a better wave function

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)?

You can find the source here:
http://www.fractalforums.com/index.php?topic=18725.0
It's not updated since a while but this format is not changed. Function CFraktalSFT::OpenMapB in file fraktal_sft.cpp opens a kfb file.
Basically the file contains two tables, one integer table with iteration count values, and a float table with smooth coefficients.
I will update the source eventually.

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?

Is wine on Mac? Cool if so.
I've learned a lot from what Paul written about Nanoscope, it has been a big inspiration.
I am the implementator, not the inventor.
I clutter up the forum with all my buggy versions while others may want to do the proper programs before each release
But this is too much fun to resist, and we are breaking new lands, so we have learned a lot on the way.

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. 

Thanks! No, no trade-offs on this was necessary. Maybe I tried to slim that and I should restore it because I also find it annoying when it happens too often.

[kjknohw]

I am not sure if it is possible, because only one reference is used at the time, since all zr and zi values for all iterations are stored and used in perturbation. Changing this reference on the fly would probably create new glitches and mixing them with correct pixels.

Making it earlier only is useful for getting a quick preview faster when exploring (not when rendering a movie).
Heres what is currently done (according to my understanding):
Calculate the entire image using Ref 1 (start with a 2x2 blocky preview).
Check for glitches and add ref2 in the center of the glitch and recalculate the glitch using ref2. Check the for more glitches among these recalculated pixels, etc, etc, etc.
For preview purposes the glitches are worse to have than a blocky image because they can cover up where the user is interested in going.

Heres what I am proposing:
Calculate a coarse image (4x4 blocks) with ref1. Find and fix glitches on the coarse image. Now you have a correct image, but it is blocky. This gives the user a preview that is up to 16 times faster. Also, there are no glitches that may cover up stuff you want to explore.
Now you have a choice, depending on how much time you have for coding:
1 (easy). Throw our everything and calculate a 2x2 image using ref1. Fix glitches the same way as above, but feel free to ignore the 4x4 image's values (you can even generate new references). Repeat for the 1x1. This way is slower in the end (about 50%) but gets a better preview out more quickly. The user should be able to choose between this way or the old way.
2 (hard). Calculate the 2x2 and 1x1 using the reference used of the parent 4x4 block. Check those for glitches as you calculate and compute new references if necessary. To reduce "boundary effects", you can "dilate" the sub-references by one pixel (so you are guaranteed to use ref2 near the boundary where ref1 begins to glitch, etc).

I clutter up the forum with all my buggy versions while others may want to do the proper programs before each release
But this is too much fun to resist, and we are breaking new lands, so we have learned a lot on the way.
Thanks! No, no trade-offs on this was necessary. Maybe I tried to slim that and I should restore it because I also find it annoying when it happens too often.

It's good to release a beta! Your program has a GUI and it is easy to use (once you get use to the quirks). Also, Nanoscope is in Java which is slower than C; speed is critical for fractal programs.

[youhn]

You can offset the palette. And I will make a better wave function

Thanks for going for the better wave function! But I mean you can cycle colors over the iterations, but you can't really offset the palette itself. Now if you use Merge Colors with step 4, it always start at palette index no 1. I want to be able to shift that. For example to get dark stripes for shadow and put white stripes in between (after shifting the palette on itself) for a kinds of glow. With MDZ I made some very cool palettes that way. I'll try to make a video of this today to clarify.

[3dickulus]

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

I'd be happy to throw together a Qt C++ interface if you have the "engine" working to your satisfaction, if it takes parameters on the cmdline and outputs image/data it's easy to do, just takes time and if it's all java I would also attempt to port the engine to C++

[kjknohw]

I'd be happy to throw together a Qt C++ interface if you have the "engine" working to your satisfaction.

Why not use cython? It allows calling c-functions, and python is a wonderful language when speed isn't so critical. Qt C++ still needs people to know C++ and battle segfaults of doom, etc.
All you would need for the engine core is "caculate(String[] imageCenter, String[] reference, int[] pixX, int[] pixY, double power, int maxIter)", where pixX and pixY are the x and y locations pixels of the image you need to compute, and imageCenter/reference are complexes. They would not be the whole image because you may want a fast preview. Power would be the log base 10 of the magnification. The result would be an array of ints (or doubles for smoothing) and an array of whether or not the pixel glitched. You only need to call this from python a few times per reference point so the overhead is minimal. Constructing the pixel arrays and calculating the new reference point's location (only two arbitrary precision adds and two multiplies needed) should be cheap enough to do in Python. Maby the coloring can also be c-ported if speed is an issue for real-time cycling, etc.

[Kalles Fraktaler]

Thanks for going for the better wave function! But I mean you can cycle colors over the iterations, but you can't really offset the palette itself. Now if you use Merge Colors with step 4, it always start at palette index no 1. I want to be able to shift that. For example to get dark stripes for shadow and put white stripes in between (after shifting the palette on itself) for a kinds of glow. With MDZ I made some very cool palettes that way. I'll try to make a video of this today to clarify.

Merge colors starts on the selected item in the list of colors, but then it stops at the end.
One quick way to create an interesting palette which I often use is to randomize for example 64 or 128 colors. Then I expand this a couple of times, or expand to 1024 colors. Then I select the 2nd color in the list and merge every 4th with white with 50%, and then select 4th color and merge every 4th with black with 50%.

[youhn]

Merge colors starts on the selected item in the list of colors, ...

Ah, just select an item...

Damn, I totally missed this feature! Sorry 

[3dickulus]

Why not use cython? It allows calling c-functions, and python is a wonderful language when speed isn't so critical. Qt C++ still needs people to know C++ and battle segfaults of doom, etc.

lol@"segfaults of doom"

I imagine that Kalles and Pauldebrot write in the language they are most familiar or comfortable with and to use the program all you need to know is how to work the mouse and keyboard.

For hacking at the code, the engine is the engine, no matter the language. Just thought I'd make the resource available if needed.

Amazing work!!! you guys rock!!! 

[kjknohw]

For hacking at the code, the engine is the engine, no matter the language. Just thought I'd make the resource available if needed.

True.
The source code for Kalles Fraktaler2 is available:

http://www.fractalforums.com/other-b130/kalles-fraktaler-2-open-project/new/?PHPSESSID=3759536d7aed8989606711b47043f6e9

The engine is not that large, but it is C code and poorly documented (at least it is english). If you could make a nice clean, well documented wrapper no matter which language you use that would really help me (or someone else) make a cython wrapper from your wrapper's source code.

[Pauldelbrot]

Actually, Nanoscope is written in Clojure, which has many of the nice features attributed to Python (and then some) and runs on the JVM (compiles to Java bytecode). With a good JIT the inner loop should be comparable in speed to C. It should also be relatively easy to port to .NET, as Clojure can compile for that platform as well (but the FFI calls to Java would need to be rejiggered to use .NET equivalents -- that means the image I/O library calls and the exact API used for bignums for the reference orbit calculations).

[SeryZone]

If you like the Mercator map method and/or multiwave coloring, it will have the edge. Anyway, the real advantage is just to have several people working on this stuff, each with somewhat their own approaches, that will eventually evolve a better product. KF has some features initially prototyped in Nanoscope, for example.

Okay  Can you teach me, how to correctly use SIMD constructions (without AVX2)  I can improve KF speed and, maybe, can help you with this idea.

[Pauldelbrot]

Okay  Can you teach me, how to correctly use SIMD constructions (without AVX2)  I can improve KF speed and, maybe, can help you with this idea.

Who, me? I don't know much about SIMD. I leave it up to the compiler writers and JVM developers to worry about things like that.

[SeryZone]

Who, me? I don't know much about SIMD. I leave it up to the compiler writers and JVM developers to worry about things like that.

Sorry)))) I very want to learn this, therefore ask everybody 

[Dinkydau]

I really like the gradient generation with waves and the fractional iteration division. Suitable colors are important even for exploring. To improve the program even more, I have a suggestion, or two.

At the moment, upon zooming in, the point at which is zoomed in becomes the center of the next image. I think it's better if the point at which is zoomed keeps the exact same location on the screen. (Mandel machine does this.)

It would also be nice to be able to drag the image to adjust the position of visible shapes.

Something less important: it just happened to me that a glitch remained unsolved, but when I loaded the location in a different instance, the glitch was solved and I couldn't reproduce the problem anymore.