Serious Chroma Subsampling Bug

I'll have to come back to you on this Jean Claude. I want to compare the behavior in 15.1.1 vs 15.1 more closely also and I'm a bit short on time just now.

But briefly (without the magnified checker images), these are the Resolve (15.1.1) scope profiles I get with the Checker-422 clip and VDub2 (32-bit 42338 build) transcodes (v210, Cineform FS3, ProRes HQ 422 q2). Also included the 'pass-through' v210 export from Resolve (15.1.1) which shows the 'chroma sampling issue'.



No I don't think there's a problem with VDub2 - but you need to set 'Rec709' explicitly (i.e. instead of default 'no change'), otherwise you'll get those R/B vs G channel shifts. Same thing in FFMPEG.

I have to say through, I had the impression that the Checker-422 clip was actually a v210 export from Resolve (15.1 then) and that Martin uploaded it to show the 422 chroma sampling issue. That's why I used the 'untainted' (as assumed) Checkers-444 (ProRes) clip as the reference source in further tests.

@Martin, if you are looking in, could you please clarify if that was the case or if you created the Checkers-422 clip outside of Resolve ? It's important to know before I roll back to 15.1 for more testing.

@Martin, if you are looking in, could you please clarify if that was the case or if you created the Checkers-422 clip outside of Resolve ? It's important to know before I roll back to 15.1 for more testing.

i think, i did all clips just by natron... but i'm such a notorious confused character, that i would have to do it again to feel certain...

I think you probably did - the Resolve scope profile of the 'original' Checkers-422 clip (in the last set) looks to be the same as that of the v210 export from Vegas Pro that I posted earlier, where I used the Checker-444 clip as the input source:

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:

Well I went ahead and rolled back to 15.1 anyway. Don't have time to produce the checker frame image crops just now, but here are the scope profiles obtained with the Checker-422 clip exported to v210 and then over a three further 'pass-through' export cycles.

Resolve 15.1



Resolve 15.1.1



Comparing the scope profiles of the initial v210 exports, I agree with Andrew's earlier comment:

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.

But briefly (without the magnified checker images), these are the Resolve (15.1.1) scope profiles I get with the Checker-422 clip and VDub2 (32-bit 42338 build)

No I don't think there's a problem with VDub2 - but you need to set 'Rec709' explicitly (i.e. instead of default 'no change'), otherwise you'll get those R/B vs G channel shifts. Same thing in FFMPEG.

Thank you. OK, I may have been wrong and I started again and.... No change
Importing in VDub2 (32-bit 42338 build) the clip checkers-422.mov and exporting it in MOV PRORES and CINEFORM, the same way yesterday. I have attention to checker REC.709

I can not get your results.

Can you post your VDub2 project? Thank you.

CINEFORM_422.jpg

PRORES_422.jpg

As for the other issue with DNxHR_444. To recap:

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.

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.

When I rolled back to 15.1 the behavior was no different - same scope profile and checker pattern as in 15.1.1 when the imported Checkers-444 (ProRes_4444) file was was exported to DNxHR_444 (10-bit and 12-bit). I also converted (with VDub2) the Checkers-444 file to Uncomp.10-bit RGB (r210), which Resolve will import (in MOV format), to see if it made any difference, and it didn't. By way of a 'control' I also exported the 'checkers-r210' import to r210 again, and the original scope profile and checker pattern was preserved, as you would expect.

So why this odd and unexpected behaviour with DNxHR ?

No I don't think there's a problem with VDub2 - but you need to set 'Rec709' explicitly (i.e. instead of default 'no change'), otherwise you'll get those R/B vs G channel shifts. Same thing in FFMPEG.

Thank you. OK, I may have been wrong and I started again and.... No change
Importing in VDub2 (32-bit 42338 build) the clip checkers-422.mov and exporting it in MOV PRORES and CINEFORM, the same way yesterday. I have attention to checker REC.709

I can not get your results.

Can you post your VDub2 project? Thank you.

Sorry, I should have been more specific. The explicit 'Rec709' Color Space setting needs to be made in the Video > Decode Format (Decompression) settings:



In the Video > Compression > Pixel Format (Output Format to Compressor) settings you can leave the Color Space at default 'No Change', because the Rec709 interpretation has already been asserted at decode and is carried through to output.

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.

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

Couldn't agree more. As per my earlier comment, I'm pretty much resigned to waiting to see what may or may not come of this way of measurably improved 422 chroma sampling.

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 ?

But you can be sure that with each update I'll be eagerly testing for any improvement. And I think your Checker-444/422 test clips are as good an indicator of that as any.

Meanwhile, this other DNxHR_444 issue is really bugging me.

OK: I do not have much time for that but I will test too

As for the other issue with DNxHR_444. To recap:

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.

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.

When I rolled back to 15.1 the behavior was no different - same scope profile and checker pattern as in 15.1.1 when the imported Checkers-444 (ProRes_4444) file was was exported to DNxHR_444 (10-bit and 12-bit). I also converted (with VDub2) the Checkers-444 file to Uncomp.10-bit RGB (r210), which Resolve will import (in MOV format), to see if it made any difference, and it didn't. By way of a 'control' I also exported the 'checkers-r210' import to r210 again, and the original scope profile and checker pattern was preserved, as you would expect.

So why this odd and unexpected behaviour with DNxHR ?

I wondered if a DNxHR_444 export from Avid Media Composer might behave differently and so installed the trial version of the program (what a tedious process). Couldn't figure if/how it's possible to export DNxHR from an HD project, so exported DNxHD 444.mxf. The file behaved exactly the same as a DNxHD_444 export from Resolve:



The only conclusion I can draw is that that is indeed how DNxHR_444 looks 'up close and personal' at the pixel level - not very encouraging.

Anyone running Resolve on a Mac care to test the 'Checker-444' file exported to ProRes_4444 ? The files are here:

... 1sec prores video clips of the 4:4:4 and 4:2:2 variant.

The only conclusion I can draw is that that is indeed how DNxHR_444 looks 'up close and personal' at the pixel level - not very encouraging.

And it gets even uglier after converting to 8-bit 4:2:0. Here I did so with AVISynth+ with and without dithering (Floyd–Steinberg - error diffusion). This was the raw AVISynth+ 8bit 4:2:0 output into VirtualDub2:



I'm tempted to suggest that despite the sub-optimal 422 chroma sub-sampling in the Resolve v210 export it probably yields the better outcome in this case. Don't have a Resolve ProRes_4444 export of the Checker-444 clip to test and compare, but I suspect it would change my opinion on that.

Came across this post (#20) on the LGG forum:

https://www.liftgammagain.com/forum/index.php?threads/comparing-dnxhr-vs-prores.8458/#post-83803

Quote: "As for DNx vs ProRes, I remember reading a paper on this subject. The takeaways were:

Both do an awesome job.

DNx was optimized to be more visually lossless while ProRes to be more mathematically lossless. So DNx adds a slight blurring in some instances to tame artifacting and aliasing in the original image. This can cause regeneration problems, but you have to go like 8 generations to see it."

Can't find the paper he's referring to, but is that correct ? If so, it might explain the behavior seen with the Checker-444 clip i.e. the blurring gets amplified by the 5x5 pixel block pattern. Feasible ?

Hello,

Is it possible to have the scopes as proposed Davinci Resolve since original application that generated the Checker-444.mov and the checker-422.mov ? (Natron if I remember correctly):
- Parade
- waveForm
- VectorScope
- Histogram

Thank you in advance.

I'm not sure I follow what you're asking Jean Claude

Just a capture screen.

Ah, OK, screen capture of the scopes in Natron ? Martin's your man for that.

I have wondered though if/how the 5x5 pixel checkerboard pattern can be created in Resolve (or Fusion in Resolve), and at other resolutions ? I think it should be incorporated as one of the built-in 'generator' test patterns (I'm kidding). It is a very useful test though.

Ah, OK, screen capture of the scopes in Natron ? Martin's your man for that.

I have wondered though if/how the 5x5 pixel checkerboard pattern can be created in Resolve (or Fusion in Resolve), and at other resolutions ? I think it should be incorporated as one of the built-in 'generator' test patterns (I'm kidding). It is a very useful test though.

Hello Bryan,

Absolutely because if the 444 is good, the 422 needs to be redone.

I followed your recommendations in VD for the decompressor and here is what I see at 400% + prefered filter 'Point'. You confirm?

VD_444_422.jpg

If I understand correctly - so there you have loaded the original Checkers-444 and Checkers-422 clips into VirtualDub2, set the decode interpretation to Rec709 (Checkers-444 clip is then decoded as YUV444P16-709 and Checkers-422 clip as YUV422P16-709) and those are the checker patterns produced on the VDub2 'Input Pane' (which it will be by default). Correct ?

If so, yes, I get the same patterns. Here, as before, I copied the VDub2 input frame (using Video > Copy Source Frame to Clipboard function), to Paint.net, magnified it and cropped a selection from the top left corner.



Actually what perplexes me (now I've come to test it) is the pattern of results when the Checkers-444 clip is transcoded to v210 in VDub2. I'll come back on that...maybe, if proves relevant.

well -- i don't understand, why Jean Claude want's to see exactly this kind of pictures, because most of us are usually looking for a different kind of beautiful images...

but at least i uploaded some stuff, which may be useful to reproduce the test patterns -- nothing fancy, because it's only a matter of a few clicks to configure a checkerboard in natron or nuke to 5px pattern size and choose the usual green and magenta colors (e.g. with the pipette from a color bar generator)...

but here you'll find a ready prepared project for natron and for nuke non-commercial

i hope, i didn't make any mistake by working sloppily...

and because Bryan wanted a solution for resolve, i also wrote a really trivial DCTL version as well. but in this case i also have to express some words of warning: because i really don't like software, which doesn't associate the four letter word "FREE" with the simple freedom of users to utilize selfwritten scripts and extensions within "free" editions of their software, i had to publish this script under the terms of the AGPL. you are therefore not allowed to use this code in any non-free application -- e.g. resolve!

Cool, thanks for that Martin. Yes, I'm a bit sick of looking at checker-board patterns also....but they do have subliminal hypnotherapeutic benefits as well Mind you I had a terrible nightmare last night where I was a pawn in a chess game and was trapped in an eternal 'Blackmagic–Diemer Gamut' (I know, 'Blackmar–Diemer Gambit', but then it wouldn't be funny).

Guess I need to familiarize myself with Natron and DCTL scripts.

but here you'll find a ready prepared project for natron

@Martin, not wishing to turn this into a Natron tutorial, I've managed to render the checker image to Uncomp.10bit YUV444 (v410), because there's an export preset for it, but cannot figure how to export Uncomp.10bit YUV422 (v210), as per your 'Checker-422' file. Couldn't see any custom profile config option. How did you do it ?



Best I could come up with for 10-bit 422 export was lossless HuffYUV (ffmpeg version) or FFV1 AVI. Neither format is imported by Resolve, but after conversion to v210 with VDub2, the behavior is the same as your Checkers-422 (v210) clip.

If its of interest, Resolve won't import/export uncompressed YUV 4:2:0, but here are the scope profiles and checker patterns obtained when the Checker test clips are exported to H264.mp4 (Best quality). I sampled off the first Key (I) frame:



It does at least look like the 4:2:0 chroma sampling is correct.

I don't plan on posting any more 'Checker' test results unless 4:2:2 chroma sampling is improved in future updates.

@Martin, not wishing to turn this into a Natron tutorial, I've managed to render the checker image to Uncomp.10bit YUV444 (v410), because there's an export preset for it, but cannot figure how to export Uncomp.10bit YUV422 (v210), as per your 'Checker-422' file. Couldn't see any custom profile config option. How did you do it ?

my rendered 444 and 422 files are ProRes HQ files. this isn't an optimal choice for this kind of tests, because lossless compression would be better, but it was at least the most compatible choice, which i could find.

unfortunately natron doesn't support a few pix_fmts via the GUI, which are available in ffmpeg and could be used in AVI containers. i really understand, that the natron developers didn't add this very exotic variants, because the list of available choices is already uncomfortable long and it's very strange demand, to look for an uncompressed export option but utilitilizing color subsampling at the same time. nevertheless we should perhaps open a feature request concerning this issue at the natron issue tracker, because it would be very easy to fix.

another rather compatible variant, which may work on windows and mac, would be utilizing one of the lossless jpeg/jpeg2000 variants -- the latter should even work in mov containers and support all color subsampling variants --, but this will unfortunately crash the linux version of resolve.

Best I could come up with for 10-bit 422 export was lossless HuffYUV (ffmpeg version) or FFV1 AVI. Neither format is imported by Resolve,..

this are file formats, which are hardly supported in non-ffmpeg-based applications, and AVI is in general a very problematic choice, because of the limited metadata, which often cause misinterpretation...

i'm not very happy about all this limitations and compromises, but at least it somehow explains/excuses, why i have chosen ProRes at the end.

Did you consider using ffmpeg to create tiff sequence?

Did you consider using ffmpeg to create tiff sequence?

image sequences are not very useful, if you want examine color subsampling issues.
o.k. in case of JPEG you can utilize similar color subsampling modes, nevertheless i think, common video codecs and containers are a more realistic test scenario.

my rendered 444 and 422 files are ProRes HQ files

OMG, you're right ! I remember now that I converted the original Checker-422 clip to v210.mov and used that in subsequent tests - the behavior is exactly the same anyway. Left the Checker-444 clip as ProRes because Resolve doesn't import v410.

Best I could come up with for 10-bit 422 export was lossless HuffYUV (ffmpeg version) or FFV1 AVI. Neither format is imported by Resolve,..

this are file formats, which are hardly supported in non-ffmpeg-based applications, and AVI is in general a very problematic choice, because of the limited metadata, which often cause misinterpretation...

They were valid lossless 10bit 422 export options in this context though.

@Martin, I also tried the Nuke (Non-Commercial) 'Checker' project you uploaded. Nuke does export v210, but the Resolve scopes show this down-shift:



I didn't alter your project at all; simply added a Writer node, set the Color Space to Rec709, File Type to mov and selected Uncomp. 10bit 422 from the export format drop-down menu. Clearly something is not right. In the Natron 'Checker' project, the Writer configuration panel had settings for both Input Colorspace (set to linear/Linear) and File Colorspace (set to display/nuke_Rec709). Can't see an Input Colorspace option on the Nuke Writer panel.

I'm sure v210 convert of the HuffYUV export from Natron is valid as an Uncompressed 10-bit 422 reference, but I want to be certain. These 'Checker' patterns are useful for validating format conversions outside of Resolve also.

everything you did sounds perfecty correct to me! (btw.: congratulations!)

it was a mistake on my side!
as already mentioned in one of my last posts, i simply used the color picker to choose some plausible color patches from the color bar generators of both applications, because i was to lazy to think about more useful values. in hindsight, this wasn't a good idea, because unfortunately the color bar generators of both applications differ significantly in their default behavior. if you really want to get exactly the same colors in all variants, you simply should change the colors in the color checker node to 0, .75, 0 and .75, 0, .75 (or .7 to get closer to more common results)

i really didn't pay greater attention to this detail, because i only wanted two opposite colors on this axis, but i didn't care much about their actual intensities. the color of the checker patches aren't interesting at all to me. it's the applied filter function, which just becomes more obvious by this example, that should be in the focus of our examination efforts.

OK, thanks for clarification. I probably should have realized that looking at the 'checkerboard' node settings.

Actually what perplexes me (now I've come to test it) is the pattern of results when the Checkers-444 clip is transcoded to v210 in VDub2. I'll come back on that...maybe, if proves relevant.

Too late to compile and report the results tonight, but further testing in VDub2 has turned up something that is very pertinent to the 422 chroma sampling issue in Resolve.

In the Natron 'Checker' project, the Writer configuration panel had settings for both Input Colorspace (set to linear/Linear) and File Colorspace (set to display/nuke_Rec709). Can't see an Input Colorspace option on the Nuke Writer panel

Nuke does not have input colorspace for writers, input is taken as is (based on default interpretation of what it should be), unless OCIO etc color management is used (ACES OCIO configs for example set one concrete working color space, into which all read footage is converted). In case of default Nuke project, input is taken as linear sRGB/rec709 (one can easily override it explicitly by using Colorspace or OCIOColorspace node in stream, but write node does not change its behavior, it still takes input as if it was linear sRGB/rec709). If you want to simply dump data into file with no transfer function/gamut transform, you can check the "raw" checkbox in write node. It will bypass all colorspace conversions and only does stuff necessary for writing the actual format.

If you want to simply dump data into file with no transfer function/gamut transform, you can check the "raw" checkbox in write node. It will bypass all colorspace conversions and only does stuff necessary for writing the actual format.

yes -- that's indeed another possibility, which is available in nuke just as in natron. in fact both applications are very similar and support more or less the same general concepts and basic capabilities. it's just a matter of warm up, to get used to their linear light color handling, but once you learned to understand the advantages of this kind of workflows, you usually don't want to go back to legacy broadcast conventions and exchange formats anymore.

nevertheless this tools are just a side issue, the real question should still concern resolves handling of color subsampling.

it's in fact a really interesting question. i still can't give a clear answer, if resolve is handling this aspects better then others (because from a theoretical point of view, this kind of image filtering may indeed have its benefits in case of upsampling resp. reconstruction of in between color values, although it causes this nasty side effects), or if the more primitive approach used by other solutions, which doesn't alter the values and archives less generative loss, should be seen as the more desirable choice?

Thanks Hendrik. I doubt that I'll be using Nuke or Natron apart from these tests - I'm pretty much a straightforward 'edit-grade' guy - but it's useful to get a little acquainted with compositing software such the need arise.

Too late to compile and report the results tonight, but further testing in VDub2 has turned up something that is very pertinent to the 422 chroma sampling issue in Resolve.

Recall the pattern of results obtained when the 'Checker-422' clip (actually the original ProRes HQ clip converted to v210 with VDub2) was 'pass-through' cycled through Resolve 15.1 and 15.11

Well I went ahead and rolled back to 15.1 anyway. Don't have time to produce the checker frame image crops just now, but here are the scope profiles obtained with the Checker-422 clip exported to v210 and then over a three further 'pass-through' export cycles.

Resolve 15.1



Resolve 15.1.1



Comparing the scope profiles of the initial v210 exports, I agree with Andrew's earlier comment:

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.

Well I repeated the test in 15.1.1 this time using the 'Checker-422' clip that I reproduced from Natron (i.e. exported as HuffYUV 10bit 422 and converted to v210 with VDub2)

What I also did though was to cycle the Checker-422 (v210) clip through Uncomp.10bit YUV444 (v410) using VirtualDub i.e. exported the Checker-422 clip to v410, converted the v410 export to v210.. and so on.

Here are the results:



As you can see, the Resolve 'pass-through' series produced the same pattern of results as the earlier test with Resolve 15.1.1 - no surprise there. What is significant is the VDub2 series shows exactly the same pattern. In other words VDub2 appears to be using the same up-sampling and down-sampling algorithms as Resolve 15.1.1. Which raises the question - are both doing it 'wrong' ?

I'll contact the VDub2 developer to see if he can shed light on the conversion algorithms used in VDub2.

Edit:

What is significant is the VDub2 series shows exactly the same pattern.

In fact when I compared the matched v210 exports in the two series using quality metrics there was no difference between them - 'lossless' according to SSIM scores.

....nevertheless this tools are just a side issue, the real question should still concern resolves handling of color subsampling.

it's in fact a really interesting question. i still can't give a clear answer, if resolve is handling this aspects better then others (because from a theoretical point of view, this kind of image filtering may indeed have its benefits in case of upsampling resp. reconstruction of in between color values, although it causes this nasty side effects), or if the more primitive approach used by other solutions, which doesn't alter the values and archives less generative loss, should be seen as the more desirable choice?

Hopefully the above results shed some further light. I'm not aware that VDub2 applies any special filtering, but I'll see what the developer has to say about this.

Clearly though Vegas Pro handles 422 sub-sampling in a different manner and one that is deemed to produce the proper/desirable outcome.

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 it's simply down to the choice of calculations applied in deriving U and V averages from the UV pair in 444 ? But that's about the limit of my basic understanding of how 422 sub-sampling works.

Noted in another, unrelated thread:

Hi all,
In light of flickering problems I'm having with 15 Studio, I want to go back to 14.3. Is there any possible way to edit my projects in 14.3 or am I SOL?

We have an update coming in the next few days to address a known issue in Windows. If you can wait for that, consider staying on v15.

Oooh, another update is imminent. Let's see what it brings.

I'll contact the VDub2 developer to see if he can shed light on the conversion algorithms used in VDub2.

I think it's a good idea. I also did a test from Fusion and Davinci Resolve V15 and if we work in uncompressed ? I also ask myself how does VDUB2 work without a filter?

ORIGINAL 422.jpg

(uncompressed QT YUV 422 10b)

FROM ORIGINAL 422_QT_UNCOMPRESSED_YUV422_10B.jpg

(uncompressed QT YUV 422 10b fusion after import in DRV15)

fusion_422.jpg

Response(s) from the VirtualDub2 developer, quote "Checked what is going on with chroma:

444 -> 422: each pixel is convolved with kernel 0.25, 0.5, 0.25. As I understand this creates some blurring.

422 -> 444: odd pixel is copied as is, even pixel is blended from two neighbor source pixels
This is simple."

Since identical are results are produced 'passing' 10-bit 422 through Resolve, it's reasonable to conclude that Resolve up-samples to 444 and sub-samples to 422 in like manner.

Edit: And, "...it seems Sony is using bilinear downsampling for 444->422, this blends max 2 neighbor pixels as opposed to summed area. For 422->444 it is still bilinear upsampling, no changes"

Notes for 15.1.2: “Addressed an issue when rendering to ProRes 444 where the output could have chroma overflow artefacts”


Sent from my iPhone using Tapatalk

Tested Resolve 15.1.2 with the Checkers-422 clip 'pass-through' exported to v210. Identical results to 15.1.1. No change in the 422 chroma sub-sampling behaviour.

Response(s) from the VirtualDub2 developer, quote "Checked what is going on with chroma:

444 -> 422: each pixel is convolved with kernel 0.25, 0.5, 0.25. As I understand this creates some blurring.

422 -> 444: odd pixel is copied as is, even pixel is blended from two neighbor source pixels
This is simple."

Since identical are results are produced 'passing' 10-bit 422 through Resolve, it's reasonable to conclude that Resolve up-samples to 444 and sub-samples to 422 in like manner.

Further clarification from the VDub2 developer on the 422 > 444 up-sampling. By definition it is
"Bilinear. Even sample is centered so it is not blended but odd sample is blended"

So it looks like the different behaviors observed with Resolve and Vegas Pro when the 'Checkers-444' clip was 'pass-through' exported to v210 do boil down to the 444 > 422 sub-sampling (UV pair averaging) modality:

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:

Resolve: (likely) each pixel is convolved with kernel 0.25, 0.5, 0.25, which creates some blurring.
Vegas: (likely) Bilinear - blends max 2 neighbor pixels as opposed to summed area.

Resolve: (likely) each pixel is convolved with kernel 0.25, 0.5, 0.25, which creates some blurring.

i don't think VDubs2 handling of this kind of operations can be simply compared with resolves actual implementation. while most of this simple traditional video applications still use pixel arrays and discrete iterations over the given pixel data, resolve will more likely use GPU accelerated techniques/abstractions (e.g. just scaling of Cb/Cr textures) for this purpose, which works slightly different resp. shows other characteristics.

Maybe so, but it seems more than co-incidence that:

...when I compared the matched v210 exports in the two series [Resolve vs VDub2] using quality metrics there was no difference between them - 'lossless' according to SSIM scores.

I don't think I can bring anything more to the table on this matter. Done the best I can to gain some insight. Maybe 'a little knowledge is a dangerous thing', so I'll leave it there.

Of course all of our (my) 'through a looking glass darkly' speculation could be swept away by a simple clarification from BMD.

Resolve: (likely) each pixel is convolved with kernel 0.25, 0.5, 0.25, which creates some blurring.

i don't think VDubs2 handling of this kind of operations can be simply compared with resolves actual implementation. while most of this simple traditional video applications still use pixel arrays and discrete iterations over the given pixel data, resolve will more likely use GPU accelerated techniques/abstractions (e.g. just scaling of Cb/Cr textures) for this purpose, which works slightly different resp. shows other characteristics.

Upscaling should be done on YCbCr components anyway, resampling RGB data is of no use because conversion to RGB already produces full-resolution image planes for each component. GPU also iterates over pixel arrays when processing is done in CUDA/OpenCL, nothing different there.

GPU also iterates over pixel arrays when processing is done in CUDA/OpenCL, nothing different there.

sure -- at the end it should look the same, and the actual processing will even e.g. in OpenGL/GLSL have to realize more or less the same calculations, but i still would see this difference as noteworthy, because you simply specify filter and resampling details in a different manner in this case and the results are also often influenced to some degree by hidden optimization details.

but concerning this whole debate, this simple statement from the other mentioned discussion board looks like the most agreeable and meaningful one to me:

"Nearest neighbor should not blur. And it should survive multiple generations . It's just duplicating the chroma samples when you go 422=>444 , dropping the exact same samples when you go 444=>422 . So it's a lossless transform if done properly, and you can do it infinite times. Any other algorithm will incur some loss each step, some rounding errors, some blurring which gets worse each successive iteration . But nearest neighbor does not necessarily look good on normal content (blocky color edges), in fact it's considered the worst usually for most types of content. But it's good for test patterns."

"Nearest neighbor should not blur. And it should survive multiple generations . It's just duplicating the chroma samples when you go 422=>444 , dropping the exact same samples when you go 444=>422 . So it's a lossless transform if done properly, and you can do it infinite times. Any other algorithm will incur some loss each step, some rounding errors, some blurring which gets worse each successive iteration . But nearest neighbor does not necessarily look good on normal content (blocky color edges), in fact it's considered the worst usually for most types of content. But it's good for test patterns."

that.

….this simple statement from the other mentioned discussion board....

BTW - I deleted the link for that 'mentioned discussion board' because it fragmented into dialogue about the perplexing DNxHR_444 behavior seen with the 'Checker-444' clip, and in the wider context, not just Resolve. What was pertinent to the present discussion (and what was sought) was the VDub developers clarification of the 422 > 444 and 444 > 422 sampling modalities as they are applied in VDub2.

Well, I've been conducting some further tests with the 'Checkers-422' clip (or rather the v210 version I recreated from Natron). This time I've been testing 10-bit 422 <->444 inter-conversions in AVISynth+ using filters that allow specification of the applied chroma sampling modality (Nearest Neighbor/Point, Bilinear, Bicubic etc).

I found that when the 'Checkers-422' clip is converted to 10-bit YUV444 and back to 10-bit YUV422, using Bilinear chroma sampling in both conversions, and the output (p210, planar 10bit YUV422) is encoded to v210 with VDub2, the encode (in mov format) imported in Resolve produces an identical scope profile to that obtained when the 'Checkers-422' clip is 'pass-through' exported to v210.

But more than that - when quality metrics are applied to compare the two encodes both the SSIM and PSNR report lossless for the Luma and UV chroma. Achieving a 'lossless' SSIM score (1.000000) is one thing, achieving a maximum PSNR score as well (i.e. Inf = Infinity) says that it is really lossless = no difference between the two Also, when I checked the file sizes, the two encodes were within a few bytes of being 'byte identical'. That is way beyond coincidence.

This leaves me with the firm conclusion that when Uncompressed 10bit YUV422 (v210) is 'passed through' Resolve 15.1.1 (15.1.2 also) and exported again to v210, the chroma sampling applied both in the up-conversion to 444 and sub-sampling back to 422, is Bilinear. That's what produces the distinctive profile patterns we've seen on the Resolve Histogram and Parade scopes. Any other combination of sampling modalities would produce a different pattern on the scopes and disparate quality metrics.

Call me naive or over-simplistic, but I don't think there's any 'special sauce' going on here, at least not on straight 'pass-through'. Exactly what sampling algorithms were applied prior to 15.1.1, I'm not sure, but that's how it is now. Whether there is justification in calling that change 'improved 422 chroma sampling' I guess remains a point of conjecture.

Do we (who have been avidly following this issue) even know what we are hoping for ? If it is lossless pass-through of Uncompressed 422, I don't think that's going to happen, unless BMD see fit to incorporate a 'by-pass' path akin to that in Vegas where YUV422 is passed through to Sony YUV 'untouched' when no transforms are applied - and I think that very unlikely also. Rohit made that clear earlier:

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

Which is not exactly encouraging (for Windows-based users) given the observed behaviour with DNxHR_444.

So where does this leave 'we who have been hoping for better quality chroma sampling' ?

My two cents again, it is not better quality that solves generation loss but additional option for user to bypass spatial filtering on chroma upsampling. Then it is up to user to decide if he needs filtering or not. Usually it is desirable, but in some cases it is not.

My two cents again, it is not better quality that solves generation loss but additional option for user to bypass spatial filtering on chroma upsampling. Then it is up to user to decide if he needs filtering or not. Usually it is desirable, but in some cases it is not.

Absolutely.

Well, I've been conducting some further tests with the 'Checkers-422' clip (or rather the v210 version I recreated from Natron). This time I've been testing 10-bit 422 <->444 inter-conversions in AVISynth+ using filters that allow specification of the applied chroma sampling modality (Nearest Neighbor/Point, Bilinear, Bicubic etc).

I found that when the 'Checkers-422' clip is converted to 10-bit YUV444 and back to 10-bit YUV422, using Bilinear chroma sampling in both conversions, and the output (p210, planar 10bit YUV422) is encoded to v210 with VDub2, the encode (in mov format) imported in Resolve produces an identical scope profile to that obtained when the 'Checkers-422' clip is 'pass-through' exported to v210.

But more than that - when quality metrics are applied to compare the two encodes both the SSIM and PSNR report lossless for the Luma and UV chroma. Achieving a 'lossless' SSIM score (1.000000) is one thing, achieving a maximum PSNR score as well (i.e. Inf = Infinity) says that it is really lossless = no difference between the two Also, when I checked the file sizes, the two encodes were within a few bytes of being 'byte identical'. That is way beyond coincidence.

I've gone on to test (using the same methodology) over 5 round-trip cycles i.e cycling 'Checkers-422' (v210 version) through Resolve and through 10bit YUV444 (with Bilinear resampling) in AVISynth+

Lo and behold the scope profiles in the two series are identical. Applying quality metrics to compare the matched v210 encodes, there is a marginal drop in the PSNR chroma scores (Y:inf, U:73.208, V:76.106 after 5 cycles) but the SSIM scores report 'lossless' (1.000000 for Y, U, and V) over the 5 cycles. Pretty amazing.

No doubt in my mind - it's straightforward Bilinear chroma upsampling to 444 and Bilinear sub-sampling back to 422.

Testing, in like manner, the 'Checkers-444' clip 'pass-through' exported to v210, looks like that's bilinear sub-sampling also.

Exactly what sampling algorithms were applied prior to 15.1.1, I'm not sure,

Can't come up with any chroma up-sampling/sub-sampling combination that replicates the behavior prior to 15.1.1 and I'm not inclined to roll back to 15.1 (again) to see if I can piece it together.

......here are the scope profiles obtained with the Checker-422 clip exported to v210 and then over a three further 'pass-through' export cycles.

Resolve 15.1



Resolve 15.1.1

Can't come up with any chroma up-sampling/sub-sampling combination that replicates the behavior prior to 15.1.1 and I'm not inclined to roll back to 15.1 (again) to see if I can piece it together.

But, of course, I couldn't resist rolling back to 15.1 to try figure this out. I also installed the Premiere Pro Trial to compare alongside Resolve and Vegas 16.

Using the same methodology as described above, I conducted an exhaustive series of tests with the Checker-444 and 422 clips. It would be too much to present all of the results, including the AVISynth chroma resampling 'simulations' and comparative quality metric data. And I'm sure folks are sick of looking at these Checker patterns. So I've compiled an all-in-one summary of the Resolve scope profiles that best illustrate the conclusions I've been able to reach.

The Vegas 16 tests were carried out in 32bit float mode. In the Premiere Pro tests, rendering was set for Maximum Depth.



After opening the link, click on (+) cursor to enlarge. Right click image to copy/save as

My conclusion is that from Resolve 15.1.1 the 444 > 422 re-sampling modality changed to Bilinear, and now behaves in the same way as Premiere Pro. And by that I'm referring to pass-though at the same resolution. All three programs (Resolve, Premiere, Vegas) give the option to choose the interpolation modality that is applied in scaling operations, whether expressed in terms of 'Best', 'Good' etc or by name. Resolve, for example, gives four 'resizer' options - Sharper (default), Bilinear, Bicubic and Smoother, but changing the interpolator does not affect the outcome of these pass-through tests. What exactly is 'Sharper' by the way ?

Prior to 15.1.1 (that is, ending 15.1) the 444 > 422 re-sampling behavior was akin to that in Vegas Pro. The scope profile of the 'pass-through' v210 (Sony 10bit YUV) export of the imported Checker-422 clip is that same as that of the Checker-444 > v210 export. The Resolve 15.1 export of the Checker-444 clip also produces the same profile. In fact, when quality metrics were applied to examine the difference between the two, the SSIM scored lossless for Luma and UV chroma. The PSNR score was a bit lower, but I think it's reasonable to conclude that the re-sampling modality is the same.

The Resolve 15.1 and Vegas v210 exports of the Checker-422 differ because, in Vegas, 422 is passed through 'untouched' when no transforms are applied. As we know (or assume), in Resolve, all imports are up-sampled to 444, so the 15.1 v210 export profile represents the net outcome of up-sampling (likely Bilinear) and sub-sampling - in essence, it is that net outcome that had been the cause for concern and one that was deemed 'sub-optimal'.

Just what that 444 > 422 re-sampling modality was (and is in Vegas) though remains a mystery (to me at least). I could not replicate the outcome with any of the chroma re-sampler combinations tested in the AVIsynth+ 'simulations', including Nearest Neighbor (Point), Bilinear, Bicubic, Lanczos, Spline 16 and 36, Gauss and Sinc. The VirtualDub2 developer thought Bilinear when I passed him the Checker-444 >v210 pattern, but the AVISynth Bilinear upsample/sub-sample simulation matches (perfectly) with the behavior in Resolve 15.1.1/15.1.2 and Premiere Pro.

All I can say is that the same modality must have been applied when the Checkers-422 clip was exported from Natron, so it can't be so obscure. Does anyone know what that is, for sure ? Is it maybe the product of additional spatial filtering ?

Edit: If it's of interest, here's information about the native chroma resample filter implementations in AVISynth(+):

http://avisynth.nl/index.php/Resampling
http://avisynth.nl/index.php/Convert#Chroma_resample

Anyhow, I think I've made some worthwhile progress on this, if only for my own interest. Finding that the 'improved' 4:2:2 sub-sampling' behavior implemented in 15.1.1 is the same as that in Premiere is reassuring.

BTW - I have also been doing some tests with 'real world' material and the metric analyses appear to back this up. I'm now in the process of scrutinizing the images.

BMD (Rohit), I've put alot of work and thought into this. Give me a sign if I'm right about 15.1.1 at least - for yes, for no, you're way off.

Incidentally, referring back to Jean Claude's earlier post:

https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=79163&start=50#p447010

When I checked to see how Fusion 9 (stable free version, 9.02 build 5, 20 Dec 2017) handles 422 sub-sampling, it gives these results:



Looks like it uses the same sub-sampling modality that Resolve (15.1) did before. Up-sampling v210 to r210 is fine, but there's definitely something weird going on there with the red channel in the v210 exports. ? Bug

Brought it up on the Fusion forum:

https://forum.blackmagicdesign.com/viewtopic.php?f=22&t=80939#p448267