Fusion: Load and extract with managed colorspaces

[BigRoy]

Is your feature request related to a problem? Please describe.

Since Color Management with imageio settings has now gotten some decent attention in OpenPype it's time to fully support the logic in Fusion too and consider how color spaces get loaded and extracted in a way that it can be relied on in production.

The issue is with automating it 100% is that it takes the flexibility out of production. Additionally Fusion doesn't require colorspace metadata or even conversions to be done at all. You can drop down an OCIO node but nothing really ensures you are doing the right thing.

Describe the solution you'd like

I kind of asked this on discord:

I was just wondering for the case where we'd want to try and make sure we store what colorspace the output file is with our publishes - like what would be a technical correct way to do so in Fusion.

One of the answers was:

It's the beauty and the curse of Fusion. 100% control of the colors yourself There is no automated way to know what color space an image is using. It's up to the user to take care of that. Most of the time you can check the metadata and it will tell you but it's not always there and it's not OCIO names What might be the best solution would be a custom macro (like nuke does with its custom gizmo) that contains a saver node + an OCIO node. That way we can list all the available OCIO color spaces that the user can pick from to tell OP what IDT the saver is getting

Anyway, we can also use the Nuke implementation as a reference and consider what we've learned there in production with OpenPype too.

But a start would be implementing what's described here on Discord but then using the new Mixin class from this PR https://github.com/ynput/OpenPype/pull/4556 - specifically:

1. Modify the render_local.py extractor to work with Extract OIIO Transcode mixin logic

2. Add the required colorspace after representation creation:

       self.set_representation_colorspace(
           repre,
           instance.context,
       )

3. Set project setting defaults or specific ones needed for your production. Defaults might be a bit too much, especially this example.

---

Example

Purely as an example these settings came up by @EmberLightVFX on discord: In the settings, under project_settings/global/imageio/file_rules/rules:

• Regex pattern: .*
• Colorspace name: ACES - ACEScg
• File extension: exr

Under project_settings/global/publish/ExtractOIIOTranscode/profiles/0/outputs/sequence/:

• Colorspace: Output - sRGB

---

Additional context

• Came up on Discord here
• Likely might need to use the new

[cuID:OP-5203]

[BigRoy]

But a start would be implementing what's described here on Discord but then using the new Mixin class from this PR https://github.com/ynput/OpenPype/pull/4556 - specifically:

1. Modify the render_local.py extractor to work with Extract OIIO Transcode mixin logic
2. Add the required colorspace after representation creation:

       self.set_representation_colorspace(
           repre,
           instance.context,
       )

This is now added to PR https://github.com/ynput/OpenPype/pull/4522 with this commit https://github.com/ynput/OpenPype/pull/4522/commits/73e0ba9cb266507c0f7ea562d6895bcd2dbaaddb

I'd say that even after merging it we can keep this issue open to track being more explicit about the colorspaces going from Fusion if possible instead of solely relying on the imageio file rule settings in OpenPype project settings.

[EmberLightVFX]

I created a quick sketchup on a custom saver node for Fusion where you also can pick the OCIO settings for your reviews.

https://user-images.githubusercontent.com/49758407/224707393-c29e3410-960c-4be0-bee2-5a9a8688fcde.mp4

But after talking to @BigRoy on Discord a better way to tackle this would be to move that setting into the Publisher itself. To get the wanted IDTs and ODTs for the reviews I think adding a dropdown that an project admin can populate with the wanted IDTs and ODTs. You pick a default setting and allows the artist to select another IDT/ODT per instance if that's needed.

A bit OT but I think OP should create a tab on the saver itself, telling the artist that it's maintained by the publisher and maybe give some extra info like what IDT/ODT is currently set for the reviews and so on. Just some nice-info-to-have stuff

[BigRoy]

A bit OT but I think OP should create a tab on the saver itself, telling the artist that it's maintained by the publisher and maybe give some extra info like what IDT/ODT is currently set for the reviews and so on. Just some nice-info-to-have stuff

That wouldn't be too hard to do actually - anyway, thanks for the solid demo. Great presentation and good explanation along with it. Great reference as we continue the development.

[jakubjezek001]

While exploring Fusion's colorspace management, it has become clear that we cannot avoid using additional nodes for each loading container and publishing instance. To align the workflow as closely as possible with Nuke, we need to convert each container or instance into a group node, as suggested by @EmberLightVFX in this comment. Each group node will have the following content:

• For Publish instance basic nodes:

  1. An OCIO colorspace node with the source set to project_settings.fusion.imageio.workingSpace and the output set to project_settings.fusion.creator.saver.colorspace.
  2. A Saver node.

• For Loading container basic nodes:

  1. A Loader node.
  2. An OCIO colorspace node with the source set to repre.colorspaceData.colorspace and the output set to project_settings.fusion.imageio.workingSpace.

Please note that I've included example paths for settings or representation data, and some of these might not yet exist.

[EmberLightVFX]

Sadly the OCIO node isn't the fastest in Fusion. I tend to use the gamut (+ cineonLog) node as much as possible and OCIO mostly for the viewer lut or custom IDTs/ODTs. If you have a lot of OCIO nodes you will feel the slowdown by them. But maybe OCIO is the only way forward as that's the color management of OpenPype. Maybe that would force BMD to optimize the OCIO node a bit more even.

[BigRoy]

we cannot avoid using additional nodes for each loading container and publishing instance.

Loading however does allow to specify the source colorspace and the colorspace you want to convert to - so I suppose loading should allow it? Right?

[EmberLightVFX]

we cannot avoid using additional nodes for each loading container and publishing instance.

Loading however does allow to specify the source colorspace and the colorspace you want to convert to - so I suppose loading should allow it? Right?

Loading does but only the included gamut and gammas from the gamut and cineonLog nodes, not OCIO configs.

[jakubjezek001]

we cannot avoid using additional nodes for each loading container and publishing instance.

Loading however does allow to specify the source colorspace and the colorspace you want to convert to - so I suppose loading should allow it? Right?

Loading does but only the included gamut and gammas from the gamut and cineonLog nodes, not OCIO configs.

In most cases, using the Gamut node with ACES and ACEScg in Fusion might be sufficient, relying on OCIO only for the viewer. However, it is important to verify if Fusion's interpretation of ACES matches the expected results.

By the way, I couldn't find a way to maximize the OCIO viewer to fullscreen. Is there a method or workaround available for this?

[BigRoy]

In most cases, using the Gamut node with ACES and ACEScg in Fusion might be sufficient, relying on OCIO only for the viewer. However, it is important to verify if Fusion's interpretation of ACES matches the expected results.

Well I'd say that'd never be fully reliable. What is ACES now, might not be the exact ACES in a next OCIO config iteration so it depends on your OCIO file whether it might be correct too. I'd say we're better off just always relying on the OCIO stuff directly.

By the way, I couldn't find a way to maximize the OCIO viewer to fullscreen. Is there a method or workaround available for this?

What viewer?

You can have a floating viewer through Window > New Image View.

You can have a "monitor output view" by pressing e.g. 3 on a tool. Similar to right clicking a tool:

I'm not sure you can full screen a regular or floating view.

[Jrsndlr]

Well I'd say that'd never be fully reliable. What is ACES now, might not be the exact ACES in a next OCIO config iteration so it depends on your OCIO file whether it might be correct too. I'd say we're better off just always relying on the OCIO stuff directly.

Totally agree. It is a shame that OCIO nodes are slow, but I do not see other way that relying on OCIO. Maybe just having pass thru (node disable in Nuke) for OCIOColorspace in project settings for people that want to trade speedup to flexibility?

I believe BMD disabled F4 (Fusion maximize window hotkey) in Fu9. You can open new floating view and make it fullscreen by doubleclicking the top.

While discussing the OpenPype Saver, the Nuke pre write nodes in the saver group proved to be huge help. Especially for projects where specs are not set in stone.

[Jrsndlr]

Thinking about future-proofing the saver, allowing arbitrary nodes even for Loader and Saver would be great.

There are Fusion comunity made nodes (Fuses) for EXR that use EXRIO and can replace Fusion native Loader and Saver, enabling multipart EXR and better metadata (see ReadEXRUltra.fuse and LifeSaver.fuse).

[EmberLightVFX]

it is important to verify if Fusion's interpretation of ACES matches the expected result

I have done some tests and ACES/ACEScg in the gamut node is 1:1 with the one included in OCIO Same with the cineonLog node and ACESlog (now named ACEScc after ACEScct came to existence)

What is ACES now, might not be the exact ACES in a next OCIO config iteration

They will never change ACES2065-1, ACEScg, ACEScc/t, they will only add more variants. One of the first goals of ACES is to always keep backwards compatibility.

I'd say we're better off just always relying on the OCIO stuff directly.

I agree with this.

[BigRoy]

Just want to propose an alternate solution for setting the colorspace of the output data:

By the way, if we want to avoid the need to require a physical node in Fusion to define the output colorspace we could also decided to adopt something similar to what this PR does for the Tray Publisher https://github.com/ynput/OpenPype/pull/4901 but then use it for Fusion for Saver nodes so the user can set what colorspace the saver should be set to.

[EmberLightVFX]

That's not a too bad idea, I like it! At least to be able to overwrite the color space that would be generated by file rules. It would also be a great idea if if was a dropdown list with pre-created alternatives so the user doesn't need to write the exact OCIO name eg. Output - Rec.2020 (P3D65 Limited) but could instead just select Rec2020. These lists would be greated by an admin/TD in the Ayon settings.