Software TBC

Ghitulescu · 10th February 2010, 17:20

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

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/archi...e-t293462.html and http://forum.videohelp.com/threads/2...-Does-It-Exist. And the doom9s' own threads (http://forum.doom9.org/showpost.php?...25&postcount=1, http://forum.doom9.org/showpost.php?...38&postcount=1, http://forum.doom9.org/showpost.php?...15&postcount=1).

lordsmurf · 11th February 2010, 10:00

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). 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 · 15th February 2010, 01:25

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 · 15th February 2010, 08:54

Quote:

Originally Posted by jmac698

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/filead...lova/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 · 15th February 2010, 15:49

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 · 15th February 2010, 15:55

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 · 15th February 2010, 16:26

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 · 15th February 2010, 17:14

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 · 15th February 2010, 18:18

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 · 15th February 2010, 19:03

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 · 16th February 2010, 08:37

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 · 16th February 2010, 21:19

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 · 16th February 2010, 21:28

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:

Code:

     11111
22222
  33333

turns into:

Code:

11111
22222
33333

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

Code:

     *    *		
 *   *
    *  *

turns into:

Code:

*    *		
 *   *
  *  *

I hope that's clearer now.

lordsmurf · 17th February 2010, 13:04

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.)

Quote:

Originally Posted by jmac698

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.

Quote:

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 · 11th February 2011, 20:10

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 · 11th February 2011, 21:04

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 · 11th February 2011, 21:59

Quote:

Originally Posted by jmac698

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 · 13th February 2011, 02:52

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 · 5th March 2011, 01:45

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.

Quote:

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 · 21st April 2011, 13:45

Quote:

Originally Posted by jmac698

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).

10th February 2010, 17:20	#1 \| Link
Ghitulescu Registered User Join Date: Mar 2009 Location: Germany Posts: 5,773	Software TBC I wonder if such any improvements exist, after so much time (2005-2006) 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/archi...e-t293462.html and http://forum.videohelp.com/threads/2...-Does-It-Exist. And the doom9s' own threads (http://forum.doom9.org/showpost.php?...25&postcount=1, http://forum.doom9.org/showpost.php?...38&postcount=1, http://forum.doom9.org/showpost.php?...15&postcount=1).

11th February 2010, 10:00	#2 \| Link
lordsmurf Registered User Join Date: Jan 2003 Posts: 124	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). 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. __________________ Back in town. If you want my advice, then find me at the DigitalFAQ forum. Glad to assist.

15th February 2010, 17:14	#8 \| Link
lordsmurf Registered User Join Date: Jan 2003 Posts: 124	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. __________________ Back in town. If you want my advice, then find me at the DigitalFAQ forum. Glad to assist.

16th February 2010, 21:28	#13 \| Link
jmac698 Registered User Join Date: Jan 2006 Posts: 1,869	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: Code: 11111 22222 33333 turns into: Code: 11111 22222 33333 Here's a pattern it might see and try to fix: Code: * * * * * * turns into: Code: * * * * * * I hope that's clearer now.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

15th February 2010, 01:25	#3 \| Link
jmac698 Registered User Join Date: Jan 2006 Posts: 1,869	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.

15th February 2010, 15:49	#5 \| Link
jmac698 Registered User Join Date: Jan 2006 Posts: 1,869	This should do the trick: http://pacific.mpi-cbg.de/wiki/index.php/BUnwarpJ Could you post a sample? I might look at it.

15th February 2010, 15:55	#6 \| Link
Ghitulescu Registered User Join Date: Mar 2009 Location: Germany Posts: 5,773	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?

15th February 2010, 16:26	#7 \| Link
jmac698 Registered User Join Date: Jan 2006 Posts: 1,869	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.

15th February 2010, 18:18	#9 \| Link
jmac698 Registered User Join Date: Jan 2006 Posts: 1,869	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.

15th February 2010, 19:03	#10 \| Link
zilog jones Registered User Join Date: Mar 2004 Location: Ireland Posts: 481	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.

16th February 2010, 08:37	#11 \| Link
Ghitulescu Registered User Join Date: Mar 2009 Location: Germany Posts: 5,773	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 ....

16th February 2010, 21:19	#12 \| Link
jmac698 Registered User Join Date: Jan 2006 Posts: 1,869	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...

11th February 2011, 20:10	#15 \| Link
NoX1911 Registered User Join Date: Aug 2003 Location: Germany Posts: 186	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).

11th February 2011, 21:04	#16 \| Link
jmac698 Registered User Join Date: Jan 2006 Posts: 1,869	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.

13th February 2011, 02:52	#18 \| Link
jmac698 Registered User Join Date: Jan 2006 Posts: 1,869	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.