Color Management
In 3D graphics, a color space refers to the range of colors that can be represented and displayed. It is used to represent colors in a way that is meaningful and consistent across different devices and platforms.
In our Viewer, we separated between the Linear color space and the RGB color space. Linear color space and RGB color space are both used in 3D graphics, but they have different properties and are used for different purposes.
Linear color space is a way of representing colors in a way that is perceptually uniform, meaning that the difference between two colors is proportional to the perceived difference between those colors. This is important for realistic lighting and shading in 3D graphics, as it allows for more accurate representation of how light interacts with objects. Linear color space is typically used for rendering, compositing, and color grading in the film and visual effects industry.
RGB color space, on the other hand, is a way of representing colors by combining different levels of red, green, and blue. This is the color space used by most computer monitors and displays, as it allows for a wide range of colors to be represented. RGB color space is typically used for image editing, digital painting, and web design.
It's important to note that the RGB color space is non-linear and therefore a linearization step is required before doing any color correction or grading, this step is called "Gamma Correction" and it's used to map the non-linear RGB values to Linear Space.
Color Management in ShapeDiver
In three.js, the 3D graphics library that we use, the internal color space that is used is the Linear color space. This means that three.js also expects all colors that are provided to be in Linear color space. Although, there are new settings to adjust this, we found it the most transparent to implement this part ourselves. See here for more information about the color management in three.js.
In our viewer, until recently (changed with 2.7.0), we also expected all colors to be in linear color space. As we have now noticed that this is an issue for the workflow of many of our users, we introduced a new setting (automaticColorAdjustment) that enables an automatic color correction.
If this setting is enabled, it assumes that
all colors that are provided as numbers are in Linear color space
all colors that are provided as an array of numbers are in Linear color space
and all other color representations are in RGB color space
For the colors that are already assumed to be in Linear color space nothing happens, as this is already the color space that is used internally. For all colors that are assumed to be in RGB color space, a conversion to Linear color space is done.
Texture Color Space
As color spaces are not only a topic for colors themselves, but also textures, we provide an additional setting to change the color spaces of textures (textureEncoding). Please note that these changes are only applied to textures where it makes sense to use different color spaces than the linear color space. These textures are the map and emissiveMap, which are by default assumed to be in RGB color space.
Output Color Space
Not only for the incoming textures the color space can be changed, also for the outgoing texture this can be done (outputEncoding). This is the final rendered image you see on the screen. There are not many use cases where this setting should be changed to the Linear color space, but we want to provide our users the freedom to do so.