Fuzz

[HazardHarry]

I can't imagine I'm the first person to come up with this, but I haven't seen it used outside of my own program yet. Basically, the idea is to introduce a bit of randomness to the output of your function with every iteration. As the randomness piles up, areas of the image that require high iteration counts become blurrier than areas of low iteration counts. This results in a pseudo-"depth-of-field" effect.

The following example code is written in Java. There's not much to it. Basically it just randomly "jiggles" the value of the incoming complex number by an amount based on the maxRealDistance and maxImageDistance parameters.

Code:

static Complex fuzz(Complex in, double maxRealDistance, double maxImagDistance) {

	Complex out = in;
	double random;

	//Real modifier
	random = Math.random();
	if(random < 0.5) {
		random = Math.random() * maxRealDistance;
		out.real -= random;
	} else {
		random = Math.random() * maxRealDistance;
		out.real += random;
	}

	//Imaginary modifier
	random = Math.random();
	if(random < 0.5) {
		random = Math.random() * maxImagDistance;
		out.imag -= random;
	} else {
		random = Math.random() * maxImagDistance;
		out.imag += random;
	}

	return out;
}

Original:


Fuzzed:

[lycium]

This kind of transform is quite common in IFS (flam3, Apophysis, Chaotica, JWildfire etc) but I haven't seen it used in escape time fractals so far. Which are you using here?

[HazardHarry]

It's an escape time fractal in a program I wrote myself. It's something I hope to release in the future, but at the moment it needs some more user-friendly accommodations, haha.

Specifically, here's the function I used:

Original code:

Code:

result = Complex.swap((u.sub(new Complex( Math.log(z.magnitude()), z.newArg() + (3 * Math.PI) / 2 ))).div(z).pow(new Complex(1, -2)));

Fuzz code:

Code:

result = Complex.fuzz(Complex.swap((u.sub(new Complex( Math.log(z.mod()), z.newArg() + (3 * Math.PI) / 2 ))).div(z).pow(new Complex(1, -2))), 0.01, 0.01);

"u" is the complex constant. In this case it's equal to 0+7.142857142857146i.

The "escape" occurs when |z| > 100.

There are a couple of functions there I should take note of:

The swap function swaps the real and imaginary components of the number inside of it.

Code:

static Complex swap(Complex in) {
	return new Complex(in.imag, in.real);
}

"newArg" is only "new" in the context of my own program. The old "arg" function I had worked differently.

Code:

private static double halfPi = Math.PI / 2;
private static double pi = Math.PI;
private static double threeHalfPi = 3 * Math.PI / 2;
public double newArg() {
	double out = 0;

	//out = Math.atan( this.getImag() / this.getReal() );
	if(this.imag == 0 && this.real == 0) {
		out = 0;
	} else if(this.imag == 0) {
		if(real > 0) {
			out = 0;
		} else {
			out = pi;
		}
	} else if(this.real == 0) {
		if(imag > 0) {
			out = halfPi;
		} else {
			out = threeHalfPi;
		}
	} else if(this.imag > 0 && this.real > 0) {
		out = Math.atan( this.getImag() / this.getReal() );

	} else if(this.imag > 0 && this.real < 0) {
		//out = Math.atan( this.getImag() / Math.abs(this.getReal()) ) + halfPi;
		out = Math.atan( Math.abs(this.getReal()) / this.getImag() ) + halfPi;

	} else if(this.imag < 0 && this.real < 0) {
		out = Math.atan( Math.abs(this.getImag()) / Math.abs(this.getReal()) ) + pi;
		} else if(this.imag < 0 && this.real > 0) {
		out = Math.atan( this.getReal() / Math.abs(this.getImag()) ) + threeHalfPi;

	}

	return out;
}

[lycium]

I see. Java is a bit of an unfortunate choice for a graphics application (performance and memory issues), but I guess it can be ok.

BTW, you seem to have a ton of code to handle special cases of cartesian -> polar angle conversion; have a look at Math.atan2(y, x) method

Also, random TeX tip: escape your functions, eg "<slash>ln" (replace <slash> with an actual slash, the forum seems to eat slashes atmo) not "ln".

[HazardHarry]

Yeah, Java's not great for extremely high iteration counts, so deep zooms are typically a no-go. That said, there's a lot of interesting things you can do with fractals without needing to do much zooming at all.

Side benefit: Keeping it in Java keeps me on my toes. I've got to make as many optimizations as possible to make sure it doesn't take 8 years to render a single image. XD One day I'll port it all to a faster language. For now though I'm happy to just keep it as is.

Thanks for the atan2 and LaTeX tips!