OpenColorIO 2 Configs for ACES

It works the same way indeed it is however geared for devs as it is missing quite a bit of transforms to be useful for production. This should be addressed with the Studio config.

The latter, i.e. Piece-Wise because it conforms to the ACES sRGB Output Transform definition. I think we might have discussed about adding a Gamma 2.2 Display at the OCIO ACES Config level but I don’t remember what was the take on it from the Working Group. Something certain is that at the minimum the Config will honour the ACES transforms and stay close to metal without replacement. It does not mean that we cannot add a new display that said! Feel free to open an issue on the repo.

Cheers,

Thomas

Is there an estimate when the Studio config will be released?
I really like the clarity of these new ones and would like to have one config file for all software I use to link to.
At the moment (Redshift, Aftereffects, Resolve, Mocha) all use their own config (which I don’t know which it is) or I manually link them to the “old” ones. Which seems to slow down things sometimes a bit.

This CG-Version worked great in all of them. But I am especially missing the cct transform for certain compositing tasks.

Thanks!

Peter

Tentatively, a first version for Siggraph!

Land in sight :slight_smile:

Thanks!

Hi, I have a little update to report for the OCIO config that I tried in Blender:

I did a little test today with the “OpenColorIO-Config-ACES 0.2.0” config in Blender 3.3 alpha.
The problem is still the same on my iMac, but not on the M1-MBP.

I tried today another config that is coming with Maya 2023 I believe (the folder is actually called “Maya2022-default”), also in Blender 3.3 alpha.
This config does does not twist the view transform and the result looks just fine on both the iMac and the M1-MBP.

I had a look in both configs but I understand too little to spot the difference in the configs that could introduce the error/bug that I encountered.

Best

Daniel

@TooDee Golly that does look quite skewed in that video!

The difference between the two configs I believe is that the ACES-CG config is using a built-in transform for the sRGB display:


  - !<ColorSpace>
    name: Display - sRGB
    family: Display
    equalitygroup: ""
    bitdepth: 32f
    description: Convert CIE XYZ (D65 white) to sRGB (piecewise EOTF)
    isdata: false
    categories: [file-io]
    encoding: sdr-video
    allocation: uniform
    from_display_reference: !<BuiltinTransform> {style: DISPLAY - CIE-XYZ-D65_to_sRGB}

while the Maya one is not:


  - !<ColorSpace>
    name: sRGB
    family: Display
    description: |
      sRGB monitor (piecewise EOTF)
    isdata: false
    categories: [ file-io ]
    encoding: sdr-video
    from_display_reference: !<GroupTransform>
      children:
        - !<MatrixTransform> {matrix: [ 3.240969941905, -1.537383177570, -0.498610760293, 0, -0.969243636281, 1.875967501508, 0.041555057407, 0, 0.055630079697, -0.203976958889, 1.056971514243, 0, 0, 0, 0, 1 ]}
        - !<ExponentWithLinearTransform> {gamma: 2.4, offset: 0.055, direction: inverse}
        - !<RangeTransform> {min_in_value: 0., min_out_value: 0., max_in_value: 1., max_out_value: 1.}

You could confirm that by swaping in that groupTransform in place of the BuiltinTransform in the ACES-CG config.

While you’re at it, you may want to consider using the pure 2.2 display instead

 - !<ColorSpace>
    name: Gamma 2.2 / Rec.709
    family: Display
    description: |
      Gamma 2.2 monitor with Rec.709 or sRGB primaries
    isdata: false
    categories: [ file-io ]
    encoding: sdr-video
    from_display_reference: !<GroupTransform>
      children:
        - !<MatrixTransform> {matrix: [ 3.240969941905, -1.537383177570, -0.498610760293, 0, -0.969243636281, 1.875967501508, 0.041555057407, 0, 0.055630079697, -0.203976958889, 1.056971514243, 0, 0, 0, 0, 1 ]}
        - !<ExponentTransform> {value: 2.2, direction: inverse}
        - !<RangeTransform> {min_in_value: 0., min_out_value: 0., max_in_value: 1., max_out_value: 1.}
1 Like

Hello,

@carolalynn, @doug_walker, @Michael Dolan, @KevinJW, @zachlewis and all the other contributors are pleased to announce that we have a first version of the Studio Config: Release OpenColorIO-Config-ACES 0.3.0 · AcademySoftwareFoundation/OpenColorIO-Config-ACES · GitHub

Please give it a crack and let us know if you have any issues!

Summary of the Studio Config

Displays

  • sRGB
  • Rec.1886 / Rec.709 Video
  • Rec.1886 / Rec.2020 Video
  • Rec.2100-HLG
  • Rec.2100-PQ
  • ST2084-P3-D65
  • P3-D60
  • P3-D65
  • P3-DCI

Linear Colorspaces

  • ACES2065-1
  • ACEScg
  • Linear P3-D65
  • Linear Rec.2020
  • Linear Rec.709

Camera & Grading Colorspaces

ACES

  • ACEScc
  • ACEScct

Blackmagic Design

  • DaVinci Intermediate WideGamut
  • Linear DaVinci WideGamut
  • DaVinci Intermediate Log - Curve

Panasonic

  • Linear V-Gamut
  • V-Log V-Gamut
  • V-Log - Curve

RED

  • Linear REDWideGamutRGB
  • Log3G10 REDWideGamutRGB
  • Log3G10 - Curve

Sony

  • Linear S-Gamut3
  • Linear S-Gamut3.Cine
  • Linear Venice S-Gamut3
  • Linear Venice S-Gamut3.Cine
  • S-Log3 S-Gamut3
  • S-Log3 S-Gamut3.Cine
  • S-Log3 Venice S-Gamut3
  • S-Log3 Venice S-Gamut3.Cine
  • S-Log3 - Curve

ITU

  • Camera Rec.709

Texture Colorspaces

  • Gamma 1.8 Rec.709 - Texture
  • Gamma 2.2 AP1 - Texture
  • Gamma 2.2 Rec.709 - Texture
  • Gamma 2.4 Rec.709 - Texture
  • sRGB - Texture

Utility Colorspaces

  • Un-tone-mapped
  • CIE-XYZ-D65
  • Raw
  • Rec1886 - Curve
  • Rec.709 - Curve
  • sRGB - Curve
  • ST-2084 - Curve

Cheers,

Thomas

4 Likes

Congratulations to everyone involved!!! Incredible work!

1 Like

Fantastic work all! Any particular reason AWG3/4 / LogC3/4 are missing?

1 Like

Hi @Shebbe ,

This is a great question and it was asked on Slack: Yes, there is a good reason, we haven’t finished the work with ARRI (@scoopxyz) to finish integrating the ARRI transforms: DRAFT: add ARRI contributions to OCIO-ACES CLFs by scoopxyz · Pull Request #54 · AcademySoftwareFoundation/OpenColorIO-Config-ACES · GitHub and we wanted to have a release for Siggraph!

They will come soon, stay tuned!

Cheers,

Thomas

2 Likes

Precision landing!
Thanks for all your great work!

Peter

1 Like

The same is true for the currently missing Canon input transforms too, yes?

Correct! Sorry for the delay but yes, the Canon IT’s will be in the next release as well.

2 Likes

OpenColorIO Configuration for ACES - Release Candidate 1

Hello,

The OCIO Configs Working Group is pleased to let you know that the OpenColorIO Configuration for ACES - Release Candidate 1 configs are available:

Cheers,

Thomas

4 Likes

Hi,

The OCIO Configs Working Group is pleased to announce that the OpenColorIO Configuration for ACES - Release Candidate 2 configs are available. This is hopefully the latest release before the final in a few days: Release OpenColorIO-Config-ACES 1.0.0-rc2 · AcademySoftwareFoundation/OpenColorIO-Config-ACES · GitHub

Cheers,

Thomas

4 Likes

Hello,

The OCIO Configs Working Group is pleased to announce the stable release of the new OpenColorIO Configuration(s) for ACES. We sincerely thank all the people from the past and the present that contributed to this community effort.

Cheers,

Thomas

3 Likes

@Thomas_Mansencal could you say a bit about how to properly use these texture color spaces? Thanks!

Hi @Derek,

Those are intended to be used for texture workflows, the way to read it is as follows:

%OETF/EOTF-1/CCTF% %Gamut% - Texture

So for example:

  • Gamma 1.8 Rec.709 - Texture decodes textures that have been encoded using Rec.709/BT.709/sRGB Gamut and the Gamma 1.8 OETF/CCTF.
  • sRGB - Texture decodes textures that have been encoded using Rec.709/BT.709/sRGB Gamut and the sRGB EOTF-1/CCTF.
  • sRGB Encoded AP1 - Texture decodes textures that have been encoded using ACEScg/AP1 Gamut and the sRGB EOTF-1/CCTF.

Cheers,

Thomas

Thanks so much. So a couple follow-up questions:

  1. Would that mean that if a texture was made under an ACES (sRGB) Output Transform it would be read in with sRGB -Texture, and if it was made under an ACES (pure gamma 2.2) Output Transform it would be read in with Gamma 2.2 Rec.709 -Texture?

  2. What would be the situation where a texture is encoded with AP1 gamut rather than Rec.709 gamut? Would that be done by setting the color picking space in the 3D paint program to ACEScg (for AP1) rather than to sRGB - Texture? Along those lines, why is there a Gamma 2.2 AP1 - Texture and not a sRGB AP1 -Texture? Or is that what sRGB Encoded AP1 - Texture means?

My guess is that AP1 texture spaces are introduced to start supporting wider gamut textures (albedo) for materials. Scans or creations don’t need to be limited by sRGB primaries anymore and can be more physically accurate.

Pointer’s gamut vs sRGB primaries
image

Pointer’s Gamut vs Rec. 2020 primaries
image