Welcome to Fractal Forums

Hi, I've been programming various Mandelbrot related fractals, and I am particularly interested in the Buddhabrot. I have successfully got it working, however the result is fairly grainy and not smooth like it is in every image I've seen it.
http://dl.dropbox.com/u/16319566/buddhabrot.png (http://dl.dropbox.com/u/16319566/buddhabrot.png)

That is with 10000 iterations. The graininess is worse with lower iterations. I am colouring simply based on 255*count[ x ][ y ]/maxCount to get a grayscale.

Any advice would be appreciated.

Thanks.

The Buddhabrot method is notorious for needing a long time to resolve.  Have patience is the best advice.

This may help speed ups if you haven't seen it before
http://www.steckles.com/buddha/

Jason.

It looks perfectly normal to me (and i generated thousands of buddhabrot  ;D ).

non-grainy buddhabrot can be created, it require a lot of parameters tweaking and many many hours of cpu time.
In my humble opinion, the grain is part of the buddhabrot and it's not a sign of "bad quality".
You'll have the same problem with millions of iteration :)

Ah, so what sorts of tweaks are to be done? I have no idea how to improve my current method.

How long does a nice looking (non-grainy) buddhabrot usually take to render?

Thanks.

for smoother grain. you can use sqrt, to strengthen (is it the right english world?) the low iteration point, and weaken high iteration point.

Please take a look at : https://github.com/ker2x/WinBuddhaOpenCL/blob/master/WinBuddhaOpenCL/BuddhaForm.cs

if you want a better contropl on lightness/contrast, take a look at :
https://github.com/emmmile/buddha/blob/master/buddha.cpp

less contrast -> less grain

Also, it usually require some hours of cpu time and a good random number generator :)

ok, i stop spamming and compile a few commons techniques for better rendering of buddhabrot :)

- You want a low contrast between low iteration point and high iteration point.
- you can use something like sqrt (or log) mapping to weaken high iteration point, or use usual graphic formula to control lightness/contrast/histogram
- you may want to ignore the first iterations of the point you're plotting. eg : instead of plotting from 1 to 100 iteration, you can try something like 50 to 100.
- zoomed buddhabrot are generally nicer and smoother. it's not the usual mandelbrot rendering, a lot of point that are not part of the M-Set are orbiting inside the MSet before escaping.
- the metropolis hastings algorithm is working very well for deep zooming
- green dominated buddhabrot look very dirty (ewww), you may want to weaken the green color. blue are nice but very dark. (blame the human eye which is very sensible in the green wavelength)

About coloured buddhabroth : the usual technic is to have 1 color per iteration
eg :
red min->max : 100->200
green min->max- : 200->300
blue min->max : 300->400

it works well. but you need to be carefull that you will usualy have much more point in the low iteration range than the high one. (in the exemple above, the rendering will be dominated by the red color)

you can also hava gap between colors :
red : 100->200
green : 300 -> 400
blue : 500->600
in the exemple, the ranges below 100, the 200->300, the 400->500 iteration will not be rendered (no color assigned).

you can have overlapping range :
red : 100->1000
green : 250->1000
blue : 500->1000

in this case you will end up with a buddhabroth dominated by black and white. (eg : the 750th iteration will be red + green + blue -> white)

you can "clamp" the points count. (eg : all points above 255 are equal 255. and you divide by 255 instead of "maxCount"). you will have some some kinf of "burned photo" effect.

here is an exemple of buddha generated by buddha++ while i was typing this.
- 6 hours of cpu time
- red : 100 -> 200
- green : 300 -> 400
- blue : 500 -> 600
- magnification : 3750
- location : -0.665000000000000 x 0.580000000000000

original size is : 1920x1005 (open the picture in a new windows, you'll see it with the original size, the forum is limiting the size)

(http://fractals.s3.amazonaws.com/buddhabrot/buddha-blueish.png)

Thanks for your help. I don't fully follow everything you posted, but I have tried the square root idea, which has improved my Buddhabrot a bit:
http://dl.dropbox.com/u/16319566/buddhabrotsqrt.png (http://dl.dropbox.com/u/16319566/buddhabrotsqrt.png)

is it possible to see the source code ? :)

Another technique with Buddhabrot (and similar type images) is to generate several different copies of the same basic image, each with a different value of the random-number-generator seed, and then average together all of the layers.

It's written in Java. I've pasted all of the relevant code (I think).
http://dl.dropbox.com/u/16319566/BuddhabrotCode.txt (http://dl.dropbox.com/u/16319566/BuddhabrotCode.txt)

I should add that I'm actually not using the random approach for picking z, although that shouldn't matter when I'm iterating over every point anyway?

That's what i suspected. It's really important !
You draw only 1 orbit per pixel, which is not enough, you need millions and millions of orbits !

here is a good starting point to understand why : https://www.fractalus.com/info/antialias.htm

:'<

I can vaguely understand why thinking about it - it makes sense.

So, would I then need more count arrays and then take the average for each count[ x ][ y ]?

EDIT: Actually, I've just confused myself, could you please give me a rough pseudocode style outline of the approach I need to take? Thanks for your help so far.

i understand your problem.

what you seem to do is :

you are limited to width*height potential orbits.

what you want is :

now you have an insane amount of different to draw.
Because many many orbit may start on the same pixel but have totally different orbits.

This is one of the possible solution (we're doing that : http://en.wikipedia.org/wiki/Monte_Carlo_method ) but there is many other possibilities (some are yet to be invented  ;D )

What should my boundaries be for the complex number? Are they the same, but with greater precision/resolution, or do I also need to increase the range?
Thanks.

you can safely choose random complex in thoses boundaries :

realMin = -2.0f;
realMax = 0.75f;
imaginaryMin = -1.5f;
imaginaryMax = 1.5f;

feel free to take a look at : https://github.com/ker2x/Fortran_buddhabrot/blob/master/buddhabrot.f90
and : https://github.com/ker2x/Fortran_buddhabrot/blob/BlackAndWhite/buddhabrot.f90

certainly not the best algorithm but easy to read (even if you don't know fortran)

It was my lack of orbits that was letting me down, you were definitely right.

I've created two images, one with 20 iterations, the other with 256 so far. I used 100 million orbits.
http://dl.dropbox.com/u/16319566/20it.png - took about 40 seconds.
http://dl.dropbox.com/u/16319566/256it.png - took about 4 minutes.

Yay \o/

65 minutes, 1 billion orbits, 512 iterations:
(http://dl.dropbox.com/u/16319566/512it-1boribits.png)

Is this about as good as would be expected given the number of orbits and iterations?

Also, I just tried the Nebulabrot; 4 hours, 2048 iterations, 1 billion orbits:

http://dl.dropbox.com/u/16319566/2048it-1borbits.png

Absolutely :)

Can you try to skip the rendering of the firsts 10 iterations ?
from 10 to 512.

nice :)

When I tried the minimum iterations 'trick', I got this sort of thing:
(http://dl.dropbox.com/u/16319566/minittest.png)
How should I decide the safest minimum iterations to avoid a 'damaged' Buddhabrot?

Hummm... How many iterations ?
And, btw, it doesn't look damaged to me, it looks enhanced :)

I think I made the minimum 1/100 of the maximum but I can't remember exactly. Probably max = 1000, min = 10.

Then it make sense.
A mandelbrot at 10 iteration :