Talk:Fractal flame

Editor

Why is Scott Draves (Spot) editing an article about his own project? This is blatant shameless self-promotion and hawking of wares in violation of Wikipedia's NPOV.--Editor5435 (talk) 03:00, 7 March 2008 (UTC)

Why are you complaining about an editor who has edited a page you clearly act as if you own? (Fractal Compression) You should stick to your knitting and don't go causing trouble for other people. Spot's edits to this page are very much in the minority. RussNelson (talk) 04:28, 11 March 2008 (UTC)

Not advertising, but a valid algorithm

I don't agree with Editor5435; fractal flames are, as far as I am aware, a type of mathematical algorithm that "belong" to math and not any one person. I don't think Scott Draves should be editing his own article, but his applications don't seem to be aggressively advocated or advertised, and with some points on the weaknesses of the algorithm (for which some kind of expert is necessary), the article would have a NPOV. I think editing is the solution, not deletion. Notostraca (talk) 18:56, 10 March 2008 (UTC)

As far as I am aware from the available literature, Scott Draves invented fractal flames, wrote the algorithm and the source code. The authoritative document was (and this makes sense) written by him and is located here: [1]. However, he doesn't "own" them as the application is open source. Draves should welcome educated comments on algorithm and code from authorities on the topic, as his entire career is founded on open-source and collaborative principles (just like Wikipedia itself!).

Fractal Flames have been incorporated into several subsequent graphics programs, including a photoshop plugin (see http://www.andrewdavidson.com/aeflame/AEFlame.txt):

"DOES A VERSION OF AEFLAME EXIST AS A PHOTOSHOP PLUGIN? HEY, ISN'T THIS THE SAME THING AS THAT FRACTAL FILTER IN KPT 5?"

"AEFlame is based on flame GNU source code written by Scott Draves. Scott rewrote flame for inclusion in Kai's Power Tools 5, a PhotoShop plugin set for Mac and Windows that also includes many more plugins than just flame. It is called "FraxFlame" in KPT5. The renderings in AEFlame and FraxFlame are very similar because they are based on the same core concepts."

It doesn't make sense to me that notability should be in question here; the only POV I see is that flames are arguably "more beautiful" when rendered a certain way which is purely subjective opinion and should probably be deleted; I don't understand which part of it "reads like an advertisement"; and I think the person who posted complaints about this article has an axe to grind against Draves for personal reasons and therefore may not be looking at the community's best interests in his comments about articles related to Draves. Thank you, Isabelwh--Isabelwh (talk) 16:54, 11 March 2008 (UTC)

The code wasn't rewritten for KPT it was relicensed. At that time nobody had yet contributed so I had the copyright on the whole source and was able to license it for proprietary use. Spot (talk) 09:40, 12 March 2008 (UTC)

"Created in"

it's debatable if flames are created or discovered i think to avoid this, the term "rendered" should be used any thoughts? 212.56.120.244 (talk) 11:55, 4 June 2008 (UTC)

there are several uses of the the word "create" in the article and i'm not sure which ones you mean, but to me, "render" refers to solving the equation and generating an image output. But the flame must also be designed, the equation parameters picked. This is why the word "create" is used, because it subsumes all of these in a generic way. "discover" is an interesting alternative for the design part of the process, and i think it warrants at least a sentance or two of explanation. Spot (talk) 20:03, 8 June 2008 (UTC)

Two penn'orth

• I think that "Draves' seminal open-source code was later ported" contains a peacock term: I would suggest original.
• Would someone like to fix the repeated reference please? Richard Pinch (talk) 19:13, 15 July 2008 (UTC)

Problem with the math

My problem is there is none, or at the verry least only a little vague bath at the beginning. The original three pieces of math at the time of writing are: Non-linear functions are iterated; such as the mandelbrot. Log density display, sounds like brightness control. Colour by structure, intriguing, but vague. These should be clarified and added to. 68.144.80.168 (talk) 02:22, 4 November 2008 (UTC)

this can provide some clarity, hopefully to be edited into the article: 1) this statement contrasts flames with IFS fractals, which had generally been done with affine functions. mandlebrot is in a different category (escape-time fractals). 2) yup, tone mapping is about brightness. in the case of flames, the brightness is proportional to the log of the density of the particles in each pixel. 3) color by structure distinguishes flames from color by density. the iteration takes place with an extra coordinate, which is then indexed into a palette to determine particle color. As a result, colors are assigned to structural components and are coherent under animation, ie changing the functions. Spot (talk) 20:30, 24 February 2009 (UTC)

Could I make flame fractal animation of turning one proper fractal into other like these fractal animation Apophisys have better visualisation Edo 555 (talk) 15:57, 12 September 2010 (UTC)

Pseudocode for the computation loop

Here is some pseudocode for the computing algorithm in latex that I don't have the time to wikify. Help appreciated!

\begin{algorithm}
\caption{Generates the dataarray for the fractal}
\begin{algorithmic}[1]
\REQUIRE $F_1,F_2,\dots,F_n$ are flamefunctions.
\REQUIRE $Fs_1,Fs_2,\dots,Fs_n$ are the colorweight of the flamefunctions.
\REQUIRE $Fc_1,Fc_2,\dots,Fc_n$ are the colorindexes of the flamefunctions.
\STATE $z \gets 0$
\WHILE {number of iterations $\leq$ max iterations}
	\STATE
	\STATE \COMMENT{Choose according to their probabilities}
	\STATE $i \gets$ random integer in $[1\dots n]$
	\STATE
	\STATE \COMMENT{Apply the flame function $i$ on $z$}
	\STATE $z \gets F_i(z)$ 
	\STATE
	\STATE \COMMENT{Update colorindex for $z$}
	\STATE $z_{c} \gets z_c(1-Fs_i) + s_i \cdot Fc_i$ 

	\STATE $w \gets Posttransform(z)$

	\IF {$w$ is within bounds of the fractal}
		\STATE
		\STATE \COMMENT{Convert $w$ to arraycoords}
		\STATE $x \gets FromWorldCoordToArrayCoord(w)$ 
		\IF {$x$ is within bounds of $A$}
			\STATE
			\STATE \COMMENT{Update $A[x]$ with the color associated to $F_i$}
			\STATE $A[x]_{red} \gets A[x]_{red} + Gradient(z_{c})_{red}$ 
			\STATE $A[x]_{green} \gets A[x]_{green} + Gradient(z_{c})_{green}$
			\STATE $A[x]_{blue} \gets A[x]_{blue} + Gradient(z_{c})_{blue}$ 
			\STATE $A[x]_{frequency} \gets A[x]_{frequency} + 1$
		\ENDIF
	\ELSE
		\STATE $z \gets $ random point
	\ENDIF
\ENDWHILE
\RETURN $A$
\end{algorithmic}
\end{algorithm}

Paxinum (talk) 20:24, 10 October 2009 (UTC)