Title: Requesting clarifications on the fractal flame algorithm Post by: Sigillum Militum on March 31, 2012, 12:34:33 PM 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. Quote 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 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. 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. Quote 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 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 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'] ...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 Title: Re: Requesting clarifications on the fractal flame algorithm Post by: cKleinhuis on March 31, 2012, 12:49:53 PM 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 Quote dude, lols, dont be so angry, it is just a definition ... 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. 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.... Title: Re: Requesting clarifications on the fractal flame algorithm Post by: DarkBeam on March 31, 2012, 12:59:12 PM 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 :yes: :yes: :yes: 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... ;D Title: Re: Requesting clarifications on the fractal flame algorithm Post by: Sigillum Militum on March 31, 2012, 01:09:43 PM dude, lols, dont be so angry, it is just a definition ... (http://29.media.tumblr.com/tumblr_lmm3edWoLK1qh55zko1_400.jpg) 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. :yes: :yes: :yes: 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... ;D Cool, thanks. How about the other stuff? Title: Re: Requesting clarifications on the fractal flame algorithm Post by: DarkBeam on March 31, 2012, 04:34:29 PM Be patient, we are not the truth keepers :)
Title: Re: Requesting clarifications on the fractal flame algorithm Post by: Sigillum Militum on March 31, 2012, 04:51:31 PM Well ... have you written fractal flame code?
Title: Re: Requesting clarifications on the fractal flame algorithm Post by: David Makin on April 01, 2012, 03:04:53 PM 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. |