Hi everyone, this is a nice R3D HDRx issue I want to share with you. It’s going me crazy.
So please take a look at the artifacts highlighted in red in the frames below.
This happen around specular lights and reflections.
Color grading system → Resolve 17.3
Color science → Aces 1.2
Color space → Acescct
Primaries → AP0
Footage → .R3D 5k with HDRx
Debayer → Full
MacPro 2012, GPU 2x AMD D700
The artifacts appear only when ACES color science is selected in project settings and when HDRx is enabled with ‘Magic Motion’ option.
I’ve never tried HDRx with ACES but do you see the same issue if you use blending instead of Magic Motion?
Do you see the issue when viewing any of the two tracks in solo, or only when blended?
no, it only happens with ‘Magic motion’ option. Furthermore I can’t check the X-layer in solo because for some kind of reason the blend slider does not produce any effect when ‘Magic motion’ is set in ACES.
I did a quick test with sample hdrx footage and it looks like nothing is happening in Magic Motion in ACES it just takes the main track, not sure why.
What I meant earlier “use blending instead” was the Simple blend version that’s just fading between the two. It looks like you are able to do that and set the slider to -1 for viewing the second track.
I don’t see any glitches but the sample footage doesn’t have any specular highlights it’s just shot a bit over exposed.
Is it possible for you to share a single R3D frame of one of the clips that have the issue? I could try to look into it.
By the way, I remember someone else having specular highlight issues with DaVinci Color Management and it seemed to disappear when he changed the image scaling resize filter algorithm to “Smoother” in the project settings.
Worth trying.
yes I understood what you mean. There are no artifacts in ‘Simple’ blending mode.
Yes I had this scaling algorythm issue times ago. When Resolve is ACES enabled, the old ‘Bilinear’ or ‘Bicubic’ settings seem to work better with graphics, texts and alpha-mattes. But this, for some kind of reason, seems also to be strictly connected to the GPU.
I think Magic Motion is bugged or not supported in ACES managed Resolve. If I use DaVinci Colormanaged the bias slider does work properly and no negative values are produced.
In ACES Magic Motion does seem to kick in but without control and when I lower the exposure in the raw tab I see this.
I think those are negative values?
Interestingly enough if I don’t use project level ACES, just no management and use nodes the issue goes away. (ACES Transform RWG/Log3G10 → ACEScct and then ACES Transform ACEScct → display)
I don’t get the image artifacts you were seeing at all however. I’m on a system with a nVidia GTX1080Ti. Maybe the GPU is related in that regard. Would recommend testing on another workstation with different gpus.
If that solves your issue but you do need ACES as global project management you should be able to bypass color management on the clips that have the issue and create the manual sandwich on them?
yes this is exactly what I think.
A small UPDATE in my research:
switch GPU Debayer to CPU Debayer → FAILED;
switch Metal to OpenCL → FAILED.
yes, I already did this test on different workstations with older operating systems and different hardware → FAILED.
Yes I need ACES as global project management and Resolve does not allow the user to change it shot-by-shot. Another way is to conform the shots from EDL in REDCineX → convert the A/X layers separately to OpenEXR 2065 AP0 sequences → import them into Resolve and make the sandwich.
Unfortunately this way is very tricky and time-wasting when grading a long feature project with many shots.
Not sure what you mean. You should be able to right click the clip in the colorpage and select Bypass Colormanagement. Yes the colorspace and gamma is greyed out in the raw tab but it should read IPP2 RedWideGamut Log3G10.
Then create the node setup as I described in previous post. The only downside is that you have to change your ODT on those nodes whenever you change the projectwide one to match. But maybe it helps to create a group for all the HDRx clips and apply your manual setup in PreGroup going to ACEScct and PostGroup from ACEScct to display so you can change them all in one go whenever you need to.
Thanks @shebbe, this is a smart solution with good cost-benefit ratio.
Just to clarify: replacing the color management (bypassing it) with a transform node returns different look. in other words: the grade beetween idt and odt must be trimmed.
Interesting, when I test it with an ACEScg exr frame it’s the same story.
Also did a test with Arri sample footage in ProRes logC. The exact same issue arises.
I might be missing some knowledge here as to how ACES works perhaps or how Resolve works vs manual setups? Changing the grade node’s colorspace or gamma didn’t give any more accurate results.
(diagonal wipe topleft to bottom right)
What I also checked was if it could’ve been the sandwich nodes themselves but they produce an identical image versus global ACES management so it has to be something with how nodes operate within the timeline space. I just find it weird that this can happen when the space the grading node is in doesn’t change.
After your last post I started testing again but your suggestions gave the same issues still.
Then your earlier comment struck me again and tested that instead.
I now understand that by bypassing color management in ACES, your node space is equal to your ODT!
In my case this was sRGB. I verified this by changing project management to DaVinci YRGB and set the timeline space to ACEScct. The grade with the ACES Transform nodes match the grabbed still from the ACES managed one!
In my head bypassing management on a clip would mean solely ignoring IDT and ODT but keep ACEScct as the timeline space. But it actually behaves as if you would place your node tree after the ODT.
What I find most unintuitive here is that timeline space is even a thing. Aren’t all colorgrading tools just math that infuences input and gives an output as a result. I don’t see how they are bound to a colorspace except for the HDR wheels’ zoning.
I’m not the most tech savvy when it comes to this still learning a lot .
Now to combat/fix this bypassing is to set the Project ACES ODT to ACEScct (which isn’t very fun for your built-in scopes readout) and move the ODT over to the timeline nodes tree in an ACES Transform. That way bypassing a clip keeps the node tree the same and you’d only add the IDT pre-grade to go to ACEScct.
Would this work? I think magic motion should work now but I don’t know if it will fix your initial issue about the artifacts. I still haven’t seen them in your clips on my machine. For reference I am running Resolve 17.3.1 Build 5.
Also if you really want to know for sure if it has to do with resizing, you could switch your timeline resolution to match the clip and see if it persists.
UPDATE: the issue seems to be fixed in resolve 17.4 update released today.
below some screenshots. please note the ‘log’ option in resize transformation.
Hey that’s great to hear!
I also downloaded 17.4 today and noticed they also added ACES 1.3 and the Reference and Paramterized Gamut Compression inside the ACES Transform OFX. Very nice.
The resize specular glitch is actually present on my system now… I suddenly noticed it in the 17.3.1 and in the current 17.4 too. Not sure if I missed it before or it suddenly creeped in.
Changing the resize filter changes the ‘look’ of the glitch so they’re definitely tied.
But none of the scaling methods gets rid of the issue.
Magic Motion slider still doesn’t work in 17.4 for me. Turning Magic Motion off gets rid of the glitch.
The method through bypassing and the sandwich still fixes it and produces an image without glitch.
If it’s fixed on your side really happy for you but I think I’ll make a report of this towards Blackmagic too as it’s clearly an issue still.
