This coloring merges several waves of colors or varying brightness of different periods into one another, and with the gradient, which can be mapped linearly, by a power, or exponentially. It takes some getting used to but when used on deep mandelbrots (or, especially, whole zoom movies) its advantages particularly shine.

With a simple gradient, if it's mapped linearly it tends to highlight the features away from the minibrots and other "deep features", whereas the latter get several copies of the gradient compressed into them and become a low-contrast fuzz or weakly-banded color. If it's mapped logarithmically, the gradient highlights deep details at the expense of the shallow features becoming faint and poor-contrast.

This scheme is designed to be capable of producing contrast for features at many different scales at the same time. At the same time it can "discover" interesting new colors and color combinations for you, and it generally produces a pleasingly complex gradient over almost any image.

There are a lot of parameters, but many have parallel behavior.

Exponent (re)Exponent (im)

Default 2; set this the same as for the Mandelbrot formula on the Formula tab to get proper smoothed iterations for your Mandelbrots. Should work for Julias too.

Hue 1AHue 2AHue 3AHue 4AShort hue shift period (iters)

The four colors here will be interpolated cubically, similar to a UF gradient with those colors at positions 0, 100, 200, and 300, and the resulting gradient will be mapped linearly (if the color tab's transfer function is left at its default) to iterations, repeating every N iterations where N is the value of the fifth parameter.

Hue 1BHue 2B...Hue 4ELong hue shift period (iters)

Another 16 colors, in blocks of 4. The cycle of A colors above will gradually permute into a cycle of the B colors, then the cycle of C colors, then D, then E, and back to A. This longer cycle will repeat every M iterations where M is the value of the 17th paramerter.

Actually, the "long hue shift period" can be set comparable to or even shorter than the "short hue shift period". If it's much shorter, the effect is for the five 1 colors to form a cycle and change gradually to the five 2 colors, then the 3s, then the 4s, and then back to the 1s -- so you get four cycles of five colors each instead of five cycles of four each. If the two are comparable, the results are more complex. The A colors will cycle, but at the same time they'll be changing to the B, C, D, and E colors and back to A. The color to iteration assignment will still vary smoothly, but it may vary more chaotically, which may be desirable, particularly for making striking still images.

As the name implies, intended to be used to slowly shift the whole of the above on even longer iteration scales, particularly to vary the scheme during very deep sequences or to highlight highly-layered structures, such as deep embedded Julias, that will be repeating.

However, it can be given any period, even a very short one.

Superslow bias modeSuperslow bias sensitivity

Determines how the superslow bias gradient is merged with the gradient described previously.

Default is HSL bias, in which the sensitivity setting does nothing. In HSL bias, it is similar to if the first gradient were applied to the layer by itself and the second gradient were applied to a copy of that layer and the layers merged with "HSL addition". However, unlike HSL addition, HSL bias avoids a) discontinuities that HSL addition sometimes induces when a low saturation color is involved and b) whiting out or blacking out. The HSL bias luminance "addition" has the property that adding bright colors tends to approach maximum luminance (white) asymptotically; likewise black is approached asymptotically at the other end. Saturation addition behaves similarly.

Like with HSL addition, the neutral color for HSL bias is a 50% saturated, 50% luminance red.

The other bias option here is saturation bias. Saturation bias merges in a manner that doesn't resemble any of the layer merge options. Instead, the superslow cycle color acts as a selective filter on the underlying colors from the first gradient. Colors similar in hue come through unaffected while colors different in hue lose saturation towards grey. The result is that you can make the first gradient produce, eventually, a full rainbow over tens of thousands of iterations and use the superslow bias to cause some deep areas to be biased towards particular colors, such as reds. Where the superslow bias color is less saturated, the bias effect itself is weaker; the luminance is added to the underlying color's with asymptotic behavior exactly as for HSL bias. The superslow bias sensitivity affects how fast colors desaturate as the hue moves away from the superslow bias hue. So one can have a narrow range of shades of red not desaturate, or have anything vaguely reddish not desaturate and only blues and greens desaturate, or in-between.

All of these superimpose cyclical luminance variations of specified periods on the gradient. It is generally good to tune these to the "iteration sizes" of important features. As with other luminance additions here, white and black are approached asymptotically.

To find a good period to use you can experiment, or you can be more analytic. Consider an image of an embedded Julia set deep in a seahorse tail. You probably want one luminance shift period set short, such as a few iterations up to 20-30 iterations, with a lowish amplitude such as 0.1 or 0.2, to add some interest to the empty areas between seahorse tails. For the next one, consider duplicating the image, zooming in tight on a seahorse tail in the image, noting the minimum iterations, going a couple of windings deeper into the spiral with another zoom, and noting the new minimum iterations. (You'll want the Statistics palette displayed for this.) The difference is probably a good period for another luminance shift. The difference between a seahorse's surroundings and a tight zoom into its "eye" is probably another good choice, and the difference between the main image's minimum and a zoom in the embedded Julia set another, so the embedded Julia features will receive contrast. Usually, though not always, the longer the period the larger the amplitude ought to be.

You can also use the three coloring periods above to tune to features. For example, for the same image you may want to make the short hue shift period about twice the seahorse edge-to-eye iteration span, so each seahorse shifts through two or so of a cycle of four hues from edge to center, and make the long period such that one cycle takes over from another between the image edge and the embedded Julia features. Further zooms (or a movie) would segue into additional cycles at each level of fourfold, eightfold, etc. embedded Julia if the long hue shift period was tuned right.

Primary gradient merge mode

This controls how the UF layer gradient is combined with the gradient produced by the above. HSL bias does as described previously: an improved HSL addition, in essence. RGB bias makes the gradient behave a bit more "intuitively": where the gradient is red, the image will be red(dish), and so forth. A 50% grey is neutral for RGB bias. The more saturated a main gradient color, the more the generated gradient from above is tinted toward that color. Luminance is biased as usual. RGB blend uses the main gradient's opacity: where the main gradient is opaque it completely determines the color and where it's transparent the generated gradient shows through. Where it's translucent, the two are blended similarly to an overlying layer with Normal merge mode and varying opacity. HSL blend is HSL bias with opacity influencing things somewhat. Hue addition is unaffected, but the saturation and luminance addition is weakened by transparency. Theoretically, the same effect can be obtained simply by using HSL bias and moving the main gradient color towards 50% luminance and 50% saturation, but it may be advantageous to be able to weaken or prevent saturation addition while keeping the main gradient hue at full saturation, and it may be simpler to create the gradient if the color changes and sat/lum changes are largely uncorrelated in position (as opacity has an independent set of control points to color in UF's gradient editor).

These affect how the main UF gradient is mapped into iteration-space. Without "Fit Gradient To Range" its first color will apply until Start iteration, and then it will repeat endlessly. With "Fit Gradient To Range" it will be fit into the range from Start iteration to End iteration, and repeated Number of repetitions times. Iterations higher than End iteration will get the gradient's final color.

Because changing the Transfer Function setting at the top from Linear will affect everything, including the gradient generated by all the wave cycles above that is preferable to map linearly to iterations, a Super transfer function setting is supplied to affect the UF gradient component only. It can be linear, power (set with Transfer power), or log. Log with start iteration the image's lowest iteration and end iteration the image's highest iteration tends to work best for isolated still images.

The UF gradient can be used to adjust things where one is unsatisfied, or to add an overall trend to the coloring; for example, if it's logmapped from the start iteration to the max iters, set to HSL bias, mostly a hue 0 saturation 0.5 luminance 0.5 red, but with a quick curve up to white at the right end, it can highlight a minibrot and surrounding filaments in white.

Bail-out value

Use same as for normal smoothed iterations.

DisplacementRescaling

Can compress or slide the whole shebang. Displacement, in particular, can be useful for testing before rendering a zoom movie: rather than render, slowly, lo-res previews of deep parts to see if the colors look good, one can find a very similar shallower structure that renders much faster due to lower precision and iterations and use displacement to temporarily shift the whole gradient left. Use the difference between the minimum iterations of the deep image and the minimum iterations of the shallow image to make the shallow image use the colors the deep one will have while tweaking the settings to get that area looking nice, then set the displacement back to zero.

Rescaling is useful for fixing up your final minibrot's filaments. The final minibrot will be slow to even preview, for a deep zoom movie, so one only wants to have to render it a few times. Render a low res preview for long enough to find out the minimum iterations and how high they get in a filament close to the minibrot, and note both numbers. Then find a shallow minibrot and find out the same numbers for that. Then you can use displacement and rescaling to map the colors that will be used for the deep minibrot to the shallow minibrot image in a similar manner. Then tweak the color scheme (probably the superslow bias, the logmapped UF gradient, or both) until the filaments stand out nicely how you want them to, and return to the deep minibrot and to displacement 0, rescaling 1.

Anyway, this is an amazing way of coloring the Mandelbrot set and emphasizes the true beauty of this fractal without directing attention away from anything. I will use this for all my renders and zoom movies. Thank you.

* Renamed "superslow bias" to "overlay bias" since it doesn't really have to be slow.

* Added "random color" parameter group. After the random color start iteration, colors start to be biased randomly. The bias color changes every so many iterations, set as the random period. The random seed gives a different set of bias colors, the luminance range limit corrals the luminances of the random colors to within a band of that width about 0.5, and the hue variation parameter limits how different adjacent random colors can be. Saturated bright colors are bound to within that many hue points of their neighbors, while less saturated colors, darks, and pastels get more leeway. Anything from 2 on down prevents, e.g., bright green and bright red abutting.

* Internal color calculations no longer use hues from 0 to 6 with red, yellow, green, cyan, blue, magenta equally spaced on the hue wheel, but instead hues from 0 to 8 with red, orange, yellow, yellow-green, green, cyan, blue, magenta equally spaced. This corresponds more closely to the human brain's color processing, which seems to use a red/green and a blue/yellow axis at right angles, and a luminance axis at mutual right angles to those. As a result, small hue additions can move blue to magenta and red to yellow but not red to green, which is more dissimilar-looking to red than blue is to magenta. Interpolation of colors also uses this new coordinate system: rg, by, lum. The exception is that the UF version still uses ordinary rgb interpolation for the main UF gradient, since UF provides no way to override this.

A consequence of the above is that if you set the first two hues in the parameters to saturated red and green, and the period short, you'll get grey or a very low saturation color instead of yellow in between.

* The four luminance waves use a sine curve instead of a four-segment spline curve and now have added phase parameters, which should be between 0 and 1.

This coloring merges several waves of colors or varying brightness of different periods into one another ... This scheme is designed to be capable of producing contrast for features at many different scales at the same time.

This reminds me of the fractal antenna, which profile repeats itself at several scales...

Interesting.I do something similar with multiple renders in Fractal Extreme and layering the results with avisynth or GIMP.Its a lot more convenient to have the tools right there in your fractal explorer.Its a lot less convenient to have that fractal explorer re-calculate every time you change a colour or mapping.Am I missing a setting in UltraFractal with this annoying recalculation?Or is it crippleware feature?If I paid for UF would I be able to change colours without the recalculations?

Interesting.I do something similar with multiple renders in Fractal Extreme and layering the results with avisynth or GIMP.Its a lot more convenient to have the tools right there in your fractal explorer.Its a lot less convenient to have that fractal explorer re-calculate every time you change a colour or mapping.Am I missing a setting in UltraFractal with this annoying recalculation?Or is it crippleware feature?If I paid for UF would I be able to change colours without the recalculations?

Unfortunately, no. The friend I have with registered UF tested it and it still recalculates. That happens with all direct-coloring algorithms, apparently.

I notice the rendering time is a lot longer using the multiwave colouring.The standard of smooth mandelbrot took about 45 seconds, multiwave was estimated to take 7:50.I guess there are multiple layers (renders) involved?

I notice the rendering time is a lot longer using the multiwave colouring.The standard of smooth mandelbrot took about 45 seconds, multiwave was estimated to take 7:50.I guess there are multiple layers (renders) involved?

That shouldn't be happening. Not if you only use one layer in UF, and the same settings for the various calculation options.

Did you take a regular Mandelbrot with ordinary Smooth (Mandelbrot) coloring, then *only* change the Outside Coloring to MandelMultiwave?

That shouldn't be happening. Not if you only use one layer in UF, and the same settings for the various calculation options.

Did you take a regular Mandelbrot with ordinary Smooth (Mandelbrot) coloring, then *only* change the Outside Coloring to MandelMultiwave?

For that I had been alternating between standard, smooth and multiwave so I've made a more rigorous analysis. I kept to the standard gradient at first, changing to multiwave got me a black image so I rotated the gradient.That's where it gets interesting, the black image was actually quicker than the smooth (mandelbrot) colouring butthe rotated gradient got the worst time.Then I tried one of my complex all 400 indexes used gradients in case that was causing the problem.At least this did not give a black image when converting to multiwave.I guess its all highly dependant on the visible colours.

You're testing it on an image that has very low iterations and is just into arbitrary precision. The second version has a fair amount of math in it, which adds a bit of overhead per pixel. With arbitrary precision this can add a few minutes to the image calculation time. However, it would add the same few minutes if the image was taking hours, with ten thousand iterations typical for the pixels in it, instead of only a minute or so.

The older version has less overhead and gives almost no noticeable time difference.

It doesn't help that your computer is apparently fairly slow. (The times I get on a single box here are half yours.)