Software TBC

[Ghitulescu]

I wonder if such any improvements exist, after so much time (2005-2006) :confused:

I remember reading long time ago in a German magazine that for several years now deceased firm, Electronic Design, had plans for its VideoCockpit software to add a TBC module. I think I still have a copy of VideoCockpit somewhere in my collection but I can't find it anymore (it came with their capture card but the CD is no longer in the same package).

It appears that's the only attempt ... besides flaxen (http://neuron2.net/flaxen/flaxen.html) on neuron2s web page and dejitter (http://avisynth.org/vcmohan/DeJitter/DeJitter.htm).

See also http://www.videohelp.com/forum/archive/why-isn-t-there-a-software-tbc-or-is-there-t293462.html and http://forum.videohelp.com/threads/243618-Hardware-TBC-s-OK-Software-TBC-Does-It-Exist. And the doom9s' own threads (http://forum.doom9.org/showpost.php?p=892725&postcount=1, http://forum.doom9.org/showpost.php?p=661938&postcount=1, http://forum.doom9.org/showpost.php?p=663115&postcount=1).

[lordsmurf]

It's pretty much impossible to create a software TBC. Once a video error has been digitized, there's really no way to undo it. All of the attempts I've seen to date only worked well on the test clips used to develop the script or software. Under real-world conditions, it usually made video much, much worse.

Yes, I'm aware the TBC digitizes the analog signal in hardware, but it's not the same as starting from digital video files.

This is exponentially more complicated than stabilization, which is already difficult and often near-impossible. I made a post several years ago showing some examples of removing video jitter (a.k.a. fixing a shaky picture) (http://www.digitalfaq.com/forum/showthread.php/examples-jitter-removed-1144.html). That was difficult enough as it is, using both hobby/home and professional software (although I don't seem to have listed it all?), and it was still not perfect. That type of software is still very much in early development stages even today, along with deinterlacing methods. TBC functionality is similar to de-shake, but with far more (and far smaller) increments of disturbances to counteract.

I just don't see it happening. Maybe not for 10-20 more years, if ever.

I wish.

[jmac698]

Such pessimism :) Not true at all. There is an excellent method to dejitter video, only in software. It's copmpletely blind and relies on a pattern in a low degree polynomial of images.

Fast Dejittering for Digital Video Images, Mila Nikolova.
http://.cmla.ens-cachan.fr/~nikolova/

I'm trying to program the algorithm right now. That's gonna be complicated and take some time, I've asked the author for her matlab codes, in which case it can be compiled into a standalone dll with some tools (mat2python etc.).
In the meantime I'm doing something simpler. I found an algorithm to detect subpixel phase, and it seems to be working. I suppose I could use this to align if one of the edges appear. That is I find the edge of the line (assuming it's not a black scene).
Actually, I had intended only to record test signal and quantify the statistics of real jitter.

I've set up a project on a code site and there are currently two developers working on it. Anyone else care to join? Especially if you are good at explaining the maths.

Also, I'm sure there is existing software for this, look up video forensics programs (like videoinspector). There also might be a free way, look for a plugin for imageJ, I'm sure there is something out there.

http://pacific.mpi-cbg.de/wiki/index.php/Main_Page
Fiji is a kinda of distro for ImageJ.

[Ghitulescu]

Fast Dejittering for Digital Video Images, Mila Nikolova.
http://.cmla.ens-cachan.fr/~nikolova/
You mean http://www.cmla.ens-cachan.fr/~nikolova/
and probably the article you're referring to is this one http://www.cmla.ens-cachan.fr/fileadmin/Membres/nikolova/RT-DJ.pdf.

In this article fig. 6 is exactly what I was looking for. I have a commercial DVD that looked like Lena top left. I've never seen in my life an analog source so bad, yet I lived enough to find one on a commercial DVD. I was curious if there's any software to correct this - it will be when this algorithm will be put into practice. BTW, my source is B/W too.

[jmac698]

This should do the trick:
http://pacific.mpi-cbg.de/wiki/index.php/BUnwarpJ

Could you post a sample? I might look at it.

[Ghitulescu]

It's very nice, I'll look for the DVD and maybe at the next weekend I'll be able to put it on the web, hopefully sooner..., 50MB would be enough?

[jmac698]

Too much even :) Only a few seconds are necessary.
Turns out that plugin may not work, it seems to want a reference image :( I couldn't find any software right now, but I'm sure there's at least one from a popular image processing platform.

[lordsmurf]

I'm quite well versed in restoration and forensic methods, thanks. What you want tends to ONLY work when an algorithm is designed specifically for the clip you have in mind. There is too much math involved for a program that could handle even a small sampling of scenarios. Yes, you can design a script or software to process a specific video, but it's only really going to work on that one video.

[jmac698]

Lord,
You have much experience and no doubt that is true. However, the paper to which I refer is only a year old, and a dramatic improvement over previous work (notably, Shake and Bake). In the tests, it was able to recover 100%. It's not always perfect of course.
It's unlikely the programs you have are using this new method.
This is one of the reasons I want to program it, because there's nothing out there and certainly not free.

[zilog jones]

That looks promising - I didn't go through all the paper so I'm not sure if this was already covered but how does it detect the edge of the active picture, especially in a dark scene or when there is a black object at the edge of the picture? It would be great to see some AviSynth (or even VirtualDub or ffdshow, I'm not picky :) ) implementation of this.

[Ghitulescu]

The algorithm can be substantially simplified, as no vertical vectors are needed, the software TBC should take care only of the horizontal jitter. Deshaker is another issue. However, it may become again complicated if one thinks of 3D procesing ....

[jmac698]

Hello,
Sorry to confuse you but I am talking about two algorithms here. The idea of edge detecting was mine, and indeed the idea would fail for black objects however, if you turn up the brightness enough you can see a darker shade of black than even black, and that itself can become the edge. I was going to try this myself because it was simpler.

As for the actual paper, it's more complex than that. It finds structure in a low order polynomial and tries to regularize that. Let me put it this way, if there's a line or a curve it will see that, and if it's jagged it will search for a pattern which makes it unjagged. Now of course a structure might be deliberately jagged however the algorithm looks at all structures in the pictures and minimizes the total jaggedness, which is most likely to be the targetted jitter and not something that's real.

By jitter I'm talking about each line being a little to the left or to the right as you go down, in a random pattern. This is caused by the motor not spinning at a perfect speed.

Like this:
1111111
22222222
3333333

Btw, sometime from now some random person will come by and ask is this done yet, aha another vapourware, well I'm not promising anything because the paper's algorithm is gonna be hard and it depends on my time and interest, but like I say if anyone wants to help...

[jmac698]

Sorry having troubles editing... dejitter is completely different from camera shake. This won't help shake at all.
And the diagram didn't come out:


11111
22222
33333


turns into:

11111
22222
33333


Here's a pattern it might see and try to fix:

* *
* *
* *

turns into:

* *
* *
* *


I hope that's clearer now.

[lordsmurf]

There's already a software TBC filter for VirtualDub, and it doesn't work well at all. Entirely useless from my tests with it. The detection is too imperfect, unlike on an analog signal, so you end up with a butchered video, ruined line by line. Are you aware of that one?

If you think you can make one, go for it, I wish you well. :) (But I won't believe it until I see it.)


I'm not promising anything because the paper's algorithm is gonna be hard and it depends on my time and interest, but like I say if anyone wants to help...
I'd help if I could, but that kind of math is outside my skill set. :eek:

The algorithm can be substantially simplified, as no vertical vectors are needed, the software TBC should take care only of the horizontal jitter.
When's the last time you saw a VHS video tape that was in perfect vertical alignment? The digital version sampling can sometimes cause bounce vertically too, small shifts along one line. And then the content itself will prove difficult to work with.

A TBC has to essentially lock both vectors, with a de-motion for vertical (without harming content!) and the de-jitter for horizontal (again, without harming content!).

I hate to feel like the killjoy here, but I'm just being realistic -- I'd be thrilled if somebody could create such a filter.

[NoX1911]

I think the reason you cannot have any software TBCs is that no capture card driver provides access to front and back porch (Austastluecke) of FBAS/CVBS. You always end up in 52µ (or 53.3µ) per line but the important part for TBCs would be in the 64µs area (like h-sync).

[jmac698]

I've come up with more ideas since then (a year already?), and yes you can access the hsync videos, for example with a bt8x8 card in virtualdub, the btx tweaker is already built in, the horizontal shift parameter can be tweaked until you see the hsync. There's also opensource drivers for most chips and you can tweak it all you like. I'm just amazed no one has written this software yet.
I also found another way to do TBC that's very simple and uses pure video, but it needs a few copies of it.
I also wrote a jitter simulator in another thread, it's called vcr simulator. So yes I'm still working on it :) I did finish one version I call a relative dejitter. It's meant for lining up multiple captures.

[NoX1911]

There's also opensource drivers for most chips and you can tweak it all you like. I'm just amazed no one has written this software yet.
The BT8x8 is the only chipset i know having open source drivers. Not quite sure about it but i guess the BT chips are dead already for years (not available anymore) so there is no point in writing such software today until there is suitable hardware available again.

I have a Philips SAA7134. If you know about any open source driver for it let me know.

[jmac698]

Yes, I think so. I had a quick look but didn't find it yet. There's some beta driver as part of Dscaler, and I found another mod of it that someone used to put together a special tweaked capture program. He was able to capture >1000 pixels resolution, and yes it did look better.
I can't access my files right now because my external enclosure is busted.

[jmac698]

I found what I was thinking of. It's not saa7134 but cx88. Sorry :( Still cool program though.
http://midimaker.narod.ru/eng/arc/cx88prg_2.zip

This program can use at least 1114 pixels per line. I've seen a screencap with it and it looks sharper.


To use this programm you should start preview or recording and start the programm from command line. To start the programm you should use such command line:

cx88prg.exe DeviceIndex PixelsPerLine HScale HDelay NotchFilter ColourSystem CombThreshold WhiteCrushOff CompClamp

DeviceIndex - CX2388x's card number (usually is 0 in the case of only one CX2388x card)

PixelsPerLine - number of pixels per line at videodecoder output. Pixels number is calculated on 64 microseconds interval for PAL/SECAM (and other 625/50 systems) and 63.5556 microseconds for NTSC (and other 525/60 systems). According to the CCIR 656 standard it is 864 for PAL/SECAM and is 858 for NTSC. Value should be in 640 - 1280 range.

HScale - the value of horizontal scaling register. The value is calculated as:

HScale = (Ku - 1) * 4096,

there Ku = PixelsPerLine / ScaledPixelsPerLine,

ScaledPixelsPerLine - number of pixels on full line after scaling. For example, if we need 640 pixels on active part of the line while videodecoder is programmed for 864 pixels per line (PAL), we should calculate as follows:

ScaledPixelsPerLine = 640 / 52 * 64 = 787,69 = 788

Ku = 864 / 788 = 1,0964467

HScale = (1,0964467 - 1) * 4096 = 395

HDelay - the delay in pixels from start of horizontal sync pulse to the start of active part of the line. This value is calculated relative to scaled pixels. For given earlier example it should be:

HDelay = 640 / 52 * 10,5 = 129

HDelay should be an even number.

NotchFilter - chooses one of 4 coefficients sets of notch filter to reject color carrier from luma signal. The values is in range 0 - 3. The value should be determined by experiment. This value affects only composite video sources.

ColourSystem - chooses color system. This value is used to determine color carrier and line frequency. Note that videodecoder is not automatically programmed to chosen color system. The value is one character. P for PAL, S for SECAM and N for NTSC

CombThreshold - adaptive comb filter threshold. Typical value range is 32 - 1023. The lower value, the less hanging dots on vertical transitions, but more blurring of high detailed areas. This value affects only composite video sources.

WhiteCrushOff - allows to disable adaptive AGC (this allows to avoid slow brightness increasing and then fast returning to original brightness and in the case of too dark or too bright image)

CompClamp - this parameter allows in some situations to reduce "ringing" on sharp edges. Below is an example for 27 MHz videodecoder decoding rate (image is enlarged by nearest neiborhood method).

[Ghitulescu]

Could you post a sample? I might look at it.
Finally got both the DVD and the time to upload a sample (being a commercial DVD, and the sketch so short, I had to upload only 5MB to observe the copyright laws).

http://www.megaupload.com/?d=PKL95HOV

The scene was analogue recorded and processed until it reached the digitizer (no film, no digital storage).

[jmac698]

Wow, I think there's a good chance of fixing that actually, the static background can be a reference point. I've been working at something else at the moment but I have a lot of the pieces I need to script this.

[pbristow]

*CHEERS* for jmac698's ongoing efforts. :)

It occurs to me one approach to this problem would be a tweak to MVTools: It already has a "horizontal only" motion detection mode; What it would need next is a way to define one or more complete video lines as a block, rather than a square-ish block as at present. (If we can do 32x32 pixels, then why not 1024x1? :) ) Then you feed it frames of video, each of which is a single line of the source (probably re-sized to a height of 4 or 8, to get around clip format restrictions), and let it mo-comp the entire line (frame) to an average of the previous and next lines' (or frames') positions. Re-stitch the lines back into frames, and see how it looks...

Is that anything like what you're doing?

EDIT: ...Or, of course, you use DePan rather than MVtools, since that's already designed to track and move whole frames instead of little blocks. [SLAPS SELF FOR MISSING THE OBVIOUS]

[Ghitulescu]

We are not discussing here HW TBCs, but whether it is feasible to implement one in software.

[tenantfile]

I didn't go through all the paper so I'm not sure if this was already covered but how does it detect the edge of the active picture, especially in a dark scene or when there is a black object at the edge of the picture?

[NoX1911]

Just a guess but i think the dedicated hardware devices do it by the 'h-sync pulse' that is like a white vertical line in the offscreen area. The problem is its even outside the 53.33µs area (the area the drivers for capture cards allow access to) so you cannot see it. Theoretically its just a driver issue...

[sven_x]

Suggesting a Software TBC using Cross correlation

Has anybody tried cross correlation function to find out which is the actual line offset?

I have thought a while about this issue. These are the results I came up with:

Cross correlation function in this case is something like
F(x) = 1/C * integral (f1(x - tau) + f2(x)

where
f1(x) are the pixels of the actual line, x are the pixel positions
f2 (x) are pixels of a reference line
C is a scaling constant
tau are the amounts of possible pixel offsets, ranging from -range … + range

The most important question is, which function (say line) could be taken as reference function f2.
The real goal is not to move the lines so that the fit best to their neighbours or to their predecessor / successor in time. The real goal is to get stable lines which begin all at the same point x.
That’s why I suggest using a master pattern of an ideal line begin as reference function f2. It will be something like ____------ (which is some pixels black followed by grey). Perhaps an averaged line (average of all even or odd lines of a frame) will give a better cross correlation which is less dependent from average luma of that frame.
Also the grey level of the reference line can be adjusted dynamically to the average grey level of the actual frame.

Because Pixel values in videos are in the range 0…255, both functions f1 and f2 have to be inverted, so that the black levels which are present in the beginning of the line get more weight.

Speed enhancement.
To get a fast computation cross correlation function is computed for the first, say, 50 pixels of a line only.
Getting a floating point result, factor C is not needed, because we’re just looking for the maximum value of the cross correlation. The value of tau we are getting is the offset the line must be moved to the left or to the right.
For cross correlation the missing pixels on the left and right can simply be filled with the value of the last pixel.

I think this might be a more stable approach then checking if Pixel color crosses a certain threshold which was suggested before in this thread, here (http://forum.gleitz.info/showthread.php?26949-MaskTool-amp-Kanten-stabilisieren&p=298467&viewfull=1#post298467), here (http://forum.doom9.org/showthread.php?t=162726), here (http://forum.gleitz.info/showthread.php?26949-MaskTool-amp-Kanten-stabilisieren&p=258635&viewfull=1#post258635) or with Dejitter. The stabilising effects of these plugins were fairly poor. Random VHS noise adds some element of chaos when a pixel value will cross a threshold. Cross correlation function better avarages the influence of noise.

The resulting value must undergo additional plausibility checks:
a) Line offset must be within a permitted range
b) Because jitter results from mechanical properties, jitter between two succeeding lines is relatively small, compared to the absolute jitter values that are possible in a single frame (the border where the lines begin is something wavy)
b2) borders between the even or the odd frames look rather constant for each group. Perhaps the resulting line offset values for even or odd frames could be stabilized by temporal avarage of some frames of the same group.
c) do nothing or take the average value of the two neighbour lines
c1) when there is no clear result
d) use a greater part of a line for correlation, when fast correlating of the border areas only gives no clear result (but here it must be ensured, that the line contains no moving areas)
…

What are your thoughts?

p.S. Cross correlation using fftw3.dll is not necessary, because cross correlation function must be computed for a few pixels only, which might be faster done in a direct way instead of using fft.

[jmac698]

Hi,
I've managed to tweak a driver and can now capture the hsync, just like a hardware TBC, so I should be able to do anything a hardware TBC does in software.
http://screenshotcomparison.com/comparison/86066
I've also worked out all the math in the Nikolova paper, except for one point I'm ready to code the algorithm. As for pbris' idea, I've tried that too, it turns out that the captures I have (and confirmed by one other person) are consistent between captures, so as I suspected there is already a line TBC active in the capture card, it just doesn't work correctly (however consistently). What I mean is, two captures of the same frame are lined up to each other.
I also have my splitbylines and correlation scripts to play with, and they could line some things up, most notably say a colorized vhs to a stable b/w dvd.
Anyhow as you can see, even with a good bright line or bright image it's still not working for me. The problem is somewhere else, not the noise. I'm thinking I need to line up both edges of the picture.
I've also recreated that russian's experiments and have digitized up to 1700 pixels per line. I can think of a way to digitize HD even with an ordinary capture card. It looks like noise when you try it, but there's a repeating pattern to the scrambled lines that you can fix. I've already captured the entire VBI area and 480p.

As to the question, how did the mathematical paper deal with a black edge, it has nothing to do with looking at edges, it analyzes the content of the entire lines and matches up the textures to each other.

[jmac698]

sven,
As to your correlation idea, what you want is a robust edge finder, even better to sub-pixel precision. There are many ways to do this, such as susan http://users.fmrib.ox.ac.uk/~steve/susan/susan/node8.html
I don't see that as the problem now because even in a test case, with a bright picture, the jitter was quite bad, much more so than the single pixel error that noise could have caused. Just look at my stills. (I have one lined just by active image edge and it doesn't look much better, even in bright areas).
However if that works on some of your samples, I could certainly make something for it.

@g
Ahh, I probably have the scripts to work on your sample now... but my experiments are more fun right now :)

[sven_x]

Now we're discussing in two threads.
Perhaps we should unite into one, because the things become clearer now. And we're getting closer to find a new algorithm.

In Dejitter script (http://forum.doom9.org/showthread.php?p=1530721) I have analyzed a screenshot with some VHS jitter, which gives some answers to my own questions in the post above.

Correction
I have imported the synced screenshot into photoshop. Line heigth was increased to 300% to get a better view.
Using a fixed selection window (720px x 3px) I copied each line into a new have layer and than manually shifted that line to a position that looked good.

The result is given below:
http://www.engon.de/temp/avisynth/jmac698_line_sync2.png

Conclusions
When a correction of the image could be done by eyes view it also must be possible to put that in a computer algorithm.


Lines from VHS grabbings cannot be synced by using what was regarded as sync signal
Lines from VHS grabbings can be synced using cross correlation between subsequent lines.
There is also a small jitter in line length, that needs an extra treatment.
The line offset jitter does not correlate very well to the beginning of the lines (which is the beginning of total black pixels) (but not as bad as to the sync signal)


This corrects my first suggestion. It seems that line begin is not a good reference to find the begin of a line. But a matching can be done by content (if it correlates to some degree the to the previous line).
Also a correction of line length should be applied (which seems to be about 1...2 pixels jitter only).

If the jitter has been reduced to a certain amount, more improvement could be achieved by using a NNEDI3 interpolation in even and odd frames with a weighted merging, that Didée has suggested here (http://www.movie2digital.at/index.php?page=Thread&postID=575522#post575522) (example images here (http://www.movie2digital.at/index.php?page=Thread&postID=575517#post575517)). His script works wonders.

[jmac698]

I posted Didee's comparison's here, http://screenshotcomparison.com/comparison/86447
That's just unbelievable...

[NoX1911]

Snowwhite pictures (http://screenshotcomparison.com/comparison/86066) look suspicious. The jitter is more or less constant in the 52µs area but there's a variable offset to the hsync from line to line. Looks more like there are dropouts in the porch area and the card doesn't really brute-sample continuously.

Edit: Where are the downloadlinks for the video?

[Ghitulescu]

Snowwhite pictures (http://screenshotcomparison.com/comparison/86066) look suspicious.

The non-software-TBCed video looks more "stable" than the TBCed one (mouse over) ;)
The algorithm must start from the end of the line towards its beginning, not viceversa.

[Mounir]

Perhaps THIS (http://www.compression.ru/video/old_film_recover/field_shift_en.html) will help for a great software tbc
I quote:
Free AviSynth filter for fixing situation when different lines of source frame are placed in different output frames. This often occurs during movie capture, when odd lines are one frame later than even lines

[jmac698]

Hi,
Try importing my test image and selectodd. You can see that interlacing isn't the problem.
A lot of people have been photoshopping! I feel sorry for that because I have a way to automatically measure jitter/stetch and to align, with subpixel precision. This will tell us a lot.
I need to make a better test image. I'm going to include a diagram to show where the front/back porch, hsync, and color burst are. I can capture again without setup/pedestal which will let me see this better. For now I will use straight lines so if you wanna plan with lining things up, it's easy.

[Perepandel]

Hi all!

Add me to the party... I came here some days ago after searching for "software TBC" in Google. I was so interested in the subject that I still want to program my own one, even I alredy transfered my VHS tapes using a VCR with an integrated TBC :P. But there's a lot of work I have to do yet.

I registered at first to contact jmac698 directly. Now I've realized the subject is hot enough to participate, plus I've discovered some of us seem to be overlapping our efforts (read "align by hand with Photoshop" here :D)

My current approach (after realizing that some more trained people than me is trying the post-captured video allignment :P) is at capture time. Let's see if we can get something useful!

[jmac698]

Welcome
:party:
Thanks for adding to the enthusiasm. I know that this topic has been discussed many times and never come to a good solution, and I'm not betting on the outcome, however I think there is something different here, that is having access to the hsync by using special chip access gives some hope. If this fails I want to understand it completely and prove that it fails, but remember one person's 'failure' is only relative to their skill level. I never want to discourage someone trying with a fresh approach. Don't give up until you feel you've done all you can do, and enjoyed the research and discovery in the meantime, after all, for programmers it's the challenge of the problem solving that is the goal, and the practical side-effect is just a bonus :)

Interlacing
I agree that interlacing should be taken into account; certainly different heads are involved and it's a separate period of time with possibly different jitter statistics; certainly not related to the lines in the other field. I feel that jitter should be linked due to the forces of momentum/rigidity. I have even measured the differences in heads in video signal quality before.
You bring an interesting resource to the mix, I'd like you to do some tests with your TBC as well.

Just hang on a few days, I'm working on a new set of tests. The really big analysis is going to take some time, I have an algorithm that works and is tested for sub-pixel alignment of a test signal; it's accurate to slight frequency changes (stretch), to noise, impervious to frequency response, but I haven't tested it's robustness to signal distortion.
In plain english, I need to record this test signal and run it through an analysis to determine the statistics of jitter, and stretch, the alignment to the hsync and picture edges. I need to examine how these statistics change over many generation copies, by tape speed, by VCR, even by capture card. If it's possible at all to line up anything, I should have the answer, if not, I can at least quantify some parameters for "intrinsic jitter", that is techniques to guess at lining up the lines.

[NoX1911]

I've shifted some lines (comparison) (http://screenshotcomparison.com/comparison/86825). The first faint yellow vertical line goes side-by-side with the global line jitter. I bet that's the hsync not the big vertical line.

HSync is 0V and below reference black voltage (0.3V) so it probably is -0.3V. The reason why it is so weak.

Whatever the big yellow line is it doesn't look like hsync at all. There is no relation to the global jitter that is constant before and after that big line. It's also suspicious that it is full white even though it should be 0V.

If you fix the picture by that first line you indeed get a corrected picture.

I would really like to know what hardware and driver you modified. Where is the discussion place for that mods?

[jmac698]

If you fix the picture by that first line you indeed get a corrected picture.

That innocent sounding statement is telling me - it actually works! I was just using the wrong line and need to enhance it more!
The 44 pixel or so area in green has been drastically brightened with tweak; that's why it's confusing you. I did notice the weak other line and that would be the rising edge of hsync. If I capture in NTSC_J I can avoid the pedastal; in other words capture lower voltages.

I'm afraid I had to spend the last hours writing a script to help create test signals (drawrect) and making a faster script to line up picture edges (fast line shifter). But I am almost ready to record another test :) Have other things to do though...
I have a prediction, stretch won't be much of a factor, because that should change the color tint along the line, and I'm not seeing that kind of problem (or unnoticeable). In other words, lining up just the left edge should be sufficient.

This will be exciting!

Perepandel in http://forum.doom9.org/showthread.php?t=162726&page=2

One of the problems would be the amount of pixels we could get per raw line or digitizing resolution. If we are limited to 800 and some, and we have to adquire the active video from it and translate the result to 720 pixels, then maybe we could get a lot of aliasing/lack of resolution, etc. But we should try it to see if it is acceptable or not. Also jmac698 said somewhere that he's able to get about twice per line that values, so in that case we'd probably have by far enough information to get good results.

All solved; we have the first report that it's actually working and we just used the wrong line. About the resolution, I can immediately capture 754 pixels which helps; this still doesn't give me 1:1 resolution for the active area though. There's two workarounds; perhaps further driver tweaking can get more resolution, or I'd have to make two passes; one for the left side+sync and one for the right side. I would put them together via correlation or motion tools. Remember this is optional and is only to get further sharpness. And also remember that VHS doesn't need such high resolution to begin with; the capture FAQ recommends much lower resolution. On the other hand I have measured the resolution of my S-VHS and I can distinguish 360 pixels (at least, I'd need higher capture resolutions to see the true limit).
Aliasing would be more of a problem of the hardware scaler in the capture card; they use oversampling and it's not at all likely that a tape based machine could overwhelm it.

[ronnylov]

Really interesting stuff you are working on! What kind of hardware do you use and can you share your tweaked driver so more people can join and try tweaking it further?

[smok3]

so basically a TBC needs to make the lines the same lenght (starting at the same point is just conclusion) i guess?

[Ghitulescu]

Not only, they also need to start at the same point. The synch pulse is recreated/replaced with a stable one. Colour burst is regenerated.

[jmac698]

If software there is no need for sync or color burst, they're just images. But in a hardware TBC, yes.

[jmac698]

I solved it. It's really simple.
http://screenshotcomparison.com/comparison/88691

for the script see
http://forum.doom9.org/showthread.php?t=162726
released

[markanini]

Wow. I've got loads of sources that will benefit.

[smok3]

I solved it. It's really simple.
http://screenshotcomparison.com/comparison/88691

for the script see
http://forum.doom9.org/showthread.php?p=1532392#post1532392
(not released yet, but soon)

do i get some shares? ;)

[Ghitulescu]

I solved it. It's really simple.
http://screenshotcomparison.com/comparison/88691

for the script see
http://forum.doom9.org/showthread.php?p=1532392#post1532392
(not released yet, but soon)

It's quite impressive.

It has the advantage over the real, hardware TBC, that it could repair 2nd, 3rd and nth generations of compounded timebase errors.

[jmac698]

gh, do you have a sample I can try?
Don't get too excited ppl, all I'm willing to say for sure is that I can capture and avoid the expense of a hardware TBC. Anyone serious has a hardware TBC anyhow so it's nothing new to them. The 2nd generation etc. might work if it shows some of the black.

[jmac698]

Script posted, bugs fixed, faster.
http://screenshotcomparison.com/comparison/88810

[Ghitulescu]

gh, do you have a sample I can try?

I remember I have somewhere a commercial DVD that wasn't TBCed (or it was but the tape used in the process was a non-TBCed nth generation). I see if I could upload a sample.

[ronnylov]

Script posted, bugs fixed, faster.
http://screenshotcomparison.com/comparison/88810

Nice results!

I can't find the script, where was it posted?