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

[jmac698]

Some small updates. New sample:
http://screenshotcomparison.com/comparison/91853


I'm still working on measuring jitter from 2nd generation tapes, etc.

I'm being mis-understood here, I know most of you can't follow these technical discussions. I should explain that I'm jumping around with a lot of different ideas, most of which have nothing to do with my script or fixing your tapes - but consider them basic research and exploring the issues.

My script *does* work on 2nd generation tapes, it only lines up black borders, the tape has nothing to do with it.
What I was referring to was basic research into technical measurements on 2nd generation tapes. I want to make my own 2nd generation copy and do some measurements on it, that's all.

[cherbette]

I wanted to thank you once again for all of your efforts with this software TBC. So far the results have been pretty stellar so I can't wait to see the final product. Keep up the good work, my friend.

[jmac698]

Welcome to the board. Bit of a different community I'm told, but hope you like it.
And your welcome *blush*
I'm working on some plugin stuff now.

[cherbette]

Awesome! I'm excited for the plugin. If it works on the darker parts of the video as well then you will have officially done what many I have read said couldn't be done...a software TBC.

[jmac698]

@sven:
Regarding your line length theory, I did some calculations, but haven't finished analyzing it yet. If you correlate two steps, first of all the mean is length/n, where length is the length of the step. I don't have the rest derived yet.
Sliding the steps against each other forms a pattern, if size=8 over 16 pixels, we have:
x=y=(1,1,1,1,1,1,1,1,0,0,0,0,0,0,0,0)
r=1
if size=7 or 9 we have
x=(1,1,1,1,1,1,1,1,0,0,0,0,0,0,0,0), y=(1,1,1,1,1,1,1,0,0,0,0,0,0,0,0,0) or (1,1,1,1,1,1,1,1,1,0,0,0,0,0,0,0)
r=.88
Continuing we have
size
8 1
7/9 .88
6/10 .77
5/11 .67
4/12 .58
3/13 .48
2/14 .38
1/15 .26
0/16 (1/0)
So we have the maximum when edges are aligned and it gets less accurate the further the edges are from each other, also you can't tell sign, that is if the edge is to the left or the right. A simple inspection could tell you probably, like the average on either side.
I still don't see why the lines get bigger, it should be symmetrical. Could be the plugin is stopping at the left edge, but in the video the right edge continues.

[jmac698]

Update: sum(x-xavg)^2=n(1-avg)^2-(n/2-size)/(n/2)
xavg=size/n

This is relevent cause r=sum(x-xavg)(y-yavg)/(sqr(sum(x-xavg)^2)*sqr(sum(y-yavg)^2))
So I have the bottom half of the expression.

[jmac698]

I almost have the answer, but a quick guess is it's something like a/n/(sqr(b/n)*sqr(c/n)) where b+c=n or something like that, anyhow this means I can do a single correlation and compute the exact distance by working backwards, then just gotta find it's sign.

So what we've just discovered is a simple formula to find the edge which is robust to noise, brightness and contrast. It gets very sensitive to noise the farther apart the edges are. I could do two correlations to get the maximum accuracy.

[cherbette]

Hey Jmac just wanted to see if you had made any progress with this great idea? :)

[jmac698]

Hey Cher,
thanks for asking, it reminds me and also encourages me. In fact I haven't done any video work since xmas, once the festivities took me away from my hobby it wasn't easy getting back. So you never know, I would like to finish these ideas...

[zerowalker]

I can get the Dscaler driver to work With Dscaler, but don´t know how to set it up in Virtualdub;S
Conextant driver, w7 x64.

Anyone knows:)?

[NoX1911]

Looking at your screenshot (http://screenshotcomparison.com/comparison/88810) it shows a visible area (52us) of roughly 670x576 pixel with a loss of horizontal information by 704->670 (~34 pixels per line). So technically the scan rate/pixel clock hasn't change noticeably if i see that correctly.

Do you have any informations about that changed parameters (clock rate, hsync, prescale...)? I'm currently looking into patching philips drivers and it would be much easier if i would have some values i can work with.

[jmac698]

Modern cards sample SD ntsc & pal at a multiple of 13.5MHz. Modern cards use oversampling of 27MHz or more. As a result, there's actually over 1000 samples per line.
There is a standard for VCRs for jitter to be +-3uS (I believe). In my sample, I used a tweaked card with standard sampling rate, but the registers adjusted to begin active video line earlier, that is less offset from front porch. If you tell me the datasheet for your device, I can suggest which register and value to put there, although if you can make all the timing registers variable then it's easier to experiment.

Hopefully I'll get back to this this year. I'm collecting new equipment to examine it in more detail. I believe I bought a TBC the other day, haven't tested it yet.

[lordsmurf]

I'm wondering if this could be modified to solve whole-frame vertical image jitter. (Not horizontal signal jitter, as this virtual TBC is attempting to resolve.)

What I'd like to see is an if/then/else type dejitter script for videos with jumps in the frame that are only ONE frame long (compared against several before/after framse). Not even frequent bouncing or vibration necessarily, but jumping frames maybe once per second (at most). If whole-frame movement exists, then act. If not, ignore.

Vibration and serious jitter can come later. It's actually less common to be that ruined.

Trying to apply deshake filters is crap because it wants to "correct" vertical pans and movements of large objects. It could be tracked against the head switching noise at the bottom of the frame. In fact, I have a matted widescreen VHS movie, where it jumps, so there's two huge black borders on top/bottom to track against.

I've tried to find a good vertical de-jitter method for probably 10 years now. All create more problems than they solve.

I'd still like to see this virtual TBC fix my fubar Robotech test captures. ;)

.

[jmac698]

Yep, vertical jitter shouldn't be hard to write in script. I'm trying to put my TBC into a plugin, but again, writing plugins is very hard. So I have a new idea for the script to make it a lot faster.

[jmac698]

New Avisynth script
TBC 0.6 by jmac698
Jul 11, 2012

A script to resize each line of the source by a different amount, by searching for black borders. YUV only. Avisynth 2.58+
Usage: see tbc.avs demo
Requirements: dejitter 0.2, findpos 0.1 (included)

0.6: first plugin version

http://www.sendspace.com/file/01u1wc

The quality is no different, but it's a lot faster. Example included.

[Mounir]

it return an error : unable to Load dejitter.dll , error=0x36b1, any idea ?

[jmac698]

Please extract the included plugins and place into your plugins directory.
jitter02.zip -> jitter.dll -> plugins\jitter.dll
findpos01.zip -> findpos.dll -> plugins\findpos.dll

Fun with jitter analysis
Using the download package, try this script instead:

srcdir="C:\Documents and Settings\me\My Documents\Downloads\filters\tbc\"
src=ImageSource(srcdir+"jittered.jpg").converttoyuy2
thresh=85
#Mark video edges
findpos_h(src, x1=60, x2=0, thresh=thresh)#search for the first bright pixel, starting 48 from left and 0 from right
#test note: (65,0)=92
converttoyv12.histogram(mode="levels")#show distribution of jitter
#histogram(mode="classic")#recreate the jitter with a solid white line
return last
function findpos_h(clip src, int "searchwidth", int "x1", int "x2", int "thresh"){
searchwidth=default(searchwidth,32)
x1=default(x1,0)
x2=default(x2,0)
l=findpos(src, x1=x1, x2=x1+searchwidth, thresh=thresh)#.crop(0,0,-src.width+2,0)
r=findpos(src.fliphorizontal, x1=x2, x2=x2+searchwidth, thresh=thresh).crop(0,0,-src.width+2,0)
stackhorizontal(l,r).pointresize(2,src.height)
l
greyscale
}


It shows the distribution of jitter amounts; it looks like a normal distribution! That's good actually, it can help me learn how to limit change per line etc.

In the classic mode, you can see more clearly the jitter in this video, but with an artificial white line.

[StainlessS]

Jmac, hope you remembered to point out that users need VC++ runtimes for 2008 (think thats your version).

[jmac698]

Oh no! The classic "works for the developer only" has bit me! Is there any way to remove this requirement?

[StainlessS]

Is there any way to remove this requirement?

Yes of course there is, use a different compiler. :devil:

Just be glad you did not choose 2010 Express.
(A lot, but not all will already have 2008 runtimes).

[Robert Martens]

Yes of course there is, use a different compiler. :devil:

Or just link the dependency statically, unless there's some danger in that? I know of problems throwing exceptions from DLLs, but as far as I can tell, env->ThrowError is just passing a string back to avisynth, which itself throws the exception; any design issues with regard to DLLs and exceptions are a matter of core development, and as plugin authors we don't have to worry about that, as long as we stick to ThrowError and don't use the throw keyword ourselves.

As for CRT version mismatches, the official, single threaded builds of Avisynth are dynamically linked with the VC6 toolset, while SEt's MT builds are statically linked with VC10 (I'm getting this from examining the different DLLs themselves, and from certain forum posts (http://forum.doom9.org/showthread.php?p=1567883), someone please correct me if I've misinterpreted something -- EDIT: Looks like I was wrong (http://forum.doom9.org/showthread.php?p=1582947#post1582947), though I don't think it changes my point), so I would think plugins that use anything else would be an absolute nightmare for everyone, yet people seem to be successfully using plugins that were linked with the 2003, 2005, or 2008 runtimes, some using static linking, some dynamic. Is there some hidden issue with this that's going to swim up and bite us all on the ass one day? Or, for that matter, something not so hidden, that I'm just overlooking?

Avery Lee touched on these dependencies in a blog post some time ago: http://www.virtualdub.org/blog/pivot/entry.php?id=296 It goes into rather intimidating detail about this stuff, though I don't know exactly how much of it changes when building plugin DLLs as opposed to executable applications.

If you do decide to stick with the CRT DLLs, jmac, you'd do well to offer up the Release builds of your plugins to users. You should be doing that anyway, but when it comes to the Runtime it's especially important since, as you can see in the second paragraph of this MSDN article (http://msdn.microsoft.com/en-us/library/8kche8ah(v=vs.90)), linked from that blog post, the Debug CRT DLLs are not redistributable.

[jmac698]

I've updated everything to use release builds.
Does even a void main() type program require CRT? I thought the error on dejitter might have come from me using math.h. I can work around that and not include it. Then it's possible I wouldn't need any runtime.

[Robert Martens]

I was embarrassed to not know the answer right off the top of my head, but a quick test in both VS2010 and 2008 shows me that even just

int main()
{
return 0;
}

ends up depending on the appropriate version of the CRT, if the project is set that way (which it is, by default). If you don't redistribute the DLLs, point people to the appropriate redistributable, or use static linking for your plugins, I don't think you can avoid the dependency, even if you ignore math.h.

[Mounir]

So what do i need to make this script work? I'm loading both dlls and still get this error

[jmac698]

I tested the latest package on a separate machine, it works fine. You have the latest package and vc runtime installed?

Did you change any parameters? Are you using avisynth 2.6?
I've only tested on avisynth 2.58. Don't use any of the new colorspaces.

[Mounir]

I have avisynth 2.6.0.2 and have installed Vc++ 2008(x86). I'm on win764 though not sure if that's what i need, you tell me
I load the findpos.dll as follow:
LoadPlugin("C:\Program Files (x86)\AviSynth 2.6\plugins\tbc\findpos.dll")
the error remain the same: error 0x36b1 unable to load dll

[jmac698]

Thanks for the report, I'll see if I can test with those conditions.

[StainlessS]

error 0x36b1 unable to load dll


Can you verify that the above error is an Avisynth Error in little red window?
Cant say I've ever seen an Avisynth error like that, with hex error code.

Are you using a debug version that was mistakenly uploaded, if so try new download.

[StainlessS]

Jmac, hate to have to tell you this, but on trying a test install (I dont really have need of the
filter), I found I was going to overwrite an already installed DeJitter.dll, on inspection, it's a
V.C Mohan filter from 2006.

http://avisynth.org/vcmohan/DeJitter/DeJitter.htm

Oh, the humanity. :eek:

EDITED: You MUST do a name change, check in future.

[jmac698]

I did, I made another one called jcorr to avoid collision. Anyhow, did it work for you?
And I've seen errors like that before, I think it was when fftw was missing. I don't see why that should be the case though.

[jmac698]

No need to worry about conflicts, http://avisynth.org/mediawiki/Plugins
just rename to jdejitter.dll, and call with jdejitter_dejitter().

Static build for Mounir, please report:

jdejitter03_static
http://www.sendspace.com/file/qk1ifv

findpos02_static
http://www.sendspace.com/file/e3jblt

btw, I think I'll be using some of your filters soon :)

Note: those links won't be updated, see the head of the thread instead.

[Mounir]

It seems you have fixed the problem Jmac, thank you.
Can someone send a video with lot of jitter i don't have any at the moment

[jmac698]

Great! The download is slightly bigger, but otherwise I don't know if there's any real disadvantage to compiling the plugin this way.

As for a video sample, it's easy to make your own, as I've made a jitter simulator (which will be going into a plugin as well soon).
http://forum.doom9.org/showthread.php?p=1470667#post1470667

You need also gscript and grunt, but you can skip noisegenerator if you comment out the respective line. You can use any of your videos as source.

[StainlessS]

Jmac, shall give em a try now re-named/updated.

Might I suggest that you consider setting up a single place where plugs can be obtained,
either 1 per plug or for the whole lot, or you are going to get into a helluva pickle,
eg 'Jmac's plugin Emporium'.
Decide where you're gonna put it and point links to there so you need not update in multiple
places.

You can also get an account (free) on eg MediaFire called pretty much whatever you want
and store them all there (better than sendspace, I think). Take a peek a StainlessS on Mediafire
in sig, the user can browse.

[zerowalker]

Has someone been able to get the Hsync with a conextant2388x card?

[jmac698]

Please see How to Capture with HSYNC
http://forum.doom9.org/showthread.php?t=162832

in the capture forum.

[Robert Martens]

Quick note for anyone who read my earlier posts in this thread, it turns out I got some details wrong: http://forum.doom9.org/showthread.php?p=1582947#post1582947

I don't think my ultimate point changes, but I've updated the post (http://forum.doom9.org/showthread.php?p=1582294#post1582294) accordingly, and just wanted to make everyone aware.

[jmac698]

Ok, a big limitation with the technique so far is that it requires clear black borders on each side. So the obvious approach is to not always rely on them. I've done a test using *internal* lines of the video, which happen to be there in some scenes. Now we can theoretically use the following information:
-any parts of a black border, even one side, and only those parts that are clear
-any internal lines, possibly at any high angle
-extend the fixed area with a motion tracking technique
This can extend the number of scenes which can be fixed, but doesn't totally solve the problem. I've placed a sample here:
http://www.digitalfaq.com/forum/21764-post18.html

A big application for software TBC is 2nd generation tapes; there's no other way to fix these.

Also, a simple technique to play with in your tests is to use an edge detector. Just adding one line might improve your results:

src=avisource
mt_edge("0 0 0 -1 0 1 0 0 0")#1 dimensional Roberts edge detector, requires Masktools v2
findpos_h(src, x1=0, x2=0, thresh=254)
rescale(src,last)

You can also get the edge detector to show your left/right black borders, so you can tell if they're good enough. I'm also experimenting to see if just one edge has enough information to resize; perhaps it's a proportion of the resizing, however so far if I fix a video on one edge, I can see that side of the screen looking good and the other side is messed up. I've also noticed that VCR comets can appear in the borders and mess up the detection, so you need some decomet operation first.

[dokworm]

These are amazing results, it might make it worth recapturing some of my old tapes now!

I also want to do a median pass where I have multiple copies of a particular movie. What is the best thing to use for that?

Oh, and will this help with laserdisc captures at all, or does the TBC built into the LD player take care of it all?

[Asmodian]

There are some good median functions for Avisynth.

I have used them to do 3, 5, and one 9 capture median's. Three captures helped a lot, five helps denoise some more (in my tests), and nine looked exactly like five. :p

It was a pain syncing all the captures because the TBC in my VCR would drop/dupe frames in different places during the captures. I had to trim out or dupe 3-4 frames in every capture to keep them in sync at all times. I used interleave and overlaid subtitles to indicate each capture during this process; please let me know if you or anyone else finds a better way!

Both of these taken from posts by jmac698, thanks for all the help!

Function Median1(clip input_1, clip input_2, clip input_3, string "chroma")
{# median of 3 clips from Helpers.avs by G-force

chroma = Default(chroma,"process") #default is "process". Alternates: "copy first" or "copy second"

Interleave(input_1,input_2,input_3)
chroma == "process" ? Clense(reduceflicker=false) : Clense(reduceflicker=false,grey=true)
SelectEvery(3,1)

chroma == "copy first" ? last.MergeChroma(input_1) : chroma == "copy second" ? last.MergeChroma(input_2) : last

Return(last)
}

Function Median2(clip "input_1", clip "input_2", clip "input_3", clip "input_4", clip "input_5", string "chroma")
{# median of 5 clips from Helpers.avs by G-force
chroma = default(chroma,"process") #default is "process". Alternates: "copy first" or "copy second"
#MEDIAN(i1,i3,i5)
Interleave(input_1,input_3,input_5)
chroma == "process" ? Clense() : Clense(grey=true)
m1 = selectevery(3,1)
#MAX(MIN(i1,i3,i5),i2)
m2 = input_1.MT_Logic(input_3,"min",chroma=chroma).MT_Logic(input_5,"min",chroma=chroma).MT_Logic(input_2,"max",chroma=chroma)
#MIN(MAX(i1,i3,i5),i4)
m3 = input_1.MT_Logic(input_3,"max",chroma=chroma).MT_Logic(input_5,"max",chroma=chroma).MT_Logic(input_4,"min",chroma=chroma)
Interleave(m1,m2,m3)
chroma == "process" ? Clense() : Clense(grey=true)
selectevery(3,1)
chroma == "copy first" ? last.MergeChroma(input_1) : chroma == "copy second" ? last.MergeChroma(input_2) : last
Return(last)
}

[dokworm]

Thanks for those, I will give it a go.

I'm thinking that a median pass first will get rid of dropouts and glitches, and then an average of the now dropout free captures would clean up the noise.

[ChibiBoi]

So I basically tried copying and pasting the script as is, and it didn't really work for me :-/ I don't have the HSYNC area for my videos, but I do have black bars on the sides.

Before using script:
http://i50.tinypic.com/2hyw8dk.png

After using script:
http://i50.tinypic.com/2uz58k1.png

Somehow, I don't think I'm doing this correctly :-/

[vcmohan]

you may try my plugin DeJitter.The following script gave better results. The very dark top and the very bottom strip can not be handled.
src=imagereader("D:\2hyw8dk.png",0,1,25,false)
DeJitter(src,jmax=50,th=40, wsyn=0, extend=false)

[ChibiBoi]

you may try my plugin DeJitter.The following script gave better results. The very dark top and the very bottom strip can not be handled.

No doubt the script does work better, for the most part. Here are some successful screenshots:

Before:
http://i3.photobucket.com/albums/y68/ChibiBoi/dejitterbefore2.png
http://i3.photobucket.com/albums/y68/ChibiBoi/dejitterbefore3.png

After:
http://i3.photobucket.com/albums/y68/ChibiBoi/dejitterafter2.png
http://i3.photobucket.com/albums/y68/ChibiBoi/dejitterafter3.png

However, there are some scenes that get really glitchy. Sometimes, there's not too much of a jitter in the scene, and then the filter shifts the video to produce a huge glitch. Sometimes, there's a lot of jitter in the scene before, but the filter doesn't fix the jitter, it adds more glitches to the video. What settings do I need to fix this? Will capturing the video with the HSYNC lines help?

Also, is there a way to make the blank area black instead of gray?

Before:
http://i3.photobucket.com/albums/y68/ChibiBoi/dejitterbefore.png
http://i3.photobucket.com/albums/y68/ChibiBoi/dejitterbefore4.png
http://i3.photobucket.com/albums/y68/ChibiBoi/dejitterbefore5.png

After:
http://i3.photobucket.com/albums/y68/ChibiBoi/dejitterafter.png
http://i3.photobucket.com/albums/y68/ChibiBoi/dejitterafter4.png
http://i3.photobucket.com/albums/y68/ChibiBoi/dejitterafter5.png

EDIT: I realize now that the glitches are caused whenever there is black footage on the left side of the video (ie. black hair, or shadow) because the filter thinks it's the black overscan bar, it tries to overcompensate by shifting the video out of the frame. I'm not quite sure how to fix this...

[vcmohan]

I have slightly modified DeJitter plugin and is available for down loading. uselast is a new option. Also it uses all colors of RGB. Try by playing with the parameters. Black at the left gives some problem always.
DeJitter(src5,jmax=30,th=20, wsyn=0, extend=false, uselast = true)

[vcmohan]

Sorry I inadvertently introduced a bug. Now it is corrected. As the black part is at the top you may flip vertically prior to dejitter and flipvertical again to correct. Also try convertto YV12. As part of black is the hair of the girl you can not avoid glitches.
sr = sr.flipvertical().converttoYV12()
dj= Dejitter(sr,jmax=30,th=40, wsyn=0, extend=false, uselast = true)
dj = dj.flipvertical()

[ChibiBoi]

Sorry I inadvertently introduced a bug. Now it is corrected. As the black part is at the top you may flip vertically prior to dejitter and flipvertical again to correct. Also try convertto YV12. As part of black is the hair of the girl you can not avoid glitches.

Too bad about the hair, there's a lot of scenes that involve black at the left edge so the glitches happen quite frequently :-/ your filter works great otherwise though!

and as for the OP's filter, i can't seem to get the filter to work, and i can't seem to capture with HSYNC because of my cap card :-/

[jmac698]

My filter should work as well but no better, though I have ideas to improve it. Not set up right now, I'll have to get back to you.

[ChibiBoi]

My filter should work as well but no better, though I have ideas to improve it. Not set up right now, I'll have to get back to you.

Alright, thanks for your hard work though! :D
I actually went out and bought a SVHS player with built-in TBC so hopefully it'll fix everything, because the jitters were really pissing me off LOL But I can't wait to see what you come up with :cool:

[Mounir]

So the project has been cancelled or what ? it's been a while since we've heard of Jmac, i'm still looking forward to his drivers tweak on linux