Question on "light source consistency" (retry)

[devijvers]

Hey,

This is my first post on fractal forums. I’ve observed a fractal result as shown in the attached images. I call it “light source consistency” although maybe there’s another name for it.

My question is: can this observation be linked to particular mathematical theories, or can it be explained in other ways?

For your information, I list the color calculation code below (Java):

Code:

public void forPixel(final int x, final int y, final ComplexNumber z0) {
	ComplexNumber z = z0;
	int t = 0;
	for (; t < MAX; t++) { // MAX = 200
		if (z.abs() > 2.0) break;
		z = z.times(z).plus(z0);
	}
	final int colorValue = MAX - t;

	raster.setPixel(x, y, new int[] {
				colorValue,
				(colorValue != 0) ? (((int)(z.abs() * 128)) % 255) | 0x90 : colorValue, // light source consistency
				(colorValue != 0) ? MAX : colorValue});
}

Thanks

Steven

[cKleinhuis]

what is your question ?!

[devijvers]

what is your question ?!

I'm rephrasing my question, trying to be precise and I can:

On the images you see coloring features that appear to be raytraced as in tracing light originating from a light source bouncing on a pixel to the imaged eye of an observer. How can these features in this fractal be explained mathematically?

[cKleinhuis]

what do you mean ? i only see bands of iterations, and current iteration complex value used for coloring

[devijvers]

what do you mean ? i only see bands of iterations, and current iteration complex value used for coloring

Where can I learn more about "bands of iterations"?

[Nahee_Enterprises]

Hey,
This is my first post on fractal forums.   ......
My question is: can this observation be linked to particular mathematical theories,
or can it be explained in other ways?

Greetings, and Welcome to this particular Forum !!!    

The images appear to show iteration banding with a limited color palette.
 

[Nahee_Enterprises]

Where can I learn more about "bands of iterations"?

I know where such things are discussed in the FractInt manual, which I am more familiar with:

  http://www.Nahee.com/spanky/www/fractint/frm-tut/frm-tutor.html
  http://www.Nahee.com/spanky/www/fractint/append_a_misc.html
  http://www.Nahee.com/spanky/www/fractint/contin_pot.html
  http://www.Nahee.com/spanky/www/fractint/bif_type.html
  http://www.Nahee.com/spanky/www/fractint/commands.html
 

[cKleinhuis]

so, usually u give a certain iteration a color, in your case it is variable "t"


(((int)(z.abs() * 128)) % 255) | 0x90
you are assuming, that the value is below 2, hence you are multipliying it by 128 to map it to full 255 colors ...
if you wanna play a litte, try using abs(z.real) or, abs(z.imag) to examine results

but with lighting it hasnt really anything to do ..

[Timeroot]

It's not really mapping to the full 255 colors, because he's just taking the integer part. That's why you get the banding within the bands.

Never mind, first he's multiplying, I see... it's the XOR that's giving the banding, I guess. What made you pick XOR 0x90? Why not some number like A0, or 50?

Wait, no, I see... you wanted the 8 bands in each "big" iteration band, and you wanted it to be greater than 128 so that it wouldn't be overly bright. Clever.

If you want something with a bit more interesting, you could try (colorValue!=0)? t%255 : colorValue for the blue component. When you put something like MAX in, it leaves the whole picture looking somewhat monotonic...

I agree with Trifox, though, that this doesn't have anything much to due with lighting. I see what you mean, though, that on the outsides of the bands it looks like it's reflecting something, and the whole thing is an elevated hump. This is quite simply due to the fact that in the green component, it grows approximately the same as the z.abs() does. And the farther that the pixel is away from the set, the greater its absolute value will be. So farther = more green = brighter coloring.

Hope that answers your question!