ok so after a couple more tests, I cannot get the same colors as the source with those small yellow/orange flowers. Magicyuv, cineform, uncompressed, other players, MediaExpress: all the same. it's not an encoding issue because encoding the source directly with the same settings output proper colors
so unless im doing something wrong in Vdub (doubt it), i guess it's because the decklink mini 4k cannot do Bt2020 even if they say it can on the box. smh

I doubt you can capture 1:1, If that's what your trying to do. I havn't been following the thread.

I know in my capture settings, there a box that says Colorspace: 2020.

I also have a device that gives me exact readout going into capture so I know extactly what the colorspace is when it hits the capture box.

There products are very misleading at times, or give you bad information.

Rep: Out product included HDR from the very start(From Launch).

Driver Update: Product now includes HDR support(About year+ after the Product was Launched).

If I haven't loaded VirtualDub for a while (I think it used to do this on pre-fork versions too) it takes a while to load - 5-10 seconds. After that, subsequent instances load up instantly. Any idea why this is? Is it enumerating something?

Yes, as already mentioned: the "Windows DLL Cache" and "Prefetch" folders as possible factors, and even delayed DLL unloading (keeping a DLL resident in the RAM even after it could be unloaded, until RAM is required to be swapped).

I've been involved in some studies over on the BlackMagic Design DaVinci Resolve forum. There was concern about the degree of chroma loss seen when Uncompressed 10bit 422 sources are serially 'passed through' (i.e. no transforms applied) Resolve, which pointed to sub-optimal YUV422 chroma-sub-sampling. As you probably know Resolve uses it's own proprietary 'DaVinci YRGB' color-science for processing - the inner workings (algorithms) of which are not publicly known and one can only speculate based on observed behavior.

One of the forum members uploaded a couple of test clips that have proved very useful in gaining more insight. The 1080p clips (created with Natron) have a two-color checkerboard pattern. The size of the checkerboard blocks are exactly 5px wide/high, such that every second border will be placed in the middle of a color sub-sampled region. Here's a more complete explanation and the download links for the test clips - one ('Checker-444') in ProRes_4444 format and the other ('Checker'-422) in ProRes HQ (10bit 422) format:

What has come to light is that when the Checker-422 (v210) is cycled through v410 in VDub2 (by which I mean encoding to v410 and then reconverting the export to v210) the pattern of results (as revealed by the Resolve Histogram and Parade scope profiles) is identical to that obtained when the 'Checker-422' clip is serially 'passed-through' Resolve.

@WorBry - if you have serially changing each generation , it suggests some interpolation going on, probably bicubic. If you have blocky sharp color borders and preserved same up/down over each generation, it can only be nearest neighbor . You can verify this by controlling the algorithm in say vapoursynth or avisynth or ffmpeg , export either v210 or v410 and check . You can check the RGB conversion algorithm this way too

"desireable" is debatable and depends on the situation - what looks good on a test pattern might not look so good on real material .

OK, thanks both. So, if I understand correctly, its 'nearest neighbour' (point) up-sampling and it's the convolution averaged chroma sub-sampling that brings about the separation of the R/B and G channel plots on the Resolve Parade scope, which manifests as blur ?

Up-sampled in that example to r210, because Resolve wont import v410

I wonder then how Vegas Pro sub-samples 444 to 422 to achieve the outcome it does ?

Quote:

Originally Posted by poisondeathray

"desireable" is debatable and depends on the situation - what looks good on a test pattern might not look so good on real material .

Which is fair point. Case in point - I freaked out when I saw the pattern of results produced when the 'original' Checker-444 (ProRes_4444) was exported to DNxHR_444 (10bit) in Resolve, and thought something must be wrong.

Only to discover that DNxHR_444 encoded with FFMPEG and DNxHD_444 exported from Avid Media Composer behaved the same way.

It was only after reading that DNxHR_444 encoding intentionally adds a small amount of blur to minimize aliasing/blocking that I came to terms with what looked like degradation on the scopes and checker pattern - reasonable explanation being the repeating 5x5 pixel checker pattern amplifies the blur. Still have some doubts that there is not more too it though.

OK, thanks both. So, if I understand correctly, its 'nearest neighbour' (point) up-sampling and it's the convolution averaged chroma sub-sampling that brings about the separation of the R/B and G channel plots on the Resolve Parade scope, which manifests as blur ?

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.

I haven't looked at those samples yet, but I'll take a closer look later

Quote:

Case in point - I freaked out when I saw the pattern of results produced when the 'original' Checker-444 (ProRes_4444) was exported to DNxHR_444 (10bit) in Resolve, and thought something must be wrong.

Only to discover that DNxHR_444 encoded with FFMPEG and DNxHD_444 exported from Avid Media Composer behaved the same way.

No . There something wrong with those last screenshots. Looks like a serious DNxHR issue somewhere in the workflow . Looks like adding some noise or dither . That' s not normal

I was saying that it's the convolution averaged 444>422 sub-sampling that introduces some blur.

Quote:

Originally Posted by poisondeathray

…..It's just duplicating the chroma samples when you go 422=>444 , dropping the exact same samples when you go 444=>422

Which is how it appears on the scopes and checker pattern in the above example where I converted the 'Checker-422' clip to r210 with VDub2.

Quote:

Originally Posted by poisondeathray

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.

Based on the above test series and Shekh's interpretation of the conversion modalities it appears that that is also how Resolve up-samples 422 to 444 on import. Nothing I can do to change that. Resolve processes in 32-bit float, as I'm sure you know.

Quote:

Originally Posted by poisondeathray

No .There something wrong with those last screenshots. Looks like a serious DNxHR issue somewhere in the workflow . Looks like adding some noise or dither . That' s not normal

Which is disconcerting to say the least. I had been thinking about switching to DNxHR_444 as a (Resolve) export intermediate but this has turned me off again. Unfortunately ProRes is not an export option in Resolve on Windows.

If the issue is somewhere in the workflow, then where ? Those blotchy checker board patterns also occur when FFMPEG and Media Composer DNxHR/DNxHD 444 exports (mov and MXF) of the Checker-444 clip (ProRes_4444 and v410 versions) are imported into VDub2, so it can't be something happening in Resolve.

Ahh you're starting with 444 and the pattern is 5x5 ... sorry I should have read more closely. I'll look into it more

But you also have to look at how you are upsampling and converting to RGB for the preview - that could be doing something too . There could be other issues with chroma center interpretation which can add additional issues. Ideally you would separate all the processes out

The DNxHR/DNxHD "noise" would make it unsuable IMO . That's a separate issue that needs investigating . For example, how does the avid export look when re-imported back into avid (using avid's own decoder) ? Since ffmpeg/avid/resolve all look bad in resolve, it might be as simple as a bad decoder version in resolve

And maybe this should be split off, because shekh answered the vdub2 specific questions

Ahh you're starting with 444 and the pattern is 5x5 ... sorry I should have read more closely. I'll look into it more

In those 'round tripping' tests I was starting with 10bit 422 ('Checkers-422'), up-sampling to 10bit 444 and then down-sampling to 10bit 422 again. In the Resolve 'round-trip' series the 'Checkers-422' import was simply 'passed through' to v210 export. In Resolve, all imports get passed to 32-bit float 'DaVinci YRGB'. There is no Uncompressed YUV422 'by-pass' as occurs in Vegas Pro with 'Sony YUV' export when no transforms are applied.

In the DNxHR/DNxHD_444 export tests I was using the 'Checkers-444' clip as the input source.

Quote:

Originally Posted by poisondeathray

The DNxHR/DNxHD "noise" would make it unsuable IMO . That's a separate issue that needs investigating . For example, how does the avid export look when re-imported back into avid (using avid's own decoder) ?

Unfortunately I didn't look at that when I ran the Media Composer trial - since uninstalled.

Quote:

Originally Posted by poisondeathray

Since ffmpeg/avid/resolve all look bad in resolve, it might be as simple as a bad decoder version in resolve

I wondered about that too. But like I said, when the ffmpeg/avid/resolve DNxHR exports were loaded into VDub2 to examine the checker patterns (copy/pasted source frame to Paint.net to produce the magnified, cropped checker images) they all looked 'bad' also:

Quote:

Originally Posted by poisondeathray

And maybe this should be split off, because shekh answered the vdub2 specific questions

Well it relates to VDub2 too if it is a wider decode issue, but if you wish maybe split-off to 'New and Alternative Codecs' section.

Regarding previewing results - it matters how it's interpreted (in terms of chroma location), that makes a big difference , and the way it's upsampled to RGB , or the way you zoom for the screenshot (what algorithm). You can get completely different results appearance wise with the same video in a different application or player

Within resolve itself , if you were only to look at the histogram, you can get fewer spikes using nearest neighbor, chromaloc left

Does it "look" better ? It really depends on what is used, and how it's interpreted, or what scenario you're using it for

I'll try to figure out what sony is using. I only have vegas 13, but it produced the same v210 as in your screenshot

That DNxHR result is completely unexpected and unacceptable. Something is up

And I'm getting similar results with Adobe's DNxHR/DNxHD implementation , also on encoding/decoding. It looks like some sort of DCT compression issues.