Hello there ACES Centralites
We have a had a few instances with material (shot RAW Alexa and Sony) have showed severe colour breakup when working in ACES - these are what I would call “electric” blues, red’s and cyans.
I seem to remember being told that this issue was known and that work is being done to solve it…
I would love some feedback
Regards
Patrick
Can you show some images?
I have no idea what a “electric” blue looks like 
Peter
Peter
I am very slightly upset that my metaphor struck no chords…with you. 
However, when you see the picture you will understand.
Here is a snippet (as it is client images)
The top image is the Arri RAW - Linear ACES decode in ACEScc using the 709OT
The bottom image is just a LOGC lut applied in rec709 (not ACES)
Oh, that’s weird. Never seen anything like that.
Can you provide one frame of the original in Arri RAW?
Or just a snippet like that picture as DPX in LogC? Then I’ll have a look with my workflow here.
Peter
Can I send it to you offline Peter?
Happy to share the outcome with the list
ACES sent me a DCTL to fix that. Are you in Resolve?
I cannot find how I can send you a private message here? I could send you my email adress that way.
Or can you provide me with one?
Peter
From your screengrabs, this looks very familiar as an issue that others have occasionally encountered in the past on other productions. The issue usually appears when LEDs or brightly colored lights are shot directly into the camera. Depending on the lens and capture scenario, the camera can “see” these colors in a way that produces problematic colorimetry for some of the later ACES color transforms. When I get time, I will try to make a post explaining the “why” of this perceived artifact.
More robust and longer-term “fixes” for this scenario are being considered. In the meantime, the solution that I have provided to many others which has seemed to help is a simple 3x3 matrix applied to the ACES data. In the “ACES block diagram” one could think of this matrix serving as a very simple “Look Transform” to be applied for these particular problem shots. This simple matrix transform can be inserted when this issue is encountered and that should allow you to continue working with ACES on these shots.
This is the matrix in standard “textbook notation”:
[ 0.9404372683 -0.0183068787 0.0778696104;
0.0083786969 0.8286599939 0.1629613092;
0.0005471261 -0.0008833746 1.0003362486]
I can’t upload attachments with CTL or DCTL extensions, so here is a Dropbox link to the matrix as a CTL: https://www.dropbox.com/s/iq9julp28rer7eg/LMT.Academy.FixHighlightImageArtifacts.ctl?dl=0
or as a DCTL: https://www.dropbox.com/s/itmg7pvrwr67nz9/LMT.Academy.FixHighlights.dctl?dl=0
Charles
We are in Nucoda
Question, after applying the DCTL from Scott - were you able to push the file into
breaking up or did it solve the issue for you?
Regards
Patrick
Hey Scott,
Would you be able to provide the 5 second synopsis of whats hiding in that 3x3 for those of us that are interested?
I like to think of the 3x3 as changing the “effective rendering primaries”. It’s sort of redefining the blue primary so that these values don’t get interpreted as fully saturated blues in AP1.
In this particular example, the blue sirens are bright but not fully saturated relative to AWG RGB encoding space. The ARRI LUT applies a tonescale in the AWG RGB space, and because the values are not fully saturated, they render “gracefully” through the tonescale. Relative to AP1, these blue sirens are much more saturated. It’s this difference in saturation relative to the RGB space in which the tonescale is applied that is preserved through the ACES rendering. Remember, the rendering has no knowledge of the input encoding - it just works on whatever RGB is fed into it.
So, by changing the “effective rendering primaries” the colorimetry is tweaked such that when the AP0-to-AP1 matrix is applied as a the first step of the RRT, these blues are instead treated more similarly by the ACES tonescale as they are in AWG->ARRI LUT. It’s certainly a story better told with accompanying graphs and I’ll work on a separate post for a more thorough explanation for those interested.
I have evaluated this matrix applied as an LMT across a large variety of test images - including ones that display the artifact and those that are more “normal”. In my opinion, it certainly seems to help in instances where artifacts can appear while at the same time preserving a fairly pleasing rendering across other more “normal” image situations. It is obviously going to appear slightly different than the default ACES Output Transform appearance, but like any LMT, it provides a starting point for a colorist to then take the images creatively wherever needed.
Note that while probably harmless if applied to all shots, I currently only recommend it be utilized on a shot-by-shot basis when needed to address problematic content.
Anyway, I’d be interested to hear if you try it. So if anyone uses it and it helps, please let me know. And certainly if anyone encounters another situation where it doesn’t seem to work, I’d be interested in examining the colorimetry from such a frame.
Hi Scott,
works great here. I immediately downloaded the dctl and tried it in Resolve. Great result.
Looking forward to that full explanation post you mentioned.
Peter
Scott, should that DCTL not include a transform to and from linear either side of the matrix?
I tested it on a problem R3D file, and it did not solve the issue unless I linearised the image data before applying the matrix, then transformed back to ACEScc afterwards.
Hi Nick,
It depends. In my usage of Resolve, it appears that DCTL can be applied in one of two places:
I should have mentioned that my DCTL is intended to be applied to the linear data and so is only appropriate for #2. My testing shows that DaVinci CTL applied via contextual menu on a per-clip basis is applied after the application of any Input Transform and before conversion to ACEScc or ACEScct. Therefore, my transform consisting of only the matrix is appropriate for application via the contextual menu - at that point in Resolve’s processing, the data is linear ACES.
However, as you know, in situation #1, one could instead apply this transform via a node in the Color page. And as you correctly point out, in this case it will not work correctly “as-is” because nodes are applied in the working space, either ACEScc or ACEScct.
So yes, since this matrix is intended to be applied to linear ACES, one would need a version of this DCTL which appends an ACEScc-to-ACES step prior to the matrix and then an ACES-to-ACEScc step on the way out. I can provide this is someone needs it, but believe this a bit more cumbersome than applying directly to the shot itself prior to grading nodes, which seems cleaner and simpler.
Or alternatively, achieve the equivalent by chaining three separate DCTL nodes in sequence: ACEScc-to-ACES, matrix, ACES-to-ACEScc
Good point, that would in gerneral be a handy thing to have. A whole set of those single transforms and matrices would make life easier in Resolve. One could combine them as needed. Like an ACES construction kit for Resolve
Peter
i used it, Alexa Mini’s / 4k XQ LogC / ACEScct /cop car lights on wet faces & StarWars light saber lit up with red,led’s - i had already graded this scene last week, but tried again with the CTL on the source, brought 3 nodes down to one with a similar look at the end of the pipe, and great time saveing - works well, and many thanks
I have actually created a set of DCTL transforms which go from every ACES variant to every other (including the non standard DaVinci ACES). I am about to update that to include ACEScct. I sell it for $50 if anybody wants to contact me off list – nick [at] antlerpost [dot] com.
Sorry for the late reply. I didn’t get a notification via email… It fixed it completely.
Hi Patrick! Nice to see you here. I´ve been meaning to email you about this issue since I´ve been encountering this quite a lot in Nucoda 2016.1 while working in ACES. The only thing I found helped a bit was when I had Alexa RAW source and changed the debayering from Linear ACES to Linear Camera Native, this reduced the problem but did not fix it completely. A major thing worth mentioning is that if I try to desaturate the clipped colors either with hue curves, a key, or just the general saturation tool, the colored pixels instantly turns black.
I really wish we get a fix for this soon, in the meantime, I will try the .ctl provided by @Scott Dyer (thanks!), IF i can get them to work in Nucoda
//O
