CrossHatching in Red Colours

[Alwyn]

Hello all, could somebody point me in the right direction, using AVISynth, to remove these orange waves across the guy's body.

When I deinterlaced it with QTGMC (basic mode) I got bad crosshatching in the red/orange portions and the across-wave was still there.

Thanks!

[Alwyn]

False alarm, caused by my ES-15.

[Sharc]

Note that although Y,Cb,Cr ("YUV)" are all withing their valid range, the conversion to RGB produces out-of-gamut values which get clipped (clipped reds). Reducing the saturation would help.
Also, there seems to be some chroma->luma crosstalk which creates "ants". Check the quality (screening, shielding) of the S-video cabling.

[Alwyn]

Thanks Sharc, I tried my EH-57, same; my EZ-48 (integrated Diga) no interference, and VCR only, no interference.

I then paused the video on a red/orange spot and the waves continued, slowed down, stopped, and then started again going in the opposite direction, so I think your cabling shielding (or lack thereof) is right. I have S-video cables everywhere here, going to the ES-15 then to a DVK, then to digitiser. Will try swapping them around.

Colour comment noted; do I need to adjust the saturation down before capture or can I do it in post?

[Skiller]

Color subcarrier leaks into luma channel. Possible cause, as mentioned by Sharc, insufficient shielding of cables or damaged connectors/jacks (bent pins) somewhere along the path of the signal. S-Video is rather prone to this.

[Sharc]

Colour comment noted; do I need to adjust the saturation down before capture or can I do it in post?

It should be doable in post in YUV colorspace, provided that no conversion YUV->RGB is in the workflow for doing the correction. Some editors and filters make an immediate conversion to RGB unfortunately. For 8bit integer the damage is there. As only the red component gets clipped it's not a too serious issue IMO. Depends on other scenes as well. Too ambitious legalization can make the picture look dull or flat (as opposed to vivid).
Some editors (NLEs) convert to float RGB so these should not clip and you should be safe with the conversion.

[_Al_]

In vapoursynth, but should be the same or similar in Avisynth, there is Tweak function that uses expressions for YUV:
import adjust
clip = adjust.Tweak(clip, sat=0.75, coring=False)

or using just expressions manually for this case, for U or V channels:
U = (U - 128) * scale) + 128; V = (V - 128) * scale) + 128
so:
scale=0.75
clip = clip.std.Expr(expr=["x", f"x 128 - {scale} * 128 +", f"x 128 - {scale} * 128 +"])

[_Al_]

I just post some visuals, sorry for polluting , but visuals help,
posting illegal RGB's below 5 and above 245,
note, after de-saturation, there is plenty of really low RGB values as well

[Alwyn]

Thanks all, I ended up lowering the saturation in the proc amp and it came out OK for my purposes.

[Alwyn]

Thanks everyone, I dropped the saturation in VDub and it looks OK for my purposes but will certainly keep Tweak in mind.

[Sharc]

Thanks everyone, I dropped the saturation in VDub and it looks OK for my purposes .....

If I am not mistaken Vdub and many of its filters convert to RGB as a first step AFAIK, so the clipping damage is already there, irreversibly, and lowering the saturation in post does not cure the problem. Better use Avisynth or some other tool which does the filtering in YUV colorspace.

Independent of the color issue, replace your S-video cables by decent ones to prevent crawling ants. Your future captures will benefit.
See
https://forum.videohelp.com/threads/403635-Panasonic-DVD-recorder-passthrough-settings...12#post2714801

[Sharc]

Thanks all, I ended up lowering the saturation in the proc amp and it came out OK for my purposes.

OK

[Alwyn]

Sharc, just to clarify (my posts beforehand are a jumble), I lowered the saturation then recaptured.