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
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 - Texturedecodes textures that have been encoded usingRec.709/BT.709/sRGBGamut and theGamma 1.8OETF/CCTF. -
sRGB - Texturedecodes textures that have been encoded usingRec.709/BT.709/sRGBGamut and thesRGBEOTF-1/CCTF. -
sRGB Encoded AP1 - Texturedecodes textures that have been encoded usingACEScg/AP1Gamut and thesRGBEOTF-1/CCTF.
Cheers,
Thomas
Thanks so much. So a couple follow-up questions:
-
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?
-
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
Pointer’s Gamut vs Rec. 2020 primaries
The Linear Rec.709 (sRGB) color space has:
from_scene_reference: !<MatrixTransform> {matrix: [2.52168618674388, -1.13413098823972, -0.387555198504164, 0, -0.276479914229922, 1.37271908766826, -0.096239173438334, 0, -0.0153780649660342, -0.152975335867399, 1.16835340083343, 0, 0, 0, 0, 1]}
Previously it was:
to_reference: !<MatrixTransform> {matrix: [ 0.439632981919, 0.382988698152, 0.177378319929, 0, 0.089776442959, 0.813439428749, 0.096784128292, 0, 0.017541170383, 0.111546553302, 0.870912276314, 0, 0, 0, 0, 1 ]}
Curious what the reason was for the change? They appear to do the same thing.
The direction has changed! 
1 Like
We do use that in Unreal Engine all the time, our working space is ACEScg and UE has buitlin sRGB encoding/decoding transfer functions.
Thanks @Thomas_Mansencal
so just to make sure I’m correctly understanding: This would be used for a texture map saved as EXR (in ACEScg AP1) that needs to be read into Unreal Engine?
Not EXR files, but 8-bit texture files that use sRGB EOTF-1 and AP1, e.g. PNG.
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?
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
2 Likes
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
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
