Questions | Proper workflow in Fusion Studio using ACES 1.3 and OCIOv2

[Jobbel (Justin Kempke)]

Hi, I am fairly new to working with OCIOv2 and OCIO in general. And after a few ACES test runs, I am

1. confused with some of the terminology used,
2. unsure if my DCC is behaving correctly with regards to the config file I am using, and
3. unsure if my workflow is correct.

General Information:

DCC: Fusion Studio (Standalone) ver18.1.1
OCIO: ver2.1
OCIO config file: studio-config-v1.0.0_aces-v1.3_ocio-v2.1.ocio

Note: I installed the OCIO config file via my systems environment variables. The OCIO config is getting detected by all my DCC tools.

---

---

Questions:

Fusion Node: OCIO Color Space (OCC)
The default behavior for the input and output space is „ACES2065-1“, which seems to be following the OCIO config „file_rules“. – did I get that right?

---

---

OCC Node available dropdown menu options:
Are these the expected, selectable dropdown options I should be seeing or is something wrong/ missing? Except for „Raw“ all of the „utility colorspaces“ that were mentioned on Github are missing.

---

---

OCIO Colorspace ViewLUT Options:
Similiar to the previous question, are these the options I should be seeing or is something wrong here? Based on the OCIO config’s „shared_views“, I was expecting something like: „ACES 1.0 – SDR Video“ or „Un-tone-mapped“ to be selectable for the ViewLUT, but I am getting the exact same dropdown list that I am getting with the OCC node.

---

---

Basic „appropriate“ Workflow:
As far as I can tell, it does not make a difference (code value-wise), if I am converting from camera space to ACEScg directly, instead of going to ACES2065-1 first and then to ACEScg. Does the latter approach make a difference and if so, is the latter one preferred?

---

---

Which output transform is the correct one:
If the available dropdown options from the OCC node are indeed the correct ones, then which should I select if I wanted to go from ACEScg as the linear working space to an output space like sRGB/2.2 or BT.1886/2.4 with the OCC node?

“Camera.709” does not make sense, as it is described as an OETF in the config file.
“Gamma 2.2 sRGB - Texture” does not seem to be an option either, as I thought these were reserved for textures only.

---

---

Thanks in advance to everyone who is trying to help.
Justin (Jobbel)

Edit: images and formatting

[shebbe (Shebanjah Klaasen)]

@Jobbel

The default behavior for the input and output space is „ACES2065-1“, which seems to be following the OCIO config „file_rules“. – did I get that right?

I don’t think that is the case for Fusion. ACES2065-1 is the first color space in the OCIO list which is probably why it’s seen first. Fusion doesn’t have any project/software wide controlled OCIO support so it is not able to utilize all OCIO features.

@Jobbel

Except for „Raw“ all of the „utility colorspaces“ that were mentioned on Github are missing.

I think this is again a product of lack of full OCIO implementation.

@Jobbel

OCIO Colorspace ViewLUT Options:
Similiar to the previous question, are these the options I should be seeing or is something wrong here? Based on the OCIO config’s „shared_views“, I was expecting something like: „ACES 1.0 – SDR Video“ or „Un-tone-mapped“ to be selectable for the ViewLUT, but I am getting the exact same dropdown list that I am getting with the OCC node.

Fusion is missing something like OCIODisplay as a node/effect which would enable the proper views for your viewerLUT and also as node for writing out with ODT+RRT.

@Jobbel

Basic „appropriate“ Workflow:
As far as I can tell, it does not make a difference (code value-wise), if I am converting from camera space to ACEScg directly, instead of going to ACES2065-1 first and then to ACEScg. Does the latter approach make a difference and if so, is the latter one preferred?

All transforms in the config are defined to go from or to ACES2065-1. There is no need to physically do this step as it automatically happens between your In and Out choice on the transform.

@Jobbel

Which output transform is the correct one:
If the available dropdown options from the OCC node are indeed the correct ones, then which should I select if I wanted to go from ACEScg as the linear working space to an output space like sRGB/2.2 or BT.1886/2.4 with the OCC node?

An output space that is tone mapped with the purpose of viewing and/or delivering final picture would require the view transform to be enabled which is not possible currently in Fusion.

The workaround would be to use the LUT based ACES 1.2 config which has them baked in the output color spaces. If you need to use ACES 1.3 for certain color spaces the 1.2 config didn’t have it should be easy to mix them as you don’t define a single config for the entire project. It’s just not very elegant…

[Jobbel (Justin Kempke)]

Thanks for taking the time, appreciated!

@shebbe

ACES2065-1 is the first color space in the OCIO list which is probably why it’s seen first.

Makes sense. I tested this by deleting the first colorspace (ACES2065-1) in the config file. The OCC node in Fusion then displayed ACEScc as the new default, as it is the next colorspace in the config.

But what are „file_rules“ for then? Based on the OCIOv2 demo description/ comment, how should one interpret that?

---

---

@shebbe

I think this is again a product of lack of full OCIO implementation.

If that is the case, then I find it really misleading that BMD says that their Fusion standalone version is supporting „OCIO v2.1.1“. Supporting „just“ part and not all of OCIO is a shame, especially if the „incomplete“ implementation of OCIO is not easily differentiable from a „complete“ implementation. At least for me as a fairly new user it is not.

---

---

@shebbe

Fusion is missing something like OCIODisplay as a node/effect which would enable the proper views for your viewerLUT and also as node for writing out with ODT+RRT.

That is really a bummer

---

---

@shebbe

All transforms in the config are defined to go from or to ACES2065-1.

Where in the OCIO config is that defined though? As a new user I kinda take the descriptions of the config at face value. If it says „Convert-ACEScg-to-ACES2065-1“, then I am kinda expecting a one way processing route and not that the inverse from ACES2065-1 to ACEScg is also possible.

---

---

@shebbe

The workaround would be to use the LUT based ACES 1.2 config which has them baked in the output color spaces. If you need to use ACES 1.3 for certain color spaces the 1.2 config didn’t have it should be easy to mix them as you don’t define a single config for the entire project. It’s just not very elegant…

I mean it is nice to know that there is a workaround, but I would expect a software tool that says it supports a certain standard, to fully and not partially support it. Or at least be transparent about it.

Is what Shebbe described as a workaround the only option anyone currently has when trying to work with ACES 1.3 and OCIOv2 in Fusion? Would be nice if someone from ACES could comment on this, if there is something to add. @nick, @sdyer, @alexfry

Is using and mixing different config files the ususal workflow then? I thought the „Studio, CG and Reference“ configs were meant as exactly that. Config files for an „entire project“ and I think that is quite elegant to be honest. At least the „studio“ version comes across that way. Or did I get that wrong?@Thomas_Mansencal

---

Thanks a lot for the help!
Justin (Jobbel)

I hope it is alright that I mentioned/ added a few other people.

[shebbe (Shebanjah Klaasen)]

@Jobbel

But what are „file_rules“ for then? Based on the OCIOv2 demo description/ comment, how should one interpret that?

You can read a bit about it here.
Because Fusion doesn’t globally utilize OCIO it can’t do anything regarding assigning a default color space to a file because the Loader node has no OCIO options attached to it.

@Jobbel

If that is the case, then I find it really misleading that BMD says that their Fusion standalone version is supporting „OCIO v2.1.1“. Supporting „just“ part and not all of OCIO is a shame, especially if the „incomplete“ implementation of OCIO is not easily differentiable from a „complete“ implementation. At least for me as a fairly new user it is not.

BMD is never really clear on most of their updates unfortunately.

@Jobbel

@shebbe

All transforms in the config are defined to go from or to ACES2065-1.

Where in the OCIO config is that defined though? As a new user I kinda take the descriptions of the config at face value. If it says „Convert-ACEScg-to-ACES2065-1“, then I am kinda expecting a one way processing route and not that the inverse from ACES2065-1 to ACEScg is also possible.

All color spaces are defined as going to_scene_reference which is ACES 2065-1 but when it’s chosen as ‘Out’ the inverse direction is applied. Some color spaces like ACEScg have built-in transform definitions but the camera log spaces can be seen as full log to linear formula and matrix transform to AP0.

@Jobbel

Is what Shebbe described as a workaround the only option anyone currently has when trying to work with ACES 1.3 and OCIOv2 in Fusion? Would be nice if someone from ACES could comment on this, if there is something to add.

Perhaps it is possible to define the display transforms you’d need as a color space instead so it would appear in the list for Fusion but I don’t know enough about OCIOv2 to tell. It’s not really the intended way to use a v2 config though I guess.

I would try to keep it as simple as possible, so if your production allows the use of ACES 1.2 I’d use that completely instead. ACES 1.3 comes with a few new color spaces and the Reference Gamut Compress but even the RGC cannot be used in Fusion from what I can see.

[Jacob (Jacob Danell)]

Fusion does have the Look dropdown in its OCIO node. Never seen it populated tho. Shouldn’t the tonemapped srgb viewer lut show up there is what would the Looks dropdown be used for?

[shebbe (Shebanjah Klaasen)]

The Looks section should be populated with any look that is present in the config. In case of the ACES 1.3 config that would be the Reference Gamut Compression. This is what that looks like on OCIOLookTransform node in Natron. I’m not even sure if Look is supposed to be an option on an OCIOColorSpace node.

[Jobbel (Justin Kempke)]

Not sure if that is the intended longterm behavior/ solution either, but in Fusion ver18.1.1 the “look” dropdown in the OCIOColorSpace node does display ACES Reference Gamut Compression as an option as long as you add the OCIO config for ACES 1.3 via the environment variables to your system.

Edit:
The visual “impact” RGC has when being applied in Fusion is also quite different (a rather marginal visual change in comparison to Resolve) to how it currently behaves when using it in Resolve ver18.1.1 for instance.

[shebbe (Shebanjah Klaasen)]

@Jobbel

OCIOColorSpace node does display ACES Reference Gamut Compression as an option as long as you add the OCIO config for ACES 1.3 via the environment variables to your system.

I didn’t know that. Never used Fusion through env vars with the ACES 1.3 configs. Thanks for pointing that out! Seems like a bug then that it doesn’t with manual loading.

[Jobbel (Justin Kempke)]

@shebbe

You can read a bit about it here .

Thanks for the link, still hasn’t clicked yet. Probably will in a few days though.

---

---

@shebbe

BMD is never really clear on most of their updates unfortunately.

Jep, that is true and kinda annoying to be honest.

---

---

@shebbe

All color spaces are defined as going to_scene_reference which is ACES 2065-1 but when it’s chosen as ‘Out’ the inverse direction is applied. Some color spaces like ACEScg have built-in transform definitions but the camera log spaces can be seen as full log to linear formula and matrix transform to AP0.

That is a handy feature. As someone who is not far down the rabbit hole yet, if I wanted to see that being reflected somewhere. Would that behavior be visible in the config or would I need to look into the OCIOv2 github codebase for that?

Thanks

[Jobbel (Justin Kempke)]

Sure no worries. Found that out a few days ago and it seems like a bug to me as well.

[shebbe (Shebanjah Klaasen)]

@Jobbel

The visual “impact” RGC has when being applied in Fusion is also quite different (a rather marginal visual change in comparison to Resolve) to how it currently behaves when using it in Resolve ver18.1.1 for instance.

It should be exactly the same. RGC is meant to be applied in AP0/Linear. If the incoming image data wasn’t that it will look different and not work as intended. Perhaps you applied it on an ACEScg image?

[shebbe (Shebanjah Klaasen)]

Upon further inspection I do notice a discrepancy. Hope anyone with more insight on ACES can comment on why this is?

Left: RGC applied in ReFusion via ACES 1.3 OCIOv2.1 Studio 1.0 config in ACES 2065-1.
Right: RGC applied via Resolve ACES project management.
Both output sRGB.

I’m not even sure which of the two is correct. Did the parameters of the reference settings ever change?

[Jobbel (Justin Kempke)]

@shebbe

Perhaps you applied it on an ACEScg image?

I mean, I have applied it in ACEScg just for the sake of it, but I definitely applied it in AP0/Linear as well.

@shebbe

Hope anyone with more insight on ACES can comment on why this is?

I would like to know this as well

[shebbe (Shebanjah Klaasen)]

It looks like ReFusion does something to the image that is the culprit. I get an exact match with Fusion Studio standalone and Resolve directly on the EXR. I’m not sure why it’s happening when running through ReFusion…

[Jobbel (Justin Kempke)]

For someone with less experience this is not so easy to follow.
If you don’t mind, could you post a screengrab and or a description of your workflow (preferbly step-by-step) as I want to make sure that I can replicate your approach and test if I get the same result on my system.

Much appreciated, thanks ^^

[shebbe (Shebanjah Klaasen)]

Sure, sorry it was quite late yesterday and I was just commenting quickly whatever popped up.
It looks like I made an error when running through ReFusion. I accidentally left the RGC on on the color pages ODT node so it applied twice.

So ACES 1.3 OCIO RGC works as it should.
Sorry for the confusion!

The way I tested was loading ACES_OT_VWG_SampleFrames.0063.exr onto a timeline and apply ACES Transform on the color page to ACES 2065-1 to sRGB with RGC applied. No project wide color management. Then a copy of the clip running through ReFusion with OCIOColorSpace ACES 1.3 loaded and applied RGC as Look. Then switch off the RGC on the ODT node on the color page for that clip. They should fully match.

If you’d want to test if this works in Fusion Studio you’d need a view transform as well. You could load a second OCIOColorSpace and have it load the ACES 1.2 config.

[Jobbel (Justin Kempke)]

@shebbe

Sure, sorry it was quite late yesterday and I was just commenting quickly whatever popped up.

No need to apologize and thanks for the additional information! I will try this as soon as I have time