- 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…).
@frankjonen. Thanks for the feedback Frank.
I feel like ACES is still a “geek” thing. If we want more people to adhere we need to make it more “plu and play”.
Thanks!
1 Like
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.
1 Like
“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:
1 Like
are there any offical ACES proxy to Rec709 LUT which I can you use on set to view the picture coming from a RED?
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,
What LUT format do you need?
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.
2 Likes
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.
@Willian_Aleman. So the 709 LUts are meant to be applied to a normalize 709 signal coming for any camera?
Nick, thanks a lot for your generosity. I won’t mind to pay or contribute for the labor of this type of work.
I haven’t experimented with the LUTs yet. I would prefer if Nick response to the question.
The LUTs I have posted are not to be applied to 709 signals. They create 709 signals with RRT/ODT applied from ACESproxy, ACEScc, ACEScct and LogC.
There are actually a number of LUTs available as part of the OCIO config:
I’m not sure I follow… What are these luts expecting as source color space?
The first part of each LUT’s name indicates the input colour space in expects. e.g. ACEScct_Rec709ODT_EE.cube expects the source to be ACEScct.
They all transform the input to ACES linear, then apply the RRT followed by the Rec.709 ODT.
The EE or LL part of the file name follows the ARRI LUT generator convention for input and output range.