-
Notifications
You must be signed in to change notification settings - Fork 129
Maya 2022: Color Management default to new config OCIO with renamed color spaces and settings #2454
Comments
Looking at the difference between the legacy OCIO (v1) to the new OCIO (v2) options it might be better to actually separate the two like that in the Admin settings too. We could have a toggle for choosing OCIO v2 over v1 when available or even have it choose legacy in Maya 2022 since it provides completely new and different arguments for As such we'd just have new extra settings for OCIO v2 (that are relevant to Maya 2022+) - Thoughts? |
Yeah, I think that we should actually do both - provide default OCIO config with OpenPype (as it would even help anyone not really versed with color management to start using some sane default values) and have ability to choose between v1 and v2 OCIO in Maya 2022. I am not sure when will Autodesk deprecate v1 support, but we'll see. |
This issue might be related to the colorspace distribution discussion and issue even though those only mention compositing hosts. |
@mkolar @antirotor Here's how it would look in settings. Thoughts? |
Actually I just found out that in Maya 2022 the I am not sure how to best be explicit about this in the OpenPype settings currently. It would be great if someone at OP dev team could take a stab at this in a way that aligns with other approaches taken with OCIO (or at least steer me in the most logical direction for OpenPype to implement it.) Could the settings show dynamically the valid attributes based on a value of another attribute? E.g. if OCIO config is set, detect whether it is V2 or not... Based on that show the right settings? Or maybe even just have settings show/hide based on whether a specific checkbox is enabled? Would love to fix up this behavior to get the full Maya 2022 support merged soon. |
I think this is a part of much bigger issue with handling colors in OpenPype, but as we need to make Maya 2022 available asap, lets divide it and implement now "dumb but fast" solution. Lets do it like you have on the screenshot, but add logic to prelaunch hook to select what's appropriate for running Maya version... This will rely on TD to have correct version of ocio config (if used) but will provide quick and not-that-painful way to run Maya. Then with proper implementation, we can add OpenColorIO as library and use it's python api to parse available config files and make it more smart, better, nicer, shiny and whatnot,,, |
We had some more discussions today and looking at the mockup from settings here, I'd also say that it's the way to go for now. Especially considering it's not only the ocio config, but also the attributes in maya themselves that have changed. |
Nevermind, this was actually my own fault. Stupid me. :) It was actually opening an old workfile and I just kept on not noticing even though I tried to double check it. |
@mkolar I'd like to propose an alternative that looks more like how it's done for settings for Hiero and Nuke. Settings layout View / View Transform The old Maya color config basically uses "View Transform" which is View + Display but in the legacy styling Display was never explicitly set in preferences. So I'd say that we use a fallback for "View" that if we're in an older host (Maya pre 2020) or are using a legacy 1.0 config then we use the View value as View Transform. I'll implement the code changes in a bit in another branch. Lists of values The settings being lists are solely to allow the fallback to happen. It's a minor complexity in settings but eases the transition for now. Custom The custom config is only used if the top is set to |
@mkolar Here is the new proposed code, branch with commit. This is basically the implementation as described in the comment above - I much prefer that code. Note: This suffers from the same issue as before that the code will only work once updated settings are saved for the project. I don't know how to possibly work around that aside of doing an initial query whether the data is as I'd need it to be - and when wrong log an error that project settings are outdated? I've tested the different use cases (maya-default, maya-legacy and custom config) in Maya 2020 and Maya 2022. 👍 |
Any thoughts on the above? Is the latest approach I described the most sensible for now? Once we pick I can merge and refactor to work with latest develop changes which merges Maya host from Avalon into OpenPype. |
Issue
OpenPype's default Color Space settings for maya are set to:
scene-linear Rec 709/sRGB
sRGB gamma
Both of these names do not exist with the default OCIO config in Maya 2022.
They are now named
scene-linear Rec.709-sRGB
andsRGB
As such the
set_colorspace
fails in Maya 2022 resulting in these errors on New File or Maya launch:This is because Maya 2022 comes with a new
.ocio
config (default) and considers the old.ocio
file legacy.<MAYA_RESOURCES>/OCIO-configs/Maya2022-default/config.ocio
<MAYA_RESOURCES>/OCIO-configs/Maya-legacy/config.ocio
Also note that Maya 2022 completely revised settings for "View Transform". It now has two separate options Display and View. More details in the Maya 2022 documentation on Color Management
Potential solutions
We can maybe allow a comma/separator divided list of values to fall back to in the settings, e.g.
scene-linear Rec.709-sRGB;scene-linear Rec 709/sRGB
.Or as @jakubjezek001 mentioned on discord maybe make the settings a combobox entry with a mapping per application version. But even those might be wrong when you are using a custom OCIO file.
Another fix could be by always defaulting to an
.ocio
file that gets provided with OpenPype which we can keep consistent across maya versions.Discussion
It would be good to know what a preferred method of fixing this would be.
Note that this could get extra complicated when mixing Maya 2020 + Maya 2022 in a single production - if you ever do that.
[cuID:OP-2260]
The text was updated successfully, but these errors were encountered: