Serious Chroma Subsampling Bug

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

Marc Wielage

  • Posts: 5775
  • Joined: Fri Oct 18, 2013 2:46 am
  • Location: Hollywood, USA

Re: Serious Chroma Subsampling Bug

PostSun Oct 21, 2018 11:47 pm

Bryan Worsley wrote:Finding that the 'improved' 4:2:2 sub-sampling' behavior implemented in 15.1.1 is the same as that in Premiere is reassuring.

Peace at last! Peace at last! Great gosh amighty, peace at last!
marc wielage, csi • VP/color & workflow • chroma | hollywood
Offline

Bryan Worsley

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

Re: Serious Chroma Subsampling Bug

PostMon Oct 22, 2018 1:05 am

LOL. Never imagined that Little Richard would be interested in chroma sub-sampling. There again "Tutti Frutti".....hmmm. Listen to it careful, played normally then backwards - "A whop bop-a-lu a whop bam boom" - clearly reference to a pixel sampling algorithm, albeit rudimentary for it's day, in hidden lyrical code.

But how can I rest 'til the puzzle is complete ? Still trying to figure out the 422 sampling modality that was used in 15.1 (and is used in Vegas and Natron), or rather the term that would be best applied to describe it - but the pattern of results is consistent with a 'box kernel' based algorithm.
Offline

Bryan Worsley

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

Re: Serious Chroma Subsampling Bug

PostTue Oct 23, 2018 12:29 am

OK, after further dialogue with some very bright folks on the Doom9 forum, I think I've reached a meaningful conclusion on this.

Based on the pattern of results obtained when the Checker-444 clip is 'pass-through' exported to v210 in Resolve 15.1.2, the observed 444 > 422 sub-sampling pattern is consistent with 'Bilinear Resampling', wherein each pixel is convolved with kernel 0.25, 0.5, 0.25. That is to say, the UV pair is derived by weighted area summation, as represented by the top diagram in this illustration (courtesy of the VirtualDub2 developer):

Image

This re-sampling modality accounts for the separation of the R/B and G channel plots that is seen when the v210 exports are re-imported into Resolve. Premiere Pro sub-samples 444 to 422 in exactly the same manner, so we're in good company ;)

Prior to Resolve 15.1.1 (up to 15.1) the 444 > 422 sub-sampling behavior was different as illustrated by the lower diagram in the picture - there it uses the 2x2 environment of a pixel and then takes the average of these neighbor pixels to interpolate the new value, as opposed to convolved area summation. Vegas Pro and Natron (which was used to create the 'Checker' clips) show exactly the same behavior. Fusion 9 also, were it not for the 'red channel' bug I posted about above.

In the context of of image scaling this mode of sampling is referred to as 'Bilinear Interpolation' (as opposed to 'Re-sampling'). Hence the potential confusion that arises when applying the term 'Bilinear' loosely in the context of 444 > 422 chroma sub-sampling. So what to call it then ? Well, the re-sampling modality that perfectly replicates this behavior in VapourSynth and AVISynth is referred to as 'Box Kernel':

Image

Technically, both outcomes can be derived from a 'box filter' but with different chroma location, but that's what I've decided to call it to differentiate the two behaviors.

So what benefits does this new and 'improved' mode of 422 chroma sub-sampling bring ? Well that's something I intend to examine more closely (for my own interest) with 'real world' sources. The most striking benefit though is that this 'bilinear' mode of sampling makes for more consistent (reconciled) 422 sampling outcomes on export from 444 and 422 inputs - at least that was the observation in these 'pass-through' tests. That's because the 422 > 444 up-sampling is Bilinear, as it was also in 15.1. So the 15.1 'pass-through' v210 exports showed a quite different pattern of results when the 'Checker-422' clip was used for input. Again, that outcome can be closely replicated with AVISynth (and Vapoursynth) Bilinear and Box kernel re-sampling filters:

Image

In essence, it was that behavior that sparked concern about the 422 chroma sub-sampling being sub-optimal in the first place. I'm now inclined to think it was more that Resolve was better tuned for RGB/444 input. So in that sense, I think it is an improvement.

Others, more knowledgeable than I, might weigh in on the finer pros and cons.

And with that - "A whop bop-a-lu a whop bam boom"
Last edited by Bryan Worsley on Tue Oct 23, 2018 5:18 am, edited 4 times in total.
Offline

Martin Schitter

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

Re: Serious Chroma Subsampling Bug

PostTue Oct 23, 2018 2:51 am

well perhaps you should take a look in introductory papers and presentations about the general principals and reasons behind this kind of filters in the resampling process -- e.g.:

http://www.cs.cornell.edu/courses/cs562 ... -recon.pdf
https://www.csie.ntu.edu.tw/~cyy/course ... ng_4up.pdf
http://www.cs.cornell.edu/courses/cs467 ... id_web.pdf
http://graphics.cs.cmu.edu/courses/15-4 ... uction.pdf

there aren't so much practical useful filter variants variants available, and they all have some very characteristic pros and cons.

in the particular case of 4:2:2 it's btw. a little bit misleading to speak about bilinear or bicubic filtering, because the actual processing is only affecting the horizontal dimension and will therefore collapse effectively to a simple 1D linear or cubic interpolation/reconstruction.

i agree with Hendrik Proosa, that an additional configuration option, which would let users choose the desired filter, would be indeed a very nice solution. but it's such a complex topic, that most customers would most likely feel hopelessly overburdened by such a decision and its preconceiving consequences. it's therefore somehow understandable, that those applications, which are commonly used to handle only specialized tasks in the production pipeline (e.g. compositing solutions) choose a more lossless default handling, while others, which are more color grading oriented or represent end-to-end solutions, prefer the smoother alternatives. sure -- i personally still prefer maximal control and technical transparency concerning this kind of processing details, but i also somehow respect the practical need/desire of many users, to keep things simple and easily manageable.
Offline

Bryan Worsley

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

Re: Serious Chroma Subsampling Bug

PostTue Oct 23, 2018 3:25 am

Martin Schitter wrote:well perhaps you should take a look in introductory papers and presentations about the general principals and reasons behind this kind of filters in the resampling process -- e.g.:

http://www.cs.cornell.edu/courses/cs562 ... -recon.pdf
https://www.csie.ntu.edu.tw/~cyy/course ... ng_4up.pdf
http://www.cs.cornell.edu/courses/cs467 ... id_web.pdf
http://graphics.cs.cmu.edu/courses/15-4 ... uction.pdf

there aren't so much practical useful filter variants variants available, and they all have some very characteristic pros and cons.

in the particular case of 4:2:2 it's btw. a little bit misleading to speak about bilinear or bicubic filtering, because the actual processing is only affecting the horizontal dimension and will therefore collapse effectively to a simple 1D linear or cubic interpolation/reconstruction.


Martin, I used these terms because those are the names given to the AVISynth and VapourSynth chroma re-samplers that were found to faithfully replicate the observed behaviors with your 'Checker' clips, which they do, much to my amazement. From a laymans 'in-use' perspective these studies (whilst meandering and groping at times in the dark) have given me an adequate level of understanding what was going on prior to 15.1.1 and what was actually changed to improve 422 chroma sub-sampling in 15.1.1. That's all. People can take from that what they will.

I remain eternally grateful for your providing those test clips. I don't think I could reached the conclusions I have without them.

Any progress with the higher level frequency domain analysis ?

Martin Schitter wrote:i really like bryans efforts to analyze this issue and looking for a solution, nevertheless i still have my doubts, if it is useful to watch only the histogram in this particular case?

i'm rather sure, that the answer for our questions is more related to the actual filter function utilized by resolve, which could be perhaps revealed by analyzing the behavior in the frequency domain. this findings could be useful, because the undisturbed signal could perhaps be retrieved by applying a simple deconvolution operation.

unfortunately i'm not an expert in signal processing and couldn't figure out a practical solution to realize this vague idea until now. but perhaps somebody more experienced in this kind of stuff is following this conversation. in this case, i would really appreciate a helping hand resp. a short public lesson in applied signal processing mathematics. ;)
Offline

Martin Schitter

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

Re: Serious Chroma Subsampling Bug

PostTue Oct 23, 2018 5:08 am

Bryan Worsley wrote:Martin, I used these terms because those are the names given to the AVISynth and VapourSynth chroma re-samplers that were found to faithfully replicate the observed behaviors with your 'Checker' clips, which they do, much to my amazement.


it's perfectly legitim to use this common terms, and in some less optimized implementations you will perhaps even find actual implementations which indeed utilize this 2D operations... it's crazy nit picking, to stress this subtle details. ;)

Bryan Worsley wrote:I remain eternally grateful for your providing those test clips.


there is also another form of infinite checker board test patterns often used to illustrate sampling and aliasing artifacts resp. the usefulness of this kind of filtering especially in computer graphics and artificial generated images:

https://de.wikipedia.org/wiki/Rekonstru ... nte_Filter
http://developer.download.nvidia.com/bo ... _ch25.html
http://www.iquilezles.org/www/articles/ ... tering.htm
http://www.yaldex.com/open-gl/ch17lev1sec5.html
http://www.cs.utah.edu/~bratkova/classe ... index.html

which make the benefits of filtering resp. differences between alternative filter solutions obviously visible:

box filter:
Image
Image

tent filter (i.e. bilinear interpolation):
Image
Image

mitchell-netravali-filter: (i.e. bicubic)
Image
Image

Bryan Worsley wrote:Any progress with the higher level frequency domain analysis?


all this troubles are in fact related to side effects of sampling principles, which can hardly be understood without reference to their reasons and theoretical explanation in the frequency domain.

nevertheless it's not always useful to apply this way of looking at things in practice -- i.e. a FFT back and forth translation of images and modification resp. filtering in between, can be an excellent solution to substitute large computing intensive spatial filter kernels in some cases, but in our case the side effects would most likely cause more damage and IQ loss than resolves actual subsampling solution. so it's perhaps not the most optimal approach in real world. nevertheless it's still a nearly unavoidable detour, to understand the issue and its theoretical foundations.
Offline

Bryan Worsley

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

Re: Serious Chroma Subsampling Bug

PostTue Oct 23, 2018 5:24 am

Martin Schitter wrote:there is also another form of infinite checker board test patterns often used to illustrate sampling and aliasing artifacts resp. the usefulness of this kind of filtering especially in computer graphics and artificial generated images:

https://de.wikipedia.org/wiki/Rekonstru ... nte_Filter
http://developer.download.nvidia.com/bo ... _ch25.html
http://www.iquilezles.org/www/articles/ ... tering.htm
http://www.yaldex.com/open-gl/ch17lev1sec5.html
http://www.cs.utah.edu/~bratkova/classe ... index.html

Cool.
Offline
User avatar

Cary Knoop

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

Re: Serious Chroma Subsampling Bug

PostTue Oct 23, 2018 5:29 am

All this shows is that after the interlaced video headache era we now need to get rid of subsampling in the next generation of video standards. Everything 4:4:4 and, of course, values in floating point!
Offline

Martin Schitter

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

Re: Serious Chroma Subsampling Bug

PostTue Oct 23, 2018 5:43 am

Cary Knoop wrote:All this shows is that after the interlaced video headache era we now need to get rid of subsampling in the next generation of video standards. Everything 4:4:4 and, of course, values in floating point!


yes -- and also in linear light models -- because, if you apply this kind of filters e.g. by some rescaling or blur operation in rec709 RGB traditional gamma representations without additional precautions [as some simple applications unfortunately still do], you'll get very ugly artifacts on the blurred border between e.g. green and magenta... ;)

Image
Offline

Bryan Worsley

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

Re: Serious Chroma Subsampling Bug

PostWed Oct 24, 2018 5:10 am

For interests sake, I've also just checked out Edius Pro 9 (Trial) to see how it handles 422 sub-sampling. Same protocol as before - testing 'pass-through' of the Checkers-444 and Checkers-422 clips exporting to v210. The Edius project was set for 10bit depth:

Image

Looks like 10-bit 422 (Checkers-422 > v210) is 'passed-through' untouched, like Vegas Pro. Perhaps not surprising given that Edius processes internally in YUV. The 444 > 422 (Checkers-444 > v210) outcome however is consistent with with simple Nearest-Neighbor (Point) sub-sampling. Yes indeed ! I included the AVISynth 'Point sub-sampling' equivalent there for comparison. The blips on the Edius export scope profiles, by the way, come from a watermark that is placed on exports in the trial version.

Edit:
Bryan Worsley wrote:Looks like 10-bit 422 (Checkers-422 > v210) is 'passed-through' untouched, like Vegas Pro. Perhaps not surprising given that Edius processes internally in YUV.

There again, if 422 is also up-sampled to 444 with 'Point' re-sampling (as it does appear to be) it will have the same outcome. More likely that's the case.

In restrospect, I think BMD did the right thing in changing from 'Box' to 'Bilinear' 422 chroma sub-sampling in Resolve, for the reason stated earlier:

Bryan Worsley wrote: The most striking benefit though is that this 'bilinear' mode of sampling makes for more consistent (reconciled) 422 sampling outcomes on export from 444 and 422 inputs - at least that was the observation in these 'pass-through' tests. That's because the 422 > 444 up-sampling is Bilinear, as it was also in 15.1.


As this article (from 2008) puts it (succinctly) "In postproduction, chroma quality can be improved by avoiding inappropriate mixing of chroma siting and resampling schemes".

http://www.glennchan.info/articles/technical/chroma/chroma1.htm

That's my laymans take on this anyway.

Cary Knoop wrote:All this shows is that after the interlaced video headache era we now need to get rid of subsampling in the next generation of video standards. Everything 4:4:4 and, of course, values in floating point!

But meanwhile........
Offline

Bryan Worsley

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

Re: Serious Chroma Subsampling Bug

PostThu Oct 25, 2018 3:15 pm

As for YUV 4:2:0 subsampling.

Resolve won't import/export Uncomp. 420 - well, actually it will import Uncomp. YV12 in mov format but the image is garbled. As the next best thing I 'pass-through' exported (Resolve 15.1.2) the Checkers-444 clip to H264 (Best quality) and took the scope shots and checker-pattern off the leading I (key) frame. I also re-imported the H264 encode and exported to H264 again and r210 (Uncomp. 10bit RGB) to figure out the 420 > 444 up-sampling behavior. For the AVISynth 'simulations' I encoded to x264 8bit 420 Intra (High Intra@L4) at CRF 2.

Image

The 444 > 420 behavior is consistent with Box chroma sub-sampling (AVISynth equivalent there for comparison). I haven't included all of the results, but based on the pattern of results produced when the H264 render was re-imported and exported to r210 and H264 again, the 420 > 444 behavior is consistent with Point (Nearest-Neighbor) chroma up-sampling. Note how well the scope profile is preserved in the second H264 export (which represents the net outcome of 420 > 'Point' up-sample > 444 > 'Box' sub-sample > 420) - the chroma is effectively passed-through. I didn't test for more than one pass-through 'cycle', but were it not for the H264 compression that round trip conversion would be lossless.

It was the same behavior in Resolve 15.1 also.

So, no exotic filtering there.
Previous

Return to DaVinci Resolve

Who is online

Users browsing this forum: bobosola, Google [Bot], Ray Snell and 47 guests