difference between applications implementation making it harder to create one config for all apps

[MrLixm]

Hello, This is the follow-up issue of my question on the OCIO slack .

From the the NanoColor OpenSourceDays24 recording there was this bullet point which sparked my interest:

No need to configure each app separately, all use the same config

Based on my personal experience with OCIO I have found that this is not really true. Despite understanding that this is the original OCIO goal, it doesn't seem it was achieved as what I feel is that in reality, every client application implemented a slightly different usage of OCIO which pushed us, config authors, having to do complex research and development on find what does each application expect to find in the OCIO config. This could just have been a documentation problem but it seems that each application took a different approach that may conflict with one another, resulting in configs that may be messier to develop and use for the artists.

I do not have an example for all DCCs but here is a few of specific issues:

• Redshift:
  • link: expect a mix of standard roles AND a colorspace with a specific transform structure
• substance 3d painter:
  • link: expect 8 custom roles
  • link does not make use of the color_picking role
• blender:
  • link: use the first Display's View to render their color-picker preview

With probably some other issues in other typical VFX applications (usually roles-related).

Also one of the other issues is the lack of Look support in the GUI for most if not all client applications. Thus we have to create Views with the looks baked which are going to be redundant for applications supporting such behavior like Blender.

On the same topic, we have the "missing display/view colorspace export in GUI" that appeared after the adoption of OCIO-2. Because this version offered a new way to build your Display/View, you didn't have to build a single distinct colorspace for your View and could instead have it built on the fly from a combination of ColorSpace and ViewTransform. But because applications didn't catch up directly we had an awkward moment where artists used to select the display corresponding ColorSpace in the GUI menu (that was listing ColorSpace entities), couldn't find a ColorSpace matching their "view-transform" anymore. Like in Nuke where you had to put an OCIODisplay node before your Write node, instead of relying on the Write node colorspace knob.

---

Hopefully, you see my point, which is that combining all the applications, at various versions, with various OCIO API version and it starts to make sense having to create one config per application just in case.

I unfortunately don't have many solutions to counter-balance the issue I'm exposing, neither think that there is anythign specific to fix in OCIO directly. But perhaps it will be useful to expose such problems for the future and maybe helping application vendor handling them ?

Let me know if anything is not clear or does not make sense. Cheers, Liam.

[KelSolaar]

Hey Liam,

Thanks, yes this is painful and the result of lack of best practices and guidance on how to expose the config to users. Something that we identified a few years ago and that the UX Working Group is trying to address by designing widget elements and best practices. Road is long but we will get there.

People are welcome to join and bubble back feedback (and frustration) directly at the meetings: http://calendar.opencolorio.org

Cheers,

Thomas