VHS capturing - luma/chroma crosstalk? What do you think?

[Slennox]

Those x264 settings are pretty extreme. Be aware that you may not be able to play the resulting video on anything but a computer.

Do you say that because the CRF 16? What settings would be a good compromise between high quality and usability? I don't mind much about the final encode size.

I suspect "P.B." stands for "play back". Ie, it's a PAL deck that can play NTSC tapes as PAL60 -- pretty much standard for PAL VHS decks. Since you have 576 line caps your tape is probably PAL. But I suspect video was converted from an NTSC tape before being broadcast as PAL. I doubt the capture device or software converted PAL60 signal to a PAL cap, though that's not impossible. Definitely try some other tapes and see if some are free of the blended fields.

This is a cap from a PAL movie. How do you look for blended fields? Do you use a particular Avisynth script for that?

All you need, IMO, and at least for the very sake of minimalism, is a clean ordinay RCA/composite deck that can produce sharp detail and has good tracking, which can be expected from a good branded, simple, black, dedicated (no combo), 4-head, HiFi unit, along with a line based external TBC.

That's pretty much the setup I have right now. My deck is a consumer model but from a reputable brand and it is in good condition. I've invested on a decent capture device with TBC. I would like to keep that setup if possible and concentrate efforts on software restoration.

Be careful with long term storage and lossless codecs. Will Huffyuv, UT Video Codec, or Lagarith still be available on the computers we'll be using 30 years from now?

I'll need to pick one anyway as uncompressed is not suitable for an archiving use case. I was going with MPEG-2 I-frame from my capture vendor but we've seen it has some issues. UT Video Codec, which is available for OS X and seems it's currently being developed, would be a good option?

[jagabo]

Those x264 settings are pretty extreme. Be aware that you may not be able to play the resulting video on anything but a computer.

Do you say that because the CRF 16?

No, it's the reference frames and consecutive b-frames. I don't have the cap here any more but if I remember correctly the settings you used looked like x264's veryslow preset. That gives you 16 reference frames and 8 consecutive b-frames. Few players can deal with that. Sticking with the slow preset (ref=5, bframes=3), maybe adding subme=10 (from the veryslow preset), will give you almost the same quality but video that will play on most players that can play HD h.264 video.

This is a cap from a PAL movie. How do you look for blended fields? Do you use a particular Avisynth script for that?

That video has no field blending. So we know the problem with the racing footage was the particular recording. The best way to check for field blending is to use Bob() in AviSynth. If you see frames that look like double exposures when there is motion you have field blending. Bob() creates aliasing artifacts and a picture that bounces up and down, hence the name, but just ignore that for this test. Field blending is very common with PAL/NTSC conversions of analog sources.

...UT Video Codec, which is available for OS X and seems it's currently being developed, would be a good option?

Huffyuv might be a better choice because it has a long track record. But it doesn't compress quite as well as some of the others, and there are a few variants that are incompatible with the original. I'd stick with version 2.1.1.

[Brad]

I've invested on a decent capture device with TBC.

Sadly, I'm seeing residual timebase errors in that racing sample. Specifically, lines in the logo wiggle horizontally. Does Matrox claim that the MXO2 Mini contains TBC functionality in its advertising? A quick search only found some forum posts.

[jagabo]

Some horizontal jitter is expected even after a line TBC. The TBC can't tell why a line is shorter or longer than normal. All it can do it stretch or compress it to the right length. For example a line may be short because the video head was spinning at the right frame rate for half the line then too fast for the second half. If the line is then stretched evenly the left half will be too long and the right side will still be too short and only line up at the far right.

I noticed in The Mask capture there is ghosting a few pixels to the right in image. I came up with a function to reduce that:

function DeGhost(clip source, int shift, float strength)
{
   ygain = int(strength*256.0) - 256
   shifted = source.Crop(0,0, -shift, -0).AddBorders(shift, 0, 0, 0)
   shifted = shifted.ColorYUV(gain_y=ygain, cont_u=ygain, cont_v=ygain)
   Overlay(source, shifted, mode="Subtract")
   ColorYUV(gain_y=256+ygain, cont_u=256+ygain, cont_v=256+ygain)
}

ffVideoSource("capture-3.mov") 
ConvertToYV12()
Crop(8,60,-8,-72)
DeGhost(last, 6, 0.15)  # reduce ghosting
vInverse()  # clean up a little residual comb artifacts
Spline36Resize(width/2, height)  # reduce dot crawl artifacts
TemporalDegrain(SAD1=100, SAD2=75, sigma=4)  # reduce noise
MergeChroma(Santiag(), aWarpSharp(depth=20))  # antialias luma, sharpen chroma
TurnRight().nnedi3(dh=true).TurnLeft()  # restore width
Sharpen(0.2, 0.0)  # a little horizontal sharpen

Sample attached.

[Slennox]

Sample attached.

Nice job!

Huffyuv might be a better choice because it has a long track record. But it doesn't compress quite as well as some of the others, and there are a few variants that are incompatible with the original. I'd stick with version 2.1.1.

I've contacted Matrox to send me a custom build of MXO2 driver with AVFoundation support (they send it upon request but it is not officialy published). I think it would then be possible to capture using ffmpeg which has the only Huffyuv implementatoion available for OS X that I am aware of.

The codec I've choosen so far for capturing and archiving is Apple ProRes 422. Although it's not mathematically lossless, it's widely used for that purpouse on Mac's workflows. And it's the only one (apart from the uncompressed master) that doesn't seem to have the blue tinge problem you pointed out on that frame:


Uncompressed (left) / Matrox MPEG-2 I-frame (right)




Uncompressed




UtVideo Pro YUV422 10bit




Apple ProRes 422




I also tested Premiere's default capture codec and settings, but it looks like it uses Apple Video (fourcc RPZA) which is a lossy codec and the resulting video seems a little burned... or not? I'm not sure whether this one looks better or have more realistic color.




I will come back with a final ProRes sample of the capture and the AviSynth script for restoration with all the suggestions you've made so far.


Thank you!

[Slennox]

Does Matrox claim that the MXO2 Mini contains TBC functionality in its advertising? A quick search only found some forum posts.

A post from Matrox support staff... I was to purchase a Blackmagic capture device but when I told the retailer that I wanted it basically to digitize VHS tapes, he strongly advise me to go for the Matrox.

[jagabo]

Prores 4:2:2 should be pretty good on Apple systems. UT 4:2:2 shouldn't have had that problem. Maybe something before or after caused the blended chroma?

I highly recommend you use some other video for testing. All the field blending in that race footage makes it very hard to see exactly what's going on. Some other live native PAL sports event would be better.

[Slennox]

I captured another sample from a spanish grand prix that should have been produced in native PAL. I've looked at it with:

QTInput("Espana.mov")
Bob()

And I couldn't determine whether any blended fields exists.

As for the first samples we've been looking into so far, I've done a final cap sample encoded with ProRes, and edited it with this script trying to include the suggestions you've made so far:

SetMTMode(5,8)
QTInput("Brasil_1.mov")
SetMtMode(2)
ConvertToYV12()
Spline36resize(360,576)
AssumeTFF()
QTGMC(Preset="Slow", EdiThreads=8)
Dehalo_alpha(rx=2, ry=2, lowsens=10, highsens=90)
Sharpen(0.3, 0.2)
MergeChroma(last, aWarpSharp(depth=20))
Spline36resize(720,576)
Sharpen(0.2)
ChromaShift(l=-2)
Crop(12,2,-10,-10) .AddBorders(12,2,10,10)

I'm pretty satisfied with the result. I couldn't see any ghosting effects which are usually related to NTSC->PAL converted sources. Anyway I tried the suggested solution of using SRestore():

SetMTMode(5,8)
QTInput("Brasil_1.mov")
SetMtMode(2)
ConvertToYV12()
Spline36resize(360,576)
AssumeTFF()
QTGMC(Preset="Slow", EdiThreads=8)
SRestore()
Dehalo_alpha(rx=2, ry=2, lowsens=10, highsens=90)
Sharpen(0.3, 0.2)
MergeChroma(last, aWarpSharp(depth=20))
Spline36resize(720,576)
Sharpen(0.2)
ChromaShift(l=-2)
Crop(12,2,-10,-10) .AddBorders(12,2,10,10)

However you can obviously see the motion isn't as smooth as the previous sample (50 fps vs 23.976 fps). Indeed I couldn't clearly see the field blending problem on that sample either...

So in the end I think I'm going to stick with the first script. Cropping is fine also I think (4:3 aspect ratio is preserved).

[jagabo]

I made some minor change to the first script:

ffVideoSource("Brasil_1.mov") 
ConvertToYV12(interlaced=true)
Spline36resize(360,576)
AssumeTFF()
QTGMC(Preset="Slow", EdiThreads=8)
Dehalo_alpha(rx=2, ry=3, lowsens=20, highsens=80)
Sharpen(0.3, 0.2)
MergeChroma(last, aWarpSharp(depth=20))
TurnLeft().nnedi3(dh=true).TurnRight()
Sharpen(0.2)
ChromaShift(l=-2, c=-2)
Crop(12,2,-10,-10) .AddBorders(12,2,10,10)

Since your source is now properly interlaced ConvertToYV12() should be ConvertToYV12(interlaced=true).

I changed lowsens and highsens in dehalo_alpha a bit. That removes a little more of the halos but it's a tough balancing act. Play around with the values and see what you think.

Instead of Spline36Resize I used nnedi3 to upscale the frame. That's a little sharper without introducing aliasing artifacts. nnedi3 was designed to scale vertically, not horizontally, hence the 90 degree rotations before and after.

I added c=-2 to ChromaShift. That shifts the chroma to the left in addition to up. That better aligns the chroma with the luma. Having more colored object to work with made it clear that was needed.

You can probably get rid of the remaining dot crawl artifacts, like in the orange Marlboro sign, by blurring more and using masks to apply that blurring to only highly saturated areas. I don't know if it's worth it.

Oh, your "after" video is encoded with the wrong aspect ratio. The SAR should be 12:11, not 1:1.

The SRestore script is in appropriate for this type of video. And you saw not blending artifacts because there are none.

[Slennox]

I made some minor change to the first script:

ffVideoSource("Brasil_1.mov") 
ConvertToYV12(interlaced=true)
Spline36resize(360,576)
AssumeTFF()
QTGMC(Preset="Slow", EdiThreads=8)
Dehalo_alpha(rx=2, ry=3, lowsens=20, highsens=80)
Sharpen(0.3, 0.2)
MergeChroma(last, aWarpSharp(depth=20))
TurnLeft().nnedi3(dh=true).TurnRight()
Sharpen(0.2)
ChromaShift(l=-2, c=-2)
Crop(12,2,-10,-10) .AddBorders(12,2,10,10)

Thank you! Indeed it does look better.

You can probably get rid of the remaining dot crawl artifacts, like in the orange Marlboro sign, by blurring more and using masks to apply that blurring to only highly saturated areas. I don't know if it's worth it.

I'll try but I'm kinda overwhelmed with all different dot crawler filters that exist. Do you have any particular suggestion for these samples and the highly saturated colors?

Oh, your "after" video is encoded with the wrong aspect ratio. The SAR should be 12:11, not 1:1.

Hmm, really? It plays well on VLC. I encoded it using yuv4mpegpipe between wine's ffmpeg frameserver and OS X's native x264:

wine ~/.wine/drive_c/Program\ Files/ffmpeg/bin/ffmpeg.exe -i restoration.avs -f yuv4mpegpipe - | x264 --stdin y4m --preset slow --subme=10 --crf 16 -o Brasil_6.m4v -

Am I missing any config switches for x264?

[jagabo]

You can probably get rid of the remaining dot crawl artifacts, like in the orange Marlboro sign, by blurring more and using masks to apply that blurring to only highly saturated areas

I'll try but I'm kinda overwhelmed

It's a little awkward because of the reduce sized frames:

#################################################
# Absolute value of chroma after UtoY() or VtoY()
#################################################

function cABS(clip c)
{
    Overlay(c.ColorYUV(off_y=-128), c.Invert().ColorYUV(off_y=-127), mode="add")
}

#################################################
# Saturation, 0-220, same size as luma
#################################################

function cSat(clip c)
{
    Overlay(c.UtoY().cABS(), c.VtoY().cABS(), mode="add").LanczosResize(c.width, c.height)
}

#################################################

ffVideoSource("D:\Downloads\Brasil_1.mov") 
AssumeTFF()
ConvertToYV12(interlaced=true)
lowres = Spline36resize(304,576).QTGMC().Spline36Resize(360,576)
Spline36resize(360,576).QTGMC(Preset="Slow", EdiThreads=4)
Overlay(last, lowres, mask=last.cSat().ColorYUV(off_y=-32).ColorYUV(gain_y=500))
Dehalo_alpha(rx=2, ry=3, lowsens=20, highsens=80)
Sharpen(0.3, 0.2)
MergeChroma(last, aWarpSharp(depth=20))
TurnLeft().nnedi3(dh=true).TurnRight()
Sharpen(0.2)
ChromaShift(l=-2, c=-2)
Crop(12,2,-10,-10) .AddBorders(12,2,10,10)

Here I make a lower resolution version of the video with the dot crawl artifacts are completely blurred away, then make a mask of the color saturation of the video. In the mask dark areas represent low saturation, bright area's high saturation. Then the two videos are overlaid using the mask. Highly saturated areas get the lower resolution image, low saturation areas get the higher resolution image. You can play with the intermediate size of the lower resolution image. I used 304 here because that is where the artifacts completely disappeared. At 320 they were still slightly visible. The smaller you make it the less detail there will be in the saturated areas. You can also play with the contrast adjustments of the mask to fine tune it.

Oh, your "after" video is encoded with the wrong aspect ratio. The SAR should be 12:11, not 1:1.

Hmm, really? It plays well on VLC. I encoded it using yuv4mpegpipe between wine's ffmpeg frameserver and OS X's native x264:

wine ~/.wine/drive_c/Program\ Files/ffmpeg/bin/ffmpeg.exe -i restoration.avs -f yuv4mpegpipe - | x264 --stdin y4m --preset slow --subme=10 --crf 16 -o Brasil_6.m4v -

Am I missing any config switches for x264?

An ITU capture of 4:3 analog PAL video has a sar of 12:11. You can add that to the x264 options as "--sar 12:11". Look at the front wheel of the car in frame 150 of the encoded video where it's almost perfectly perpendicular to the camera. In your square pixel version it is slightly taller than it is wide. After correcting for SAR it is round.

[jagabo]

Regarding the other dot crawl filters, some work with NTSC video where the dot pattern repeats every two frames, but not well with PAL which has a four frame pattern. Some are too destructive when turned up enough to eliminate the dot crawl. The ones that work work best on still parts of the picture, not on moving parts. That's a problem with VHS where most parts of the picture have horizontal time base jitter. Since it's pretty easy to (nearly) eliminate VHS dot crawl by downsizing then upsizing that's usually the way to go.

[Slennox]

The mask works pretty well and does its job. The Marlboro sign looks squeaky clean after applying it:


Before:


After:



It's awesome what Avisynth can do in the hands of an skilled editor! Jagabo, thank you for all your help and thorough explanations on every step. Now I have all the workflow in place to batch encode my tapes

[jagabo]

The artifacts in the orange Marlboro sign have been cleaned up but there is also a little more blurring in the Skol sign and Shell logo in the background. A fair tradeoff in my opinion.

[PuzZLeR]

All you need, IMO, and at least for the very sake of minimalism, is a clean ordinay RCA/composite deck that can produce sharp detail and has good tracking, which can be expected from a good branded, simple, black, dedicated (no combo), 4-head, HiFi unit, along with a line based external TBC.

That's pretty much the setup I have right now. My deck is a consumer model but from a reputable brand and it is in good condition. I've invested on a decent capture device with TBC. I would like to keep that setup if possible and concentrate efforts on software restoration.

Now I have all the workflow in place to batch encode my tapes

I agree you're on your way to get the most out of your captures.

Although not quite relevant to the topic here, but since you're into AviSynth and software solutions and have some ambition for this project, I can recommend just one more thing that will add much more value to your results, which is multiple captures and median methods.

https://forum.videohelp.com/threads/362361-Median%28%29-plugin-for-AviSynth

Now for sure your final results will be those which years from now you'll look back on and say that you really did all you could to make them as best as possible.

Of course, using lossless is always the most recommended, for capturing, processing and archiving, but pseudo lossless can have other advantages to some workflows. Just as simply as I don't think DV is a bad format for this project either.

But I would apply the resizing trick to remove crosstalk before anything else, including median methods, and including any subsequent processing/encoding thereafter. Crosstalk removal is always first on my agenda after capture.

[Slennox]

All you need, IMO, and at least for the very sake of minimalism, is a clean ordinay RCA/composite deck that can produce sharp detail and has good tracking, which can be expected from a good branded, simple, black, dedicated (no combo), 4-head, HiFi unit, along with a line based external TBC.

That's pretty much the setup I have right now. My deck is a consumer model but from a reputable brand and it is in good condition. I've invested on a decent capture device with TBC. I would like to keep that setup if possible and concentrate efforts on software restoration.

Now I have all the workflow in place to batch encode my tapes

I agree you're on your way to get the most out of your captures.

Although not quite relevant to the topic here, but since you're into AviSynth and software solutions and have some ambition for this project, I can recommend just one more thing that will add much more value to your results, which is multiple captures and median methods.

https://forum.videohelp.com/threads/362361-Median%28%29-plugin-for-AviSynth

Now for sure your final results will be those which years from now you'll look back on and say that you really did all you could to make them as best as possible.

Of course, using lossless is always the most recommended, for capturing, processing and archiving, but pseudo lossless can have other advantages to some workflows. Just as simply as I don't think DV is a bad format for this project either.

But I would apply the resizing trick to remove crosstalk before anything else, including median methods, and including any subsequent processing/encoding thereafter. Crosstalk removal is always first on my agenda after capture.

Thank you. Definetely I'll have a look at it. A quick question though, is this method applicable only if the captures are uncompressed? I wonder whether using a particular codec for compress the cap (like Apple ProRes on my workflow) would make you capping the same encoded video each time? At least, I would expect this method to work better with uncompressed caps?

[PuzZLeR]

Thank you. Definetely I'll have a look at it. A quick question though, is this method applicable only if the captures are uncompressed? I wonder whether using a particular codec for compress the cap (like Apple ProRes on my workflow) would make you capping the same encoded video each time? At least, I would expect this method to work better with uncompressed caps?

Yes, you can use pretty much any lossy or lossless, compressed or uncompressed, codec/format for methods here, but the two key advantages of using lossless are: highest quality on capture, and zero to minimal degradation on processing.

So, having said that, you will capture the most out of your projects to begin with using lossless. Maybe Apple ProRes can do well here too, but I doubt that, at least in theory, it can capture more detail than a lossless codec would.

As well, every time you do any processing with lossless, you will have much more flexibility than you would with a lossy codec. Assuming you stay within the same colorspace, you can process a lossless codec again, and again, and again, without penalty - the only changes will be those of any filters you add.

If you use lossy, you will add artifacts with every generation of processing ON TOP of anything else. This can turn out quite ugly if you plan to do several layers of work, such as crosstalk removal, noise removal, median methods, etc, even if your workflow had good stuff. That's just the way it is working with lossy.

Then again, I doubt a format like Apple ProRes would reveal as many artifacts as, say, MPEG-2 would per encode, but it is indeed lossy, and you would lose something, at least minimally, every time you re-encode it.

Note: "Uncompressed" is not synonymous with "lossless" - they can be different, and either can be lossy or lossless depending on context. However, what I was comparing here is lossless vs. lossy.

[Slennox]

I'm having some problems with chroma shifting in another cap. I think it is in poorer condition than the first footage we have discussed during this thread (30 sec sample)...

Applying the restoration script you can see a white line artifact at the bottom of the "1" sign



If I don't adjust any chroma shifting I get a better result, however some white dots can still be seen where they should be blue in the "BENNETON RENAULT" banner.



Is possible to correct them through ChromaShift? Or it would be better to not apply the filter in this cap?

#################################################
# Absolute value of chroma after UtoY() or VtoY()
#################################################

function cABS(clip c)
{
    Overlay(c.ColorYUV(off_y=-128), c.Invert().ColorYUV(off_y=-127), mode="add")
}

#################################################
# Saturation, 0-220, same size as luma
#################################################

function cSat(clip c)
{
    Overlay(c.UtoY().cABS(), c.VtoY().cABS(), mode="add").LanczosResize(c.width, c.height)
}

#################################################

QTInput("Argentina.mov")
AssumeTFF()
ConvertToYV12(interlaced=true)
lowres = Spline36resize(304,576).QTGMC().Spline36Resize(360,576)
Spline36resize(360,576).QTGMC(Preset="Slow")
Overlay(last, lowres, mask=last.cSat().ColorYUV(off_y=-32).ColorYUV(gain_y=500))
Dehalo_alpha(rx=2, ry=3, lowsens=20, highsens=80)
Sharpen(0.3, 0.2)
MergeChroma(last, aWarpSharp(depth=20))
TurnLeft().nnedi3(dh=true).TurnRight()
Sharpen(0.2)
ChromaShift(l=-2, c=-2)
Crop(18,2,-24,-10) .AddBorders(18,2,24,10)

[jagabo]

Just change to ChromaShift(c=-2). That will shift chroma left by two pixels, but not up or down (l=-2 shifted it up by two lines). You'll still have a little bit of white in the blue text. The inherently low chroma resolution, along with the sharpening with aWarpSharp is responsible for some of the white. You can play with less or more sharpening.

Here you can see the Y (left), U (top right) and V (bottom right) channels (as greyscale) of the YV12 image after only QTGMC() (contrast of the chroma channels was enhanced 2x for visibility here):



The blue text isn't readable in the chroma channels so the colors won't line up well with the luma. So you won't get perfect blue letters on a grey background.

[Slennox]

Thanks, it seems it's the best you can do with this particular source. You've seen that huge static band on the right part of the video, I had to crop a lot of pixels. Just curiosity, do you know if it is related to the tape condition (20 years old) or the poorer signal that was recorded that time?

[PuzZLeR]

Thanks, it seems it's the best you can do with this particular source. You've seen that huge static band on the right part of the video, I had to crop a lot of pixels. Just curiosity, do you know if it is related to the tape condition (20 years old) or the poorer signal that was recorded that time?

Maybe we can do better. You have ghosting it seems. I have a formula with some of my captures, let's see if it works for you. (Need to try it first. Have to take off this moment, but will try it shortly with some of my methods and report back.)

As for the static band, it may even be the way your VCR plays that tape. Yes, the more aged and warped your tape is, the more likely it will be worse. Other VCRs may play it with less of that problem there, but it may shift elsewhere. There are threads on head-switching noise you can search, but they mostly discuss such a problem at the bottom of the screen, and I personally didn't find them much help anyway.

I'd just crop it off (and resize if need be). It's not that bad, and a part of VHS capture IMO.

[Slennox]

Maybe we can do better. You have ghosting it seems. I have a formula with some of my captures, let's see if it works for you. (Need to try it first. Have to take off this moment, but will try it shortly with some of my methods and report back.)

Yes, indeed it is. You can see the shadows near the big yellow banners and even in the TV station logo:



I've looked again on the first cap and they can also be seen on that one, though are less noticiable.

[PuzZLeR]

I played around with some of your samples, and the "Argentina" one is quite messed up with this ghosting (very ugly). Still working on it with exorcist (not perfect, but de-ghosting in general isn't either). But it needs several layers, but I doubt it's saveable without major sacrifice elsewhere (like brightness, colors, sharpness, etc.).

I can keep playing with is a bit more (no promises though), but I'd like to ask since there's a difference in your samples. The "Espana" sample wasn't so bad, and the "capture-3" with Mask was much more workable, certainly better than the "Argentina" one. Are you capturing under different settings (computer, VCR, software, TBC, etc)? Then again, it could be the tape itself that is different quality in all of them. At any rate, it's always better at the capture level in a case like this if this problem can be removed.

Here's what I did so far with "capture-3": Using VirtualDub (after removing crosstalk and upsizing) using exorcist (3 pixels right, brighten 25%) and HSV (saturation 75%, value 20%) after to get the values similar to the original.

Ghosting:


Less Ghosting - look at the man on the right's nose:

[Slennox]

I can keep playing with is a bit more (no promises though), but I'd like to ask since there's a difference in your samples. The "Espana" sample wasn't so bad, and the "capture-3" with Mask was much more workable, certainly better than the "Argentina" one. Are you capturing under different settings (computer, VCR, software, TBC, etc)? Then again, it could be the tape itself that is different quality in all of them. At any rate, it's always better at the capture level in a case like this if this problem can be removed.

All the samples are captured with the same settings and setup. The only differences should be the recorded signals and the tape brands. The Argentine Grand Prix ("Argentina" cap) has one of the poorest signal quality of my tape collection. It was recorded +20 years ago and I think it was originally produced as a PAL-M and then was converted to PAL-B by the TV broadcaster (spanish Tele5). Spanish Grand Prix ("Espana" cap) however was produced in the same PAL-B standard that was later broadcasted. The signal quality was much better.


These caps are the best I can get of my tapes. The only thing to try is an S-Video capture instead of the composite ones you see here. But at the end of the day all the restoration we can do has to be achieved by software tools.

[Slennox]

As the ghosting from the "Argentina" cap is quite similar to the "The Mask" cap (few pixels to the right), I've applied the DeGhost script provided by jagabo, getting slightly better results (left is original, right after applying the filter):



What do you think?

function DeGhost(clip source, int shift, float strength)
{
   ygain = int(strength*256.0) - 256
   shifted = source.Crop(0,0, -shift, -0).AddBorders(shift, 0, 0, 0)
   shifted = shifted.ColorYUV(gain_y=ygain, cont_u=ygain, cont_v=ygain)
   Overlay(source, shifted, mode="Subtract")
   ColorYUV(gain_y=256+ygain, cont_u=256+ygain, cont_v=256+ygain)
}

DeGhost(last, 6, 0.15)  # reduce ghosting

[Slennox]

My best bet. Indeed DeGhost() seems to clean up the ghosting effect quite reasonably but generates more noise. However it can be gently removed by TemporalDegrain(). Good combination. I don't notice much loss of sharpeness either.

#################################################
# Absolute value of chroma after UtoY() or VtoY()
#################################################

function cABS(clip c)
{
    Overlay(c.ColorYUV(off_y=-128), c.Invert().ColorYUV(off_y=-127), mode="add")
}

#################################################
# Saturation, 0-220, same size as luma
#################################################

function cSat(clip c)
{
    Overlay(c.UtoY().cABS(), c.VtoY().cABS(), mode="add").LanczosResize(c.width, c.height)
}

#################################################

function DeGhost(clip source, int shift, float strength)
{
   ygain = int(strength*256.0) - 256
   shifted = source.Crop(0,0, -shift, -0).AddBorders(shift, 0, 0, 0)
   shifted = shifted.ColorYUV(gain_y=ygain, cont_u=ygain, cont_v=ygain)
   Overlay(source, shifted, mode="Subtract")
   ColorYUV(gain_y=256+ygain, cont_u=256+ygain, cont_v=256+ygain)
}

QTInput("Argentina.mov")
AssumeTFF()
ConvertToYV12(interlaced=true)
DeGhost(last, 6, 0.15)
lowres = Spline36resize(304,576).QTGMC().Spline36Resize(360,576)
Spline36resize(360,576).QTGMC(Preset="Slow")
Overlay(last, lowres, mask=last.cSat().ColorYUV(off_y=-32).ColorYUV(gain_y=500))
TemporalDegrain(SAD1=100, SAD2=75, sigma=4)
Dehalo_alpha(rx=2, ry=3, lowsens=20, highsens=80)
Sharpen(0.3, 0.2)
MergeChroma(last, aWarpSharp(depth=20))
TurnLeft().nnedi3(dh=true).TurnRight()
Sharpen(0.2)
ChromaShift(c=-2)
Crop(18,2,-24,-10) .AddBorders(18,2,24,10)

[jagabo]

The ghost in the Argentina video is shifted 7 pixels to the right. Unfortunately, the DeGhost() script doesn't work with odd values and YV12 video. One workaround is to convert the video to YV24, DeGhost, then convert back to YV12:

ConvertToYV24()
DeGhost(last, 7, 0.15)
ColorYUV(gain_y=5)
ConvertToYV12()

The DeGhost() script darkens the picture by a bit so I compensated with ColorYUV(). I would put this sequence just before the cCrop() and AddBorders().

This leaves a secondary ghost about 11 pixels to the right in some of the text overlays. Following the First DeGhost() with DeGhost(last, 11, 0.05) cleans that up but damages some of the main picture. I'd just live with those minor secondary ghosts.

[Slennox]

Thanks. I didn't notice the darker picture after DeGhost(). As for TemporalDegrain(), I think I'll give it a try with the Argentina source and see the result. Where should you put the filter on the script? Is it better to apply it when you have the half width frame? I don't know if it's just me but I think DeGhost() generated a few noise/grain. Should be better to apply it after DeGhost() then?

QTInput("Argentina.mov")
AssumeTFF()
ConvertToYV12(interlaced=true)
lowres = Spline36resize(304,576).QTGMC().Spline36Resize(360,576)
Spline36resize(360,576).QTGMC(Preset="Slow")
Overlay(last, lowres, mask=last.cSat().ColorYUV(off_y=-32).ColorYUV(gain_y=500))
TemporalDegrain(SAD1=100, SAD2=75, sigma=4)
Dehalo_alpha(rx=2, ry=3, lowsens=20, highsens=80)
Sharpen(0.3, 0.2)
MergeChroma(last, aWarpSharp(depth=20))
TurnLeft().nnedi3(dh=true).TurnRight()
Sharpen(0.2)
ChromaShift(c=-2)
ConvertToYV24()
DeGhost(last, 7, 0.15)
ColorYUV(gain_y=5)
ConvertToYV12()
Crop(18,2,-24,-10) .AddBorders(18,2,24,10)

QTInput("Argentina.mov")
AssumeTFF()
ConvertToYV12(interlaced=true)
lowres = Spline36resize(304,576).QTGMC().Spline36Resize(360,576)
Spline36resize(360,576).QTGMC(Preset="Slow")
Overlay(last, lowres, mask=last.cSat().ColorYUV(off_y=-32).ColorYUV(gain_y=500))
Dehalo_alpha(rx=2, ry=3, lowsens=20, highsens=80)
Sharpen(0.3, 0.2)
MergeChroma(last, aWarpSharp(depth=20))
TurnLeft().nnedi3(dh=true).TurnRight()
Sharpen(0.2)
ChromaShift(c=-2)
ConvertToYV24()
DeGhost(last, 7, 0.15)
ColorYUV(gain_y=5)
ConvertToYV12()
TemporalDegrain(SAD1=100, SAD2=75, sigma=4)
Crop(18,2,-24,-10) .AddBorders(18,2,24,10)

[jagabo]

TemporalDegrain while the image is half width will be faster. It's hard to say which will work better. Try both. Personally, I don't mind a little noise, and dislike the smeary artifacts you can get with temporal NR. At least try using as weak NR settings as you can get away with.

[PuzZLeR]

All the samples are captured with the same settings and setup. The only differences should be the recorded signals and the tape brands. The Argentine Grand Prix ("Argentina" cap) has one of the poorest signal quality of my tape collection. It was recorded +20 years ago and I think it was originally produced as a PAL-M and then was converted to PAL-B by the TV broadcaster (spanish Tele5). Spanish Grand Prix ("Espana" cap) however was produced in the same PAL-B standard that was later broadcasted. The signal quality was much better.

Of course, it would have been better to target the reason in your workflow as it would have been easier to figure out a solution, but yeah, I'm not surprised it was your source. It could be the broadcast, or the tape itself, or a combination. It could have been the quality of the recording of the original VCR too, or it could have been one of the recording speeds it used as well.

And these diverse levels of ghosting have happened to me as well. I had a capture to do for a friend, which was recorded from a very old, heavy, 80s top-loading deck - in LP to make things worse - very sharp but serious ghosting here, and many layers of it. It would have been nice to try a capture with the original VCR, but it was long dead, but I don't think it would have helped since the ghosting felt rather "hard coded" into the recording. The exact same ghosting showed up in every VCR I've tried this tape on.

I did manage to upgrade it to "decency". I could have handled a few more layers but it started compromising quality to more serious levels, so left it at that. (I was actually a bit lucky the recording had some sharpness to sacrifice - don't tell my friend... )

These caps are the best I can get of my tapes. The only thing to try is an S-Video capture instead of the composite ones you see here. But at the end of the day all the restoration we can do has to be achieved by software tools.

I have had no better or worse success with an S-video deck with this. I have a professional JVC which seems to make improvements, but all it does, upon closer inspection, is blur so much - it's actually removing detail, not just the ghosting.

But, like I said, the ghosting may be at this point an "actual detail" in your recording, and a good VCR will capture it faithfully, so yeah, it may be the best you can do with this problem, and leave it to software solutions after. Some are workable, like the Mask example before, but others, like the Argentina example, will be very taxing and compromising. The choice of solutions on the latter can also be very subjective.

I guess, <sigh>, this is indeed something we have to accept with VHS captures. (I hate VHS. I always did.)

I personally like the VirtualDub filters for this as I mentioned, easy to use and quite effective, but if the AviSynth ones work for you, it's all good. But keep in mind I used the HSV filter along with the removal of ghosting, as Jagabo used ColorYUV(). I see you've already noticed that you will need to compensate for lost values in brightness, contrast, saturation, and noise in your case, etc, as a result of de-ghosting.

(For some reason, every time I use colorYUV() I have to do further compensating to remove the extra "blue" it yields...)