Resolve Causing Chromatic Abberations with 10-bit V-Log L

I did some more testing:

I used the tiff test chart Martin provided and created a pixel for pixel HD Prores 4444 version for testing.

I imported this file to Resolve and rendered an unmodified version to Prores HD422HQ.
I then used the two files on a timeline. Layer one = Prores 4444, Layer two = Prores 422HQ.
I used the difference transfer mode to reveal the differences.
I tried this setup in FCPX, Apple Motion, AE, Premiere & DaVinci Resolve.
The differences are very small so not visible to the eye. I created nested & compound clips etc, to apply gain to the nested clip to reveal the differences in each software.

Results: No chroma issues with any software EXCEPT DaVinci Resolve, which clearly showed the chroma problem. It is interesting to note that both source clips were rendered from DaVinci Resolve but only DaVinci Resolve has an issue with them when they are re-imported. All other software I tested were ok.

I also did a test with my own GH4 H264 4:2:0 camera footage and the results were the same.
This is very odd for software that makes claims about the superiority of it's image processing.
IMO this is not a Quicktime, MXF, ffmpeg or other format issue , but a DaVinci Resolve YUV subsampling decoding issue.

Apologies in advance, but I think I may still be confused here.
[...]
From merely a troubleshooting point-of-view, I'm trying to reconcile the statement that the problem only seems to happen with QT-based formats, but that it also happens with DNxHD and DNxHR codecs in a non-QT MXF container (that you transcoded with AME). If the problem is also happening with MXF files that are not being decoded by QT, then I am having trouble understanding how it is a QT problem and not possibly a larger issue.

It is, totally. My first idea was just to see if it's general 422 (it's not, as already said by multiple people) or only T based (it's not, as we see).
However, I have no idea how DNxHD/R is handled inside of Resolve, if it maybe gets treated by its QT decoder or if it's something that is underlying in the Codec that just happens here, too.
It's just funny that neither 420 nor 444 formats are affected at all.

Until then, this is why I use TIFF in - TIFF out for my Resolve workflows.

You can still use Prores 4444 without any issues (which I'd do anyway), for image sequences I'd suggest you DPX or EXR; DPX is smaller in filesize (16bit TIFFs get HUGE), and EXR can be conveniantly compressed and work great, even at 16bit

the only 4:2:2 variant that works as expected, seems to be h.264/AVC intra.

Have you tried my sample-files? Except for QT and DNxHD/R all work for me; for you, too?

i just saw an actual video from dave dugdale about 8bit vs. 10bit footage. while i wouldn't take it very serious as an analysis of this particular question, there is a passage in this video (19:29-22:30), which looks really interesting to me from a different point of view.

they are fighting green-mangenta color artifacts!

it's exactly the same problem, i realized myself, when i evaluated a lot of v-log footage a few month ago -- and i also used resolve and prores proxies for my tests. now, since i know this other 4:2:2 import issues, it looks very significant to me, that this artifacts are only visible in the 4:2:2 intermediates, not in 4:2:0 8bit footage straight from the camera! it immediately reminded me of the topic here in this thread. sure, in this particular case we were just looking for color artifacts in small contours and line patterns, while in those other cases the artifacts fill homogeneous areas, but nevertheless it looks just the same! i think, it could be related to a bug in resolves 4:2:2 color handling, that is much more fundamental.

would be really nice, if some BMD engineer could analyze this issues more thorough.

DaVinci Resolve 12.3 is out! i don't test it yet but from description "Addressed an issue with jagged edges when decoding YUV 422 clips" seems they fix a bug with 422 chroma.

DaVinci Resolve 12.3 is out! i don't test it yet but from description "Addressed an issue with jagged edges when decoding YUV 422 clips" seems they fix a bug with 422 chroma.

Very nice catch, Dmitry. I downloaded 12.5.3 last night and gave it a quick test run with a new project that I am working on. So far so good. I will repeat the test of the images on this thread to see if the chromatic aberrations go away.

Tested the OP's supplied clip with Resolve 12.5.3 and can confirm that this issue seems to be solved. Thanks BMD, this was important! Next test is Panasonic V-log from GH4 to see if there is any improvement. Just tested GH4 internal 8bit 4:2:0 V-Log. There is still some banding visible when pushing the grade in Resolve, but if I use curves rather that a LUT, a lot of the magenta/green artefacts are greatly reduced or gone completely. Nice!

I tested the grayscale ramp that Martin Schitter uploaded. While before, the ProRes version showed the chroma artifacts on my setup, identical to what Martin and others posted (the TIFF was fine), the chroma artifacts are now completely gone as of 12.5.3. Clearly, BMD has fixed something in how they upsample YUV 422 to RGB. "Addressed an issue with jagged edges when decoding YUV 422 clips." So, they got the jaggies out? That doesn't sound like a decoding issue to me but rather a resampling strategy e.g. like choosing between lanczos vs nearest neighbor. Nonetheless, this is good news as it means BMD is listening to our feedback. Well done, BMD!

Nonetheless, this is good news as it means BMD is listening to our feedback. Well done, BMD!

Keep in mind that I sent a support request for this issue, it was not just this forum topic that generated BMD interest. I think it is VERY important to raise support issues directly with BMD & not expect every forum topic to be read by BMD staff.