[Bf-viewport] Color Management in the Viewport and UI in general

[Lukas Stockner]

Hi all!

Since the Viewport and generally all areas concerned with OpenGL are being overhauled for 2.8, this would be a great time to also think about incorporating Color Management into all UI aspects.

First of all, a summary of what's the issue:
OpenGL itself doesn't care about Color Management - the software writes a RGB triple, and it will be sent straight to the screen. Ideally, the same triple would always give you the same color.
However, that's not true for two reasons - first of all, screens aren't exact, every model and even every individual screen will deviate from the standard a bit.
Also, and even more importantly, there isn't just "the" standard - most screens (try to) conform with sRGB, and that's what Blender currently assumes. However, especially for professional graphics work, screens with a wider color space are often used. Especially now that new iMacs come with DCI-P3 screens, it's important to support that - to use an extreme example, even if the screen swaps green and blue, it has to be possible to configure Blender so that it looks as always. Of course that's not an issue that comes up in practise, but it helps to emphasize that CM really must be applied to everything that's drawn - if swapping channels isn't possible, then correct CM isn't possible.

The current state:
Blender uses OpenColorIO (OCIO) for color management. The user can select a display color space in the Scene options. However, that is only used for a few specific cases - for example, Cycles viewport rendering and the Image Viewer apply the correct transform, but the Viewport and UI elements don't. Also, the display transform is used for some things where it shouldn't be used, for example, to convert color values into Hex format in the color picker.
Another issue is that there is only one setting for all of Blender - when the user has e.g. a expensive wide-gamut monitor for color-critical work and a normal sRGB one for other things like modelling, there's no way to get correct colors on both, and the UI colors won't be consistent between them.

What should be done:
- First of all, it needs to be clear for every color value in which color space it is. Most colors are stored as float arrays, and for those the OCIO reference space is the obvious choice. For colors where storage size matters (for example, Images or Vertex Colors), precision becomes a concern (storing linear values in a 24-bit color isn't the best ides), so it must at least be clear from the context which space is used. For Images that already is the case, but for others it isn't.
- Then, the user must be able to select a different Display Color Space for every Blender Window in order to support multi-display configurations. This also means that caching the transformed values, like it's currently done for Images, is tricky because they might be different for every window.
- Finally, every color that is drawn to the screen has to go through a OCIO transform from the space in which it's stored to the correct display space. For this, there are two options: The first is a regular C-based API that maps colors, which is fast enough for individual colors like UI elements. The second option is generating a GLSL snippet and a 3D LUT texture that allow to apply the transformation from within GLSL shaders, which should be used for things like Textures (it's already used for the Cycles Viewport, for example).

The third point is the reason why I bring this up now - since all the drawing code is being modernized now anyways, this is the perfect opportunity to introduce the proper conversions.

Now, I don't really have that much experience with the UI and drawing code of Blender (yet), which is why I don't include a particular implementation suggestion in this mail. However, I'd be interested in helping out with CM, and hope that people with more insight into the overall code layout can suggest how and where to actually implement that on the UI side :) 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
Url : http://lists.blender.org/pipermail/bf-viewport/attachments/20161009/77aedd86/attachment.pgp