Tone mapping

In this chapter, we'll focus on tone mapping details. This completes the Tonemapping explained chapter with a deeper technical focus.


Task: Enabling tone mapping

RED::IViewpoint* iviewpoint = viewpoint->As< RED::IViewpoint >();
RED::PostProcess& pp = iviewpoint->GetPostProcessSettings();

RC_TEST( pp.SetToneMapping( RED::TMO_PHOTOGRAPHIC ) );

All tone mapping controls are available on the RED::PostProcess class instance of the viewpoint. Please note that the RED::PostProcess class is accessed directly, without any RED::State transaction parameter. Consequently, changing the tone mapper settings should only occur from the rendering thread, before or after a rendering call. This lets the calling application dynamically change the tone mapping of an image while its calculated.

Anti-aliasing and tone mapping

Many rendering engine force the user to choose its tone mapper settings before rendering the image. Once the image is calculated, it can't be modified, and if the tone mapper settings are not correct, another image has to be rendered. The technical reason for this way of doing calculations is generally related to anti-aliasing that gets broken if tone mapping is applied after the image calculation.

In REDsdk, this is not true: tone mapper settings can be changed anytime: during the rendering and after the rendering, once the image has been calculated. Tone mapping can even be applied just to an image that was saved earlier.

REDsdk has a special format for anti-aliased image, the RED::FMT_FLOAT_RGBA_AA. This format keeps anti-aliasing informations available for the tone mapper, so that tone mapping can be applied really as a post-process step, without the need for re-rendering the scene. It can even be applied from another executable, not necessarily the one that was used to render the image.

This is a key feature in REDsdk aiming at reducing the number of needed image calculations to get the right result.

GPU accelerated or software tone mapping

REDsdk has two implementations of the tone mapping controls: one is GPU based and the other one is CPU based. REDsdk will use GPU tone mapping whenever possible. This is a faster processing that takes less than 1 millisecond to complete. So:

A tone mapping only rendering loop

As mentioned above, REDsdk can be used to only apply tone mapping to a completed image. A typical software rendering application uses the following feedback loop to process an image:

Typical software rendering loop.

While the image is not complete, proceed with RED::IWindow::FrameTracing. Then, internally, REDsdk calls RED::IWindow::FrameDrawing and the tone mapping is performed on the actual software image result, which is refining iteratively. Once the image has beeen calculated, we can add another internal feedback loop. This time we'll explicitely call RED::IWindow::FrameDrawing (2), and we won't call RED::IWindow::FrameTracing (1) anymore after the completion of the image:

The tone mapping only application loop.

The first feedback loop - before image is completed - is identical to the case seen earlier. The second feedback loop that occur after is just calling FrameDrawing, instead of FrameTracing, after having specified images to tone map using RED::IViewpointRenderList::SetViewpointSoftImages. These images should have been retrieved after feedback loop (1), either calling RED::IWindow::FrameTracingImages or RED::IWindow::FrameTracingImageLayers.

Luminance control for animations or tiled rendering

Some specific rendering workflows require the knowledge of image luminance informations needed by the tone mapping beforehand. Among these workflows, two are typical:

Tone mapping works using luminance informations. There are two sources of luminance informations in REDsdk:

So, back to our two scenarios:

The ignore background option

the background can occupy a large place in an image. For instance on rendering a mechanical assembly, or an outdoor model, we can see large portions of the background in the resulting image. Sometimes the user wishes to tone map this background, sometimes not. In the example of a background photography, the user may want it to remain 'as is' while its model is still rendered and properly tonemapped. The RED::OPTIONS_TONE_MAPPING_IGNORE_BACKGROUND let the application control the behavior of REDsdk regarding the background.