MDegrainX introduces a chroma shift in 420 sources.

[erazortt]

See the 3 screenshots link, you will need to zoom in and be able switch back and forth between the images to actually see that shift of about half a pixel.
The shift is only in B. C matches A (apart from being degrained).
I have checked with many files and all versions going back to 2.7.29 and even some before it. There is always a shift in B.
The screenshot names match the following 3 scripts.

A:
DGSource("file").UToY()

B:

DGSource("file")
clip=last
srch_super = clip.MSuper(pel=2)
bvec1  = srch_super.MAnalyse(isb=true,  delta=1, blksize=16, overlap=8, search = 4)
fvec1  = srch_super.MAnalyse(isb=false, delta=1, blksize=16, overlap=8, search = 4)
thSAD1 = int(9*8*8)
o_super = clip.MSuper(pel=2, levels=1)
clip.MDegrain1(o_super, bvec1, fvec1, thSAD=thSAD1)
UToY()

C:

DGSource("file")
z_ConvertFormat(pixel_type="YUV444P8",resample_filter="spline36",resample_filter_uv="spline36",use_props=3)
clip=last
srch_super = clip.MSuper(pel=2)
bvec1  = srch_super.MAnalyse(isb=true,  delta=1, blksize=16, overlap=8, search = 4)
fvec1  = srch_super.MAnalyse(isb=false, delta=1, blksize=16, overlap=8, search = 4)
thSAD1 = int(9*8*8)
o_super = clip.MSuper(pel=2, levels=1)
clip.MDegrain1(o_super, bvec1, fvec1, thSAD=thSAD1)
z_ConvertFormat(pixel_type="YUV420P8",resample_filter="spline36",resample_filter_uv="spline36",use_props=4)
UToY()

[DTL2020]

In B and C looks you not need to make 2 MSuper if you not modify 'clip' (like pre-filtering for MAnalyse). Your first MSuper already create all levels required for MAnalyse and MDegrain. So you can save memory and get better performance if use only 1 MSuper() call. For pel=2 each MSuper create refined 4 planes even for levels=1. It takes memory transfer, CPU cycles and thrashes CPU caches.

About shift - it good to report pixel format (type) for B (returned by DGSource()). As I see in C you convert something to 4:4:4 8bit before mvtools. So you can place Info() after DGSource() and add pixel format for B.

B may be simple
DGSource("file")
super = MSuper(pel=2)
bvec1 = super.MAnalyse(isb=true, delta=1, blksize=16, overlap=8, search = 4)
fvec1 = super.MAnalyse(isb=false, delta=1, blksize=16, overlap=8, search = 4)
thSAD1 = int(988)
MDegrain1(super, bvec1, fvec1, thSAD=thSAD1)
UToY()

And C too.

[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. I have also tried YUV420P16.
The conversion in B is just convert it to 444 for the degrainig and then convert back to 420.

[Dogway]

I don't see a shift in a controlled test:

ColorBarsHD(width=1280, height=720, pixel_type="YV24")
ConverttoYUV420()
a=ExtractU()

clip=last
srch_super = clip.MSuper(pel=2)
bvec1  = srch_super.MAnalyse(isb=true,  delta=1, blksize=16, overlap=8, search = 4)
fvec1  = srch_super.MAnalyse(isb=false, delta=1, blksize=16, overlap=8, search = 4)
thSAD1 = int(9*8*8)
o_super = clip.MSuper(pel=2, levels=1)
clip.MDegrain1(o_super, bvec1, fvec1, thSAD=thSAD1)
ExtractU()
ex_makediff(a, metric="none", aug=true, dif=true, show=3) or Subtract(a) or Compare(a) or Expr(last,a,"x y - abs 50 *")

It might happen as a product of edge denoising by design but probably not as a bug (?)

[erazortt]

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

[pinterf]

The processing assumes that the chroma location is "center".
If your original clip has "left" chroma location, then try converting the input 420 clip to "center" before processing, and back to "left" after that. I wonder you are seeing the same difference.

[erazortt]

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 pervious images, but also zoomed in versions, a 2 sec snipped of the clip and an avs script. The images are taken at frame 24. link

[erazortt]

I also made an animated image switching between B and C to show the issue: image
There it can be seen that not all of the pixels are shifted. Especially the upper left part is shifted while the rest is not.

[Dogway]

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

Maybe because the shifted edges are low local contrast areas, the static parts are either motion static, or failed match blocking or high contrast...

Maybe you can try increasing saturation (contrast for the chroma channels) to see if the effect diminishes to discard this theory.

[DTL2020]

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

Do disabling of 'truemotion' preset at MAnalyse change or fix it ? As I see from some documentation it is enabled by default.

[erazortt]

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 but its output is only one set of vectors for all three planes. You could even disable the chroma completely for MAnalyze, and the resulting vectors could still be applied to MDegrain and the outcome is the same. So the morion vectors themselves cannot explain a shift, between luma and chroma, because it’s the same vectors which get applied. But perhaps however it’s the way MDgrain applies the motion vectors to subsampled chromas which is somehow imprecise.

…

Am 01.03.2023 um 23:21 schrieb Dogway ***@***.***>:  No, the chroma location itself cannot be the issue, because the problem is not consistent. Some patches are being shited other are not shifted. Maybe because the shifted edges are low local contrast areas, the static parts are either motion static, or failed match blocking or high contrast... Maybe you can try increasing saturation (contrast for the chroma channels) to see if the effect diminishes to discard this theory. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[erazortt]

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 can never explain a shit between planes, since it’s the same vectors that are supposed to be applied on all planes.

…

Am 02.03.2023 um 00:36 schrieb DTL2020 ***@***.***>:  No, the chroma location itself cannot be the issue, because the problem is not consistent. Some patches are being shited other are not shifted. Do disabling of 'truemotion' preset at MAnalyse change or fix it ? As I see from some documentation it is enabled by default. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[Dogway]

I understand now the premise. So the motion vectors for the chroma planes are not being shifted according to chroma location right? Maybe DTL2020 or pinterf have an idea where to look for this in source.

To test this since you can't disable luma motion vectors, try to set scaleCSAD to 2, so it takes more weight from chroma, if it looks better then it's a MV misalignment.

[erazortt]

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 vectors just based on the luma by setting chroma=false for MAnalyse.
The resulting motion vectors can still be applied by MDegrain to all planes which the produces the same shift of the chroma planes relative to the luma plane.

So these scripts produce basically the same issue:

---

b=org
ssb = b.MSuper(pel=2)
bvb = ssb.Greyscale().MAnalyse(isb=true, delta=1, blksize=16, overlap=8, search=4)
fvb = ssb.Greyscale().MAnalyse(isb=false, delta=1, blksize=16, overlap=8, search=4)
thSAD1 = int(576)
b=b.MDegrain1(ssb, bvb, fvb, thSAD=thSAD1).Subtitle("B")

---

and

---

b=org
ssb = b.MSuper(pel=2)
bvb = ssb.MAnalyse(isb=true, delta=1, blksize=16, overlap=8, search=4, chroma=false)
fvb = ssb.MAnalyse(isb=false, delta=1, blksize=16, overlap=8, search=4, chroma=false)
thSAD1 = int(576)
b=b.MDegrain1(ssb, bvb, fvb, thSAD=thSAD1).Subtitle("B")

---

you can even remove the chroma component completely for the motion vector generation:

---

b=org
ssb = b.MSuper(pel=2)
bvb = ssb.Greyscale().MAnalyse(isb=true, delta=1, blksize=16, overlap=8, search=4, chroma=false)
fvb = ssb.Greyscale().MAnalyse(isb=false, delta=1, blksize=16, overlap=8, search=4, chroma=false)
thSAD1 = int(576)
b=b.MDegrain1(ssb, bvb, fvb, thSAD=thSAD1).Subtitle("B")

---

All three versions will procude the same chroma shift after MDrgrain.

[pinterf]

UV degrain processes all motion vectors, and it's simply using a /2 (for 4:2:0) to get the source X,Y position on the chroma plane. This means that if you encounter left shift you must notice an upwards shift as well.
https://github.com/pinterf/mvtools/blob/mvtools-pfmod/Sources/MVDegrain3.cpp#L1548

btw, what happens without overlap?

[DTL2020]

"So MAnalyse returns only one set of vectors for all planes. "

Yes. But when you process in 4:2:0 the UV planes are twice smaller and the quantization error in placement is 2 times larger for blocks of UV planes.
Position precision of MVs in 4:2:0 with pel=2 is 0.5 sample in Y plane and only 1 sample in UV plane (after decompressing to 4:4:4 RGB for display). So when GetBlock()/GetPointer() return sub-shifted block (with motion-compensated coordinate for MDegrain) it have different precisions for Y and UV in 4:2:0 and may cause this effect.
MVs data is really integer (not float) - so with pel=2 it is +1bit for Y plane and 0.5 sample precision. For UV half sized planes it is 2 samples with pel=1 and +1bit is only full-sample precision.
Try to see if setting pel=4 will help any. It will allow to have 1/2 sample precision at UV planes in 4:2:0.

So may be the sub-sample shifting with your pel=2 used can not track UV shift as precise as in 4:4:4 mode. It may be some version of the source of the issue.

The idea about truemotion - it cause large fields of coherent MVs so the quantization error is also equal for this area and you see it as global patch shift. If truemotion is false the MVs are more random and error is more random and less visible. Just an idea.