How to remove color bleed VHS?

[Opticum]

i got a soccer match VHS (PAL ) Video here from the mid 90th, i suspect its at least a 2nd gen copy. (the original tape has been lost)

i am trying to remove the color bleeding. After using QTGMC and filters the color bleeding gets worse (not blaming qtgmc but maybe some of the other filters)

does anyone know a good way to remove this?

attached is a short sample.

[newpball]

Could you add the same sample before you applied processing as well? Also could you mention exactly which filters (and options) you used?

[jagabo]

I haven't seen the video yet but try something like: MergeChroma(aWarpSharp(depth=30)) You may have to shift it too: ChromaShift(c=-4).

[johnmeyer]

I'm waiting for the large video file to download. I'll know more after I look. However, for chroma shift caused by copying tapes (i.e., 2nd generation), this code often works:

Vshift=0 # 2 lines per bobbed-field per tape generation (PAL); original=2; copy=4 etc
Hshift=0 # determine experimentally 
fields=source.SeparateFields() # separate by fields
fields=MergeChroma(fields,crop(fields,Hshift,Vshift,0,0).addborders(0,0,Hshift,Vshift))
Weave(fields)

Hshift=2 and Vshift=2 are good starting points.

This does a good job removing the color halos that you get in tape copies.

[Opticum]

thanks for the suggestions, i will try those out first thing tomorrow morning.

the sample i uploaded is the raw video unprocessed. i can add a proccessed one, but right now i am just trying to fix the color shift because qtgmc is allready working a fine job on the video aside the color.

thanks again!

[LMotlow]

the sample i uploaded is the raw video unprocessed.

Thanks for the sample, but I disagree. It is processed. it's been converted to uncompressed RGB24. Also, if your original sample is YUV, the converted version is 4 times bigger than it should be. No wonder it takes so long to download.

[jagabo]

Try something like this:

AviSource("sample1.avi") 
AssumeTFF()
ConvertToYV12(interlaced=true)

luma=last
SeparateFields()
BicubicResize(width/2,height*2)
aWarpSharp(depth=30)
BicubicResize(width*2,height/2)
Weave()
MergeChroma(luma,last)

[johnmeyer]

Your upload is just fine for illustrating the problem. In the future, when using DV video, you can simply cut it using VirtualDub by selected the "Direct Stream Copy" option. That doesn't touch a pixel, and you don't get the 5-6 times increase in size going to uncompressed.

There are halos on both sides of the video, so my code doesn't work. Try jagabo's code instead. I tried to use it, but for some reason, even when I load the aWarpSharp DLL explicitly, I get an error saying that there is "no function named aWarpSharp." I am using AVISynth 2.60, so perhaps that's the problem.

[poisondeathray]

@johnmeyer - the new awarpsharp is called by " awarpsharp2() " ; the dll's are from 2009,2012 (20090619, 20120328). The original awarpsharp is called by " awarpsharp() " (without the "2"), the .dll is dated 20030203 . awarpsharp2 was written to prevent the green edge borders with the orginal awarpsharp, but some older functions still rely on the older version

[jagabo]

I have more problems with aWarpSharp2() (crash and die) than with aWarpSharp() under AviSynth 2.6 MT. That's why I usually stick with the old one. Both work with this script though.

[themaster1]

I like jogabo solution a lot, that'll help me with a couple of videos. It seems the result is optimal if you deinterlace first
I had to correct the syntax to make it work... as follow:
a=last
luma=last
BicubicResize(width/2,height*2)
aWarpSharp(depth=30)
BicubicResize(width*2,height/2)
MergeChroma(a,last)

[jagabo]

I had to correct the syntax to make it work... as follow:

Oops, I changed the name of the original video in one place but forgot to change the other. I think it's fixed now.

Regarding the scaling I did: VHS has much less chroma resolution horizontally than vertically. So after separating the fields I reduced the horizontal frame size (but still much more resolution than VHS chroma) and increased the vertical frame size so that aWarpSharp() would work better horizontally without thinning too much vertically. After aWarpSharp the fields is scaled back to their original size before weaving them back together.

<edit>
How about this:

AviSource("D:\Downloads\sample1.avi") 
AssumeTFF()
ConvertToYV12(interlaced=true)
luma=last
SeparateFields()
BicubicResize(width/3,height*2)
aWarpSharp2(depth=25)
Spline64Resize(width*3,height/2)
Weave()
MergeChroma(luma,last)


Subtitle("Processed")
Interleave(luma,last)
Tweak(sat=2.0)
Bob()
SelectEvery(4,0,2,1,3)
StackHorizontal(last, StackVertical(UtoY(), VtoY()))
return(last)

The lower part of the script is just to visualize the results.

[johnmeyer]

@johnmeyer - the new awarpsharp is called by " awarpsharp2() " ; the dll's are from 2009,2012 (20090619, 20120328). The original awarpsharp is called by " awarpsharp() " (without the "2"), the .dll is dated 20030203 . awarpsharp2 was written to prevent the green edge borders with the orginal awarpsharp, but some older functions still rely on the older version

Thanks. Calling awarpsharp2 did the trick.

[Opticum]

thank you for your input. i just tried jagabo's script and the result is amazing! thank you so much!!

the Processed / unprocossed change really shows the power of this.

[Opticum]

i may have one more problem, more related to virtualdub i fear. When i open my soccer video in virtualdub and vlc there is quite a difference in color levels / saturation especially when looking at people faces:

[LMotlow]

i may have one more problem, more related to virtualdub i fear. When i open my soccer video in virtualdub and vlc there is quite a difference in color levels / saturation especially when looking at people faces:


[Attachment 29184 - Click to enlarge]

It has less to do with VirtualDub and mostly to do with your source. The way different media players treat colors and levels is another story altoget5her, but the color in both images looks dopey. Mainly, your black levels are too high and chroma in the images as well as your original sample is seriously clipped at the bright end. The guys in both images look orange: too much bright red and green, and blue has serious problems. Because of clipping, dynamic range and color correction in brights and skin tones is impaired. Your original, images don't look oversaturated, they look off-color and washed out.

You have to correct in YUV first. Your earlier avi sample appears to have been captured as too bright.

With high IRE and chroma clipping, there's not much one can do. In the "correction" below you can see that even if you bring black levels down and try to lighten brights, the bright end lacks brilliance and looks washed and skin tones won't ever look quite right:

[Opticum]

ok thanks for the input again! i will try to make the most of it. Maybe someone magically finds those original master tapes again (which i highly doubt)

[LMotlow]

Could try a sample from your original AVI's YUV colorspace, saved in VirtualDub with "direct stream copy" to avoid RGB conversion and clipping. It's possible to rescue a lot of detail using the original, not a converted clip.

[jagabo]

VirtualDub always uses a rec.601 matrix when converting YUV sources to RGB (usually correct for SD, wrong for HD). Most media players will use whatever matrix is flagged in the video, or in the absence of a flag will use rec.601 for SD, rec.709 for HD (both of which are usually correct). Media players may also perform other processing either explicitly with their own settings or implicitly via the graphics card's settings.

[Opticum]

here is a direct stream copy sample. Thanks alot for the technical input, really appreciate it.

[LMotlow]

Thanks, opticum, a more workable sample. Not much work for skin tones here, but same basic problems of high gamma and black levels, and brights blown out. It appears to be on the original tape dupe (no surprise), but also looks as if brightened more during capture (again, no surprise). So, making corrections won't relieve clipping loss entirely. But level corrections can rescue some bright details, preserve more dynamic range, and give the images more perception of depth if conversion to RGB display is managed more carefully by fixing things first in YUV. Dozens of ways to do it -- basically lower gamma (black levels) and try to keep bright colors from smashing against the right-hand side of histograms.

I used the code below but there could be many variations:

ColorYUV(cont_y=20,off_y=-5)
ColorYUV(cont_v=-20,gain_v=-5,cont_u=-15)
Levels(12, 0.95, 255, 16, 250)
Tweak(sat=1.2,coring=false)

Also cropped off excess borders and got closer to real 4:3 DAR by keeping frame size to 704x576 for SD PAL. BTW, sample2 has far less levels and chroma damage than the earlier avi or the images posted in #15. Luma in this one is within 16-235 margins, but chroma somehow got shifted upward and shoots past 235.