Thread: VirtualDub2
View Single Post
Old 17th October 2018, 04:41   #676  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,345
Quote:
Originally Posted by WorBry View Post
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
poisondeathray is offline   Reply With Quote