Filter Construction: Fundamental Techniques

What's supposed to be so special about "Blending" you say? Well, it's "Knowing Your Blend Modes" that is the key to harnessing the power of the Blend component and unleashing its great potential for efficiency unto your filters. Something as simple as choosing the right blend mode at the right time can very much 'make' a filter. Believe it or not, "Blending" is an art form that goes well beyond Blend components, as we shall demonstrate later.

But first, let us explore these blend modes and their usage. The above example shows a simple yet interesting use of the "Lighten" blend mode: Two boring grids of hemispheres are miraculously transformed into a sofa surface! Looks like only the buttons are missing now... ;)



Another example of the "Lighten" blend mode in action, but this time a bit more exciting! What appears to be a rather complex layering of scales is actually achieved in a very economic manner. Without this blend technique one would have to resort to rather tedious masking operations that would likely involve many more components than the above solution.

So what does this "Lighten" blend mode actually do? Well, it compares the values of R, G and B channels for both the foreground and background layers and selects the greater value for each channel. The three selected values are combined into a color to produce the result. As demonstrated by the example above, this blend mode is particularly useful in the creation of complex height maps, as it provides a convenient way to 'merge' height information.

Helpful filters for studying the use of the "Lighten" blend mode (among many other things!) are:

• Chain Mail by Constantin Malkov
• Rusty Chainlink by Mike Blackney
• Knitted Fabric by Constantin Malkov
• Vintage Clay Tile by Mike Blackney

Here we can observe the "Darken" blend mode at work. As its name would suggest, it is the opposite of the "Lighten" blend mode, as it compares the values of R, G and B channels for both the foreground and background layers and selects the smaller value for each channel. The three selected values are then combined into a color to produce the result. When examined in the context of height map creation, this blend mode acts as a carving operation that 'substracts' from the existing height map. Very useful!



The "Multiply" blend mode in action on two Blend components. This is another mode that comes in handy very often. However, let us examine the Checker component to the right of the two. In this special case, a blend operation with a checker mask was clearly called for. Instead of using the more obvious approach, which would have required an additional checkered mask as an Opacity input for a Blend component, the filter author went for another solution: The Checker component was used to directly combine the two sources, resulting in a solution that requires one component less.



You knew we'd boil this one down even further, didn't you!? Indeed! Let us examine the above example, which reduces the complexity by another two components. To be clear on this, Blend components are among the fastest components in FF, but it is always a thrill to reduce filters down to as few components as possible. The Profile Gradients are definitely there to stay, so this is about as efficient as it gets. As you can see by this example, we have already taken the "Art of Blending" beyond the use of Blend components.



Another example that achieves blending without actually using Blend components: Above we can see a multitude of nested Tiles components. The filter author took advantage of their 'inherent' blend capabilities by chaining them via the Tiles and Mortar map inputs. [Example taken from the Compact Discs filter]



The Threshold component is categorized as an Adjustment component, yet it can provide for very elegant solutions to certain masked blending challenges. The filter construction above is actually inefficient, because the full innate potential of the Threshold has not been taken advantage of. It has indeed been treated as if it were 'just' and Adjustment component, while it could in fact completely replace the Blend! Let's see how this is possible...



In our given scenario, the Threshold component creates a two-color version of a checkered noise field. Noise 'pixels' with a lightness below the Threshold value (as controlled by the Attendance slider) acquire the Low color (black), while those with a lightness above acquire the High color (white). The result constitutes an Opacity mask that was used to control the Blend operation in our initial example above.



Now, if we take advantage of the Low and High map inputs of the Threshold component, we can remove the Blend component altogether! We'll set the alpha value of the Low color swatch to zero and connect the Multiblend directly to the High map input, effectively substituting the black & white pixel field with meaningful image data (i.e. a horde of corporate smilies). Voila! The result is visually identical to what we started with yet more efficient! [Example taken from the Grin Inc. filter]

Additional Information on this topic:

• A brief explanation of blend modes
  

-- Crapadilla

Getting The Most (tm) Out Of Your Components



The screenshot above shows the Old Parchment filter loaded into the Filter Editor. Notice how the Perlin Noise has six outgoing connections to various other components' map inputs throughout the filter. Granted, connections going all over a filter do make its filter tree harder to read, but constructing a filter like this reaps huge advantages in effectivity and render-speed:

The renderer has an optimization called "sample cache" that can save a significant amount of rendering time in situations when a single component has multiple outbound connections. Note that this speedup will not occur when using duplicates instead of connections.



So what about these duplicates mentioned above? Consider this example: The two Techno noises above are identical, except for their Contrast value (one is set to zero, the other to 65). Since they have the same Variation (i.e. the parameter that controls the noise seed), they are essentially duplicate components. Constructing the Filter Tree like this forces FF to generate the same noise twice!



Let us assume that we do not need a second Techno noise with a different seed for our filter. We just want the noise color-corrected to feed it into some map input elsewhere. In that case, the solution is simple: Replace the duplicate Techno noise with a Brightness/Contrast component and set its Contrast parameter to a value of 65. By doing so, we are not only getting rid of another very slow component (the worley noise), but we're also taking advantage of the sample caching optimizations built into FF.



Another example: Here we have two Stones noise components that only differ in their Variation settings. Each of the noises has a different seed and thus effectively is unique, but the two are still similar enough that we might be able to cook up some simplification for this...



Hmmmm... replacing the second Stones noise with an Offset yielded a result somewhat visually comparable to our starting point. Sometimes we can get away with just warming up the same noise and serving it a second time, albeit slightly stirred! It appears that - again - Captain Efficient was able to get rid of another slow component. Cheers! :)=)



These two Perlin Noise components do have the same Variation, yet all their other parameters are completely unique, resulting in two components of radically different appearances. In this case there is no hope of approximating one by using the other as a base. Unless these noises become superfluous in the course of later construction works, there is nothing to simplify here. Of course, chaos fetishists might insist on setting different Variation values for the two components.



Let's examine yet another case: In the example above, a color map, a height map and a reflectivity map are piped through three Noise Distortion components. Since the distortion effect on all these maps needs to be identical, each Noise Distortion uses exactly the same parameter settings: They are exact copies that have the same Variation. Consequently, three identical copies of the same noise are computed, one by each Noise Distortion! Looks like a threefold waste, doesn't it?



Indeed! We can streamline this easily by replacing the Noise Distortion components with Offset components (See Reverse-Engineering Noise Distortion for more info). Mapping all their Offset H and Offset V inputs with a single Perlin Noise ensures that the sample cache optimizations are properly harnessed for all three distortions. Note that the result we have thus achieved is visually very similar to what we started with.

-- Crapadilla

In the following, the term "Order of Operations" is used to denominate the sequence in which image operations are performed (i.e. processed) by a filter. Inside the Filter Editor, operations are represented by components and the Order of Operations is defined by the connections between them, resulting in what is called the Filter Tree. An inefficiently designed Filter Tree with a bad Order of Operations can make for very poorly performing filters. Consequently, we shall closely examine this aspect of filter creation in the following section.

The evaluation of any given Filter Tree and its Order of Operations must rest on a solid understanding of how the different components perform in combination. The article "Optimizing Filters for Speed" serves as an excellent primer in this regard and is recommended as preparatory reading.



The image above shows the Filter Tree of the Wind Blur filter. Feel free to load it up in the Filter Editor while we are discussing it. I'd like to focus on a particular sequence of components, which I have marked in red: A Blur component (marked by a red ellipse), which is connected to an Invert, which in turn is fed into 24 (!) Offsets (marked by a red rectangle). Note that each of the 24 Offsets has different parameter settings courtesy of a remapped control slider.

The Order of Operations is quite clear in this case: The source image is blurred first, then 24 'copies' of this blurred image are created, each offset by a different amount, which are subsequently blended to achieve the final 'wind blur' effect. This Order of Operations makes sense since the Blur must be identical for all 24 copies, and thus it only needs to be calculated once.



However, the effect could also be achieved via a particularly bad Order of Operations: Take a look at the close-up above and imagine the Blur calculation were to take place directly after the Offsets were calculated (but before the final blending). In that case we would not only be dealing with 24 Offsets but also with 24 Blur components! Although the result would be visually identical, it would perform abysmally slow due to the additional Blur components present. Admittedly, this rather nightmarish scenario is quite unlikely to be encountered (due to FF authors generally being gifted with a good dose of technical sense), but it nevertheless illustrates how the Order of Operations could be designed to be very bad indeed.

Let's examine the Order of Operations under another important condition: User interaction. Whenever a user changes the value of a filter control, whole branches of the Filter Tree can become 'invalid' and must be recalculated. Filter controls that are located 'closer' to the Result component are likely to invalidate fewer components, while those located on far branches might force the whole Filter Tree to be recalculated. Consequently we can generalize that the 'closer' prominent (i.e. often-used) filter controls are located to the filter's Result component, the more interactive the filter becomes.

Coming back to our Wind Blur filter above, the most prominent controls are likely to be those that control core features of the 'wind blur' effect, namely its direction (Blur Angle) and the length of the wind streaks (Blur Length). These controls are anticipated to be tweaked often, forcing all Offsets to be recalculated frequently. Consequently it would be prudent to resolve any slow calculations present in the Order of Operations (like the Blur) before these Offsets. This - in addition to aesthetic considerations regarding the final look of the effect - is the reason there is no Blur component at the very root of the Filter Tree (i.e. near the Result component).

More examples will be coming soon, so stay tuned!!! :)

-- Crapadilla

Filter Forge processes four distinct image channels per component: Usually these are Red (R), Green (G), Blue (B) and Alpha (A). You can use this to your advantage in certain cases...

In this example, let us assume that each of the four grayscale images on the left must be noise-distorted. Since a grayscale image can be expressed by a single channel, the four images can be safely combined into one single RGBA data stream via an Assemble RGB and a Set Alpha component. After having undergone the Noise Distortion, the RGBA stream can then be disassambled into its component images again by the use of Extract RGB and Get Alpha components. Instead of using four (!) Noise Distortions, we have successfully boiled this operation down to a single one. Neat!

Be aware that the processing cost of the above setup may be higher than the uncombined solution, simply because it requires six additional components to do the channel-combining and channel-extracting. In cases similar to the above, using four Noise Distortions may actually be faster, depending on your filter tree. Most likely, this technique will lend itself to slow Processing components, but be sure to always test its performance against the uncombined method!

Note: Several components do not process the Alpha channel. The High Pass component for example leaves the alpha channel untouched. This is also true for most components in the Adjustment category.

-- Crapadilla, Sphinx.