OpenColorIO 2 Configs for ACES

[Derek]

So a PNG texture, made in Substance Painter for example working in ACEScg, would be read into Maya with sRGB - Texture (which takes the sRGB EOTF and brings that into the ACEScg working space of Maya). However for Unreal it would need to instead be read into Unreal with sRGB Encoded AP1 which would take the sRGB EOTF with AP1 gamut and bring that into UE’s rRGB gamut. Is that right?

The default color picking role is sRGB - Texture which I would think would put colors in the sRGB gamut. So does the above workflow assume that the color picking role would instead be ACEScg?

[Thomas_Mansencal]

Hello,

The OpenColorIO Configuration for ACES 2.0.0 have been released: Release OpenColorIO-Config-ACES 2.0.0 · AcademySoftwareFoundation/OpenColorIO-Config-ACES · GitHub.
Note that the studio-config-v2.1.0_aces-v1.3_ocio-v2.3 and cg-config-v2.1.0_aces-v1.3_ocio-v2.3 configs are builtin in the OpenColorIO 2.3.0 release.

Thanks again to all the contributors!

Cheers,

Thomas

[TooDee (Daniel Brylka)]

Hi Thomas,
can it be that even the Nuke 15 beta cannot read this new release?
The message is that Nuke only supports OCIOv2 2.2 and not 2.3.

Maybe I can change the minor version number by hand and then Nuke will be able to read the config?
I will try, last year with Blender this hack worked as well
…At least Nuke 15 has an updated write node…

Never mind, I found the v2.2 config

But another thing:
I do not see this option on my iMac
! {name: ACES 1.1 - SDR Video (P3 lim), view_transform: ACES 1.1 - SDR Video (P3 lim), display_colorspace: <USE_DISPLAY_NAME>}

Do I need to change something in the config by hand?

Thanks,

Daniel

[Thomas_Mansencal]

Hi @TooDee,

Yes, we have configs attached to the release notes for OCIO 2.1, 2.2 and 2.3.

The DisplayP3 views are set as follows in accordance with the aces-dev ODT:

CG Config

  Display P3 - Display:
    - !<View> {name: Raw, colorspace: Raw}
    - !<Views> [ACES 1.0 - SDR Video, Un-tone-mapped]

Studio Config

  Display P3 - Display:
    - !<View> {name: Raw, colorspace: Raw}
    - !<Views> [ACES 1.0 - SDR Video, ACES 1.0 - SDR Video (D60 sim on D65), Un-tone-mapped]

Cheers,

Thomas

[TooDee (Daniel Brylka)]

@Thomas_Mansencal

D65), Un-tone-map

Thanks Thomas,
I still wonder about the D60 sim on D65?!
I thought I might find something similar like @alexfry included in his OCIO (OpenColorIO-Configs-master_AlexFry_P3) config for ACES 1.2

I assume the two outputs in these two OCIO configs are not the “same”, right?

[Warguez (Manu Quinto)]

Hi @Thomas_Mansencal ,

First, thanks for these 2.0.0 configs ! ^^

I have a few questions :
For the moment at our studio we’re still using ocio 1 configs, but we’re slowly updating our softwares so they are ready to ingest ocio 2 ones.

I just tested the ocio v2.1 as it is the latest compatible with our main softwares version (maya and nuke), and I noticed either in maya or nuke that the “output” IDTs are not available anymore.
I guess … it’s mainly because of the new LUT less architecture (and maybe also because of the gamut mapping invertibility) ?
For sure it wasn’t used that much, but it was a nice workaround to ingest baked rec709 footages or rendered sRGB images back in an ACES workflow.

Digging a bit I’ve noticed that under the utility section, there’s a “camera rec.709” IDT that seems to have a behavior close to what the old “output” IDTs proposed ==> untone map the image + gamut conversion. I say “seems” as it’s just a visual guess…
Was this “ITU/camera rec.709” IDT made for that purpose ? Would it be possible to add/get the same kind of IDT for rendered sRGB images too ?

In advance sorry if this topic was already raised elsewhere, and I’d be glad to be redirected there…

Thanks

[Shebbe]

In OCIO2 the displays are their own category separating them from color spaces. I think the main reason is simplicity and flexiblility. To achieve an inverse ODT you have to use an OCIODisplay node with the appropriate spaces and set it to invert. When delivering refs/previews with ODT baked the same needs to be done but without invert checked of course.

Perhaps in the future a write node will have an option to output through OCIODisplay rather than only color space conversion, don’t know if that’s against the design philosophy.

[Warguez (Manu Quinto)]

Thanks Shebbe for the quick answer,

Effectively, I wasn’t aware of this “invert” option ni the OCIODisplay node. It’s seems to work as expected.

However, it’s a bit sad/annoying that this manipulation is only available in nuke AND requires an additional node for each read (even more if we also consider the write node)…
It was also pretty nice in maya for example to be able to load an image plane and convert it on the fly to the desired working color space, for visualization purpose.
The previous system was more flexible to me (but maybe more prone to errors for unexperienced users, I must admit)…

thanks again

[Shebbe]

I think you can still customize a config to have some ODTs defined as a color space but this means that you’re running a customized config which may not always be desirable within a team/collaboration.

[Warguez (Manu Quinto)]

Ideally, using a custom config migh not be a problem for us, as we are already working with custom ocio v1 ones.

But I have to be honest, we’re not ocio experts. The .ocio files are really painfull to understand, and a little help with how to add an ODT as a potential IDT would be greatly appreciated…

[Shebbe]

I’m also not an expert at it, but I think this is the way you can do it.

  - !<ColorSpace>
    name: Rec.1886 Rec.709 - Display - ACES 1.0 SDR Video
    aliases: []
    family: Utility/Display
    equalitygroup: ""
    bitdepth: 32f
    description: |
      Convert ACES2065-1 to Rec.1886 Rec.709 ACES 1.0 SDR Video ODT

      CLFtransformID:
    isdata: false
    categories: [file-io]
    encoding: sdr-video
    allocation: uniform
    from_scene_reference: !<GroupTransform>
      name:
      children:
        - !<BuiltinTransform> {style: ACES-OUTPUT - ACES2065-1_to_CIE-XYZ-D65 - SDR-VIDEO_1.0}
        - !<BuiltinTransform> {style: DISPLAY - CIE-XYZ-D65_to_REC.1886-REC.709}

Took the information from the existing display space and view transform.
You can apply the same principle for any other display space+view transform you’d need.
Here’s my file which added Rec.709 and sRGB at the end of the colorspace list. Where it says family: that’s the folder it will end up in, which you can change if you want. Only relevant for apps that inherit this structure in the dropdown menus rather than a flat list.

[Warguez (Manu Quinto)]

Thanks a lot @Shebbe, seems to work as expected.

With your file we’ll certainly learn how to add/configure more colorspaces by comparing with the original config.

Thanks again

[Shebbe]

Sure thing, glad it helped! I noticed a typo in the sRGB version where I left “Rec.” in the name. Would recommend removing that or redownload the one from my link!

[ken]

I was under the impression that was the purpose of the “- Texture” colour spaces. In this case “sRGB - Texture” and “ Gamma 2.4 Rec.709 - Texture”