hpdz.net

Beyond E308

From the beginning, the software used for all videos on this site, even the most deep-zoom animations, has represented the size of the image on the complex number plane with a regular old IEEE754 double-precision floating point number. That is all right for almost every purpose, because even for most deep-zoom animations, the approximately 14 digits of precision that format offers is enough to specify the difference between the left/right and top/bottom coordinates with way more accuracy that is needed to locate pixels correctly in the image.

But using the native double-precision format to represent the size of images does impose a subtle limit -- a limit on the smallest image that can be drawn. Since the IEEE754 format represents the exponent value with 10 bits of binary data, it is limited to about 1e-308 as the smallest number it can represent. That means that the top-bottom difference (which is what I refer to as "size") is limited, and images smaller than about 1e-308 on the complex number plane just can't be drawn. This is purely an artifact of a bad choice I made ten years ago when I started this project. Back then, it seemed inconceivable that an creating an animation zooming to such a small size would ever be feasible.

But computing power has increased dramatically, and several others have published animations quite a bit beyond E308, so I had to fix this limit. Once the arbitrary-precision floating point arithmetic code was done, using it to represent the size was a natural next step.

It was painful, since that double-precision type for the size is integrated deeply and widely in the code, but in April 2011 I finally got that done.

Now the limit on how deeply I can zoom is determined by the range of exponents of the arbitrary-precision floating point arithmetic library. The details are explained on the floating point arithmetic page (see link above, but the bottom line is that it can represent numbers as small as about 1/10^323,228,497. More than enough!! Nobody is going to zoom that deep anytime soon, and even if the technology existed to do make such an animation, it would be 10.24 years long if it started from something around 10⁰ or 10¹ and magnified 10X every second.

Results

The first Beyond E308 image was created with this software in late April. This is a size of 1e-305 and is centered on the Misiurewicz point (1,0).

The second image was made the next day, after getting a good rest. It has a size of 1e-400 and yet is not 10⁹⁵ times more exciting, centered on the same point (1,0).

The first E1000 image zooms to the Misiurewicz point at (-2,0), always a favorite.

The First Deepest Zoom Ever!

Click on the image to download an 8 MB MP4 video file (no fast start)

The thumbnail above is a link to the first animation to E1000 made with this software, showing the final frame at E1000. If it were not so short, this would be in the running for the most boring fractal animation ever created -- or indeed, the most boring animation of anything ever created. But with a mere 1000 frames it lasts only 33-1/3 seconds and zips by so fast it's over before you realize it. That's a factor of 10X every frame, and you can see a lot of temporal aliasing in this. Obviously, this was just intended to be a test, not something you'd actually want to watch. It was rendered with frame interpolation, and was the first successful test of the frame interpolation system with the new arbitrary-precision floating-point size parameter.

It took almost exactly 2.5 hours to render the original 80x45 pixel frames for this on a 3.0 GHz quad-core Core2 Extreme (not the same CPU that the previous system used, although it is the same motherboard).

This 2 Mbps MP4 encoding is 800x450, or 10X the original format, just to save anyone who wants to watch it the annoyance of having to enlarge their player to see it. The weird movement at the beginning is because this was designed to test the interpolation system's ability to track as well as zoom, so the animation starts out centered at (0,0), then magnifies while translating to (-2,0). That motion is over by about frame 21.

This video and the two below are, for what it's worth, the DEEPEST ZOOMS EVER into the Mandelbrot set that are made without undersampling the image data. At least one other video out there goes to 1e-999, but uses a very clever mathematical transformation to drastically reduce the computing time by oversampling data only in the center of the image and allowing the periphery of the image to become drastically undersampled. Search for "phaumann" on YouTube.

One could argue that publishing this in 800x450 format is also undersampling, and that opens up a can of worms about what is fair game to put out there as the deepest zoom. What if I made a 16x9 video?

Two More Serious E1000 Animations

These are zoom animation starting with a size of 10¹ on the complex number plane (in the y-direction) and ending with a size of 10^-1000. That's an overall magnification of 10¹⁰⁰¹. The magnification rate is 10X per second, and the frame rate is 30 fps, so each video has 30,031 frames. The extra 1 frame is due to a tiny arithmetic error in the software that I've never bothered to fix. Note that 1001 seconds is over 16 minutes.

These test videos were rendered with frame interpolation from 3753 primary images at 315x181 resolution, downsampled to 160x90 video frames, then upconverted to 1600x900 in the final video compression step for no good reason other than to save the hassle of having to enlarge the video in the player. The videos are encoded at 2Mbps and are only available as MP4 files. They have no music. Again, they're just tests, not real production art.

The thumbnails below are the final frame of each video, both at a size of 1e-1000 vertically.

E1000A

Click on this image to download a 245 MB MP4 video file

This zooms into the Misiurewicz point at (-2,0) like the above tiny animation does. This was rendered in about 48 hours.

E1000B

Click on this image to download a 245 MB MP4 video file

This zooms into the Misiurewicz point at (1,0) (my software draws + numbers down, so it looks upside down). This took about 77 hours to render, longer than E1000B, because half of the (-2,0) image is points that always require 0 iterations to be excluded.