Open MrLixm opened 1 month ago
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
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:
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:
color_picking
roleWith 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.