I was wondering if there are any plans set yet for what to ship in the ACES2.0 OCIO configs that will be presented as baseline package for implementors/users to use.
No idea if this is the right place but I have some notes based on the current ACES 1.3 configs.
How relevant do people find the presence of linear versions of the camera log spaces? I personally never had the need to use those and remove them in our minimized config to make navigating faster (especially in apps that don’t list the folders/family).
CanonLog3 is present but CanonLog2 is not. AFAIK CLog3 is not the succesor to CLog2. Clog2 has the most dynamic range and is the preferred choice to take into post.
Will F-Log2 (and maybe F-Log) be added to the new studio config? I think that Fuji cameras also get quite a lot of use.
Slight OCD comment: the order of how linear vs log spaces of the same family are listed is inconsistent. Could be nice if the order is the same in the new config if linear variants are kept.
Just to answer your fist question: In the VFX world our main way of interchanging files is in LIN. Either ACES 2065 or the LIN/Camera gamut combo. We then use the LOG encoding to apply LUTs and grades. The “log space” (per se) is not really a space. The files can be either lin or log in a given gamut. So to answer the question: yes really relevant.
Thanks @chuckyboilo , I understand it’s use. I just wondered how many studios were actually dealing with camera linear exports when working in ACES since the ‘expected’ way is making ACES2065-1 linear files instead. Since a linear file can cause confusion we often request no conversion at all if they’re unfamiliar with ACES and just request native log files rather than linear EXRs. But that’s just from my personal experience . Totally no objection to keep it in the configs since it’s very easy to disable them for custom needs.
Ah! Sorry I must have misinterpreted your question. Hopefully, I didn’t pass as trying to “mansplain” this. My apologies.
To further elaborate: yes we use those on output all the time as we revert back to camera gamut on a lot of shows. Some shows will send 2065-1 and some camera gamut. We convert to ACEScg to work and convert back to lin/camera gamut (when show requires it) when sending back EXRs.
They are also important for interchangeability for AMF.
We decode all RAW files to linear colour spaces in the SDKs.
If we write an AMF we need the linear camera spaces to write down our decode choices in AMF.
They are absolutely required as working spaces for compositing: ACEScg as a working space cannot represent all the captured values of many cameras, thus you might find yourself keying a green or blue screen with negative values in ACEScg that was perfectly fine in REDWideGamutRGB. We basically never comp in the CG working space these days, whether it be ACEScg or something in-house.
Thanks for the ordering pedantry, I will take a look at the spreadsheets, we did make a pass recently but it needs some more.
I guess most of it has been said but even in an ACES workflow, it is often preferred to extract the footage in linear but in its native gamut. Most grading systems and VFX pipelines convert them to ACES internally before applying the RRT/ODT. Some workflows will also require to apply a LUT within the camera color space, so in linear, you are almost there.
. Totally no objection to keep it in the configs since it’s very easy to disable them for custom needs.