User talk:Patteone

Java source code

There are various versions of the source code. Here's the project directory that created Zom-B's image (you'll need this if you want to create the deep zoom as it contains the DoubleDouble class.) Here's some classes from one I made more recently which is lacking the DoubleDouble class although it contains an easier to adapt gradient creator class and it shouldn't be too hard to add the DoubleDouble class. --Simpsons contributor (talk) 11:24, 28 September 2011 (UTC)[reply]

Also if you want to make an animation this animated gif creator should be handy too. --Simpsons contributor (talk) 11:46, 28 September 2011 (UTC)[reply]

I've uploaded a new and better version of the Mandelbrot renderer which contains a class that checks if double precision is adequate. Basically this allows you to use the faster double based processor class for as long as possible as the DoubleDouble based processor is much slower. --Simpsons contributor (talk) 17:14, 29 September 2011 (UTC)[reply]

Hi, thank you so much for the code! Why dont you put it in a public repository? The code was already very useful to me as I'm now using it to generate the zoom sequence in 1920x1080 resolution. When I'm done I will upload the h264 video and put the link here. I modified your code by removing the swing parts, the schedulers and the parallel processing. Benchmarking yielded that it was faster without showing a preview in the window, without calculating fancy scheduling patterns und by not using threads but a number of different processes with different start and end frame numbers. The color gradient is so pretty! --Patteone (talk) 21:57, 29 September 2011 (UTC)[reply]

Yeah I never understood why Zom-B used that weird scheduler model; here's what happens when I try to make a (720p) HD image. There's some odd design patterns there. That DoubleDouble class is certainly invaluable though. What program will you use to turn the image string into a video? Also I've provided links to the source code (mine and Zom-B's) on the Wikimedia Commons page now. --Simpsons contributor (talk) 12:32, 2 October 2011 (UTC)[reply]

I put my code into this git repository the readme also lists how to convert the frames into a video. I'm using linux, so doing it, is just one small command. It also might explain that I dont have the problem you are having since I'm not using the sun/oracle java you are probably using on windows but the openjdk by redhat. I have no errors here and already produced over 1200 frames. A priliminary video in low resolution of what is done until now can be found here.--Patteone (talk) 15:51, 2 October 2011 (UTC)[reply]

Yeah I've never used Linux before, I use the Windows jdk and NetBeans. I've been wanting to write a AVC encoder for a while now, but that's easier said than done and the specification is roughly £209. --Simpsons contributor (talk) 08:11, 3 October 2011 (UTC)[reply]

It seems that precision is not high enough anymore for such a high resolution starting at about id 1600. Have a look at number 1680 here. It seems I need to begin using an arbitrary precision library.

Aren't you using the DoubleDouble (MandelPrecision) class? --Simpsons contributor (talk) 06:56, 7 October 2011 (UTC)[reply]

I didnt change anything in the algorithms and neither did I remove the DoubleDouble. To prove that it is not my changes, I was running the original Zom-B code you sent me and it starts throwing this error beginning with id 1591:

     [java] SEVERE: null
     [java] precision.PrecisionException: X precision lost!
     [java] 	at precision.CheckPrecision.checkPrecision(CheckPrecision.java:36)
     [java] 	at deepZoom.renderer.Scene.render(Scene.java:206)
     [java] 	at deepZoom.MandelAnimator.calculate(MandelAnimator.java:258)
     [java] 	at deepZoom.calculator.ParallelCalculator.run(ParallelCalculator.java:50)
     [java] 	at java.lang.Thread.run(Thread.java:636)

I dont get this error in my modified code because I removed CheckPrecision.java for more speed. --Patteone (talk) 07:16, 7 October 2011 (UTC)[reply]

At line 59 of MandelAnimator after image 1591 (when double precision produces duplicate values per pixel) you should just change [private Fractal fractal = new Mandel();] to [private Fractal fractal = new MandelPrecision();]. Also I placed the check precision method in a poor location (checking once per pixel instead of once per scene, I'll move that now.) --Simpsons contributor (talk) 10:27, 7 October 2011 (UTC)[reply]

Indeed that works but the time it now takes to calculate a new frame is insane! 4 hours for a single frame! This would be about one year for the remaining 2000 frames! Once I have time I should reimplement the same algorithm in C using a faster multiprecision library. And why is the switching from double to doubledouble precision not done automatically in the original code? --Patteone (talk) 18:22, 7 October 2011 (UTC)[reply]

Using DoubleDouble to make HD video won't be cheap. As I say in the description of the original image the small (640x480) animated gif with a mere 475 frames and 3x anti-aliasing took months to render using the two most powerful computers I had at the time (4 cores each). In the end I lost count of the exact time and just had to call that "a while" in the description. You're going to need a supercomputer or cloud configuration to make a deep HD zoom in. C code may be a better option than Java, although arbitrary precision may be even slower than DoubleDouble. --Simpsons contributor (talk) 19:32, 7 October 2011 (UTC)[reply]