Colouring fractals

Some time ago I realized that there was no question in sci.fractals-faq about the use of colours in fractal images. I suggested to Terry W. Gintz to write something about this. He wrote the 2 questions-answers #20 and 20b. But he told me that he limited the text about true colours fractals (answer 20b) to his personal approach of the problem, and that it would be a good thing if other programmers might add their contributions to the question.
We all know the names of some of you who are concerned by this. How can we make a comprehensive text ? I am now launching a bottle in the sea, and you might agree or not.
Look at what follows as a starting point (may be good, may be bad, it does not matter).
I think that we can start from the problem of colour banding in classic fractal images. To reduce, or suppress this, 2 technical problems must be solved. The first is to use more than 256 colours (24 bits encoding), because all the graphic cards offer us better possibilities. The second is to use escape algorithms with more graded steps than the classic escape time one.
About the number of colours, I think that the solutions can be divided into 2 groups :
the first way is to use a hand-made palette (like a Fractint one) and to do interpolations between the fixed 256 (or 236 in Windows programs) colours. For example Terry's Zplot-24 uses this solution.
The other is to use a strictly algorithmic process to build the whole range of colours (Flarium 24 and the other programs of Stephen Ferguson do it).
About the graded escape algorithms, Terry wrote in his text some proposals he uses in his program, but some others exists. For example Linas has an interesting renormalization method giving continuous colour progressions, even when using escape time and a low number of iterations (Linas, can you explain this in a short text, which can be understood by a non-mathematician, like me ?).
I hope to receive several contributions (even if you think that the starting points suggested above are not adequate). I will then wrote a synthetic text which might be posted here to receive your latest suggestions or corrections before it is introduced in the faq. For the existing texts about colours in the faq, see Q20 and Q20a
http://www.mta.ca/~mctaylor/sci.fractals-faq/
Thanks.

The dmj-pub.frm file I have on my web site
http://www.fractalus.com/downloads/fractint.htm
includes three formulae (dmj-Mand-Smooth, dmj-Mand-SmoothX2, dmj-Mand-SmoothPHC) which use Linas Vepstas' algorithm, with only 256 colors. It works very well, but I found a small change was necessary to get the results to be consistent with different bailout values.
The basic idea behind the algorithm is to examine the final bailed-out iteration value, and see if it "only just" bailed out, or if it greatly exceeded the bail-out value. This is used to calculate a "fractional" iteration, which is then combined with the actual integer iteration count for a full continuous value.
From this, either custom-palette mapping (like ZPlot) or algorithmic mapping (Iterations, Flarium, InkBlot, Talis) can be used. Actually, these algorithms could use *any* coloring technique which provided a continuous value. Integer iteration values are just an approximation for "potential", anyway, which is a continuously variable value. 

As you mentioned, I use an algorithm to generate the color gradients for the programs Iterations, Inkblot, and Flarium24. I also use basically the same algorithm for my fourth program, Talis, which is an 8-bit palette based program. To my knowledge these algorithms have not been used in other programs, yet it is a very simple algorithm. Fractint may use it, I just don't know. Basically the color index starts at a predefined color and continues to 255. Then instead of wrapping around back to zero it starts decrementing from 255, the next numbers would be 254, 253, etc... (if the step value is 1) This must be applied to each of the red, green, blue components independently. There is also a step and a start value for each color component. The start value is the color index used for an iteration count of 1. The step value is the multiplication factor.
If you want a more detailed description of the exact coloring algorithm I'm using, let me know and I will send it to you. 
On the problem with color banding, I use Linas Vepstas's algorithm
http://linas.org/art-gallery/escape/escape.html
in my true-color programs as well as "Talis", the 256 color program. It not only works with true colors, but I get excellent results with 256 colors from my Talis program. Some of the sample images from my Talis page at
http://home1.gte.net/itriazon/Talis/talis.htm
uses Linas's algorithm with excellent results in only 256 colors. I have to admit that I don't understand his algorithm, I just know it works great for removing color bands from both true-color as well as 256 color images. However it seems to work only with the Mandelbrot type formulas such as z*z+c. It does not work with Newton type formulas. 

[Stephen C. Ferguson] On the problem with color banding, I use Linas Vepstas's algorithm
http://linas.org/art-gallery/escape/escape.html
in my true-color programs as well as "Talis", the 256 color program. It not only works with true colors, but I get excellent results with 256 colors from my Talis program. Some of the sample images from my Talis page at
http://home1.gte.net/itriazon/Talis/talis.htm
uses Linas's algorithm with excellent results in only 256 colors. I have to admit that I don't understand his algorithm, I just know it works great for removing color bands from both true-color as well as 256 color images. However it seems to work only with the Mandelbrot type formulas such as z*z+c. It does not work with Newton type formulas.
Thanks Stephen, I am interested by more information about your coloring scheme (even if I don't know if I will use detailed information in the faq). I hope that Linas will send a contribution (I think that the beginning of the explanation on his web page is very good but what follows is more complex for me !). I looked at the images made with Talis and I agree that the results are very impressive for a 8 bit coding of the colors. I think however that when a 256 colors range is used, you can reduce, smoothen... banding, but it is impossible to suppress it. A way to reduce it is to use only 2 to 4 basic colors with graded shades of these colors : Paul Carlson, Phil Pickard where the first (I think) to use this trick in bubble and stalk methods. The results are generally very smooth because there are only few differences between the different shades.

[JPL] About the number of colours, I think that the solutions can be divided into 2 groups : the first way is to use a hand-made palette (like a Fractint one) and to do interpolations between the fixed 256 (or 236 in Windows programs) colours. For example Terry's Zplot-24 uses this solution. The other is to use a strictly algorithmic process to build the whole range of colours (Flarium 24 and the other programs of Stephen Ferguson do it).
As you know, ZPlot 24 now contains an HSV-filter option that extends the interpolated palette I have been using in it. Basically, you convert every pixel's iterated rgb value to an hsv value, then apply an offset to one or more components of it (hue, saturation or value.) The offset can be time-based, magnitude-based or angle-based or a combination of factors, such as level-indexed. By converting this "extended" hsv value back to an rgb value, you overcome the limits of an interpolated rgb palette. But you still have a visual base to work from, so pixel colors aren't exactly unpredictable as in a "strictly algorithmic process." I have used this process with a ten-fold increase in color spread over the basic interpolated palette. Most recently, I have implemented an HSV filter based on the level-indexed algorithm (BOF61.) This works quite well when applied to the hue of a pixel. The resulting pictures are much brighter.

I would just update the language you currently have in the FAQ.
The current language centers around this approach :

pixel = colortable[iter % table_size]

While this is a handy approach when colortable[] can fit inside the DAC of a video card, it is not so great for 24-bit images or more interesting uses of the orbit information. For fractals arising from the dynamics on the complex plane, you can color the pixel from any information in the orbit :

pixel = color_function(orbit)

Most 24-bit coloring schemes use only the last Z value in the orbit, reducing the memory requirements for such coloring schemes considerably, especially for very deep zooms at a high maximum iteration count :

pixel = color_function(iter, last_z)

(Since we aren't passing the whole orbit, we also pass in iter so that the function knows how many iterations it took to get to last_z.) Naturally color_function can do an arbitrary calculation to produce the RGB triplet. For instance, Linas Vepstas' algorithm can be summarized as :

delta = escape_delta(last_z, bailout)
pixel = colortable[iter]*(1 - delta) + colortable[iter + 1]*delta

Where "delta" is a fraction in the [0, 1) interval indicating how close you are to hitting the next iteration count and the pixel expression is your basic linear interpolation between two colors as specified by the fraction delta. Similarly, fractint's coloring methods summarized in the FAQ are equivalent to :

outside=real :
pixel = colortable[iter + last_z.real]

outside=imag :
pixel = colortable[iter + last_z.imag]

outside=summ :
pixel = colortable[iter + last_z.real + last_z.imag]

outside=mult :
pixel = colortable[iter * last_z.real / last_z.imag]

outside=atan :
pixel = colortable[atan(last_z.real, last_z.imag)]
and so on.

For 24-bit rendering in fractint, I've suggested that these formulas be made explicit in the sense that all 24-bit coloring methods are variations on the same theme : given an orbit (or just the length of the orbit and the last value in the orbit), produce an RGB color. In fractint, there are a number of different parameters that affect color indexed renderings (logmap, biomorph, etc.) that are all subsumed by the idea of writing the orbit -> pixel mapping as a formula. They just do different things with the iteration count and the last_z value. If you look at the 24-bit coloring from this point of view, then you begin to realize that even the standard M-set fractal still has plenty of variation left in it based on how you color the pixels.
Beyond this simple, straightforward approach, there is the possibility of using all the orbits for all pixels in the image in order to color a pixel. In the above, each pixel's color is assumed to be independent of the colors of other pixels in that each pixel's color depends only on the orbit of the point in the complex plane represented by the pixel. However, one can generalize this approach even further and color pixels not only by the properties of their individual orbits but also on the properties of their orbit compared to the orbits of all the other pixels in the image. One can do histogram renormalization techniques and so-on to determine a pixel's color in terms of how its orbit compares to the "typical" orbit in the image. 

[JPL] Some time ago I realized that there was no question in sci.fractals-faq about the use of colours in fractal images.
..................
For example Linas has an interesting renormalization method giving continuous colour progressions, even when using escape time and a low number of iterations (Linas, can you explain this in a short text, which can be understood by a non-mathematician, like me ?).
OK, here goes an attempt :
Q : How can I smoothly shade the exterior of the mandelbrot set ?
A : Most pictures of the exterior of the mandelbrot set use the "escape count" of the iteration. The "escape count" is the number of times that the iteration is performed until the iterated value exceeds some radius. Normally, this count is an integer, and thus, when it is used to select a color, "bands" (areas of constant color) appear.
Banding can be eliminated by using a fractional escape count. There are many ways that a fractional escape count can be computed. One possible way of obtaining a fraction is to measure how far the iterated point landed outside of the escape cutoff. One of the smoothest, most mathematically correct formulas is the "renormalized" iteration count. For the iterated equation
z(n+1) = z(n) ^ 2 + c, the renormalized count is given by
mu = N + 1 - log (log |Z(N)|) / log 2
where N is the usual "escape count", Z(N) is the value of Z when it escaped, and |z| is the modulus of z. (that is, if z=x+iy then |z| = sqrt (x*x+y*y) ).
For the more general formula
z(n+1) = z(n) ^ k + c,
the renormalized count is
mu = N + 1 - log (log |Z(N)|) / log k
Although it is not obvious from the formula, the value of mu is almost completely independent of the actual escape radius. This is because the mathematics used to derive the formula implicitly take the limit of the escape radius going to infinity, and then subtracting the infinite iteration count resulting from taking that limit. (This formula shows only the first term).
The following simplified and very insightful derivation of the formula is provided by Earl L. Hinrichs :
"Ignoring the +C in the usual formula, the orbit point grows by Z := Z^2. So we have the progression Z, Z^2, Z^4, Z^8, Z^16, etc. Iteration counting amounts to assigning an integer to these values. Ignoring a multiplier, the log of this sequence is : 1, 2, 4, 8, 16. The log-log is 0, 1, 2, 3, 4 which matches the integer value from the iteration counting. So the appropriate generalization of the discrete iteration counting to a continuous function would be the double log." 
Reference :
http://linas.org/art-gallery/escape/

[Rich Thomson] For 24-bit rendering in fractint, I've suggested that these formulas be made explicit in the sense that all 24-bit coloring methods are variations on the same theme : given an orbit (or just the length of the orbit and the last value in the orbit), produce an RGB color. In fractint, there are a number of different parameters that affect color indexed renderings (logmap, biomorph, etc.) that are all subsumed by the idea of writing the orbit -> pixel mapping as a formula. They just do different things with the iteration count and the last_z value. If you look at the 24-bit coloring from this point of view, then you begin to realize that even the standard M-set fractal still has plenty of variation left in it based on how you color the pixels.
Just an FYI : Truemand, which is available on my website and uses the Vepstas algorithm, has incorporated almost all the Fractint options for coloring. Some had to be modified somewhat to work with the Vepstas algorithm. Check it out ! 
http://www.hiddendimension.com/futils.html

A short summery (not intended to be a text for the FAQ) and questions.
....
Nobody has disputed the statements that, to remove banding in fractals images, we need more than 256 colors, and escape algorithms using more graded steps than the classic escape time one.

- HOWEVER -

Banding can be nicely reduced even with 256 colors by choosing carefully the escape criterion and palette. Specially the Linas's algorithm has given good results to Damien (using personal Fractint formulae) and Stephen (in his program Talis). For 256 colors palettes the best seems to use graded shades of 2 to 4 main colors as in orbit trap fractals (see Paul Carlson, and Phil Pickard's Fractal Orbits), but Damien uses such palettes in some of its recent images.
To be sure, Linas's algorithm works better in true color programs. This algorithm is said to concern Mandelbrot type fractals. I suppose that it works also with Julia types. More informations from Linas and some others might help me (in other words, what are the generalized formulae to which this method can be applied ?). 
In my first posting I said that 24 bits coloring schemes seems to fall into 2 groups : interpolation based on a hand-made (Fractint like) palette, or strictly algorithmic schemes. But when I read Stephen I realized that he used also a palette (not hand-made, but obtained by an algorithmic way). Therefore this topic must be rewritten more accurately.
Using Rich Thomson formalism, palette based programs use
pixel=colortable[some_escape_criterion].
But if I understand Rich
pixel=color_function(orbit)
suggest a family of programs computing the color (the RVB values ?) without any preexisting palette.
Do such programs exist ? If yes, how the aesthetic rendering of colors can be controlled ?
Now my question is for Earl Hinrichs : do you use such a method ? Some words in a recent mail from Damien let me suppose that it might be possible.
PS : Terry's Zplot 24 is based on palette interpolation, but more recent additions (HSV filters) are oriented towards algorithmic computation of colors.
I hope that this will open a new discussion (perhaps to rectify some of my statements). 

[JPL] Banding can be nicely reduced even with 256 colors by choosing carefully the escape criterion and palette. Specially the Linas's algorithm has given good results to Damien (using personal Fractint formulae) and Stephen (in his program Talis). For 256 colors palettes the best seems to use graded shades of 2 to 4 main colors as in orbit trap fractals (see Paul Carlson, and Phil Pickard's Fractal Orbits), but Damien uses such palettes in some of its recent images.
Yes, I never really noticed how crooked my "smooth" palette was until I tried this myself ... the problem is that my palette was supposed to go from dark to light, and instead is rather bumpy between dark & light.
So one more suggestion for FAQ : to be smooth, choose palettes that are smooth in overall intensity in YUV rather than RGB. What "smooth" means in color space, though, is a whole nuther question...
[JPL] To be sure, Linas's algorithm works better in true color programs. This algorithm is said to concern Mandelbrot type fractals. I suppose that it works also with Julia types. More informations from Linas and some others might help me (in other words, what are the generalized formulae to which this method can be applied ?). Send me some typical iterated formulas, and I promise to think about them in the next few weeks or month...

[JPL] To be sure, Linas's algorithm works better in true color programs. This algorithm is said to concern Mandelbrot type fractals. I suppose that it works also with Julia types. More informations from Linas and some others might help me (in other words, what are the generalized formulae to which this method can be applied ?).
The Vepstas algorithm may be different for different formulae. For example, the Ikenaga function is a power of three function. The correct formula for for calculating the incremental iteration value has a factor the square root of three in it rather than the square root of 2. Linas has the general derivation on his web site. I have not totally succeeded in calculating the incremental iteration value for newtons and localized strange attractors, although I have gotten some pretty good results. If anyone is interested, I will share the results.

[Linas Vepstas] So one more suggestion for faq : to be smooth, choose palettes that are smooth in overall intensity in YUV rather than RGB. What "smooth" means in color space, though, is a whole nuther question ...
This leads one in the direction of psychometry -- the measuring of the perception of color. Lots of work has been done in this field. I can probably dig up some references for the Truly Motivated (tm) :).
Here are some general recommendations from my experience :

1. Try to avoid RGB space interpolation.

Why ? Pick two colors of comparable intensity in RGB space and then produce an interpolated color table ramp from the two colors. Chances are the colors in-between will not have the same intensity as the two endpoints. This is because interpolation in RGB space doesn't preserve intensity.
Use a color space like HSV, YUV, etc., (See the Color FAQ for detailed information on color spaces and gamma <URL: http://www.inforamp.net/~poynton/ColorFAQ.html>.)When you want to interpolate the color (hue) and leave the intensity (saturation & value) constant, use a space like HSV and vary the hue, leaving saturation and value constant. This is how you algorithmically produce a palette of pastel colors.
If you have two RGB values and you want to interpolate between them, try converting them to HSV space first and interpolating there and then converting back to RGB. You may want to experiment with different color spaces, as they have different properties.

2. Try to avoid linear steps in intensity when interpolating intensity

Why ? Because the eye actually registers intensity logarithmically. So when you create a linear gray-scale ramp, the gray scale doesn't seem evenly distributed. However, if you create a logarithmic color ramp, your eye will perceive the grayscale as changing in a more even fashion. Such logarithmic colormaps are often called "gamma" maps because they most often arise as a correction step to compensate for the nonlinear response of a display device, which is characterized by its "gamma" value. (Again, see the above FAQ for more details on this.)

3. Use a colorspace that is natural for the data being visualized.

Are you taking the argument (angle in the C plane) of the last iterate ? This maps easily onto the hue in HSV space, because the hue is modeled there as an angle around a cone. Similarly, you might find magnitude of the last iterate intuitively maps well to the saturation or the value in HSV space. 

[JPL] But if I understand Rich
pixel = color_function(orbit)
suggest a family of programs computing the color (the RVB values ?) without any preexisting palette.
You can still use a palette here. The idea is that you're using more information from the orbit than just its length to compute the color. Palettes can still be used even with this higher information. Linas' algorithm essentially does this, by using the last iterate's Z value to give "fractional" palette indicies and then interpolate between the palette colors based on the fraction.
[JPL] Do such programs exist ? If yes, how the aesthetic rendering of colors can be controlled ?
Most of the fractal programs I've written myself produced 24-bit output and used this technique. You can control the range of colors produced by limiting the program to operate within a region of a color space. For instance, although HSV space allows hue to vary from 0 to 360 degrees and saturation/value to vary from 0 to 1, you can constrain the program to generate colors only within a more limited range. 

I agree with Rich Thomson's statements about HSV versus RGB. I have played with a smooth curve (cubic, but not splines) intepolation in HSV space.
I'm interested in the question of the user interface needed to properly control the mapping of a continuous variable into a 24 bit color.
I have made an attempt to do this, which can be seen if you download my (free) package at
http://www2.capcollege.bc.ca/~mfreeman/mand.html
I don't think it's the ultimate solution, but it seems to work. 

[Mike Freeman] I'm interested in the question of the user interface needed to properly control the mapping of a continuous variable into a 24 bit color.
Ah, a very good question... I suspect that what most programmer types would tend to do is create a dialog box where the user can type in a formula. While this is easy to code, it doesn't lead to a clear and intuitive UI for controlling this aspect of the process.
An alternative approach would be to provide a palette of icons representing the various mappings and allowing the user to select one. This has the advantage that the icons can display the visual properties of the mapping of orbit -> color but it gives up some of the flexibility of being able to type in an arbitrary formula since you are dependent on the author's selection of formulas for the icons in the palette.
A hybrid approach, where the user's formula results in the creation of a new icon on the palette is also possible.
However, I have been thinking about this sort of thing for a while. I have done the formula route and even though I can handle writing formulas, it still doesn't lead to an intuitive and aesthetic exploration of the possibilities. Too much time is spent coding/debugging the formula rather than focusing on the creative / brainstorm "lets just

However, I have been thinking about this sort of thing for a while. I have done the formula route and even though I can handle writing formulas, it still doesn't lead to an intuitive and aesthetic exploration of the possibilities. Too much time is spent coding/debugging the formula rather than focusing on the creative / brainstorm "lets just try it" aspect that I prefer when interactively working on fractals.
Furthermore, either of these techniques don't readily allow one to build a set of reusable components that can be combined together in new and novel ways. Thinking about all of this leads me in the direction of an interface similar to the scientific visualization systems that were first popularized in the workstation community with programs like AVS (Advanced Visualization System).
Here, the user had a toolbox (palette) of reusable visualization techniques, each of which had inputs and outputs, with the inputs and outputs color coded to indicate their data type (i.e. scalar field, image, 3D geometry, etc.). The user grabbed modules off the palettes and dropped them onto a canvas. Since the inputs and outputs of the modules were typed, the program could often attach various blocks together for you automatically (you could always disconnect it when it made a wrong guess). If there were more than one possibility, the program did nothing, but the user was assisted with hints when the mouse was used to wire modules together.
This kind of approach is complex to program, but seems to offer the best of both :

1. blocks are reusable :

Suppose you have 5 different kinds of transformations that utilize a circular inversion effect -- z' := r/(z - c), inverts z through a circle of radius r and center point c -- by building a block that does the inversion, you can reuse this over and over without having to recode it in your formulas, possibly introducing bugs in the process. For this particular block, the parameters r and c are entered into the block's display area and not as an input (z is the input and z' is the output). But one could also imagine a block where z, r, and c are all inputs to the block, thus enabling you to dynamically change the radius parameter for each z input.

2. blocks are composable :

By connecting the output of one block to the input of another block, you can compose a few basic tools together to get a wide variety of results

3. blocks are easily manipulated without understanding formulas :

Since blocks have their inputs and outputs marked and the program helps you wire them together with the mouse, you don't need to understand algebra, operator precedence rules, operators, etc.

4. Blocks can be grouped together to define new blocks :

Drag select a group of connected blocks to create your own "macro block". These can then be reused composed and manipulated just like any other block.

If there are any programmers out there wanting to know the details of how one would implement this, email me. I suspect its too technical for this list :).
I'd love to see this kind of thing created; I think its an interface the techie types could use just as proficiently as those of us who are less technically inclined to write things like :
z := cos(omega*z*z*z*z + phi) / (r*sin(z) - c)
and be confident in what we are going to get out of it without resorting to random luck.

[Rich Thomson] Furthermore, either of these techniques don't readily allow one to build a set of reusable components that can be combined together in new and novel ways. Thinking about all of this leads me in the direction of an interface similar to the scientific visualization systems that were first popularized in the workstation community with programs like AVS (Advanced Visualization System).
Mouse was used to wire modules together.
This (conceptually) is the approach that I've taken toward 24-bit fractals : build a set of coloring schemes and another set of image processing tools, and then play "try this" with the combinations. Specifically, Piclab was written by the Stone Soup Group (of Fractint fame), and is a freeware, DOS-based image processing program that supports batch files and macros. One of my favorites tricks is to render two fractals in Fractint, using the same fractal parameters but different coloring schemes. Then, I turn to Piclab and throw a bunch of macros at them. Refinement of a given image is fairly simple, and the investment per trial is minimal (given small enough initial images).
Given the arithmetic nature of Piclab's image combining (add, subtract), and the non-linear nature of clipping intensities when they go outside of the 0-255 range, all sorts of possibilities are available, including : find the minimum or maximum RGB components of a series of images, average a number of images, find the absolute value of the difference between two images, etc. And the macros can be used with each other, to as many levels as one would like.
I think this method adds another dimension to fractal imaging, without being hampered by 256 color limitations, and without having to kill oneself developing new fractal formulas.

[Rich Thomson] Furthermore, either of these techniques don't readily allow one to build a set of reusable components that can be combined together in new and novel ways. Thinking about all of this leads me in the direction of an interface similar to the scientific visualization systems that were first popularized in the workstation community with programs like AVS (Advanced Visualization System).
Mouse was used to wire modules together.
[Kerry Mitchell] This (conceptually) is the approach that I've taken toward 24-bit fractals : build a set of coloring schemes and another set of image processing tools, and then play "try this" with the combinations.
Well, for the unix/linux folks out there, may I remind y'all about the "GIMP" which is an Adobe Photoshop work-alike, available as freeware, with full source code.
http://www.gimp.org
Its not at all AVS, but it does define a plugin api for adding various special-effects modules; it had something like 60 or 70 plugins about a year ago. Maybe a fractint-plugin would be a good thing to do, if someone hasn't already done it ...
P.S. Someone has taken the GIMP and wired it to a web server so that you can play fund tricks with it from a web browser. Try
http://scheme.XCF.Berkeley.EDU/net-fu/
P.P.S. There are now 102 plugins, three of which are for fractals; a number more are gradient editors & colormap/palette editing tools. Although I am sure that this is not enough, so coders are encouraged to hack on this. There appears to be no plugin for reading fractint files, as best as I could tell.

[JPL] Do such programs exist ? If yes, how the aesthetic rendering of colors can be controlled ? Now my question is for Earl Hinrichs : do you use such a method ? Some words in a recent mail from Damien let me suppose that it might be possible.
I do not use a palette in my program, all of my fractals are generated directly in 24 bit color mode using various algorithms to compute the color. Many months ago I was somewhat an evangelist on this mail list on the use of algorithmic coloring schemes versus palette schemes. I did not win any converts, so I have not brought it up again. Besides, I get a lot of comments about the unique colors in my fractals. If everyone used algorithmic colors, I would have to work harder to be different. Here is a repost of an old message.
-----Original Message-----
Sent : Saturday, May 31, 1997 10:33 AM To: 'fractal-art@aros.net' Subject: RE: tutorial for true-color rendering methods
[Terry] I failed to explain that escape-time algorithms are unsuitable for true color not only because the maxiter is low, which as you say can be scaled upward, but because escape time is integer in nature. You can't scale a series of whole numbers into a total of colors beyond what's in the series. For example a series of 1000 numbers (derived from a maxiter of 1000) can only address 1000 colors no matter how they are scaled.
I do not think it is the discrete, integer, nature of escape time coloring that is the problem. Even in true color mode, a typical video card can only display 256 shades of a color. I think the problem is that escape time coloring is inherently one dimensional.
[Kerry] to the applicable variable range. Color space (on today's computers) is inherently 3-dimensional; covering it coherently in 3d is tricky at best.
I agree that the key is adopting a 3d view of the color space. (Here I am referring to 3d as the three components, RGB of true color mode. Not 3d as in ray tracing. I am pretty certain Kerry meant it that way.)
Tricky ? Well that is relative. Yes it takes a lot of tweaking to get the right 3d color mapping for an image. But then people have spent hours tweaking a 1d palette map. To get nice fractals, you HAVE to spend a lot of time selecting the colors, whatever approach you use. (And either method is a whole lot easier than selecting a color to paint the bedroom.)
I want to set up the motivation for these claims. But if you are in a hurry, you can skip to the paragraph that starts "**Conclusion :"
I have written and abandoned at least one fractal program a year for the last ten years. In the most recent incarnation, I decided to abandon palettes altogether and only work with 24 bit color. (A better video card motivated the decision.)
The first thing I tried was creating a list of colors with a real number 0 <=3D x <=3D 1, associated with each color. I then compute a number between 0 and 1 for each point in the image. Usually the number is the ratio of the escape time index over the maximum iteration count. I then find the colors with index above and below that value in the color table, and do a linear interpolation. Sometimes I use other functions, such as the square root, to make the color distribution non-linear.
Essentially I created a continuous, real number indexed palette to replace the traditional discrete, integer indexed palette. With high maximum iteration counts the color banding would disappear. However the resulting images did not look much different from an image generated with a discrete palette.
The next thing I tried was to take the value of the orbit point at the escape iteration and map the real part to the R color component, the imaginary part to the G component, and needing a third value, I mapped the distance from the origin to the B component. I had parameters to tweak to convert the full range of real values into the 0-255 range for each color component.
The result was unlike any palette-colored fractal (good), however, it looked like three independent images superimposed (not so good).
I found better ways, other than location at escape-time, to pick the point to color. I have described those other methods at other times, today I want to talk about the color calculation. Then next thing I tried with colors, was to imagine RGB lights at three points in the complex plane. To color a value, compute the distance from each of the color sources. Then make the intensity of that color component inversely proportional to the distance from the color source. Now I was getting interesting results. The different color components were working together nicely, rather than being unrelated as in my earlier attempts.
The location of the light sources, and rate at which the color intensity decays as you move away from the light source are controllable parameters with this method. It takes some effort to find the parameters that produce interesting images. There is a single 'bright spot' (center point between the three sources). If the intensity function is too flat, the image is dull, if it is too steep, the image breaks up into separate R,G,B spots.
My next attempt is what I use for most of my fractals. I envision three points in the plane, and then imagine sine waves of color emanating from those points. I calculate the distance from each light source, then apply a (periodic) sin function to the distance and use that for the intensity. (I can not think of a physical analogy for this.) The frequency, phase, and amplitude of each sine function are controllable parameters, as are the source locations. The periodic nature of the sine functions allows a steep color intensity curve, without isolating the color to a single point.
**Conclusion : After working these variation, it occurred to me that these approaches are instances of a general method for true color fractal coloring.
Generate a complex number during the fractal calculation. The actual point calculation does not matter. By that I mean, any calculation can be used, different calculations giving different color schemes. I have used 'last point', 'closest point to the origin', 'closest point to the x (or y) axis', 'angle of closest point to the x axis', 'closest to a moving target', 'sum of the points', 'sum of the closer points', 'weighted sum of points', and many other methods to compute this point.
Also create a coloring (expressed as a function of x & y) of the plane. Again, any coloring will work for the general algorithm. All of the color schemes I described above could be viewed as a mapping from the plane to RGB color space.
You then use the color function to look up (calculate) the color of the point generated during the iteration.
This is a very rich source of new fractal exploration. The selection of the complex number offers new ways to bring out the fractal nature of your object, that are not possible with escape-time coloring and its variations. The number is not limited to when the orbit escaped, but can also be influenced by where it escaped, and the path it took to get there. For that matter, the point does not have to escape ! Interesting features of captured points can be represented. Many of my fractals consist *entirely* of captured points.
Next ? Recently I have added code to my program to add any two arbitrary colors. I am working on modifying the color sine wave scheme, so that the color sources can be any color, and not limited to red, green and blue. I am also adding a third dimension to the color map, looking at the escape time index as well as the complex coloring point. I have ideas for higher dimension functions that I want to try out as well.
------ [end of reprint] ----
By the way, I have put on the web six months worth of my fractals. You can get there through the "archive" link on the URL in my signature. I include the creation date with each image. If you have the patience to wade through this 50+ meg of images, you can see the coloring method evolution I described above.

Sometimes it is easier to cut and paste then to write something new. I continued the evangelism I mentioned in the previous post in private emails with anyone who would listen. Here is a section of one of those emails :
-----------[reprint]----
The trick is to come up with a color set that doesn't vary wildly like the standard 256 color palette. So in a sense, I *do* have to program some kind of indexing function for the iterations. Something similar to
R(x), G(x), B(x)
Where x is the number of iterations on that specific pixel. Or am I misunderstanding what you mean here ?
Close, but you do not get to light the cigar yet. Forget about iteration count for a minute. (You can remember it later.) Write it like this :
R(F), G(F), B(F).
F represents the fractal. There are three different functions of the fractal. Get wild and creative. R is the real value of the of the orbit point on the last iteration step. G is the sine of the real part times the imaginary part of the third iteration step. B is the iteration count. That example would be pretty ugly, but my point is to stretch your imagination. The R(x), G(x), B(x) scenario is one dimensional because all color values are based on the same, one dimensional, property. Use different properties of the fractal for each gun.
Try this experiment. Look at an ordinary fractal. Pick a point surrounded by a continuous region. Notice the color. Draw any path from that point in the continuous region. There are two possible sequences of color as you walk that path, determined by whether the iteration count increasing or decreasing along your path. The rate at which the colors change will depend on your path, but the colors will always be the same. Find another starting point with the same color, do the same exercise. Guess what, you get the same sequence of colors. It is obvious when you think about it, you are mapping a fractal onto a line (iteration count) and then mapping that line into 3d color space. There is only one path from color A to color B. Look at my fractals, every path from A to B goes through different shades of the intermediate colors.
Forget about computers. Imagine that you are painting on a canvas. Imagine that someone imposed the above requirement, you can paint anything you want, but the color transitions had to follow the above rule. I doubt that any artist would accept that limitation. But every fractal artist that uses a palette and escape time are accepting that limitation.
I am getting too verbose. Anyway the three functions should coordinate with each other and the fractal in some reasonable way to make an interesting picture.
-----------[end of reprint]----
There are two points in the preceding that deserve further emphasis. First, base the color calculation on the entire fractal. More precisely, base it on any or all of the points in an orbit, not just the last value, or not just on the first time the orbit exceeds a predetermined limit. All of the points in the orbit are candidates to contribute to the color. Second, avoid one dimensional intermediate steps. A palette is a map from a one dimensional space to the color space. The continuous extension of a palette is a map from a one dimensional space. If you convert z to |z| before computing the color you are mapping from a one dimensional space. (OK, technically the domain of the palette function is a finite set of integers which has dimension 0.) 

[Earl L. Hinrichs] All of the points in the orbit are candidates to contribute to the color.
YES !!! This is what I've been trying to get across when I talk about 24-bit coloring methods. Somehow we always end up talking about floating-point escape time and palettes...

Earl, this was a nice repost, thanks ! I must have missed the original article, or else I wasn't yet subscribed to fractal-art at that time. I like your idea of building a collection of light "sources" in the plane and then using a candidate Z point from the orbit to pick the color based on its position in the plane. As far as I know, this is a totally new and novel way to color fractals !
For more help in visualizing your color schemes, have you thought about drawing the light source color plane itself ?

[Rich Thomson] For more help in visualizing your color schemes, have you thought about drawing the light source color plane itself ?
Yes, actually this is very easy. I give the fractal a maximum iteration of 0 and plot the final z value. 

[Earl L. Hinrichs] Forget about computers. Imagine that you are painting on a canvas. Imagine that someone imposed the above requirement, you can paint anything you want, but the color transitions had to follow the above rule. I doubt that any artist would accept that limitation. But every fractal artist that uses a palette and escape time are accepting that limitation.
I am getting too verbose. Anyway the three functions should coordinate with each other and the fractal in some reasonable way to make an interesting picture.
There are two points in the preceding that deserve further emphasis. First, base the color calculation on the entire fractal. More precisely, base it on any or all of the points in an orbit, not just the last value, or not just on the first time the orbit exceeds a predetermined limit.
All of the points in the orbit are candidates to contribute to the color.
Second, avoid one dimensional intermediate steps. A palette is a map from a one dimensional space to the color space. The continuous extension of a palette is a map from a one dimensional space. If you convert z to |z| before computing the color you are mapping from a one dimensional space. (OK, technically the domain of the palette function is a finite set of integers which has dimension 0.)
A couple of points I'd like to add to this discussion. First, an important clarification I'd make is on how the questions/answers for the FAQ I wrote on fractal coloring were somehow misconstrued lately. Rich Thompson has commented that the FAQ centered around escape-time (iter) for coloring. There are other coloring methods drawn on in the FAQ including magnitude and angle-based methods. Escape time was only used as a starting point in the FAQ. As J.P. Louvet mentioned, I didn't feel comfortable speaking therein on behalf of other fractal artists, such as Earl, who have quite intricate methods of coloring.
Earl has made his point succinctly on a number of occasions, and I am just beginning to digest some of his methodology for my own use (no plagiarism intended.) But what Earl may not realize, that others may have already discovered, about the methods he suggests --
one : there is a technical background that is presupposed that few fractal artists (except programmers) are likely to possess,
and two : given that background exists, the ability to use colors effectively in his manner is tricky to say the least. It takes a great skill to manipulate colors Earl's way, sight unseen, as great or greater than any brush painter's. So most fractalists might be more comfortable with a palette-based fractal program to start with, than a program that used only Earl's methods of coloring.
Even great painters like Picasso went through various stages in their careers, like what might be termed "blue period", for example. Using a palette doesn't necessarily limit you, when you can design a palette from 16 million colors. The nature of certain color combinations to suggest moods is a major advantage of palette-based fractals. More important is finding a set of colors that "work" for an individual fractal. Beyond fractals, and this is Earl's strongest advocate, is his ability to see through "fractals" to an art that embraces both fractal science and the unbounded scope of computer art in general.

[Terry W. Gintz] But what Earl may not realize, that others may have already discovered, about the methods he suggests --
one : there is a technical background that is presupposed that few fractal artists (except programmers) are likely to possess,
Agreed. Recently on the fractint list someone was asking some fundamental questions about colormaps -- the whole concept of computer representations of color was new to them. Sometimes us techie types can lose sight of this. I recommend that everyone (even the techie types) go and read that Color FAQ I mentioned the other day. (There are nice PostScript and PDF versions that you can download and print to keep the formulas, etc., intact.) The FAQ describes many of the nagging details that an artist will face in using the computer to generate color pictures. They are too numerous here to go into, but there is a very nice explanation of things like taking an RGB image and printing it with a CMYK ink process and so on. He is necessarily terse in the FAQ, but fortunately he gives a good bibliography for those who wish to dig deeper into any subject. And, being a collection of Frequently Asked Questions, you can skip the parts you don't need to know.
and two : given that background exists, the ability to use colors effectively in his manner is tricky to say the least. It takes a great skill to manipulate colors Earl's way, sight unseen, as great or greater than any brush painter's. So most fractalists might be more comfortable with a palette-based fractal program to start with, than a program that used only Earl's methods of coloring.
I agree once again ! :)
I have been wondering lately if there are any tools that might help out people in this regard. I'm thinking of a program that can generate fractint .map files with the capacity to :
- extract colormaps from other GIF files
- extract colormaps from 24-bit files via quantization methods
- combine 2 (or N) colormaps in some algorithmic way (add them together, select entries at random, etc.)
- use a few "tried and true" techniques for generating gradients and ramps.
Do Kai Power Tools gradient tools let you just create the colormap and save it out ?
It seems there is some fertile ground here for a colormap exploration tool. I'm all in favor of making the algorithms and technological artifice "disappear" behind an interface that's so easy to use, people don't even think twice about what's happening in terms of the computation. 

[Earl L. Hinrichs] All of the points in the orbit are candidates to contribute to the color.
[Rich Thomson] YES !!! This is what I've been trying to get across when I talk about 24-bit coloring methods. Somehow we always end up talking about floating-point escape time and palettes...
Well, why not write a paragraph or two for the FAQ explaining this ? I also suggest providing simple examples, and giving names to the simple examples, so that everyone can use the same terminology. e.g. some that I've played with are :

n	escape count
|z|	modulus
Ph(z)	phase of z, goes from 0 to 2pi radians (0-360 degrees)
Sign(re(z))	which half-plane the last pointed ended on ...
|zn - z(n-1)|	length of last hop
Ph(z(n)-z(n-1))	direction of last hop
n*z(n)+(n-1)*z(n-1)+ ...	weighted average of last z's
|z(n)-z'(n)| where z(0) and z'(0) differ by small amount	called ??
log of above	lyapunov exponent (modified)
|z*z/c|	don't have a name, but gives very good, interesting colorings !!
Ph(z*z/c)	etc.

In the end, the possibilities are limited only by the imagination.

[Linas Vepstas] Well, why not write a paragraph or two for the FAQ explaining this ? I also suggest providing simple examples, and giving names to the simple examples, so that everyone can use the same terminology.
I started this thread to get more information for the FAQ, but the results is far beyond what I expected (variety and very high quality of the postings). Therefore I think now that I opened a Pandora's box, and everybody writing a concise (and impartial) summary will be welcome !
.......................
Don't forget that all this is for art (even if some technical information are needed) : only a few painters know the theoretical chemistry underlying paints or the behavior of electrons responsible of colors of pigments !

[Rich Thomson] combine 2 (or N) colormaps in some algorithmic way (add them together, select entries at random, etc.). Do Kai Power Tools gradient tools let you just create the colormap and save it out ?
MetaCreations to my knowledge has never divulged the file format for their KPT Gradient Designer plug-in, and it has changed from version 2 to version 3. In the Mac version of this plug-in there is a "Layer Bin" (try SHIFT-L or Command-L to bring it up) which lets you combine existing gradients in interesting ways. However, there is a bug in this feature and you can't save the results, even in KPT's own format.
I have never had the time to try to reverse-engineer the gradient file format, and a friend of mine who tried was unsuccessful. (He didn't spend much time on it.)
I'm all in favor of making the algorithms and technological artifice "disappear" behind an interface that's so easy to use, people don't even think twice about what's happening in terms of the computation.
You have my vote for that. However, I also vote for making that interface just a mask--one that can be removed at will by the technically inclined. My biggest complaint with gorgeous interfaces like KPT is the inability to specify cold, hard numbers by folks who want to do that. (But don't get me started on KPT's interface, I can go for hours. :)

[Rich Thomson] I'm all in favor of making the algorithms and technological artifice "disappear" behind an interface that's so easy to use, people don't even think twice about what's happening in terms of the computation.
[JPL] What a good remark !!!
Thanks :). The best example I can think of in this regard is Kai Power Tools. The algorithms and techniques that are being used are quite complex and powerful, yet the interface is so easy to use you just run with it and don't think twice about the technology !

[JPL] Don't forget that all this is for art (even if some technical informations are needed) : only a few painters know the theoretical chemistry underlying paints or the behavior of electrons responsible of colors of pigments !
Well, two comments :
1) artists still need to understand the drying time of oils, the solubility of watercolor, the variety of chisels used for marble as opposed to wood sculpting, the lost-wax process. Art has always a fairly technically sophisticated process -- in the middle ages, artists had to make their own pigments, search the land for clay deposits that were just right for ceramics, and in modern times, understand film, film chemistry, printing intricacies, etc. So almost all artists are grounded in a fairly huge amount of technical knowledge, whether they realize it or not.
2) To keep it simple, you could make the faq be a "how to use fractint", but I don't think that's what you want. Given how the software must always lag behind the latest technical developments, some artists will want to know about the latest theories and techniques. Watering it down too much can be an insult to the readers intelligence.
Don't confuse "technical" knowledge with "scientific" knowledge. Electricians and auto mechanics need a lot of technical knowledge to do their work, but this hardly means that they understand theoretical chemistry of combustion or the behaviour of electrons in wires. Or closer to home : photographers understand f-stops and lenses; this does not imply that they understand the theory of refraction. However, implying that they don't need a good grounding in film and lens properties would elicit derisive cries from most pro's.
Nothing in the FAQ even remotely begins to approach "science", and its not clear that it even provides a good "technical" introduction. Don't water it down for the sake of watering it down.

[Linas] Well, two comments :
1) artists still need to understand the drying time of oils, the solubility of watercolor, the variety of chisels used for marble as opposed to wood sculpting, the lost-wax process.
(snip).....
Nothing in the FAQ even remotely begins to approach "science", and its not clear that it even provides a good "technical" introduction. Don't water it down for the sake of watering it down.
I agree mostly with you, and in spite of the fact that my students will be technicians I always emphasize that it is necessary to understand (to some extent) the theoretical background.
But I also like to be provocative... and from your last sentences I think that you also...
Most seriously I wanted to say that theoretical knowledge must be explained to be understood by non-specialists (and not only by the ones who already know the domain).

And maybe I should have stressed the difference between artist and artisan :
The great artisan achieves beauty through the mastery and perfection of technique; the great artist achieves beauty through striving for beauty.

[Rich Thomson] I'm all in favor of making the algorithms and technological artifice "disappear" behind an interface that's so easy to use, people don't even think twice about what's happening in terms of the computation.
That should definitely be the goal for all software. Paraphrasing somebody, 'make the difficult easy, and the impossible possible'.
It seems that putting an intuitive interface on fractal exploration is particularly challenging in some ways, because you have a fundamental conflict between speed, generality and accessibility. Choose any two.
I think its made particularly challenging because fractal calculations may have a wider range of calculation times than any other type of commonly used software. It is easy (especially with deep-zooming) to have some images that take one second to generate, and others that take a month. How does one create an intuitive and fast interface that handles both those extremes !
I (biased remarks follow) think Fractal eXtreme has done a great job on a lot of aspects of this problem - it's certainly a heck of a lot easier to use than FractInt. Click-drag to pan, double-click to zoom, control-click to rotate, shift-click to interactive zoom - all animated so that you can see what happened. You can't get any simpler than that. But, it doesn't have the flexibility of FractInt, so again : choose any two.

[Terry] But what Earl may not realize, that others may have already discovered, about the methods he suggests --
one : there is a technical background that is presupposed that few fractal artists (except programmers) are likely to possess, and
two : given that background exists, the ability to use colors effectively in his manner is tricky to say the least. It takes a great skill to manipulate colors Earl's way, sight unseen, as great or greater than any brush painter's. So most fractalists might be more comfortable with a palette-based fractal program to start with, than a program that used only Earl's methods of coloring.
I think Terry is complementing me here, so I probably should just shut up. But that is difficult for me.
Having a mathematics and programming background does enable me to visualize something, then imagine the mathematics required to create the vision, and then code the math into a program. (Sometimes the results are what I wanted to achieve, more often the result is less than desired, and on rare occasions it is more.)
However, this is something that is done very rarely.
You might classify my program as a "programmer's program". I make strong use of the object oriented programming features of C++. My user interface exposes the underlying C++ objects. Constructing an image amounts to linking various objects together. The UI is not a sophisticated as someone (Rich Thompson, I think) suggested, where you drag and drop icons representing objects and set the connections between them. Rather I pick a name from a menu of objects that fill a particular need. I have domain objects, calculation objects, trap objects, boost objects, color objects, and some more.
When I am in "artist" mode, as opposed to "programmer" mode, I do not think about the math or the programming in the objects. I operate, as I am sure more fractal artist do, on as much experimentation and discovery as construction. Past experience with using an object guides me, not knowledge of the internal workings of the program. "I wonder how this fractal will look with this other coloring scheme."
"This area looks interesting, I think I will zoom in over here."
I have described a "sine waves of color" coloring method. Originally I went through a "programmer mode" process where I conceived of a desired effect, figured out the math, wrote the code to put the object in the program. But once done, I forgot about the technical details. This color object comes with a dialog box that contains entries for fifteen real numbers. These numbers control the center of the light source, and the period, phase and amplitude of the sine waves for each of the three color guns. (All come with suitable defaults so I can get a reasonable effect without changing any values.) When I use the dialog box, I do not think of the mathematics. I think things like
"I want more blue, changing this value turns up the blue."
"The red transition is too sharp, I want to smooth it out".
"This would look better if I moved the red bands just a little bit."
In my program, the UI is just entering numbers. But, with a little bit of programming effort the numbers could be represented by slide bars and dials.
The point to this lengthy post is that I do not think these methods require any special skill or intuition to use.

[Terry] But what Earl may not realize, that others may have already discovered, about the methods he suggests -- one : there is a technical background that is presupposed that few fractal artists (except programmers) are likely to possess, and two : given that background exists, the ability to use colors effectively in his manner is tricky to say the least. It takes a great skill to manipulate colors Earl's way, sight unseen, as great or greater than any brush painter's. So most fractalists might be more comfortable with a palette-based fractal program to start with, than a program that used only Earl's methods of coloring.
[Earl] I think Terry is complementing me here, so I probably should just shut up. But that is difficult for me
I think I am agreeing with Earl when I state the following :-)
The various coloring methods Earl describes can be boiled down to a bunch of routines that can be given names, and selected from a menu. This should allow anyone to use them. Think of all the people who use photoshop or the gimp, without their understanding the math details behind a convolution, a laplacian, an edge detect, etc. This doesn't stop people from picking these from the photoshop/gimp menus... The remaining work is to
1) write a clear and concise description of a number of these tricks,
2) give them catchy but accurate names,
3) write the code needed to implement them, and put that code in fractint or your favorite program, and
4) create the menu in fractint or whatever, and
5) unleash it on the world !
Over the last year, Earl & I (and others ??) have attempted to do #1 in various ways. But #1 is not complete, and #3, 4, 5 hasn't been done for the popular packages. So again, lets try for #1. If its not appropriate for the main fractal faq, how about a "how to color faq" on the side, so that the contributors to fractint etc. can get on with it !