"Gamma correction" is actually a data compression technique that relies on the non-linearity of our human visual system. It uses the limited number of bits to encode more dark levels where we are more sensitive to intensity changes while bright levels are more sparse. This is why floating point output formats don't need it as FP numbers are exponentially encoded by definition.
In order for V-Ray to perform mathematically correct calculations, input and output color data should be linear. The results should only be converted to a non-linear color space (such as sRGB) for display. This is called linear workflow.
By default the VFB (V-Ray Frame Buffer) has its sRGB option enabled, so you will see the original linear image with sRGB applied as a post-process. The files you save from the VFB or with VRayRenderer::VFB::saveImage()
will be linear like the actual data if saved in a floating point format such as EXR or VRIMG. On the other hand, most 8/16-bit integer formats implicitly save their data gamma-encoded (e.g. JPEG applies ~2.2 gamma for color encoding. Applications that read JPEG handle that and display the data in the required color space, gamma-encoded or decoded linear). Saving to such integer file formats with saveImage()
or from the VFB button also bakes any color corrections done in the VFB, including the sRGB conversion. So these files will look exactly like you see them in the VFB. This does not apply to EXR and VRIMG.
There is a good article on linear workflow (LWF) on CGArena.
The plugin that controls color mapping is called SettingsColorMapping. It has the following parameters:
|
The Clamp output option, when enabled, will have an effect regardless of the value of the Adaptation only option. |
The proper workflow for texture file assets is to control color mapping via BitmapBuffer
or RawBitmapBuffer
. They have a few parameters for converting the image file colors - transfer_function
, rgb_color_space
, gamma
.
The most important one is transfer_function
(also aliased as color_space
for backward compatibility). It supports the following values:
Most integer formats (bmp, png, jpeg, tiff) will require setting transfer_function=2
.
The gamma parameter is used only when transfer_function=1. Setting both transfer_function=1 and gamma=0.4545 will give similar (but not identical) result to setting transfer_function=2.
rgb_color_space
is а string parameter signifying the linear RGB color space of the texture. Possible values are:
If the OCIO environment variable is set or if the SettingsUnitsInfo::ocio_config_file
parameter is set, the value can be any color space available in the OCIO config. This conversion is applied after the transfer function. The parameter transfer_function
must be set, or else texture filtering will NOT work correctly.
The parameter |
These settings are also set by the VRayRenderer.setImprovedDefaultSettings()
method (along with others):
SettingsColorMapping.type=6 // 6=Reinhard mapping (plugin default is 0=linear) SettingsColorMapping.gamma=2.2 // close to sRGB (plugin default is 1.0); 2.2 will improve sampling of dark areas even if adaptation_only != 0 SettingsColorMapping.adaptation_only=2 // 2=only apply color mapping (plugin default is 0=apply both color mapping and gamma) SettingsColorMapping.linearWorkflow=0 // NOTE: this option exists only for legacy scenes |
This example demonstrates the differences between some of the color mapping types.
The Sibenik Cathedral model was created by Marko Dabrovic (http://www.rna.hr) and was one of the models for the CGTechniques Radiosity competition. |
As visible in the above images, the Linear multiply mapping method clamps bright colors to white, causing bright parts of the image to appear "burnt out". Both the Exponential and HSV exponential types avoid this problem. While Exponential tends to wash out the colors and desaturate them, HSV exponential preserves the color hue and saturation.