New Script: Software TBC 0.6 & Sample (was Fast Line Shifter 0.53)

[jmac698]

Also to point out that Border Detection 0.3 needs some more work; it seems it should be scaled wider to show more of the correlation surface (it's for testing only).

[sven_x]

I found that the input for Corr2D CCF should have a least an area of 100 px height and 200 px width (better 400 px). Then we could cut the line with the right half of the CCF from the resulting output area. With smaller resolutions the output pixels of ccf are scaled down which results in avaraging with their black neighbor pixels.
It is better to use the right side because the left side is terminated at (width/4) px.

When using the output of CCF it better has to be

• blurred (perhaps - please look at the last example in my Part 2 image with strong noise superimposed on input - this gives some noise on the ccf output)
• converted to black/white using a thresh to get a sharp length of CCF
• subtracting the number of pixels that the auto correlation of the border model produces, because in the case when the real border is exactly at the same position as the border model (i.e. offset = 0) the output reduces to the autocorrelation function of the border (and not to zero)
  (To acchieve a similar effect perhaps the left side of the CCF could be automaticly subtracted from the right side using a kind of mirroring at x=width/4.)
• set the border model to a minal number of pixels (say 2 px) to get offset values in one direction only

When the input is scaled up enough we do not need convert exactly the number of pixels of the output function to get an offset value, because 11 and 14 px give the same result (3) when 5 pixels in CCF correspond to 1 px input (before it was inflated).

[ronnylov]

Originally Posted by jmac698

How to get the capture
The capture section has moved to "How to Capture with HSYNC" in the capture forum. That topic is unrelated to script usage.
http://forum.doom9.org/showthread.php?p=153072
[/code]

This link is wrong? They talk about SVCD creation in a 9 year old thread.

Should be: http://forum.doom9.org/showthread.php?t=162832

[jmac698]

thanks, fixed

[jmac698]

First test of my "perfect TBC" test signal, I have a number which is proportional to the shift in high accuracy. This was a test of an actual VHS. It's just the detection value, no dejitter yet. I also have to scale the number into actual pixels first. At least it looks like it's going to work. Oh, and that 'head switching noise' that everyone crops? No need to, I can recover quite a bit of it.

[jmac698]

Results of my jitter analysis. Good and bad. My test shows jitter is +-.25 in left border and +-.5 in right border. This is with a modern card which probably has an Ultralock type feature. I hardly need TBC for this tape.
The samples of jitter I've provided before were from an older capture card, and a worn VHS which possibly had macrovision, that could explain why it's so much worse.
I need to prepare more tests with a VHS in LP mode, with a stretched tape, or with a copy of a copy to get some real jitter.

[Perepandel]

Hi! I finally tried to take a look at this. Have a hardware TBCd capture that, even that, has a couple of seconds with jitter that it seem it wasn't able to recover (or maybe it came from a previous generetion or whatever). I've haven't been able to make virtualdub vhsrest2.vdf plugin work (it makes it crash, nor through avisynth's LoadVirtualDubPlugin), and with DeJitter.dll I get far more jitter than in the original file.

The problem is I am not able to run this script. I've been upgraded to Avisynth 2.6 alpha, downloaded and included the required plugins with the following lines:
LoadPlugin("mt_masktools-26.dll")
LoadPlugin("GRunT.dll")
LoadPlugin("minmax.dll")
and loaded the video file, but I always get an "I don't know what 'thresh' means ([ScriptClip], line 4)" error.

I'm suspecting something is not getting loaded. Any hints??

[Gavino]

Originally Posted by Perepandel

I always get an "I don't know what 'thresh' means ([ScriptClip], line 4)" error.

Perhaps you are running an older version of the script.
Check your script is the same as in the first post.
Before the call to ScriptClip, there should be this line:
thresh=int(findthresh(src))+3

[jmac698]

It's true, an "auto" thresh feature was added in the last .52 version.

[sven_x]

This is part 3 of posting 69 and 82.

Basing on Border Detection 0.3 by jmac698 (same thread, here) I have modified the script that calculates cross correlation between the border of a real video and an edge model, whose parameters can be adjusted (edge blur, white level and number of black pixels of the edge).

You are welcome to do your own tests.

PHP Code:

#AvsP script

#loadplugin("J:\plugins\Gscript.dll")  # For y=0 ... loop
loadplugin("J:\plugins\GRunT.dll")  # For use of Runtime functions inside user functions
loadplugin("J:\plugins\Corr2D.dll")  
loadplugin("J:\plugins\VariableBlur.dll")   
loadplugin("J:\plugins\NNEDI3.dll")  

#Border Detection Sven_X Corr2D version basing on 0.3 by jmac698 
# see http://forum.doom9.org/showthread.php?p=1533363#post1533363
# A function to show cross correlation between the left border of a video and an edge model that can be tweaked
# Requirements:  corr2d  http://avisynth.org/vcmohan/Corr2D/Corr2D.html
# infact we do neet a Corr1D only, which would be much faster, but we have none...
# GRunT (NNEDI3, Variablelbur in some cases for the edge model)

SetMemoryMax(800)  #set this to 1/3 of the available memory  

[<separator="Clamping">]
clamp2=[<"Input clamping", 16, 255, 43>]
global clamp=[<"cff out clamping", 16, 255, 27>]
mag2 = [<"Magnification", 1, 8, 1>]

[<separator="Edge model">]
bwidth=[<"Black px", 2, 16, 2>]
bblur=[<"Edge blur (0)", 0, 5, 1>]
bgrey=[<"Edge white (255)", 16, 255, 43>]

Directshowsource("J:\test\test.avi")
converttoyuy2
#nnedi3(-2) #deinterlace, double frame rate, to view a non interlaced version 
#return last #view input video

border=32#32
crop(0,0,-last.width+border,0)
#crop(0,0,-0,last.height*1/4)  #1/2 for test purposes only, faster, 
levels(0,1,clamp2,0,clamp2)  #clamp bright areas 
edge=makeedge(last,bwidth).converttoYV12.averageblur(bblur).converttoYUY2.levels(0,1,255,0,bgrey) 
#make an edge model with minium edge at x=2 px
#return edge
corrbyline3(last, edge) # input, reference
pointresize(last.width*mag2/2,last.height*mag2/2) #Magnify output


function SplitLines2(clip c, int n) {#duplicates then crops each copy in a different spot
    Assert(c.height%n == 0, "Clip height not a multiple of 'n'")
    Assert(!(c.IsYV12() && n%2==1), "'n' must be even for YV12 clips")
    nStrips = c.height/n   #= 576 lines PAL
    c = c.ChangeFPS(nStrips*Framerate(c)).AssumeFPS(c) # Repeat each frame 'nStrips' times
    BlankClip(c, height=n) # template for ScriptClip result
    GScriptClip("c.Crop(0, (current_frame%nStrips-1)*n, 0, n)", args="c, nStrips, n") #(left, top,width,heigth)
}


function MergeLines(clip c, int n) {MergeLines2(c,n,n)}

function MergeLines2(clip c, int n,int i) {
  i<2 ? c.SelectEvery(n) : stackvertical(MergeLines2(c,n,i-1),c.SelectEvery(n, i))
}


function makeedge(clip v, int x){
    #Based on the properties of v, make an edge of x black + white pixels
    x=x/2*2
    v
    blk=blankclip(last, width=x, color_yuv=$108080)
    wht=blankclip(last, width=last.width-x, color_yuv=$EB8080)
    stackhorizontal(blk, wht)
}

function corrbyline3(clip v1, clip v2){
    #Correlate two videos, line by line, and return the horizontal cross correlation. 
    # when input 1 and 2 are edges (a square waveform, then the length of the resulting ccf correponds to offset between both edges
    scale=2
    v1
    pointresize(v1.width, v1.height*scale) #scale line height, for yv12 a line has to have at least 2 px height
    h=last.height #PAL 2x576 lines = 1152
    splitlines2(scale)  #make n frames with one line (height=scale) from a frame
    v2l=v2.crop(0,0,0,scale)
    interleave(last, v2l)
    pointresize(last, 400, 100) #to enlarge output of CCF, at least 200x100
   corr=corr2d (last)
   Crop(corr,100, 24, -0, -72).pointresize(corr.width,corr.height*4) #400x400
   Crop(0, 126, -200, 2) #to get the interesting part of CCF (x=0...)  2 px height
   selectevery(2,1) #drop cff output of every odd line
   mergelines(h/2)   #compose a frame from h/2 frames that contain a single line
   v2=pointresize(v1,v1.width*2,v1.height*2)
   stackhorizontal(v2,last,last.levels(clamp-2,1,clamp,0,255)) #clamps grey levels of ccf output above clamp to white
}


function corrbyline2(clip v1, clip v2){
    #Correlate one video line by line, and return the cross correlation between two succeeding lines
    scale=2
    v1
    pointresize(last.width, last.height*scale) #scale line height, for yv12 a line has to have at least 2 px height
    h=last.height #PAL 2x576 lines = 1152
   splitlines2(scale)  #make n frames with one line (height=scale) from a frame
    pointresize(last, 400, 100) #to enlarge output of CCF, at least 200x100
   corr=corr2d (last)
   Crop(corr,50, 24, -0, -72).pointresize(corr.width,corr.height*4) #400x400
   Crop(0, 126, -300, 2) #to get the interesting part of CCF (x=0...)  2 px height
   mergelines(h/2)   #compose a frame from h/2 frames that contain a single line
   v2=pointresize(v1,v1.width*2,v1.height*2)
   stackhorizontal(v2,last,last.levels(clamp-2,1,clamp,0,255)) #clamps grey levels in Cff output above clamp to white
} 


Here are a few first results.







It can be seen that the width of the cross correlation reacts on the luma of the input video. Bright image parts produce a longer CCF output. The effect is smaller when input contrast is lowered (which is done in this version by clamping all luma values above a certain threshold).

By looking at these pictures I am not so convinced anymore that cross correlation can provide a good border detection.

[jmac698]

sven,
Great work and analysis. I have a simple suggestion, just change the 'white' color of the edge model into the averageluma of the video, this would eliminate the 'border bias' you are getting.
If I analyzed the actual correlation calculations, I'm sure I could understand why it's doing this anyhow.
Does your script work on two model edges correctly?
What about using a pure threshold, but then using salt&pepper removal to clear the noise?
It seems your borders are quite good, there just has to be some way to detect them. Did you try the edge masks built into masktools?

[Perepandel]

Originally Posted by Gavino

Perhaps you are running an older version of the script.
Check your script is the same as in the first post.
Before the call to ScriptClip, there should be this line:
thresh=int(findthresh(src))+3

Yeah, I'm using that version, dated 27th october... I also tried to put the "int(findthresh(src))+3" instead of the "thresh" variable inside the ScriptClip part to try to isolate the problem but no luck... I guess I'm using some old/different version of some of the plugins...

By the way, I just wanted to test how the alignment was working with one of my already-captured-without-sync captures...

[jmac698]

Oh, make sure you have gscript installed.
http://forum.doom9.org/showthread.php?t=147846
Can also set thresh manually, thresh=20 (for example) inside the scriptclip.

Gscript is sort of dangerous to have around for development, it silently affects variable scope I believe making me not realize I need it in a script. I mean something will just work for me when a plain avisynth would give an error.

[Gavino]

Originally Posted by jmac698

Oh, make sure you have gscript installed.
http://forum.doom9.org/showthread.php?t=147846

You mean GRunT, not GScript (although GScript is also needed later in your script).

Gscript is sort of dangerous to have around for development, it silently affects variable scope I believe making me not realize I need it in a script. I mean something will just work for me when a plain avisynth would give an error.

Again I assume you mean GRunT, as GScript does not affect variable scope.
The fact that "something will just work" is what it is intended to achieve, so is for the most part an advantage(!), but I understand what you mean in that it is harder to realise you need it for a given script. This is because once installed it extends the standard run-time environment and will still be used if you call 'ScriptClip' instead of 'GScriptClip' - it has to be this way as all run-time filters must work the same way for it to function properly.

Perepandel, are you saying your script is like this:

src=AVISource("...")
thresh=int(findthresh(src))+3
ScriptClip(src, """
#Mark video edges
converttoyv12
m=mt_binarize(thresh)
#Line up video
findpos_h(m, searchwidth=22)
alignbyluma(src,last)
""")
...

and you get "I don't know what thresh means" inside ScriptClip?
That should work whether or not you are using GRunT. The only exception would be if you have put this code inside a function (or if you have also configured GRunT to run each run-time script in a separate scope, by calling GRTConfig(local=true)), in which case you would have to add args="src, thresh" to the ScriptClip call (or simply make src and thresh global).

[Perepandel]

Originally Posted by jmac698

Oh, make sure you have gscript installed.
http://forum.doom9.org/showthread.php?t=147846

It was GScript! After I installed it, the script worked! Thanks a lot! I need to make further tests now

[jmac698]

I've updated the instructions and requirements.
Also have my perfect TBC working today

[Gavino]

Originally Posted by Perepandel

It was GScript! After I installed it, the script worked!

Certainly, GScript is required, but without it you should get the error 'there is no function named "GScript"', not a message about 'thresh'. Or is this actually what you did get?
(I need to understand the details just in case there is something strange happening with GRunT.)

[jmac698]

Example of my ideal TBC performance
http://screenshotcomparison.com/comparison/91487
You'll see some aliasing, that's due to a simple resizer to fix the jitter. On VHS you'd never notice.
What this is, a test signal is added to the video, this allows my software to line-up the video and remove the jitter. This is only useful for new VHS recordings. It's use really is just to measure the actual jitter added, not to perfect obsolete VHS
I'm still working on measuring jitter from 2nd generation tapes, etc.

[mammo1789]

Excellent result jmac can we download the whole script and what plugins are required to work
Thanks

[jmac698]

What, my "perfect TBC"? Oh, that's useless to you, you have to make a new recording with an extra test signal on it. It's too late to perfect the obsolete VHS anymore