Home > Features > Version 2.0 > 

Gamma-Aware Workflow

Filter Forge 2.0 takes the first step towards a gamma-aware workflow – it introduces a set of simple options allowing you to configure when and how Filter Forge applies gamma correction to images it loads or saves. Filter Forge's gamma handling is condensed into two methods – the first one is for people who just want their images to look consistent with other image-editing applications, and another for graphic nerds who get mad when something messes up the RGB channel values somewhere along the way:

Essentially, the first option ensures that all images are encoded in monitor gamma after they are loaded into Filter Forge, and the second option allows the images to be loaded into Filter Forge without any corrections. The first option represents the default workflow, while the second one is useful for people who perform bitmap-based computations that require the pixel RGB values to be left intact.

However, all this is far from being a complete solution to the gamma problem – it's rather just a first baby step. Read on.

The Gamma Problem

Gamma correction is a nerdy topic that nobody wants to understand – but, as you shall see, it is important. Nearly half of the people who participated in this CGTalk poll have admitted that they "never quite understood that topic" or just have no idea about it. However, almost 30% of participants of the same poll "have a fully linear workflow and everything under tight control" – and they claim that, at least for 3D rendering applications, the results are well worth the effort.

But, you might say, Filter Forge is just a 2D bitmap generator, not a 3D renderer, so we don't need all this gamma hassle, right?

Wrong.

Just look at the Dalai Lama scaling test in the article above and try it in your image-editing app. This simple test demonstrates that even basic, fundamental 2D operations like downsizing a bitmap can be totally screwed up if they don't handle gamma correctly. What's even more scary is that almost every graphic software on the market – including the mighty Photoshop – has the same error! Filter Forge is no exception – the current beta doesn't pass the Dalai Lama scaling test when working with nonlinear images, e.g. JPEG photos (however, it does pass the test if you use the new options to turn the gamma correction off and load an image with linear gamma, e.g. an OpenEXR file.)

The solution is to switch to a fully linear workflow. In case of Filter Forge, it would look like this:

• Any non-linear input images, such as JPEG photos, are linearized, i.e. converted to linear gamma, on loading. Color picker colors are linearized as well before getting passed to components or renderer. HDR images such as OpenEXR are assumed to be linear, so they should be loaded without linearization unless they explicitly specify a non-linear gamma (in general, Filter Forge should respect the gamma value specified in image files, but it remains unclear whether it is possible to handle gamma correctly when Filter Forge is called as a plugin from a host application). Note that any "data" textures and colors such as normal maps and height values should be left "as is" – they shouldn't be linearized.
• All internal calculations are performed in linear color space. It so happens that we already do everything in linear, with the exception of lighting, which assumes its diffuse map to be non-linear and linearizes it, adds the light, then gamma-corrects the result back to monitor gamma.
• The output image and any previews are corrected back to monitor gamma, unless the output image is an HDR image or a "data" texture such as a specular, bump or normal map.

The Dilemma

We now face a dilemma. On one hand, we could implement a fully linear workflow that would let Filter Forge deal with bitmap data in a more physically correct manner and deliver better results when it comes to image scaling, bilinear and bicubic filtering, anti-aliasing and lighting. On the other hand, there is a deeply ingrained, decades-old workflow that almost everyone in the industry is used to ("hey, it gets the job done and my clients like it, so why bother?") – and if we deviate from it, a lot of people will get confused about why the same operations in Filter Forge and Photoshop produce different results.

So, should we implement a linear workflow in Filter Forge? Is there a demand for that? Will it scare you off? Should it be default or optional – and if optional, should it be per-filter or per-program? What extra gamma-related options would you like to have? Let us know what you think!