Serious Chroma Subsampling Bug

A (presumed) chroma subsampling bug has come to light that affects all of the export and transcode YUV 422 formats (8-bit and 10-bit). It manifests as spurious chroma shifts and spikes that are clearly visible on the scope Histograms and which worsen with each import/export cycle.

viewtopic.php?f=21&t=78837&start=50#p437471

The results of earlier metric tests with Uncompressed 10-bit YUV 422 samples had given a strong indication of progressive deterioration in chroma quality. The visual evidence on the scopes and images is undeniable.

It is not entirely clear if this is occurring on import, export or both, but this is a serious problem.

Further investigation reveals that the bug was first introduced in Resolve 15 beta 1. It was not present in Resolve 14.

I am raising the issue separately here in case it escaped the attention of BMD in the above linked thread, given that it was not the original and central topic of discussion.

I bet you it will be fixed in next update.

Hope so. Not wishing to be alarmist, but it does no harm to raise the awareness. Our dialogue on this issue had anyway become somewhat 'interleaved' with the main topic of discussion, so there was perhaps need to split off into a separate thread.

Just to stress also that the bug does not affect YUV 444.

A (presumed) chroma subsampling bug......

very good expression.

Yes, thought I'd better add that in case it turns out there's another explanation. Maybe 'broken YUV 422 chroma bug' would be more apt.

Incidentally, these aberrations do appear in like manner on RGB Histograms when the affected export files are loaded in other programs. So it's not something peculiar to the Resolve scopes.

Also be sure to email the support team directly from the BMD support page. They do read these forums, but these forums are primarily for user-to-user help. Emailing them directly is the official way to notify them about a bug.


Sent from my iPhone using Tapatalk

Thanks Seth. Didn't realize that. During 15 beta development there was a separate sub-section devoted for bugs. I just assumed that posting on the main forum was appropriate now we are into official 15 releases.

Edit: I've notified BMD by email also.

Not fixed in 15.1 (at least on Mac).
Not good at all!

Not fixed in 15.1 (at least on Mac).
Not good at all!

Sadly, 15.1 on Windows also. No, not good at all.

Edit: I've notified BMD by email also.

But the good news is I'm now on the BMD mail-out list. As if I need more promotional literature.

So how small and big studios making 4:2:2 masters from R15?
Are they simply ignoring this serious bug and producing crap masters anyway (or they go 444 and do 422 outside Resolve)?
Probably 50% of studios have no clue there is a bug there.

Probably not. I think alarm bells would have been sounding off on the forum at an earlier stage in 15 beta development and BMD would have been on to it before the official release. There again it's not exactly something you'd want to draw clients attention to.

I'm seriously considering rolling back to 14.3 until this is fixed. I can live without v15 enhancements for the sake of clean YUV 422 export. But I'm a 'one man show' and for most that is likely not a practical proposition.

Folks transcoding to 422 formats for import, I would definitely suggest looking at alternative transcode methods. Implications for optimised media also ?

Implications for optimised media also ?

Referring back to the test I did (in the other thread) with the EBU Color Bars:

Repeated the above Uncomp. 10-bit 422 AVI 'generation' tests using the EBU Colour Bars as source.

1. EBU Color Bar Generator > Timeline > Compound Clip
2. Exported to Uncomp. 10-bit YUV 422 AVI (Full Data Levels)
3. Re-imported the export (Full Data levels) and encoded to Uncomp. 10-bit YUV 422. AVI again.
4. Repeated the cycle up to 10 re-encodes.

Brought the clips onto timeline (Full Data Levels) and took screen grabs of the Histograms.
Couldn't be bothered running SSIM/PSNR metric tests. The images and Histogram profiles were evidence enough.



Edit: Ooops, I see I cropped-off the blue channel on that last (10th) generation re-encode histogram. I redo it when I have a moment.

That was testing in 15.01. Repeating the test in 15.1 gives exactly the same results, so no change there. The bug persists. But here's what interesting:

(1) Taking, say, the first re-encode of the first Uncomp.10-bit YUV export. Imported back onto the Resolve timeline the RGB Histogram profile is exactly the same as the third one down on the compiled image I posted there (labelled 'First Generation Re-encode') - the chroma degradation is visible. If I then select Uncomp.10-bit YUV 422 (v210 for brevity) as the Optimized Media (and Render Cache format) and Generate Optimized Media, the Histogram profile (with 'Use Optimized Media if Available' active) does not change. Yet if I take that same export file, re-encode it to v210 using Resolve's transcode function and import it back it onto the timeline the RGB Histogram reveals that the degradation has worsened.

Why the difference ? Suggests to me that the degradation is occurring on import. Otherwise why would the process of generating v210 as the Optimized Medium itself not bring about further degradation and be reflected the RGB Histogram ?

(2) Furthermore, taking that first case, where I generated Optimized Media (v210) - if I export out again to v210 and import back onto the timeline, the RGB Histogram looks exactly the same as that of the imported transcode - the degradation has worsened. No surprise there. What's interesting though is that selecting 'Use Optimized Media' on export makes absolutely no difference to the outcome. Surely, if the degradation was occurring on export one might suppose that evoking the 'Use Optimized Media' option could prevent it i.e. the optimized media characteristics get transferred without loss to the export file, both being Uncompressed 10-bit 422 in this case. Or is that not how it works?

That's the only way I can explain the observed behaviour anyway. I think the problem is on import.

Why the difference ? Suggests to me that the degradation is occurring on import...

why are you refusing to utilize other tools for your tests?
IMHO it's much easier and target oriented to utilize at least measuring tools, which work reliable, to check and isolate issues in buggy software.

why are you refusing to utilize other tools for your tests?
IMHO it's much easier and target oriented to utilize at least measuring tools, which work reliable, to check and isolate issues in buggy software.

Refusing ?? Just trying to figure out whats going the only way I know. More importantly, I wanted to explore if there are any possible workarounds. The behaviour with optimized media is not something I'd looked at before. If you are familiar with analytic tools that can more precisely pinpoint the bug, by all means go ahead. Probably I should just leave off the subject altogether and wait for a fix. Dwaine Maggart came back on my email this evening to confirm that the BMD Development Team have been alerted to the problem.

Refusing ??

please don't get me wrong!
i really like your efforts and do not want to demotivate you.
i just have my doubts, if it is really useful to analyze the issue by only watching the behavior of a black box, without utilizing outer reference and comparisons -- e.g. subsampling loss in similar applications.

Rest assured, my motivational drive has in no way waned. I just don't think I can bring anything more to the table of real insight and practical relevance - at least that doesn't pose more questions than it answers. Based on the symptoms I described in the first post and finding that this worrisome behaviour was first introduced in Resolve 15 beta 1, I think folks can draw their own conclusions about the seriousness of this bug and the ramifications.

To be honest, the prime reason for my perpetuating dialogue on the subject has been to keep the thread up-stream and visible. Now that BMD have back come to confirm that the issue has been referred to the development team, I think can relieve myself of that dizzying duty.

I did the other evening try to set-up a simulated v210 > r210 > v210 conversion cycle with FFMPEG but just could not get it right - looked there was some chroma plane inversion going on.

Cheers.

Rest assured, my motivational drive has in no way waned. I just don't think I can bring anything more to the table of real insight and practical relevance - at least that doesn't pose more questions than it answers.

it's indeed a very interesting case and not the fist time, that resolve shows significant flaws in its color subsampling implementation.

it's just hard to catch from within resolve, because even on zooming in till the maxima, you will not see the artifacts within the application. but in other tools - e.g. in natron or nuke -- the symptoms become immediately obvious.

To be honest, the prime reason for my perpetuating dialogue on the subject has been to keep the thread up-stream and visible. Now that BMD have back come to confirm that the issue has been referred to the development team, I think can relieve myself of that dizzying duty.

yes -- i also asked many times for a more transparent public accessible issue tracker to handle critical bug reports and open issues in a more constructive manner. but this kind of very useful feedback and software quality control mechanisms, which we all learned to esteem from open source projects, seem to be not compatible with commercial software development culture and secret sauce cooking. here we can only guess, that we really stumbled over a critical issue, if we don't get an answer, because otherwise someone would at least reply, that it's just caused by a stupid user error...

I did the other evening try to set-up a simulated v210 > r210 > v210 conversion cycle with FFMPEG but just could not get it right - looked there was some chroma plane inversion going on.

handling v210 in ffmpeg is always a little bit tricky and error prone, because the AVI container doesn't include enough metainformation to signify the content as rec.709 footage. you therefore have to add at least an explicit "-vf scale=in_color_matrix=bt709:out_color_matrix=bt709" or similar to utilize the right coefficients for the RGB conversion instead of the rec.601 ones.

Just one point about this bug.
These kind of bugs are completely avoidable being released by having appropriate automated testing modules.

This is core functionality, not some newly introduced feature. It should have long been part of an automated QA testing suite and be done for each daily build. Failure of such tests should block any release.

This is the point.
I don't use Resolve for any clients' related work (because it's very different nature). I was about to use it for some job, but these sort of bugs worry me a lot. I know I can't use it without validation (I always check any conversion with few tools and cross reference- simply don't trust anyone) every time I want to use it (specially when version changes).

I'm afraid I made an error in reporting that the 'bug' was not present in Resolve 14.3. I've just rolled back again to 14.3 and on re-testing I find (to my horror in one respect and relief in another) that it was present after-all.

When I went through previous versions to test for the bug I used the method described above, with the EBU Color Bars. For expediency though I did not run the full 10 re-encode cycles but limited it to one - that is to say the first re-encode of the initial v210 export. The reason being that, in the above tests, the first v210 export showed no visible aberrations on the RGB Histogram when imported back onto the timeline. It was only after re-encoding the first export that the aberrations became clearly visible. So I took that as the test indicator. I think what happened when testing 14.3 is that I somehow mixed-up files on the timeline. As a result, when examining the RGB Histograms, what I thought was the first v210 re-encode clip was actually a duplication of the initial v210 export. Regardless, I made a mistake.

Whats more - rolling back even further to version 12.5.5, I find that it was present then also, and in fact 'worse' - even the first v210 export showed aberrations on the Histogram.

Clearly, this puts a different perspective on the matter. All I can say is that I am extremely sorry to have made and reported such an error.

That said, what prompted these retrospective studies in the first place was concern about the degree of quality loss (as assessed by quality metrics) that occurs when Uncompressed 10-bit YUV 422 sources are serially passed-through Resolve. Which leaves the question - is it reasonable to expect that that should be a lossless process, and if not, what degree of generational quality loss should be deemed acceptable in a 32-bit float RGB system? In other words, is there still legitimate cause for concern ?

No doubt discussion will continue on that very subject, as indeed it has in that other thread:

https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=78837&start=100#p438966

Again, my sincere apologies for reporting inaccurate and misleading information. Excuse me while I crawl under my desk

I did the other evening try to set-up a simulated v210 > r210 > v210 conversion cycle with FFMPEG but just could not get it right - looked there was some chroma plane inversion going on.

handling v210 in ffmpeg is always a little bit tricky and error prone, because the AVI container doesn't include enough metainformation to signify the content as rec.709 footage. you therefore have to add at least an explicit "-vf scale=in_color_matrix=bt709:out_color_matrix=bt709" or similar to utilize the right coefficients for the RGB conversion instead of the rec.601 ones.

Thanks Martin, yes, explicit -vf scale=in_color_matrix=bt709:out_color_matrix=bt709 was the missing piece.

That sorted, I ran a series of four r210>v210>r210 conversions cycles with FFMPEG using the EBU Color Bars exported to r210 (Uncomp.10-bit RGB) as source. Metric analysis on the r210 encodes revealed negligible quality loss (SSIM 0.9999) over the 4 cycles.

Testing the v210 encodes (using the first FFMPEG v210 encode as reference) there was zero quality loss over 4 cycles as judged by SSIM (1.0000). PSNR analysis scored 69.2284 for the Luma, but there was no loss in UV chroma at all (Inf). Also when the files were brought into Resolve, no aberrations were visible on the RGB Histograms.

Compare that with the metric scores obtained after 4 pass-through cycles of Uncompressed 10-bit YUV 422 in Resolve, using the first v210 export as reference. Luma showed no loss, but the scores confirmed significant chroma degradation over the four cycles -

SSIM: Y=1.00 U=0.9694, V= 0.9848, All=0.9985
PSNR: Y=Inf. U=31.1067, V=33.2831, Average=35.0702


Those PSNR scores for the UV chroma are extremely low - as has been noted before. And of course when the files were brought back into Resolve the chroma degradation was visible as aberrations on the RGB Histograms.

Granted, in one sense, this is comparing apples & oranges; in the FFMPEG series Uncomp.10-bit YUV 422 (v210) was being cycled through Uncompressed 10-bit (integer) RGB, in Resolve it passing through 32-bit float RGB. But does this not raise concern - is it normal and expected that YUV 422 formats should suffer that much degradation passing through a 32-bit float RGB system ? That is the point, irrespective of how long this has been the behaviour in Resolve ?

The above results are accurate and double checked BTW - I didn't screw up this time.

Martin, is it possible to do the v210 re-coding via 32-bit float RGB with FFMPEG ? If so, how ? Logically, that would be a more relevant comparison.

Thanks Martin, yes, explicit -vf scale=in_color_matrix=bt709:out_color_matrix=bt709 was the missing piece.

i stumbled over this issue myself a few days ago, when i was writing a few little jupyter notebooks, which wanted to send you as inspiration, how this kind of research can by handled by alternative means. but at the end i always had to realize, that they will not help you in practice, so i threw them away again. either you are already familiar with programming and this kind of schematic demonstrations, than it's absolute superfluous trivial stuff, or you are not used to this kind of approaches, than it's again an useless overload of information...

nevertheless i'll send to this time one of these set aside notebooks and an easier viewable html-version for the original output of resolves color generator and the first generation of rereading the file.

based on this evaluations, i would also guess, that the issue seems to be related to 4:2:2 input processing.

btw. you always have to take care, that the output resolution in resolve doesn't differ from the timeline resolution, otherwise you'll see similar nasty artifacts even in 4:4:4 resp. uncompressed RGB image sequence workflows!

That sorted, I ran a series of four r210>v210>r210 conversions cycles with FFMPEG using the EBU Color Bars exported to r210 (Uncomp.10-bit RGB) as source. Metric analysis on the r210 encodes revealed negligible quality loss (SSIM 0.9999) over the 4 cycles.

that's an expected result, because this kind of generative loss evaluations are very often utilized in exactly this manner to testify video compression solutions etc. and the results usually look much more acceptable than your resolve findings.

Those PSNR scores for the UV chroma are extremely low - as has been noted before. And of course when the files were brought back into Resolve the chroma degradation was visible as aberrations on the RGB Histograms.

yes -- the numbers may look very well and the generative loss doesn't increase over additional iterative recompression, but this doesn't strictly imply, that resolves behavior couldn't make sense in respect to other demands. this image filtering and refinement techniques are a really complicated topic, and the simple solutions, which are used in ffmpeg, may not always lead to the most convincing practical results as well, although they look very plausible and technically satisfaying at first sight.

for example: a very simple 'nearest neighbor' scaling algorithm will also have some interesting characteristics and benefits in comparison to more complicated scaling filter solutions. e.g. you will never find any new values in the histogram and will look more correct in this respect. it also may give even better better looking results on some patterns and scaling factor then the other alternatives. nevertheless you would hardly ever use this scaling approach in any serious graphic workflow, for all the well known reasons. and very similar arguments could expressed about the pros and cons of different color subsampling methods.

Martin, is it possible to do the v210 re-coding via 32-bit float RGB with FFMPEG ? If so, how ? Logically, that would be a more relevant comparison.

i definitely would suggest natron as an intermediate step to realize this kind of experiments. it uses the ffmpeg libraries to import the uncompressed YCbCr values but does all further computing in 32bit float RGB till it exports the video again by help of ffmpeg in the same reliable manner. there you will also find accurate implemented RGB->rec.709 and rec.709->RGB nodes, if you want to study the YUV values resp. channel representations. ffmpeg itself IMHO isn't very suitable for this more advanced demands.

Martin, is it possible to do the v210 re-coding via 32-bit float RGB with FFMPEG ? If so, how ? Logically, that would be a more relevant comparison.

i definitely would suggest Natron as an intermediate step to realize this kind of experiments. it uses the ffmpeg libraries to import the uncompressed YCbCr values but does all further computing in 32bit float RGB till it exports the video again by help of ffmpeg in the same reliable manner. there you will also find accurate implemented RGB->rec.709 and rec.709->RGB nodes, if you want to study the YUV values resp. channel representations. ffmpeg itself IMHO isn't very suitable for this more advanced demands.

OK, thanks Martin. I hear what you are saying, but I'm not sure I want to invest time getting my head around yet another program that I am unlikely to use in practice. FFMPEG I do, but mostly for straight one-directional transcoding.

Like I said, if others well acquainted with such systems are inclined to step up to the plate, all well and good. If conducted in a properly controlled manner, it could well help the jury reach a verdict on the complaint under consideration, to wit:

...concern about the degree of quality loss (both measurable and visible) that occurs when Uncompressed 10-bit YUV 422 sources are serially passed-through Resolve. Which leaves the question - is it reasonable to expect that that should be a lossless process, and if not, what degree of generational quality loss should be deemed acceptable in a 32-bit float RGB system? In other words, is there legitimate cause for concern ?

At the end of the day though what matters is BMD's ('The Judge') perspective and verdict on this issue and likely the only indication we'll see of that privy session is if a 'Fixed/Improved..." writ appears in a version update changelog and there is a measurable change in behaviour.

We can measure, speculate and pontificate until the cows come home, but if BMD don't deem it important, nothing's going to change.

Again my apologies for wrongly reporting this as a new behaviour, but it did at least serve to escalate the issue.

It's REAL issue (at least for me) and it eliminates Resolve for any direct conversion of YUV (non 4:4:4) files back to YUV based format.
This also strengthen my old recommendation that Resolve should not be treated as "generic transcoder", specially for broadcast needs where most formats are YUV based.
I'm still waiting for fix.

Right. I stopped using Resolves transcode function a good while back. For me, this behaviour devalues Resolve as a 'pass-through' cut-editor for YUV Sources (non YUV 444, that is).

If it's of any interest, I ran another series of 'pass-through' generation tests, this time using the 'Belle Nuit Test Chart' as source:

https://www.belle-nuit.com/test-chart



The original chart is 8-bit, but that's OK.

Same basic protocol:

1. Test Chart > Timeline > Exported Uncomp. 10-bit YUV 422 (v210)
2. Re-imported v210 export and exported again to v210.
3. Repeated cycle five times.
4. Loaded the v210 encodes in Vdub2, copied input frame to Paint.net, cropped and saved as png.

Ran a second series also exporting to DNxHR_444 (10-bit). Used an Uncomp.10-bit RGB (r210) export for the reference image.

The main point of interest was the sector with the alternating Red and Cyan lines which target chroma sub-sampling efficiency.

Here are crops taken from the frame images of the first v210 export and first and fifth generation re-encodes:



As seen, there is progressive degradation of the vertical line set over the 5 cycles (6 including the first export). I did run another series exporting to 8-bit Uncomp. YUV 422 and the image patterns were the same.

And then the DNxHR_444 (10-bit) series:



Speaks for itself, and what I had hoped to see.

Anyway, I ran the tests for my own interest, but thought I'd post the images as they illustrate the issue rather well.

And with that, I bid you 'Bonne Nuit'

Great work Bryan!

I just love that technical eye-candy

Question: on a image 3840x2160, does the chroma shift occur on the whole frame or only on the right side of frame?

let me add that i saw something odd comparing a prores i did and a prores that was re-wrapped from that prores and comparing them i saw a shift of chroma, but only on the right side of frame.

Maybe you saw it on right hand side because shift is in the left direction and you can easily see it on the right hand side edge (if you have something red there).

And here is quickly 5 generations in vapoursynth (Lanczos scaler, 16bit int math):



Better than Resolve 1st generation. I love Resolve's 5th generation image- it has been "automatically" graded without you even touching it

From web site https://www.belle-nuit.com/test-chart

The file can be imported to a HD-NLE system and inserted into HDCAM tape before processing (these encoding processes will already alter the content).

The chart can then be examined by eye, on the waveform monitor and be exported back to an RGB file to be compared in an image processing program.

We know image is going to be damaged due to chroma smapling- this is the whole point. Resolve "damage" is just beyond any acceptance level. It's shockingly bad. Simple bars make it easily visible for eyes.
It doesn't have to be any chart etc. Anything with "hard edges" will do. That note is meaningless here.

I'm inclined to think the 'error' is occurring on export now. If I import that first v210 export back into Resolve and export to DNxHR_444 (10-bit) or r210, the 'chroma shift' on the Belle Nuit chart does not worsen - looks exactly the same as first v210 export. Knowing where it's occurring is important for me - I want to be able to import native 4:2:0 and 4:2:2 camera clips with confidence and switch to DNxHR_444 only for export. If the 'error' is occurring on import (also) I'm faced with the prospect of having to transcode everything to DNxHR_444 with FFMPEG. ProRes_4444 encoded with VDub2 could be an alternative - but tedious either way. Switching to DNxHR_444 export alone presents workflow obstacles down-stream.

Sure hope BMD fix this as a matter of priority. Goodness me, you pay a premium to get native 10-bit 422 import but can't produce clean 422 output.

Question: on a image 3840x2160, does the chroma shift occur on the whole frame or only on the right side of frame?

that's a really interesting question!

and the short answer is:

no -- the issue affects the whole frame just the same, but on the rightmost border there are a few colums of pixels, which seem to be not affected.



this time i created a few testfiles of colored checkerbord patterns. the size of the checkerboard segments are exactly 5px wide/high. this arrangement entails, that every second border will be placed in the middle of a color subsampled region. in an application which works reliable, they files will usually look like this in 444/422/420:



if you want to reproduce it yourself in resolve, here are 1sec prores video clips of the 4:4:4 and 4:2:2 variant.

unfortunately i couldn't figure out any working 4:2:0 variant. the common nv12 an i420 uncompressed files are not visible in the media page, the ljpg and jpeg2000 yuv will even crash resolve, and mpeg4 has such an unacceptable bad quality, that it isn't useful for our purposes.

as you have already seen in the fist picture of this post, the files look rather different in resolves viewer on the delivery page at high zoom levels.

Nice. And of course the chroma shift gets progressively worse if you cycle the Checkers_422 clip through Resolve exporting to v210. Also if you import the Checkers_422 clip, export to r210 and examine the two files in VDub2, they have the same pattern. Which suggests again that the '422 chroma error' is occurring on export.

BTW, the Checkers_444 file will come in very useful for testing other aspects of my workflow. Thanks for uploading that.

15.1.1 just dropped. The release notes say it has “improved chroma sub sampling for 4:2:2 renders.” Anyone want to test It out?


Sent from my iPhone using Tapatalk

I'll do more testing later, but running that 'pass-through' cycling test with the EBU Color Bars exporting to Uncomp.10-bit YUV 422 (v210) AVI, it appears to be worse ! When I ran the tests in Resolve 15.1 the aberrations (spurious spikes) on the Histogram profile only became visible in the first re-code of the initial v210 export. Now in 15.1.1 they are clearly visible in the first v210 export also. And, as before, the aberrations worsen with each cycle.



As usual, after opening link in Imgur, click on (+) cursor to enlarge.

Can't see how that's an improvement

Edit: Same results if the v210 is exported in QuickTime (MOV) format, btw. Thankfully, as before, DNxHR_444 (10-bit) is not affected.

FWIW - also tried running the v210 test (exporting as MOV at Video data levels) under 'Broadcast Safe' (0-100 IRE) restriction, and it made no difference - spurious peaks still appeared in the first export. And neither did reducing the global saturation to 40. For good measure I also put these v210 exports through an AVISynth script that detects 'out-of-gamut' Rec709 values - requires down conversion to YV12, but none were detected. So I think we can rule out 'invalid' YUV values.

Can't be bothered doing more tests. If the bug was actually fixed there might be cause for some celebratory eye-candy and awe-inspiring quality metrics. As it is, the color bar histograms are evidence enough that the bug persists. One wonders by what criteria BMD deemed the YUV 4:2:2 chroma sub-sampling to be improved ?

I want to be able to import native 4:2:0 and 4:2:2 camera clips with confidence and switch to DNxHR_444 only for export. If the (422) 'error' is occurring on import (also) I'm faced with the prospect of having to transcode everything to DNxHR_444 with FFMPEG. ProRes_4444 encoded with VDub2 could be an alternative - but tedious either way

Maybe importing ProRes_4444 and exporting DNxHR_444 is not such a good idea. Here I imported the Checkers-444 (ProRes_4444) test file (that Martin provided) into Resolve 15.1.1, exported to DNxHR_444 (10-bit) and Cineform RGB (16-bit) and re-imported the export files to examine the Histogram and Parade profiles. The MOV imports and exports were all applied at 'Video' data levels (i.e. same as 'Auto'). I also loaded the export files in VirtualDub2, copied frame grabs to Paint.net and cropped the images at magnification to view the checkers pattern.



Why the degeneration seen with the DNxHR_444 exports (same result with 12-bit also) ? The Cineform RGB (16-bit) export preserved the checker pattern well, but heck I don't want to be working with files of that size.

I also tried re-encoding the original Checkers-444 file to ProRes_4444 and Uncompressed 10-bit YUV 444 (v410) with VirtualDub2 to see if that made any difference. Resolve wouldn't import the v410 encode (mov or avi). The imported ProRes re-code preserved the characteristics of the original and when exported to DNxHR-444 the same degeneration was observed on the scopes and checker pattern in VDub2. Same also when the Cineform RGB (16-bit) export was re-imported and exported to DNxHR_444.

Yet when I ran the 'pass-though' cycle tests with the Resolve SMPTE Color Bars exporting to DNxHR_444 I didn't see observe any degradation in the Histogram profiles.

Edit: BTW, Vdub2 decodes both ProRes_4444 and DNxHR_444 to YUV444P16 by default. Cineform RGB (16-bit) decodes to RGBA64.

And, FWIW ('cos I'm in an eye-candy state of mind), here's what the Checker-444 pattern looks like when exported to Uncomp. 10-bit YUV 422.mov (v210) and then re-imported/exported to v210.mov over five cycles. All import/exports at 'Video' data levels.



The crops showing the checker patterns of the export files are taken from the top left corner of the magnified frame grab images.

VirtualDub2 decodes the v210 files to YUV422P16.

[Rohit Gupta]

If you want multiple generations of encode/decode, please use a 4:4:4 format. 4:2:2 -> 4:4:4 -> 4:2:2 conversion is also going to cause losses due to filtering algorithms used to convert from 4:2:2 to 4:4:4 and 4:4:4 to 4:2:2.

This is no different than spatial resolution if you convert from HD to UHD and then back to HD, you will see differences if you do multiple passes.

Besides, if you are using a lossy compression codec like ProRes etc, you are also going to see compression artifacts.

If you want multiple generations of encode/decode, please use a 4:4:4 format. 4:2:2 -> 4:4:4 -> 4:2:2 conversion is also going to cause losses due to filtering algorithms used to convert from 4:2:2 to 4:4:4 and 4:4:4 to 4:2:2.

i think, nobody here will deny this principal limitations, but we are much more anxious about the simple fact, that resolves seems to handle this task in a significant more lossy and image quality lessening manner than most other common video processing solutions.

My two cents is that there could be an option to either resample 422/420 material to 444 using some smoothing filter or to use pure impulse filter conversion which will prevent smearing. If this kind of upsampled material is then downsampled to 422 again using similar non-spatial method, result will be identical to original if no other spatial processing has been applied in the middle.

If you want multiple generations of encode/decode, please use a 4:4:4 format. 4:2:2 -> 4:4:4 -> 4:2:2 conversion is also going to cause losses due to filtering algorithms used to convert from 4:2:2 to 4:4:4 and 4:4:4 to 4:2:2.

i think, nobody here will deny this principal limitations, but we are much more anxious about the simple fact, that resolves seems to handle this task in a significant more lossy and image quality lessening manner than most other common video processing solutions.

Exactly that. Rohit, if you trace this matter back to it's origins in the other thread I linked to in my first post, you will see that what sparked concern was the degree of chroma loss (signaled first by quality metrics) observed when 'real world' 10-bit 422 sources are 'passed through' Resolve (with no transforms applied) to Uncompressed 10-bit 422, even on first export - and likewise after transcoding using Resolve's internal transcode function:

https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=78837#p436777

The subsequent use of test patterns (EBU Color Bars, Belle-Nuit Test Chart, Martin's Checker image) for reference was seen as an attempt to gain better visual representation/characterization of the underlying issue - the evidence pointing to sub-optimal 422 chroma sub-sampling. Evidently BMD identified some scope for improvement as the change-log for 15.1.1 declared 'Improved chroma subsampling for 4:2:2 renders'. I haven't repeated those first quality metric tests with the 'real world' v210 clip - might do so if they serve to illustrate the point. But the evidence from the chart tests is that the issue persists.

One wonders by what criteria BMD deemed the YUV 4:2:2 chroma sub-sampling to be improved ?

Perhaps you could elaborate.

My two cents is that there could be an option to either resample 422/420 material to 444 using some smoothing filter or to use pure impulse filter conversion which will prevent smearing. If this kind of upsampled material is then downsampled to 422 again using similar non-spatial method, result will be identical to original if no other spatial processing has been applied in the middle.

Well Rohit eludes to 'filtering algorithms':

4:2:2 -> 4:4:4 -> 4:2:2 conversion is also going to cause losses due to filtering algorithms used to convert from 4:2:2 to 4:4:4 and 4:4:4 to 4:2:2.

But of course we don't know to what extent that involves supplementary 'conditioning' filters and it's obviously not in BMD's interest to divulge the specifics of their algorithms. Would it really be of value to know anyway - the 'proof of the pudding is in the eating' after-all ?

15.1.1 behaves slightly differently, but it's hard to call it real improvement (maybe small one). It's still faaaaar behind a "proper" conversion. Not really acceptable for top grading tool.

v210 exports of the Checker-444 (ProRes_4444) clip from Resolve 15.1.1 and Vegas Pro 16. Vegas was set in 32-bit float (Video levels) mode:



No point in running parallel 'pass-through' cycle tests in Vegas because v210 (Sony 10-bit YUV) is passed-through untouched when no transforms are applied (preview screen on render confirms 'no re-compression'). Actually I did run a couple of cycles, just to check, and the pass-through was lossless. Surely that's how it should be ?

Maybe importing ProRes_4444 and exporting DNxHR_444 is not such a good idea. Here I imported the Checkers-444 (ProRes_4444) test file (that Martin provided) into Resolve 15.1.1, exported to DNxHR_444 (10-bit) and Cineform RGB (16-bit) and re-imported the export files to examine the Histogram and Parade profiles. The MOV imports and exports were all applied at 'Video' data levels (i.e. same as 'Auto'). I also loaded the export files in VirtualDub2, copied frame grabs to Paint.net and cropped the images at magnification to view the checkers pattern.



Why the degeneration seen with the DNxHR_444 exports (same result with 12-bit also) ? The Cineform RGB (16-bit) export preserved the checker pattern well, but heck I don't want to be working with files of that size.

Would still appreciate some insight/explanation as to what's happening there with DNxHR_444 (10-bit and 12-bit). Transcoding the Checker-444 (ProRes_4444) clip to DNxHR_444 with FFMPEG produces exactly the same pattern btw, so it can't be something peculiar to Resolve. DNxHR_444 is encoded RGB isn't it, so why the degeneration ? Does it behave like that in AVID MC ?

If you want multiple generations of encode/decode, please use a 4:4:4 format.

Well yes, DNxHR_444 encoded to 'self' shows negligible quality loss over multiple pass-through cycles. I verified that over 5 cycles using quality metrics. But the 'damage' is already done on the first export. What's more, when it comes to converting DNxHR_444 to a 10-bit 422 format outside of Resolve things get even messier.

Here I took the DNxHR_444 export of the Checkers-444 clip and transcoded to v210 with Vegas Pro 16 (AVID codecs installed) and FFMPEG:



See what I mean? 'Out of the frying pan, into the fire' you might say.

In short, I don't think exporting DNxHR_444 and converting to 10-bit YUV 422 externally is at all a satisfactory workaround for the sub-optimal chroma sub-sampling that persists with native 422 renders. Sure wish native ProRes export was available in the Windows version, but that's long been a common cry.

But DNxHR 444 was fine in previous version no?

It was (15.1) and still is (15.1.1) fine when tested ('pass-through cycling') with the EBU Color Bars, but there the reference source was created internally (EBU Color Bar Generator > Compound Clip). Where DNxHR_444 'deteriorates' is with an imported 444 source, like the Checkers-444 (ProRes_4444) clip. I'd have to roll back to 15.1 to see if the behaviour was any different, but like I said FFMPEG DNxHR_444 transcodes of the Checkers-444 clip show the same pattern on the Resolve scopes and VDub2 frame grabs.

Pity Resolve won't import Uncompressed YUV_444 formats (v410, Y416) when it comes to tests like this.

Brian,

A simple test and I understand more: you confirm?

I downloaded checker_Martin_Schitter 422
Directly I used VD2 SAT SEP22 Build 42338 release.

I converted:

in Prores 422 prores 10bits_q2
in cineform 422 cineform 10 bit filmscan 3

And import in Davinci Resolve.

And Results (Sure VD is good? Help me?)

Cheker 422 Martin Schitter 422.jpg

VD checkers 422 cineform 10B 422 filmscan3.mov.jpg

VD checkers 422 prores 422 10bits q2.mov.jpg