mirror-github-bspeice/speice.io
1
0
Fork 0
mirror of https://github.com/bspeice/speice.io synced 2024-12-22 08:38:09 -05:00
Code Issues Releases Wiki Activity

First pass proof-reading

Browse Source
This commit is contained in:
Bradlee Speice 2024-12-15 15:55:27 -05:00
parent a05acf6748
commit 1ce6137c17
7 changed files with 132 additions and 118 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
blog/2024-11-15-playing-with-fire/1-introduction/Gasket.tsx
View File

@ -14,7 +14,7 @@ export function Render({f}) {
export default function Gasket({f}) {
return (
<SquareCanvas>
<SquareCanvas name={"gasket"}>
<Render f={f}/>
</SquareCanvas>
)

2
blog/2024-11-15-playing-with-fire/1-introduction/GasketWeighted.tsx
View File

@ -31,7 +31,7 @@ export default function GasketWeighted() {
<>
<div className={styles.inputElement}>
<p><TeX>{title}</TeX>: {weight}</p>
<input type={'range'} min={0} max={1} step={.01} style={{width: '100%', background: 'transparent'}} value={weight}
<input type={'range'} min={0} max={1} step={.01} value={weight}
onInput={e => setWeight(Number(e.currentTarget.value))}/>
</div>
</>

105
blog/2024-11-15-playing-with-fire/1-introduction/index.mdx
View File

@ -7,11 +7,11 @@ tags: []
---
Wikipedia describes fractal flames fractal flames as:
Wikipedia describes [fractal flames](https://en.wikipedia.org/wiki/Fractal_flame) as:
> a member of the iterated function system class of fractals
It's a bit tedious, but technically correct. I choose to think of them a different way: beauty in mathematics.
It's tedious, but technically correct. I choose to think of them a different way: beauty in mathematics.
import isDarkMode from '@site/src/isDarkMode'
import banner from '../banner.png'
@ -22,14 +22,15 @@ import banner from '../banner.png'
<!-- truncate -->
I don't remember exactly when I first learned about fractal flames, but I do remember becoming entranced by the images they created.
I don't remember exactly when I first learned about fractal flames, but I do remember being entranced by the images they created.
I also remember their unique appeal to my young engineering mind; this was an art form I could participate in.
The original [Fractal Flame Algorithm paper](https://flam3.com/flame_draves.pdf) describing their structure was too much
for me to handle at the time (I was ~12 years old), so I was content to play around and enjoy the pictures.
But the desire to understand it stuck around. Now, with a graduate degree under my belt, maybe I can make some progress.
But the desire to understand it stuck around. Now, with a graduate degree under my belt, I want to revisit it
and try to make some progress.
This guide is my attempt to explain fractal flames in a way that younger me &mdash; and others interested in the art &mdash;
This guide is my attempt to explain how fractal flames work in a way that younger me &mdash; and others interested in the art &mdash;
can understand without too much prior knowledge.
---
@ -41,7 +42,7 @@ This post covers section 2 of the Fractal Flame Algorithm paper
:::
As mentioned, fractal flames are a type of "[iterated function system](https://en.wikipedia.org/wiki/Iterated_function_system),"
or IFS. The formula for an IFS is short, but will take some time to unpack:
or IFS. The formula for an IFS is short, but takes some time to unpack:
$$
S = \bigcup_{i=0}^{n-1} F_i(S)
@ -69,15 +70,15 @@ export const simpleData = [
However, this is a pretty boring image. With fractal flames, rather than listing individual points,
we use functions to describe which points are part of the solution. This means there are an infinite
number of points, but if we find _enough_ points to plot, we'll end up with a nice picture.
And if we change the functions, our solution changes, and we'll get a new picture.
And if the functions change, the solution also changes, and we get a new picture.
### Transform functions
Second, the $F_i(S)$ functions, also known as "transforms."
At their most basic, each $F_i$ takes in a 2-dimensional point and gives back a new point
(in math terms, $F_i \in \mathbb{R}^2 \rightarrow \mathbb{R}^2$).
While you could theoretically use any function, we'll focus on a specific kind of function
known as an "[affine transformation](https://en.wikipedia.org/wiki/Affine_transformation)."
While you could theoretically use any function, we'll start with a specific kind of function
called an "[affine transformation](https://en.wikipedia.org/wiki/Affine_transformation)."
The general form of an affine transformation is:
@ -102,7 +103,7 @@ d &= 0 \\
e &= 1 \\
f &= 1.5 \\
F_{shift}(x,y) &= (1 \cdot x + 0 \cdot y + 0.5, 0 \cdot x + 1 \cdot y + 0.5) \\
F_{shift}(x, y) &= (x + 0.5, y + 0.5)
F_{shift}(x, y) &= (x + 0.5, y + 1.5)
\end{align*}
$$
@ -139,7 +140,7 @@ $$
S = \bigcup_{i=0}^{n-1} F_i(S)
$$
Or, to put it in English, we would get something like this:
Or, to put it in English, we might say:
> Our solution, $S$, is the union of all sets produced by applying each function, $F_i$,
> to points in the solution.
@ -154,40 +155,41 @@ explaining the mathematics of iterated function systems:
> of finite compositions $F_{i_1...i_p}$ of members of $F$.
:::note
I've tweaked the wording slightly to match the conventions in the Fractal Flame paper
I've tweaked the wording slightly to match the conventions of the Fractal Flame paper
:::
Before your eyes glaze over, let's unpack this explanation:
Before your eyes glaze over, let's unpack this:
- **$S$ is [compact](https://en.wikipedia.org/wiki/Compact_space)...**: All points in our solution will be in a finite range
- **...and is the [closure](https://en.wikipedia.org/wiki/Closure_(mathematics)) of the set of [fixed points](https://en.wikipedia.org/wiki/Fixed_point_(mathematics))**:
Applying our functions to these points does not change them
Applying our functions to points in the solution will give us other points that are in the solution
- **...of finite compositions $F_{i_1...i_p}$ of members of $F$**: By composing our functions (that is,
using the output of one function as input to the next function), we will arrive at the points we care about
using the output of one function as input to the next function), we will arrive at the points in the solution
Thus, by applying the functions in our system to "fixed points," we will find the other points we care about.
However, this is all a bit vague, so let's work through an example.
Thus, by applying the functions to fixed points of our system, we will find the other points we care about.
<details>
<summary>If you want a bit more math first...</summary>
<summary>If you want a bit more math...</summary>
...then there are some details worth mentioning that I've glossed over so far.
...then there are some extra details I've glossed over so far.
First, the Hutchinson paper requires that the functions $F_i$ be _contractive_ tor the solution set to exist.
First, the Hutchinson paper requires that the functions $F_i$ be _contractive_ for the solution set to exist.
That is, applying the function to a point must bring it closer to other points. However, as the Fractal Flame
algorithm demonstrates, we only need functions to be contractive _on average_. At worst, the system will
degenerate and produce a bad image.
Second, we're focused $\mathbb{R}^2$ because we're generating images, but the Hutchinson paper
allows for arbitrary dimensions - which means you could also have 3-dimensional fractal flames.
allows for arbitrary dimensions; you could also have 3-dimensional fractal flames.
TODO: Mention attractors? https://en.wikipedia.org/wiki/Chaos_game
Finally, there's a close relationship between fractal flames and [attractors](https://en.wikipedia.org/wiki/Attractor).
Specifically, the fixed points of $S$ act as attractors for the chaos game (explained in detail below).
</details>
## Sierpinski's gasket
This is still a bit vague, so let's work through an example.
The Fractal Flame paper gives us three functions we can use for our function system:
## [Sierpinski's gasket](https://www.britannica.com/biography/Waclaw-Sierpinski)
The Fractal Flame paper gives us three functions to use for our first IFS:
$$
F_0(x, y) = \left({x \over 2}, {y \over 2} \right) \\
@ -200,7 +202,7 @@ $$
### The chaos game
Next, how do we find the "fixed points" we mentioned earlier? The paper lays out an algorithm called the "[chaos game](https://en.wikipedia.org/wiki/Chaos_game)"
that will give us points in the solution set.
that gives us points in the solution set:
$$
\begin{align*}
@ -214,12 +216,13 @@ $$
$$
:::note
In effect, the chaos game algorithm implements the "finite compositions of $F_{i_1..i_p}$ mentioned earlier.
The chaos game algorithm is effectively the "finite compositions of $F_{i_1..i_p}$" mentioned earlier.
:::
Now, let's turn this into code, one piece at a time.
First, the "bi-unit square" is the range $[-1, 1]$. We can :
First, we need to generate some random numbers. The "bi-unit square" is the range $[-1, 1]$,
so we generate a random point using an existing API:
import biunitSource from '!!raw-loader!../src/randomBiUnit'
@ -233,14 +236,12 @@ import randintSource from '!!raw-loader!../src/randomInteger'
### Plotting
Finally, implementing the `plot` function. This blog series
is designed to be interactive, so everything shows
real-time directly in the browser. As an alternative,
software like `flam3` an Apophysis can also save an image.
Finally, implementing the `plot` function. This blog series is designed to be interactive,
so everything displays directly in the browser. As an alternative,
software like `flam3` and Apophysis can "plot" by saving an image to disk.
To display the results, we'll use the [Canvas API](https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API).
This allows us to manipulate individual pixels an image,
and display it on screen.
To show the results, we'll use the [Canvas API](https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API).
This allows us to manipulate individual pixels in an image and display it on screen.
First, we need to convert from Fractal Flame coordinates to pixel coordinates.
To simplify things, we'll assume that we're plotting a square image
@ -250,10 +251,9 @@ import cameraSource from "!!raw-loader!./cameraGasket"
<CodeBlock language="typescript">{cameraSource}</CodeBlock>
Next, we'll use an [`ImageData` object](https://developer.mozilla.org/en-US/docs/Web/API/ImageData)
to store the pixel data.
Next, we'll store the pixel data in an [`ImageData` object](https://developer.mozilla.org/en-US/docs/Web/API/ImageData).
Each pixel in the image on screen has a corresponding index in the `data` array.
To plot our image, we set that pixel to be black:
To plot a point, we set that pixel to be black:
import plotSource from '!!raw-loader!./plot'
@ -271,18 +271,16 @@ import chaosGameSource from '!!raw-loader!./chaosGame'
<hr/>
<small>
The image here is slightly different than the one in the paper.
I think the paper has an error, so I'm choosing to plot the image
in a way that's consistent with [`flam3` itself](https://github.com/scottdraves/flam3/blob/7fb50c82e90e051f00efcc3123d0e06de26594b2/rect.c#L440-L441).
The image here is slightly different than in the paper.
I think the paper has an error, so I'm choosing to plot the image
the same way as the [reference implementation](https://github.com/scottdraves/flam3/blob/7fb50c82e90e051f00efcc3123d0e06de26594b2/rect.c#L440-L441).
</small>
### Weights
Finally, we'll introduce a "weight" ($w_i$) for each function that controls how often we choose
that function during the chaos game relative to each other function.
For Sierpinski's Gasket, we start with equal weighting,
but you can see how changing the function weights affects the image below:
There's one last step before we finish the introduction. So far, each function $F_i$ has
the same chance of being chosen. We can change that by introducing a "weight" ($w_i$)
to each transform in the chaos game:
import randomChoiceSource from '!!raw-loader!../src/randomChoice'
@ -292,16 +290,23 @@ import chaosGameWeightedSource from "!!raw-loader!./chaosGameWeighted";
<CodeBlock language={'typescript'}>{chaosGameWeightedSource}</CodeBlock>
For Sierpinski's Gasket, we start with equal weighting,
but changing the transform weights affects how often
the chaos game "visits" parts of the image:
:::tip
Double-click the image if you want to save a copy!
:::
import GasketWeighted from "./GasketWeighted";
import {SquareCanvas} from "../src/Canvas";
<SquareCanvas><GasketWeighted/></SquareCanvas>
<SquareCanvas name={"gasket_weighted"}><GasketWeighted/></SquareCanvas>
## Summary
Studying the foundations of fractal flames is challenging,
but we now have an understanding of both the mathematics
and implementation of iterated function systems.
and implementations of iterated function systems.
In the next post, we'll study the first innovation that fractal flames
bring: variations.
In the next post, we'll study the first innovation of fractal flames: variations.

41
blog/2024-11-15-playing-with-fire/2-transforms/index.mdx
View File

@ -12,9 +12,9 @@ shapes and patterns that fractal flames are known for.
<!-- truncate -->
:::info
This post uses a set of [reference parameters](../params.flame) to demonstrate the fractal flame algorithm.
This post uses [reference parameters](../params.flame) to demonstrate the fractal flame algorithm.
If you're interested in tweaking the parameters, or generating your own art, [Apophysis](https://sourceforge.net/projects/apophysis/)
can load that file and you can try tweaking things yourself!
can load that file to play around with!
:::
## Variations
@ -30,8 +30,8 @@ playing the chaos game leads to an image of Sierpinski's Gasket. Even though we
the image it generates is exciting. But it's still not nearly as exciting as the images the Fractal Flame
algorithm is known for.
This leads us to the first big innovation of the Fractal Flame algorithm: applying non-linear functions
after the affine transform has happened. These functions are called "variations":
This leads us to the first big innovation of the Fractal Flame algorithm: adding non-linear functions
after the affine transform. These functions are called "variations":
$$
F_i(x, y) = V_j(a_i \cdot x + b_i \cdot y + c_i, d_i \cdot x + e_i \cdot y + f_i)
@ -41,8 +41,9 @@ import variationSource from '!!raw-loader!../src/variation'
<CodeBlock language="typescript">{variationSource}</CodeBlock>
Just like transforms, variations ($V_j$) are functions that map $(x, y)$ coordinates to new coordinates.
However, the sky is the limit for what we can do in between input and output.
Just like transforms, variations ($V_j$) are functions that take in $(x, y)$ coordinates
and give back new $(x, y)$ coordinates.
However, the sky is the limit for what happens between input and output.
The Fractal Flame paper lists 49 different variation functions,
and the official `flam3` implementation supports [98 different variations](https://github.com/scottdraves/flam3/blob/7fb50c82e90e051f00efcc3123d0e06de26594b2/variations.c).
@ -70,8 +71,6 @@ apply the affine coefficients to the input point, and use that as the output poi
This variation is a good example of the non-linear functions we can use. It uses both trigonometry
and probability to produce interesting shapes:
TODO: Connection with the julia set?
$$
\begin{align*}
r &= \sqrt{x^2 + y^2} \\
@ -93,7 +92,7 @@ import juliaSrc from '!!raw-loader!../src/julia'
### Popcorn (variation 17)
Some variations rely on knowing their transform's affine coefficients; they're known as "dependent variations."
Some variations rely on knowing the transform's affine coefficients; they're called "dependent variations."
For the popcorn variation, we use $c$ and $f$:
$$
@ -106,7 +105,7 @@ import popcornSrc from '!!raw-loader!../src/popcorn'
### PDJ (variation 24)
Some variations have extra parameters we can choose; these are known as "parametric variations."
Some variations have extra parameters; they're called "parametric variations."
For the PDJ variation, there are four extra parameters we can choose:
$$
@ -122,7 +121,7 @@ import pdjSrc from '!!raw-loader!../src/pdj'
Now, one variation is fun, but we can also combine variations in a process called "blending."
Each variation receives the same $x$ and $y$ inputs, and we add together each variation's $x$ and $y$ outputs.
We'll also give each variation a weight (called $v_{ij}$) that changes how much it contributes to the transform:
We'll also give each variation a weight ($v_{ij}$) that changes how much it contributes to the result:
$$
F_i(x,y) = \sum_{j} v_{ij} V_j(a_i \cdot x + b_i \cdot y + c_i, \hspace{0.2cm} d_i \cdot x + e_i \cdot y + f_i)
@ -144,11 +143,12 @@ Try using the variation weight sliders to figure out which parts of the image ea
import {SquareCanvas} from "../src/Canvas";
import FlameBlend from "./FlameBlend";
<SquareCanvas><FlameBlend/></SquareCanvas>
<SquareCanvas name={"flame_blend"}><FlameBlend/></SquareCanvas>
## Post transforms
Next, we'll introduce a second affine transform, known as a post transform, that is applied _after_ variation blending.
Next, we'll introduce a second affine transform, applied _after_ variation blending. This is called a "post transform."
We'll use some new variables, but the post transform function should look familiar:
$$
@ -163,19 +163,18 @@ import postSource from '!!raw-loader!./post'
<CodeBlock language="typescript">{postSource}</CodeBlock>
The image below uses the same transforms/variations as the previous fractal flame,
but allows modifying the post-transform coefficients.
but allows modifying the post-transform coefficients:
<details>
<summary>If you want to test your understanding...</summary>
Challenge 1: What post-transform coefficients will give us the previous image?
Challenge 2: What post-transform coefficients will give us a _mirrored_ image?
- What post-transform coefficients will give us the previous image?
- What post-transform coefficients will give us a _mirrored_ image?
</details>
import FlamePost from "./FlamePost";
<SquareCanvas><FlamePost/></SquareCanvas>
<SquareCanvas name={"flame_post"}><FlamePost/></SquareCanvas>
## Final transforms
@ -204,12 +203,12 @@ import chaosGameFinalSource from "!!raw-loader!./chaosGameFinal"
import FlameFinal from "./FlameFinal";
<SquareCanvas><FlameFinal/></SquareCanvas>
<SquareCanvas name={"flame_final"}><FlameFinal/></SquareCanvas>
## Summary
Variations are the fractal flame algorithm's first major innovation over previous IFS's.
Blending variation functions and post/final transforms allows us to generate interesting images.
Variations are the fractal flame algorithm's first major innovation.
By blending variation functions, and post/final transforms, we generate unique images.
However, the images themselves are grainy and unappealing. In the next post, we'll clean up
the image quality and add some color.

70
blog/2024-11-15-playing-with-fire/3-log-density/index.mdx
View File

@ -6,9 +6,9 @@ authors: [bspeice]
tags: []
---
So far, our `plot()` function has been fairly simple; map an input coordinate to a specific pixel,
So far, our `plot()` function has been fairly simple; map a fractal flame coordinate to a specific pixel,
and color in that pixel. This works well for simple function systems (like Sierpinski's Gasket),
but more complex systems (like our reference parameters) produce grainy images.
but more complex systems (like the reference parameters) produce grainy images.
In this post, we'll refine the image quality and add color to really make things shine.
@ -20,20 +20,21 @@ In this post, we'll refine the image quality and add color to really make things
This post covers sections 4 and 5 of the Fractal Flame Algorithm paper
:::
To start, it's worth demonstrating how much work is actually "wasted"
when we treat pixels as a binary "on" (opaque) or "off" (transparent).
One problem with the existing chaos game is that we waste work
by treating pixels as a binary "on" (opaque) or "off" (transparent).
If the chaos game encounters the same location twice, nothing actually changes.
We'll render the reference image again, but this time, count each time
we encounter a pixel during the chaos game. This gives us a kind of "histogram"
of the image:
To demonstrate how much work is wasted, we'll render the reference image again.
However, we'll also count each time the chaos game encounters a pixel.
This gives us a kind of image "histogram":
import chaosGameHistogramSource from "!!raw-loader!./chaosGameHistogram"
<CodeBlock language="typescript">{chaosGameHistogramSource}</CodeBlock>
When the chaos game finishes, find the pixel we encountered most frequently.
Finally, "paint" the image by setting each pixel's alpha value (transparency)
to the ratio of times encountered, divided by the maximum value:
When the chaos game finishes, we find the pixel encountered most frequently.
Finally, we "paint" the image by setting each pixel's alpha value (transparency)
to the ratio of times encountered divided by the maximum:
import CodeBlock from "@theme/CodeBlock";
@ -49,27 +50,27 @@ import {paintLinear} from "./paintLinear";
## Tone mapping
While using a histogram to paint the image improves the quality, it also leads to some parts vanishing entirely.
While using a histogram reduces the "graininess" of the image, it also leads to some parts vanishing entirely.
In the reference parameters, the outer circle is preserved, but the interior appears to be missing!
To fix this, we'll introduce the second major innovation of the fractal flame algorithm: [tone mapping](https://en.wikipedia.org/wiki/Tone_mapping).
This is a technique used in computer graphics to compensate for differences in how
computers represent color, and how people see color.
computers represent brightness, and how people see brightness.
As a concrete example, high dynamic range (HDR) photography uses this technique to capture
nice images of scenes with wide brightness ranges. To take a picture of something dark,
you need a long exposure time. However, long exposures can lead to "hot spots" in images that are pure white.
By taking multiple pictures using different exposure times, we can combine them to create
nice images of scenes with a wide range of brightnesses. To take a picture of something dark,
you need a long exposure time. However, long exposures lead to "hot spots" (sections that are pure white).
By taking multiple pictures with different exposure times, we can combine them to create
a final image where everything is visible.
In fractal flames, this "tone map" is accomplished by scaling brightness according to the _logarithm_
of how many times we encounter a pixel. This way, "dark spots" (pixels the chaos game visits infrequently)
will still be visible, and "bright spots" (pixels the chaos game visits frequently) won't wash out.
of how many times we encounter a pixel. This way, "cold spots" (pixels the chaos game visits infrequently)
will still be visible, and "hot spots" (pixels the chaos game visits frequently) won't wash out.
<details>
<summary>Log-scale vibrancy is also why fractal flames appear to be 3D...</summary>
<summary>Log-scale vibrancy also explains fractal flames appear to be 3D...</summary>
As explained in the Fractal Flame paper:
As mentioned in the paper:
> Where one branch of the fractal crosses another, one may appear to occlude the other
> if their densities are different enough because the lesser density is inconsequential in sum.
@ -89,15 +90,17 @@ import {paintLogarithmic} from './paintLogarithmic'
## Color
Finally, we'll introduce the last innovation of the fractal flame algorithm: color.
By including a color coordinate ($c$) in the chaos game, we can illustrate the transforms
responsible for each part of the image.
By including a third coordinate ($c$) in the chaos game, we can illustrate the transforms
responsible for the image.
### Color coordinate
Color in a fractal flame uses a range of $[0, 1]$. This is important for two reasons:
Color in a fractal flame is continuous on the range $[0, 1]$. This is important for two reasons:
- It helps blend colors together in the final image
- It allows us to swap in new color palettes easily
- It helps blend colors together in the final image. Slight changes in the color value lead to
slight changes in the actual color
- It allows us to swap in new color palettes easily. We're free to choose what actual colors
each color value represents
We'll give each transform a color value ($c_i$) in the $[0, 1]$ range.
Then, at each step in the chaos game, we'll set the current color
@ -139,14 +142,14 @@ import mixColorSource from "!!raw-loader!./mixColor"
Color speed values work just like transform weights. A value of 1
means we take the transform color and ignore the previous color state.
Similarly, a value of 0 means we keep the current color state and ignore the
A value of 0 means we keep the current color state and ignore the
transform color.
### Palette
Now, we need to map the color coordinate to a pixel color. Fractal flames typically use
256 colors (each color has 3 values - red, green, blue) to define a palette.
Then, the color coordinate becomes an index into the palette.
The color coordinate then becomes an index into the palette.
There's one small complication: the color coordinate is continuous, but the palette
uses discrete colors. How do we handle situations where the color coordinate is
@ -163,11 +166,11 @@ import colorFromPaletteSource from "!!raw-loader!./colorFromPalette";
<summary>As an alternative...</summary>
...you could also interpolate between colors in the palette.
For example: [`flam3` code](https://github.com/scottdraves/flam3/blob/7fb50c82e90e051f00efcc3123d0e06de26594b2/rect.c#L483-L486)
For example, `flam3` uses [linear interpolation](https://github.com/scottdraves/flam3/blob/7fb50c82e90e051f00efcc3123d0e06de26594b2/rect.c#L483-L486)
</details>
In the diagram below, each color in our palette is plotted on a small vertical strip.
Putting the strips side by side shows the palette used by our reference image:
Putting the strips side by side shows the full palette used by the reference parameters:
import * as params from "../src/params"
import {PaletteBar} from "./FlameColor"
@ -177,14 +180,15 @@ import {PaletteBar} from "./FlameColor"
### Plotting
We're now ready to plot our $(x_f,y_f,c_f)$ coordinates. After translating from color coordinate ($c_f$)
to RGB value, add that value to the image histogram:
to RGB value, add that to the image histogram:
import chaosGameColorSource from "!!raw-loader!./chaosGameColor"
<CodeBlock language="typescript">{chaosGameColorSource}</CodeBlock>
Finally, painting the image. With tone mapping, logarithms scale the image brightness to match
how it is perceived. When using color, we scale each color channel by the alpha channel:
how it is perceived. With color, we use a similar method, but scale each color channel
by the alpha channel:
import paintColorSource from "!!raw-loader!./paintColor"
@ -206,10 +210,10 @@ Next, introducing a third coordinate to the chaos game makes color images possib
the third major innovation of the fractal flame algorithm. Using a continuous
color scale and color palette adds a splash of color to our transforms.
The Fractal Flame Algorithm paper goes on to describe more techniques
not covered here. Image quality can be improved with density estimation
The Fractal Flame Algorithm paper does go on to describe more techniques
not covered here. For example, Image quality can be improved with density estimation
and filtering. New parameters can be generated by "mutating" existing
fractal flames. Fractal flames can even be animated to produce videos!
fractal flames. And fractal flames can even be animated to produce videos!
That said, I think this is a good place to wrap up. We were able to go from
an introduction to the mathematics of fractal systems all the way to

22
blog/2024-11-15-playing-with-fire/src/Canvas.tsx
View File

@ -8,18 +8,20 @@ type PainterProps = {
}
export const PainterContext = createContext<PainterProps>(null)
const downloadImage = (e: MouseEvent) => {
const link = document.createElement("a");
link.download = "flame.png";
link.href = (e.target as HTMLCanvasElement).toDataURL("image/png");
link.click();
}
const downloadImage = (name: string) =>
(e: MouseEvent) => {
const link = document.createElement("a");
link.download = "flame.png";
link.href = (e.target as HTMLCanvasElement).toDataURL("image/png");
link.click();
}
type CanvasProps = {
name: string;
style?: any;
children?: React.ReactElement
}
export const Canvas: React.FC<CanvasProps> = ({style, children}) => {
export const Canvas: React.FC<CanvasProps> = ({name, style, children}) => {
const sizingRef = useRef<HTMLDivElement>(null);
const [width, setWidth] = useState(0);
const [height, setHeight] = useState(0);
@ -93,7 +95,7 @@ export const Canvas: React.FC<CanvasProps> = ({style, children}) => {
<>
<center>
<div ref={sizingRef} style={style}>
{width > 0 ? <canvas {...canvasProps} onDoubleClick={downloadImage}/> : null}
{width > 0 ? <canvas {...canvasProps} onDoubleClick={downloadImage(name)}/> : null}
</div>
</center>
<PainterContext.Provider value={{width, height, setPainter}}>
@ -103,6 +105,6 @@ export const Canvas: React.FC<CanvasProps> = ({style, children}) => {
)
}
export const SquareCanvas: React.FC<CanvasProps> = ({style, children}) => {
return <center><Canvas style={{width: '75%', aspectRatio: '1/1', ...style}} children={children}/></center>
export const SquareCanvas: React.FC<CanvasProps> = ({name, style, children}) => {
return <center><Canvas name={name} style={{width: '75%', aspectRatio: '1/1', ...style}} children={children}/></center>
}

8
blog/2024-11-15-playing-with-fire/src/css/styles.module.css
View File

@ -1,7 +1,7 @@
.inputGroup {
padding: .2em;
margin-top: .2em;
margin-bottom: .2em;
margin-top: .5em;
margin-bottom: .5em;
border: 1px solid;
border-radius: var(--ifm-global-radius);
border-color: var(--ifm-color-emphasis-500);
@ -25,6 +25,10 @@
.inputElement > input[type=range] {
width: 100%;
height: 4px;
appearance: none;
background: var(--ifm-color-emphasis-400);
border-radius: var(--ifm-global-radius);
}
.inputReset {