Welcome to Fractal Forums

In the book "The Beauty of Fractals" there are some very striking black and white images of Mandelbrot and Julia sets. (For example, Map 41 on page 84, and map 43 on page 85. Also an unnumbered plot on page 188.)

I really like the look of these plots, but I am at a loss to figure out how they were created. I always assumed that they were just plots calculated to some arbitrary number of iterations, and pixels that escaped where colored in white, and pixels that did not escape were colored in black. However, that's not the case.

Does anybody else know how these images were created?

I realize that this book is a bit dated, but I still really like the images and would love to know how they were created.


Duncan C.

P.S.: In contrast, there is an image on page 192 that the authors say required an IBM mainframe at IBM labs in Bblingen, plus a special high resolution printer. I was able to duplicate this image quite easily in a few minutes using my laptop and HP Laserjet printer. Today's laptop is yesterday's supercomputer.

I gave it a very quick try using FractInt, and came up with these PARs which you can use to load and try out.  I also saved the MAP files used to create them if you wish those separately.  (See the images further on down.)

test_01            { ;  (c) Paul N. Lee -- Apr 13, 2007 - 02:15:26
                     ; time=  0:00:00.82 on a PIII-700 at 640x480
                     ; Video=F5 using FractInt 2099.8
  reset=2099 type=mandel passes=t
  center-mag=+0.29124525926602574/-0.01530508041716197/3112.83
  params=0/0 float=y inside=0 colors=www000<253>000
  }

test_02            { ;  (c) Paul N. Lee -- Apr 13, 2007 - 02:15:26
                     ; time=  0:00:00.82 on a PIII-700 at 640x480
                     ; Video=F5 using FractInt 2099.8
  reset=2099 type=mandel passes=t
  center-mag=+0.29124525926602574/-0.01530508041716197/3112.83
  params=0/0 float=y inside=0 colors=000www<253>www
  }

test_03            { ;  (c) Paul N. Lee -- Apr 13, 2007 - 02:24:10
                     ; time=  0:00:00.71 on a PIII-700 at 640x480
                     ; Video=F5 using FractInt 2099.8
  reset=2099 type=mandel passes=t
  center-mag=+0.29130558810737911/-0.01519509048573419/18097.85
  params=0/0 float=y inside=0 colors=www000<253>000
  }

test_04            { ;  (c) Paul N. Lee -- Apr 13, 2007 - 02:24:10
                     ; time=  0:00:00.71 on a PIII-700 at 640x480
                     ; Video=F5 using FractInt 2099.8
  reset=2099 type=mandel passes=t
  center-mag=+0.29130558810737911/-0.01519509048573419/18097.85
  params=0/0 float=y inside=0 colors=000www<253>www
  }

 (http://www.Nahee.com/Fractals/FractInt/Images/fract001.gif)

 (http://www.Nahee.com/Fractals/FractInt/Images/fract002.gif)
 
 

Mr. Lee,

I use a Mac, and the Mac version of FracInt is so out of date that it won't launch on my computer (It is an old "classic" OS 9 application.) Thus I can't use your PAR and MAP files.

In any case, the images you posted look about like what I get using my program.

The black and white images from "The Beauty of Fractals" are 1 bit images, not grayscale. they show a very crisp image of the shape of the fractal, in a way I can't duplicate. They show texture across a range of iteration values. I can't figure out how they are assigning black or white to each pixel in the image. It is not as simple as picking an iteration threshold.

Here's my attempt at map 43, from page 85 of the book:
 (http://upload.pbase.com/image/77096175.jpg)
 http://upload.pbase.com/image/77096175 (http://upload.pbase.com/image/77096175)
(click the picture to see the original version on pbase, including plot coordinates)

And here is a photograph of the image from the book:

(http://upload.pbase.com/image/77097006.jpg)

Note how my image has black "blobs" in it where I chose my iteration cutoff. By contrast, the image from B of F shows the features of the fractal very well, and has detail from a wide range of iteration values.

They look like inverse Julia images, wherein the iteration uses the inverse of the Julia calculation and the orbits settle on the fractal boundary of the Julia set.

Kerry

Maybe it has something to do with the 'Distance Estimation Method' they use? (Just a guess)
But things like 'moderate number of iterations' and 'high resolution' also come to mind when I look at those images. I could imagine that certain very high resolution paperwhite monitors could produce such an effect...
Just some thoughts though...  :)

Regards,
Stijn Wolters (stijnw@funiter.org , http://www.funiter.org/)

They are definitely Mandelbrot set plots. Is the inverse iteration method applicable to Mandelbrot sets?



Duncan C

I think Stijn is correct - the image was produced using Distance Estimation rather than plain iteration colouring - black and white - black only when the points are within a given distance estimate of the "inside" i.e. when the calculated distance estimation value is less than a given value.
(Also "inside" is black)

A quick look at the code in "The Science of Fractal Images" for the "Distance Estimator Method for Mandelbrot set" reveals a matrix with only the values '0' and '1' assigned to it, so they don't seem to use grayscale.

I think it has to do with the prints, a combination of 'more details' caused by the "DEM/M" and a very 'fine' grid of pixels, that way it can look like grey when a black and a white pixel are directly adjacent to eachother (dithering effect).

Regards,
Stijn Wolters.

Stijn,

I managed to find my copy of "The Science of Fractal Images" (S of F I for short).  Sure enough, they state specifcially that they use their distance estimator method DEM to create these black and white plots. Thanks for the tip.

One question I have: How do the results for the DEM method differ from other methods that take the log-log of the last Z value (with other adjustments.) See this link (http://linas.org/art-gallery/escape/smooth.html/original) for a discussion of this method.

Obviously, the DEM method in S of F I is written to give binary "near" or "far" values, and the fractional distance method from the link on smooth shading is not. What about the underlying math, however?

I don't have enough advanced math under my belt to fully grasp this stuff.

Recording all the iteration values and then running a huge differential equation on them seems like a lot of work for each pixel, particularly for high "bailout" (or max iteration) values. My app supports a 64k bailout value. I'd need a megabyte buffer to store the iteration values (2 doubles / iteration * 64k iterations = 2 * 16 * 64k) = 1 megabyte. Plus my app is multithreaded, and each compute thead would need it's own iteration value buffer.


Duncan C

Hi Duncan,

The key to distance estimation is what I call the "running derivative", here's how the default (Mandelbrot) Dist. Est. formula for Ultrafractal works:

For the entire fractal compute pm1 = p-1 and ip = 1/p where p is the power (estimated rate of divergence)

Before iterating (i.e. per-pixel) initialise a complex variable dz to (0,0)

At the end of each iteration compute the running derivative:
  dz = dz*p*(z^pm1) + 1

After bailout use something like:
  Dist. Est. = (p*log(cabs(z))*cabs(z)/cabs(dz))^ip

For a Julia Set initialise dz to (1,0) and omit the +1 in the iteration calculation.

The above method is a simplification of the original Distance Estimation by Hart for which I don't have a direct reference to hand - I think it's available as a PDF on the net.

Note that both Mandelbrot and Julia versions work better with higher bailouts - typically >65536 or so.

David,

I'm getting ready to implement the Distance Estimator Method (DEM) for Mandelbrot and Julia sets. I found the section in "The Science of Fractal images" that describes this method. I had forgotten that dz, the derivative, is a complex number. The section in "The Science of Fractal images" that covers DEM for Mandelbrots (DEM/M) says to initialize dz to zero. Your post says to initialize dz to 1+0i, which is really a better description of the setup. Thanks for pointing that out.

Does UltraFractal support generating 3D plots using DEM? If so, can you point me to some sample 3D Mandelbrot or Julia images using DEM for the height value?


Duncan C.

I've taken a first stab at implementing the Distance Estimator Method (DEM) documented in The Science of Fractal Images.

I still can't get the crisply defined shapes that the authors do, but I'm getting closer.

The image below was generated at 1400 x 1400 pixels, then downsampled to 750x750, and contrast adjusted. This improves the look of the image greatly.


Duncan C
(http://www.pbase.com/duncanc/image/80283308/original.jpg)

You could do that in Ultrafractal but I'm not sure if anyone has done so yet.

The main way I've used DEM is to get the solid boundary when rendering fully-3D Julibrots, Quaternions and Hypercomplex fractals - using DEM for the solid boudary works far better than using the smooth iteration value for this.

For heightfields you might also like to try producing them from orbit trap values to get a completely different view.

David,

I've googled "estimated rate of divergence" and found all kinds of unrelated stuff, by inserting "fractal" into the search, All I came up with is this thread in this forum.

.......  How do I estimate the rate of divergence?

(In particular I'm playing around with 3D Quaternions)

Thanks

The estimated rate of divergence is usually provided/estimated by the user in Ultrafractal formulas i.e. the formula author provides a user-parameter that can be set by the user so they can tweak until a suitable value is found.

For a normal z^n+c formula the estimated rate of divergence is n and in fact for a*z^n + b*z^(n-1)+c*z^(n-2)+...+const it will also be approcimately n but for more complex formulas involving higher functions or conditional calculations it's not so straightforward to estimate.
The problem with the value required for the DEM calculation is that you need to know it prior to iterating which means it can only really be estimated however normal smooth iteration calcuilation also involves the estimated degree of divergence and in that case we can actually calculate a value as log(cabs(final z))/log(cabs(penultimate z)) where final z is the bailed out value - actually you don't need to do the full cabs() calculation, the result is the same if you don't calculate the two square roots.

I should have made clear that in the context of the DEM calculation my mentioning of the estimated degree of divergence only really applies to formulas like z^n+c - the generic DEM calculation is actually:

Before iterating (i.e. per-pixel) initialise a complex variable dz to (0,0)

At the end of each iteration compute the running derivative:
  dz = dz*f'(z) + 1.0

After bailout use something like:
  Dist. Est. = (p*log(cabs(z))*cabs(z)/cabs(dz))^ip
(where ip is 1/estimated divergence which could be calculated here using the method I mentioned for smooth iteration in my previous post)

For a Julia Set initialise dz to (1,0) and omit the +1 in the iteration calculation.

Where f(z) is the iterated formula and f'(z) is its derivative.

The above should work in Quaternion form as well as Complex.

not quite ;) sqrt(x)/sqrt(y) doesn't give the same result as x/y (sqrt is nonlinear), but from the laws of exponents you can shave off one sqrt: sqrt(x/y)

edit: and that final sqrt you can pull out of the log via some log-identities, which i've mentioned in another thread somewhere.

i may have linked this elsewhere, but i'm pretty sure you'll find this interesting (the power of the gpu) and useful ("zealously commented" source code): http://graphics.cs.uiuc.edu/svn/kcrane/web/project_qjulia.html

No, it does give the same result - the calculation for the rate of divergence is not log(sqrt(a)/sqrt(b)) but log(sqrt(a))/log(sqrt(b)) which is exactly the same as log(a)/log(b) :-)

Is the value your calculating above the DEM or the value of p?

This above is just for the value of p - the benefit of using this value rather than a fixed estiimate is that for some formulas (e.g. standard lambda, nova/halley etc.) the rate of divergence varies from one pixel to another in the fractal and of course for others e.g. involving conditionals, transcendentals etc. the "correct" value is simply very hard to guess/tweak and this calculated value takes that necessity away from the fractal artist.

ah whoops, trust me to go simplifying the wrong equation ;) done that way too often in exams as well... careless!

Duh !
Actually ignore the above for the calculation of ip - the value of ip used here should be fixed for the entire fractal but variable based on any parameter changes to the formula that change the overall divergence provided that the true derivative of the main formula is used in the iterative DEM calculation.

Having said that I'll just add that using the calculated divergence at bailout as I've described is great for smooth iteration colouring - in addition to what I've already mentioned (non uniform divergence across a fractal and difficult to specify divergence) calculating the value also gets you smooth iteration colouring with smaller bailouts than is normally the case for instance it produces smooth iteration colouring on the standard Mandelbrot with x^2+y^2<4.

Ok....  now I'm lost    ???

I can calulate the value of p by pixel after the iterations are complete with...
p =  log(cabs(final z))/log(cabs(penultimate z));

pm1 = p-1;
ip    = 1/p;

DistEst =  (p*log(cabs(z))*cabs(z)/cabs(dz))^ip;

dz is initialized to [0,0];

At each iteration dz = dz*p*(z^pm1) + 1;

What I can't figure out is what value to use for p to iterate dz inside the iteration loop?

It's not working, but Here's what I've gor so far in Fractorama.....
I may try it in ChaosPro tonight

formula
   {
   $maxcount = 1000;
   z=current;
   zOld = z;
   w=[real(z),imag(z)];
   c= [0.33,-0.52];
   dz=[0,0];

   z=(z*z)+w;
   $p = 1.5625;
   $pm1 = $p-1;
   $ip = 1/$p;
   while ($count < $maxcount && magnitude(z)<4)
      {
      zOld = z;
      z=(z*z)+c;
      $p = (log(magnitude(z))/log(magnitude(zOld)));
      $pm1 = $p-1;
      dz = dz*$p*(z^$pm1) + 1;
      }

   $ip = 1/$p;
   $distEst = ($p*log(magnitude(z))*magnitude(z)/magnitude(dz))^$ip;

      set_color
         (
         $distEst
         );
   }

Hi all,

Sorry - I obviously confused everyone by mentioning that you can calculate the degree of divergence - it can only be calculated at the end i.e.
The calculation for the degree of divergence,

p = log(cabs(final z))/log(cabs(penultimate z))

Only works for the bailout (last) iteration where you're using final z and penultimate z, itr does not work with z and zold on any earlier iterations.

For z^2+c you should use p=2, pm1=1 and ip = 0.5 all fixed for the whole fractal, that holds for any z^p + c fractal eg. for z^3+c then p=3, pm1=2 and ip=0.3333333

For a general fractal z = f(z) then on each iteration you calculate:

dz = dz*f'(z) + 1.0

where f'(z) is the derivative of f(z)

and in the final calculation after bailout the ip value needs to be the inverse of the estimated divergence - again probably best using a fixed value for the whole fractal.

Much of the math in these posts is over my head.  But I did spend quite a bit of time generating my own Mandelbrot images some years ago, using BASIC.  I assigned a pair of colors to each failure range, so that every single failure value got a unique space on the map.  Higher failure values had different color codes than lower, so I could see section by section how long it took each point to fail. 

If I were to use this approach simply with black and white, I could switch back and forth between black and white for every single failure value, and then when I was completely in, or completely out at a very low setting, I could use a constant color.  If I did that, I'd create a look not unlike the one shown early in this thread. 

I will say that in the 14 color scheme available to me in 1990, when I ran most of my fractals, I ended up with maps that looked like intertwined intestines.  Sometimes there's such a thing as knowing too much.

Greetings and welcome to this particular Forum !!      :)

One can never know too much.     ;)

You mean like this?
(http://www.pbase.com/duncanc/image/74926337/original.jpg)

I'm finally generating DEM (Distance Estimate Method) based images that I'm happy with. It turns out that my code had a couple of bugs in it.

The new code runs reasonably fast, even with all the extra math to compute distance estimates.

The algorithm in S of F I ("The Science of Fractal Images" uses a sharp cut-off from white to black when pixels get close enough to the set, but I find this makes for jagged looking plots. I've implemented a non-linear color gradient that works pretty well.

For pixels where their DE value is  threshold>=DE>=0, I scale the value of DE to 1>=DE>=0, then do the calculation:
    gradient_value = 1 - (1-DE)^n,     ("^n" means to the n power. I wish I could use superscripts!)

"n" is an adjustment factor that lets me change the shape of the gradient curve.

The value "gradient_value" determines the color of the pixel. If it's 0, the pixel is colored at the starting color (white, for a B&W plot.) If "gradient_value" is 1, the pixel gets the end color (e.g. black)

For values of n>1, this gives a rapid change in color for pixels that are far from the set, and a slower change in value as DE approaches 0.

For values of n<1, it gives a slow color change for pixels far from the set, and rapid change close to the set. For n=1, I get a linear color gradient.

The non-linear gradient lets me use the DE value to anti-alias my plots. By adjusting my threshold value and my adjustment value, I can get good looking results for a variety of images.

Here is my latest version of the sample image from "The Beauty of Fractals":

(http://www.pbase.com/duncanc/image/91202738/original.jpg)

And here are a couple of other images where I really like the lacy effect I get from DEM (the distance estimator method):


(http://www.pbase.com/duncanc/image/91485524/original.jpg)

(http://www.pbase.com/duncanc/image/91190108/original.jpg)


My app stores the DE value of each pixels, and does the color assignments at display time. This means that you can tweak the color values and get different looks without having to re-calculate the fractal.


Duncan C