Serious Chroma Subsampling Bug

Get answers to your questions about color grading, editing and finishing with DaVinci Resolve.
  • Author
  • Message
Offline

Bryan Worsley

  • Posts: 292
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Serious Chroma Subsampling Bug

PostThu Sep 13, 2018 4:40 am

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.
Offline

Andrew Kolakowski

  • Posts: 4237
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Serious Chroma Subsampling Bug

PostThu Sep 13, 2018 11:16 am

I bet you it will be fixed in next update.
Offline

Bryan Worsley

  • Posts: 292
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Serious Chroma Subsampling Bug

PostThu Sep 13, 2018 3:18 pm

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.
Offline
User avatar

Jean Claude

  • Posts: 1668
  • Joined: Sun Jun 28, 2015 4:41 pm

Re: Serious Chroma Subsampling Bug

PostThu Sep 13, 2018 5:28 pm

Bryan Worsley wrote:A (presumed) chroma subsampling bug......


very good expression. :)
Windows 10 PRO X64 1709 and 1803 | DaVinci Resolve Studio 15.1.0.023 | Fusion Studio 9.0.2 | Decklink Studio 4K 6G | Desktop Video 10.10.11
Offline

Bryan Worsley

  • Posts: 292
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Serious Chroma Subsampling Bug

PostThu Sep 13, 2018 5:45 pm

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.
Offline

Seth Goldin

  • Posts: 311
  • Joined: Wed Nov 04, 2015 7:43 pm

Re: Serious Chroma Subsampling Bug

PostThu Sep 13, 2018 5:52 pm

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
DaVinci Resolve Studio 15.1.0.024
Windows 10 Pro 1803 17134.285 and CentOS Linux 7.3 [Blackmagic Design custom ISO]
HP Z8 G4
GeForce GTX 1080 Ti
Offline

Bryan Worsley

  • Posts: 292
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Serious Chroma Subsampling Bug

PostThu Sep 13, 2018 6:02 pm

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.
Offline

Andrew Kolakowski

  • Posts: 4237
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Serious Chroma Subsampling Bug

PostFri Sep 14, 2018 10:47 am

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

Bryan Worsley

  • Posts: 292
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Serious Chroma Subsampling Bug

PostFri Sep 14, 2018 2:22 pm

Andrew Kolakowski wrote:Not fixed in 15.1 (at least on Mac).
Not good at all!

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

Bryan Worsley wrote: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. ;)
Offline

Andrew Kolakowski

  • Posts: 4237
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Serious Chroma Subsampling Bug

PostFri Sep 14, 2018 2:49 pm

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.
Offline

Bryan Worsley

  • Posts: 292
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Serious Chroma Subsampling Bug

PostFri Sep 14, 2018 5:42 pm

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 ?
Offline

Bryan Worsley

  • Posts: 292
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Serious Chroma Subsampling Bug

PostSat Sep 15, 2018 2:39 am

Bryan Worsley wrote: Implications for optimised media also ?


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

Bryan Worsley wrote: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.

Image

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.
Last edited by Bryan Worsley on Sat Sep 15, 2018 4:01 am, edited 2 times in total.
Offline

Martin Schitter

  • Posts: 787
  • Joined: Tue Apr 28, 2015 10:41 pm

Re: Serious Chroma Subsampling Bug

PostSat Sep 15, 2018 3:49 am

Bryan Worsley wrote: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.
Offline

Bryan Worsley

  • Posts: 292
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Serious Chroma Subsampling Bug

PostSat Sep 15, 2018 4:27 am

Martin Schitter wrote:
Bryan Worsley wrote: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 ?? :shock: 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.
Offline

Martin Schitter

  • Posts: 787
  • Joined: Tue Apr 28, 2015 10:41 pm

Re: Serious Chroma Subsampling Bug

PostSat Sep 15, 2018 8:33 am

Bryan Worsley wrote:Refusing ?? :shock:

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.
Offline

Bryan Worsley

  • Posts: 292
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Serious Chroma Subsampling Bug

PostSat Sep 15, 2018 3:42 pm

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.
Offline

Martin Schitter

  • Posts: 787
  • Joined: Tue Apr 28, 2015 10:41 pm

Re: Serious Chroma Subsampling Bug

PostSat Sep 15, 2018 5:56 pm

Bryan Worsley wrote: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.

Bryan Worsley wrote: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... ;)

Bryan Worsley wrote: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.
Offline
User avatar

Cary Knoop

  • Posts: 648
  • Joined: Sun Mar 12, 2017 6:35 pm
  • Location: Newark, CA USA

Re: Serious Chroma Subsampling Bug

PostSat Sep 15, 2018 7:05 pm

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.
Offline

Andrew Kolakowski

  • Posts: 4237
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Serious Chroma Subsampling Bug

PostSat Sep 15, 2018 8:37 pm

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).
Offline

Bryan Worsley

  • Posts: 292
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Serious Chroma Subsampling Bug

PostSat Sep 15, 2018 10:37 pm

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 :oops: :oops:
Offline

Bryan Worsley

  • Posts: 292
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Serious Chroma Subsampling Bug

PostSun Sep 16, 2018 4:40 am

Martin Schitter wrote:
Bryan Worsley wrote: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.
Offline

Martin Schitter

  • Posts: 787
  • Joined: Tue Apr 28, 2015 10:41 pm

Re: Serious Chroma Subsampling Bug

PostSun Sep 16, 2018 9:09 am

Bryan Worsley wrote: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!

Bryan Worsley wrote: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.

Bryan Worsley wrote: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.

Bryan Worsley wrote: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.
Offline

Bryan Worsley

  • Posts: 292
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Serious Chroma Subsampling Bug

PostSun Sep 16, 2018 5:28 pm

Martin Schitter wrote:
Bryan Worsley wrote: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:

Bryan Worsley wrote:...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.
Offline

Andrew Kolakowski

  • Posts: 4237
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Serious Chroma Subsampling Bug

PostSun Sep 16, 2018 6:49 pm

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.
Offline

Bryan Worsley

  • Posts: 292
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Serious Chroma Subsampling Bug

PostSun Sep 16, 2018 7:31 pm

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).
Offline

Bryan Worsley

  • Posts: 292
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Serious Chroma Subsampling Bug

PostTue Sep 18, 2018 3:56 am

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

Image

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:

Image

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:

Image

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' :)
Last edited by Bryan Worsley on Tue Sep 18, 2018 2:44 pm, edited 6 times in total.
Offline
User avatar

Cary Knoop

  • Posts: 648
  • Joined: Sun Mar 12, 2017 6:35 pm
  • Location: Newark, CA USA

Re: Serious Chroma Subsampling Bug

PostTue Sep 18, 2018 4:20 am

Great work Bryan!
Offline

Bryan Worsley

  • Posts: 292
  • Joined: Fri Apr 15, 2016 11:26 am
  • Location: Montreal, Canada

Re: Serious Chroma Subsampling Bug

PostTue Sep 18, 2018 4:36 am

I just love that technical eye-candy ;)
Offline
User avatar

waltervolpatto

  • Posts: 6045
  • Joined: Thu Feb 07, 2013 5:07 pm
  • Location: Burbank, CA

Re: Serious Chroma Subsampling Bug

PostTue Sep 18, 2018 4:26 pm

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.
SuperServer 5039AD-I
C9X299-PGF - DDR4-2400 16x4 GB
i9-7920xCPU 12c 2.90GHz Water cooled
2x GTX 1080ti DeckLink Studio 4K
Window10 - Resolve Studio 15.0.1.003
nvidia dr: 398.82
Offline

Andrew Kolakowski

  • Posts: 4237
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Serious Chroma Subsampling Bug

PostTue Sep 18, 2018 4:54 pm

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):

Image

Better than Resolve 1st generation. I love Resolve's 5th generation image- it has been "automatically" graded without you even touching it :D
Last edited by Andrew Kolakowski on Tue Sep 18, 2018 7:56 pm, edited 1 time in total.
Offline
User avatar

Jean Claude

  • Posts: 1668
  • Joined: Sun Jun 28, 2015 4:41 pm

Re: Serious Chroma Subsampling Bug

PostTue Sep 18, 2018 5:45 pm

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.

:)
Windows 10 PRO X64 1709 and 1803 | DaVinci Resolve Studio 15.1.0.023 | Fusion Studio 9.0.2 | Decklink Studio 4K 6G | Desktop Video 10.10.11
Offline

Andrew Kolakowski

  • Posts: 4237
  • Joined: Tue Sep 11, 2012 10:20 am

Re: Serious Chroma Subsampling Bug

PostTue Sep 18, 2018 6:01 pm

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.

Return to DaVinci Resolve

Who is online

Users browsing this forum: 5-Hydroxy-Tryptophan, Bing [Bot], David E King, shangshangw and 26 guests