@Thomas_Mansencal: what I meant there is that the camera is 4K native and for “slo mo” it resizes to HD. Which introduces some heavy aliasing. I did no resizing after that.
On a side note: @nick, do you know which resizing algorithm Resolves uses for Sharper and smoother? We don’t have as many options as VFX artist have in Nuke (per se).
Thanks!
What @nick and I were discussing about too this morning is the fact that when the data is converted to Y’CbCr and sub-sampled it introduces a lot of cross-channel correlation and might make the situation even worse by introducing ringing artefacts around areas of hight contrast which seem to be the case here.
No I don’t know, I’m afraid. The Resolve manual suggests they are proprietary.
This is what I get when I plot the gamut of that image.
As you can see, a lot of the values are way outside even the AP0 gamut.
Many of the extreme values are in the shadows, which I suspect is related to quantisation (the FS7 is only 12-bit linear). The other out of gamut pixels are probably due to short cuts taken when recording high frame rate, down-sampling by pixel binning, recording in a Y’CbCr codec, and so forth.
It would still appear that Resolve 15 is not handling these out of AP0 gamut values correctly and introducing new artefacts not present in other ACES implementations.
Chiming in here to say THANK YOU THANK YOU THANK YOU. Just graded an entire feature (1500 shots, ugh), in ACEScct in Resolve 15. There are many instances of purple / magenta fringe pixelation, usually when the camera is getting flared out. The producer was freaking out and I was in the hot seat. Suddenly the grade became all about fixing these purple fringes, never mind that I made the movie look good or achieved pretty perfect shot matching. I was gearing up to give 1-2 full days of my life, for free, to qualify and desaturate each individual instance of this. I can’t believe you made a .dctl that magically fixes this. I applied and voila! Gone! Producer is happy. And I have 2 extra days of my life. Thank you so much.
Glad you we’re able to get that done easily.
@sdyer: wasn’t this LMT supposed to be directly implemented in ACES 1.0.3? Aka we wouldn’t have to apply it systematically.
Thanks!
Hi Christophe,
Sorry just saw this. I’m testing out the ACES1.1 OCIO config currently and it seems to fix the issue. Can you give a link here to your new topic?
Hey Derek, thanks for your reply. I think I didn’t create a topic for this in the end since there was an improvement with the ACES 1.1 config. Thanks for the reminder!
Hi, everyone!
I’ve been following this post for a few months and worked with ACES in many projects with diferent cameras (RED Gemini, F55, F65, Arri Alexa, Arri Alexa Mini, FS7, A7SII…). The FixHighlights dctl aways managed to get rid of highlight purple and blue artifacts.
However, I’m working with Red Helium footage for the first time in ACES and I’m getting lots of artifacts that the DCTL doesn’t help with, specially in the red channel. 
If I dessaturate completely, I see there’s negative luma data on those artifacts as they become black.
If I change the RAW debayer and change the color temp. towards 1700K, drastically, it goes away… But I’m wondering if there’s other fix to this, since messing up the balance of the shot is something I’d like to avoid.
Using Davinci Resolve 15.3 - my ODT is Rec709
Is it present with the RED LUTs? Might just be a limit of the camera…?
Don’t think so
I’ve imported the same file in a YRGB project, IPP2 RedWideGamutRGB + Log3G10, and even though something similar does happen when I apply a Rec709 LUT or the ColorSpaceTransform, it’s not present at the origin… I can easily manage it without using LUTs, working “behind” them or automatic transforms as well.
So far the “fix” has been setting WB to 1700 and then bringing back the correct WB with grading tools, but that feels wrong. And I’m prettty sure client will ask why the Non-Graded Archival Master is so off-balance in a few shots…
I’ve worked on a film shot on F55 that was HEAVY on neons, red, blue and green lights, all king of colorful and bright footage, without any artifacts whatsoever (apart from the ones easily fixed with the DCTL)
Are you using ACES in the project “Color Management” panel? Or, AcesTransform?
If you manage you project in AcesTransform you can try the following: use a ColorspaceTransform to go from IPP2 to Arri Wide Gamut and use the ARRI IDT. That “might” help.
Note that the best way I foung to apply the aces_fixHighlight.dctl file is to sandwhich it between the IDT and ACES Ap-0. You can then go from Ap-0 to ACEScct for grading.
Cheers
I’m using the Color Management Panel in this project. In this case, I usually apply the FixHighlight DCTL as an Input DCTL in the file! Since the debayer is straight to AP0/Linear, I think it makes sense, right?
I’ve tested your tip, and it works very well!
I think the client will prefer I don’t do the ACES Color Management with the OFX, since they’ll receive the project and they were kind of specific about this workflow
I’ll check with them if it’s an option…
Made a few new tests, all using ACES in the Color Management panel:
If I use the Gamut Limiter OFX and set it from AP1/cct to a less broad gamut, it seems to work very well to solve this issue.
Arri Wide Gamut fixes it in the situation I set the example to, but in another situation with a car light it’s still a little bit problematic:
If I set the limiter it to Rec709 it solves the issue, but I’m… limiting ACEScct to Rec709, which feels crazy.
(I’m showing it dessaturated because it’s easier to see the issue, I think)
Are you always grading in AP0? Or, are you grading in ACEScct? That might just be the problem…
Personaly, I feel the that the ACEStransform workflow is easier as ou can manage only the camera footage thru ACES. You can group your cameras together and use the Pre group and post group for IDTs and ODTs,
This workflow doesn’t force everything thru ACES before the grade. AKA editing effects and titles will look correct (I’m still on 15 so don,t know if that’s still an issue in 16). Basically makes resolve behave like NUKE. Let’s say you want to pull a nice key. Just add a corrector and go from ACEScct to 709, pull you key and just link the nodes thru alpha. It also enables you ability to work in other color spaces for OFX purposes.
I’m grading in Acescct!
So, in this project I have to deliver an Archival Master fully in ACES ap0 (hence, without the ODT), so everything would need to go through the pipeline
I really like working with the Aces Transform ofx and feel safer with it, but I’ve never encountered anything I had to fix outside of ACES before, specially with a camera like a Red Helium, so I figure I’d follow the client’s guidelines and I’d be fine with it
All digital cinema cameras can have “holes” with very saturated lighting (such has cheap LEDs etc…). So you might of just found one.
If you produce a NGAM and manipulate before going to ACES then the workflow is good and the footage will always replicate correctly. ;o)
Indeed, maybe! Looks ugly as hell though 
You right about the NGAM! I’ll see if the client is bothered by me changing to this workflow. It’s not like I lost my day’s work as soon as I keep in Cct
Thanks
I think you’re client we’ll be happy that you can fix de problem correctly! 
It’s not really changing anyhting. ACES data will be the same in the end.
