First off I’d like to say that so far ACES had been very beneficial to our workflows. That being said there’s always room for improvement.
LMTs. I get what LMTs are. But so far we can’t create them or use them. Davinci Resolve does not automate this process… All we can use is LUTs… This portion needs to be streamlined.
Onset monitoring and ACESproxy. This also is a little bit confusing. DPs should be able to monitor with the ACES “look”. No cameras offer this presently and we don’t have any clear and simple workflows (IE: in Quebec people don’t use DITs). I would like to be able to send a DP with an ACES based look embedded in a LUT box or directly into a camera.
ACES colors. While the base image looks pretty nice I think this base could be somewhat refined. Certain primary colors are too poppy or saturated. I know that I can trim these down using my CC software. But it’s extra work we need to do. It would be nice to have tools to modify certain primaries. This could be like an “RAW” development panel.
Film LOOKS. People still want film emulations. I would be great to have a solution for this…
ACESproxy is not required to monitor on set with ACES. You can bake a combination of an IDT, the RRT and an ODT into a LUT and use that to monitor with an ACES base look. This can be done in a number of ways. For example, here is how you would create a LUT for Rec.709 ACES monitoring of LogC with OCIO:
That’s not correct. Sony offers official and “special” LUTs for at least F5 and F55. Which output either a RRT/Rec709 ODT or ACESproxy. Those are offically released, by Sony and Academy approved.
That’s probably also true for the F65. But that I don’t know.
Those even consider the varying EI-Settings - which I still don’t understand how they do it. But it seems to be a Sony-Special-LUT.
I’ve made these LUTs via lightspace. But it always seem like I’m doing something “illegal”.
The ideal situation would be to have a way to make looks that have an ACES starting point available for on set purpose. And all of this in a streamlined and comprehensive way.
LMTs - I like the idea of them, but there is no execution beyond that idea stage yet. It’s like having to write BASIC in order to use a computer. Pre-early stage.
+1 on the ACES colours. Especially when you’re going to sRGB and skin starts to look ghoulish because the VLUT and the output don’t match (unless you read it back into ACES which entirely defeats the purpose).
Film LOOKS - Yes, that’s a big drawback of using ACES and one of the reasons I stopped using ACES. I think tools like Lattice could write attachment “configs” that could be loaded instead of having to be part of someone’s config.ocio. But an ‘attachment’ config would be a hack too. Something real would be great. It’s something that could be addressed with external LMTs eventually.
RRT: As others have said before, I also think the RRT should be neutral. I’m in favour of the RRT having a look to start from, but it should be up to the artist to make the call which look that is. Maybe the RRT could have a ‘default’ look (backwards compatibility) and users could install looks they like and pick one from those instead of the ‘default’ look. A set of common looks could be shipped with the base OCIO (direct linear, film generic, default…).
It’s very bleeding edge right now and only really used by the people who helped develop it (at least that was the impression I got so far). It definitely needs to mature to a point where it’s: Load this project, it looks right, render, it still looks right. Like we have it with nuke_default at the moment for CG.
I don’t mind more complex LMTs, as long as the complexity is optional and they can be used close to the simplicity of a (documented) LUT. If someone wants to write filters into an LMT for actual simulation of film development techniques, it’d be great if they can do that (and probably profitable to them) but those are probably not the cases the majority would be using them.
I would not say that ACES is bleeding edge: a lot of studios have been using it successfully and have shipped either films or games for the last half decade although it is true that it has not reached a global plug’n’play state across all the hardware/software platforms.
“Film LOOKS. People still want film emulations. I would be great to have a solution for this…”
“Film LOOKS - Yes, that’s a big drawback of using ACES and one of the reasons I stopped using ACES”
I agree that to be able to use 3D LUTs (Film Emulation LUTs for creative purpose, like those provided by da Vinci Resolve for example) is a key asset of color grading.
I recently reached out calling for a series of still-missing components in an ACEScentral thread from April 15th. Just felt this thread is presently and appropriately collecting the feature requests for v2, so I’m copy-n-pasting here.
In my opinion the addenda (including some which I pointed out in as early as 2013, and which should be in the internal to-do list already) are:
Improved integration of ACES in IMF and other mezzanine, mastering and long-term archival formats; in particular, ACES-aware OPL syntax.
Improved consistence of metadata/tags layout in OpenEXR and MXF containers, including pictures in colorspaces different from ACES2065-1 (usually, ACEScg). This means improving on from SMPTE ST2065-4 and ST2065-5, possibly embracing other production containers, such as QuickTime and ARRIRAW.
Redesign of the ACESclip XML metadata tool to sidecar with non-EXR files as well and support full stack of production metadata
Encourage the use of CommonLUT format (CLF) to increase its read/write support by more software applications
Include a “Color Pedigree” (in both IMF, SMPTE2065-4, SMPTE2065-5, as well as in the ACES clip container) that tracks the “past” and “present” color history of a clip: how it was generated and manipulated to become the clip the pedigree is currently addressing, including optional intents for output colorimetries. Procut partners honouring such color-pedigree may better manipulate the color management of such pictures – even pictures not (yet) in ACES colorimetry, like raw-camera pictures or assets not sourced in ACES, for a correct interpretation in an ACES pipeline.
Add color-pedigree metadata in the CommonLUT format as well, so that LUTs are described by XML tags as well, for applications to better acknowledge its use and possibly warn users about (possibly) wrong applications (e.g. converting from float-to-int and then back, or applying a non-invertible transform, or using a missing or wrong shaper-LUT).
Agreeing with the ACES Retrospective and Enhancements document, analytical invertibility of the RRT is a key requirement for the improvement of a truly interchangeable framework in diverse M&E echosystems.
Better integration of UUIDs for ACES CTL components like IDT, ODT, RRT, LMT and generic utilities so that, for example, concatnation of color operations can be recorded (and stacked) and, in case of successfull juxtaposition of a color mapping and its inverse, simplifications can be applied to reduce approximation/roundoff errors. Academy-original or other proprietary CTLs can have optional hashing syntax at the beginning for their integrity self-check.
Creating a CTL repository that includes Academy-official ODTs from various ACES releases and vendors (thus also IDTs) and a way to automatically download and validate these CTLs against their UUID. GitHub may be a choice, but an oscars.org domain would be better. This should work in a way similar as to how each Digital Cinema manufacturer hosts its servers’ public certificates (retrieved by the servers’ serial numbers as unique IDs) – but without the need for all that security.
Official documentation that maps individual metadata and tags from non-ACES production file formats, into both ACESclip, SMPTE2065-4 and ST2065-5 metadata/tags, to use them when addressing/referencing non-ACES images (such as REDCODE, ARRIRAW, DNG, MXF, ProRes, XDCAM). For example:
which unique identifiers or tags from those file formats, etc. should be used as picture UUIDs
which TimeCode fields should be considered
which colorspace mappings should be used for ACES colorspaces and/or AP color primaries’ families
Consider creating an integer-math encoding, “ACESproxy-variant” of ACEScct colorspace, for on-set viewing and CDL of material to be graded in ACEScct.
Extend the UX Guidelines to OpenColorIO and greatly improve OpenColorIO naming-convention to better match with ACES (e.g. remove ambiguities such as “Utilities - Texture” in an ACES naming context)
Relevant for tape archives: include / complement ACESclip metadata with LTFS specific metadata to be included in the LTO Index partition for long-term archival of color- and production-specific metadata that is really application-agnostic.
Not all of the above are high-priority, but necessity for all of them was asynchronously confirmed by the several teams I worked with in the last few years ( post/finishing, CG/VFX, on-set/D.I.T.) in several professional applications of ACES 1.0.x for theatrical releases. More specifically, I think these missing or yet-incomplete components are:
Have a look at my post earlier in this thread, which shows how to use OCIO to create a LUT for ACES monitoring. My example is for a LogC AWG source, but you can change that to any other input colour space.
If you are not comfortable working in the command line, tools such as LightSpace and Lattice can make ACES monitoring LUTs.
But I agree that it would be useful if The Academy were to make a set of officially approved ACES monitoring LUTs available for various camera log formats.
yes I saw that but I never used OCIO and it looks quite complicated.
But I agree that it would be useful if The Academy were to make a set of officially approved ACES monitoring LUTs available for various camera log formats
yes that would be amazing, perhabs from ACES proxy to Rec709 and and from ACEScc to Rec709 would be great to have,
Here are three LUTs in .cube format, which are ACESproxy to Rec.709 and ACEScc to Rec.709 (these two are essentially legal in legal out, and full in full out versions of the same LUT) and also the LogC one from my OCIO code above.
Bear in mind, ACESproxy is unscaled SDI code values, so the LUT generates Rec.709 in the same range, and is therefore suitable for use in a hardware LUT box. The ACEScc LUT generates full range Rec.709.
Thanks a lot for the files.
Do you have a LUT in .cube format for ACEScct?
This to avoid dealing with the incompatibility between ACESproxy and ACEScct in post.
I’ve added an ACEScct version to the same download.
I should point out that the shape of the curve on the ACEScct version as it goes into black is not ideally suited to a 33^3 LUT with linear interpolation. Tetrahedral interpolation and/or a larger mesh is preferable.
In any case, remember that these LUTs should be used for preview purposes only. A proper ACES implementation should be used for finishing.
