Color maps

Being able to specify a mapping between scalar variables and parameters used for represent visually those variable is a recurring theme in visualization applications. An exemplary case is the transfer functions that map density to RGBA and opacity values in volume rendering with an emission-absorption optical model.

This specification describes the messages to deal with maps as a particular case of transfer function (TF). The more generic case will be addressed in a separate document.

This document follows the discussion initiated in by [https://github.com/HBPVIS/Lexis/pull/19]

Requirements

• Represent RGBA color maps with an independent TF for each channel. The basic TF definition should be reusable for the more generic case.
• Represent extra material properties such as light emission and contribution.
• The network representation shouldn't restrict the options in the implementation of a GUI editor.

Discussion

Defining a color map with control points only makes sense if the application shader is capable of computing its values at runtime. In other words, the shader has to be able to compute any value that resolves the linear/Gaussian/etc function defined by control points. That (heavy and incompatible with real-time rendering) computation has to be implemented for all technologies used by the shaders (currently c++, glsl, cuda, ispc, etc). If generalization is wanted in the form of a method of the color map event (implemented in C++), that method has to compute the transformation from the control points to a lookup table in order to feed the shaders. And in that case, why not simply expose the color map as a simple lookup table, and leave the control point management to the client application?

Why lookup tables?

Pros

• Generated by the UI.
• Used as is by the rendering engines, avoiding any kind of transformation in various technologies. Precision is defined by the sampling.
• More suitable for real-time rendering since value are precomputed

Cons

• Not as accurate as control point since the precision depends on the sampling rate

Why control points?

Pros

• Precision is infinite if the application can handle them, otherwise a single C++ implementation in the event does the job but looses the interest of using control points.
• Convenient for the UI.

Cons

• A lookup table is still required for convenience with existing (python or JavaScript) client libraries.
• Sending control points is not enough to define the transfer function. Other information such as tangents and type of algorithm (guassian, linear, etc) also need to be communicated to the renderer.

State owner

The UI holds the state of the transfer function, and overwrites any value held by the renderer.

To summarize

• The transfer function event is a set a lookup table (RGBA, and extra attributes) with variable lengths and a range of values to which the lookup table is applied.
• The size of the lookup table determines the precision of the sampling.
• The UI (or any client in general) is responsible for the state of the color map.
• The UI is responsible for generating the lookup tables, as well as the sampling rate according to its own capabilities (Control points, mathematical functions, custom color maps, etc).

Design

A simple event defines a range and a transfer function for each 'channel'. In our case, channels are the diffuse color, the opacity (alpha), the light emission, and the contribution to the geometry (how much of the geometry material is impacted by the transfer function). Each lookup table can have a variable number of values.

Message

namespace lexis.render;

table Color
{
    red: float; // [0..1]
    green: float; // [0..1]
    blue: float; // [0..1]
}

table MaterialLUT
{
    range: [double:2]; // Range of value to which the color map should apply
    diffuse: [Color]; // Diffuse color
    emission: [Color]; // Light emission
    alpha: [float]; // Opacity [0..1]
    contribution: [float]; // Contribution rate to the existing surface
                              material [0..1]
}