Hi,
Does anybody know if it would be possible to make a custom RRT/IDT combo for Resolve.
I’ve been hearing that certain post houses have been making their own RRT. I’d like to know more about this if anybody has info.
Thanks!
Changing the RRT is discouraged and here’s why: one of the many valuable benefits of ACES is that it unambiguously defines, and in many cases standardizes critical components of the imaging pipeline. Sticking with one RRT is important for facilitating reproducible results and maintaining interchangeability across multiple facilities without losing the creative intent. When working in-house, it’s tempting for “super-users” to control their pipeline and to “customize” the RRT, though doing so is counter to basic ACES design principles.
An out-of-spec customization like changing the RRT introduces much more room for error and keeps us in a world of snowflake workflows and the game of “guess the viewing LUT.” With one RRT, there is only one rendering and only metadata about what version of ACES and which defined (and soon-to-be standardized) Output Transform was used is required for full access to the creative intent.
Since the default “look” built into the RRT isn’t necessarily to everyone’s taste, ACES provides a means to alter the default look via the Look Modification Transform (LMT). I will be posting some explanations of LMTs and how to create and use them in the coming days.
In the visual effects industry, it is now more common to receive footage as ACES from production, finally. However, I have not seen one single project where the production required us to use the RRT as the official viewing transform. They always provide their own LUT, which vary wildly from project to project and usually serve a precise aesthetic goal.
I’ve also seen a renowned DP over exposing his entire film only to bring everything down using the provided LUT (exposing to the right). He could have used the CDL to do the same, but I guess he thought is was more trustworthy that the LUT would be applied everywhere in the post pipeline where the CDL might be omitted in some places. He did use CDLs for minor adjustments on a per shot basis.
If I had to qualify one viewing transform as standard in the industry because it is used more often than others, it would be the Alexa K1S1 LUT. But I think it has been on about 15 to 20% of the movies I’ve worked on.
To say honestly… I’m very happy with the RRT. But I’m always keen on knowing what people are doing.
That being said what @sdyer explained makes total sense. it would defeat the whole purpose of ACES.
The only thing that’s bugging us (here at post-moderne) is the rendering of the reds in P3. A little bit too intense. And this goes for most primary colors. But red is a standout.
Thanks for the reply!
Hi Charles.
I completely agree with Scott as to the two main reasons to not change the RRT:
##1
Changing one core component such this in a system like ACES most certainly breaks its universality and above all interoperability benefits – why bother using ACES (rather than any other “custom” workflow) then?
##2
On a creative standpoint, one thing that I would like to state clearly is that, while the RRT may have an aesthetic look embedded in its scene- to display-referal conversion (and was indeed designed to have one), its function is purely technical, so the part where the basic “look” for a show or shooting is sought after can, would and should be placed in the Look Modification Transform (LMT ) component of an ACES pipeline.
####To go into more detail for the first point above:
if you change the RRT you need to change all the Output Transforms as well, because all of them (or at least the “forward” ones) internally include the RRT as first “block”. So, as Scott said, you will probably end up dealing with even more LUTs (and thus possibly more color-accuracy errors) than sticking with your long-tested (yet practically effective) workflow. So why bother using ACES at all?
####To go into more detail for the second point above:
First of all please have a look at the official documentation about LMT: TB-2014-010: Design, Integration and Use of ACES Look Modification Transforms.
The LMT is a non-fixed component of ACES and, despite some LMTs are included into release versions of ACES (e.g. the “bleach bypass”), they are just meant as examples, while users can create custom LMTs as they prefer and even stack with each other. CDLs can be part LMTs, as primary grades do. They are all to be applied in ACES2065 colorspace (or ACEScc/ACEScct as working-space only), thus before any Output Transforms (RRT+ODT).
So if one wants to “unbuild” the RRT an LMT has to be graded or designed, that is stacked below/before the RRT, that hits the aesthetic goal after the LMT is viewed through the standard ACES output pipeline. It is guaranteed to be achievalbe without removing/replacing the RRT because of the invertibility of it.
But, ultimately, color-creative decisions should be left to DoPs and colorists, and color assistants and DITs, leaving terminologies like RRT and ODT just out of the equation since they are internal blocks meant to be referred to for technical purposes only.
Speaking about real-world experience instead, I must say that all the colorists whom I presented the latest versions of the RRT to work with since 2014 (but one) liked its default look and started to implement it from the beginning (using FilmLight Baselight ). The one colorist that didn’t like it turned out to be just very acquainted to his own “base look”, and actually asked me to change the RRT at the beginning (so I proposed to designing an LMT that also inverted the effects of the RRT and we started designing it together, both with formulæ n’graphs, and via colorist’s tools).
The more he started using ACES in production though (grading in ACEScc and viewing in DCI P3 out of the projector) the more he liked its default look. So in the end it was him asking to stop this “deRRT” LMT in the end ― things I was verry happy to. I think it is very important that colorists I work with feel satisfied with all the technologies they use in the first place, including color management.
At the end of the story, however, we also ran a test showing to a couple of outstanding DoPs two different looks to start with and they all agreed to base-light the one with just the basic RRT applied ― and start grading from there.
As a last point, I want to say a couple of personal opinions as to the reasons why I believe that many facilities either used to work and might still be working with non-standard RRT.
-
First of all earliest pre-release versions of the RRT were highly non-invertible, which caused potential troubles to ACES’ early adopters, i.e. important film post labs (like one I worked in for many years). Each one of these labs already had their own complete colour management solution, and had to stick to it due to color-alignment constrains with the photochemical process from film-scanning throughout film-printing. So early-adopting a pre-release version of ACES might have included custom RRTs.
-
Secondly, most of these labs (either they don’t do photochemical any longer, or they do but I’m told ACES works much better with film now) are still sticking with their own color management workflow which has probably been successfully used for longer than ACES was released. This sometimes results in them exposing custom LUTs to external partners and contractors, wose management is yet quite cumbersome and likely feasible only if you also own a rock-solid color expertise, which smaller facilities usually don’t have. That is where ACES comes in.
Said that, even bigger labs that were not early adopters are now all aligned to ACES, but sometimes smaller actors who are used to getting on with workflows shaped alike the bit labs’ color management, and based on cursom, unspecified LUTs, have some difficulty in changing the color approach.
1 Like
Thanks for the insight @walter.arrighetti!
The whole LMT thing is still a bit foreign to me. I get what they are meant for… I just don,t understand what form they are supposed to take.
For example, I have a look built on ACEScct and I want to use that as an LMT to forward it to VFXs. What for will this take? A Lut? It seems that we are out of that world when working in ACES.
If only there was a way to create DCTLs or CTLs from our grading systems…
Is anybody working on streamlining this process?
Thanks!
1 Like
Hi,
Some of us in the VFX and Interactive Entertainment industries would actually like to have a parametric RRT, this is relevant for multiple reasons: the RRT look is far from being neutral, heavy on blacks, highlights rolloff is strong, etc… which makes it very hard to work depending the system you use. This is especially relevant for those without LMT support. Also and importantly, altering the tonescale too much in the LMT implies that you are altering significantly the image state which is still meant to be scene referred before entering the RRT.
Given that you properly track the parameterisation of the RRT through metadata, this is a non issue, the RRT itself has been through many public versions already.
I would argue that the look is beyond technicality as of now 
I’m not sure to follow here: the ODTs are feeding on OCES values, i.e. colours you would project to an idealised display, and they were built specifically to make the display an independent variable in the image rendering process. If you render OCES values that are pleasing and faithful to your scene on the idealised display, there should be no need to change the ODTs, implying that it should be theoretically entirely possible to alter the RRT without affecting the ODTs, the system has been designed with this in mind.
Cheers,
Thomas
2 Likes
The other issue with relying on passing around custom LUTs is that they’re usually designed for only one input and one output. Let’s say that you send me a LUT that expects ACES 2065 as input, applies a “customized” RRT, and outputs to P3-DCI code values.
But let’s say that in my facility we calibrate our projectors to P3-D65. Then either:
a) your images will not look as intended,
b) I need to recalibrate my projector to P3-DCI,
c) I will need to come back to you and ask for a LUT that goes to P3-D65, or
d) I need to be smart enough to append another LUT or transform which will properly “undo” the P3-DCI encoding and prepare the code values such that I can view P3-DCI on a P3-D65 calibrated device.
That’s a lot of room for error, and not meant as a slight against anybody specific, but mistakes get made all the time and/or not all facilities have the time/experience/or know-how to be able to properly adjust for the differences. So you’re much more likely to get option “a” and have the images get viewed incorrectly (because “P3 is just P3”, right? 
)
But if we both agree to use ACES with the standard RRT, you can just send me your ACES files and I can view them as intended by selecting an Output Transform appropriate for my display set-up. (obviously this is a simple example, I wouldn’t want to just assume Rec. 709 or HDR or something drastically different than your mastering set-up would look correct).
1 Like
Scott, I agree with everything you say.
What happens sometimes is we ask them what their LUT is made for, and they reply they have no idea.
2 Likes
@flord. That is exactly why ACES is here for. Apart from having its official file format for LUTs with full metadata aimed at describing soure and target colorspaces (the CommonLUT Format, even if it still poorly supported), the main purpose is having a pipeline where every hardware device, firmware, and imaging software employs ACES components that are fully interoperable. Much less room for color-interpretation errors.
@Thomas_Mansencal: This is just an ACES-nomenclature misunderstanding here. While Input Transform (v1.0+ name) coincides with IDT (pre-release name), what is called an Output Transform in v1.0+ is effectively concatenation of two internal steps with different pre-release names: the RRT part (common to all Output Transforms) and the ODT part.
Again, separation of RRT and ODT is now part of the “internals” (yet completely open for all to see) and creative/æsthetic decisions should, by ACES design, be all placed “before” the Output Transform.
To use a metaphore: changing the RRT is possible, but is like color-grading using also the contrast/brightness and RGB-offset/gain controls of your reference monitor.
@chuckyboilo: ACES is vendor-agnostic; it just describes what a component should do, leaving implementation details to the manufacturers, software developers and, epecially for the non-fixed parts like the LMT, freedom to decide how to implement it.
For color mappings, for example:
- some color-grading systems (e.g. Flame and Nucoda) use pre-baked LUTs for every color passage (including Input/Output Transforms),
- some others implement the original CTLs provided in the Reference Implementation by AMPAS,
- some others (e.g. Baselight ) implement direcly the maths via OpenGL shaders in the workstation GPU(s),
- others (RED Digital Cinema) just expose a SDK for other vendor products to integrate.
Therefore, as regards LMT, it depends on how your workflow is better suited. You can implement an LMT component via a series of primary grades in your color-correction software, or maybe as a LUT preset in your imaging software/box, or even as a CDL from the on-set. Again, please refer to the ACES official documentation PDF about LMTs.
Right, I was talking in a broad ACES context while I think you might have been specific to Resolve as per the OP.
@walter.arrighetti: I agree with many of your points, but do need to correct your comment that:
- some color-grading systems (e.g. Flame and Nucoda) use pre-baked LUTs for every color passage (including Input/Output Transforms),
In fact, Flame, Lustre, and Maya do not use 3d-LUTs to implement ACES. Instead they use what I would call more of an exact-math implementation of the original CTLs. This allows for greater accuracy across the full floating-point range and much better inversion.
I also wanted to comment on one of the other points in this thread. The word “Look” has become somewhat of a loaded term that connotes an intentional move away from the baseline for aesthetic purposes. As such, I feel it is a bit misleading to say that the ACES Output Transforms impart a “Look”.
There were many design constraints on the development of the ACES Output Transforms but I don’t think the desire for “a look” was one of them.
Rendering transforms for cinema (ACES, motion picture film, camera renderings, …) attempt (at least partially) to do something that is not strictly possible: to recreate the illusion of an outdoor scene within the constraints of a 48 nit white point, 2000:1 contrast ratio, P3 gamut, dark surround, etc.
So any solution is going to involve trade-offs and reasonable people may disagree over which they like. Many, many approaches were tried on the road to ACES 1.0 and, in my opinion, one of the top priorities was to try and be as faithful to the original scene as possible given the constraints. For example, a number of characteristics that are found in motion picture film that many find pleasing, but which could be considered biases to the scene, are not found in ACES.
The Output Transforms represent a difficult technical challenge and no doubt improvements will be made over time as more is learned. However, as Scott, Walter, and others have pointed out, the benefits to the industry of having a standard baseline rendering far outweigh any current limitations.
I also agree with the point that the full LMT system described in the ACES specifications is not widely deployed yet and that will need to happen to meet the needs of productions to communicate the custom looks needed for particular projects across their workflows in a standardized way.
– Doug
Some comments… (apologies to those people who might have heard this before)
I’ll start with the context that my experience is VFX heavy project biased.
On the use of the RRT, none of our “ACES” VFX shows listed in Steve’s latest list on this forum used the RRT, at least during VFX post - I can’t be sure if this held all the way through to final DI in every case, but I can be sure for some of them
I think only one project used the RRT as-is and that was an OTT TV delivery.
We have had shows using the LMT to try remove the RRT look/trade offs, but most of them just outright don’t use it. I use the word try due to the residual limits caused by incomplete inversion in the mathematics/ctl code.
I’ve spoken to a number of creatives on the choices and generally they agree that despite the lack of intention mentioned by Doug, there is a look to ACES which they think is ‘too strong’ - there is clearly a preference involved in that statement.
We have legitimate technical reasons we use an alternative ‘RRT’ for our internal uses, for legacy matching requirements injecting this into the LMT stage is not currently a solution for the same inversion reasons. I’d prefer that we could use the system without modification, but currently that is not possible.
My conclusion for a solution would be that there needs to be movement in several directions:
- improved support of the current system (better support of LMT/ACES clip, less use of LUTs, etc) by manufacturers
- More parameterisation/remove the limits in the RRT perhaps by moving them into the LMT by default.
Kevin
Hi Kevin…thanks for your perspective.
To help people understand our thinking on the ACES Productions List…during this initial adoption phase we’re identifying productions that have used ACES in a significant and meaningful way. Because we’re using IMDb as our source, in many cases, the information is provided by those who actually used it on the production.
We’re working on an official program (partly based on requests from producers and the studios) to create a definition and acknowledgement of “what constitutes an ACES production.” As we envision it, that may also allow a production to be approved to use the ACES logo in the credits of the production. We’ll update the community as that progresses.
One of the technical staff will likely continue this conversation from a technical perspective as well.
Steve T
Hi Kevin,
The RRT is not strongly limited by itself, the real limits are imposed through the choice of an ODT.
Again both the LMT+RRT+ODT should not compromise the ACES EXR ‘negative’ which should retain
it’s range if possible. (gamma or power being operations that are problematic). I agree about ACESclip
and getting better support for LMTs with vendors. The LMT is a systematic bias for a range of clips, and yes
it is eventually supposed to be baked in with a grade, so that you can look at the image with just the
generic RRT and an ODT for your device.
The problem of reds being too intense as mentioned earlier in the thread is really a problem of the wide color gamut primaries (Rec2020 R) because the Red channel effectively goes twice as far in chroma as the other two. The RRT tries to reduce the red somewhat, but maybe the correction for this didn’t go far enough.
(in the shadows, a low-slope desaturates red so we have the opposite issue in the darks) Like everything else there is a trade-off here.
Always looking for feedback so thank you for your comments. If there is a set of images that show a desired look vs. the ACES default I would love to see them, and try to understand more of where this comment is coming from.
1 Like
Thanks @jim_houston. Sorry for the late reply I was busy grading projects in ACES! ;o)
The problem we had with Reds we’re in P3. But itMs nothing we can’t really handle when garding. it would be great to have some better tools to creat LMTs for these kinds of purpose.
I have tools like 3Dlut creator that could give me the tools I need to “tone down” the reds. But I feel weird using LUTs in ACEScct. Seems counter productive!
Thanks!