Very, very informative - thank you very much @troy_s for taking the time! I continue to hammer 
!
I came up with some theory on how to implement a proper ACES workflow, based on your insights. And how to integrate the unique features of Filmic Blender into that ACES workflow. Scroll all the way down! I think Iām gonna give it a try 
.
Default Color System First thingās first. If I understand correctly, this is Blenderās default (Rec709 gamut = sRGB gamut) :
Cycles Render (scene-referred [0, inf], linear encoding, Rec709 gamut)
*Colors coming out of cycles will have Rec709 primaries.
*More saturated colors (like (2, 0, 0) red) are lost on clip.
|
| * Transfer Function: sRGB on [-0.125, 4.875]
/
sRGB (display-referred [0, 1], gamma encoding, sRGB gamut)
*When put into compressed/viewing focused .jpg, .png, etc., all more saturated colors than in the limited sRGB gamut are lost.
*** Sometimes saved with an sRGB transform extra, which is undone on load.
Filmic Log Color System Default system is terrible. DR is lost, itās not photographic at all. Hereās how I understand Filmic Log:
Cycles Render (scene-referred [0, inf], linear encoding, Rec709 gamut)
*Colors coming out of cycles will have Rec709 primaries.
*More saturated colors (like (2, 0, 0) red) are lost on clip.
|
| * Log2 transform from [-10EV middle grey, 15EV middle grey) to [0, 1]
| * 3D LUT: Crosstalk simulation on HDR log2 encoded footage.
| * Multiply: Scale [0, 0.66] to [0, 1], such that the output covers [-10EV middle grey, ~6.5EV middle grey]
/
Filmic Log (display-referred [0, 1], log2 encoding, Rec709 gamut)
- Itās not exactly Rec709 gamut, LUTCalcās analysis says. But itās very, very close.
- Filmic log gives us HDR, not wide gamut.
| * Look LUT: log2 [0, 1] to display [0, 1]
/
Filmic Output (display-referred [0, 1], gamma encoded, Rec709 gamut)
- The gamma encoding varies based on the setting - base, high, very high contrast, etc. .
- It is sRGB; calibrate your monitor to sRGB!
Proposed ACES Color System If all this is accurate, then wouldnāt an ACES transform stack look something like this:
Cycles Render (scene-referred [0, inf], linear encoding, Rec709 gamut)
*Colors coming out of cycles will have Rec709 primaries.
*More saturated colors (like (2, 0, 0) red) are lost on clip.
|
| * Matrix Transform: Since invalid (beyond Rec709, like (2, 0, 0)) colors in Rec709 are valid (<1) in ACES, we should do a simple (unbounded) matrix trasform.
| * This would form the IDT for Cycles. Quite simple, as the āCameraā's custom gamma/gamut is well-defined in our case - itās just Linear Rec709.
/
ACES Space (scene-referred [0, inf], linear encoding, ACES gamut)
- Grades to ACES images from different cameras should look the same. Thatās the whole point.
- Supposedly, different render engines would produce the same result once converted to ACES - no matter their native gamut.
***Save to EXR! Impossible in Blender - it refuses to dump anything but Cycles base data.
*SO: Work in ACES, preview in ACES, but save Cycles data. Then use an external tool to bring the dumped EXRs in line with what you worked with.
For Display & Final Output we have the RRT and the ODT. The RRT, according to http://www.openexr.com/UsingOpenEXRandCTL.pdf, makes āACES images
that are approximately scene-linear look pleasing and āfilm-likeā when displayed on a screenā. In other words, itās a creative choice. A quote:
"It is expected that most movie production projects will use the RRT for color rendering. However, for
some projects, the RRT will be replaced by an alternative RT. For example, 3D computer animation is
sometimes done such that displaying the resulting ACES images directly on the reference display yields the
intended result. In this case color rendering is not needed and the RT is an identity transform."
**The grade happens here
ACES Space (scene-referred [0, inf], linear encoding, ACES gamut)
|
| * Clip [0, 1]. Since
| * Optional RRT 3D LUT, defined in CTL: https://github.com/ampas/aces-dev/blob/master/transforms/ctl/rrt/RRT.ctl
| * Alternatively, use nothing. Use an Identity RRT.
/
OCES Space (display-referred, [0, 1], RRT encoding, ACES gamut)
- We now have a pleasing OCES image. But itās still in ACES gamut. No monitor can display this stuff.
|
| * Mandatory ODT: Does a gamut transform, then a gamma encoding, depending on target space.
| * Matrix Transform: From ACES RRT (with wide color reproducibility) to Target Gamut.
| * Gamma Transform: From Linear Target Gamut to Target Colorspace.
/
Target Space (display-referred [0, 1], target encoding, target gamut)
Implementation of ACES-based system. Might be worth making an ACEScg version of this, as well. See http://www.slideshare.net/hpduiker/acescg-a-common-color-encoding-for-visual-effects-applications .
How would this ACES system I described be added intuitively?
-
Set scene_linear to ACES in config.ocio. reference space should be XYZ (linear XYZ, obviously), and all spaces should be defined against that (D65).
[LIST]
-
Why XYZ? All spaces have XYZ-relative matrices because itās huge. Weāll never see or interact with it, of course.
-
Why ACES for scene_linear? 1) Workflow becomes intuitive & future proof, 2) So that saving ACES to EXRās is possible. (hopefully. God I hope so. Itās worth a patch if not.)
-
As in Filmic Blender, we keep 25 stops of DR, using the range [-12.473931188, 12.526068812] for scene_linear.
-
Viewable output gamuts like sRGB, Rec709, Rec2020, Adobe RGB, etc. will clip to [0, 1]. Unviewable DI gamuts like ACES, XYZ, S-Gamut, etc. will retain the full DR of Scene_linear.
-
āDisplaysā: contain Target Spaces. sRGB, Rec2020, Adobe RGB, S-Gamut (with log encoding), etc. and of course ACES.
-
āViewsā, which represents the context of a Target Space.:
-
Raw (no transform; just ACES space)
-
Default (see ACES Display).
-
- āACES Displayā (ACES working space ā> direct ODT to the Target Space)
-
ACES RRT (ACES working space ā> RRT and ODT baked together to the Target Space)
-
Filmic (ACES ā> Rec709 ā> log2 encoding ā> desat65cube.spi3d ā> multiply ā> deencode log2 Rec709 ā> ACES ā> RRT ā> ODT to Target Space)
[LIST]
-
This essentially only uses the cube file for its crosstalk feature. The RRT takes the place of filmic contrast profiles.
[/LIST]
-
āThe ACES displayā, specifically has fewer options:
-
Raw
-
ACES (same as Raw. Because scene_linear is ACES. Itās there for the sake of being there)
-
Filmic display, works exactly as filmic blender.
-
Raw
-
Log (Rec709 ā> log2 encoding ā> desat65cube.spi3d ā> multiply; itās assumed that the Look does the ACES ā> Rec709 transform before the View)
-
Looks implement Filmic Blenderās contrast profiles.
-
Contrast profiles, false color - all work as usual with Filmic/Default. Implementation hasan āACES ā> Rec709ā matrix prepended.
-
In a perfect world, an ACES gamut, log2 encoded, version of desat65cube.spi3d and the other looks would remove these nasty ACES ā> Rec709 transforms and keep us in the realm of ACES logic, instead of exporting us to Rec709 logicā¦ No?
[/LIST]
.
