Straighten Curved VHS grabs

[Schnoodledorfer]

I am trying to convert some old VHS tapes to digital format. One thing that I've run into is that the captured image is curved, no doubt thanks to the VHS deck. I'd rather not buy another one.

I have tried to find an avisynth tool to take care of this, but haven't had much luck. Actually, I was able to get VCMohan's Perspective (http://avisynth.org/vcmohan/Perspective/Perspective.html) plugin to fix it in three passes, but that's painfully slow.

. . . . Original: can you see me?Fixed:
http://mynetimages.com/1a210ad08a_th.jpg (http://mynetimages.com/viewimage/1a210ad08a) . . . http://mynetimages.com/1c2a45ccf3_th.jpg (http://mynetimages.com/viewimage/1c2a45ccf3)
(click for full size)

I could accomplish the same thing by cropping the top half into two bands and applying it to them individually, but I'm hoping for a better way. Both Perspective and GIMP's Curve Bend tool also slightly widen the image. I don't know why, but I couldn't find a way (other than resizing) around that.

I think VCMohan's Reform (http://avisynth.org/vcmohan/Reform/Reform.html) plugin would also work, but I ran into a bug that I've PMed him about just now. I would break the top half into two strips and skew them in the same way as with the Perspective tool. From what I can tell, it works much faster (assuming you avoid the bug).

His DeJitter (http://avisynth.org/vcmohan/DeJitter/DeJitter.htm) plugin has some promise for the lower part of the image, but it won't work at the top because I don't have a left edge. It also get's confused if a dark object is at the left edge. It doesn't seem to look at the right edge at all and can make it worse. If it did, it would be useful for the additional problems here:
http://mynetimages.com/4939d6851e_th.jpg (http://mynetimages.com/viewimage/4939d6851e)

Actually, that's the same frame as above, but it includes both fields. I intend to just throw away the lower field because about 80-90% of the noise originates there. It's so bad that I doubt the information there could be useful for denoising. (The other two pics were of the top field expanded to 480 just so it would look right.) I'll eventually size to 352x240 anyway.

So, any other ideas? It seems a little odd that only one plugin developer would have developed the only tools that might be used to straighten a video taken from a VCR. There are tools like DePan that are categorized as stabilization tools, but as far as I can tell, it and similar plugins are just for camera shake and similar problems. Maybe I missed something though.

I'd also be interested if there is a good reason to not immediately dispose of the lower noisy field.

@VCMohan: Followup to bug report: Is there really a good reason to limit the minimum size of sides of the quadrilateral in the first place?

[2Bdecided]

http://www.questronix.com.au/info/info_tbc.htm

[Mounir]

Post a video sample

[juhok]

http://www.questronix.com.au/info/info_tbc.htmLots of misinformation about external "TBC"'s ability to correct this kind of time base error. I haven't tried all of the devices listed there, but the ones I have do nothing to fix the visible time base errors. They only make the signal more stable and easier to AD.

[johnmeyer]

Lots of misinformation about external "TBC"'s ability to correct this kind of time base error. I haven't tried all of the devices listed there, but the ones I have do nothing to fix the visible time base errors. They only make the signal more stable and easier to AD.I would have said the same thing until a year ago, when my VCR died and I had to get a new one. I got a NIB older VCR that not only has built-in Firewire output (so I can directly encode my old videos), but also has a built-in TBC.

I thought this TBC would only help with "flagging," but it turns out that it makes a huge difference on how individual scan lines align, resulting in far less tearing and "teeth" on vertical lines in the video.

I still have a very nice semi-pro Panasonic PVS-4990 that supposedly has a TBC built in, and this operated in exactly the manner you describe and as a result was pretty much useless.

[juhok]

Not sure if we disagree :). Built-in TBC's do work and correct visual timebase errors (sure, there can also be bad apples or broken ones). External TBC's are often just framesyncs which do little to the visual image, they stabilize the signal itself. IIRC for the external TBC to be able to correct the visual errors you'd need unaltered DOC signal from the drum directly to the external TBC. This DOC stuff exists in professional realm, not in consumer/prosumer gear (I've seen one Panasonic FS-100 with a mod to output DOC but that's a hack).

If new VCR is not an option the screenshots look like they could be somewhat corrected by adjusting physical tape guides (needs professional service and might cost the same as new VCR..). Can't say for sure tho, only done that kind of adjusting for Video8/Hi8 decks but the principle is the same and corrected similar error. That is not replacement for built-in TBC so aligment and TBC should be used together for best results (good new VCR might not need any fidling).

I might've misused some jargon here, it's been a while since last time thinking about TBC stuff.

edit: So this is how it works for me:

VCR -> Capture card = Framedrops and timebase errors
VCR + framesync -> Capture card = Works great but has timebase errors.
VCR + built-in TBC -> Capture card = Framedrops but no timebase errors
VCR + built-in TBC + framesync = Works great and no timebase errors.

My claim: most if not all devices in the questronix list are framesyncs.

[2Bdecided]

Sorry, I wasn't suggesting questronix, or any other. I was just going to post "TBC" - but thought I'd post a link that talked about TBCs instead.

My experience is the same as yours - the VBCs built into decent consumer VCRs (and some DV camcorders with analogue inputs, and a few DVD recorders) are excellent at removing time base wobbles - while external devices often are not - they don't act with a fact enough time constant IMO.

Cheers,
David.

[Ghitulescu]

The external TBCs stabilize the signal. If the signal is already "stabilised" by the electronics inside a VCR, an external TBC cannot do much, as already suggested, since it has almost nothing to correct. The TBC doesn't interpret the signal, just makes sure the timing is standardized. Besides, if this error has already been compounded into the video (the tape is the second generation) there's nothing to be done.

Not that I had a huge experience with VHS, but I haven't seen this "flagging" type of error, and I've seen lots of damaged tapes. I heard about it only related to NTSC format. Is it a NTSC-only artefact? Or maybe is the NTSC format more prone to flagging than PAL (due perhaps of its higher speed)? Or is there a patented method to obtain such an artefact on a tape?

[johnmeyer]

I cannot answer the question about NTSC vs. PAL flagging. However, flagging is an extremely common problem in NTSC VHS tapes recorded in 6-hour mode.

[2Bdecided]

Besides, if this error has already been compounded into the video (the tape is the second generation) there's nothing to be done.I read this in a lot of places. Yet any small wobbles (typically H-sync errors) from the first tape will be copied faithfully (with appropriate wobbly syncs!) onto the second tape - and it'll all still be there for the TBC to fix from the second generation.

It's larger TBC errors, particularly those affecting vertical sync, which throw off the second machine when recording the tape, making it record a real mess to tape that can't be fixed later.

Chroma is quite fragile though.

Cheers,
David.

[johnmeyer]

There are a few fixes that can help a little with 2nd generation VHS dubs. Someone posted the following modification to the standard MDegrain2i2 script. The modifications add the VShift and HShift parameters which are then used by MergeChroma to remove some of the chroma halos that result from the delay in 2nd gen copies.

You have to experiment with the two shift parameters. I don't think you need to use any shift with an original, and only a shift of 2 with a copy (2nd generation in my terminology).

I've used it a few times, and it in a few cases the improvement was quite remarkable.

function MDegrain2i2(clip source, int "blksize", int "overlap", int "dct")
{
Vshift=0 # 2 lines per bobbed-field per tape generation (PAL); original=2; copy=4 etc
Hshift=0 # determine experimentally

overlap=default(overlap,0) # overlap value (0 to 4 for blksize=8)
dct=default(dct,0) # use dct=1 for clip with light flicker

fields=source.SeparateFields() # separate by fields

#This line gets rid of vertical chroma halo
fixed_fields=MergeChroma(fields,crop(fields,Hshift,Vshift,0,0).addborders(0,0,Hshift,Vshift))

#This line will shift chroma down and to the right instead of up and to the left
#fixed_fields=MergeChroma(fields,Crop(AddBorders(fields,Hshift,Vshift,0,0),0,0,-Hshift,-Vshift))

super = fixed_fields.MSuper(pel=2, sharp=1)
backward_vec2 = super.MAnalyse(isb = true, delta = 2, blksize=blksize, overlap=overlap, dct=dct)
forward_vec2 = super.MAnalyse(isb = false, delta = 2, blksize=blksize, overlap=overlap, dct=dct)
backward_vec4 = super.MAnalyse(isb = true, delta = 4, blksize=blksize, overlap=overlap, dct=dct)
forward_vec4 = super.MAnalyse(isb = false, delta = 4, blksize=blksize, overlap=overlap, dct=dct)

MDegrain2(fixed_fields,super, backward_vec2,forward_vec2,backward_vec4,forward_vec4,thSAD=400)

Weave()
}

[Ghitulescu]

I read this in a lot of places. Yet any small wobbles (typically H-sync errors) from the first tape will be copied faithfully (with appropriate wobbly syncs!) onto the second tape - and it'll all still be there for the TBC to fix from the second generation.

The reason why you see it everywhere is that normally small wobbles are generally more or less invisible (it depends on the experience and/or the ability to see of the operator, last but not least the ability of the TV to hide/correct this issue) so most people don't notice it in the first place and consequently don't think it's necessary to put a TBC inbetween for the first copy, while bigger ones are visible and will get compounded.
small and bigger are of the same size as your small ;)

[2Bdecided]

@johnmeyer, You should always shift the chroma up on PAL VHS - 1 line per field (2 lines per frame) per tape generation (and that includes the first!). I don't know about NTSC.

Cheers,
David.

[Ghitulescu]

... always shift the chroma up on PAL VHS - 1 line per field (2 lines per frame) per tape generation (and that includes the first!)...

Could you please elaborate a bit on this issue?

[2Bdecided]

If you record a signal to PAL VHS, and play it back, you will find the chroma has effectively moved down one line per field relative to the luma. It does this each and every time, so multi-generation copies have the chroma shifted multiple lines.

Strictly, on line N you get the chroma from line N + the chroma from line N-2 added together. The two are added together in the player to remove cross talk from the adjacent field (which sits on the next track on the tape itself). Hence the average chroma position effectively moves down one line, and is blurred. This happens on each generation - which is why multi-generation VHS has the chroma so blurred, and so far below where it should be!

This processing is somewhat similar to what PAL TVs do already - adding the chroma from the previous line to the current line to remove hue errors. However, PAL TVs only get to do the trick once, and only across a single line. VCRs do it once per generation, and across three lines (ignoring the middle one).

Cheers,
David.

[Ghitulescu]

Thanks, I knew that but I ignored its consequences on VHS.
Now I can tell what generation a tape is ;)

[Gerry62]

... always shift the chroma up on PAL VHS - 1 line per field (2 lines per frame) per tape generation (and that includes the first!)...

There isn't a bit of code for this function?

I have tried one of VDUB's filters in the past for this, Flaxens VHS filter.
Have a 1981 THORN-EMI tape of a TV series that will never see the light of day again!

[johnmeyer]

There isn't a bit of code for this function?Something other than the code in my post above??

[Gerry62]

apologies, My browser for some reason didn't show me that part, Thanks, looks good!


It's looking great on my source btw!

Turned off the MDegrain2 and am using another cleaner.

Back to dubbing CV tapes (which luckily suffer none of this chroma business)

[Mounir]

You should always shift the chroma up on PAL VHS - 1 line per field (2 lines per frame) per tape generation (and that includes the first!). I don't know about NTSC.

Even with commercial tapes ?? And about about ntsc then

[vcmohan]

The DeJitter plugin was developed for a particular problem and its limitations are mentioned in its documentation.
Reform bug was fixed. The 1/8 dimension limitation was for the reason that any enlargement more than 8 may get a too low a quality of output. Further the Geometry extrapolation may run into serious problems in certain cases.

[johnmeyer]

Even with commercial tapes ?? And about about ntsc thenI deal only with NTSC. Some are copies, but most are 1st generation.

Whenever I do any restoration project, I always start with a script that I've used before, but then tweak it. No two video projects are exactly alike.

When it comes to chroma shift, I look for scenes that have some fairly hard edges that are moving, and then look at the "halos" around those edges (I, of course, have turned off all the "HQ" and other VHS sharpening circuitry in the VCR before capturing, but there are still halos). I then experiment with the chroma shift parameters in the script I posted earlier. I try both positive and negative values (theoretically, I should never have to use negative values, but it actually let me fix a problem on one strange video someone sent to me). I basically just experiment until it looks good. On some videos, it makes an enormous difference. I had one second generation video of the 1972 Rose Bowl, and the hash marks on the football field were yellow instead of white because the chroma from the grass was bleeding across. After I got the right settings, not only were the hash marks white, but everything became much sharper because the chroma was not blurring across the luma (if that is the right way to describe it).

So, yes, it is an issue for NTSC, and yes, you may find that it helps even with fairly pristine tapes, but you'll have to experiment for yourself to know for sure.

[Mounir]

John can you show us with pictures the work it does precisely before/after , that would be cool.

Well i just made a test with a ntsc commercial tape (1st generation obviously) captured with basic options, it don't help at all in my eyes; actually the colors look better distributed (for lack of better wording) and the UV lines (see vectorscope) are more straight i suppose that's the work of mergechroma in action but there is no shift to fix as far as i can tell. I have kept the values at 0 for vshift and hshift and i find the result rather odd.0 shouldn't shift anything no? Yet it does

Result:
http://imageupload.org/?d=6855B67D1

Original:
http://imageupload.org/?d=7850E9F01

[IanB]

As you are dealing with vertical artefacts, try ColorBars(480, 640, PixelType="YV12").TurnLeft() as your sample image. This will give more vertical chroma transitions to experiment with.