• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
1

Color picker OCIO implementation

Community Beginner ,
Jul 31, 2024 Jul 31, 2024

Copy link to clipboard

Copied

Hello,

 

I would like to propose a small improvement regarding the color picker and the OCIO implementation.

 

We are currently having an issue where by default the color picker uses an inverse transform of the View and this is not artist-friendly at all. I believe instead it should simply use the "color_picking" role.

 

Here is the 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).

 

Thanks !

Idea No status

Views

194

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
3 Comments
Adobe Employee ,
Jul 31, 2024 Jul 31, 2024

Copy link to clipboard

Copied

Hi Christophe,

 

That sounds like a good suggestion.

We were already aware that some role existed to override/define the behavior of the color picker, however it seemed there were some confusion around them (like explained here https://chrisbrejon.com/articles/ocio-ramblings-and-color-picking-nightmare/ ) so we choose to not expose anything so far.

 

Your suggestion sounds reasonable, I will discuss about it with a developper that is famillair with the workflow as well.

 

Are you aware you can also override the color profile for the eye dropper (see "eye dropper color space" here: https://helpx.adobe.com/substance-3d-painter/interface/color-picker.html) ? Is this something you would need a role for, and if so which value would you usually see it assigned with ?

 

 

Votes

Translate

Translate

Report

Report
Community Beginner ,
Jul 31, 2024 Jul 31, 2024

Copy link to clipboard

Copied

Thanks Lena !

 

Yes, the override for the "eye dropper color space" should in my opinion use the "color_picking" role.

 

I know the "color_picking" role has created lots of confusion over the years in the industy but if implemented correctly, it is really useful.

 

I would not recommend using it with an inverse transform though, because most output transforms available out there do not invert perfectly. In our case, I would recommend to set the "color_picking" role to your "working gamut in linear".

 

I will attach a screenshot of Houdini where you can see that the View/Display color spaces are different from the ones to color_pick (which is "linear_rec709" in that case).

 

Does that make sense ?color_picking.jpg

Thanks !

Votes

Translate

Translate

Report

Report
Community Beginner ,
Aug 06, 2024 Aug 06, 2024

Copy link to clipboard

Copied

LATEST

Just quickly replying to myself and maybe put together a better explanation.

 

I read the following in the documentation:
Display Selector: Allow to choose which display to use to edit colors (spectrum and sliders). The default value match the Display used by the main viewport.

 

I think this is this particular behavior that could be improved. Instead of reading the View, it should read the role "color_picking" (because of inversion issues and such).

 

Hope that makes sense,

Chris

Votes

Translate

Translate

Report

Report
Resources