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.
Aces 1.3 with ‘reference gamut compress’ option helped a lot to reduce the artifacts but was not enough to definitely solve the issue. It seems this option operates in a different way from ‘Gamut compress’ DCTL. Infact the DCTL was not able to produce the same clean result.
The Magic Motion slider does not produce any effect yet.
This was always set to log in my testings. Now with ACES 1.3 if I apply the reference gamut compression in project settings the issue seems to disappear with image scaling set to Smoother. A few other scaling algorithms still give issues however but much less severe than without the compression.
It could be that gamut compression project wide happens before any image scaling which would explain the differences between that and the DCTL version perhaps.
So we know it’s some negative values issue that happens with scaling whilst combining X/A with Magic Motion. I don’t know how Magic Motion works but it has to be it’s math in conjunction with conversion in and out of ACES. It’s interesting that DaVinci Managed with something like DaVinci Wide Gamut/Intermediate doesn’t suffer from this and even the slider just works as expected then.
If you want me to test anything I’m happy to help but trying to understand/solve it is a bit outside of my knowledge at this point
I shot LayerX 4 stop under.
So we can create master in ACES OpenExr sequences that are able to keep all those informations in the sky (or other highlights) for further mastering when display technology could be able to show them.
Ah cool so it does blend just the bias doesn’t work. That part was hard to judge on the earlier files as everything was static now I can clearly see the second layer.
