Colour artefacts or breakup using ACES

Tags: #<Tag:0x00007f90e4369800> #<Tag:0x00007f90e4369738> #<Tag:0x00007f90e43695a8> #<Tag:0x00007f90e4369490>
#81

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?

#82

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!

#83

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. 17%20AM

If I dessaturate completely, I see there’s negative luma data on those artifacts as they become black.
15%20AM

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.
50%20AM 09%20AM

Using Davinci Resolve 15.3 - my ODT is Rec709

#84

Is it present with the RED LUTs? Might just be a limit of the camera…?

#85

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)

#86

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

#87

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…

#88

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:
02%20PM

If I set the limiter it to Rec709 it solves the issue, but I’m… limiting ACEScct to Rec709, which feels crazy.
13%20PM

(I’m showing it dessaturated because it’s easier to see the issue, I think)

#89

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.

#90

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

#91

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)

#92

Indeed, maybe! Looks ugly as hell though :joy:

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

#93

I think you’re client we’ll be happy that you can fix de problem correctly! :grinning:

It’s not really changing anyhting. ACES data will be the same in the end.

1 Like
#94

I just used a similar fix. ACEScct with Sony footage. IDT set to proper camera. ODT to REC709. I had this hilite issue (have been frustrated with this for a while) with 1 shot. Just added a CST on the first node and converted from Timeline to Arri Log C and the issue completely went away!

2 Likes