Title: Kalles Fraktaler 2 Post by: Kalles Fraktaler on June 24, 2013, 11:57:00 AM http://www.chillheimer.de/kallesfraktaler
(http://www.chillheimer.de/kallesfraktaler/screen.png) Unlimited* pertubation exploration of the Mandelbrot Fractal (* = current limit is e100000) From 1 to e600 the ordinary double datatype is used. From e600 to e4920 long double is used, which is 3,5 times slower. From e4920 to infinity, a custom datatype is used, with the same precision as double, and this is about 10 times slower than the double datatype. However it is still very fast compared to ordinary Mandelbrot rendering. - The glitches can be avoided by going a little deeper than the location of interest. Then select "Reuse reference" and go back up. - Animations are only stored as a list of jpeg images. You need the other program in the zip to create avi files. - The UI is unfortunately not fully worked through and intuitive, I hope you find out how the program works Many improvements has been added due to the excellent collaboration on this forum. Thanks to all that has given feedback, published result or ever used Kalles Fraktaler! :thanks1: My humble thanks goes to mrflay for sharing his mathematical findings! And to Botond for sharing extensions of series approximation etc And to pauldelbrot for sharing his glitch detection method And to knighty for series approximation formulas for higher power Mandelbrot And to laser blaster for the burning ship perturbation formula And to Dinkydau for the locations in the gallery Without this forum and your contributions this software could never been made. My contribution is small in comparison, since Kalles Fraktaler is just a collection of the amazing discoveries and methods you found! Title: Re: Kalles Fraktaler 2 Post by: cKleinhuis on June 24, 2013, 12:16:16 PM nice, but the program crashes right after the first click and zoom :( its just a 2ghz 32bit laptop, but i thought i mention it
Title: Re: Kalles Fraktaler 2 Post by: cKleinhuis on June 24, 2013, 12:19:09 PM on a second try it worked better, but it was really hard to reach an interesting deep zoom location ;)
can you include some nice deep zoom locations ? Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on June 24, 2013, 12:46:32 PM It should work fine on your old laptop, it works fine on mine.
Why is it hard for you to reach interesting deep locations, is it due to the nature of that deep locations are deep? ;-) Take a look at Dinkydau and others images in the art section of this forum, you can find location parameters for many of them there and paste them in. Title: Re: Kalles Fraktaler 2 Post by: blob on June 24, 2013, 12:49:00 PM Systematic crash on trying to resize the program window.
The max iteration thing doesn't seem to work too well as I can't seem to be able to zoom in and always have a detailed render despite increasing it manually. Title: Re: Kalles Fraktaler 2 Post by: cKleinhuis on June 24, 2013, 01:11:55 PM it happened when it was in full screen window mode
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on June 24, 2013, 01:26:30 PM Systematic crash on trying to resize the program window. Yes Max iterations is only manual, and when resizing you need to press F5 to refresh before you can zoom further... The max iteration thing doesn't seem to work too well as I can't seem to be able to zoom in and always have a detailed render despite increasing it manually. Sounds like there are many improvements that needs to be done ;) Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on June 24, 2013, 01:58:25 PM Thanks for the bug reports! This is spare time programming so please have indulgence with the quality not being perfect.
I've made a small fix since I realized that it was not possible at all to resize the window. Unfortunately I had to reduce the maximum depth to e20000, since the problem was a stack-overflow. This can be corrected later, if e20000 is to low, by increasing the stack, which takes a little more programming. Title: Re: Kalles Fraktaler 2 Post by: elphinstone on June 24, 2013, 03:09:28 PM Unfortunately I had to reduce the maximum depth to e20000, since the problem was a stack-overflow. This can be corrected later, if e20000 is to low, by increasing the stack, which takes a little more programming. I have no idea what your code looks like, but if too deep zooms cause a stack overflow it means that you are making a large use of recursion, right? CPUs are very good at managing it, but a high level of recursion means also a lot of function calls, which could lead to unnecessary overhead... and that's probably not what you want. ;) Are you sure that you cannot avoid recursion? Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on June 24, 2013, 03:24:03 PM Awesome! I am going to try it right now.
You made a typo on your website: Quote which I think is as big discovery as the Mandelbrot forumla Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on June 24, 2013, 03:31:25 PM I have no idea what your code looks like, but if too deep zooms cause a stack overflow it means that you are making a large use of recursion, right? CPUs are very good at managing it, but a high level of recursion means also a lot of function calls, which could lead to unnecessary overhead... and that's probably not what you want. ;) No recursion is used. Instead the arbitrary precision variables have all their decimals fixed allocated on the stack, which makes it maybe 100 times faster than allocating the array on the heap. The stack is 1MB default, and each variable is 20kb for 20000 decimal precision. For 30000 it did not fit. It is possible to have lagrer stack size though...Are you sure that you cannot avoid recursion? Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on June 24, 2013, 03:49:35 PM Unfortunately I can't get the program to do anything at all. I'm using windows 7. When I start the program, it runs for a few seconds with very high CPU usage and I can't do anything, then it crashes and CPU usage goes to 0.
Title: Re: Kalles Fraktaler 2 Post by: elphinstone on June 24, 2013, 04:00:56 PM No recursion is used. Ok sorry :) Then yes, you can increase the stack size. Usually it's just a compiler option but I'm not sure if it applies to child threads stacks too... If not you should be able to specify the size when you create the thread, but it depends from the libraries you are using. Nice software anyway! Looking forward to see new zooms! Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on June 24, 2013, 04:08:20 PM Unfortunately I can't get the program to do anything at all. I'm using windows 7. When I start the program, it runs for a few seconds with very high CPU usage and I can't do anything, then it crashes and CPU usage goes to 0. Don't you even see the first zoom 1 mandelbrot?Do you have 64-bit? Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on June 24, 2013, 04:16:31 PM Hmm, I just downloaded it on my laptop which has windows 64-bit just like my desktop computer, and it works now. That means it's probably a problem on my end. I also had a similar problem with skype before. Maybe I'm missing some kind of framework or something.
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on June 24, 2013, 06:35:03 PM It might be that your desktop pc doesn't have msvc60.dll or something like that in the system directories, which used to be included by default since w2k. However it should generate an error message saying so if it is due to missing libraries. I will compile a 64-bit version later that also hopefully will be faster
Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on June 24, 2013, 07:16:59 PM Neither my desktop nor my laptop have that dll file. I do have various msvcp
Code: 1 VERSIONINFO When fraktal_sft.exe crashes, I get the following entry in the event viewer Code: Faulting application name: fraktal_sft.exe, version: 0.0.0.0, time stamp: 0x51c83287 I don't know if it's useful, just posting it. I also installed the full version of .net framework 4.5 which didn't help. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on June 24, 2013, 07:42:05 PM No I don't understand those error dumps. I do C++ so .net is not applicable. I have now added a 64-bit version to my site, hope it works without problem.
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on June 24, 2013, 07:45:28 PM There might also be a permission issue in win7 that makes the program crash:
http://social.technet.microsoft.com/Forums/windows/en-US/cb8a6fd1-9cc6-4c14-9f0d-e280a1acb02d/exception-code-0xc0000005 Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on June 26, 2013, 12:31:02 PM can you include some nice deep zoom locations ? I've added a "Gallery" zip file with some parameter files and jpeg images, to my site http://biphome.spray.se/karl.runmo/fraktal2.htmMost of the images are from Dinkydau's locations, I hope he don't mind. The location "flora-fantasy" is special since it requires zooming a bit further, select "Reuse reference" and then zoom back in order to get rid of the pertubation glitches and make it look like the included jpeg image. There is also a zoom to e600, which takes about 15sec to render on my machine with the default window size, 640x360. And a zoom to e601, which takes about 60sec to render with the same window size, which is about 4 times slower. This shows the border between ordinary double and my own datatype. I hope that 60 sec is still much faster than what the old programs (fractal extreme) perform? I have also included a file with e1000 :o Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on June 27, 2013, 01:40:11 AM The speed at which it renders "tick tock" and "integral of..." is really good, but the render time certainly does still depend a lot on iterations/depth. I inserted coordinates of the minibrot that I posted in this thread:
http://www.fractalforums.com/mandelbrot-and-julia-set/smallest-midget/15/ It's at a depth of E892. Renders really, really slowly... I don't think I will approach the limit of e20000 anytime soon. Maybe a bug: I'm currently rendering this location, but it doesn't show progress here. It doesn't even keep the time, but it still renders. User friendlyness could be greatly improved by making the program render pixels in the center first, then go outward. It makes zooming much easier. I see it already makes an approximation first by rendering one out of x pixels, and then the rest. If you add more stages, such as a very rough approximation first, and then more and more refined, makes it even easier. Maybe the limit of e20000 could be extended. :D (Or, I could say: imitate how the zooming fractal extreme works, I really think it's the ideal method.) Question: on the bottom of the program there's that line with: x%,R:y%,G:z% x is progress of the entire render, y is progress of calculating the reference point, z is percentage of guessed pixels? Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on June 27, 2013, 10:03:26 AM Yes it is still dependent of the number of iterations. How many iterations are there in the e892 location?
I have unfortunately no idea of how to render from center and out currently. Yes the percentages is what you wrote. Title: Re: Kalles Fraktaler 2 Post by: blob on June 27, 2013, 12:01:31 PM Thanks for fixing the window resize bug, working fine now.
The max iteration issue I often encounter remains however, using F5 helps a bit sometimes but most often it does not and renders are insufficiently detailed in places, generally at the center. Basically it seems that the program determines automatically the maximum amount of iterations it performs which often is not enough to render a fully detailed image, and this of course when the absolute max number of allowed iterations has been set manually to a much higher value. Is there something you could do about that such as allowing to override its automatic amount of iteration choice and force it to perform more of them? I understand that zooming further in, using the reuse reference command and zoom back out is what should be done in those cases (is this correct), but often several zooms are necessary before more iterations are performed and zooming out appears quite glitchy/buggy here, so it doesn't work too well. Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on June 27, 2013, 02:50:02 PM Yes it is still dependent of the number of iterations. How many iterations are there in the e892 location? I had the max iterations set to 1 400 000 iterations.I have unfortunately no idea of how to render from center and out currently. Yes the percentages is what you wrote. I wanted to test the zoom limit of the program by zooming very far into (-2 ; 0i), so I entered these coordinates and a zoom level of 10E3000. The result was the whole screen filled with the same color. I thought it may be a problem with the reference point, so I tried 10E1000, didn't work, and then 10E20, but that also didn't work. So I started zooming manually to see where it would go wrong, and it did not go wrong at all zooming manually. I set the coordinates and zoom level to (-2 ; 0i) and 10E20 and I got the screen filled with a single color again. This time I tried to zoom out and see from where on it would begin to be normal. The program crashed. So apparently when you insert the coordinates (-2 ; 0i) and some zoom level, not even deep, the program just stops working correctly. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on June 27, 2013, 03:36:18 PM Thanks for fixing the window resize bug, working fine now. It's not a bug, it's a feature ;)The max iteration issue I often encounter remains however, using F5 helps a bit sometimes but most often it does not and renders are insufficiently detailed in places, generally at the center. Basically it seems that the program determines automatically the maximum amount of iterations it performs which often is not enough to render a fully detailed image, and this of course when the absolute max number of allowed iterations has been set manually to a much higher value. Is there something you could do about that such as allowing to override its automatic amount of iteration choice and force it to perform more of them? I understand that zooming further in, using the reuse reference command and zoom back out is what should be done in those cases (is this correct), but often several zooms are necessary before more iterations are performed and zooming out appears quite glitchy/buggy here, so it doesn't work too well. My program does not try to figure out where the best reference point is, it is only trying to render as fast as possible, also beyond the e308 and e616 boundaries. One have to understand the behavior of the pertubation rendering with reference points, and use the program with this in mind. So I am sorry, my program is not easily accessible and is not a candidate for replacing fractal extreme and others when it comes to the user experience in finding nice locations, and there are certainly many location not accessible in this program, that are accessible in fx and others. However with it locations not accessible with other programs can be found, at depths never visited before! :) I had the max iterations set to 1 400 000 iterations. Your E892 location is a nasty one, and I will have to look into it in detail. I had it half rendered in 1,5 hour, however it seems to stop in the middle without reason. Maybe something is crashing. How long does it take to render it in fx?I wanted to test the zoom limit of the program by zooming very far into (-2 ; 0i), so I entered these coordinates and a zoom level of 10E3000. The result was the whole screen filled with the same color. I thought it may be a problem with the reference point, so I tried 10E1000, didn't work, and then 10E20, but that also didn't work. So I started zooming manually to see where it would go wrong, and it did not go wrong at all zooming manually. I set the coordinates and zoom level to (-2 ; 0i) and 10E20 and I got the screen filled with a single color again. This time I tried to zoom out and see from where on it would begin to be normal. The program crashed. So apparently when you insert the coordinates (-2 ; 0i) and some zoom level, not even deep, the program just stops working correctly. What an excellent way of testing the depth limit! I just tried that and it worked without problem. Maybe you need to restart the program and try again.I could just type in -2, 0, 1E10000, then use the automatic Find Minbrot and let it run over night, and then create an E20000 movie. But that would be a very boring move. Title: Re: Kalles Fraktaler 2 Post by: cKleinhuis on June 27, 2013, 03:38:04 PM i would be interested in concrete speed comparisons... :)
Title: Re: Kalles Fraktaler 2 Post by: blob on June 27, 2013, 05:25:49 PM It's not a bug, it's a feature ;) I don't encounter that issue using SFT, or at least very considerably less, so what you're saying doesn't make that much sense to me, I am sure there is room for improvement in your implementation in that respect.My program does not try to figure out where the best reference point is, it is only trying to render as fast as possible, also beyond the e308 and e616 boundaries. One have to understand the behavior of the pertubation rendering with reference points, and use the program with this in mind. So I am sorry, my program is not easily accessible and is not a candidate for replacing fractal extreme and others when it comes to the user experience in finding nice locations, and there are certainly many location not accessible in this program, that are accessible in fx and others. However with it locations not accessible with other programs can be found, at depths never visited before! :) Will you be implementing the antialiasing algos there is an SFT too? Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on June 27, 2013, 08:22:14 PM I don't encounter that issue using SFT, or at least very considerably less, so what you're saying doesn't make that much sense to me, I am sure there is room for improvement in your implementation in that respect. Yes there is always room for improvements. But my first goal was to be able to make a new depth record and that I did ;)Will you be implementing the antialiasing algos there is an SFT too? http://www.fractalforums.com/images-showcase-(rate-my-fractal)/deep/ Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on June 27, 2013, 08:26:11 PM Your E892 location is a nasty one, and I will have to look into it in detail. I had it half rendered in 1,5 hour, however it seems to stop in the middle without reason. Maybe something is crashing. How long does it take to render it in fx?What an excellent way of testing the depth limit! I just tried that and it worked without problem. Maybe you need to restart the program and try again. Your program is definitely faster. A 1280×800 render of almost the same minibrot at a slightly greater depth (E914) took fractal extreme 15h 45m on my desktop computer. My laptop would have finished the default resolution render of the E892 minibrot in maybe 1,5 hours, but that's an estimate. A speed comparison is still a good idea:I could just type in -2, 0, 1E10000, then use the automatic Find Minbrot and let it run over night, and then create an E20000 movie. But that would be a very boring move. i would be interested in concrete speed comparisons... :) Because I cannot use Kalles fraktaler on my desktop and I cannot use a very deep location in SuperFractalThing, and I know all of them work well with Tick Tock, let's use that to test the speed. I'm going to test right now.Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on June 27, 2013, 08:59:39 PM Because I cannot use Kalles fraktaler on my desktop Since I haven't made any installation file that puts the program in the folder "program files" you need to run it as administrator or in xp-mode in win7. Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on June 27, 2013, 09:04:16 PM Settings:
Resolution: 640×360 Coordinates: Code: Re = -1.479,946,223,325,078,880,202,580,653,442,563,833,590,828,874,828,533,272,328,919,467,504,501,428,041,551,458,102,123,157,715,213,651,035,545,943,542,078,167,348,953,885,787,341,902,612,509,986,72 2^471 6.0971651373359223269171820894398 E141 Test results:
SuperFractalThing time was measured with a clock, so it's not as accurate as the others. The reason is that while the dialog window is opened to save the PNG file, the timer still counts (I just noticed). An important factor is the time it takes to calculate the reference point. The fewer pixels rendered, the more influence that the reference point has on the total calculation time. Both SuperFractalThing and Kalles Fraktaler would score better if the resolution was larger, especially SuperFractalThing because of the short total time. This explains the different speed-up factor from my previous test in the SuperFractalThing topic. Big differences, what is it that SuperFractalThing does better? Title: Re: Kalles Fraktaler 2 Post by: cKleinhuis on June 27, 2013, 09:20:58 PM thank you for the numbers, SFT is incredibble !
i have no clue what it does better, i hadnt had the time to look a slightest into it, *offtopic*because of a little flood here in my house that destroyed my beloved main computer, aaaargh, this weekend show recording and cutting with ultra slow laptop :( Title: Re: Kalles Fraktaler 2 Post by: cKleinhuis on June 27, 2013, 09:22:13 PM but it might have to do with the fact that you just use equation (1) ;)
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on June 27, 2013, 10:06:30 PM Thanks for the comparison. It shows that algorithm and optimization is more important than language. I have some fun optimization in front of me :)
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on June 28, 2013, 10:22:15 AM Pauldebrot mentions in the other thread that my program lack "series approximation", which SFT and the program he is making will have. I don't know what he means but maybe that can explain the difference in performance. I would like to know what this is.
Dinkydau, was it the 32-bit or 64-bit version of Kalles Fraktaler you used? Title: Re: Kalles Fraktaler 2 Post by: claude on June 28, 2013, 04:40:24 PM my program lack "series approximation".... I would like to know what this is. That's the later equations in the sft maths pdf: the idea is that you compute A,B,C for the reference point, then initialize all the pixels in the image using that - which allows you to skip the first bunch of iterations completely for all the pixels. I think that if the reference point has period P, then you can skip the first 2P iterations of equation 1 for every pixel. SFT uses recursive subdivision, but I haven't yet worked out how much of an extra win that is. Dinkydau's coordinates has partials: 1 2 4 6 12 106 220 326 652 1304 2908 5516 11032 22064 So I think it'd be around an island with period 5516 (as the later two partials are exact multiples of it), so you could skip the first 11k iterations of eq1 for each pixel... Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on June 28, 2013, 06:15:02 PM thank you for the numbers, SFT is incredibble ! Oh, that's not nice. I hope you haven't lost much important data.i have no clue what it does better, i hadnt had the time to look a slightest into it, *offtopic*because of a little flood here in my house that destroyed my beloved main computer, aaaargh, this weekend show recording and cutting with ultra slow laptop :( Pauldebrot mentions in the other thread that my program lack "series approximation", which SFT and the program he is making will have. I don't know what he means but maybe that can explain the difference in performance. I would like to know what this is. I used the 64-bit version.Dinkydau, was it the 32-bit or 64-bit version of Kalles Fraktaler you used? Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on July 05, 2013, 09:10:08 AM I have updated my program, now series approximation is used.
My goal is not to create the smartest application, others are working with that. Instead I want my application to be able to create deep zoom animations as fast as possible. And it is now a little faster than SFT. Enjoy :) Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on July 05, 2013, 12:15:58 PM 4,518 seconds!!!
So the new test results are:
Title: Re: Kalles Fraktaler 2 Post by: cKleinhuis on July 05, 2013, 12:56:55 PM congrats, now its getting interesting ;)
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on July 05, 2013, 02:09:42 PM That's really great! (your computer is twice as fast as mine ;))
With series approximation 33097 iterations are skipped for each pixel, which is almost 3/4 of all iterations. Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on July 05, 2013, 05:23:11 PM It still doesn't work on my desktop, but it looks like something has improved. The program first renders the mandelbrot set and then crashes, instead of immediately. While it's rendering, I can access the menus, but the time is too short to do anything.
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on July 05, 2013, 08:36:32 PM Strange, and it does work on your laptop. And the difference is that your desktop is running Windows7 and your laptop some other version...
The current location is stored for each zoom click, so that if the app crash it should be possible to recover the position. But storing a file in the same directory as the application should not cause it to crash... Title: Re: Kalles Fraktaler 2 Post by: klixon on July 08, 2013, 01:14:47 PM Strange, and it does work on your laptop. And the difference is that your desktop is running Windows7 and your laptop some other version... The current location is stored for each zoom click, so that if the app crash it should be possible to recover the position. But storing a file in the same directory as the application should not cause it to crash... It might if your program installs into one of the "program files" directories, or other directories protected as "windows" or "system" directories. DinkyDau, have you tried running the programs as administrator? (right-click the shortcut/executable and choose "Run as administrator..." Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on July 08, 2013, 01:55:39 PM Yes, I did that. I tried everything.
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on July 08, 2013, 05:29:49 PM Does the event viewer tell anyting?
Are you able to run the 32-bit version? The difference between the 32- and the 64- bit versions is much less now with series approximation, on my machine tick-tock is rendered in 8 seconds with 64 and 11sec with 32. Unfortunately I don't have any access to win7... I discovered a bug preventing >e300 animations to be created, which I have solved. Latest version is 2.0.3 Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on July 08, 2013, 09:24:03 PM The 32-bit version behaves the same as the 64-bit version. Both crash the same way. Event viewer doesn't tell anything except what I already posted on page 2.
New version, new chances, so i have downloaded the new version 2.0.3, but unfortunately it's still the same. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on July 09, 2013, 11:53:50 AM It might be something with freeing memory when rendering is complete. I will have a look when I'm in front of the computer in a couple of days.
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on July 10, 2013, 07:55:18 PM The 32-bit version behaves the same as the 64-bit version. Both crash the same way. Event viewer doesn't tell anything except what I already posted on page 2. I am sometimes careless when I call delete on pointers, arrays should be delete [] but it is usually not important on simple datatypes. The behaviour you describe make me suspect that this is the reason, so I have gone through the code and added [] on all delete of arrays. I hope this solves the problem...New version, new chances, so i have downloaded the new version 2.0.3, but unfortunately it's still the same. Title: Re: Kalles Fraktaler 2 Post by: cbuchner1 on July 10, 2013, 08:21:20 PM Oh, a C++ implementation!!
I would be very curious how currently the C++ code in the central loop of the program looks like. Is this using any SSE2 or AVX instruction sets yet? (For double precision computations, a speed-up of factor 2 respectively 4 could be expected) I have some experience with SSE2 intrinsics on the GCC and Microsoft Visual C++ 2008 and 2010 compilers. Using intrinsics means you don't have to go to the low level of assembly language. The compiler remains in charge of register allocation. Also the intrinsics code can be neatly wrapped into a C++ class, so the regular arithmetics operators (+ - / *) can be used on such vector registers. Let me know if you need any assistance. Christian Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on July 10, 2013, 09:58:53 PM Oh, a C++ implementation!! I don't know much of SSE2 or AVX.I would be very curious how currently the C++ code in the central loop of the program looks like. Is this using any SSE2 or AVX instruction sets yet? (For double precision computations, a speed-up of factor 2 respectively 4 could be expected) I have some experience with SSE2 intrinsics on the GCC and Microsoft Visual C++ 2008 and 2010 compilers. Using intrinsics means you don't have to go to the low level of assembly language. The compiler remains in charge of register allocation. Also the intrinsics code can be neatly wrapped into a C++ class, so the regular arithmetics operators (+ - / *) can be used on such vector registers. Let me know if you need any assistance. Christian It would be really cool if you could do your magic on my floatexp class and increase it's performance, I have attached it to this post (renamed from .h to .txt - I was a little lazy and implemented as a header file only) It is using a double as the mantissa and an integer as exponent, and is invoked when zoom is deeper than e300, to overcome the limitation of the exponent of the ordinary double. It is currently four times slower than the ordinary double... Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on July 10, 2013, 10:45:06 PM I am sometimes careless when I call delete on pointers, arrays should be delete [] but it is usually not important on simple datatypes. The behaviour you describe make me suspect that this is the reason, so I have gone through the code and added [] on all delete of arrays. I hope this solves the problem... It still crashes. Could it have explained that it works on my laptop with almost the same version of windows? It works on my laptop with home premium but not on my desktop with ultimate. That means it's probably not an error in your code. I think it has to be something weird, maybe even something with my own computer. The best way to test would be to reinstall windows, keep it fresh, instal only Kalles Fraktaler and see if it crashes, but that's a lot of work and I'm rendering at the moment. I might do it, though.Title: Re: Kalles Fraktaler 2 Post by: knighty on July 10, 2013, 10:57:15 PM @Dinkydau: have you tried to run it in compatibility mode?
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on July 10, 2013, 11:57:53 PM It still crashes. Could it have explained that it works on my laptop with almost the same version of windows? It works on my laptop with home premium but not on my desktop with ultimate. That means it's probably not an error in your code. I think it has to be something weird, maybe even something with my own computer. The best way to test would be to reinstall windows, keep it fresh, instal only Kalles Fraktaler and see if it crashes, but that's a lot of work and I'm rendering at the moment. I might do it, though. I searched on google and found that it is possible that a program crash when it tries to write to a file in any restricted folder.So I have now removed the automatic saving of location for recovery. New version (2.0.5), new hopes... Title: Re: Kalles Fraktaler 2 Post by: marius on July 11, 2013, 08:29:56 AM I don't know much of SSE2 or AVX. It would be really cool if you could do your magic on my floatexp class and increase it's performance, I have attached it to this post (renamed from .h to .txt - I was a little lazy and implemented as a header file only) It is using a double as the mantissa and an integer as exponent, and is invoked when zoom is deeper than e300, to overcome the limitation of the exponent of the ordinary double. It is currently four times slower than the ordinary double... Can't you get a O(1) align by looking at the double as int64 and fiddle with the exponent bits directly? All those base 10 operations don't come naturally to computers. http://en.wikipedia.org/wiki/Double-precision_floating-point_format (http://en.wikipedia.org/wiki/Double-precision_floating-point_format) Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on July 11, 2013, 08:09:55 PM I searched on google and found that it is possible that a program crash when it tries to write to a file in any restricted folder. That's not it either.So I have now removed the automatic saving of location for recovery. New version (2.0.5), new hopes... Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on July 12, 2013, 10:13:19 AM That's not it either. That's bad, I have no more ideas currently Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on July 12, 2013, 01:38:20 PM Can't you get a O(1) align by looking at the double as int64 and fiddle with the exponent bits directly? All those base 10 operations don't come naturally to computers. Yes, I have had that thought. However then it would be tricky to convert from the arbitary precision library to floatexp. The best would be if both floatexp and CFixedFloat would be 2 based...http://en.wikipedia.org/wiki/Double-precision_floating-point_format (http://en.wikipedia.org/wiki/Double-precision_floating-point_format) Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on July 29, 2013, 05:11:39 PM I've made an update, version 2.0.6, with an automatic glitch correction function:
http://biphome.spray.se/karl.runmo/fraktal2.htm I didn't want to do this at first, since it takes efforts to implement it and slows down rendering, but the improvement in the exploring experience is too great to be ignored. ;) The rendering time gets about 1 second longer for "tick-tock", so it is possible to turn off this function. This function is not available for zoom animations (yet?) The glitch function, even not 100% perfect, has been stressed with the two locations on this link: http://www.fractalforums.com/images-showcase-(rate-my-fractal)/other-worlds'-frightening-digital/ Title: Re: Kalles Fraktaler 2 Post by: blob on July 29, 2013, 07:44:31 PM I was waiting for it, it's great, thanks. :beer:
Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on July 30, 2013, 12:37:08 AM Great, that is very critical to make your program suitable for exploring. It's still difficult to go extremely deep, like really extreme. If you could manage to let it start rendering from the center and in stages, or not even in stages, that would make a very huge difference.
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on July 30, 2013, 08:39:30 PM I just got an idea of having the threads pick pixels from a central pixel managing class instead of managing their own sections.
It was fairly easy to implement and don't affect performance, so I have made another update, 2.0.9. Don't have too big expectations though, since my way of correcting glitches requires you to wait until the whole picture is done before the glitches are corrected. Title: Re: Kalles Fraktaler 2 Post by: hapf on August 07, 2013, 04:14:41 PM How do you detect glitches? All pixels with the same number of iterations?
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on August 07, 2013, 04:39:45 PM How do you detect glitches? All pixels with the same number of iterations? Yes, I find the largest area with the highest, and the same, iteration count. The blobs must be at least 3x3 pixels. So this is more a visual than a mathematical search and it is not able to handle all cases. Title: Re: Kalles Fraktaler 2 Post by: Chillheimer on September 18, 2013, 11:28:54 PM Hello!
First of all: Thank you so much for your dedicated work and sharing it with us all here! and for free! It's incredible. The unbelievable speed - it's a paradigm shift, I'm shure Benoit would have loved to see that! You're doing great work! and all that with just 240kb of code!!! it's mindblowing! I just discovered your program yesterday - browsing youtube-zoom videos. I couldn't believe how any machine could render videos that deep. And mistakenly thought Kalles Fractaler was the name of one guy, not a program. Ah, what a good day, and I've been having lots of fun with the program... :D fractal xtreme has been rendering for days on one image not that deep - and I've been diving deeper and deeper on my old laptop with kalles fractaler... :) But lots of questions emerge.. I hope this is the right place to ask them.. 1.is there any sort of manual? there are quite a lot of parameters that I don't know how to handle or understand. 2.how can i influence size beyond my screen? all I seem to be able is to pull the window open as far as possible. and is there a anti aliasing feature? -edit- found out at youtube, that antia aliasing works through the backwards-rendering. still: how can I do this for a single picture? 3.how can I slow down zoom movies below 1 percent? I want to achieve a tranquil movement and don't know how to do this.. (i use virtual dub to put together the jpgs, correct starting point?) 4. where can i remove the written zoom-level top left? 5. more to come :embarrass: As I come from fractal extreme, I'd like to mention some feature wishes that I really miss. I don't want to bug you with stuff - it's already incredible! but maybe some feedback what people would like to see is appreciated? I'd actually really would like to pay a fair amount for this programm, even more so if I had some minor(?) features added.. I'll just toss them in here: -colour cycling (esp. in video) -rotating in videos -a good way to find the right zoom tempo in videos, right now it seems to be guessing or calculating? some sort of fixed number like in fractal extreme, where I now 0.8 is my favourite speed.. -- variable zoom tempo for interesting regions would be a blast! -an automatic max-iteration finder (find highest iteration does not do anything here, I dont see anything happening) to set the number of max iterations at an optimum to save processing? -box-zooming, drawing the size of a box to zoom in, or even better, mousewheel zooming.. - more to come ;) Anyways, again, thank you for the great work! :) cheers, chilli ps: what is that sideway view of the mandelbrotset called? where you see the zooming in-movement on a "spectrogramm"-like view from left to right? Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on September 19, 2013, 10:05:19 AM Hi Chillheimer, thanks for your kind words! :)
Fraktal is swedish for fractal, Fraktaler is plural, and Kalle is a common swedish nick-name for my name Karl, therefore Kalles Fraktaler, not a fancy name at all, I know... I have made many updates on the program since the latest release but I haven't put it available on my web-page yet. I was kind of waiting until someone would ask, also to know if anyone was using it at all. If no one is using it, I would not made any updates available ;) Feedback is very appreciated. But I don't want to charge for my program. It would give me responsibility and this is only a hobby program so I may not always be available to correct things. The big job is made by K.I.Martin that shared the pertubation and series approximation methods, and he shared for free. And... I wont make a fortune anyway... ;) 1. No manual yet, I should perhaps put a description on my web-page. Some of the menu items are there for only my debugging. 2. You can store a jpeg image in any size, but then you cannot manually correct glitches. I've already separated the image from the window size, so it would be possible to have them managed separately. If image shrinking can be considered anti-aliasing? 3. I have now abandoned my previous video frame rendering method and are currently doing it the same way as fx, with key frames for every power of 2. But that requires another program that creates the movies by combining the frames, I have made such program but it does not have any UI yet. 4. :D With the power of 2 rendering the other program set this text instead. Don't you want it? I think this text is a main part of my fascination of the infinity of the Mandelbrot set though. 5. Colour cycling. Interesting, could be done also with the power of 2 method, if also the iterations for every pixel is stored... 6. Rotating, could perhaps be done in the video creating program, but with the cost of using only the center of each frame image... 7. With the power of 2 method it is easier to control the speed, at least per frame, and it can be as slow as wanted. It makes it also possible to correct and replace frames with glitches that were not automatically corrected. 8. Find highest iteration just puts the cursor over the pixel with the highest iteration and was used for debugging. The Find Minibrot function handles maximum iterations automatically, so the same could be used when exploring. 9. Box-zooming, isn't that already there? And I don't even have a mouse on my laptop, and no mouse wheel... I am not sure the sideview turned out that good, did it? Cheers Title: Re: Kalles Fraktaler 2 Post by: Chillheimer on September 19, 2013, 11:08:05 AM Feedback is very appreciated. But I don't want to charge for my program. It would give me responsibility and this is only a hobby program so I may not always be available to correct things. The big job is made by K.I.Martin that shared the pertubation and series approximation methods, and he shared for free. And... I wont make a fortune anyway... ;) I understand that..If you're in contact with K.I.Martin, please send him greetings and huge thanks! I don't understand how this new method doesn't create a huge fuss in this forum. It is at the core of what happens here and nearly noone seems to be interested... very strange. probably because everyone is so much focussed on 3d-fractals now. but I guess the time will come, then you and mr. Martin will be overwhelmed with praise ;) btw, do you think that method will work for 3d too? 1. No manual yet, I should perhaps put a description on my web-page. Some of the menu items are there for only my debugging. --yeah, please do! or if it is easier, a short mouseover-description would be enough 2. You can store a jpeg image in any size, but then you cannot manually correct glitches. I've already separated the image from the window size, so it would be possible to have them managed separately. If image shrinking can be considered anti-aliasing? --I don't know, but don't think simple shrinking has the same effect. but I'm sure a graphic program can shrink with anti-aliasing, so the possibility to render big images is already a workaround. :) but how do you set the size then, could you please descibe it shortly? 3. I have now abandoned my previous video frame rendering method and are currently doing it the same way as fx, with key frames for every power of 2. But that requires another program that creates the movies by combining the frames, I have made such program but it does not have any UI yet. --I really hope that this doesn't change the speed, and especially not the great quality and perfect details at the image-edges (that blurriness outside of the 'keyframes' is the most annoying 'feature' of fractal xtreme for me) some ideas for ui follow below 4. :D With the power of 2 rendering the other program set this text instead. Don't you want it? I think this text is a main part of my fascination of the infinity of the Mandelbrot set though. --yes, I'd love to get my hands on it! what do you mean with "this text"? ... 8. Find highest iteration just puts the cursor over the pixel with the highest iteration and was used for debugging. The Find Minibrot function handles maximum iterations automatically, so the same could be used when exploring. 9. Box-zooming, isn't that already there? And I don't even have a mouse on my laptop, and no mouse wheel... -----I meant drawing the size of the box instead of having to go into a menu to choose the size.. would be nicer for the 'work'flow.. but not a must-have at all.. ;) I am not sure the sideview turned out that good, did it? ---- you are right, BUT! ;) I just wanted to make sure you know what I'm talking about so you understand my UI-idea.. I imagine automation of interesting video-parameters on the timeline of the sideview. To give you an idea, I mean something remotely similar to the automation I use in my daily work: (http://media.soundonsound.com/sos/may06/images/cubase0506box1pic.l.jpg) (of course just one track and unbroken) so in the sideview you can see where you are in the fractal and what is happening. when there is something interesting you could for example decrease the speed so one has time to appreciate the details. other interesting parameters would be: -colourmap (but maybe not a pre-fixed one, but setting the colours in the timeline itself, so one can give desired areas exactly the colour you want. I'd really love to be able to do this in zoom movies. -rotation and its speed -and it would be a great navigator through the video itself. I have absolutely no idea how complicated something like that is to program - but wouldn't it be awesome? :surprised: :D cheers, Chilli Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on September 19, 2013, 01:42:13 PM Mrflay is on the forum from time to time I think.
People may think Mandelbrot is over-explored, but for me that first saw it in the 80s it will never stop being fascinating, and now it is possible to explore it in depths that we could only dream of for decades. 2. Isn't there a small dialog displayed when you want to save as jpeg, where the size can be specified? It might be that I have added that too recently. 3. I have not compared the rendering time in detail. It is of course unnecessary to render the center of the frames many times, but much less frames needs to be rendered. I have used this method since my 39th movie, I cannot see that it is much more blurry than my 38th movie? 4. I meant the "Zoom:" text in the upper left corner, that you want to get rid of :) Ok, with sideview I thought you meant my little 3D animation. The functionality you described is for my other program, that put together the key frames. You mentioned virtual dub to put the jpegs together when they were one image for each frame, are there any similar programs already available that can put together power of 2 key frames? My current program creates avi files, it does not handle audio, it does not have any UI and I am changing the program to get differences in speed for each movie. I then import the avi files into Microsoft Movie-maker to create the final video. Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on September 19, 2013, 11:01:23 PM I have made many updates on the program since the latest release but I haven't put it available on my web-page yet. I was kind of waiting until someone would ask, also to know if anyone was using it at all. If no one is using it, I would not made any updates available ;) Please do release new versions.Title: Re: Kalles Fraktaler 2 Post by: simon.snake on September 19, 2013, 11:30:09 PM I've been using it too.
Thankfully, even the odd random crash doesn't put me off as it is usually possible to resume when starting the program again. I only wish I could optionally turn off the small magnification window as I only use it some of the time. Title: Re: Kalles Fraktaler 2 Post by: DustyMonkey on September 20, 2013, 01:12:04 AM I created an account here today in order to also ask for updates to your renderer.
Title: Re: Kalles Fraktaler 2 Post by: Chillheimer on September 20, 2013, 09:26:29 AM People may think Mandelbrot is over-explored, but for me that first saw it in the 80s it will never stop being fascinating, and now it is possible to explore it in depths that we could only dream of for decades. agreed - how could such a beauty ever be overexplored..2. Isn't there a small dialog displayed when you want to save as jpeg, where the size can be specified? It might be that I have added that too recently. Yes there is. :banginghead: How could I miss that? I guess I never tried to export a jpg,because I thought "I wouldn't want it in that small window size" and then didn't export. Sorry..3. I have used this method since my 39th movie, I cannot see that it is much more blurry than my 38th movie? no it isn't, seems to work great.. :)4. I meant the "Zoom:" text in the upper left corner, that you want to get rid of :) Ah, ok... although it is indeed fascinating and very interesting, I'd love to have a checkbox to disable it for some videos.. Ok, with sideview I thought you meant my little 3D animation. I don't know of any programs that do this - but then, I'm a musician and not a video-specialist..The functionality you described is for my other program, that put together the key frames. You mentioned virtual dub to put the jpegs together when they were one image for each frame, are there any similar programs already available that can put together power of 2 key frames? My current program creates avi files, it does not handle audio, it does not have any UI and I am changing the program to get differences in speed for each movie. I then import the avi files into Microsoft Movie-maker to create the final video. No problem that your current programm doesn't handle audio, one can add that with other tools. although in the long term it would be great if in combination with the sideview one could had some sort of grid, that shows typical timemarks, 4 bars, 8 bars, 16 bars andso on - to match music with video.. ;) What do you think of the sideview-idea? interesting? and more important - programmable? I second dustmonkey - please share the update! even if it's a beta.. I'd love to get my hands on it! Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on September 20, 2013, 01:29:51 PM I just made my latest version available on my page
http://biphome.spray.se/karl.runmo/fraktal2.htm Most updates are on the glitch detection and the color handling. With the new zoom sequence animation, the size of the executables are even smaller, 180kb (32-bit) resp. 194kb (64-bit) Title: Re: Kalles Fraktaler 2 Post by: blob on September 20, 2013, 01:55:13 PM I just made my latest version available on my page Thanks! :beer:http://biphome.spray.se/karl.runmo/fraktal2.htm Most updates are on the glitch detection and the color handling. Title: Re: Kalles Fraktaler 2 Post by: hsmyers on September 20, 2013, 10:26:57 PM Not be a grammar or spelling pendant :fiery: :dink:, but here is the upper text on you webpage corrected:
Kalles Fraktaler 2 Mandelbrot fractals are fascinating both for the esthetic beauty and also because they are truly infinite. Recently a new method was developed to render Mandelbrot fractal images from a reference point rather than calculating the escape-speed for each pixel. Since lower precision then can be used, the time to render images decreases significantly. For details see sft_maths.pdf My humble thanks to K.I.Martin for sharing his mathematical findings, which I think are as big a discovery as the Mandelbrot formula itself. For feedback and discussions follow this link http://www.fractalforums.com/announcements-and-news/kalles-fraktaler-2/ Update Version 2.0.6: The perturbation glitches are corrected automatically (can be disabled) Update Version 2.0.9: Render from center and out (instead of sections) Update Version 2.0.10: Improved glitch correction and colour dialog. Zoom sequence is now rendered with the "power of 2" method. The previous video rendering program doesn't work anymore. A program that can convert the images to a movie will follow shortly. Absolutely great program! :beer: Keep them coming! -hsm Title: Re: Kalles Fraktaler 2 Post by: blob on September 21, 2013, 01:56:46 AM Not be a grammar or spelling pendant :fiery: :dink:, but here is the upper text on you webpage corrected: :rotfl: ;D Title: Re: Kalles Fraktaler 2 Post by: hsmyers on September 21, 2013, 02:43:12 AM Yeah, I caught another just before I pressed post :embarrass: What can I say, I'm lexdysic errrr---dyslexic :dink:
--hsm Title: Re: Kalles Fraktaler 2 Post by: Pauldelbrot on September 21, 2013, 03:58:18 AM Title: Re: Kalles Fraktaler 2 Post by: SeryZone on September 22, 2013, 04:06:17 PM Kalle! Can I ask you for new updates?
1) Non-Linear color density: Your coloring formula is Index = iteration / (Iteration Div) More smooth is Index = sqrt(iteration) / (IterationDiv). It gives more smooth coloring on denser elements and near minibrot (or Julia). 2) Cosine palette Interpolation. (http://fadedead.org/temp/public/latex/b16/87eb72985bb44edfbeb7f21df8d48987eaa944d931da8efaa0ad6.png) x1 = 0, y1 = 0. x2 = 255, x2 = 255 //Linear interpolation function interpolate_linear(a, b, k:Double):Double; begin Result := a * (1 - k) + b * (k); end; //Cosine Interpolation function interpolate_cosine(a, b, k:Double):Double; begin Result := ((a + b) + (a - b) * cos(pi * k)) / 2; end; a - begin point (x1) b - end point. (x2) k - |y2-y1| Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on October 05, 2013, 04:39:59 PM I am glad to be able to announce that I have made a new version available on my web-page
http://biphome.spray.se/karl.runmo/fraktal2.htm This program is free, but if you are ever able to make money of what you produce with my program you may consider sharing it with me. Title: Re: Kalles Fraktaler 2 Post by: hsmyers on October 05, 2013, 06:08:09 PM Kalles,
It just keeps getting better :D Have you considered some sort of automatic/adaptive option for iterations? You can reach depths that need greater counts so quickly that it would be nice to have it adjust it self. Perhaps even something as rudimentary as Ctrl+D to double the current iteration? In any event, keep up the great work :beer: --hsm Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on October 05, 2013, 09:54:14 PM Awesome
I'm zooming with your new program right now. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on October 05, 2013, 11:13:34 PM hsmyers, thanks for the reminder, I had this planned but forgot it. There is a 2.1.1. available now :)
Dinkydau, so your desktop is at least 8 times faster than your laptop, since it has 8 times more processor cores. And now my program is at least 10 times faster on depths deeper than e301. You realize that we would be able to explore the Mandelbrot set maybe 100 times faster on your desktop, right? So how are we going to get my program work on your desktop...?? :) Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on October 06, 2013, 01:50:03 AM Really I have no idea. I tried everything that I could think of to fix the problem. My desktop has windows 7 ultimate while my laptop has windows 7 home. It happens with every version of Kalles fraktaler you released.
There is one possible explanation that I have thought of, and that is that the problem is inherent to the CPUs. Maybe your program doesn't work with two physical CPUs, the AMD interlagos architecture or the number of cores. But I find it very unlikely that anything like that is indeed the problem. The CPUs should not be a problem as long as the operating system works. At least they should not make a program crash... Title: Re: Kalles Fraktaler 2 Post by: panzerboy on October 06, 2013, 01:28:41 PM Big thankyou to Karl for the Movie Maker! :worm:
Now I can finally make a mandelbrot zoom movie with colour cycling and rotation. http://www.youtube.com/watch?v=UZ5e99j533A A Couple of suggestions if you might be developing further. The file names for multi-part videos do not automatically load into VirtualDub. You use file names like file[01].avi, file[02].avi ... If you change them to file_01.avi, file_02.avi and so on I wouldnt have to do this DOS 1 liner to convert the file names. Code: for /f "usebackq delims=[] tokens=1-3" %i in (`dir /b film[??].avi`) do rename %i[%j]%k %i_%j.avi The rotation does not seem to work for 0.5 even though the docs on the page say the degrees rotation is a 'float value'. Super slow rotation can look cool. I'd like slower colour cycling too, but noting that the iterations per frame is an integer and you 'smooth' the colours by using palette indexes I guess all your colouring logic is integer based? So converting to floating point would be a biggie. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on October 06, 2013, 03:34:02 PM Big thankyou to Karl for the Movie Maker! :worm: Now I can finally make a mandelbrot zoom movie with colour cycling and rotation. A Couple of suggestions if you might be developing further. The file names for multi-part videos do not automatically load into VirtualDub. You use file names like file[01].avi, file[02].avi ... If you change them to file_01.avi, file_02.avi and so on I wouldnt have to do this DOS 1 liner to convert the file names. Code: for /f "usebackq delims=[] tokens=1-3" %i in (`dir /b film[??].avi`) do rename %i[%j]%k %i_%j.avi The rotation does not seem to work for 0.5 even though the docs on the page say the degrees rotation is a 'float value'. Super slow rotation can look cool. I'd like slower colour cycling too, but noting that the iterations per frame is an integer and you 'smooth' the colours by using palette indexes I guess all your colouring logic is integer based? So converting to floating point would be a biggie. Thanks for your kind comments. Yes I found these bugs, some hardcoded values I forgot to set. I have also found that the cycling could be nice to be slower than 1. I will make an update this evening. :-) Edit: I have now updated the KeyFrameMovie program and corrected the bugs and changed the out file names. BTW, Panzerboy or CommandLineCowboy, did you know that you made me into all this a year ago? I found one of your movies on youtube and was mind blown, my program Kalles Fraktaler 1 could not zoom more than e13, which is the limit when using the double datatype and the standard methods. I got inspired and encouraged to create an arbitrary precision module, and I did many zoom movies with it. It feels rather long time ago now, but it is only a year. Here is my first movie, uploaded in October last year, so it is an anniversary today. http://www.youtube.com/watch?v=PvPk_-xcrEo Title: Re: Kalles Fraktaler 2 Post by: Chillheimer on October 06, 2013, 08:51:18 PM yeah! lovely to see progress here! :)
sadly, the moviemaker doesn't work here (win 8 64 bit) it starts like in the screenshot and then freezes.. Title: Re: Kalles Fraktaler 2 Post by: blob on October 06, 2013, 09:09:19 PM Movie maker crash here also (on Windows ME) the same kind of way, shows its window (with that horrible typo in the title bar :dink:) and then I get a message saying it has caused an error in itself and I find this in faultlog.txt:
Quote KEYFRAMESMOVIE caused an invalid page fault in module KEYFRAMESMOVIE.EXE at 0177:0040718f. Registers: EAX=00000000 CS=0177 EIP=0040718f EFLGS=00010212 EBX=00000000 SS=017f ESP=0063e61c EBP=00000658 ECX=00000000 DS=017f ESI=00008af8 FS=83bf EDX=00000000 ES=017f EDI=0063ea88 GS=0000 Bytes at CS:EIP: 8b 43 10 8b 2d 18 92 40 00 6a 00 6a 00 68 8b 01 Stack dump: 00008af8 00000658 00000001 00000000 00403fcf 0063e648 0063ea88 00008af8 00000658 00000001 ffff0000 00000000 00000000 00000000 00000000 57c40002 The main application runs just fine as usual. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on October 06, 2013, 09:23:52 PM Does it crash on start or were you able to select any folder where you have zoom images and start render movies?
Title: Re: Kalles Fraktaler 2 Post by: blob on October 06, 2013, 09:27:22 PM Upon launching it, I just get to see that preview window and this is it, no browse for folder dialog (or else) appears (apart from the error message).
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on October 06, 2013, 10:38:37 PM It might be that things happens in different order on different operating systems.
One object is maybe used before it is initialized. I have uploaded a new version, 1.4, which I hope prevents this and solved this crash bug. Thanks for your patience :) Title: Re: Kalles Fraktaler 2 Post by: blob on October 06, 2013, 10:59:49 PM Looks like it works OK here now. :beer:
The ugly typo in the preview window titlebar is still there however... :tongue1: Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on October 06, 2013, 11:28:43 PM Looks like it works OK here now. :beer: The ugly typo in the preview window titlebar is still there however... :tongue1: That is just great! :beer: But I couldn't figure out what I misspelled? :embarrass: Title: Re: Kalles Fraktaler 2 Post by: simon.snake on October 06, 2013, 11:55:01 PM You have (or had) 'preview' as 'preivew' in the window title:
(http://www.needanother.co.uk/uploads/preivew.png) Title: Re: Kalles Fraktaler 2 Post by: Chillheimer on October 07, 2013, 01:24:29 AM just a short test: it opens normally and seems to works fine now!
rendering my first vid now.. :) I already told you that I'd be more than happy to pay for a great tool like that - you responded no, as this would mean you have responsability.. I wish everyone would work like that. Your dedication is heartrising.. If I should ever come close to make any money with all that wonderfull beauty and fun I'll definitely think of you. Title: A couple of caveats, a suggestion and a possible bug Post by: panzerboy on October 07, 2013, 02:55:51 AM Initially I was having a terrible time getting videos to work.
They ended up looking like this... http://www.youtube.com/watch?v=LCsYnXd4TlQ The problem is that the defaults for zoom size in Kalles Fraktaler is 4 but the zoom out level in movie maker is 2. This is explained on Karl's web page, but its soo easy to forget to switch the zoom size to 2 before you 'Store zoom-out images'. I also misinterpereted the meaning of a frame in the movie maker speed control. I was thinking video frames, I'm sure now that Karl means zoom-image frames. So my attempt at a Fractal Extreme style speed acceleration from the start became way to slow. Also note that with a 4xzoom size the speed is doubled. The default of 25 means that theres 25 video frames per zoom so if you do create a video with 4x zoom make sure to change the default speed to 12 or 13. Otherwise you get the kind of speed up in the 2nd half of this video. http://www.youtube.com/watch?v=1OJUWlnNNuI Note that the video starts pointing the wrong way round. The movie maker preserves the rotation from the previous test runs you may have done. Could the movie maker reset the rotation each time you click start? At the start there is a obvious break in the smooth colour pallette. Kalles Fraktaler seems to be creating an extra black colour at the end of the pallette. This black is definately not in my palette definition. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on October 07, 2013, 09:31:28 PM Thanks for the feedback from all of you!
I have now uploaded KF version 2.1.2 and KFM version 1.4 (http://biphome.spray.se/karl.runmo/fraktal2.htm) And I have corrected the typo ;D panzerboy, 1. I have done the same mistake many times, forgot to change the "Zoom size" to 2 before making a zoom sequence. I added a notification, so that you are aware of the Zoom size. 2. Color cycling and Rotation is now reset for each movie render. 3. The break in the palette was a bug that I have corrected. Strangely I haven't notice it myself, I usually only use random colors. I have also updated the color cycling in the movie program to combine color indexes, as you suggested, since I saw that it did not turn out good when using a value lower than 1 on locations near -2,0i. I also updated the color division in both programs to combine color indexes, but I haven't tested yet if both color division and cycling is applied on the same animation, I hope it just works... Title: Re: Kalles Fraktaler 2 Post by: panzerboy on October 07, 2013, 10:14:37 PM Thanks for the rapid turn-around. :thanks2:
Sadly :sad1: the unwanted black colour is still there. Couldn't possibly be anything to do with my pallette? Code: Re: 0 Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on October 07, 2013, 10:22:27 PM Thanks for the rapid turn-around. :thanks2: At what location do you see the black color?Sadly :sad1: the unwanted black colour is still there. Couldn't possibly be anything to do with my pallette? That might copy-paste okay, but as you can see no 0,0,0 colour defined. Edit: I found that this does not occur if you use a multiple of 2 number of key colors, so if I use 32 key colors I don't get any black areas... Title: Re: Kalles Fraktaler 2 Post by: hsmyers on October 07, 2013, 10:30:52 PM Kalles,
Sounds like an off by one error. The requirement of a power of two in you palettes that is. You might try and find out why it needs to be so? --hsm Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on October 07, 2013, 11:03:14 PM Kalles, Sounds like an off by one error. The requirement of a power of two in you palettes that is. You might try and find out why it needs to be so? --hsm It's because the key colors are expanded on the 1024 actual colors... Title: Re: Kalles Fraktaler 2 Post by: hsmyers on October 07, 2013, 11:47:14 PM OK, that makes sense. In that case, I'd pick a fill color like black or whatever, use that to pad the supplied palette and then when using the mod 2 length palette jump to the beginning as soon as you hit the 'guard' color. Just a thought...
--hsm Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on October 08, 2013, 07:19:35 AM Or I change the number of colors edit box to a drop down box with predefined values... :)
Title: Re: Kalles Fraktaler 2 Post by: DustyMonkey on October 11, 2013, 04:28:52 AM ..or just do that math right so that you arent off by 1 to begin with :)
The "trick" is to not rely on or even allow rounding.. rely on and demand truncation. Let (j) be the index into the output palette Let (output_size) by the number of elements in the output palette (the largest element is at index output_size - 1) Let (i) be the index into the input palette Let (f) by the fractional value between (i) and (i+1) that is represented by a given (j) Let (input_size) by the number of elements in the input palette Now we can map a (j) into an (i) and (f), relies on floating point division: temp = j * input_size / output_size i = floor(temp) f = temp - i Now you can interpolate between input(i) and input(i+1) using f, to produce the desired output(j) .. and use modular arithmetic at the ends for a smooth interpolation between the end points .. interpolation can be linear, cosine, cubic, etc.. Specifically you will now iterate over each entry in the output palette and reduce that to a position in the input palette, rather than iterate over each entry of the input palette and expand to a position in the output palette, which ensures that you cannot miss an output palette entry due to the size of the input not being a common denominator of the size of the output. Title: Re: Kalles Fraktaler 2 Post by: panzerboy on October 13, 2013, 10:31:32 AM http://www.youtube.com/watch?v=ELw6dy6WBSk
Resolved the colour problems by using a palette of 32, an even divisor of 1024. Rendering the zoom-outs stopped about 4 times. I'd check the PC and find Kalles Fraktaler not running. To restart you must have saved the location and magnification of the ending frame. The last file(s) generated will have the magnification in n.nnEnnn format, thats not quite enough precision to continue. Load the saved ending frame and put the location zoom into the desktop calculator. If you paste the value in the uppercase E wont work so use the exp button (you do have you calculator in scientific mode right?). Then divide by 2 and keep hitting = until you match the last files zoom, and then just one more time. The value from the calculator should copy/paste into Kalles Fraktaler's zoom textbox okay. I could then restart generating the zoom-outs. Its easiest when changing the location parameters to cancel the rendering. One time when I hadn't It created a partially rendered jpeg and I assume .kfb file. It's a good idea to run through the JPEGs to check them, I found 10 instances of zoom frames needing to be re-rendered. This is a matter like before of calculating the right zoom number. Then using the special->add reference and clicking on the area of missing detail. Often I would turn off the 'auto-solve-glitches' if it wasnt finding any more references. That way I could more quicker add another reference as often they would only fix a few iteration bands. Karl, the hot-key to reuse reference ctrl-R doesnt seem immediatley usefull. Perhaps it would be better for add-reference, or perhaps you could explain the thinking behind re-use reference. Once a render frame is fixed I saved as both jpeg and map using the same file names but with "fix" before the extension. When all render frames were fixed and saved I used this batch to rename old file names as "old" and remove the "fix" from new. Code: C:\Users\panzerboy\Documents\bin>type kffixrename.bat MOST important After renaming move the old files away. Move *old.* .. You could just save the files over the top of the old files when fixing but these extra steps helped because I got one of the file names wrong. I saved to 00105_3.65e047 instead of 00106_1.82e047. easy to get confused when both files are at the same zoom magnificaion exponent (e047). To fix that I moved the old files back into the directory ans used the follwing batch file to rename new files as "fix" and remove "old" from the old. Code: C:\Users\panzerboy\Documents\bin>type kfoldrename.bat Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on October 13, 2013, 04:46:36 PM The movie is awesome Panzerboy!
I don't know why the program stopped, I have run renders that took more than a month without it stopped. It should be a popup saying it crashed, if it did...? I should write a tutorial on how to make a movie, but you figured it out yourself. Next time it will be much easier ;) I use my own program to calculate zoom levels, which is able to go far beyond the boundaries of double, i.e. e318 http://biphome.spray.se/karl.runmo/calc.htm ;) I am surprised that you only had to correct 10 frames, since this zoom passes a lot of areas where blobs usually arise. The reuse of the reference point is useful to speed up a zoom out sequence since the high precision reference point would be calculated only once. Less glitch blobs will arise if the reference point is in the final Minibrot. On deep zoom levels with several hundred thousand or millions of iterations it takes a significant amount of time to calculate the reference point, and convert and store all of them in a array of double. However, the reference re-usage cannot be combined with auto glitch correction or additional reference points. And also thanks to DustyMonkey, I have implemented your suggested solution and will included it if I make a new release. Title: Re: Kalles Fraktaler 2 Post by: Nahee_Enterprises on October 14, 2013, 02:25:14 AM www youtube.com/watch?v=ELw6dy6WBSk Resolved the colour problems by using a palette of 32, an even divisor of 1024. Rendering the zoom-outs stopped about 4 times. I'd check the PC and find Kalles Fraktaler not running. To restart you must have saved the location and magnification of the ending frame. ........ [etc...] ....... Enjoyed the video fractal animation !!! :D Title: Re: Kalles Fraktaler 2 Post by: Chillheimer on October 17, 2013, 01:27:11 AM Is it just here that the programm makes a strange short click-noise, whenever an action is completed?
this can become a little annoying when rendering in the background, it clicks for every rendered frame... any chance you could disable that sound? ----------- doesn't happen all the time, now it's quiet.. oh, win8, 64bit ------ and another question about the movie maker: It doesn't like to use my full cpu power - it tends to work at 13-15% with no other programs running. Any idea why that is? still: I love it! Title: Re: Kalles Fraktaler 2 Post by: blob on October 17, 2013, 05:33:15 AM and another question about the movie maker: It doesn't like to use my full cpu power - it tends to work at 13-15% with no other programs running. Any idea why that is? Let me guess, you're having an 8 cores CPU and the video codec you're using has no multithreading capability or is improperly configured in this respect, is that it? :DTitle: Re: Kalles Fraktaler 2 Post by: panzerboy on October 17, 2013, 06:35:56 AM No I'm sure the movie maker is single threaded.
I only have a dual core and movie maker never takes more than 50%. When I encode videos from virtualdub the usage goes up to 98-97% and the PC becomes unusable. So its not the codecs that are single threaded. The last movie I created took 3 hours to create the zoom out frames (274 of them 7.5e81). To encode a simple uncompressed HSL (YV12) video took 5 hours 10 minutes giving 8.8GB of uncompressed video. (2560x1440 zoom outs for 1280x720 video) At a guess I'd say there is no multi-threading nor SIMD (MMX, SSE, AVX?) trickery going on in the movie process. To convert that YV12 to h264 (x264) took 40 minutes for two pass encode. H264 is doing MUCH more than YV12 Title: Re: Kalles Fraktaler 2 Post by: Pauldelbrot on October 17, 2013, 09:06:13 AM Is it just here that the programm makes a strange short click-noise, whenever an action is completed? this can become a little annoying when rendering in the background, it clicks for every rendered frame... any chance you could disable that sound? ----------- doesn't happen all the time, not it's quiet.. oh, win8, 64bit ------ and another question about the movie maker: It doesn't like to use my full cpu power - it tends to work at 13-15% with no other programs running. Any idea why that is? still: I love it! Modern Windowses (Vista onwards) provide the ability to set the sound volume for individual applications using some OS control panel. But I forget the details on how. You could use this to mute or really quieten a particular program. Title: Re: Kalles Fraktaler 2 Post by: simon.snake on October 17, 2013, 09:34:53 AM Modern Windowses (Vista onwards) provide the ability to set the sound volume for individual applications using some OS control panel. But I forget the details on how. You could use this to mute or really quieten a particular program. You primary-click (usually the left mouse button for right handed users) the small speaker icon in the notification area, click on mixer on the bottom of the popup and you can then adjust the volume of individual apps, although when I tried this while typing this I didn't get a choice of adjusting sound on Chrome (my browser) or Fractal eXtreme which is running two instances, so I'm not sure how precisely you can adjust sounds for individual apps. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on October 17, 2013, 10:15:24 AM The sound is a debugging left-over which I should have removed.
And yes, the movie maker is single threaded. I don't think it is possible to add frames into the AVI stream in parallel, so I didn't think it would be necessary. But with the color cycling the image is generated for every frame and that could perhaps benefit from multithreading. Title: Re: Kalles Fraktaler 2 Post by: Pauldelbrot on October 17, 2013, 11:24:34 AM You primary-click (usually the left mouse button for right handed users) the small speaker icon in the notification area, click on mixer on the bottom of the popup and you can then adjust the volume of individual apps, although when I tried this while typing this I didn't get a choice of adjusting sound on Chrome (my browser) or Fractal eXtreme which is running two instances, so I'm not sure how precisely you can adjust sounds for individual apps. You're probably running a bazillion miscellaneous Windows processes at any given time, even if only a few are user-oriented "applications" with visible windows. I'm guessing that to avoid clutter it only lets you adjust applications that have requested access to the sound mixing subsystem by making Windows API audio-related calls since starting. So you'd have to make Chrome play a sound first (going to any site with Flash ought to suffice) to get its volume control to appear. Title: Re: Kalles Fraktaler 2 Post by: Chillheimer on October 17, 2013, 04:06:01 PM Thanks for clearing that up kalle!
It'd be great if someday multithreading would be possible in the moviemaker -as the fractal calculation is so unbelievably fast, this no is the slowest process in generating a fractal movie ;) @blob: No it's a quad-processor (core i7) I can't finde where to confige the codecs more than from within the mnovie maker pop-up where I can select the codecs. And there is not much to change.. Oh, is there any chance I could get my installed h264 codec directly into the list of codecs to choose from? More questions: -is it possible to reverse the direction of colour-cycling? adding a "-" doesn't do the trick. -is there any trick to achieve smoother colours? My goal would be to eliminate the visible transition-lines between the different colours. I already expanded a palette of 25 base-colours to the max of 1024 but it doesn't seem to make that much a difference. -i don't understand the difference between "frame size" and "movie size" in the Movie Maker - can anyone explain what to choose there (I'd like to make 1920*1080 movies) in the last frames my zooms become increasingly "pixely" does this have to do with it? edit: just read this post: http://www.fractalforums.com/mandelbrot-and-julia-set/coloring-points-inside-the-mandelbrot-set/?topicseen Wouldn't it be great to see this implemented (optional) in kf? edit2: another question.. ;) kf just crashed while rendering zoom out pics for a movie. it's only been working 3 hours, but yet it would be great if I could continue where it crashed - but that doesn't seem to work. or I don't know how to do this. Title: Re: Kalles Fraktaler 2 Post by: blob on October 17, 2013, 05:18:31 PM @blob: No it's a quad-processor (core i7) If there is a configuration option for multithreading it'll be within a codec's own configuration dialog, not on the codec selection dialog.I can't finde where to confige the codecs more than from within the mnovie maker pop-up where I can select the codecs. And there is not much to change.. Oh, is there any chance I could get my installed h264 codec directly into the list of codecs to choose from? If your h264 codec is a VFW one, it should appear there. If it's a standalone application or a DirectShow filter it won't. If it's a VFW one and it doesn't appear check out if you can use it from VirtualDub for example so you'll know if the issue is generic or specific to KFMM. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on October 17, 2013, 09:46:34 PM Oh, is there any chance I could get my installed h264 codec directly into the list of codecs to choose from? I use Intel IYUV codec, it doesn't seem to compress at all, since all movies get exact the same size and are proportional to the resolution, which I think is good. I then use Microsoft MovieMaker to assemble the movies and then compression is applied.More questions: Yes, it should easy to implement, I will have a look :)-is it possible to reverse the direction of colour-cycling? adding a "-" doesn't do the trick. -is there any trick to achieve smoother colours? My goal would be to eliminate the visible transition-lines between the different colours. I already expanded a palette of 25 base-colours to the max of 1024 but it doesn't seem to make that much a difference. Try add a value in "Divide iteration" larger than 1.-i don't understand the difference between "frame size" and "movie size" in the Movie Maker - can anyone explain what to choose there (I'd like to make 1920*1080 movies) But you can only edit the "Movie size" field. The "Frame size" is the size of the key-frames, i.e. the images rendered by KF.in the last frames my zooms become increasingly "pixely" does this have to do with it? The last frames get "pixely" due to the density of the pattern around deep minibrots, and anti-alias is needed to render them properly. If you replace the last key-frames with larger kfb-images these frames will be squeezed and anti-alias effect will be achieved.edit: just read this post: Yes I have tested it. But I don't know, I feel that the pertubation makes the values of z (in z[n+1]=z^2+c) get instable when the bailout value is reached and the result doesn't get as good as I want it. Before pertubation I was applying a metallic effect by using the values after bailout, but I couldn't get that proper either. Maybe others doing pertubation, hapf, claude, Pauldebrot, have tested this and can give some insights?http://www.fractalforums.com/mandelbrot-and-julia-set/coloring-points-inside-the-mandelbrot-set/?topicseen Wouldn't it be great to see this implemented (optional) in kf? edit2: It's very easy!another question.. ;) kf just crashed while rendering zoom out pics for a movie. it's only been working 3 hours, but yet it would be great if I could continue where it crashed - but that doesn't seem to work. or I don't know how to do this. Go to the next zoom position and start rendering the zoom sequence again. Ok, I will explain in detail: First, make sure you saved the location where the zoom sequence ends. Let's say you have a zoom that ends at 1.27e200, but in the Location dialog, the zoom level is specified with much more decimals. Let's say your last frame is 90, so the name of the last file is something like 00090_2.05e173.kfb. Then take the end zoom level, from the Zoom field in the Location dialog, and divide it with 2^90. I have made a calculator that can handle very large numbers which you can use if you want, http://biphome.spray.se/karl.runmo/calc.htm 1.27e200 / 2^90 = 1.02589783e173 Paste in the result in the zoom field of the Location dialog. Start the zoom sequence render again. KF will browse the files in the folder and start counting on 91. I hope I was able to explain this in an understandable way... ;) Title: Re: Kalles Fraktaler 2 Post by: panzerboy on October 17, 2013, 10:21:20 PM -is it possible to reverse the direction of colour-cycling? adding a "-" doesn't do the trick. Subtract the desired speed from 1024, so for a -1 use 1023, for -0.667 use 1023.333In the same way you can reverse the rotation by subtracting from 360, 359 would be a -1 degreee rotation anti-clockwise. Title: Re: Kalles Fraktaler 2 Post by: Chillheimer on October 17, 2013, 10:32:46 PM But you can only edit the "Movie size" field. The "Frame size" is the size of the key-frames, i.e. the images rendered by KF. Thats true, but if I render the images for example with 3840*... and then set the movie size to half, 1920*.. the strange behaviour as described by panzerboy in this post occurs:http://www.fractalforums.com/announcements-and-news/kalles-fraktaler-2/msg66904/#msg66904 (what happens when you don't match zoom outs) happens. so if you have to use the exact same size as with the imagerenders, i don't understand the meaning/use of these two values.. The last frames get "pixely" due to the density of the pattern around deep minibrots, and anti-alias is needed to render them properly. If you replace the last key-frames with larger kfb-images these frames will be squeezed and anti-alias effect will be achieved. Got that, but I mean seriously pixely, as in my attached pic..It's very easy! I have to say, before it was really very easy - this is a little more complex, but still manageable ;) thx for showing me how to, I'll try next time.Go to the next zoom position and start rendering the zoom sequence again. Ok, I will explain in detail: First, make sure you saved the location where the zoom sequence ends. Let's say you have a zoom that ends at 1.27e200, but in the Location dialog, the zoom level is specified with much more decimals. Let's say your last frame is 90, so the name of the last file is something like 00090_2.05e173.kfb. Then take the end zoom level, from the Zoom field in the Location dialog, and divide it with 2^90. I have made a calculator that can handle very large numbers which you can use if you want, http://biphome.spray.se/karl.runmo/calc.htm 1.27e200 / 2^90 = 1.02589783e173 Paste in the result in the zoom field of the Location dialog. Start the zoom sequence render again. KF will browse the files in the folder and start counting on 91. I hope I was able to explain this in an understandable way... ;) And thanks for the other answers, too. Great to get help so fast! :) Subtract the desired speed from 1024, so for a -1 use 1023, for -0.667 use 1023.333 Wow!In the same way you can reverse the rotation by subtracting from 360, 359 would be a -1 degreee rotation anti-clockwise. How cool is that?! Did you find that out yourself?!! Thank you! I'll try, as soon as my large render is done. edit: one more question! :embarrass: If I plan to use rotation in a movie - does it make more sense to use a image size with equal values, like 1024*1024? Or should I always chose the size that I plan to use as movie-size? edit two ('he won't stop.. ::)') my render series should have finished now, but it takes ages for the last frames to render, where now the main mandelbrot comes into view. Actually it takes longer(10min/frame) than the very firt ultradeep-renders(7min/frame). In between it was as fast as 20sec/frame. Iterations are now for some reason up to the 1 million, that I had set as max for the final minimandel. Yet the same first zooms rendered veryvery fast when i was zooming in manually.. Is this a "bug" or do I do something wrong? Title: Re: Kalles Fraktaler 2 Post by: Chillheimer on October 18, 2013, 02:27:51 AM So here I go again...
I'm rendering the movie right now with the suggested Intel IYUV codec. when i compare the 'original' keyframe-picture with the corresponding image in the video, the original has a real full hd resolution, while the video doesn't. i selected 1920*1080 during the zoom process as well as in the movie maker.. what am i doing wrong?! (the different position is due to the rotation and the jpg is compressed to fit the forums 250kb limit, but the blur should show what I mean) Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on October 18, 2013, 10:43:30 AM Thats true, but if I render the images for example with 3840*... and then set the movie size to half, 1920*.. the strange behaviour as described by panzerboy in this post occurs: Unfortunately there are things in the KFM that are not reset between renders, so you need to re-start the program if you want to change the output resolution...http://www.fractalforums.com/announcements-and-news/kalles-fraktaler-2/msg66904/#msg66904 (what happens when you don't match zoom outs) happens. so if you have to use the exact same size as with the imagerenders, i don't understand the meaning/use of these two values.. Got that, but I mean seriously pixely, as in my attached pic.. The zoom in animation combines 5 key-frames to make the center high quality. However in the end of the animation there are fewer than 5 key-frames left, and in the end only one key-frame, and when this last key-frame is zoomed it gets "pixely". You may remove that part of the movie in MS Movie Maker or whatever you use to merge the raw avi-movies.If I plan to use rotation in a movie - does it make more sense to use a image size with equal values, like 1024*1024? Or should I always chose the size that I plan to use as movie-size? You should choose a size twice as the resulting movie. Unfortunately I have only made a fixed 16/9 proportion, so rotation is a big waste of pixels. And it is significantly slower to render.edit two ('he won't stop.. ::)') The maximum iterations are the same through out the zoom-out sequence, and it is indeed unnecessary high near the big Mandelbrot. You may stop the sequence, change the max iteration, and continue.my render series should have finished now, but it takes ages for the last frames to render, where now the main mandelbrot comes into view. Actually it takes longer(10min/frame) than the very firt ultradeep-renders(7min/frame). In between it was as fast as 20sec/frame. Iterations are now for some reason up to the 1 million, that I had set as max for the final minimandel. Yet the same first zooms rendered veryvery fast when i was zooming in manually.. Is this a "bug" or do I do something wrong? So here I go again... The size of the avi with 1920x1080 and 500 frames should be 1.5 GB, can you verify that and that the AVI file has the same resolution?I'm rendering the movie right now with the suggested Intel IYUV codec. when i compare the 'original' keyframe-picture with the corresponding image in the video, the original has a real full hd resolution, while the video doesn't. i selected 1920*1080 during the zoom process as well as in the movie maker.. what am i doing wrong?! (the different position is due to the rotation and the jpg is compressed to fit the forums 250kb limit, but the blur should show what I mean) Title: Re: Kalles Fraktaler 2 Post by: Chillheimer on October 18, 2013, 11:45:10 AM Ah! I didn't think the resolution might be different to what I selected - it actually is, exactly half the size.
And i guess this has to do with your other answer, that you have to double resolution when using rotation. I will give it a try! A workaround for the pixel-problem also is to zoom some more steps (obviously 5 are enough) than needed. works of course only, if you end inside a minibrot. Title: Re: Kalles Fraktaler 2 Post by: panzerboy on October 20, 2013, 01:44:14 AM Had an intersting challenge with this movie.
http://www.youtube.com/watch?v=N_G2i9tFHhc Notice the flash inside the mini-brot at 49-50 seconds? It corresponds to a lot of work i did adding references to remove the block colours shown in the picture below. The parameters for this location (& palette) are Code: Re: 0.2952759114501225583748642023454358810964425781575845087544281689002901046120834798971939 The image size was 2560x1440 and window size of 1280x720, that gave a problem using the 'Find center of glitch' as it would position the cursor outside of the window. Perhaps that function doesnt scale to the window size? I hoped that 'no approximation' might do a simple non-perturbation mandelbrot but no. Frustrating, at this zoom level 80bit FPU math would suffice doing a simple mandelbrot. Would have saved a few hours of repetitions of Alt-A, cursor up, cursor across, cursor down, cursor down, cursor down, enter (add reference), click. As well as the time I clicked without selecting add reference, so it zoomed, lost all my fixes on that frame. When you've got a lot of fixups to do, a locked add reference mode would be nice, I could just click, click... I'm thinking the flash in the video might have been a added reference on one of the frames that mapped to an iteration that was coloured black. Often adding a reference outside the interior would change the colours of the blocks inside the mini-brot. So I thought I'd removed all the coloured areas but couldnt see the black coloured area against the black interior of the mini-brot. Viewing the iteration wouldnt have helped much, at 150000 iterations the picture was mostly black with a few bright white (bad) blobs. Have I mentioned that the number of frames calculation in the movie maker underestimates when using rotation. It gives the number of frames based on the full image size not the quarter resolution that rotation implies. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on October 21, 2013, 06:41:53 PM Thanks panzerboy
The thing you came across is a third type of glitch, with pattern that arise on top of a minibrot when the reference is near but outside of it. I found another one a while ago http://www.fractalforums.com/images-showcase-(rate-my-fractal)/interesting-glitch/ What you can do with the minibrot visible around 2e17, is to: - turn off "Auto solve glitches" - add a reference inside the minibrot. - turn on "Reuse reference" - Press F5 to refresh the whole image. The reference for the image will now be in the minibrot and not in the center of the window, but if there would be other glitches around they would not be solved automatically. To add additional references make sure to turn of the "Reuse reference". The function to lock the "Add reference" is a very good suggestion, together with the rest. Title: Re: Kalles Fraktaler 2 Post by: Chillheimer on October 22, 2013, 12:00:10 AM Just a short mention, what might solve an issue with picking colours:
when the "show index" box in the colour-menu is ticked, how about having to press an additional key like shift or (german?) strg to have the colour only memorized when you stop holding that button? at the moment, you can find the colour by mouse-over, but as soon as you go to the colour-editor you loose the original colour as you move over the screen. btw: kalle, is it ok and you want people like me come to you with stuff like that? I often feel like that annoying guy, complaining all the time.. Without lots of knowledge (or care) of math and science, just loving nice "eye-teasers" but on the other hand I think that your great tool is still in progress, and if I had the gift of being able to programm sth like that I'd be happy to get more input.. (and I'd probably be annoyed by some guys giving mostly criticism, like me for example ;)) I payed for ultra fractal and enjoyed mandelbulb 3d for quite some time,but Kalles Fractaler is my greatest time-thieve since I discovered. I think this is the biggest compliment I can give. And I'd like to point this out emphatically once and for all (so that I can keep annoying you with tiny little annoying bug-crap ;without having to remember how greatful I am!) Regards, Chilli ps: resuming as you described worked fine! I had a hard time finding out how to correctly type the numbers in the calculator, but google is your friend ;) i want to mention this bevause this probably is stuff for "math-heads" that is essential and doesn't need explanation - but it's actually not general education for everyone and stuff like this can be a huge obstacle (at least for people who don't know how to google ;) to make it short: wouldn't it be relatively easy to integrate this calculation? Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on October 22, 2013, 05:40:23 PM Just a short mention, what might solve an issue with picking colours: If you click on the image while this checkbox is checked, the color edit dialog will be displayed for the color. when the "show index" box in the colour-menu is ticked, how about having to press an additional key like shift or (german?) strg to have the colour only memorized when you stop holding that button? at the moment, you can find the colour by mouse-over, but as soon as you go to the colour-editor you loose the original colour as you move over the screen. btw: kalle, is it ok and you want people like me come to you with stuff like that? I don't mind at all, I appreciate your comments and suggestions :)I often feel like that annoying guy, complaining all the time.. Without lots of knowledge (or care) of math and science, just loving nice "eye-teasers" but on the other hand I think that your great tool is still in progress, and if I had the gift of being able to programm sth like that I'd be happy to get more input.. (and I'd probably be annoyed by some guys giving mostly criticism, like me for example ;)) I payed for ultra fractal and enjoyed mandelbulb 3d for quite some time,but Kalles Fractaler is my greatest time-thieve since I discovered. That's really great to hear! I did it for my self in the first place, but I am very glad if others can enjoy :)I think this is the biggest compliment I can give. And I'd like to point this out emphatically once and for all (so that I can keep annoying you with tiny little annoying bug-crap ;without having to remember how greatful I am!) Regards, Chilli ps: resuming as you described worked fine! I have ideas of 2 new functions to add for a new release whenever I get the time:I had a hard time finding out how to correctly type the numbers in the calculator, but google is your friend ;) i want to mention this bevause this probably is stuff for "math-heads" that is essential and doesn't need explanation - but it's actually not general education for everyone and stuff like this can be a huge obstacle (at least for people who don't know how to google ;) to make it short: wouldn't it be relatively easy to integrate this calculation? 1. An edit function for zoom sequences. A function to browse the key frames rendered, that opens the already rendered pixels from the KFB file, keeps track of their names and locations, and that let you add references with just clicking the image, and then store and continue with the next frame. 2. A function that help to continue a zoom sequence that is stopped. Title: Re: Kalles Fraktaler 2 Post by: panzerboy on October 27, 2013, 03:55:04 AM To get better detail at low YouTube bit rates I've slowed down, spaced out the colours and slowed the colour cycling.
Figuring all that would ease the burden of the x264 video codec. The following video has all 1024 colours defined and sorted in classic commandlinecowboy style. The colour 'divide iteration' is 5, the 'Color Cycle, iterations per frame' is 0.1 http://www.youtube.com/watch?v=_EsITcnh4SQ Its obvious the colour cycling hasnt smoothly adjusted its speed. Single stepping through the video it seems the colours cycles every 10th video frame. Probably some relationship between 0.1 iterations per frame and 10 frames of video :hrmm: I think I'll start rendering an HD version of this video. It looks pretty nice without the colour cycling. Having 1024 colours to play with is a big improvement over the 228 colours of Fractal Extreme I've finally worked out a good way to make 1024 samples of the 24bit colour cube thus a return to my colour sorting methods. The location and pallette are below. If you copy-paste all this into notepad (make sure wordwrap is disabled Format->wordwrap) Then save-as yourchoiceoffilename.kfr (or .kfp for pallette) Code: Re: 0.262112050929892125172742638581539906024089411758346320071479521534275816 Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on October 27, 2013, 04:03:49 PM Thanks for the feedback panzerboy.
Yes, unfortunately it seems that youtube is not able to handle our color cycling movies. :( I have also found the bug when combining a low value of color cycling with iteration division in the Movie-maker. I solved it for my latest movie, and I have now also put the update on my web-site. http://biphome.spray.se/karl.runmo/fractal2.htm I have also made a new function that enables editing the key frames more easily. Since the iterations are available in the kfb files, they are loaded instead of rendering the whole frame again. Then in editing mode more new references can be added without having to select the menus. The glitch you reported previously, with pattern on top of minibrots, can be solved in one step by setting the main reference inside the minibrot. The only downside with this function is that it is a little slow to browse the frames, since it is calculating the zoom location by doing a full precision division. I would want it to be as fast as browsing jpeg images with an image program, but it is a little bit slower. Anyway, I hope the improved editing possibilities compensate for that :) I have also fixed so that any number of key colors can be used. Yep, the colors are not in RGB order and the imaginary axis is upside down. Early mistakes that I don't dare to change now :snore: Title: Re: Kalles Fraktaler 2 Post by: panzerboy on October 28, 2013, 04:40:47 AM Thank You Karl.
The colour cycling seems to have slowed down a tad? Using colour cycling of 0.3 iteration per frame seems about the same speed as the 0.1 previoiusly. Of course its nicely smooth now. I might try bumping up the bitrate, theYouTube page mentions 720p at 30,000Kbs for 'enterprise quality ... connections'. https://support.google.com/youtube/answer/1722171?hl=en Which rather suggests the bitrate of 5000Kbs is a suggestion rather than fixed limit. Title: Re: Kalles Fraktaler 2 Post by: Chillheimer on November 01, 2013, 04:50:10 PM Hi Kalle!
I've been rendering some days on a deeper zoom now, and at about 40% I've come across a glitch as shown in the attachement. I'd be very dissappointed if all the past days of rendering were wasted - Is there a way to fix this? Regards, Chilli Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on November 01, 2013, 05:10:20 PM Hi Kalle! Hi ChilliI've been rendering some days on a deeper zoom now, and at about 40% I've come across a glitch as shown in the attachement. I'd be very dissappointed if all the past days of rendering were wasted - Is there a way to fix this? Regards, Chilli Did you save the end location in the same folder as the frames? If you did, then use the "Examine Zoom Sequence" function to browse the frames and add references where needed on the frames that need it, in a rather simple way. :) Title: Re: Kalles Fraktaler 2 Post by: Chillheimer on November 01, 2013, 05:18:39 PM Yes, the end location is saved in the same folder.
I'm not sure how to do this - I just click "add reference" after clicking "examine zoom sequence"? I cant find "examine zoom sequence" anywher in the menues.. (still rendering right now, but I think all menus are shown anyway) Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on November 01, 2013, 05:34:20 PM No worries, when the render is complete go to my page and download the latest version, this function is recently added.
Then with this function you will have a dialog with "Previous" and "Next" to browse the frames and you can just click in the image to add references when the dialog is visible. (Or if you don't want to wait you can rename fraktal_sft64.exe to fraktal_sft64_old.exe or something, you can do that while the program is running. Then extract the new file to the same folder, and run it in parallel) Title: Re: Kalles Fraktaler 2 Post by: Chillheimer on November 02, 2013, 01:37:39 PM hey kalle!
thank you, works great! just one thing is strange, sometimes mini-mandelbrots are not black as they should be. I click them to add a reference and save it. when i return the colour has changed again (to a different colour). and: what is the difference between add reference and set main reference? when should I use what? edit: and one more, sometimes I have to add lots of references in one frame, in the same area, to fill out the details. it seems that in these cases it only changes the one colour-band that I clicked into. Is there a way to fix all at once? Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on November 02, 2013, 11:34:05 PM The first issue might be that you have a lower maximum iteration value than you started with, which I suggested in a previous post? This is a bug that I should solve.
Second thing is related to the third, that a re-render of the whole image with a different reference can solve the nasty type of glitch that contains many different colors and not just a one color blob. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on November 16, 2013, 06:19:53 PM I have put a new version on my page http://biphome.spray.se/karl.runmo/fraktal2.htm
- Smooth color transitions - Optimized animation render - the center of the keyframes is reused when zooming out. Should save 1/4 of the time, perhaps more since the center usually has higher number of iterations. - Bugfixes, for example when editing keyframes Enjoy! Title: Re: Kalles Fraktaler 2 Post by: panzerboy on November 16, 2013, 10:53:54 PM Thanks for that.
I don't think the smooth color transitions works in the movie maker. :sad1: Tried first with color cycling, then without, then unticked the color transitions (in case the logic got reversed) but got the same iteration bands each time. All the jpgs in the source directory look nicely smoothed though. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on November 17, 2013, 10:16:45 AM Thanks for that. Thanks for finding this - the combination iteration division and smooth transition did not work in the movie maker. The movies I made for testing did not use division.I don't think the smooth color transitions works in the movie maker. :sad1: Tried first with color cycling, then without, then unticked the color transitions (in case the logic got reversed) but got the same iteration bands each time. All the jpgs in the source directory look nicely smoothed though. I have updated! :) Title: Re: Kalles Fraktaler 2 Post by: Mircode on November 18, 2013, 11:47:57 PM Just posted on the main thread of sft but I think this is the better place:
And I also have some simple feature requests for Kalles Fraktaler 2: - Maybe I am just too stupid but it feels like it is not possible to change the aspect ratio of the image. That would be very useful. - Also, rotation of the rendering and better zoomlevel control would be nice. How about: aspect ratio of the image is determined by the aspect ratio of the window or can be predefined, the mouse-down-point determines the center of the next image, the mouse-up-point determines the the upper right corner of the image (which also defines the rotation angle) I hate people who only demand stuff, so I will try to make a contribution myself by creating a WebGL based player that imports zoom-out pictures from Kalles Fraktaler 2. One will be able to choose between scrolling and auto-zoom. @Kalles Fractaler: It would also be very cool if one was able to export not just rendered color images, but also "raw data" like iteration, estimated distances, ... per pixel. That way the coloring can be done dynamically using WebGL and GLSL shaders which will allow super sexy effects, for instance an emboss effect with the mouse as lightsource. Looking forward to this! Title: Re: Kalles Fraktaler 2 Post by: panzerboy on November 19, 2013, 01:48:33 PM @Mircode
The iterations data for Kalles Fraktaler is available in the .kfb files. The following is lifted from a post by Mr Kalles Fracktaler himself here http://www.fractalforums.com/index.php?topic=8233.msg67085#msg67085 Code: // The first 3 bytes contain "KFB" - just to make sure that I don't read garbage and try @Kalles Fraktler The smooth colouring is working just fine now, thanks. http://www.youtube.com/watch?v=QYd1ihhK8bE&feature=c4-overview&list=UUxs-S3Czgsh0qOL0dC8-FLg Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on November 19, 2013, 08:57:00 PM @Mircode
Yeah, the program is optimized to create movies to be watched on my smartphone or PC. But yes, it's a good suggestion to be able to change the aspect ratio. Free zoom with the mouse - easy! Rotate the image - harder.... I have extended the KFB file to include float values, which all are between 0 and 1, to be used when blending the iteration color with the next iteration color. The size of the files got doubled. So, append this pieces of code Code: float **ppTrans = new float*[nWidth]; I don't mind feedback and suggestions, I appreciate it. I am not familiar with distance estimation, I did some tests but it did not turn out well, I didn't dig into it much. A square root for each iteration in each pixel would slow down the render much though... but it's maybe worth it? @panzerboy - that's a fantastic movie. It's beautiful with the darker regions between the spirals got synced :) Title: Re: Kalles Fraktaler 2 Post by: Mircode on November 20, 2013, 10:01:59 AM Hi!
What is the problem with rotation? Do you need help on that? You don't have to do the distance estimation stuff. Just store whatever you compute at each pixel, I can use it in the shader. There are several ways to color the thing: - by escape time - by distance estimation - smallest absolute value of the orbit - phase of the last value that didn't escape - ... If you want to include anything of this, we can use it as well. Greetings! Mirko Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on November 20, 2013, 07:20:26 PM Hi! Well, I think rotation is always tricky with sinus, cosinus and such :)What is the problem with rotation? Do you need help on that? You don't have to do the distance estimation stuff. Just store whatever you compute at each pixel, I can use it in the shader. There are several ways to color the thing: - by escape time - by distance estimation - smallest absolute value of the orbit - phase of the last value that didn't escape - ... If you want to include anything of this, we can use it as well. Greetings! Mirko I am currently working on optimizing the movie maker by adding multi-threading, because it shouldn't take 4 times longer to create the movie than render the key frames! Can you do magic with the code from the two posts above then? Would be really cool :) Please remember that the pertubation method produce glitches. I tried to solve them automatically but it is far from being 100% perfect. The work around is the frame editing function, but it takes some efforts to go through all the frames and find and correct glitches. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on November 27, 2013, 10:25:39 PM I have just put an update of the Key Frame Movie Maker program, now version 1.8
I am sorry I did not have time to add the functionality to save and load settings. Go to http://biphome.spray.se/karl.runmo/fraktal2.htm and download it! :) Title: Re: Kalles Fraktaler 2 Post by: panzerboy on November 28, 2013, 01:21:49 AM Rotation and colour cycling just don't seem to work for me.
I've tried small and large values for colour cycling, with and without smooth color transitions. Specifying a rotation will make the video smaller The CPU usage seems quite bursty, the performance tab of task manager shows peaks and troughs. See the attached picture of my CPU usage history. MovieMaker.exe alternates between a low of 38% up to a high of 83% CPU, about half the time in the 40% to 50% range. The preview window is fairly stop-start, maybe rendering 10-15 frames then stopping for 1/2 a second end repeating this sequence. Its interesting that memory usage seems to cycle with the CPU usage, perhaps you are allocating and freeing chunks of memory? Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on November 28, 2013, 09:34:02 AM Rotation and colour cycling just don't seem to work for me. That's bad that cycling doesn't work. I updated the screenshot with a movie I am currently rendering, which is the same but slower that I called "Too much for youtube" because I like that location and coloring too much to just leave it as it is. That image might give you a hint. Otherwise, please explain why it doesn't work :)I've tried small and large values for colour cycling, with and without smooth color transitions. Specifying a rotation will make the video smaller The CPU usage seems quite bursty, the performance tab of task manager shows peaks and troughs. See the attached picture of my CPU usage history. MovieMaker.exe alternates between a low of 38% up to a high of 83% CPU, about half the time in the 40% to 50% range. The preview window is fairly stop-start, maybe rendering 10-15 frames then stopping for 1/2 a second end repeating this sequence. Its interesting that memory usage seems to cycle with the CPU usage, perhaps you are allocating and freeing chunks of memory? (http://biphome.spray.se/karl.runmo/screen1.png) Since I don't know how, and I don't think it's even possible, to write the AVI stream from parallel threads, the parallel step is only when the images are combined. When not using color cycling this occur for each key frame. When color cycling is used, it occurs for every movie frame, and therefore it reduces the time to render a movie almost 4 time on my quadcore laptop. By setting color cycle to 0 for parts of the movie the render will get much faster Title: Re: Kalles Fraktaler 2 Post by: panzerboy on November 28, 2013, 11:31:02 AM I'm rendering a video now. At about zoom level e009 it has started to rotate and colour cycle in the preview window.
I specified rotation and cycling from frame 0, see my attached GIF. e009 zoom level starts with file 00090_1.07e009.kfb, the first file is 120_0.9.kfb so that would be frame 30 in the rotation list? My first attempt I just set the frame 0 to constant speed colour cycling and/or rotation. Perhaps the rotation and cycling only kicks in for the 2nd item in the lists onwards? Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on November 28, 2013, 08:06:55 PM Thanks panzerboy!
This is because I made smooth transitions also for cycling and rotation. If you set the frame number to 1 instead of 0 for these it will work, but I will mak an update on this Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on November 28, 2013, 09:49:38 PM ...but now it seems my web-page on biphome doesn't work anymore.
I hope it's temprary, I have had this page for perhaps 15 years. If not I will try to find another location to place my page. Any suggestions are welcome. Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on November 30, 2013, 03:29:18 AM That's a shame. I was about to try the latest version of your program.
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on December 01, 2013, 09:51:42 PM 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!! :worm: Title: Re: Kalles Fraktaler 2 Post by: panzerboy on December 02, 2013, 05:20:06 AM 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 The later (resumed) file at 2:20pm has the same filenumber prefix "00158" perhaps it should be "00159"? Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on December 03, 2013, 12:21:38 AM 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. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on December 06, 2013, 07:49:54 PM 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 Title: Re: Kalles Fraktaler 2 Post by: SeryZone on December 09, 2013, 09:49:30 AM 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...
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on December 09, 2013, 12:47:11 PM 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? Title: Re: Kalles Fraktaler 2 Post by: SeryZone on December 09, 2013, 11:17:02 PM Quote 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... Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on December 12, 2013, 12:04:19 AM 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 Title: Re: Kalles Fraktaler 2 Post by: Chillheimer on December 15, 2013, 07:07:05 PM 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 Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on December 17, 2013, 12:14:48 AM 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 :) Title: Re: Kalles Fraktaler 2 Post by: Chillheimer on December 17, 2013, 01:31:54 PM 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! Title: Re: Kalles Fraktaler 2 Post by: SeryZone on December 22, 2013, 10:02:19 PM 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. Title: Re: Kalles Fraktaler 2 Post by: SeryZone on December 22, 2013, 10:03:46 PM But... SS planes on perturbation - FASTEST IDEA ON EARTH!!! But... This idea needs donating, you, maybe, understand, why...
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on December 22, 2013, 10:15:07 PM Hi Kalle! 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.I 'need' that huge resolution, because I make my videos in Full HD, using Rotation. ... This will be the last update for this year, but maybe not last update ever :) Merry Christmas to you all Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on January 02, 2014, 12:09:29 AM 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: (http://biphome.spray.se/karl.runmo/img1.jpg) 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: (http://biphome.spray.se/karl.runmo/img2.jpg) 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 :D) Now look at how these coefficients looks when lowest value is black and highest white: (http://biphome.spray.se/karl.runmo/img3.jpg) 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 (http://biphome.spray.se/karl.runmo/img4.jpg) 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. Title: Re: Kalles Fraktaler 2 Post by: Pauldelbrot on January 02, 2014, 12:24:18 AM :thumbsup1:
Though Nanoscope was using smoothed iteration values to distinguish cases like 1, 2, 3 from cases like 4 from its inception. :) Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on January 02, 2014, 09:50:40 AM Though Nanoscope was using smoothed iteration values to distinguish cases like 1, 2, 3 from cases like 4 from its inception. :) But what happened then, because I don't think you are using Nanoscope for the lovely images you are publishing here, and you haven't completed it have you?Did you get discouraged by all the different situations that can occur? Because it sometimes discourage me ;) Title: Re: Kalles Fraktaler 2 Post by: Pauldelbrot on January 02, 2014, 08:16:11 PM But what happened then, because I don't think you are using Nanoscope for the lovely images you are publishing here, and you haven't completed it have you? Did you get discouraged by all the different situations that can occur? Because it sometimes discourage me ;) Nah, I just have a lot of other stuff on my plate ... and most of the fractals I'm doing right now are reasonably fast with my C2 speedup or would not be sped up by Nanoscope (in the latter case, that means "not Mandelbrot"). Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on January 09, 2014, 11:53:22 PM I've just uploaded version 2.2.3
I tried to fix the crash bug when clicking to zoom further while the render of the current view is not yet complete. This should of course be possible, as it is in all other Mandelbrot programs. I have still not been able to crash it now, but one can never be sure... I also made it possible to zoom in and out with + and - keys, and even with the mouse wheel, even though I don't have a mouse, I only use touch-pad. So I have no idea if it works, but I hope so, and that in and out behaves as expected :D Code: else if(uMsg==0x020A){//WM_MOUSEWHEELTitle: Re: Kalles Fraktaler 2 Post by: simon.snake on January 10, 2014, 12:39:33 AM Hi Carl.
Your site has been down most of today. I wanted to see what the speed options are when creating the zoom movies from the individual frames. E.g., what does a speed of 25 mean? I've managed to re-create all the zoom images after modifying the zoom level as you described in your reply to my other post, and it's allowed me to view the sequence and correct a few glitches that it has found along the way. There's just a few frames that I've not been able to fix, but hopefully one or two out of 2012 is not too noticeable. Thanks again. Simon Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on January 10, 2014, 12:37:18 PM Your site has been down most of today. Yep, it is down also now, but comes up sometimes...I wanted to see what the speed options are when creating the zoom movies from the individual frames. E.g., what does a speed of 25 mean? It means that there will be 25 movie-frames per key-frame. Use FPS 30 if you want to put it on youtube, which means 30 movie-frames per second.I've managed to re-create all the zoom images after modifying the zoom level as you described in your reply to my other post, and it's allowed me to view the sequence and correct a few glitches that it has found along the way. Great, it would be nice to see it :)There's just a few frames that I've not been able to fix, but hopefully one or two out of 2012 is not too noticeable. Thanks again. Simon Title: Re: Kalles Fraktaler 2 Post by: simon.snake on January 10, 2014, 01:51:34 PM Try the following:
http://www.youtube.com/watch?v=fRW199hvfxk I apologise for the lousy quality, I did create the movie at 960x540 resolution but youtube has messed that up! Simon Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on January 12, 2014, 07:21:25 PM Super awesome! The mousewheel zooming is inverted. Scrolling up zooms out and scrolling down zooms in. Other than that, it works.
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on January 12, 2014, 09:32:40 PM Super awesome! The mousewheel zooming is inverted. Scrolling up zooms out and scrolling down zooms in. Other than that, it works. Thanks, but still not on your super 32-core hardware, right...?Ok I will flip the if-condition :) Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on January 13, 2014, 07:03:29 PM It still crashes at startup.
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on January 21, 2014, 08:38:16 PM New versions available
Kalles Fraktaler 2.2.4: mousewheel zooming swapped to be as expected. The floatexp 'double precision arbitrary exponent' class made 2-based which yielded more than double speed when zooming deeper than e4920 Key frame movie maker 1.15: a resource leak found and fixed. Only affected thouse 45+minutes movies... Is anyone interested in having this project available as open source? Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on January 21, 2014, 09:32:51 PM (http://i538.photobucket.com/albums/ff342/formule/kalles_crash.png~original)
I made a fresh install of windows 7 on my computer and Kalles Fraktaler still crashes and the same way. Now I really don't know what else to do. Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on January 21, 2014, 11:41:25 PM Okay, I know what the problem is. There was one last thing I thought could have been it, although highly unlikely, being the two physical CPUs. I disabled one of my two physical CPUs in the bios and Kalles Fraktaler works perfectly now. Apparently indeed Kalles Fraktaler can't handle the two physical CPUs! I found it so unlikely that I actually decided to do a fresh OS install before trying this, and I gotta say I'm very surprised. The operating system should be a layer between the hardware and the software so this should either not be possible or it should happen to more programs, but it doesn't. What the hell?
Title: Re: Kalles Fraktaler 2 Post by: simon.snake on January 22, 2014, 11:49:57 AM Okay, I know what the problem is. There was one last thing I thought could have been it, although highly unlikely, being the two physical CPUs. I disabled one of my two physical CPUs in the bios and Kalles Fraktaler works perfectly now. Apparently indeed Kalles Fraktaler can't handle the two physical CPUs! I found it so unlikely that I actually decided to do a fresh OS install before trying this, and I gotta say I'm very surprised. The operating system should be a layer between the hardware and the software so this should either not be possible or it should happen to more programs, but it doesn't. What the hell? That's a bizarre situation. Only time I ever had a problem with a cpu was when I had an AMD processor and I purchased some software that would allow the user to speak into the microphone and dictate to the word processor. Unfortunately, it only worked on Intel processors and simply crashed on AMD processors, but the shop that I purchased it from wouldn't accept that the program was at fault and wouldn't offer me a refund. Thankfully, I only paid £5 or so for the software, so I didn't complain too much at the time. Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on January 22, 2014, 04:07:58 PM I also have AMD processors if that helps. Intel may be better overall nowadays, but their products are so expensive...
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on January 22, 2014, 05:04:36 PM Dinky, I sent you a PM
I made a debug version with exception handling, that display the position of the crash in a popup. I hope you please want to test it and let me know the result. http://biphome.spray.se/karl.runmo/fraktal_sft64d.zip Your screen-dump image was very informative, thanks for that. From it I can see that the progress is 100%, so all 32 threads has been started and finished their job without problem. However the status bar doesn't display the text "Done", so something is crashing the program when the render is completed. (if there is no popup displayed, the crash is happening earlier though...) That is a limited part of the program, that can to be examined further. 16 cores is in it self awesome, maybe tick-tock can be rendered in 1 second, but 32 cores and 0.5 seconds is of course better :) Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on January 22, 2014, 07:26:31 PM Unfortunately it doesn't give any pop-ups. It crashes the same way as other versions of your program.
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on January 22, 2014, 08:22:42 PM Unfortunately it doesn't give any pop-ups. It crashes the same way as other versions of your program. OK, then the crash occurs earlier.If you don't mind: http://biphome.spray.se/karl.runm/fraktal_sft64d2.zip I moved exception handling earlier in the process... Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on January 22, 2014, 08:48:24 PM What did you change? Keep it this way! It works, without any errors at all.
It asked for the missing ldbl64.dll file to speed up rendering, but it worked even without the file. I copied it from your previous "normal" release and it still works. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on January 22, 2014, 09:53:50 PM What did you change? Keep it this way! It works, without any errors at all. Oh, that is super!!It asked for the missing ldbl64.dll file to speed up rendering, but it worked even without the file. I copied it from your previous "normal" release and it still works. If you put ldbl64.dll in the same folder and restart, and then zoom deeper than e300, does it still work? I have two variants of my parallel thread class, and I changed the execution plan for the one using ordinary double. If it crash when you go past e300, I will simply change all 3 of them (double, long double, floatexp) Otherwise I don't understand this, but that would not matter much :embarrass: Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on January 22, 2014, 10:16:55 PM It works when I load such a deep location from a file. The program still crashes every now and then. Sometimes I get the error "pos = 5", sometimes not (even when I do exactly the same things). Let's say it works "most of the times".
Tick tock renders in 1,5 seconds. Title: Re: Kalles Fraktaler 2 Post by: Pauldelbrot on January 22, 2014, 10:34:03 PM This sounds like a race condition to me. Between the intermittency, nondeterminism, and dependence on number of physical CPUs, that seems more likely than any alternative.
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on January 22, 2014, 10:57:17 PM I have put a version 2.2.5 that all depths have the simpler execution of the parallel threads (which don't affect anything else since the number of parallel task is the same as threads).
"pos = 5" is the last position shown, and this is when memory is freed up. Can it be that competing threads on several physical CPUs is more sensitive? Anyway, I am glad of this progress. :chilli: :banana: :worm: Since you are used with Fractal eXtreme you are probably scrolling alot, with the mouse-wheel, without stopping the ongoing render process, and I have problems to make that total stable. Be gentle with the mouse-wheel ;) Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on January 22, 2014, 11:08:09 PM Yeah, I noticed that the program is somewhat sensitive to fast scrolling. I zoom very fast with fractal extreme. With Kalles Fraktaler that's not even possible. Instead of showing very zoomed the last rendered pixels like fractal extreme, the window becomes completely black after a few zooms.
Every time the "pos = 5" error occurs, the rendering continues normally, but then zooming further makes the program crash. Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on January 23, 2014, 01:45:14 AM It doesn't even crash anymore with the latest version. You fixed everything in one day. That's some very nice work. I'm zooming to an extreme location, then I will render the most extreme zoom ever, even extremer than that one to 2^3039 and passed several minibrots.
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on January 23, 2014, 05:01:54 PM It doesn't even crash anymore with the latest version. You fixed everything in one day. That's some very nice work. I'm zooming to an extreme location, then I will render the most extreme zoom ever, even extremer than that one to 2^3039 and passed several minibrots. I have uploaded a new version, 2.2.6, now it is possible to do ungentle scrolling with the mouse-wheel and no black intermediate images appears!I must admit it does improve the exploring experience! An extreme movie from you would be my reward and make my efforts worth it :dance: Please note that if you pass several minibrots, you will unfortunately have a to do a lot of extra efforts to examine the frames and manually add reference to correct glitches that the automatic function fail to discover (even if I constantly improve this function for every new version...) And also, with perturbation and series approximation, all iteration values are stored in a list, 8 byte double up to e300, 16 byte long double up to e4920 and 16 byte floatexp for deeper. So I think there is a limit of maybe some 100 millions iterations, which takes some gigabyte in memory usage. Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on January 23, 2014, 09:04:21 PM Nice, it's getting better and better. You have created a highly efficient mandelbrot render and exploring program. Several people are using it. It automatically solves blobs, has support for ultra-extreme depths and many CPU cores. You have broken the record of the deepest zoom several times with your own software, and it's getting better by the minute. You have achieved a lot already.
Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on January 27, 2014, 01:26:46 AM When I use "auto solve glitches" while rendering a zoom out sequence, the center of the images jumps around. It looks like it uses the last calculated reference point to zoom out from, instead of the center of the image. Is that true? If so, why can auto solve glitches not be used in zoom out sequences? It would save a lot of time not having to do it by hand.
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on January 27, 2014, 08:24:57 AM When I use "auto solve glitches" while rendering a zoom out sequence, the center of the images jumps around. It looks like it uses the last calculated reference point to zoom out from, instead of the center of the image. Is that true? If so, why can auto solve glitches not be used in zoom out sequences? It would save a lot of time not having to do it by hand. No that is not how it should work, not at all. I think most movies are done with auto solve glitch on. Are you combining it with reuse reference? Sorry that is not possible. Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on January 27, 2014, 02:57:39 PM 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? Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on January 27, 2014, 09:36:36 PM Yes, I also had reuse reference on. What is the difference between 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.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? 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...) (http://biphome.spray.se/karl.runmo/npg1.jpg) 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: (http://biphome.spray.se/karl.runmo/npg2.jpg) 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. (http://biphome.spray.se/karl.runmo/npg3.jpg) 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. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on January 29, 2014, 05:35:37 PM I your version is 2.2.9 don't use it, current version is 2.2.10!
Title: Re: Kalles Fraktaler 2 Post by: SeryZone on January 31, 2014, 06:49:56 AM I wait for 2.2.10)))
Title: Re: Kalles Fraktaler 2 Post by: panzerboy on January 31, 2014, 03:41:49 PM Though the website says v2.2.9 the version I downloaded says 2.2.10.
Perhaps Karl is busy with other things (programming?) Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on January 31, 2014, 06:52:23 PM Though the website says v2.2.9 the version I downloaded says 2.2.10. 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. Perhaps Karl is busy with other things (programming?) 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 :) Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on January 31, 2014, 07:49:43 PM 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. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on January 31, 2014, 09:06:18 PM 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: That is bad, and hard to replicate for me. 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. 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) Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on January 31, 2014, 10:04:24 PM 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. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on February 01, 2014, 12:05:56 AM 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 :) Title: Re: Kalles Fraktaler 2 Post by: Chillheimer on February 01, 2014, 09:12:44 AM 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 Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on February 01, 2014, 01:09:45 PM Hi Kalle! Cool. You are really driving my program to extremes. And I like it very much, thanks a lot, it is pleasant challenges.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 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? Title: Re: Kalles Fraktaler 2 Post by: Chillheimer on February 01, 2014, 05:20:53 PM 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 ;DBut I would never criticize you and tell you to redo you render. Go ahead and criticize.. good feedback is always welcome :)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? 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: http://www.youtube.com/watch?v=NedXxP3Uur0 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 ;) Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on February 02, 2014, 09:48:24 AM 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? Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on February 04, 2014, 10:57:40 AM 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. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on February 04, 2014, 02:11:58 PM 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) Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on February 04, 2014, 08:18:31 PM Can kalles fraktaler be used with CMD to create kfb files using given settings?
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on February 04, 2014, 09:40:47 PM No unfortunately not.
What version are you using? Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on February 04, 2014, 10:23:34 PM I'm using version 2.2.10.
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on February 04, 2014, 11:50:31 PM Have you continued the render, is it running now?
I have had a look at the bitmap and found a thing that I corrected recently, but that us included in version 2.2.10. I will look some more... If my site is not accesible within a couple of days I will put updates somewhere else. Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on February 05, 2014, 12:48:50 AM Kalles Fraktaler crashed again after one frame of which the JPEG file was again incorrect. It's not running right now because I'm out of ideas. The strangest is that everyone appears to be able to render videos, and I have been able to do a few simple test videos, and now in a real world scenario all those strange things happen.
I haven't seen it fail in the middle of a render, though, so that's why I was wondering if it's possible to use it with CMD. Then it would be easy (or I should say "possible") to make a batch file and let all the frames be rendered separately. I used to make apophysis animations that way. It's a very flexible method. For example, multiple batches could be run at the same time to fill up empty CPU time when a reference point is being calculated using 1 core. Such renders can be easily resumed if anything happens. It's generally more reliable, and when a crash occurs the damage is easier to repair. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on February 05, 2014, 05:39:33 PM Thanks to Chillheimer I am now able to make a new version of this experimental prototype of application available :)
The update can be downloaded from http://www.chillheimer.de/kallesfraktaler The news of Kalles Fraktaler 2.2.11 are * Super smooth coloring. The old color method is still accessible via the "Iterations" dialog (I put it there since it is affecting the bailout value and needs the whole view to be re-render) * Option to select if jpegs are not to be created when making zoom sequence. * I have gone through the code and tried to prevent the bitmap from being accessed from concurrent threads, which I think may cause the program to crash. The news of Key Frame Movie Maker 1.17 is that the performance is improved, thanks to Yann Lby (via youtube) that gave me tips. Title: Re: Kalles Fraktaler 2 Post by: panzerboy on February 05, 2014, 09:29:23 PM I get a "Failed - No file" when trying to download the movie maker.
The two versions of Kalles Fraktaler download and run okay. The new smooth colouring looks nice ;D Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on February 05, 2014, 10:18:05 PM Thanks for that panzerboy, sorry I forgot to upload that file.
Please try again :) Title: Re: Kalles Fraktaler 2 Post by: SeryZone on February 08, 2014, 10:40:46 AM I was downloaded new version! It is cool! You set high bail-out value! I was think that perturbation can't use high bail-out...
What's happened with your biphome.spray profile? I was download your 'Kalles Kalkylator' - cool program! Title: Re: Kalles Fraktaler 2 Post by: simon.snake on February 12, 2014, 09:51:02 PM I've been generating another interesting zoom to e637 (it's taken most of the time to redraw the frames as a lot of them were generated offset from the centre). I'm down to the last 3 or 4 hundred to check.
I have found out what all the items in the status bar at the bottom of the window except the last one, the S: value. I'm sure I'll kick myself when I find out, so please put me out of my misery. Thanks Simon Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on February 12, 2014, 10:06:55 PM I've been generating another interesting zoom to e637 (it's taken most of the time to redraw the frames as a lot of them were generated offset from the centre). I'm down to the last 3 or 4 hundred to check. S = Smooth coefficient, a value between 0 and 255.I have found out what all the items in the status bar at the bottom of the window except the last one, the S: value. I'm sure I'll kick myself when I find out, so please put me out of my misery. Thanks Simon It is displayed so that I might be able to see why any blob doesn't get solved automatically. So it is more for debugging than being informative :) Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on February 19, 2014, 10:13:07 PM I've just uploaded a new version - 2.3
Thanks to Botond Kósa I got a couple of tips to speedup the render, which is now some 3 times faster. On my machine the bench-mark view "tick-tock" was rendered in 8.5 seconds - it is now rendered in 2.7 seconds, on my machine. Still a way to go to Mandel Machine that renders tick-tock in 1 second on my machine, but it is still a big improvement. Also Key Frame Movie Maker is updated to version 1.18 since I found a bug related to the caching function I implemented in the last version - everything except the maximum iteration value was stored in the cache, which caused problems when one stop the zoom sequence render and lower the maximum iteration value, which I usually do in order to faster render the initial close passage of the main Mandelbrot. I think this will be the last update on Kalles Fraktaler, since my knowledge in assembler optimizations is very limited (unless an insurmountable bug is found or something new revolutionary is discovered). I leave with a warm hand to Mandel Machine to take the lead in the realization of the perturbation and series approximation methods. Thank you all for your interest! PS. But I will sure publish a movie once in a while with my program. ;) Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on February 19, 2014, 11:21:19 PM The time to render tick-tock has been reduced to 0.97 seconds here, so it's not much of a difference, but that zoom I'm rendering at high-resolution and very deep, that's where I really notice the extra speed. Really 3 times faster? Even more, I'd say.
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on February 19, 2014, 11:29:24 PM The time to render tick-tock has been reduced to 0.97 seconds here, so it's not much of a difference, but that zoom I'm rendering at high-resolution and very deep, that's where I really notice the extra speed. Really 3 times faster? Even more, I'd say. Tick-tock may not be the best view to use for comparison, since it is now rendered so fast that the overhead of image handling, glitch detection, etc is significant. I was rendering an animation and when I stopped it the frames were rendered in 8 minutes each. When I continued it in the new version the following frames where rendered by 3 per minute... :) Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on February 23, 2014, 07:54:10 PM An insurmountable bug was found and fixed.
Minibrots between e300 and 4920 got distorted, which is now corrected. Newest version is 2.3.1 Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on February 27, 2014, 08:43:29 PM Another update, now version 2.3.2
Just a couple of bug-fixes 1. I was surprised that Mandel Machine have fewer glitches even though only double precision is used in both programs. I realized that I transferred to few digits from the arbitrary precision library to the double variables, I have done that all the time, sorry for all the unnecessary glitches. Anyway, solved now! 2. Long double in gcc does not behave as I expected on overflow or underflow, they seem not get into an erroneous state instead just takes the highest or lowest possible value. This caused a glitch when using large bailout smooth coloring at very deep zooms, i.e. >e1000. 3. The extra references were not always placed as intended, causing unnecessary glitches on automatic glitch correction. 4. Large bailout causes long double to overflow already at e4900, so I lowered the value when floatexp is used (are anyone else than me ever going that deep... ;)) I am planning to publish the source of Kalles Fraktaler, but I want to make a version for this that is compiled in the free compiler gcc and Bloodshed DevC++ (instead of VS) But I am stuck in problems regarding operators and references in my arbitrary precision class. I had this problem also in the floatexp class, but since that class only contains two variables, the cost of copying the parameters on each call isn't that big. Example: Code: //How I would like it to be: Does anybody have knowledge in how to solve this? Title: Re: Kalles Fraktaler 2 Post by: hobold on February 28, 2014, 12:48:40 AM I am planning to publish the source of Kalles Fraktaler, but I want to make a version for this that is compiled in the free compiler gcc and Bloodshed DevC++ (instead of VS) Try declaring the input parameters as "const" references. You might have to declare the function itself as "const", too, to meet the strict behaviour of the operators that you are trying to overload. So you would have something like:But I am stuck in problems regarding operators and references in my arbitrary precision class. I had this problem also in the floatexp class, but since that class only contains two variables, the cost of copying the parameters on each call isn't that big. floatexp operator =(const floatexp& a) const { . . . } Title: Re: Kalles Fraktaler 2 Post by: 3dickulus on March 02, 2014, 10:40:01 PM I am planning to publish the source of Kalles Fraktaler, but I want to make a version for this that is compiled in the free compiler gcc and Bloodshed DevC++ (instead of VS) That sounds like something I'd like to play with... just looking over some other operators in some mathlibs (wanting to make a GPU arbitrary complex type) and this is how I see it in these libs... single args to return *this Code: floatexp& operator=(const floatexp&); two args to return define var other than *this Code: floatexp operator*(const floatexp& a, const floatexp& b) {edit: http://code.google.com/p/heo/source/browse/trunk/contrib/arprec/include/arprec/mp_complex_inline.h has a myriad of operator decls :) Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on March 09, 2014, 09:00:50 PM Uncompileable code can be downloaded from http://www.chillheimer.de/kallesfraktaler/fraktal_src.zip
Free to use and distribute, an acknowledge is appreciated but no responsibility taken. If anyone is able to compile it with gcc, or have any opinions on how I solve things, positive or negative criticism, please share. ƘᎥИÐ ЯЄ❡ᗩЯÐᔕ ƘᗩℓℓЄ Title: Re: Kalles Fraktaler 2 Post by: Chillheimer on March 10, 2014, 07:46:33 PM very generous and cool step you took there kalle!
thank you! Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on March 14, 2014, 01:14:02 AM This reminds me of the structures that sometimes appear inside minibrots, except this time it's not in minibrots.
(http://i538.photobucket.com/albums/ff342/formule/rare_glitch.png~original) Left contains glitches, right is correct. The program uses many reference points to render it like this, but it is often fixed just by placing the main reference in the center of such a distorted spiral. Title: Re: Kalles Fraktaler 2 Post by: knighty on March 14, 2014, 06:34:22 PM It's a Misiurewicz (pre-periodic) point which make good reference points. see: http://www.fractalforums.com/announcements-and-news/mandel-machine/msg71597/#msg71597
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on March 16, 2014, 07:40:24 PM The program uses many reference points to render it like this, but it is often fixed just by placing the main reference in the center of such a distorted spiral. Yes, structures can appear on any glitches, your flake view is one of the most palpable, but on other views it may be enough with only one reference to render the whole view without any glitches.But how can a program know which pixel in advance? Maybe if the program first calculates one pixel per 10 in a grid, i.e. 1/100 of all the pixels, or maybe even less, and if any of these pixels has higher iteration count than the center, it stops and use that pixel as main reference. It won't find the exact best pixel to use as reference, and would still need to add references, but maybe structured glitches can be avoided? Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on March 16, 2014, 09:38:46 PM I'm afraid there would still be exceptions. These glitches appear throughout my video, so I spent a few days solving them. Placing the main reference in a distorted spiral fixes the spirals, but often it makes the center inaccurate! In particular that happens when there is something complex in the center like a julia set with shapes inherited from the last minibrot passed by. In such situations it usually helps to place the main reference point somewhere close to the center but not exactly in the center, while sometimes simply nothing works.
Fortunately, far into the zoom and close to the final minibrot, where the render time gets extreme, the structures including the spirals become so small that the distortions aren't visible anymore. I wonder where the lack of accuracy comes from. Clearly the theory works otherwise we wouldn't be able to render anything at all. There are just some errors somewhere. I think the glitch problem should be solveable without workarounds somehow. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on March 17, 2014, 02:14:19 PM I think the glitch problem should be solveable without workarounds somehow. That is my wish too, but I haven't found it. And no one else either as far as I know, and we are several that have struggle with it. Unfortunately my knowledge in chaos math is too limited to find a solid or theoretical solution, I am only able to do workarounds... Manual glitch solving needs, currently(?), to be an enjoyable(?) part of the rendering ;) Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on March 17, 2014, 10:27:41 PM I found a bug :o that I have corrected: one GDI handle leaked for every zoom-in. :embarrass:
Two more things I have played with also got added, version 2.3.3 - scaled double between e300 and e600, which increases speed on this interval with more than 3 times :horsie: - maximum depth more than e100000 ;D Available on http://www.chillheimer.de/kallesfraktaler/ Title: Re: Kalles Fraktaler 2 Post by: hapf on March 18, 2014, 11:14:24 AM That is my wish too, but I haven't found it. Glitches are unavoidable given the limited resolution of double hardware computations (or any other format, if you zoom deep enough). Depends where you zoom if you see any or not. The deeper and the more embedded Julia sets the more glitches and the more references needed to solve them. The real problem are not the glitches. The real problem is finding out which pixels are affected by glitches (aka corruption). Once you know that blob fixing is not a big issue. Doing it most efficiently is a challenge, though (e.g. recomputing all corrupted pixels with arbitrary precision is not efficient).And no one else either as far as I know, and we are several that have struggle with it. Unfortunately my knowledge in chaos math is too limited to find a solid or theoretical solution, I am only able to do workarounds... Manual glitch solving needs, currently(?), to be an enjoyable(?) part of the rendering ;) Title: Re: Kalles Fraktaler 2 Post by: Chillheimer on March 18, 2014, 11:23:59 AM great to see that you're still working on improving it :)
may I recommend to make a dedicated post that you made kf open source? this crucial info might otherwise drown in this huge thread. Title: Re: Kalles Fraktaler 2 Post by: 3dickulus on March 19, 2014, 03:53:18 AM regarding operators and references in my arbitrary precision class. in my .h file the operators look like... Code: floatexp& operator=(const floatexp& other); and in the .cpp file like... Code: floatexp& floatexp::operator=(const floatexp& other) this is working in GCC 4.7, hope this helps :) Title: Re: Kalles Fraktaler 2 Post by: SeryZone on March 19, 2014, 06:45:03 AM Thank you, Karl!!! Now we can zoom to infinity!!!
P.s. I don't understand how your classes works... For SIMD I learn 'Raw' code with standart types... Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on March 21, 2014, 07:25:19 PM Thank you, Karl!!! Now we can zoom to infinity!!! SIMD is not so difficult after allP.s. I don't understand how your classes works... For SIMD I learn 'Raw' code with standart types... http://www.codeproject.com/Articles/4522/Introduction-to-SSE-Programming But it would require a re-arrangement of everything in Kalles Fraktaler and I don't feel that it is worth it. Because there is no SIMD/SSE available for the 80-bit long double datatype, that KF use when zooming deeper than e600. And if you use pixel grouping 1 in Mandel Machine, i.e. no SIMD/SSE, it is as "slow" as Kalles Fraktaler, so I don't think my program is so bad after all. :) But still, Kalles Fraktaler is and will always be an experimental prototype and will never be a commercial product. I shared it at the first place only so that people like Dinkydau could run it on their super hardware :) Title: Re: Kalles Fraktaler 2 Post by: lycium on March 21, 2014, 08:37:30 PM double precision hasn't been 80bit for a long time, it's 64bit. long double isn't 80 bit either anymore, iirc.
Title: Re: Kalles Fraktaler 2 Post by: claude on March 21, 2014, 08:51:13 PM double precision hasn't been 80bit for a long time, it's 64bit. long double isn't 80 bit either anymore, iirc. depends on compiler / architecture - if in doubt, test it! Code: $ uname -a Title: Re: Kalles Fraktaler 2 Post by: lycium on March 21, 2014, 08:52:50 PM Yup, and in your example you could have mentioned the architecture ;)
What I do know is that you don't have 80bit FP in 64bit mode, i.e. with SSE. Title: Re: Kalles Fraktaler 2 Post by: claude on March 21, 2014, 09:00:30 PM Yup, and in your example you could have mentioned the architecture ;) sorry, here it is Code: $ file numeric-limits Title: Re: Kalles Fraktaler 2 Post by: lycium on March 21, 2014, 09:14:07 PM Hmmmmm, that's very interesting! I was under the impression that FP maths is always 64bit on modern archs, though I guess this could still be true (and the 80bit is being emulated).
Title: Re: Kalles Fraktaler 2 Post by: Botond Kósa on March 21, 2014, 09:27:04 PM Hmmmmm, that's very interesting! I was under the impression that FP maths is always 64bit on modern archs, though I guess this could still be true (and the 80bit is being emulated). There is no restriction on machine code using 80bit FP maths is x64 mode. The precision of the generated machine code depends on the compiler used. Microsoft's C/C++ compiler generates code that uses the SSE registers and instructions, therefore it is limited to 64bit precision. GCC is still able to generate code that uses the old x87 register stack with 80bit precision. This is also possible in assembly code, of course. BTW, Kalle, what compiler do you use for Kalles Fraktaler 64bit? Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on March 21, 2014, 09:52:25 PM BTW, Kalle, what compiler do you use for Kalles Fraktaler 64bit? I use VS10 for most of the program and for 80-bit long double I made a dll in gcc Bloodshed DevC++ which is freeware. You can get it from here :) http://www.fractalforums.com/other-b130/kalles-fraktaler-2-open-project/ Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on April 03, 2014, 06:44:20 AM What is this?? It looks like a julia set, but kalles fraktaler can't even render julia sets. There's supposed to be a minibrot here.
(http://i538.photobucket.com/albums/ff342/formule/julia_set.png) Code: Re = -1.76867872112652352344459411386653663775287705156707967520571895215849441304559320913172522013960055361761841257031034787731503477 Magnification: 1.83475743775E106 Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on April 03, 2014, 10:31:03 AM What is this?? It looks like a julia set, but kalles fraktaler can't even render julia sets. There's supposed to be a minibrot here. Strange... Are you using version 2.3.3? I think I had a bug that distorted minibrots in an earlier version (2.3 - 2.3.2)http://i538.photobucket.com/albums/ff342/formule/julia_set.png Code: Re = -1.76867872112652352344459411386653663775287705156707967520571895215849441304559320913172522013960055361761841257031034787731503477 Magnification: 1.83475743775E106 I tried the location in 2.3.3 but I did get a minibrot in the center, 10 million max iterations required. Title: Re: Kalles Fraktaler 2 Post by: SeryZone on April 03, 2014, 01:40:43 PM Aaaaaaaaaahahhahahahha, Dinkydau, I tried too render Verstoppertje, in MM and I seen same as this ;D ;D ;D
Title: Re: Kalles Fraktaler 2 Post by: ellarien on April 03, 2014, 01:57:02 PM I came across something similar once, but unfortunately didn't save the evidence. There was a slightly distorted minibrot, I tried to glitch-fix it, and it turned into something Julia-shaped. Another attempt at fixing sorted it out. (It wasn't so deep that it was a big problem -- I hardly ever go past about 10^6 iterations.) It was a few weeks back, but I think it was after the version that mentioned fixing the distorted-minibrot problem.
Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on April 03, 2014, 06:15:26 PM Strange... Are you using version 2.3.3? I think I had a bug that distorted minibrots in an earlier version (2.3 - 2.3.2) I tried the location in 2.3.3 but I did get a minibrot in the center, 10 million max iterations required. Maybe it matters that the resolution was 3840×2160? I just got the correct minibrot in low-resolution right from the start. In high resolution I placed the reference point inside the weird julia set, then there was what seemed to be some circle-like julia set, and when I placed the main reference in the middle of that, the correct minibrot appeared after all. Title: Re: Kalles Fraktaler 2 Post by: laser blaster on April 03, 2014, 06:56:39 PM I encountered a black colored Julia set while zooming in Kalles Fraktaler, and all I had to do was increase the iterations, and it was fixed. I thought that was normal behavior.
But I did find a glitch that you might already know about. If you keep zooming into the very tip of the needle of the M-set, the auto glitch fixing stops working and the screen gets half-covered in a solid color. In general, the needle of the set is prone to glitches. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on April 03, 2014, 08:49:50 PM Maybe it matters that the resolution was 3840×2160? I just got the correct minibrot in low-resolution right from the start. In high resolution I placed the reference point inside the weird julia set, then there was what seemed to be some circle-like julia set, and when I placed the main reference in the middle of that, the correct minibrot appeared after all. My biphome site hasn't worked at all for some week now, and I haven't been able to upload anything for several months. The page on Chillheimer's domain is the official site now :) I encountered a black colored Julia set while zooming in Kalles Fraktaler, and all I had to do was increase the iterations, and it was fixed. I thought that was normal behavior. It is probably the addends that cause this thing in the needle too.But I did find a glitch that you might already know about. If you keep zooming into the very tip of the needle of the M-set, the auto glitch fixing stops working and the screen gets half-covered in a solid color. In general, the needle of the set is prone to glitches. I will make an update this weekend with some other small things as well. :) Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on April 12, 2014, 01:25:28 AM Since Kalles Fraktaler still rules the universe as being the fastest Mandelbrot explorer beyond e600 available to all known lifeforms, I have made a new version. Both Kalles Fraktaler, now version 2.3.4, and Key Frame Movie Maker version 1.19.
I will (perhaps) add more info later, but here is some of the updates: * Bug fixed on zooming the spike with bailout = 2. But with the fixedfloat ap class you cannot go deeper than e50000 at <-2,0i> with precision 100000 since there will be 50000 zeroes... * Glitch solving movie frames - go backwards, fix glitches and bring the center to the next (previous) frame * Glitch solving movie frames - jump directly to desired frame * Fractional iteration division - can be especial cool on movies but division change must be small to avoid too much flicker. Iteration division can be lower than 1. * Square root, Cubic root, logarithm and an experimental histogram coloring, available also for movies (but none of them fully tested yet) * Color dialog changes in realtime Available on www.chillheimer.de/kallesfraktaler Thank you Chillheimer for hosting my program, and to all of you who have given feedback, published result, or ever used it :thanks1: :flowers: Title: Re: Kalles Fraktaler 2 Post by: panzerboy on April 12, 2014, 04:30:23 AM :thanks1: Fractional Iteration division! :joy:
What does the number of colours control in the movie maker do? Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on April 12, 2014, 10:38:29 AM What does the number of colours control in the movie maker do? I always wanted smooth change of density, so when I gave up the fractional iteration division I instead changed the number of key colors in the palette, when decreased the denisty is also decreased. But changing the number of colors is limited though, and now when I got FID working, it should be much better. I haven't published any movie with it yet though. I have noticed that if you start with division=1, it will be only flickering to go to 2 on say 25 movie-frames. It doesn't get smooth unless you change it to as little as to 1.01 or ever 1.001. Some more news: * You can specify from which frame KFMM start from, and * Less key frames used on preview, which make it easier to test things like iteration divisions. * Color cycling in the Color dialog - the value of all edit boxes with arrows at right can be changed with the arrow keys on the keyboard, so that it is possible to "animate" their effects Title: Re: Kalles Fraktaler 2 Post by: youhn on April 12, 2014, 08:08:47 PM Kalles,
I just began using your program. I love how it is oriented around fast Mandelbrot navigation. But I noticed a frustrating thing, that only happens now and then. Sometimes when zooming into an area, it display an area which is slightly off. Sometimes the center falls off-screen. Perhaps a bug, perhaps I'm doing something wrong? Title: Re: Kalles Fraktaler 2 Post by: panzerboy on April 13, 2014, 08:36:48 AM I have also experienced the strange veering off behaviour on one my first mandelbrot with version 2.3.4 (64bit).
On 3 more since that one it hasn't happened again. I was counting how many zooms between losing the centre, I got to 14. The Color Offset box requires you to enter the offset in reverse order. If you want to enter 256 you have to type 652. I haven't been able to generate a generate a zoom sequence since my initial attempt. After the first (ending frame) the frames are blank and tick over with great rapidity like there is no calculation happening just rapid saving of completely black frames. My first attempt with v 2.3.4 worked, that was a test at 320x180 resolution. Increasing the size to 2560x1440 I got 3 or 4 frames at the end then the rest were blank. Now all I get is that first (end) frame in my last 4 attempts at different sizes, palettes, divide iterations, offsets. Title: Re: Kalles Fraktaler 2 Post by: ellarien on April 13, 2014, 09:26:41 AM Same here. :sad1: The first frame (minibrot) frame rendered OK, then it's all black until the last few frames, which show a black circle on a coloured background. Looks like a problem with the iteration limits -- the iteration min and max were 0 and 48 on that final frame! This was starting from a location found in 2.3.3, but a quick test zoom directly in 2.3.4 wasn't much better -- obviously not enough iterations to see anything. (Win 8.1 64-bit, 8Gb RAM).
Title: Re: Kalles Fraktaler 2 Post by: panzerboy on April 13, 2014, 10:18:11 AM I've got a zoom sequence to work, but there is the occasional off center frame. :confused:
I've attached the culprits below. Here is the location Code: Re: -0.73920582659370281682685512479845850584098027008338793734257008861815634637782009327111599831853904049379810588968799636119695786894830387465331255740564889038171690897165125105798735790108311698144532 When I was zooming in the center always moved down and right, in the attached pictures the center has moved up and left in the reverse zoom direction. I've overlaid these jpgs in GIMP and the center don't quite line up so the offset isn't quite consistent. Title: Re: Kalles Fraktaler 2 Post by: Botond Kósa on April 13, 2014, 02:25:54 PM The decentering issue is present on still images as well (see attached images and kfr file). This is a regression between versions 2.3.3 and 2.3.4. It may be related to parsing the location coordinates.
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on April 13, 2014, 06:41:16 PM Thanks all for testing, thanks for your replies!
I have put a new version, 2.3.5, on www.chillheimer.de/kallesfraktaler that I solve 3 issues: When I resumed an zoom sequence, I found that all the following, but the first, got black, so I hope this is what also was your problems. It had to do with the histogram coloring and is fixed now. The other problem may be due to that I have tried to slim the precision of the arbitrary precision calculation, and it seems I slimmed it too much. Every 8 more decimals requires an additional integer, so for the same number of iteration, the calculation time is doubled for every 8 decimals. But a location on 1e100 requires more than 100 decimals, and I want it to not use more extra decimals than necessary. It is hard for me to know how exactly how many extra decimals is required, different location seems to require different amount, maybe because of joints of those 8-digit integers I am using. I have now added one extra so I hope it is enough. The value of Color cycling is updated when exceeding 1024, but should of course not always be updated... Title: Re: Kalles Fraktaler 2 Post by: ellarien on April 14, 2014, 12:07:27 AM Thanks! The zoom-out images seem to be working properly now, both in colour and centering. However, when minibrot-finding at 4x zoom I did observe a few cases of the image jumping off-centre. The attachment is the minibrot .kfr for my zoom -- just a quick trip down to 1e100 with about 100K iterations.
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on April 14, 2014, 04:36:45 PM Thanks! The zoom-out images seem to be working properly now, both in colour and centering. However, when minibrot-finding at 4x zoom I did observe a few cases of the image jumping off-centre. The attachment is the minibrot .kfr for my zoom -- just a quick trip down to 1e100 with about 100K iterations. Thanks for the location. I entered the re and im parameters, but set magnification to 1e50, and started zooming in the center.At 5.07E61 the center jumped off. I have now added one more decimal and the problem is solved - for this location at least. New version, 2.3.6 This behavior with jumping location is typical for too low precision, which was how the zooms ended back in the time of the e13 limit, when using only double precision. So I think this problem is solved for good now :) Title: Re: Kalles Fraktaler 2 Post by: ellarien on April 14, 2014, 09:00:16 PM Thank you! I tried it on a different location and that seemed to be OK too.
Title: Re: Kalles Fraktaler 2 Post by: youhn on April 14, 2014, 09:29:06 PM Fast track development ... much appreciated! :D
/me downloading Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on April 17, 2014, 05:24:38 PM And there are new versions available
Kalles Fraktaler 2.4 with Pauldelbrot's glitch detection method, and a couple of bug-fixes. Key Frame Movie Maker with a little improved Histogram color mapping (still experimental though): http://www.youtube.com/watch?v=Ic4E6-jJk9w Title: Re: Kalles Fraktaler 2 Post by: Pauldelbrot on April 18, 2014, 01:03:24 AM And there are new versions available Kalles Fraktaler 2.4 with Pauldelbrot's glitch detection method, :thumbsup1: Title: Re: Kalles Fraktaler 2 Post by: ellarien on April 18, 2014, 02:08:56 PM I hate to be the bearer of bad news, but something doesn't seem right. I did a zoom-out with v2.4 and got glitches in fairly simple cases that I wouldn't have expected (top). Sure enough, the glitches got auto-fixed when using the previous version (bottom).
(Zoom level 3.82e140, but that's not the only case.) Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on April 18, 2014, 03:11:07 PM I hate to be the bearer of bad news, but something doesn't seem right. I did a zoom-out with v2.4 and got glitches in fairly simple cases that I wouldn't have expected (top). Sure enough, the glitches got auto-fixed when using the previous version (bottom). Thanks a lot. (Zoom level 3.82e140, but that's not the only case.) 2.4 replaced the glitch detection completely but since the location from hapf in the other thread I have already considered a combination. So there will be a new version soon :) Again, thanks for testing. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on April 20, 2014, 06:23:18 PM I have made a new version, Kalles Fraktaler 2.4.1
It is now using a combination of Pauldelbrot's glitch detection and my own color-area detection. Any location that is not handled is not bad news, since it will make me able to improve KF :) Title: Re: Kalles Fraktaler 2 Post by: SeryZone on April 21, 2014, 04:53:19 PM I have made a new version, Kalles Fraktaler 2.4.1 It is now using a combination of Pauldelbrot's glitch detection and my own color-area detection. Any location that is not handled is not bad news, since it will make me able to improve KF :) And I can't zoom my e8000 location again :'( Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on April 21, 2014, 06:21:58 PM And I can't zoom my e8000 location again :'( Oh no... I should have tested also your location. But guess what, there's a version 2.4.2 now with this fixed. Thank for your notice Title: Re: Kalles Fraktaler 2 Post by: panzerboy on April 24, 2014, 10:55:21 AM I seem to be getting visible frames using 2.4.2 (64 bit).
http://www.youtube.com/watch?v=_12DlRDID7M I see rectangular "frames" at ... 1:31 1.87e050 1:43 9.8e055 2:16 4.41e071 2:36 4.74e080 2:48 1.24e086 2:56 6.36e088 2:58 2.54e089 3:00 2.03e090 3:16 2.13e096 3:22 5.46e098 3:38 5.73e104 3:46 2.93e107 4:02 7.69e112 4:05 6.15e113 4:07 2.46e114 4:24 6.45e119 I've attached the first visible frame as a picture below. Its created from the saved JPGs, shrinking 00285_1.49e051 and overlaying it on 00286_7.48e050 to show the discontinuity. Examining the zoom sequence and mousing over the top left corner (0,0) of 285_1.49e51 gave a slightly different i:3759 s:66 compared position (320,180) of 286_748e50 i:3758 s:66. Perhaps there is a difference in the iteration and smoothing values between frames? I could upload the 2 kfb files to my mediafire account if you'd like to inspect (uploading all 12.4Gb would take forever and be over 1/2 my Internet cap). I've also attached the kfr and kmm files needed to re-create this zoom, should you wish. (nice palette in the .kfr, created solely with the Set Colors dialog using the L wave on an 8x8 colour combo) Title: Re: Kalles Fraktaler 2 Post by: SeryZone on April 24, 2014, 02:10:57 PM Yes, I have some problem!
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on April 24, 2014, 05:46:33 PM Thanks panzerboy and SeryZone.
Yes, i have seen that myself and mentioned it before. Even though the high bailout makes beautiful smooth coloring and actually makes it easier to identify glitches automatically, it can produce slightly different colors on "empty" areas for different reference points. Very annoying... I am wondering if any of the others programming perturbation (Botond, pauldelbrot, hapf) are experiencing the same? Did you changed the main reference on that frame? To solve this - never use the set main reference function when solving glitches manually. If not, hmm... Then I currently do not know. Would be sad if I had to recommend you to only use bailout=2 when making movies... Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on April 24, 2014, 08:05:59 PM I think I found a solution for this, or, a workaround.
The reference parameters needs to be stored and not calculated between frames, since the empty areas are so sensitive with high bailout. I just want to test it before a upload a new version. Sorry for the time wasted on glitchy renders. KF is still experimental :) I think your colors were beautiful! Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on April 24, 2014, 10:29:46 PM And no, my thought about this did not solve this problem :(
The only way currently to make flawless movies with high bailout smooth coloring is to use the "Reuse reference" function to create all frames from one reference, and then correct all glitches manually with the "Examine Zoom Sequence" function... Title: Re: Kalles Fraktaler 2 Post by: Pauldelbrot on April 25, 2014, 01:53:26 AM Thanks panzerboy and SeryZone. Yes, i have seen that myself and mentioned it before. Even though the high bailout makes beautiful smooth coloring and actually makes it easier to identify glitches automatically, it can produce slightly different colors on "empty" areas for different reference points. Very annoying... I am wondering if any of the others programming perturbation (Botond, pauldelbrot, hapf) are experiencing the same? Nanoscope does not have that problem. I even examined a region at the boundary between where two different reference points were used looking for even the subtlest seams, with a proverbial magnifying glass, and could not see the boundary. Nanoscope does two things specially, though, that might matter here: 1. It computes reference points with an exceedingly high bailout of one googol (10100). 2. The bailouts I've been doing test renders and other work with tend to be either 105 or 107. I think I read somewhere here than you were using lower bailouts, around 102-103. Those cause curves of constant smooth iterations to have big enough deviations from exact equipotential curves as to potentially induce distortions that don't noticeably mar the smoothing but do differ visibly when different reference points are used. Also, if KF is checking the magnitude of delta rather than the magnitude of (ref pt plus delta) for bailout, the discrepancy might impact things. I found a way to optimize the delta calculations that calculates (ref pt plus delta) incidentally along the way, used for both enhanced glitch checking and bailout tests. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on April 25, 2014, 11:34:04 AM 2. The bailouts I've been doing test renders and other work with tend to be either 105 or 107. I think I read somewhere here than you were using lower bailouts, around 102-103. Those cause curves of constant smooth iterations to have big enough deviations from exact equipotential curves as to potentially induce distortions that don't noticeably mar the smoothing but do differ visibly when different reference points are used. Thanks Paul, this is exactly the information I need :)Maybe this explains why mandel machine stops at 2^1900 already since I use double to e600 which is ok with my 102 bailout. I will try a higher bailout which probably require this limit to be decreased. Title: Re: Kalles Fraktaler 2 Post by: Botond Kósa on April 25, 2014, 05:24:24 PM Maybe this explains why mandel machine stops at 2^1900 already since I use double to e600 which is ok with my 102 bailout. I will try a higher bailout which probably require this limit to be decreased. The bailout value used in Mandel Machine is only 32, so the bailout criteria is: re2+im2>1024. (I am not sure if the 105, 107 and 10100 values mentioned by Pauldebrot are bailout or bailout squared.) In order to speed up the calculation, the bailout criteria is evaluated in every 4th iteration only, so the absolute value of the orbit can be in the range of 25 to over 280. I experienced no noticeable glitches so far with this method. BTW, Kalle's guess was correct, the zoom limit of 1900 in MM is also caused by this. Evaluating bailout in every iteration allows me to zoom up to 2000, but with the current method the orbit can grow beyond 10308 above 1900, causing an overflow to infinity and corrupting the image. Title: Re: Kalles Fraktaler 2 Post by: Pauldelbrot on April 25, 2014, 06:10:18 PM The bailout value used in Mandel Machine is only 32, so the bailout criteria is: re2+im2>1024. (I am not sure if the 105, 107 and 10100 values mentioned by Pauldebrot are bailout or bailout squared.) In order to speed up the calculation, the bailout criteria is evaluated in every 4th iteration only, so the absolute value of the orbit can be in the range of 25 to over 280. I experienced no noticeable glitches so far with this method. BTW, Kalle's guess was correct, the zoom limit of 1900 in MM is also caused by this. Evaluating bailout in every iteration allows me to zoom up to 2000, but with the current method the orbit can grow beyond 10308 above 1900, causing an overflow to infinity and corrupting the image. The numbers I cited are for bailout, not bailout squared. Nanoscope does not have the zoom limit, either, as it uses some trickery with rescaling dx and dy when below 10-308. I've generated a test image at 10768 successfully -- one with solid-blob glitches, as a matter of fact, which Nanoscope had no trouble detecting and fixing way down there. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on April 25, 2014, 10:49:38 PM Nanoscope does not have the zoom limit, either, as it uses some trickery with rescaling dx and dy when below 10-308. I've generated a test image at 10768 successfully That's very interesting, if you are able to do so without losing too much speed by e.g. separating mantissa from exponent as I do in KF, beyond e4900 and long double, which make it 10 times slower.Because I think it is possible to use only the range e-308 - e308, i.e. e616 with doubles? Title: Re: Kalles Fraktaler 2 Post by: Pauldelbrot on April 26, 2014, 03:46:10 AM That's very interesting, if you are able to do so without losing too much speed by e.g. separating mantissa from exponent as I do in KF, beyond e4900 and long double, which make it 10 times slower. Because I think it is possible to use only the range e-308 - e308, i.e. e616 with doubles? It loses very little speed -- it may actually gain speed, because on most iterations that deep the delta squared term can be ignored as it's another 10-308 smaller still; except when either the reference orbit is very close to zero or the delta term computed without delta squared is. The reason is that Nanoscope doesn't work with the exponent on most iterations -- there's a rescaled delta, stored in doubles, and an exponent value, but the new rescaled delta can be computed from just the old rescaled delta and the reference point on most iterations. When delta squared is needed, or after about 500 iterations, one iteration is done using precision-16 java.math.BigDecimals -- that one iteration is slow, even with the precision limited to a double's, but has unlimited exponent width. The "after about 500 iterations" is because on most iterations delta roughly doubles and at most grows by a factor of four (given the reference point hasn't escaped!), and 500 quadruplings will take a rescaled delta close to 1 up to near 21000 ~ 10300, putting it in spitting distance of exponent overflow. It seems to work in practice. At some point I'll post actual code. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on April 27, 2014, 12:20:06 PM New version uploaded, 2.4.3
I haven't had time to test all locations but I have made some great findings First, my optimization on loop expansions and not checking bailout on every iteration did improve render with double speed but introduced the bug on difference reference gave different result. I have removed these optimizations, so it is 2 times slower now (still twice as fast as 2.2 though) I could of course have fixed the bug and kept the optimization, but I removed it, because... When checking bailout on every iteration, I found that pauldelbrot's glitch detector is bullet proof! Even with series approximation!! The intervals where the glitch is detectable can be very short and then disappear again, so it is important to check every iteration. Really good news is that SA doesn't prevent glitches from being detected! Kalles Fraktaler now handles flake and the locations from ellarien and hapf without problem, even when SA skips most iterations. Manual glitch solving is now history, just a vague memory from the past! Even one-pixels sized glitches are discovered and solved automatically. One click and all frames on a zoom sequence are rendered flawless without manual intervention! Pauldelbrot, I am glad that I once again need to say to your that, I was wrong you are right! ;) Title: Re: Kalles Fraktaler 2 Post by: Pauldelbrot on April 27, 2014, 01:08:19 PM New version uploaded, 2.4.3 I haven't had time to test all locations but I have made some great findings First, my optimization on loop expansions and not checking bailout on every iteration did improve render with double speed but introduced the bug on difference reference gave different result. I have removed these optimizations, so it is 2 times slower now (still twice as fast as 2.2 though) I could of course have fixed the bug and kept the optimization, but I removed it, because... When checking bailout on every iteration, I found that pauldelbrot's glitch detector is bullet proof! Even with series approximation!! The intervals where the glitch is detectable can be very short and then disappear again, so it is important to check every iteration. Really good news is that SA doesn't prevent glitches from being detected! Kalles Fraktaler now handles flake and the locations from ellarien and hapf without problem, even when SA skips most iterations. Manual glitch solving is now history, just a vague memory from the past! Even one-pixels sized glitches are discovered and solved automatically. One click and all frames on a zoom sequence are rendered flawless without manual intervention! Pauldelbrot, I am glad that I once again need to say to your that, I was wrong you are right! ;) Thanks. But we'll just see, in the fullness of time. It's still early yet. I wouldn't bet 100% on my glitch detector unless years go by without anyone finding a case where a noisy glitch sneaks past it. :) Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on April 27, 2014, 03:45:36 PM I'm currently trying to make a decision what to do. I have a complete render of a new video which is full of glitches, some of which are not blobs. Should I re-render with the latest version, or solve the glitches manually?
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on April 27, 2014, 03:57:35 PM Thanks. But we'll just see, in the fullness of time. It's still early yet. I wouldn't bet 100% on my glitch detector unless years go by without anyone finding a case where a noisy glitch sneaks past it. :) It won't be the first time I have to take such statements back, but I keep on being optimistic. I'm currently trying to make a decision what to do. I have a complete render of a new video which is full of glitches, some of which are not blobs. Should I re-render with the latest version, or solve the glitches manually? I am sorry, and I am currently rerendering a zoom myself. And it takes if course longer time with new version and auto-glitch for every frame. I guess it depends on how long your render took...? I am only rerendering the shallower half of my sequence though. I deleted half of the frames and resumed... Carefully checked that the joint weren't visible, in kfmm Addition: It might be an idea that always use the "Reuse reference" with only one full precision calculation and no glitch solving on the deepest parts of hard zoom sequences. And then, when glitches start to get visible, stop the render, lower the Max iteration value and turn auto-glitch correction on, and resume again. Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on April 27, 2014, 04:14:12 PM I just noticed that the tool to check for glitches now has a button to auto-correct glitches.
Edit: it doesn't detect the glitches. I ask too many questions. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on April 27, 2014, 05:21:41 PM I just noticed that the tool to check for glitches now has a button to auto-correct glitches. Hm... Yeah, with pauldelbrot's glitch detection I removed the old detection to avoid unnecessary processing...Edit: it doesn't detect the glitches. I ask too many questions. Title: Re: Kalles Fraktaler 2 Post by: ellarien on April 28, 2014, 06:21:10 PM 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. :dink: Title: Re: Kalles Fraktaler 2 Post by: kjknohw on April 28, 2014, 06:33:03 PM Amazing program :o. 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).
Make Glitch correction earlier. Don't wait for the fine-resolution image to be calculated/guessed before those ugly splotches get corrected. If the coarse passes detect significant glitches, deal with them now, not later. Even when the coarse check doesn't pick up anything, you can still run a final glitch detection during the high resolution images at the end just to be sure (although that shouldn't be necessary in most cases, the algorithm is spotless so would still be very good on a coarser grid). Add a 4X4 coarse render pass: it gives a preview at up to a 16 fold speedup (apart from calculating the initial references), instead of just 4 fold. Colors: Allow us to specify the frequency of the "waves" when we generate them. This allows more control over getting the coloring to work. Also, we should be able to specify sqrt and log to be from the lowest iteration in the image, this makes for better coloring in most cases. Other optimizations: Even with the expensive "reference" calculations, the image itself usually takes up most of the time. Periodicity checking, solid guessing (you already seem to have this), etc are all still useful for the image calculation. Fractal Extreme can render the mandelbrot set with a million iterations in under one second at the default size and zoom level, due to these optimizations. Xaos is also really fast at low zooms. Movement: Can we be able to pan the view or zoom in/out by a tiny amount to get that perfect "shot" (without guessing what numbers to type in) as well as keep the current way of exploring? Max iteration auto (this could be hard): This is the best I've seen but it still doesn't work in many cases. Improvement is needed. However, disabling it and setting max iterations now seems to work (not to confuse low max iterations black regions with non-black glitches). It is most likely to fail deep in the cusps of baby mandelbrot sets. One strategy might be to look for how "bulby" the regions are. If you implement these simple improvements the program will be very solid as well as technically astounding. Title: Re: Kalles Fraktaler 2 Post by: SeryZone on April 28, 2014, 10:03:52 PM Amazing program :o. 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). Make Glitch correction earlier. Don't wait for the fine-resolution image to be calculated/guessed before those ugly splotches get corrected. If the coarse passes detect significant glitches, deal with them now, not later. Even when the coarse check doesn't pick up anything, you can still run a final glitch detection during the high resolution images at the end just to be sure (although that shouldn't be necessary in most cases, the algorithm is spotless so would still be very good on a coarser grid). Add a 4X4 coarse render pass: it gives a preview at up to a 16 fold speedup (apart from calculating the initial references), instead of just 4 fold. Colors: Allow us to specify the frequency of the "waves" when we generate them. This allows more control over getting the coloring to work. Also, we should be able to specify sqrt and log to be from the lowest iteration in the image, this makes for better coloring in most cases. Other optimizations: Even with the expensive "reference" calculations, the image itself usually takes up most of the time. Periodicity checking, solid guessing (you already seem to have this), etc are all still useful for the image calculation. Fractal Extreme can render the mandelbrot set with a million iterations in under one second at the default size and zoom level, due to these optimizations. Xaos is also really fast at low zooms. Movement: Can we be able to pan the view or zoom in/out by a tiny amount to get that perfect "shot" (without guessing what numbers to type in) as well as keep the current way of exploring? Max iteration auto (this could be hard): This is the best I've seen but it still doesn't work in many cases. Improvement is needed. However, disabling it and setting max iterations now seems to work (not to confuse low max iterations black regions with non-black glitches). It is most likely to fail deep in the cusps of baby mandelbrot sets. One strategy might be to look for how "bulby" the regions are. If you implement these simple improvements the program will be very solid as well as technically astounding. Hey, for calculate millions iterations, we need to rewrite loops and complex calculations on assembler language. I leard SIMD-instructions as hard, but my strides equal zero. Okay, what can do lonely 17-year guy? I do not have goal in life, I must to find myself! I must strive for perfection! But I still strange! And Fractal eXtreme is not calculation champion! People on fasm forum can write programms, faster than FX in more times! And, mercator maps make rendering faster. Fractal eXtreme, 8-cores used: 2 minutes Me little program with SIMD, mercator map, 1-core: 1:30 minutes, and it is without guessing!!! Imagine, what's fractal monster we can write if we combine: 1) Mercator map 2) Full Guessing (Minibrots and dwell bands) 3) Multi-core rendering 4) High-precision math 5) Perturbation Theory 6) SIMD instructions (for my AMD only AVX, but for Intels - AVX2). 7) All write on FASM Imagine!!! People have many differences unlike animals. One of them - imagination. I dream and see, that I write and use this 'monster'. 7 optimizations... Title: Re: Kalles Fraktaler 2 Post by: youhn on April 28, 2014, 10:21:05 PM Colors: Allow us to specify the frequency of the "waves" when we generate them. This allows more control over getting the coloring to work. Also, we should be able to specify sqrt and log to be from the lowest iteration in the image, this makes for better coloring in most cases. Yeah, please this one! Combine the current stuff with the features of MDZ palette editor: (http://jwm-art.net/mdz/screenshots/mdz-0.0.9.png) 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). Title: Re: Kalles Fraktaler 2 Post by: Pauldelbrot on April 28, 2014, 10:21:49 PM Hey, for calculate millions iterations, we need to rewrite loops and complex calculations on assembler language. I leard SIMD-instructions as hard, but my strides equal zero. Okay, what can do lonely 17-year guy? I do not have goal in life, I must to find myself! I must strive for perfection! But I still strange! And Fractal eXtreme is not calculation champion! People on fasm forum can write programms, faster than FX in more times! And, mercator maps make rendering faster. Fractal eXtreme, 8-cores used: 2 minutes Me little program with SIMD, mercator map, 1-core: 1:30 minutes, and it is without guessing!!! Imagine, what's fractal monster we can write if we combine: 1) Mercator map 2) Full Guessing (Minibrots and dwell bands) 3) Multi-core rendering 4) High-precision math 5) Perturbation Theory 6) SIMD instructions (for my AMD only AVX, but for Intels - AVX2). 7) All write on FASM Imagine!!! People have many differences unlike animals. One of them - imagination. I dream and see, that I write and use this 'monster'. 7 optimizations... 1) Nanoscope has this 2) Not sure it's worthwhile, especially with smoothed iterations, likes to chop off the ends of minibrot valleys 3) Nanoscope has this 4) Nanoscope has this 5) Nanoscope has this 6) Nanoscope has this if the JIT in your JVM does 7) Nanoscope has this if the JIT in your JVM does What's Kalle's Fraktaler doing in these areas? As far as I'm aware it uses keyframe interpolation, so not 1, and obviously yes to 4 and 5 ... Title: Re: Kalles Fraktaler 2 Post by: youhn on April 28, 2014, 10:50:12 PM Is the nanoscope GUI ready for us to be used ... ? ::)
Title: Re: Kalles Fraktaler 2 Post by: Pauldelbrot on April 28, 2014, 11:58:34 PM Is the nanoscope GUI ready for us to be used ... ? ::) No, not yet. Work on it is momentarily stalled due to external factors beyond my control. Title: Re: Kalles Fraktaler 2 Post by: kjknohw on April 29, 2014, 12:31:33 AM 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)?
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? Title: Re: Kalles Fraktaler 2 Post by: Pauldelbrot on April 29, 2014, 03:19:18 AM 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. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on April 29, 2014, 08:50:20 AM Amazing program :o. 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: You can offset the palette. And I will make a better wave function :)<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). 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. 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.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. :dink: Title: Re: Kalles Fraktaler 2 Post by: kjknohw on April 29, 2014, 02:45:00 PM 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. Title: Re: Kalles Fraktaler 2 Post by: youhn on April 29, 2014, 02:55:48 PM 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. Title: Re: Kalles Fraktaler 2 Post by: 3dickulus on April 29, 2014, 02:59:05 PM 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++ :) Title: Cython for the win (or something like that) Post by: kjknohw on April 29, 2014, 04:28:32 PM 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. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on April 29, 2014, 04:43:42 PM 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%. Title: Re: Kalles Fraktaler 2 Post by: youhn on April 29, 2014, 05:12:46 PM Merge colors starts on the selected item in the list of colors, ... Ah, just select an item... Damn, I totally missed this feature! Sorry :headbatting: Title: Re: Cython for the win (or something like that) Post by: 3dickulus on April 29, 2014, 06:17:51 PM 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!!! :beer: Title: Re: Cython for the win (or something like that) Post by: kjknohw on April 29, 2014, 06:44:21 PM 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 (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. Title: Re: Kalles Fraktaler 2 Post by: Pauldelbrot on April 29, 2014, 07:50:13 PM 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).
Title: Re: Kalles Fraktaler 2 Post by: SeryZone on May 01, 2014, 06:49:59 AM 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)??? :beer: I can improve KF speed and, maybe, can help you with this idea. Title: Re: Kalles Fraktaler 2 Post by: Pauldelbrot on May 01, 2014, 12:28:28 PM Okay ^-^ Can you teach me, how to correctly use SIMD constructions (without AVX2)??? :beer: 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. :) Title: Re: Kalles Fraktaler 2 Post by: SeryZone on May 05, 2014, 03:27:11 PM 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 :dink: :D :D Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on May 06, 2014, 05:23:59 PM 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. Title: Re: Kalles Fraktaler 2 Post by: knighty on May 07, 2014, 07:58:23 PM 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. me 2. (using 32-bit version).Is it possible to have DEM and triangle inequality coloring (and maybe other ones) in the next versions? :D Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on May 08, 2014, 12:03:26 AM I know why there may be rare unsolved glitches randomly - it's because of multithreading. I will fix it.
The coloring - I don't know what it is ;) Dragging content - I have too little time at the moment, wave coloring is more fun, I will show you soon :) Title: Re: Kalles Fraktaler 2 Post by: knighty on May 08, 2014, 01:46:26 PM BTW, is it possible to lower the priority of the threads that do the computations? While rendering (especially in high resolution), it is almost impossible to do anything else.
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on May 08, 2014, 05:40:11 PM BTW, is it possible to lower the priority of the threads that do the computations? While rendering (especially in high resolution), it is almost impossible to do anything else. It could be done in the program, but you can also change the priority of the process in task-manager...Title: Re: Kalles Fraktaler 2 Post by: Sockratease on May 08, 2014, 06:21:50 PM It could be done in the program, but you can also change the priority of the process in task-manager... BTW, is it possible to lower the priority of the threads that do the computations? While rendering (especially in high resolution), it is almost impossible to do anything else. I actually get better results changing the program's "affinity" rather than it's "priority" This way if you have, for example, 4 processor cores you can limit it to just 2 of them, or even one. Then change other programs to the other cores, or let them use all. But this way no one program monopolizes the processors and everything can run at a steady pace. I used this when rendering an UltraFractal animation (gave UF 2 cores) and a 3D Animation (gave Carrara 1 core), while exploring with Kalles Fractaller (which also had 1 core). I liked this better because no program ever used much less than it's assigned percent of the processor power while using priority any one of the programs could drop below 5 or 10% Using affinity the usage stayed stable and each program used the most it could within those limits (in my example UF used about 50% and each other used about 25%). Hope that helps O0 Title: Re: Kalles Fraktaler 2 Post by: knighty on May 08, 2014, 07:12:09 PM Thank you Kalles and Sockratease.
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on May 10, 2014, 06:57:17 PM I have uploaded a new version of Kalles Fraktaler, now version 2.5
News: * Editable palette waves. Sine waves are applied on the RGB values to create the key colors in the palette. The period values specifies the number of periods in the palette - the higher value the faster wave. * Infinite wave colors. Sine waves are applied on the HSB values to create infinite colors. The period values specifies the period lengths - the higher value the slower wave. * 3rd degree Mandelbrot. Is set in the "Iterations" dialog - since it affects rendering. Thanks knighty for encouraging and for the Series Approximation formulas. Also Key Frame Movie Maker is updated, now version 1.21, to support Infinite wave coloring. The source code is also synced and available from the main page, http://www.chillheimer.de/kallesfraktaler/ Title: Re: Kalles Fraktaler 2 Post by: ellarien on May 10, 2014, 09:30:22 PM Brilliant!
(https://farm3.staticflickr.com/2902/14174165733_cabf4f90ed.jpg) (https://flic.kr/p/nAwiDP)may10_01 (https://flic.kr/p/nAwiDP) by ellarien (https://www.flickr.com/people/77963359@N00/), on Flickr Title: Re: Kalles Fraktaler 2 Post by: knighty on May 10, 2014, 11:10:23 PM Awesome!
It is much faster than previous versions. What kind of magic have you done? Title: Re: Kalles Fraktaler 2 Post by: youhn on May 10, 2014, 11:28:12 PM Thank you very much for the update!
Already downloaded, now a quick test-render for the new wave function on color palettes. Testing on the 3-power Mandelbrot. I'll post the result. Title: Re: Kalles Fraktaler 2 Post by: Chillheimer on May 10, 2014, 11:34:00 PM wow, what an update! :o :D ;D
the wave colouring works really nice! and kind of a whole new set to explore.. awesome work!, kalle! edit: haha, I'm sitting here, excited as a little kid! This is such an improvement! Title: Re: Kalles Fraktaler 2 Post by: youhn on May 11, 2014, 12:10:40 AM (http://i.imgur.com/KFcdndC.jpg)
Re: -0.245949643461449994595087018222596574641401137066912001643855084143341173410374314595243969632582478930376191805229455307 Im: -1.316624182789306613227916731274807966104041519777466712208339027828372614942507766754269516555946164234277405762242688322 Zoom: 3.30000000000E95 Iterations: 10507 Further down: (http://i.imgur.com/egEk9fQ.jpg) Re: -0.2459496434614499945950870182225965746414011370669120016438550841433411734103743145952439696325827203480662713944457108564888469971619549786307771176863048421596857841355313699076156631168822411261278380827292 Im: -1.3166241827893066132279167312748079661040415197774667122083390278283726149425077667542695165559437624615507051004371874914829209834650201588189657276975746271992188648262465265793695170833209605260110350819817 Zoom: 1.90558125475E184 Iterations: 35068 Palette was created with the Palette waves. Stripes of black added manually with the Merge colors function. (http://i.imgur.com/4rpkYMw.png) Is it possible to combine the waves with the merge function? Not merging a single color, but merging a wave over every 8th step for example. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on May 11, 2014, 10:03:47 AM Thanks everyone, and thanks for the beautiful images!
Is it possible to combine the waves with the merge function? Not merging a single color, but merging a wave over every 8th step for example. It would be possible I think. But merging too many waves do not give good result, in my tests the whole image turns toward grey as more waves are added...Awesome! The glitch finder should be faster but that's all :)It is much faster than previous versions. What kind of magic have you done? I forgot to mention, that Pauldelbrot's glitch detecting method works also on 3rd degree Mandelbrot perturbation. Super!! Title: Re: Kalles Fraktaler 2 Post by: hapf on May 11, 2014, 11:00:28 AM Thanks everyone, and thanks for the beautiful images!It would be possible I think. But merging too many waves do not give good result, in my tests the whole image turns toward grey as more waves are added...The glitch finder should be faster but that's all :) It should work generally with perturbation since measuring out of sync will always correlate with amount of rounding errors.I forgot to mention, that Pauldelbrot's glitch detecting method works also on 3rd degree Mandelbrot perturbation. Super!! Title: Re: Kalles Fraktaler 2 Post by: Pauldelbrot on May 11, 2014, 03:38:50 PM It should work with any Mandelbrot-type fractal with a critical point at zero. In particular zn + c.
Critical points away* from zero might not be capable of causing this type of glitch, but I don't know if other kinds of glitches or difficulties might arise applying perturbation to such systems. * Well, far enough away. One with a magnitude smaller than 10-16 could still cause this type. Title: Re: Kalles Fraktaler 2 Post by: ratcat65 on May 13, 2014, 01:32:39 AM Hello to everyone on the forum.
I have been using Kalles Fraktaler for a couple of weeks and getting accustomed to its various behaviours and occasional bugs. I loaded a kmm file which was made in the previous version of the movie assembler into the latest version and the resulting movie has colour cycling at a much faster speed. I can't get it to cycle slowly the way the previous version did. A value of 1 or -1 produces much faster cycling than before. Unfortunately I lost the older version of the movie assembler when windows 7 did a collapse today and I had to do a fresh install. The previous version isn't hosted on the site anymore and I need to re-do a movie in the slow cycling mode which were lost in an accidental overwrite. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on May 13, 2014, 07:25:56 AM Hello ratcat65
I've seen your movies, thanks a lot for these! You can specify float numbers for color cycling, so if 1 is too fast you can enter 0.1 instead :) Title: Re: Kalles Fraktaler 2 Post by: youhn on May 13, 2014, 09:41:20 PM I know it's not totally appropriate to post images in a software announcement topic, but I just very much like the new color waves! :rotating: :thanks2:
(http://fc00.deviantart.net/fs71/i/2014/133/1/6/transparent_waves_of_colors_by_jeroensnake-d7i843f.jpg) Source: http://jeroensnake.deviantart.com/art/Transparent-waves-of-colors-453874875 Notice how the colors line up to create some sort of fake transparency effect. Title: Re: Kalles Fraktaler 2 Post by: Pauldelbrot on May 13, 2014, 10:06:20 PM I know it's not totally appropriate to post images in a software announcement topic, but I just very much like the new color waves! :rotating: :thanks2: Seems perfectly appropriate to me if it's to showcase what the relevant software can do. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on May 13, 2014, 11:57:59 PM It's totally appropriate!
It's a fantastic image! Thanks a lot!! :thanks1: Title: Re: Kalles Fraktaler 2 Post by: cKleinhuis on May 14, 2014, 12:37:06 AM indeed, it seems that i need to open up a kalles fraktales section as well, with dedicated gallery section
@kalle what about hosting kalles.exe on ff ? to provide a consistent download and versioning location ? opening up a kalles fractaler section is not accounted by that, but might be helpful to keep track of versions that people use! Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on May 14, 2014, 01:05:33 PM indeed, it seems that i need to open up a kalles fraktales section as well, with dedicated gallery section I don't mind hosting the exe on ff too, I can do the updates both on www.chillheimer.de and ff.@kalle what about hosting kalles.exe on ff ? to provide a consistent download and versioning location ? opening up a kalles fractaler section is not accounted by that, but might be helpful to keep track of versions that people use! I think the updates now will decrease in frequency, but it's not the first time I think so though, and I have one more really really cool update on it's way. ;) I hope I have time for this update this weekend. Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on May 14, 2014, 02:53:23 PM Variable power mandelbrot sets with perturbation?
Title: Re: Kalles Fraktaler 2 Post by: blob on May 14, 2014, 03:54:04 PM Antialiasing! ;D
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on May 14, 2014, 08:10:51 PM Yes, variable powers!
Testing this takes too long time so I have put the update available, now version 2.5.1. Should be considered as beta, since it is not fully tested yet, but you are very welcome to help me! :) There are 4 breakpoints for the datatypes used, and I think these has to be adjusted for higher powers. To test this it is necessary to zoom to that deepths to see where the datatypes breaks. Zooming to e4900 with high powers takes a while I guess, because it takes a lot of time even to e300... But it is also possible to force long double or floatexp to be used though.
You can now enter any integer up to 70 as power, however I recommend max 7 since the glitch detection might not work on higher powers. I had to increase the threshold to detect glitches at all at power 7, and I haven't tested fully above that. Again, it takes long time to test. Above 70, even double is not enough to render the un-zoomed m-set, at least not with my current implementation. I also implemented the merge color optionally as sine wave, which youhn suggested :) Title: Re: Kalles Fraktaler 2 Post by: laser blaster on May 15, 2014, 03:07:33 AM Awesome! KF just keeps getting better and better. ;D
Title: Re: Kalles Fraktaler 2 Post by: ellarien on May 15, 2014, 09:54:11 PM I've been playing with 2.5.0 for few days now, and 2.5.1 for a day or so. I think zooming to > e300 with the higher-degree sets is not for the faint-hearted or under-cooled, even with perturbation; the higher the power, the harder the computer has to work for even quite small numbers of iterations, and things get dense quite quickly.
This (power 6) took around half an hour to render at 3K width, and the iteration depth is only 20K: (https://farm3.staticflickr.com/2911/14170409876_63b5f5b10c.jpg) (https://flic.kr/p/nAc4aE)may15_03 (https://flic.kr/p/nAc4aE) by ellarien (https://www.flickr.com/people/77963359@N00/), on Flickr Code: Re: 0.19009200738664003775048587995178562421318906985724823420747507642375015168586422 I guess it would have been completely out of amateur reach without perturbation! The upside is that in this relatively unexplored territory I feel less embarrassed about sharing my modest attempts at movies, like this power-6 zoom down to 1e70: https://www.youtube.com/watch?feature=player_detailpage&v=uff2T_0U1IU The added capabilities are great, but I have found a few niggles. -- Sometimes in a zoom-out sequence, if a glitch or minibrot falls across the edge of a frame, the parts outside the frame won't be properly solved on subsequent zoomed-out frames. Usually this can be fixed by going to that frame in the zoom sequence examination tool and doing a 'refresh', then adding references by hand. -- Speaking of which, I love the ability to jump to a specific frame when examining the sequence, but it woud be nice if the number to enter matched the number on the kfb file instead of being the difference between that and the highest frame number. -- It seems to cause problems (program hangs or goes into an endless loop) if I try to change the iteration limit while the calculation is running. The obvious work-around is not to do that. :dink: Changing the window or image size mid-calculation may also do bad things. -- The minibrot finder doesn't seem to very useful with the higher-degree sets, but I'm not sure how hard it would be to tweak it. (Having said that, I just turned it loose on a filament of the power-3 set, and while it won't settle on one minibrot it quite happily took me down to e400 in a few minutes, at which point it seems to be stuck.) --Update: after a couple of hangs and restarts around e400 I got it chugging away again, and it finally zoomed in on a minibrot at 5e617. (I don't suppose that's a record? I'm happy to share the location, but it would make a really boring movie!) So apparently it does work if you can get deep enough to isolate a minibrot in the first place ... End update -- Would it be possible to automatically switch off the new checking for the last few frames of a zoom-out? It gets slow when half the frame is occupied by the main 'brot. Finally, thanks again for the new toys! Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on May 16, 2014, 11:17:34 AM Thanks ellarien. Yeah I already found your movies! They use a little higher resolution, but they are indeed lovely!
And with them I found an error on the transition of references, around e10 :) Glitches falling on the edges should be solved automatically for at least 2nd and 3rd power, but I found that glitches may sneak through for higher powers. I guess the threshold value needs to be adjusted further. File name number in Examine Zoom sequence can be added, and I guess I never tried to change maximum iteration or background image size during rendering. Should be easily solved by stopping the render when these parameters are changed. You can also stop the render with the escape key before you do such changes. The find minibrot expects two-fold symmetry, so it should work on even powers. But it definitely does not work for odd powers. That would be very tricky to achieve I think :) If you start a zoom sequence at a deep minibrot with some million iterations, it will be very very slow when it is rendering the ending frames with the big main mandebrot occupies most of the view. You can stop the render, decrease the iterations, and then start the render again, not with resume but with store zoom sequence, because it checks the files already created and starts from the last number. Using escape key to stop rendering while changing parameters. I should make it automatic though. Thanks for your list. There will be a new version soon ;) Title: Re: Kalles Fraktaler 2 Post by: ellarien on May 16, 2014, 12:13:55 PM Thanks ellarien. Yeah I already found your movies! They use a little higher resolution, but they are indeed lovely! And with them I found an error on the transition of references, around e10 :) Thanks! I'm afraid bandwidth limitations make it hard to go much higher in resolution -- it takes me about an hour to upload 100Mb. I have another movie ready to upload where I avoided the e10 issue by recalculating the problem frames with no approximation, but I'm glad it was helpful. The find minibrot expects two-fold symmetry, so it should work on even powers. But it definitely does not work for odd powers. That would be very tricky to achieve I think :) I've done some more experimenting, now that I'm getting more of a feel for the higher powers. It works OK on 3, 4, and 5 if I find a good place to start -- somewhere with roughly circular patterns. 6 and 7 are trickier just because the minibrots are so close together, so it's hard to get a good zoom going, but I have found locations where it will auto-zoom for at least a few steps. Thanks for your list. There will be a new version soon ;) Happy to help, and I look forward to the new version. One more quirk that I noticed yesterday: if I 'save as jpeg' with a different resolution from the current one, the frame renders with the new resolution before opening the save file dialog. That's fine, but then after saving it starts to render again -- at least the glitch-fixing passes, maybe not the whole thing -- which seems unnecessary and can be a bit of a pain when the image takes a long time to calculate. Again, it's easy enough to render at the required resolution before saving, so not a big problem. Thanks again! Title: Re: Kalles Fraktaler 2 Post by: kjknohw on May 16, 2014, 04:31:25 PM Nice update!
You can't save the infinite wave palettes? Guessing starts at 2x2, not 4x4. This is important near a the black when using a high iteration count. 4x4 is more prone to artifacts, so maybe a toggle. The find minibrots is broken even on the z^2 mandelbrot method for me. Has anyone had success with this? Although it is a minor feature. Pauldelbrot uses a method that exploits "regularity near deep mandelbrots". This will be a fundamental speedup on-top of perturbation. You may even be able to apply it to when calculating the reference pixels. Is anyone working on combining these methods? Time for some amazing images! Title: Re: Kalles Fraktaler 2 Post by: ellarien on May 16, 2014, 05:36:06 PM The find minibrots is broken even on the z^2 mandelbrot method for me. Has anyone had success with this? Although it is a minor feature. It does work for me now, at least on powers 2-6. (64-bit version 2.5.1.) It isn't foolproof, and it works best if you can get it roughly centered first on somewhere a minibrot has to be -- then it takes some of the drudgery out of zooming in, which is nice for zoom movies. Also, when it does work it stops a few zooms short of the minibrot actually becoming visible -- and it can occasionally be fooled by dense julias of the sort you get by passing very close to a minibrot. Title: Re: Kalles Fraktaler 2 Post by: SeryZone on May 16, 2014, 05:40:56 PM Kalle, approximation at 3 and more powers doesn't work well.
For example: max: 250,000 min: 34,223 Approx is not 34,223 about less! it is 256 iterations! (http://s1.hostingkartinok.com/uploads/images/2014/05/63e4d9dbd32889dfa0f604618dfa983b.png) Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on May 16, 2014, 10:25:57 PM I made a small update, now 2.5.2
I have made more adjustments on the glitch detection threshold, increasing it for each power from 0.000001 (squared value) up to 0.5 for powers 11 and above. But it still doesn't work so well for powers higher than that. And I haven't yet tested all views either (;D) I've also solved the issue with changing from reference <0,0> to the center of the view, which is done deeper than e10 and which caused a difference of one iteration. It's hardly noticeable in images but is visible on a movie. SeryZone, can you give me location parameters? The series approximation is very dependent of the "flatness" of the image. An image with mostly thin filaments can be approximated for example 2000 with minimum iteration 2005. But the rate you showed is usually for deep minibrots... Title: Re: Kalles Fraktaler 2 Post by: SeryZone on May 17, 2014, 10:41:50 AM SeryZone, can you give me location parameters? The series approximation is very dependent of the "flatness" of the image. An image with mostly thin filaments can be approximated for example 2000 with minimum iteration 2005. But the rate you showed is usually for deep minibrots... For THIRD power. re: -0.039518784717566485688811172499194617461984478762 im: -0.769259846138562111329035386664949131620627931046 iterations: 17000 min: 10300 max: 15521 approx: 119!!! Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on May 17, 2014, 10:36:54 PM The reason perturbation is being used is of course the super speed, and it is very good, but it can be much better. I know I already mentioned it before, but fractal extreme as well as mandel machine are much faster (something like a factor 10) at calculating pixels at full precision than kalles fraktaler is. It's such a big difference that there has to be something fundamentally different about the way they are calculated. What is it?
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on May 17, 2014, 10:58:49 PM For THIRD power. Thanks seryzone you found a bug. It will be at least 1000 skipped iterations!... approx: 119!!! The reason perturbation is being used is of course the super speed, and it is very good, but it can be much better. I know I already mentioned it before, but fractal extreme as well as mandel machine are much faster (something like a factor 10) at calculating pixels at full precision than kalles fraktaler is. It's such a big difference that there has to be something fundamentally different about the way they are calculated. What is it? Unrolled for loops = at least 2 times fasterSIMD = also 2-12 times faster (depending on your CPU) But you cannot unroll the e10000 loops and less the e100000 the program will be too large. ...and you cannot do SIMD in 32-bit... Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on May 17, 2014, 11:39:30 PM Okay, the loop unrolling is more of a speed for space trade-off, but probably still worth doing up to some depth at least. Can you program SIMD? It would improve the speed more than anything at the moment.
Title: Re: Kalles Fraktaler 2 Post by: SeryZone on May 18, 2014, 07:46:18 AM Stop... Why 32-bit do not support SIMD??? It really support SSE (I tried it for my own 32-bit application), I add AVX too. My processor suport all SIMD without AVX2. And my applications on 32 bit and works fast.
Title: Re: Kalles Fraktaler 2 Post by: Botond Kósa on May 18, 2014, 09:09:05 AM Okay, the loop unrolling is more of a speed for space trade-off, but probably still worth doing up to some depth at least. Can you program SIMD? It would improve the speed more than anything at the moment. Loops can be partially unrolled by checking the condition every nth time. If n is large enough (>20), it will run just as fast as a fully unrolled loop. Kalle uses some generic arbitrary precision library I guess, that cannot use Mandelbrot-specific optimizations. This may account for an additional 2x-3x speed difference (in the computation of reference orbits). No SIMD instructions are used in MM to calculate the reference orbit with full precision. Title: Re: Kalles Fraktaler 2 Post by: Botond Kósa on May 18, 2014, 09:21:07 AM Stop... Why 32-bit do not support SIMD??? It really support SSE (I tried it for my own 32-bit application), I add AVX too. My processor suport all SIMD without AVX2. And my applications on 32 bit and works fast. SIMD can be used in 32-bit applications, but only half of the registers (8 instead of 16) will be available. This makes it almost impossible to fully saturate the FPU pipelines of modern processors (especially the ones without HyperThreading). And also full-precision calculation of references will be 4x slower compared to 64-bit. Kalle, do you have any statistics about the 32/64 bit download ratio of KF? Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on May 18, 2014, 04:07:50 PM My full precision class is my own and is not intended to be general, it can be adjusted for Mandelbrot fractals as much as needed :)
When I made it I had an idea that if the number of digits in each integer in the array would be fewer, I would win performance since overflow would not having to be checked, ideally not at all. I compared it with IBM's decNumber and by Wikipedia referred ttmath, and mine was twice as fast when it came to multiplying. I later rewrote it to use fixed decimal positions, and it got another 2 times faster. So I was pleased with that and I haven't touched it much since my very first fractal video 1.5 years ago (18th October 2012 http://youtu.be/PvPk_-xcrEo ) I know that some very smart guys have worked many years with a Mandelbrot program, and they also published a number of articles about it. I have read and adopted only one of these articles, the one about squaring, so I have indeed more to learn in this area. Here is a snippet of the very calculation of the reference: Code: for(i=0;i<m_nMaxIter && !m_bStop;i++){I have implemented a Square function, according to the above, and a Double function that instead of multiplying with 2 does a bit-wise shift, but that's about it when it comes to optimizations. Also note that the threshold values are stored in a 3rd double array, m_db_z, to be used for glitch detection. Those extra 6 double operators also takes some time. The reference calculation has not been my main concern, but any help on making this faster is much appreciated :) Kalle, do you have any statistics about the 32/64 bit download ratio of KF? I am sorry I have no statistics of downloads of my program.Maybe Chillheimer has? It would of course also be interesting for me... :) Title: Re: Kalles Fraktaler 2 Post by: SeryZone on May 18, 2014, 06:56:31 PM My full precision class is my own and is not intended to be general, it can be adjusted for Mandelbrot fractals as much as needed :) When I made it I had an idea that if the number of digits in each integer in the array would be fewer, I would win performance since overflow would not having to be checked, ideally not at all. I compared it with IBM's decNumber and by Wikipedia referred ttmath, and mine was twice as fast when it came to multiplying. I later rewrote it to use fixed decimal positions, and it got another 2 times faster. So I was pleased with that and I haven't touched it much since my very first fractal video 1.5 years ago (18th October 2012 http://youtu.be/PvPk_-xcrEo ) I know that some very smart guys have worked many years with a Mandelbrot program, and they also published a number of articles about it. I have read and adopted only one of these articles, the one about squaring, so I have indeed more to learn in this area. Here is a snippet of the very calculation of the reference: Code: for(i=0;i<m_nMaxIter && !m_bStop;i++){I have implemented a Square function, according to the above, and a Double function that instead of multiplying with 2 does a bit-wise shift, but that's about it when it comes to optimizations. Also note that the threshold values are stored in a 3rd double array, m_db_z, to be used for glitch detection. Those extra 6 double operators also takes some time. The reference calculation has not been my main concern, but any help on making this faster is much appreciated :) I am sorry I have no statistics of downloads of my program. Maybe Chillheimer has? It would of course also be interesting for me... :) Kalle, try to test my e8000 location with operators and without it. And, you, maybe want to realize Karatsuba multiplying? P.s. And you had mistake: rewrite 'Botond Kosa' without 'Botond Kysa': Quote Thanks also to Botond Kуsa and knighty for the extensions on Series Approximation. Title: Re: Kalles Fraktaler 2 Post by: Pauldelbrot on May 19, 2014, 01:59:52 AM P.s. And you had mistake: rewrite 'Botond Kosa' without 'Botond Kysa': Hm? His own user name has an O (though, it's an accented O): "Botond Kósa" If you're seeing a Y, you might have character encoding issues with your browser configuration or something. Title: Re: Kalles Fraktaler 2 Post by: SeryZone on May 19, 2014, 06:44:31 AM Hm? His own user name has an O (though, it's an accented O): "Botond Kósa" If you're seeing a Y, you might have character encoding issues with your browser configuration or something. Ummmm, maybe, you are rigth. My browser even not decode sweden! Duh... Title: Re: Kalles Fraktaler 2 Post by: Chillheimer on May 19, 2014, 09:06:08 AM Maybe Chillheimer has? sorry, no I don't have.It would of course also be interesting for me... :) if you know how to set this up, let me know, and we'll do this Title: Re: Kalles Fraktaler 2 Post by: Botond Kósa on May 19, 2014, 02:10:54 PM Here is a snippet of the very calculation of the reference: Code: for(i=0;i<m_nMaxIter && !m_bStop;i++){I suppose you store the full precision numbers in arrays inside sr/si/xr/xi. How are they stored exactly? In int or long arrays? Do you store decimal or binary digits? How many digits are stored in an int/long value? Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on May 19, 2014, 06:15:53 PM I suppose you store the full precision numbers in arrays inside sr/si/xr/xi. How are they stored exactly? In int or long arrays? Do you store decimal or binary digits? How many digits are stored in an int/long value? Yes, these are of type CFixedFloat.The full precision numbers are stored in an array of 64-bit integers. They are limited to 8 decimal digits per integer in the array. So... perhaps the "Lattice multiplication" method could allow me to have more digits per integer, as long as I use the Microsoft specific routines to multiply them and have them stored in two integers. It could perhaps be a little more effective if they would be stored as binary values, so that bit-wise AND, OR and shift operations could be used instead of modulus, division etc. http://www.chillheimer.de/kallesfraktaler/fractal_src%202.5.zip Title: Re: Kalles Fraktaler 2 Post by: laser blaster on May 19, 2014, 06:28:04 PM I have a couple of tips about arbitrary precision arithmetic. I once wrote my own arbitrary precision math functions for my own fractal zoomer. Nothing came of it, though.
Don't use base 10. It adds extra overhead and is only useful for banking and accounting. Use the full range of the native integer type on the target machine as the arithmetic base. For good performance, it's essential to use inline assembly or intrinsic functions to access the carry bit from addition, and to access the full 128-bit result of multiplying two 64-bit integers (on 32-bit machines, halve those numbers). There's also this fantastic article on hpdz.net about arbitrary-precision math for fractals (these may be the articles you mentioned earlier): http://www.hpdz.net/TechInfo/Bignum.htm (http://www.hpdz.net/TechInfo/Bignum.htm) It has great tips such as halving the number of multiplications needed for a bignum multiplication (which introduces error, but it's more efficient to use this trick and simply increase precision to compensate), and halving it once again for squaring .It also covers karatsuba multiplication, which I would recommend using for very high precisions (the savings will eventually greatly outweigh the costs of the extra carries), although it's not a good fit for SSE instructions, as the article mentions. Title: Re: Kalles Fraktaler 2 Post by: Botond Kósa on May 19, 2014, 08:59:22 PM Laser blaster summed it up very well. One more thing to add: you can avoid multiplication and replace it with a squaring (which is about twice as fast) using an algebraic trick. Details can be found in the following article written by Bruce Dawson, author of Fractal eXtreme:
http://randomascii.wordpress.com/2011/08/13/faster-fractals-through-algebra/ (http://randomascii.wordpress.com/2011/08/13/faster-fractals-through-algebra/) Title: Re: Kalles Fraktaler 2 Post by: 3dickulus on May 19, 2014, 09:36:48 PM sorry, no I don't have. if you know how to set this up, let me know, and we'll do this if you have access to webserver logs... $> grep fraktal_sft64.zip /var/log/www-access.log | wc -l will tell you how many times the file has been accessed on *nix machines :) Title: Re: Kalles Fraktaler 2 Post by: youhn on May 19, 2014, 09:52:49 PM I want to use Kalles Fraktaler to make zoom video, but I'm having some troubles. I'm running Kalles through wine on Linux and would like to produce a serie of still images, which I can scale back to get AA pictures. Then I want to use ffmpeg of mencoder to create the actual video. Is there a way to script it from command line? Or another way to produce large series of images?
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on May 19, 2014, 10:05:47 PM Thanks for the articles.
Of those I had already read and adopt one of them, i.e. the maximum precision truncates the result of a multiplication, and squaring can reuse the same result from a*b and b*a. I just tested the square instead of multiplication trick, and it reduces the time to calculate an e8000 reference with 60000 iterations from 1:10 to 0:47 minute, so I can save a little but not revolutionary much... I think the main drawback with my implementation is that each integer in the array only store 8 decimal digits. If they could store full 64-bit binary values and be multiplied to a 128 bit result, and implemented in assembler, I guess that would probably make it a couple of times faster. I want to use Kalles Fraktaler to make zoom video, but I'm having some troubles. I'm running Kalles through wine on Linux and would like to produce a serie of still images, which I can scale back to get AA pictures. Then I want to use ffmpeg of mencoder to create the actual video. Is there a way to script it from command line? Or another way to produce large series of images? You have the option to store additional jpeg images for each frame on a zoom sequence.There will still be kfb files, so you have to remove these manually if you don't want them. You can choose to store them in highest quality so that you don't loose too much quality. Title: Re: Kalles Fraktaler 2 Post by: youhn on May 20, 2014, 07:46:41 PM Maybe I'm looking in the wrong corner, but I cannot seem to find a way to create good enough series of images. The function "Store Zoom-out images" seems broken (or just does not work correctly running it under Wine in Linux?). Both the kfb and jpg files are created and the numbering in the filenames seems OK. But after some images have been calculated, it seems to hang on just 1 location. Only the first and last few are good, everything in between are duplicated of 1 image.
In the keyframemovie.exe program I don't see an option for storing all (30 fps) images as jpg. Title: Re: Kalles Fraktaler 2 Post by: marius on May 21, 2014, 12:39:39 AM I just tested the square instead of multiplication trick, and it reduces the time to calculate an e8000 reference with 60000 iterations from 1:10 to 0:47 minute, so I can save a little but not revolutionary much... I think the main drawback with my implementation is that each integer in the array only store 8 decimal digits. If they could store full 64-bit binary values and be multiplied to a 128 bit result, and implemented in assembler, I guess that would probably make it a couple of times faster. Just pointing out the obvious: e8000 is 1000 "digits" in your notation? Thus a simple multiply (non-karatsuba) would be order of 1000x1000 operations. e8000 in 64 bit would be 125 "digits". Thus 125x125 operations. That makes it 64x faster.. might be worth the hassle, perhaps? Also, computers are binary machines. Doing such computations in decimal is a crime against their nature :tongue1: Title: Re: Kalles Fraktaler 2 Post by: Botond Kósa on May 21, 2014, 01:44:05 AM Just pointing out the obvious: e8000 is 1000 "digits" in your notation? Thus a simple multiply (non-karatsuba) would be order of 1000x1000 operations. e8000 in 64 bit would be 125 "digits". Thus 125x125 operations. That makes it 64x faster.. might be worth the hassle, perhaps? Also, computers are binary machines. Doing such computations in decimal is a crime against their nature :tongue1: e8000 is 8000 decimal digits, this equals to 8000 * log210 = 26575 binary digits, and this equals 416 words (assuming 64-bit word length). So it would need 416x416 operations in binary, that is only about 5 times faster. Title: Re: Kalles Fraktaler 2 Post by: marius on May 21, 2014, 05:05:35 AM e8000 is 8000 decimal digits, this equals to 8000 * log210 = 26575 binary digits, and this equals 416 words (assuming 64-bit word length). So it would need 416x416 operations in binary, that is only about 5 times faster. Good point, duh. It seemed excessive when I did the math in my head but what's a factor of 10 among friends? ;D Title: Re: Kalles Fraktaler 2 Post by: SeryZone on May 21, 2014, 06:38:36 AM Heehee... My location is useful, isn't it?
P.s. Who knows, what does it means: sfufpd or shufps ymm1, ymm2 and after binary code??? How it works? Title: Re: Kalles Fraktaler 2 Post by: Botond Kósa on May 21, 2014, 09:22:27 AM Heehee... My location is useful, isn't it? P.s. Who knows, what does it means: sfufpd or shufps ymm1, ymm2 and after binary code??? How it works? http://www.jaist.ac.jp/iscenter-new/mpc/altix/altixdata/opt/intel/vtune/doc/users_guide/mergedProjects/analyzer_ec/mergedProjects/reference_olh/mergedProjects/instructions/instruct32_hh/vc293.htm (http://www.jaist.ac.jp/iscenter-new/mpc/altix/altixdata/opt/intel/vtune/doc/users_guide/mergedProjects/analyzer_ec/mergedProjects/reference_olh/mergedProjects/instructions/instruct32_hh/vc293.htm) http://www.jaist.ac.jp/iscenter-new/mpc/altix/altixdata/opt/intel/vtune/doc/users_guide/mergedProjects/analyzer_ec/mergedProjects/reference_olh/mergedProjects/instructions/instruct32_hh/vc292.htm (http://www.jaist.ac.jp/iscenter-new/mpc/altix/altixdata/opt/intel/vtune/doc/users_guide/mergedProjects/analyzer_ec/mergedProjects/reference_olh/mergedProjects/instructions/instruct32_hh/vc292.htm) These are descriptions for the shufps and shufpd working on 128-bit xmm registers. 256-bit ymm variants work analogously, but shuffle twice as many data. Title: Re: Kalles Fraktaler 2 Post by: ratcat65 on May 21, 2014, 12:43:36 PM Newbie question here, i'm afraid. The last few frames of creating a zoom out movie are painfully slow to render. I'm currently stuck rendering a mandelbrot at 1.5 million iterations which is absurd. Is there some way to render these final few keyframes at a more realistic resolution? I tried cancelling the render and then lowering the iterations and then refresh but the program just renders that one frame and stops. If i try to restart the zoom out it just goes back to 1.5 million iters again.
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on May 21, 2014, 12:56:11 PM Ratcat65 - lower the iterations and restart the zoom sequence - but not with the "resume" menu option but instead with the "store zoom sequence" menu. The program keeps track of previous rendered files and their numbers.
I will make an update within short with this issue fixed. There is a risk though that it will be an issue with the extreme movies like the YouTube user "fractal universe" creates, so I need to test it... Title: Re: Kalles Fraktaler 2 Post by: ratcat65 on May 21, 2014, 01:25:53 PM OK, Thanks. It seems obvious now. :embarrass:
Title: Re: Kalles Fraktaler 2 Post by: laser blaster on May 21, 2014, 05:31:32 PM I thought I'd mention that I've succeeded in applying perturbation theory to the burning ship fractal. I even have a sample program written in Fragmentarium glsl, that demonstrates the correctness of the formula (though my program is extremely inefficient and limited). The formula really needs a good CPU-side implementation to be useful.
So if you have the time and inclination, Kalle, I'd love to see the burning ship added to your program. http://www.fractalforums.com/index.php?topic=19165.0 (http://www.fractalforums.com/index.php?topic=19165.0) Title: Re: Kalles Fraktaler 2 Post by: ratcat65 on May 23, 2014, 02:10:41 AM I was doing a zoom out sequence this evening and noticed when playing back what I had rendered in the keyframes editor that there was a sudden jump from e519 to e516 in the keyframes. I'd like to somehow render the missing frames but things start to get complicated when re-inserting frames into a numbered sequence. Is there a way to do this without resorting to a batch file renamer?
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on May 23, 2014, 05:16:27 PM I was doing a zoom out sequence this evening and noticed when playing back what I had rendered in the keyframes editor that there was a sudden jump from e519 to e516 in the keyframes. I'd like to somehow render the missing frames but things start to get complicated when re-inserting frames into a numbered sequence. Is there a way to do this without resorting to a batch file renamer? Sorry, there is no such function available in Kalles Fraktaler... :hurt:Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on May 23, 2014, 07:35:07 PM I just uploaded version 2.5.3
News: - A new fractal type, Burning Ship. Thanks to lazer blaster for the forumla! Available from the "Iterations" dialog. - Iteration control on zoom out sequences. This may fail though, on extreme fractals where spirals can have many times more iterations than deep minibrots, so it can be disabled by un-checking the menu "Use auto iterations". - Probably some bug fixes, that I don't remember. The perturbation formula of Burning Ship from lazer blaster shows that it is indeed possible to render more fractal types with perturbation. More formulas are very much appreciated, I challenge all of you with fresh mathematics knowledge! :) For example: Perpendicular Burning Ship - Zi = Zr * |Zi| * -2 + Ci, Zr = Zr^2 - Zi^2 + Cr Perpendicular Mandelbrot - Zi = |Zr| * Zi * -2 + Ci, Zr = Zr^2 - Zi^2 + Cr Cubic Buffalo - Z = abs(Z^3) +C, The abs() function is applied separately to both the real and imaginary portions of Z^3 Newton fractals... Title: Re: Kalles Fraktaler 2 Post by: plynch27 on May 23, 2014, 08:31:43 PM Hey, Kalle, I was wanting to make a kind-of feature request for the Key Frames Movie Maker side of the program.
It would help out a lot if the user could choose the output directory, mainly because the program is very heavy in hard drive activity with both the input and output streams being always open for the whole process. In cases like this, if the program isn't reading from and writing to the same hardware, its performance will easily multiply by a factor of 4, possibly up to 10 depending on the rest of the system's configuration. The limiting factor that drops the performance in Movie Maker's current configuration doesn't even really have much to do with the width of the pipeline; it's the constant back-and-forth seeking mixed with the fact that it's constant switching back and forth between read and write modes. Reading and writing from different hardware makes the data stream far more solid, so the data can smoothly move from the input drive through the program's code to the output drive without ever having to wait in line for any of the hardware to prepare to receive it. Thanks again for the program. Title: Re: Kalles Fraktaler 2 Post by: laser blaster on May 23, 2014, 09:51:57 PM All right! Burning ship here I come! Thanks Kalle!
Title: Re: Kalles Fraktaler 2 Post by: Chillheimer on May 23, 2014, 10:31:44 PM wow, so cool! thanks kalle! and laser blaster!!
Title: Re: Kalles Fraktaler 2 Post by: ellarien on May 24, 2014, 12:32:12 AM That was fast! Thank you!
I hit something a bit weird on my second attempt at a zoom. Can anyone tell me why the mini-ship at this location is so distorted? Throwing more iterations at it doesn't seem to help, at least up to the limits of my patience. Code: Re: 1.1450415777350918293427892524606566433234618099943861636234308511641091674036753925539578015640361144825447621300752714644020002832604952 Title: Re: Kalles Fraktaler 2 Post by: laser blaster on May 24, 2014, 02:30:39 AM The Burning Ship's mini-sets aren't always ships. Sometimes they are copies of the celtic fractal (some say it looks like an aircraft carrier), or some weird elongated, asymmetrical pointy heart shaped thing, or a hybrid of any of the three. The exact nature of the mini-set depends on your zoom location.:)
Title: Re: Kalles Fraktaler 2 Post by: ellarien on May 24, 2014, 11:13:23 AM The exact nature of the mini-set depends on your zoom location.:) Thanks! And south of the western antenna there aren't any minisets at all? Maybe I'm over-generalizing, but I've done a couple of zooms down there and found lots of pretty julia-like structures with nothing in the middle but a sort of shallow cusp. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on May 24, 2014, 12:35:09 PM Thanks all
@plynch27, I don't think it is disk io that is the bottleneck of kfmm. Because if you check 'test only' it is about as slow as when movies are made (if you consider it used 2 frames for test and 6 for real render) So unfortunately I doubt it would get any faster reading and writing from different hardware storages. Because it takes time to do thing such as color cycling. Our non-forum French friend Yann had made his own movie making program from KFB files, and so has SeryZone. I don't think their programs are much faster if you consider what they do. Title: Re: Kalles Fraktaler 2 Post by: ratcat65 on May 24, 2014, 02:41:32 PM Inverse smooth colour transition isn't showing up when the keyframes are loaded into the editor. The .kfr file was saved with inverse smoothing and if the file is opened the effect is present.
Thanks Kalle for a fantastic program. I'm looking forward to the perpendicular buffalo. Title: Re: Kalles Fraktaler 2 Post by: SeryZone on May 24, 2014, 05:50:38 PM Thanks all @plynch27, I don't think it is disk io that is the bottleneck of kfmm. Because if you check 'test only' it is about as slow as when movies are made (if you consider it used 2 frames for test and 6 for real render) So unfortunately I doubt it would get any faster reading and writing from different hardware storages. Because it takes time to do thing such as color cycling. Our non-forum French friend Yann had made his own movie making program from KFB files, and so has SeryZone. I don't think their programs are much faster if you consider what they do. Kalle, my programs very stupid! I can't make anything! Title: Re: Kalles Fraktaler 2 Post by: laser blaster on May 24, 2014, 06:59:09 PM So I was rendering a zoom sequence, and I changed the window size. Well that caused the render resolution to change to the window size, so I tried to fix the resolution, and the program crashed. Now I'm trying to resume the zoom sequence, but now it will only render the next frame and then stop without even saving the frame...
It might be because I deleted a bunch of black frames and the corresponding kfb files from the zoom sequence directory (these were frames that it never rendered before, I guess they were pre-allocated or something). Is there any way to recover from this disaster? Title: Re: Kalles Fraktaler 2 Post by: ellarien on May 24, 2014, 07:29:55 PM Something is definitely odd about the color tables and the movie rendering. After saving a lot of burning ship zoom sequences I've just started rendering one, and it's coming out with completely different colors from the ones in the saved jpegs. I'm using the 1.21 version of the movie maker -- should I have updated that too?
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on May 24, 2014, 09:21:14 PM @ellarien, 1.21 is the latest version. I will need to render a sequence to see if the palette doesn't work... :)
Edit: Color offset is not read by kfmm. Also color cycling, number of colors, color division and color waves can be changed in kfmm, it may be this that differs? @laser blaster, Changing the window size only affects the render if the new size is larger than the background memory image. I haven't done that much though so I haven't tested that. If it crashes the program I didn't know, it's easy to fix though. And unfortunately I haven't render with together with storing jpeg either. I think there is a problem with that, memory leakage perhaps, I need to investigate that. Edit: Even though the jpegs comes out as black, due to this memory leak, the kfb files are usually ok and you can view them in the movie maker. I never stor jpegs anymore, and I use the kfmm program to check the result, by entering the frame number and click the test button... ratcat65 - yes you are right, I have forgot to implement that in kfmm. Will do that :) Title: Re: Kalles Fraktaler 2 Post by: laser blaster on May 24, 2014, 09:48:58 PM Wait, there is a different way to render than to store zoom-out images? I just want to be able to resume the rendering from where I left off and then put together a zoom movie. I could manually enter the coordinates for the next frame and start a new zoom sequence, but then will I be able to combine it with the previously rendered frames to make a full zoom video? :hmh:
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on May 24, 2014, 10:04:21 PM Wait, there is a different way to render than to store zoom-out images? I just want to be able to resume the rendering from where I left off and then put together a zoom movie. I could manually enter the coordinates for the next frame and start a new zoom sequence, but then will I be able to combine it with the previously rendered frames to make a full zoom video? :hmh: Yes, if you enter the coordinates manually you can start a new sequence with the menu "Store zoom-out images" (instead of Resume...)The existing kfb files will be detected and the file number will be increased. But make sure you set the zoom value with many decimals (more than 4) so that there wont be any visible joints Title: Re: Kalles Fraktaler 2 Post by: ellarien on May 24, 2014, 10:26:31 PM @ellarien, 1.21 is the latest version. I will need to render a sequence to see if the palette doesn't work... :) Edit: Color offset is not read by kfmm. Also color cycling, number of colors, color division and color waves can be changed in kfmm, it may be this that differs? I wasn't doing anything fancy with the colors in kfmm, but there may have been an offset. I guess that would explain it. Thanks! Title: Re: Kalles Fraktaler 2 Post by: ellarien on May 26, 2014, 10:34:04 PM I posted some images on Flickr. (https://www.flickr.com/photos/ellarien/sets/72157644900929333/) I'm rather intrigued by these things, south of the Western Antenna -- as far as I can tell one could zoom in indefinitely and never find a miniset, but I could be wrong. (https://farm3.staticflickr.com/2908/14089051460_1e488e62af.jpg) (https://flic.kr/p/nt159m)may24_04 (https://flic.kr/p/nt159m) by ellarien (https://www.flickr.com/people/77963359@N00/), on Flickr Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on May 27, 2014, 09:28:52 AM I posted some images on Flickr. (https://www.flickr.com/photos/ellarien/sets/72157644900929333/) I'm rather intrigued by these things, south of the Western Antenna -- as far as I can tell one could zoom in indefinitely and never find a miniset, but I could be wrong. (https://farm3.staticflickr.com/2908/14089051460_1e488e62af.jpg) (https://flic.kr/p/nt159m)may24_04 (https://flic.kr/p/nt159m) by ellarien (https://www.flickr.com/people/77963359@N00/), on Flickr I am not quite familiar with the Burning Ship yet, so I am making nice discoveries. I agree it is fascinating, so very different compared with ordinary Mandelbrot. http://www.youtube.com/watch?v=2p6FB4eHzyM Title: Re: Kalles Fraktaler 2 Post by: SeryZone on May 31, 2014, 12:01:42 PM Whohoo! Reference generates about 28 seconds on e9000! Cool!
Title: Re: Kalles Fraktaler 2 Post by: kjknohw on May 31, 2014, 02:30:52 PM I'm rather intrigued by these things, south of the Western Antenna -- as far as I can tell one could zoom in indefinitely and never find a miniset, but I could be wrong. I have seen similar "sterile regions" in other fractals that have "reflecting" aspects in their formula (such as abs(real)), or branch points. It's like they get "cut off". Are they truly sterile or is there a mini miniset somewhere? Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on May 31, 2014, 02:52:49 PM I think no one ever found one in that region. I also took the challenge a few times but without succes.
Title: Re: Kalles Fraktaler 2 Post by: ellarien on June 01, 2014, 12:49:21 AM I suppose a really tiny miniset is possible. Even north of the antenna they can be elusive -- I've just done a zoom sequence where about halfway down it passes through an 'island' that is about four pixels on an otherwise bland frame, and I'm working on one now where I got down to e200 before I found anything that didn't end up centered on a void after a few zooms. South of the antenna, though, I can't see where a miniset would be hiding at all.
Title: Re: Kalles Fraktaler 2 Post by: youhn on June 01, 2014, 02:01:26 AM I found out that the burning ship is very sensitive to the color density (divide iteration in Kalles Fraktaler). For zoom(in/out) vids for burning ship, we need an automatic adjustment or another color method altogether.
Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on June 01, 2014, 03:08:37 AM For some reason coordinates from the burning ship in fractal extreme do not work in kalles fraktaler.
The whole thing looks mirrored, so I flipped the sign, but there's apparently something else going on. Which program does the correct calculations? Title: Re: Kalles Fraktaler 2 Post by: panzerboy on June 01, 2014, 03:38:05 AM 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: Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on June 01, 2014, 04:29:40 AM Oh, so you still have to invert the imaginary part as well. Compared to your fractal extreme plugin, it looks only to be flipped horizontally.
Title: Re: Kalles Fraktaler 2 Post by: hgjf2 on June 01, 2014, 09:15:01 AM 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" :peacock: :thumbsup1: :surprised: :ok: Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on June 01, 2014, 07:39:33 PM 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 ;D And finally I know where this pattern comes from: :spiral: Title: Re: Kalles Fraktaler 2 Post by: youhn on June 01, 2014, 08:41:33 PM 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! :beer: Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on June 02, 2014, 07:42:25 PM 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 Thanks! But it is and will always be an experimental prototype :)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! :beer: 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...) Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on June 02, 2014, 07:51:33 PM From memory I flipped the coordinates for FX's burning ship, to make it look like examples I'd seen online. 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.Just checked the code... yep coordinates are flipped by subtracting the real and imaginaries eg. Code: case FT_BurningShip: Code: Re = 1.99433270612477098133238929437627777114179521395878761184111509174580069593600399539342136038592734218389132940639032704182715934691321308296153457671113540459988177959341694798272090475163809104849804990505554293321832065055051136201576337342335810747775706468375892916000095316130617700229812635608032228538842556508340662529592613070320 Magnification: 2^1111 2.7817953874931422193200157252798 E334 Title: Re: Kalles Fraktaler 2 Post by: ellarien on June 02, 2014, 08:45:29 PM 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.
Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on June 02, 2014, 09:05:35 PM 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.
(http://i538.photobucket.com/albums/ff342/formule/FX_burning_ship.png~original) (http://i538.photobucket.com/albums/ff342/formule/KF_burning_ship.png~original) Bailout value is set to be 2 in both images and smooth colors are off. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on June 02, 2014, 09:56:15 PM 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? Title: Re: Kalles Fraktaler 2 Post by: youhn on June 02, 2014, 10:42:42 PM ... 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). Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on June 03, 2014, 12:48:48 PM 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. 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.... Bailout value is set to be 2 in both images and smooth colors are off. 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?Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on June 03, 2014, 08:26:04 PM 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. 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.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? 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. Title: Re: Kalles Fraktaler 2 Post by: ellarien on June 03, 2014, 09:31:24 PM 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. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on June 03, 2014, 10:19:33 PM 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: Anyway, if your formula is creating beatiful additional patterns, it is cool :) But I don't understand the difference... Title: Re: Kalles Fraktaler 2 Post by: panzerboy on June 04, 2014, 03:22:54 AM 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. :embarrass: Attached is the glitch with the smoothed logic. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on June 08, 2014, 08:20:23 PM 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/ (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 Title: Re: Kalles Fraktaler 2 Post by: ratcat65 on June 10, 2014, 05:32:35 PM I think there could be a stability issue with version 2.5.4. I started rendering a zoom out sequence last night from e413 and the program terminated unexpectedly at least 8 times before it reached e400. A few times also rendering stopped mid way and the program had to be terminated and restarted by me. I have restarted the render with version 2.5.3 and have not had any problems, so far.
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on June 12, 2014, 06:06:32 AM Interesting and thanks for keeping 2.5.3
I'll have a look! Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on June 19, 2014, 03:43:16 PM I have uploaded a new version of Kalles Fraktaler, now 2.5.5
- Bugifx: A float overflow could hang high power zooms - Bugfix: One pixel sized glitches were not always "covered" as intended - More additional references are added, now up to 130. This is because SeryZone's program's histogram coloring showing glitches that are not corrected too much. - When zooming deep into higher zooms, I realized the need for a quick preview of the whole image. So the image is now generated in 8x8 pixels as a first step, similar to how Fractal eXtreme is doing. Also a new version of Key Frame Movie Maker, now 1.22: - Bugfix: There were "jumps" in the color when negative cycling and fractional color division. As Yann has showed (with his own movie program) really cool movies can be made with these settings. Thanks all for your contribution! Now it is midsummer time in Sweden and time to leave the computer for a while :) Title: Re: Kalles Fraktaler 2 Post by: ratcat65 on June 19, 2014, 09:36:34 PM Thank you so much, Karl for all your efforts in continuing to improve this fantastic program. .. cheers :beer:
Title: Re: Kalles Fraktaler 2 Post by: Roquen on June 20, 2014, 10:07:00 AM Some notes on very old post:
The JVM (HotSpot) does not support SIMD in any meaningful way in that it does not auto-vectorize. It will only generate scalar operations. Perhaps some of the experimental ones will such as Graal. I wouldn't bother writing anything in assembly. Just use the intrinsic functions as they are supported by gcc, clang, visual studio, and intel's compilers. The compilers won't do as good a job but less hassle. Title: Re: Kalles Fraktaler 2 Post by: youhn on June 22, 2014, 09:58:06 AM Thanks for the update! Just downloaded both programs. Will try the movie maker with DivIter < 1 and negative color cycle.
:thanks1: Title: Re: Kalles Fraktaler 2 Post by: plynch27 on June 23, 2014, 06:47:31 PM I don't think it is disk io that is the bottleneck of kfmm. Because if you check 'test only' it is about as slow as when movies are made (if you consider it used 2 frames for test and 6 for real render) That's a very good point. When I wrote that post I'd used the "test only" mode a few times, but it hadn't clicked in my head that it was running at the same speed as the full render. I think I'm just way too used to writing write-heavy programs. lolTitle: Re: Kalles Fraktaler 2 Post by: youhn on June 23, 2014, 08:35:17 PM New movie done!
Just a bit of color cycling, a color palette with some pastel-like contrasts, some playfull zooming speeds ... and of course a little addition from youtube. Which makes the details pop up out of the waved-colored iteration goodness. https://www.youtube.com/watch?v=XC8vUxCtRfw Params to be found on the youtube description. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on June 23, 2014, 10:19:27 PM Lovely! And it is very cool that you did it on Linux :)
Title: Re: Kalles Fraktaler 2 Post by: youhn on June 23, 2014, 11:04:27 PM Ha, so you admit linux is cool and still develop
:hit: No, just kidding. I think I read something about being very hard to compile, not sure if it was about Kalles Fraktaler or another fractal zoomer. You could do one thing that would make me happier than I already am with your software. Make the key frame movie maker write all frames directly to JPEG or PNG (like SeryZone's map visualizer does, I still have to put myself on that). Because if the disk space and my patients allows, I try to do some scaling and blurring with ImageMagick (command line tool, perfect for batch operations). Recently I found out that mencoder (part of MPlayer) also can do blurring, while recoding the videos. But the flexibility of mencoder makes it hard to use. Maybe I'll write some tutorial to use with Kalles Fraktaler if I manage to get a comfortable workflow. Title: Re: Kalles Fraktaler 2 Post by: kjknohw on June 24, 2014, 02:04:01 PM Ha, so you admit linux is cool and still develop The KF source code is very windows-centric. Thankfully it works on Wine... Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on June 24, 2014, 04:30:00 PM Ha, so you admit linux is cool and still develop Yes I do indeed admit that there are other cool OS. But unfortunately I have never ever tried Linux in any way. Unfortunately. The KF source code is very windows-centric. Thankfully it works on Wine... I don't think it is so windows centric. ;) It should be fairly simple to split windows specific code from general computations I think (hope). The big problem I had when I tried to compile it with gcc is all the operators of CFixedFloat. Return variable or reference, const or not, etc etc etc.... And if I get it working in gcc it doesn't work in VS10. So I didn't had the time to make it work in both and then I skipped gcc. Unfortunately. I succeeded to make the operators of floatexp work in both compilers, but it is much simpler. Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on July 03, 2014, 09:39:13 PM Since not all of us lives in areas with reliable power supply, I have made an update on Kalles Fraktaler, now version 2.5.6.
The current frame is saved in intervals and the zoom can be resumed from the first frame. Title: Re: Kalles Fraktaler 2 Post by: ratcat65 on July 08, 2014, 08:56:24 AM Lets imagine you've just spent the last 24 hours creating a series of zoom out images/keyframes and now there is something you don't like about the gradient. Currently, as far as I know there is no way to apply a different gradient to the fractal data without rendering the whole zoom out series again. Will the ability to apply different gradients to the fractal data be implemented in future versions?
Title: Re: Kalles Fraktaler 2 Post by: Dinkydau on July 08, 2014, 03:45:50 PM As a workaround you can use seryzone's program to change the colors to something you like better.
Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on July 08, 2014, 06:03:15 PM Lets imagine you've just spent the last 24 hours creating a series of zoom out images/keyframes and now there is something you don't like about the gradient. Currently, as far as I know there is no way to apply a different gradient to the fractal data without rendering the whole zoom out series again. Will the ability to apply different gradients to the fractal data be implemented in future versions? The palette is fetched form the first frame (KFB). So if you re-save the first frame with a new palette that palette will be used. But I guess you won't be able to see how the palette looks like using the first out-zoomed frame, so here is what you can do: * Use the examine zoom sequence and select a frame where you can see the result of the palette. * save the palette as a palette file * go to the first frame, open the palette, and then save. You may need to click in the image somewhere to add a reference to make it be saved. Sorry for this complicated sequence of operations. The color dialog should maybe be inserted in the KFMM program as well I guess. I only use the waves these days... Title: Re: Kalles Fraktaler 2 Post by: ratcat65 on July 08, 2014, 07:48:44 PM Thanks. That's funny because I tried that a few weeks back and it didn't work. Must have done something wrong, I guess.
Thanks, as always for this excellent program. :beer: Title: Re: Kalles Fraktaler 2 Post by: Kalles Fraktaler on July 08, 2014, 08:08:24 PM Thanks. That's funny because I tried that a few weeks back and it didn't work. Must have done something wrong, I guess. Thanks a lot. I am willing to call it a experimental prototype :DThanks, as always for this excellent program. :beer: The test button doesn't reset cached datat unfortunately. You may need to check 'test only' and press 'Start' or even restart the program. Title: Re: Kalles Fraktaler 2 Post by: cKleinhuis on July 31, 2014, 12:29:56 AM ******************** REMARK ********************** i splittet the most recent postings in this thread into separate postings, so that this overcrowded thread can come to an end, since kalle has now his own board, make use of it and make finer graded postings, creating a better sorted reference and i locked the topic and made it sticky ;) |