Kalles Fraktaler 2

[hgjf2]

Congratuleiton! This topic was reached at 2nd place after the topic "True 3D Mandelbrot" whick have 37 pages but is locked.
3rd place own topic "Mathematical FS model"

[Kalles Fraktaler]

How many times, in a lifetime, does a programmer get the opportunity to make revolutionary things in a concept that is several decades old and fascinates you and several others for decades?
How many times do you get the opportunity to beat the well established programs in this area, that some very intelligent, talented and skilled people worked with for decades, with sometimes hundreds of times?

And I didn't do anything revolutionary myself, I just put it together 
And finally I know where this pattern comes from:
 

[youhn]

Since the new burning ship perturbation feature, I'm dedicated to make some (deep) zoom video into this fractal. It's nice to explore, since it shares many properties of the Mandelbrot set. But the shapes are more confusing, so my time in the old mset really pays off. The bigger contrast in iteration-density ask for other color method. Playing around with the palette option is certainly helpfull, but I still think another (or additional) method is better. For example see http://www.juliasets.dk/FractalsAndArt.htm

Running Kalles with Wine under Linux is doable, but brings some challenges. For example the Key Frame Movie maker does not have much codecs to choose from. So I render non-compressed video, extract all images with mplayer, scale them down for antialiasing and putting them back into a movie with mencoder. This process could be more streamlined, if the keyframe maker could store JPG or PNG directly. Like the program Xaos for example does.

Don't get me wrong, the program so far is wonderfull. Though I might seem a little impatient and pushy, I really respect your work. Keep up the good work!

 

[Kalles Fraktaler]

Since the new burning ship perturbation feature, I'm dedicated to make some (deep) zoom video into this fractal. It's nice to explore, since it shares many properties of the Mandelbrot set. But the shapes are more confusing, so my time in the old mset really pays off. The bigger contrast in iteration-density ask for other color method. Playing around with the palette option is certainly helpfull, but I still think another (or additional) method is better. For example see http://www.juliasets.dk/FractalsAndArt.htm

Running Kalles with Wine under Linux is doable, but brings some challenges. For example the Key Frame Movie maker does not have much codecs to choose from. So I render non-compressed video, extract all images with mplayer, scale them down for antialiasing and putting them back into a movie with mencoder. This process could be more streamlined, if the keyframe maker could store JPG or PNG directly. Like the program Xaos for example does.

Don't get me wrong, the program so far is wonderfull. Though I might seem a little impatient and pushy, I really respect your work. Keep up the good work!

 

Thanks! But it is and will always be an experimental prototype

It should be possible to create jpeg images though.
I just did an e110 zoom sequence with stored jpeg images, and monitored the usage of handles, user objects and GDI objects, and it worked as expected.
Maybe there is a problem with the jpeg images because of wine...
Or maybe you minimized KF while rendering, which I didn't test that but I know was causing problems before?
Can you test a render without minimizing KF?
(if you are afraid of breaking the render by accidentally clicking in the window - I usually open the "Iterations" dialog, to monitor interesting stuff, which is modal and blocks the main window - but don't click OK in that dialog...)

[Dinkydau]

From memory I flipped the coordinates for FX's burning ship, to make it look like examples I'd seen online.
Just checked the code... yep coordinates are flipped by subtracting the real and imaginaries eg.

Code:

case FT_BurningShip:
	for (/**/; count < MaxIters && zrsqr + zisqr < OverFlowPoint; count++)
	{
		zi = abs(zr * zi) * 2.0 - JuliaI;
		zr = zrsqr - zisqr - JuliaR;
		zisqr = zi * zi;
		zrsqr = zr * zr;
	}
	break;

I've tried out a location, if you negate both real and imaginary values from Fractal Extreme it looks right in Kalles Fraktaler.

I really can't get it to work. Can you see a small burning ship on this location in kalles fraktaler? Coordinates are from fractal extreme, so I would expect they both need a minus sign, but that doesn't work for me.

Code:

Re = 1.99433270612477098133238929437627777114179521395878761184111509174580069593600399539342136038592734218389132940639032704182715934691321308296153457671113540459988177959341694798272090475163809104849804990505554293321832065055051136201576337342335810747775706468375892916000095316130617700229812635608032228538842556508340662529592613070320
Im = 0.00000081561078413677459233197066759976643507224758738026546643955561961686639072258384945588779665044103159380877446917385559197803066769746776826523930496313831007081028303021855816450545567402149336048032768933742865811575273067934391565924452776695604556852839506359998689018878921792755647084961419169080587434930871994265705972315492

Magnification:
2^1111
2.7817953874931422193200157252798 E334

[ellarien]

That location doesn't work for me, no. But with the negations, at zoom=1 it looks like the right sort of location (north of the Western Antenna near a miniship), so maybe it's a precision issue rather than a sign one? I've noticed sometimes that beyond about e200 it sometimes doesn't work to paste Mandel Machine locations back into KF, either.

[Dinkydau]

I investigated from where it goes wrong, and it happens right at 79 zooms or 8.08357032783E23. Apparently the burning ship in fractal extreme contains elements that don't appear in kalles fraktaler.





Bailout value is set to be 2 in both images and smooth colors are off.

[Kalles Fraktaler]

I tried it in "Kalles Fraktaler 1" which is using full precision calculations for each pixel, and which I played with before I knew anything about perturbation.
It doesn't show the elements from Fractal extreme.
Is it panzerboy's algorithm that is used in fx?
Is it possible that his minuses in the formula causes this kind of difference?

[youhn]

...
Maybe there is a problem with the jpeg images because of wine...
Or maybe you minimized KF while rendering, which I didn't test that but I know was causing problems before?
Can you test a render without minimizing KF?...

Well, was doing some bug hunting based on program behavior. It seems related to focus of windows and/or screens. I use Openbox as window manager and I've configured it to use 3 virtual desktops or screens. When I switch away from the screen on which Wine/KF is active, it immediately starts to store the last image over and over again. Switch back to the screen and KF picks up where it should be. All images in the meantime are not stored, since they are all copies from the last one when switching away.

Just tested with minimizing ... same things as switching virtual screens. It does not seem to have a direct connection with the focus of the window (as long as it stays on the current desktop).

[Kalles Fraktaler]

I investigated from where it goes wrong, and it happens right at 79 zooms or 8.08357032783E23. Apparently the burning ship in fractal extreme contains elements that don't appear in kalles fraktaler.
...
Bailout value is set to be 2 in both images and smooth colors are off.

I am not very familiar with the Burning Ship fractal so I'm not an expert, but I think those elements in FX looks incorrect, considering the surrounding structure.
Did the zoom you investigate continue into one of these elements, and if so, is it deep inside one of these that you find the mini-ship?

That location doesn't work for me, no. But with the negations, at zoom=1 it looks like the right sort of location (north of the Western Antenna near a miniship), so maybe it's a precision issue rather than a sign one? I've noticed sometimes that beyond about e200 it sometimes doesn't work to paste Mandel Machine locations back into KF, either.

Do you have any example of this?

[Dinkydau]

I am not very familiar with the Burning Ship fractal so I'm not an expert, but I think those elements in FX looks incorrect, considering the surrounding structure.
Did the zoom you investigate continue into one of these elements, and if so, is it deep inside one of these that you find the mini-ship?

Yes, the zoom continues into such an element. Once zoomed in on it, it doesn't look weird anymore and reveals a world of beautiful details including symmetry increases that lead to a burning ship.

Honestly I have no idea which of the two is incorrect. Other than those small details and the fact that Panzerboy flipped his ship horizontally, the ships seem to be exactly the same. (Indeed Panzerboy created the fractal extreme plugin.) If there's a mistake anywhere, I find it very strange that the differences are so small.

[ellarien]

Do you have any example of this?

Unfortunately not. My idle attempt to reproduce the problem this afternoon got me a fairly boring deep zoom and a very weird MM glitch, but no problem reproducing the location (minus glitch) in KF. I'll let you know if I run into it again.

[Kalles Fraktaler]

Unfortunately not. My idle attempt to reproduce the problem this afternoon got me a fairly boring deep zoom and a very weird MM glitch, but no problem reproducing the location (minus glitch) in KF. I'll let you know if I run into it again.

Thanks, that's great.

From memory I flipped the coordinates for FX's burning ship, to make it look like examples I'd seen online.
Just checked the code... yep coordinates are flipped by subtracting the real and imaginaries eg.

Code:

case FT_BurningShip:
	for (/**/; count < MaxIters && zrsqr + zisqr < OverFlowPoint; count++)
	{
		zi = abs(zr * zi) * 2.0 - JuliaI;
		zr = zrsqr - zisqr - JuliaR;
		zisqr = zi * zi;
		zrsqr = zr * zr;
	}
	break;

I've tried out a location, if you negate both real and imaginary values from Fractal Extreme it looks right in Kalles Fraktaler.

Panzerboy, what is OverFlowPoint and why do you need to check it? Edit: of course, it's bailout...
Anyway, if your formula is creating beatiful additional patterns, it is cool But I don't understand the difference...

[panzerboy]

My plugin for FX has a known glitch that sometimes appears in the smoothed version of the Burning Ship once it hits the high precision fixed point logic.
It is interesting that the glitch doesn't show when using the smooth shaded version with low iterations.
You need to use iterations > 16383 to turn on the smooth shading, this activates logic that multiplies the iteration value by 256 and then adds a 0-255 smooth value.
With iterations lower than 16384 (actually seems to be 16200 ?!) the only difference should be the number of bits used for the integer part of the high precision fixed point numbers.
In the normal iteration colouring burning ship there should be 6 bits of integer value, smoothed version 5.
With a bailout of 4 if both the real and imaginary were close to 4 the sum of the squares would be close to 32, which needs 5 bits.
I thought I could get away with trimming the integer part a little and gain 1 whole bit of bicemal precision,
possibly allowing 1 more zoom before extra precision is needed and slowed down calculation (eg. from 192 bit to 256 bit arithmetic).
So its weird that less precision in the integer removes this artifact.

When smooth shading is turned on a whole extra word (32 or 64 bit) of integer values is added to cope with large bailout values, and another word of bicemal to preserve precision after multiplication. The smooth shading glitch looks different from the iteration colouring glitch.

The high precision number format for FX is messy, the dll seems to have been written to have 1 word and 3 bits of integer.
The sample plugin discards the word of integer and extends the integer width to 6 bits.
I've now messed with that and changed the format to be 5 bits integer, until you overflow the standard bailout of 4 or do 2 extra iterations for smoothing, then a word of integer and a word of bicemal is added.
Any of which might have subtle bugs, most likely in my code.  
Attached is the glitch with the smoothed logic.

[Kalles Fraktaler]

I have uploaded a new version, 2.5.4

I was just beginning to get confident in Kalles Fraktaler, but just as I completed a deep julia morphing sequence - on one of the 2466 frames, there was a glitch!!!
The Series Approximation uses 5 terms and allowed 0.1% difference, and as I mentioned before in http://www.fractalforums.com/announcements-and-news/pertubation-theory-glitches-improvement/30/
I was previously suspecting that Pauldelbrot's glitch condition could be missed if it only occurrs on iterations that is skipped by Series approximation. But I found out that it was instead the optimizations that hid the condition (for Dinkydau's flake location).

Now I found out that the 0.1% tolerance it too much and can indeed hide a glitch from being detected. If I decreased the tolerance to 0.0001% this glitch is caught for all main references in this view.
This value is now the very same value that is used for Pauldelbrot's glitch condition, maybe they are related?

The location is, the glitch occurs in one of the corners...:

Code:

Re: -1.7497415120544229852294434038347923546464860116975
Im: 0.00000072462200351594671836485600005157469714403056546967
Zoom: 7.5E22

With 0.1% tolerance 697 iterations was skipped, and with 0.0001% 562 iterations. So, unfortunately consequently, render time for this location increase with 60%, but on many other locations the same number of iterations can be skipped.