Kalles Fraktaler 2

[Kalles Fraktaler]

Yes, I also had reuse reference on. What is the difference between
1. reuse reference + manual solve glitches, and
2. reuse reference + auto solve glitches?

Isn't the glitch solving essentially the same, whether it's manual or automatic?

There is only one list of reference values, main reference or additional reference, and if the reference is to be reused, it is not re-calculated for the next key-frame.
I have never tested to combine these two, but the last additional reference, to solve glitches, would be used for the next key-frame.

For locations that do not pass too close too many deep minibrots, it is enough to use one reference only, no auto glitch solve, and only a few or not at all glitches needs to be solved manually.
But for all locations the key frames are of course much faster rendered with one reference only, and the glitches to be solved manually are fewer than when exploring since such reference is deeper than the rest of the pixels.

And finally, I have made a new version, 2.2.8.
Because I have solved a rare problem that I have seen a few times, which is sometimes impossible to solve in another way.
Here is a glitch that the auto function did not solve, because the smooth coefficients did not have the same colors inside the blob, which is unusual (but maybe related to this problem...)

If a new reference is added in that blob, a new glitch occur, because unfortunately those pixels had the exact same color (i.e. iteration count value) as the blob, but those pixels were correctly rendered at the first time, and got incorrect with the new reference:

The nasty thing with this particular new glitch is that it is not a blob glitch but a gradient glitch, and many new references would be needed to solve it, causing other areas in the view to become incorrect.
The solution is to cancel the changes, check the "Use near pixel method" check-box, and add the reference in the first blob again. This time only the connected pixels, i.e. the pixels in the blob, are re-rendered, and all other pixels are untouched.

Since these images are only the left corner of the whole frame, the same blob glitch occur 4 times and 4 additional references needed to be added.
Usually only one additional reference is needed to solve all similar glitches on the same view.

[Kalles Fraktaler]

I your version is 2.2.9 don't use it, current version is 2.2.10!

[SeryZone]

I wait for 2.2.10)))

[panzerboy]

Though the website says v2.2.9 the version I downloaded says 2.2.10.
Perhaps Karl is busy with other things (programming?)

[Kalles Fraktaler]

Though the website says v2.2.9 the version I downloaded says 2.2.10.
Perhaps Karl is busy with other things (programming?)

Yeah. A man from youtube wanted to help me improve the movie maker program, which indeed take long time when color cycle and rotation are applied.
His first suggestion was to combine the two tabels iterations (int) and smooth coefficients (float) to one float table.
The reason I had them separated was that I didn't want to risk that the floats would be truncated on my very deep locations. According to Wikipedia a float is only reliable to 6 decimal digits. And unfortunately I was right. So I reverted the KFB file format for now.
But he had also other better suggestions regarding making as narrow jumps as possible in memory to take advantage of CPU memory caching, something I have never considering.
So there will indeed be more versions

[Dinkydau]

I started the rendering of a zoom out sequence from an extreme location with max iterations at 25 000 000 and a depth of E450. When it was done with the first key frame (it took 3 days, which is amazing), kalles fraktaler instantly created another (almost) 500 key frames which are only copies of the first one, and then (apparently) crashed. The first key frame was rendered correctly. I had the following settings:
Reuse reference
NO auto solve glitches
Auto iterations
Image size 2880×1620

It worked before with those settings because I had tested it, except the test render was only 800×450 and I started at less than half the depth to make the test take a reasonable time. I have removed all but the first two frames and resumed the render of the zoom out sequence.

[Kalles Fraktaler]

I started the rendering of a zoom out sequence from an extreme location with max iterations at 25 000 000 and a depth of E450. When it was done with the first key frame (it took 3 days, which is amazing), kalles fraktaler instantly created another (almost) 500 key frames which are only copies of the first one, and then (apparently) crashed. The first key frame was rendered correctly. I had the following settings:
Reuse reference
NO auto solve glitches
Auto iterations
Image size 2880×1620

It worked before with those settings because I had tested it, except the test render was only 800×450 and I started at less than half the depth to make the test take a reasonable time. I have removed all but the first two frames and resumed the render of the zoom out sequence.

That is bad, and hard to replicate for me.

I have never resumed a sequence from only one key-frame so I don't know if it works. I think it uses the last 2 frames to calculate the zoom level, so I hope you have selected 2 already?
3 days for the first frame is a long time on depth e450. The time to render following frames will decrease, but slowly and I think it will take many months to complete the sequence. (My 2-month render took a little more than 1 day on the first frame)

[Dinkydau]

Indeed it doesn't resume with just one key frame, so I assumed it needed at least 2 key frames to recognize the sequence.

The render time will be very long, but it's worth waiting for a good video. Is that 2-month render the zoom to a depth of e10000? You had many more frames to render for that one.

[Kalles Fraktaler]

Yes it was.
2 month was also the time for the infinite Julius tree, but I don't remember how long the first frame took.
But if it goes ok now it will indeed be fantastic to see the result of your render!
And you are not afraid of long time render, I know

[Chillheimer]

Hi Kalle!
I've got a problem here..
I just finished rendering a new beautiful sequence(with v2.2.6)
It's in 7680*4320, as it needed aliasing, I plan to use rotation and I want the final version in full hd.

But: Can it be that the movie maker(1.15) can't handle such file sizes? (.kfb-files are 256mb each, Pics around 30mb)
It keeps crashing after a few seconds.
The movie generated shows a pixely-hd version of the rotating first Frame, no zoom. The preview window shows the zooming until it crashes after around 10 seconds (at different points every try)
--
it also crashes when I deactivate rotation(resulting short movie just shows a standing version of the first frame), set the frames per movie to a low rate like 30 or use any codec availlable
--
It would be great if you find a solution for this.

regards,
chilli

[Kalles Fraktaler]

Hi Kalle!
I've got a problem here..
I just finished rendering a new beautiful sequence(with v2.2.6)
It's in 7680*4320, as it needed aliasing, I plan to use rotation and I want the final version in full hd.

But: Can it be that the movie maker(1.15) can't handle such file sizes? (.kfb-files are 256mb each, Pics around 30mb)
It keeps crashing after a few seconds.
The movie generated shows a pixely-hd version of the rotating first Frame, no zoom. The preview window shows the zooming until it crashes after around 10 seconds (at different points every try)
--
it also crashes when I deactivate rotation(resulting short movie just shows a standing version of the first frame), set the frames per movie to a low rate like 30 or use any codec availlable
--
It would be great if you find a solution for this.

regards,
chilli

Cool. You are really driving my program to extremes. And I like it very much, thanks a lot, it is pleasant challenges.

First I just want to say that at all times 6 key-frames are combined in FKMM, which results in that the center of the movie is antialiased with between 32x32 and 16x16.
The images are cached in memory, so your sequence requires 6*7680*4320*16 = 3GB, impossible to allocate for a 32-bit application.

But I would never criticize you and tell you to redo you render.
Instead I have a plan, KFMM should not allocate more than 1920x1080 (or maybe 3840x2160) or in memory and should do the antialiasing calculations.

I need some days to do this though, I hope you can wait?

[Chillheimer]

Cool. You are really driving my program to extremes. And I like it very much, thanks a lot, it is pleasant challenges.

It's your own fault, as you make all this possible 

But I would never criticize you and tell you to redo you render.
Instead I have a plan, KFMM should not allocate more than 1920x1080 (or maybe 3840x2160) or in memory and should do the antialiasing calculations.
I need some days to do this though, I hope you can wait?

Go ahead and criticize.. good feedback is always welcome
Of course I can wait! In the days of ultrafractal I had to wait that long just for one high quality render.. now I can make movies in the same time. I never seriously tried this before you program, because coming from audio, where a render takes max. as long as the file you render will be, I didn't even think of waiting several days or even weeks to finish a render. just to realize I made mistakes.
you shrinked the waiting time down just enough to make it worth the effort.
And I love it when it works as planned, and sometimes even better:
<a href="http://www.youtube.com/v/NedXxP3Uur0&rel=1&fs=1&hd=1" target="_blank">http://www.youtube.com/v/NedXxP3Uur0&rel=1&fs=1&hd=1</a>
The moment in the end, when the colour cycling seems to stay at the same point but you keep zooming in. For me this is magic, I hadn't dreamt of to be able to discover a year ago. thanks for that!

I think I'll do a rerender anyways, I'm so curious if my plan worked this time. The (see attached)stillframes are promising..
And it will just take a day, my cpu would be needlessly idling anyway

[Kalles Fraktaler]

That is a beautiful image and an amazing movie, with the cracked flakes that EricB inspired us.
So, maybe antialias in KF is more useful than being able to create huge image files then?

[Dinkydau]

This night I started rendering the same extreme zoom as defore, except with a lower magnification to find out what's going wrong. I had it start at 3.39974778864E298 which is exactly 2^500 less than the actual final magnification. This time another strange thing happened. I started my monitor this morning and noticed Kalles Fraktaler was not running anymore. This is the history:

1:21 The render started. Of the first frame, only the unfinished render that was on the screen was saved.
1:45 The second frame, and the first correctly rendered frame was saved
2:36 The fourth rendered frame was saved. The JPEG image shows an unfinished render with blobs. All the following JPEG files are EXACTLY the same (checked with md5 calculator).
9:06 Apparently the last frame, number 22, was saved at this time. Then Kalles Fraktaler crashed.

I have also checked the actual kfb files. They did show different md5 hashes, so I examined the zoom sequence. It looks like all the frames that were rendered were rendered correctly (except the first one). It's just he JPEG files that are wrong and the program crashed.

I made a backup of the rendered files thus far just in case, and resumed the render.

One more thing: I went to bed after the 3rd frame was saved, so it immediately went wrong when I was away. All I can remember that might somehow be it is that I minimized Kalles Fraktaler to the taskbar.

[Kalles Fraktaler]

Strange that the jpegs get the same, but they aren't necessary anymore, maybe I can discard them in future versions.
Sounds like the bitmaps in KF get corrupted/destroyed, I have seen it a couple of times but it was a while ago now.
It doesn't affect the iterations and smoothing data which are stored separately, but the program doesn't display the content correctly.
What resolution did you use? There is probably a maximum on 3840x2160, at least KFMM cannot handler higher resolution.

And I have discovered that it is not possible to do anti-aliasing (at least with reasonable effort currently) using the iteration count values and smoothing coefficients. It is easy to do anti-aliasing with the resulting RGB values to display images, but to make color cycling movies with various density, the iteration and smooth values are needed.

Next version will have a size limit, and check that reference reuse is not used with auto glitch correction, but currently I am not able to access my page to upload anything (however since my image is displayed, the site is working)