Skip to content
This repository has been archived by the owner on Sep 20, 2024. It is now read-only.

Maya 2022: Color Management default to new config OCIO with renamed color spaces and settings #2454

Closed
BigRoy opened this issue Dec 30, 2021 · 11 comments · Fixed by #2445
Closed
Assignees

Comments

@BigRoy
Copy link
Collaborator

BigRoy commented Dec 30, 2021

Issue

OpenPype's default Color Space settings for maya are set to:

  • Rendering Space: scene-linear Rec 709/sRGB
  • Viewer Transform: 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 and sRGB

As such the set_colorspace fails in Maya 2022 resulting in these errors on New File or Maya launch:

Traceback (most recent call last):
#   File "S:\openpype\OpenPype\repos\avalon-core\avalon\pipeline.py", line 631, in emit
#     callback(*args)
#   File "S:\openpype\OpenPype\openpype\hosts\maya\api\__init__.py", line 206, in on_task_changed
#     lib.set_context_settings()
#   File "S:\openpype\OpenPype\openpype\hosts\maya\api\lib.py", line 1924, in set_context_settings
#     project_data.get(pixelAspect_key, 1))
#   File "S:\openpype\OpenPype\openpype\hosts\maya\api\lib.py", line 2825, in set_colorspace
# RuntimeERROR: colorManagementPrefs: Rendering space scene-linear Rec 709/sRGB is unknown.
# 

This is because Maya 2022 comes with a new .ocio config (default) and considers the old .ocio file legacy.

  • Maya 2022 Default: <MAYA_RESOURCES>/OCIO-configs/Maya2022-default/config.ocio
  • Maya 2022 Legacy: <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.

Example quoted from Discord

[
    {"rec_709_srgb": "Rec.709-sRGB"},
    {"gamma22": "Gamma 2.2"}
]

Mapping for Maya 2022 in code

mapping_2022 = {
    "rec_709_srgb": "scene-linear Rec.709-sRGB",
    "gamma22": "..."
}

Mapping for others in code

mapping_old = {
    "rec_709_srgb": "scene-linear Rec.709/sRGB",
    "gamma22": "..."
}

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]

@BigRoy
Copy link
Collaborator Author

BigRoy commented Dec 30, 2021

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 maya.cmds.colorManagementPrefs like ociov2Enabled=True with displayName, viewName versus the old viewTransformName when ociov2Enabled=False.

As such we'd just have new extra settings for OCIO v2 (that are relevant to Maya 2022+) - Thoughts?

@antirotor
Copy link
Member

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.

@BigRoy
Copy link
Collaborator Author

BigRoy commented Jan 23, 2022

This issue might be related to the colorspace distribution discussion and issue even though those only mention compositing hosts.

@BigRoy
Copy link
Collaborator Author

BigRoy commented Jan 23, 2022

maya2022_ocio_settings

@mkolar @antirotor Here's how it would look in settings. Thoughts?
Will look into implementing code coming week.

@BigRoy
Copy link
Collaborator Author

BigRoy commented Jan 23, 2022

Actually I just found out that in Maya 2022 the ociov2Enabled flag isn't one you can set but it's only one you can query. It's because it basically depends on whether the used ocio config is OCIO 2+.

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.

@antirotor
Copy link
Member

antirotor commented Jan 24, 2022

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,,,

@mkolar
Copy link
Member

mkolar commented Jan 24, 2022

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.

@BigRoy
Copy link
Collaborator Author

BigRoy commented Jan 25, 2022

The original Maya 2020 color settings. Can someone confirm for me did they what they intended to do? :) They don't seem to work for me on Maya launch (they do work on New File but not on Maya start). So the initial scene without open latest workfile, the empty scene Maya starts in, doesn't initialize to the right settings.

For example change Rendering Space to ACEScg and Viewer Transform to 1.8 gamma. Maya 2020 will not start with those settings for me. @mkolar can you confirm on your end?

I think originally we might have gotten lucky because OpenPype's default settings are Maya's default settings. :')

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.

@BigRoy
Copy link
Collaborator Author

BigRoy commented Jan 26, 2022

@mkolar I'd like to propose an alternative that looks more like how it's done for settings for Hiero and Nuke.

Settings layout

afbeelding

With the dropdown:
afbeelding

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 custom.

@BigRoy
Copy link
Collaborator Author

BigRoy commented Jan 26, 2022

@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. 👍

@BigRoy
Copy link
Collaborator Author

BigRoy commented Feb 12, 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.

@BigRoy BigRoy self-assigned this Feb 12, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants