Requesting clarifications on the fractal flame algorithm

[Sigillum Militum]

Here I'm going on the original paper: http://flam3.com/flame.pdf

The flam3 source code is far less clear than I'd like (and appears to implement a lot of tricks not specified in the paper) and Kandid and Apophysis both use it.

The normal algorithm for solving for S is called the chaos game. In pseudocode it is:

Code:

(x, y)= a random point in the bi-unit square
iterate { i = a random integer from 0 to n − 1 inclusive
    (x, y) = F_i(x, y)
    plot(x, y) except during the first 20 iterations
}

Does fractal flame rendition really require you to iterate the transform 20 or so times before you plot the point? With a standard IFS you don't need to do that.

The bi-unit square are those points where x and y are both in [-1,1].

Do I need to make sure points fall within the bi-unit square? I wouldn't think so.

We now generalize this algorithm. The first step is to use a larger class of functions than just affine functions. Start by composing a non-linear function V_j from R^2 to R^2 with the affine functions ...

The non-linear functions are given in the back of the paper. What are some good ways to get affine functions for inside V_j short of evolution?

Would these do e.g.?

http://ecademy.agnesscott.edu/~lriddle/ifskit/gallery/gallery.htm

Are post and final transforms necessary to get decent looking flames? Furthermore the pseudocode for final transforms is unclear.

Code:

(x, y)= a random point in the bi-unit square
iterate { i = a random integer from 0 to n − 1 inclusive
    (x, y) = Fi(x, y)
    (x_f , y_f) = F_final(x, y)
    plot(x_f , y_f) except during the first 20 iterations
}

So, the paper tells me that the final transform is not "in the loop" (apparently meaning that it comes after all the 20 or whatever iterations) but in the pseudocode it seems otherwise.

Regarding colors. We'll assume I want an RGB image. So, assuming I'm reading the paper right, Pythonic code for increment would be like:

Code:

pixel['red'] = (c_i + pixel['red']) / 2
pixel['green'] = (c_i + pixel['green']) / 2
pixel['blue'] = (c_i + pixel['blue']) / 2
pixel['alpha'] += 1

Then, when all iterations are done, and I'm ready to plot the image, for each pixel, I do:

Code:

pixel['red'] = pixel['red'] * math.log(pixel['alpha']) / pixel['alpha']
pixel['green'] = pixel['green'] * math.log(pixel['alpha']) / pixel['alpha']
pixel['blue'] = pixel['blue'] * math.log(pixel['alpha']) / pixel['alpha']

...and then do a linear scale of these values from [0,1] to [0,255], like here e.g. (will be required for both the python prototype I plan on writing and the OCaml final which will output PPM files)

Code:

pixel['red'] = int(255 * pixel['red'])

The thing is, do I also scale alpha? If so, before or after the color channels?

TIA

[cKleinhuis]

hi there, thats alot questions ...

from the start ...

you ommit the first 20 iterations just to get your point on the track ... you plot each iteration, but the starting is most often not in the "real" set that is represented through your set of affine ( or non affine using the so called flame method ... ) transforms ... after 20 iterations you can say, ok now i am on my set that i have defined ... but the 20 is just arbitrary number, could be lower or higher ... as you wish ... the single point does not really affekt the resulting image, but some people feel disturbed by the starting point

Quote
The bi-unit square are those points where x and y are both in [-1,1].

Do I need to make sure points fall within the bi-unit square? I wouldn't think so.

dude, lols, dont be so angry, it is just a definition ...

and the 1 is always a magic number, you can say that a transformation that has determinant bigger than 1 lets your formula explode, because it would scale the value by the amount, and you now, a scale of 2 is very quick growing if you repeat it ... 2*2*2*2*2... so, and when using ifs function you want your transforms to stay below 1, so that your formula is not so likely to explode, and the same rule counts in for negative values, hence the bi-unit square makes a lot sense here....

[DarkBeam]

Are post and final transforms necessary to get decent looking flames? Furthermore the pseudocode for final transforms is unclear.

Code:

(x, y)= a random point in the bi-unit square
iterate { i = a random integer from 0 to n − 1 inclusive
    (x, y) = Fi(x, y)
    (x_f , y_f) = F_final(x, y)
    plot(x_f , y_f) except during the first 20 iterations
}

 

It's absolutely necessary especially for nonlinear stuff, and for placing "fixed" elements correctly like noise and "shaped noise"

Final transform is "less necessary" but cool for an additional effect. Like an artsy look...

[Sigillum Militum]

dude, lols, dont be so angry, it is just a definition ...

and the 1 is always a magic number, you can say that a transformation that has determinant bigger than 1 lets your formula explode, because it would scale the value by the amount, and you now, a scale of 2 is very quick growing if you repeat it ... 2*2*2*2*2... so, and when using ifs function you want your transforms to stay below 1, so that your formula is not so likely to explode, and the same rule counts in for negative values, hence the bi-unit square makes a lot sense here....

When I was plotting the Barnsley fern yesterday to get up to speed on IFSes, on the y-axis, it went as high as 10. But I did get a well-defined fern image at the end. So the points can exceed the bi-unit square without bouncing off into infinity.

It's absolutely necessary especially for nonlinear stuff, and for placing "fixed" elements correctly like noise and "shaped noise"

Final transform is "less necessary" but cool for an additional effect. Like an artsy look...

Cool, thanks. How about the other stuff?

[DarkBeam]

Be patient, we are not the truth keepers

[Sigillum Militum]

Well ... have you written fractal flame code?

[David Makin]

To be honest I don't like that bi-unit square stuff either - all he means is that overall your transforms should *not* be divergent

As to the "final" transform it's included in the loop in that it's applied on every step and the result after it is applied is taken as the location to plot *but* the value passed on to the next iteration is the value prior to application of the final transform - also you can make this final "transform" as complicated as you like and it doesn't even need to obey the contraction/convergent rule.