Jump to content

Talk:Fractal flame

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Editor

[edit]

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)[reply]

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)[reply]

Not advertising, but a valid algorithm

[edit]

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)[reply]

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)[reply]

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)[reply]

"Created in"

[edit]

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)[reply]

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)[reply]

Two penn'orth

[edit]

Problem with the math

[edit]

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)[reply]

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)[reply]

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)[reply]

Pseudocode for the computation loop

[edit]

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)[reply]

Software info

[edit]

The info about rendering software was removed, without motivation. Hence, I did restore it. I claim that that section belongs to this page, compare with other pages describing algorithms; Object-oriented_programming, Face-recognition, Mp3, where different programs implementing the algorithm are mentioned.

Yes, the section certainly should be improved upon, if we remove every flawed section from Wikipedia, there would be nothing left. Paxinum (talk) 18:06, 10 June 2011 (UTC)[reply]

I believe there are at least a few more tools in existence (which create, modify and render fractal flames) than what the article lists. I'm pretty sure that could be expanded. --RichardAlexanderHall (talk) 01:35, 18 December 2018 (UTC)[reply]

Lots of stuff deleted without comment

[edit]

I am a bit frustrated that a bunch of info (comparison with other algorithms, etc), was deleted, as well as differences between implementations. The flame algorithm is NOT equivalent to the flam3 implementation! If flam3 needs special attention, put it in a separate article, similar to Apophysis.

89.233.225.53 (talk) 20:42, 1 June 2012 (UTC)[reply]

[edit]

Hello fellow Wikipedians,

I have just modified one external link on Fractal flame. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 15:19, 22 January 2018 (UTC)[reply]

— Preceding unsigned comment added by 41.115.55.178 (talk) 03:42, 3 August 2020 (UTC)[reply]

why eliminate pixels that only appear once ?

[edit]

calculation of alpha does not seem right. since log(1) = 0, and alpha for pixels occuring only once, are being eliminated (alpha = 0). is this correct ? — Preceding unsigned comment added by 41.115.55.178 (talk) 03:50, 3 August 2020 (UTC)[reply]

The initial points that get orbited are typically chosen randomly, so if you make buckets that are only visited once or twice a color that's distinguishable from the buckets that are visited 0 times, you end up amplifying noise. Any buckets that represent actual orbits will be visited many times, so there's no significant information loss from doing this. — Preceding unsigned comment added by 50.58.96.2 (talk) 17:55, 4 August 2020 (UTC)[reply]