Kalles Fraktaler 2

[Kalles Fraktaler]

My web-page is working again and I have put new updates.
The frame editing function is approved a little to make it faster to browse the frames.
Please use it, take the time and go through every frame and solve all glitches

The bug regarding the initial rotation and cycling are fixed in the Key Frame Movie Maker program.

It's very rewarding to find movies on youtube and vimeo created with my program. Thanks!!

[panzerboy]

Good that your page is back up.
I was debating with myself wether to Sourceforge is still a suitable host to suggest.
The people that do GIMP the image processing software decided to remove it from Sourceforge because of deceptive "DOWNLOAD NOW" advertisements.

A small matter.

When Resuming a Zoom sequence KF2 uses that most recent number prefix again instead of incrementing, eg.

Code:

 Directory of C:\Users\panzerboy\Documents\Kalles Fraktaler\wal92_320x180

02/12/2013  02:20 p.m.            81,101 00158_1.13e074.jpg
02/12/2013  02:20 p.m.           463,895 00158_1.13e074.kfb
02/12/2013  01:56 p.m.            83,458 00158_2.26e074.jpg
02/12/2013  01:56 p.m.           463,895 00158_2.26e074.kfb

The later (resumed) file at 2:20pm has the same filenumber prefix "00158" perhaps it should be "00159"?

[Kalles Fraktaler]

Thanks panzerboy. I found that error with the file Annes also so it should be solved in the latest version, 2.1.6
I got an offer to host my page in a pm here, thanks for that I will keep that in mind if biphome disappears too often.

[Kalles Fraktaler]

I have done a thing I've been thinking about some time now to do, and that is to make a tutorial on how to make movies without glitches with my program. I hope this can be useful, even if I understand that it might be too rudimentary.
http://biphome.spray.se/karl.runmo/tutorial.htm

[SeryZone]

Hello! I have a problem with exploring. I explore is too deep place (final ~e900). Now I explore to e675 and... reference generates is too long. I try to find maximum iterations - 320,000, no more. When open iteration control window - more than 500,000 iterations was set automaticaly! I change to 320,000 and when zoom - and more than 500,000 iterations again! And problem that I can't turn off this expensive function...

[Kalles Fraktaler]

Hello! I have a problem with exploring. I explore is too deep place (final ~e900). Now I explore to e675 and... reference generates is too long. I try to find maximum iterations - 320,000, no more. When open iteration control window - more than 500,000 iterations was set automaticaly! I change to 320,000 and when zoom - and more than 500,000 iterations again! And problem that I can't turn off this expensive function...

I got many request of having the iteration count automatically, so I did.
But I can make it optional, possible to switch off?

[SeryZone]

I got many request of having the iteration count automatically, so I did.
But I can make it optional, possible to switch off?

If too many... Maybe yes...

[Kalles Fraktaler]

Another update

Kalles Fraktaler 2.2:
Glitch correction improved, which makes it more effective and not wasting so many references.
For example Dinkydau's tick-tock location only needs one reference, and previous version added several unnecessary references.
With this improvement my bold statement that my program is 70 times faster than the commercial programs is true also with automatic glitch correction on.
But since the glitch finding function is general, unnecessary references may still be added for other locations, especially near <-2,0i>

And some more menu options:
  Show smooth transition colors   Displays the image black-and-white representing the smoothing coefficient
  Use long double always            Use always the 80-bit long double hardware data type. This may solve some type of glitches, but is unfortunately 3-4 slower
  Use auto iterations                  Turns automatic iteration control on or off. This is on per default.

Key Frame Movie Maker
Color cycling with no iteration division made smoother

[Chillheimer]

Hi Kalle!
Nice to see that you keep the updates coming!

I have an issue with the latest version:
Zoom Sequence Export: with unchanged thread-priority, kalles fraktaler slows down pc extremely. (win 8, 64bit)
until the newest version I just set the priority in the task-manager to lower than normal, which worked fine.
Now this results in a freeze of kf.
------
edit: seems like it has nothing to do with the thread priority. It keeps freezing after 2-3 HiRes Frames (3840*2160) If I do the same thing in LoRes it works fine)
When freezing, kf goes down from 99% cpu usage to 10-12%, but doesn't do anything anymore. windows says the standard "application not reacting" if thats correctly translated from the german "keine Rückmeldung"
I don'T know what more info I could give you.. would the .kfr help? it's attached.
-----
edit 2:
I don't know exactly what caused this, but the freezed program came back to life and is rendering again now. I think i pressed the windows closing X and then it got back to work..
--edit 3:
it finished rendering the next frame, didn't safe and froze again.
doesn't work for me
----edit4:
the freeze happens exactly when the calculation of ref1 is finished.
--------------------

A bug (not new): Zooming out when the rendering is not finished results in a crash everytime. Which makes it hard to go back at all..

And a wish: is there any way you could implement sideway-'scrolling' into moviemaking?

and a second wish: please make the picture size completely customizable..

edit 398: one more wish: in normal browse mode, an ability to rotate the picture would be great

regards,  chilli

[Kalles Fraktaler]

Hi Chillheimer

Thanks for your notes.

Maybe this freeze is due to my attempts to improve the glitch handling. The numbers of pixels grow exponentially and I haven't tried that huge resolution.
But it did work before did it?

I usually turn automatic glitch correction off when I render zoom sequence and I also even check 'reuse reference' so that high precision is made in one point only. With the new ability to use long double all the way less glitches will occur even if the render will get slower. I then use the 'Examine' function to solve glitches afterwards instead.

I note the crash scenario and will look at it.
Please explain the sideway scrolling
I will have more time to look into this after christmas

[Chillheimer]

Hi Kalle!
I 'need' that huge resolution, because I make my videos in Full HD, using Rotation.
Yes it worked before, the last working version I have here (I overwrote the more recent ones with the updates) is 2.14. I'm using that to render the zoom frames now, and the newest version to correct the glitches. There the same strange behaviour as described occurs, but after some time of the program window "not responing" (while 99%cpu, so still calculating) I can save and go to next. So this works fine.

I'll try with automatic glitch correction of when the big render is done..

Different thinh: is there any way to speed up the calculation of the black areas of the main mandelbrot?
It already works very fast when zooming in manually but the same thing takes ages when calculating zoom-sequences.. (not sure if I already posted this one)

Sideways scrolling as opposed to zooming in, so no zoom, just scrolling left/right/up/down..
but maybe this is not necessary, if one could set the image size freely, I could make a pic with e.g. 10.000*1080 and move the 'camera' over the picture later from left to right.

No hurry! Pre-Christmas-Time is always so busy...

Regards!

[SeryZone]

Hey to all... You are talk about side-scrolling and I can't go by this. I try to write on Assembler Side-Scrolling render. It not hard. I can give delphi and ASM formulas writen by me. It without arbitrary calcs. Please, for details talk to me in personal (because I'm afraid and can't post my soft on forum).
Peace.

[SeryZone]

But... SS planes on perturbation - FASTEST IDEA ON EARTH!!! But... This idea needs donating, you, maybe, understand, why...

[Kalles Fraktaler]

Hi Kalle!
I 'need' that huge resolution, because I make my videos in Full HD, using Rotation.
...

Thanks again for your note. Of course I want you to be able to do really huge resolution movies! I have made an update on my site.
This will be the last update for this year, but maybe not last update ever
Merry Christmas to you all

[Kalles Fraktaler]

I have put another update on my web-page, version 2.2.2
It will be the last update for a while now I think, if not an obvious bug is found.

I haven't implemented requested functions like side-scrolling or rotation, the time I have managed to spend on this I've spent only on automatic glitch-solving.

And I have found a promising way of identifying glitches.
The following image is a detail of the location sent by hapf some posts ago.
This image have only one reference, in the center of the image:


One type of glitch is marked with 1, another one with 2 which is probably but not surely the same as 3, these glitches are areas with one color/iteration count, shown as big one-color blobs.
A big area with correctly one color/iteration count is marked with 4.
So how to find that 1, 2 and 3 are glitches but not 4???
The float error detection show nothing in this image.
The iteration count it not good enough either, since the iteration count in 4 is actually higher than 3, as indicated in this image with lowest iterations as black and highest as white:


I have rather newly added a smooth color transition function to my program.
This smooth color transition coefficient, used to blend the iteration count color with it's neighbor color, is calculated from ( |Z[n]|-2 ) / ( |Z[n]| - |Z[n-1]| ) (but maybe the standard function log ( log ( |Z[n]| ) ) / log(2) also could work). This is because I wanted a coefficient number between 0 and 1 in order to blend one index color with the next index color. I thought "how close was the previous iteration to reach bailout" (a.k.a Runmo-coloring )
Now look at how these coefficients looks when lowest value is black and highest white:

Glitch 1, 2 and 3 are clearly shown as one color blobs, and the big area 4 has a distinct gradient color from white to black.
By combining the one-iteration count area with the smooth coefficient value, the glitches can be identified and ideally only 2 more references need to be added to create the final image


Of course it is not that easy, and there are many situation where the coefficient blobs don't have the same value all over, or don't lies exactly on the same area as the one iteration count blob. And fine tuning one image makes another image not work. I have some 30 different locations that I go through every time I do a change, and I also have a couple that I still cannot solve automatically, for example Dinkydau's Flake.
But the improvement is still significant and much better than only examine iteration counts or float calculation errors.
The float calculation errors maybe I should have removed since it doesn't work well and it makes the render much slower.
And on some locations the glitches can be solved only when long double is used always because of incorrect pattern appears on the blobs, or the smoothing coefficients doesn't have the same values in the blob area.