Color Picker Values are wrong in Gamma Corrected properties and profiled displays #39707

New Issue

Antonis Ryakiotakis · 2014-04-13T21:25:35+02:00

2014-04-13 21:25:35 +02:00

System Information
Ubuntu 13.10 64 bit, Geforce 540M GT, 8 GB RAM

Blender Version
5d79c26

Short description of error
Gamma properties in color pickers skip color management entirely.
This means that even if user has profiled his monitor (ESPECIALLY if) then
he gets sRGB colors without correction always.

Exact steps for others to reproduce the error
Will post later

**System Information** Ubuntu 13.10 64 bit, Geforce 540M GT, 8 GB RAM **Blender Version** 5d79c26 **Short description of error** Gamma properties in color pickers skip color management entirely. This means that even if user has profiled his monitor (ESPECIALLY if) then he gets sRGB colors without correction always. **Exact steps for others to reproduce the error** Will post later

Antonis Ryakiotakis commented

2014-04-13 21:25:35 +02:00

Changed status to: 'Open'

Antonis Ryakiotakis commented

2014-04-13 21:25:35 +02:00

Added subscriber: @Psy-Fi

Antonis Ryakiotakis self-assigned this 2014-04-13 21:25:44 +02:00

Antonis Ryakiotakis changed title from ~~Color Picker Values are wrong in Gamma Corrected properties and calibrated displays~~ to Color Picker Values are wrong in Gamma Corrected properties and profiled displays

2014-04-13 22:21:52 +02:00

Bastien Montagne commented

2014-04-13 23:00:46 +02:00

Added subscriber: @mont29

Troy Sobotka commented

2014-04-15 00:05:42 +02:00

Added subscriber: @troy_s

Troy Sobotka commented

2014-04-15 00:05:42 +02:00

This extends beyond transfer curve to primaries. This means the actual color cannot be correctly displayed ever, regardless of color space selected, including sRGB.

Antonis Ryakiotakis commented

2014-05-14 00:44:05 +02:00

Since this is more a TODO item for now I will archive it. I will mention it on Blender Institute next Wednesday though.

Antonis Ryakiotakis commented

2014-05-14 00:44:43 +02:00

Changed status from 'Open' to: 'Archived'

Antonis Ryakiotakis closed this issue

2014-05-14 00:44:43 +02:00

Troy Sobotka commented

2014-05-23 01:45:17 +02:00

I thought that I should add some relevant information, as solving this issue isn't quite as simple as it might first appear.

The general order of tasks for any given RGB color transform is relatively simple:

Linearize via inverting a color space's transfer / tone response curve.
Convert to absolute XYZ space via an RGB to XYZ matrix based on the source color space's color primaries.
Convert back to the destination RGB color space via an XYZ to RGB matrix based on the destination color space's color primaries.
Apply the destination color space's transfer / tone response curve.

The two matrices can be distilled down into a single matrix obviously, and the last step is only for display referred output.

For the Blender internal space, the RGB system is assumed linearized and scene referred. This poses a unique issue with correcting the color picker for any given display.

Most corrections will be in a 3D LUT format where a single RGB triplet is transformed into a single RGB triplet on output. However, the inversion of a 3D LUT results in a one to many collision, making inversion effectively impossible.

A color picker has the unique need to both display the color accurately and provide the ability to obtain the color not as the displayed value, but rather in the working space value system.

As it currently stands, the color picker is displayed using hard coded perceptually curved values, which Blender displays in the raw format, under the erroneous conclusion that the display will display the assumed sRGB primaries accurately. This will never be the case, hence the need to correct the picker's output.

So the first issue is to adjust the internal working linearized values to a perceptual model. Using a role would likely be prudent here, such as UI_perceptual. This would permit all UI to properly display gradients and ranges of colors in a perceptual intensity view, and is easily invertible as it is traditionally communicated via a 1D LUT.

Therefore, the theoretical inversion of the full color picker is entirely possible; invert the displayed picker's transfer curve via the 1D LUT and transform the primaries from the destination space to the working space via a matrix.

However, a properly corrected display output tacks on the 3D LUT to the tail end to correct the theoretical values to the unique properties of the given display. The following steps would happen, with the first two being outlined as above):

Working Space to Destination Display Output via Matrix (Combined RGB to XYZ to RGB).
Destination RGB values curved for intensity via transfer / tone response curve 1D LUT.
Format the picker drawing based on the output from above.
Destination RGB values corrected for display via 3D LUT.

In the final buffer, the values would be non-invertible.

It would seem necessary to keep an idealized copy of the color picker around to invert that avoids the final 3D LUT correction for display output, in order to keep the invertibility of the 1D LUT and matrix combination.

All of this would be sped up by keeping an OCIO processor around to perform the transforms rapidly.

I thought that I should add some relevant information, as solving this issue isn't quite as simple as it might first appear. The general order of tasks for any given RGB color transform is relatively simple: - Linearize via inverting a color space's transfer / tone response curve. - Convert to absolute XYZ space via an RGB to XYZ matrix based on the source color space's color primaries. - Convert back to the destination RGB color space via an XYZ to RGB matrix based on the destination color space's color primaries. - Apply the destination color space's transfer / tone response curve. The two matrices can be distilled down into a single matrix obviously, and the last step is only for display referred output. For the Blender internal space, the RGB system is assumed linearized and scene referred. This poses a unique issue with correcting the color picker for any given display. Most corrections will be in a 3D LUT format where a single RGB triplet is transformed into a single RGB triplet on output. However, the inversion of a 3D LUT results in a one to many collision, making inversion effectively impossible. A color picker has the unique need to both display the color accurately and provide the ability to obtain the color not as the displayed value, but rather in the working space value system. As it currently stands, the color picker is displayed using hard coded perceptually curved values, which Blender displays in the raw format, under the erroneous conclusion that the display will display the assumed sRGB primaries accurately. This will never be the case, hence the need to correct the picker's output. So the first issue is to adjust the internal working linearized values to a perceptual model. Using a role would likely be prudent here, such as UI_perceptual. This would permit all UI to properly display gradients and ranges of colors in a perceptual intensity view, and is easily invertible as it is traditionally communicated via a 1D LUT. Therefore, the theoretical inversion of the full color picker is entirely possible; invert the displayed picker's transfer curve via the 1D LUT and transform the primaries from the destination space to the working space via a matrix. However, a properly corrected display output tacks on the 3D LUT to the tail end to correct the theoretical values to the unique properties of the given display. The following steps would happen, with the first two being outlined as above): - Working Space to Destination Display Output via Matrix (Combined RGB to XYZ to RGB). - Destination RGB values curved for intensity via transfer / tone response curve 1D LUT. - Format the picker drawing based on the output from above. - Destination RGB values corrected for display via 3D LUT. In the final buffer, the values would be non-invertible. It would seem necessary to keep an idealized copy of the color picker around to invert that avoids the final 3D LUT correction for display output, in order to keep the invertibility of the 1D LUT and matrix combination. All of this would be sped up by keeping an OCIO processor around to perform the transforms rapidly.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Color Picker Values are wrong in Gamma Corrected properties and profiled displays #39707