erazortt

Thanks I will look into the MSupers. Concerning the chroma shift, the pixel format is YV12(=YUV420P8) in this example. However the behaviour is all the same for all bit depths....

You must use real footage. I think there might be a connection to motion vectors.

No, the chroma location itself cannot be the issue, because the problem is not consistent. Some patches are being shited other are not shifted. I uploaded a zip containing the...

I also made an animated image switching between B and C to show the issue: [image](https://drive.google.com/file/d/1p019Hm54wD2l67bghzQIR8HnlES-e-Kq/view?usp=share_link) There it can be seen that not all of the pixels are shifted. Especially...

Well, chroma is always low saturated. But that is actually irrelevant because the motion vectors are calculated on the image, not for specific planes. MAnalze can take chroma into consideration...

So MAnalyse returns only one set of vectors for all planes. There are no separate vectors for each plane. So independently how it came to determining the motion vectors, this...

There is no such thing as "motion vectors for the chroma planes". To make it more understandable, you can make MAnalyse disregard the chroma planes completly, and produce the motion...

Yes, pel=4 helps. It not exectly as good as 444 with pel=2 but its getting there. However I do not want to process the luma also at that precission. So...

~Wait I am not sure about that theory. Please take a look a the new version D:~ ~d=org ssd = d.MSuper(pel=2) bvd = ssc.MAnalyse(isb=true, delta=1, blksize=16, overlap=8, search=4) fvd =...

~In my version D, even msuper is 420. The only thing being 444 is the clip d itself: d=d.MDegrain1(ssc, bvd, fvd, thSAD=thSAD1).Subtitle("D") And it still produces the same result as...