Color-picker doesn't behave consistent across OCIO configs.

[Liam Collod]

(Using Substance-Painter version 7.4 - Windows)

Hello,

Since the latest big release 7.4 that introduce OCIO, it seems that the color-picker "picking" function doesn't work as excepted when using OCIO as a color-management system. The result vary depending of the OCIO config being used. Unfortunately there is no OCIO config that make it work in all the cases :

Here are my hypothesis :

Case 1

You are using an OCIO v2 config that uses Display colorspaces and Shared Views (OCIO v2 new features) :

The picker take the value at the display (after the view-transform is applied) and return it. This only work when there is no view-transform, i.e. is it is disabled or use a display with a "passtrough/raw" encoding. If you are viewing color data with the proper view-transform, the picked value will not correspond to the original value you used.

Case 2

You are using an OCIO v1 config or v2 without the new features : The picker take the value at display (with the view-transform), then apply an inverse display transform. It pick the default one, i.e. the first defined in the config or in the active_displays key. And as the sliders don't go above 1, the result is clamped between the 0-1 range.

To come to these conclusions, I executed a bunch of tests with various OCIO configs.

You can find them here: https://liamcollod.notion.site/Substance-Painter-Color-Picker-Issue-1d1cdeeb0e2846ba977ebc453e5ae56b 

I don't really know what is the actually issue but I can tell for sure that there is unfortunately very few cases where the colorpicker pick the original value properly.

Hope you could have a look at that.

Cheers.

Liam.

[Léna Piquet - Froyok · Accepted solution]

What you describe in case 1 seems to be close to what we are currently doing.

We are working on various bug fixes regarding the color management, which includes a rework of the behavior of the color picker. I can't share the exact changes we are planning as things are still in development, but they should be available once 7.4.2 is released (planned for next month currently, but may slip off a bit).

By the way, thank you for taking the time to do all those tests, we will take that into consideration on our side as well. 🙂

[Liam Collod]

That is great news to hear.

Thanks for your answer.

Cheers.

Liam.

[Christophe38911010nz3b]

Hello @Léna Piquet - Froyok 

We are having a similar issue regarding the color picker and the OCIO config.

I would like to do the following proposal:

• If the "color_picking" role is declared in the OCIO config, then the "top colorspace menu" should read that. I believe this would be the correct implementation of this role.
• If the "color_picking" role is not declared in the OCIO config, the behaviour of this "top colorspace menu" can stay as it is.

Does that make sense ? (I have attached an image for reference).

Bottom line is : using an inverse transform to pick a colour is not artist-friendly. Please let me know if I should start a new thread about this or not. Thanks !