jmac's other plugins support page

[jmac698]

If you have questions about anything except TBC, don't be shy.

My plugins start here
http://forum.doom9.org/showthread.php?p=1581813#post1581813

Decomet - remove 'comets' from video tapes
taverage - temporal average of all frames
findpos - find pixels and return their position, by line
dejitter/jdejitter - crop/resize differently by line
jcorr - correlation between two frames
corrbyline - correlation between two lines
slicer - decode digital codes embedded in video
addcode - add digital codes to video
mandelbrot - make a fractal animation video in Avisynth

Update: all my plugins are under the New Plugins thread now.

[StainlessS]

Well done, I was hoping that you would get yourself a plug page.

Thankyou, will be a regular visitor.

:)

[jmac698]

These don't make anyone's encodes better, I think they will hardly be used, but they are more to support my larger scripts which will get updated in due time. Anyhow I was just wondering if you tried any, if the included demo scripts worked, and what version of Avisynth you used, and what OS. I think they should all work on 2.58 and 2.62, in xp and win7 x64. I'm not sure about the MT version, I had this installed before but got a lot of crashes so I've gotten rid of it for now.

[jmac698]

If you've got 2 minutes, you should try out my Mandelbrot filter. It's just pretty :)

[Groucho2004]

@jmac698
Is there a reason you're not releasing the source code? I would like to compile the Mandelbrot DLL myself statically so I don't have to deal with the MS runtime mess.

[jmac698]

That's one I especially wanted to release source for, however it doesn't work right now (if you check the relase notes).
But I can make static versions, I guess I should do that always now!

Update: static version posted.

[jmac698]

Updated decomet, slicer.

[jmac698]

Updated addcode.

[Emulgator]

jmac698, just in case you want to tackle an universal dotcrawl remover:
I have some ideas for that (Dotcrawl) that have never been used before.
It is ntsc or pal? Can we have a short clip?

--------------------------------------------------------------------
Dotcrawl description for evaluation of a forward compensation:

In stronger saturated parts of encoded NTSC (and probably PAL as well) 4:2:0 YV12 frames (pulldown ignored)
a scrolling 2x2 pixel checkerboard moiré becomes visible.

The fault lies in Y plane only !
Greyscale() (forcing U,V to 127) keeps the fault, Forcing Y to 0 or 127 shows clean U,V planes.

This fault is moving vertically through the lines stepping height down by 1-2-1, so pattern is repeating every 4 frames:

Frame 0:
Y of lines 0+1 modulated into positive direction
AND Y of lines 2+3 modulated into negative direction
Frame 1: (Fault steps 1 line down):
Y of line 0 modulated into negative direction
AND Y of lines 1+2 modulated into positive direction
AND Y of Line 3 modulated into negative direction
Frame 2: (Fault steps 2 lines down, so pattern is reversed to Frame 1):
Y of line 0 modulated into positive direction
AND Y of lines 1+2 modulated into negative direction
AND Y of Line 3 modulated into positive direction
Frame 3: (Fault steps 1 line down):
Y of lines 0+1 modulated into positive direction
AND Y of lines 2+3 modulated into negative direction.

I get the impression as if strong U,V gradients are leaking into Y
and modulate Y-values of neighboring 2x2 squares checkerboardwise in opposite directions under certain conditions.
Y values are modulated in 2x2 pixel squares, one square has its Y-value modulated to (Y+F),
the surrounding squares have their Y-values modulated to (Y-F).

For a vertical border at a given x the arithmetical mean value of Y-values in lines (n,n+1) and (n+2,n+3)
would give the correct Y-values,
the affected vicinity around the vertical border is +-3 to +-4 pixels wide.

The colour of the border element (blue/red) influences the phase !
At right border: skyblue and orange wings trigger different line pairs !

Local Condition: A contour where saturation (U,V) rises/falls more than a certain amount per pixel.
In vicinity of U,V deviating more than +-30(?) from 127(?) the fault occurs and the stronger the saturation, the stronger is F.

A purely saturated area does not exhibit this fault.

A strong chroma signal change is needed to watch this fault.
Strong vertical black/blue or black/red or black/orange or black/green borders will show best how it behaves.

Black/Grey/White changes do not trigger the fault.

A short sample is here:
http://www.dvd-manufactur.de/files/TC_VTS_01_3a.VOB

-----------------------------------------------------

For building an universal Dotcrawl remover I would suggest a 3-step approach:

Step 1: Forward compensation by manually finding of leaking thresholds, leaking radius and leaking coefficients (curves ?) for U,V.
While manually finding compensation coefficients Step 2 (spatial FFT Filtering) and 3 (temporal Filtering a la Didée) must be bypassed.

Step 2: Manually finding of FFT coefficients in F2Quiver/UV. While finding FFT coefficients Step 1 and Step 3 must be bypassed.

Step 3: Temporal compensation as in http://forum.doom9.org/showthread.php?t=165409

Then probably applying all 3 steps in sequence or independently, appropriate to the source.

[jmac698]

Mandelbrot updated.
This is funny:
http://forum.doom9.org/showthread.php?p=799667#post799667

I'll get back to you.

[jmac698]

If you see error 0x7E it means ERROR_MOD_NOT_FOUND

Install all the modules (libraries) that the plugin relies on. In the case of my plugins, that would be the VC runtime. I'm trying to migrate to creating plugins in a such a way that nothing external is needed. The plugins have worked for me on a separate computer, however I don't have a 64bit OS to test on (as I have some special equipment that only works in older systems).

I had a report about decomet not working, what I can do is make a new version in C++ with the new process that doesn't require anything external.

[StainlessS]

Jmac, this is one of the reasons I suggested linking to this thread from "new plugins & utilities' thread:
http://forum.doom9.org/showthread.php?p=1583470#post1583470

Your actual links should be here on first page, all in one place.

You will continue to get user responses in new plugs thread so long as it remains the way it is.

[jmac698]

But then so would anyone else who announces there...

[StainlessS]

Nope, many/most (the savvy) posts links to the plugins support thread.
EDIT: Should at least point to support thread if keeping direct link.

[jmac698]

Something new in development, might turn into a script. http://forum.doom9.org/showthread.php?t=165462 how to sync noisy video captures of the same video.

[jmac698]

jcorr updated, much faster.

[jmac698]

New plugin, findampbyline.

I've used it to do a frequency measurement on a VHS.
http://screenshotcomparison.com/comparison/137533

What you are seeing:
The first image is the frequency sweep. The first line is a single sinewave as luma. You can count the one bright spot in the middle.
Next it goes 2,6,10...a total of 35 frequencies, ending at 134 sines per line (or 2.5MHz). The approximate frequency in real terms is 18.75KHz * n.
The histogram to the right is not symmetrical; this means there was some clipping in the capture. The right side has been autocalibrated to 235 (max white), while the left side shows there was some clipping in the black. The lack of the symmetry about the middle shows some non-linearity (in fact the middle values are about +5 more than the input).

The next image shows the frequency response, as found by findampbyline(mode=1). Based on a levels calibration, where it hits luma=255 means the expected and flat frequency response. Instead there's a bit of a hump and it steadily declines.
When it passes the blue line in the histogram, that's the official cutoff for a bandwidth rating.
In this case, we're getting about .5MHz. The maximum frequency is about 2.75MHz (not shown). On the histogram area, the X axis is amplitude normalized to DC, the Y axis is frequency. Both scales are linear. Note that amplitude can be more than 1, if there's some peaking at a certain frequency. Accuracy is about 1% for the most part.

Ignore the two sudden drops, those are just glitches. It's a very experimental test. (They actually come from dropped frames - long story).

I'll do a much better calibration, and I'd like to measure all my devices this way, with an automated test.

I see so many people looking for test patterns and trying to come up with measurements with them. I think swept sines and resolution charts are useless! With my technique, all the measurements can be done automatically and plotted. I'd like to make a test DVD people can download to test all their equipment.

It looks like the tests will have to go in this order; capture window, levels/non-linearity, frequency response.
-
My plugins are just building a base right now, since there is sooo much missing from Avisynth. It will be after that that I can make some real progress in the filtering that everyone loves.

[jmac698]

Emulgator,
ok, I read your idea - I know exactly how dot crawl happens, and can create the exact formula for it. I could probably come up with something if I spent some time on it. Thanks for the explanation !

[jmac698]

Huhn - this is becoming a blog of sorts.

I think I learned something quite interesting today. I noticed the peak on my test of VCR frequency response. Next, I looked at the datasheet for a head amplifier. Three things I've learned;

1 I thought I could connect a digitzer straight to the heads and somehow get a better quality signal. In fact, the single chip head amplifier directly outputs the VCR signal, which means it demodulates the FM signal. So nothing as simple as touching a digital oscilloscope to a couple pins. Also, changing out this one chip for a better one might give less noise or different sharpness.
2 Some issues with layout can cause the peaking I've observed. So I know my VCR might not be good quality. I also know it can be fixed by soldering a single part. Or I can do this in software.
3 The head amplifier directly combines Y and C signals, so in fact having s-video in is pointless :( I want to check this with a few more chips. I've always wondered this; first I read that the "color-under" method means the signals are separate, but instead they are just separated by the amplifer. So I want to do more research.

[TheFluff]

New plugin, findampbyline.

What, exactly, are you trying to measure with this? It sounds like you're after properties of the analog signal itself and/or the analog recording equipment, and I really don't get why you'd try to measure that after the signal has been digitized.

[jmac698]

1 It can help with new captures
2 It can still help with old captures on the same system. You can go back and correct existing files.
3 The information in general helps with the design of new algorithms. It is a normal process of engineering to develop a model of the system so that you can analyze it's behavior. In this case, I can develop algorithm parameters that could work in general.

It seems to me that test disks like Avia sell well, so no doubt there is a big market for this kind of thing.

So what if I turn this into a test disk, and you record it into your computer. The computer then makes a test report for you and gives you the option to fix existing recordings, and makes the settings for new recordings for you? Would that interest you?

There is NO commercial, wizard style product on the market specifically targetted at the REAL VCR issues that come up, like dot crawl, dropouts, tracking noise, flickering colors, 2nd generation jitter, etc. Even at this late time, I'm sure there's still a big market for it.

pfClean, Neatvideo and others started out as articles on image processing by students, who then went on to develop companies around the algorithms. You can still get their articles and FREE versions of the software in Matlab.

[TheFluff]

I don't think you understood the question. I didn't ask why you're trying to measure whatever it is that you're trying to measure, even though that would be a good question (I still don't understand what you think it is you're measuring).

I asked why you're trying to measure properties of your analog signal recording equipment by examining a digitized signal. Digitization is far from a lossless process (especially not for this use case, where you're looking at a relatively small number of discrete samples of a continuous signal; you are familiar with the Nyquist-Shannon sampling theorem, I presume?), the digitization equipment itself is perfectly capable of introducing funny signal distortions, and at what sample rate are you digitizing the signal, anyway? If you want to measure stuff like how well your VCR preserves an analog input signal, then measure the analog signal you're interested in.

Also, I saw your post pre-edit and was highly amused by the "hardcore research" claim.

[jmac698]

findamp will measure the amplitude of an arbitrary, cyclic waveform.

My first use for this tool, is to robustly measure the amplitude of a sine waveform. I have tested the algorithm in the following situations;
-Cropping
-Clipping
-Noise
-Non-linear distortion
In those cases, I had 1% relative error.
Even though I've measured a digitized signal, I'm still able to get a precise result. It works by averaging many measurements. Most test equipment has gone digital anyhow.

Why do I want to measure the amplitude of a sinewave?
I already know the amplitude, but I record the sinewave to a tape and measure it again. I get a different answer. This shows me how the tape responds to different frequencies. Frequencies are related to sharpness in video.
I can now measure the distortions added by each piece of equipment. In the future, I will correct for each distortion. For example, you could check the box that says remove distortion for the saved profile of the TBC1000 in pass through mode, and then the picture is fixed.

I can measure the distortions in the capture card itself. And yes, there is some kind of reference I am comparing against, in my case I'm using a known accurate hd-dvd player.

The sample rate is 27MHz minimum, that's standard for a modern capture card. The bandwidth of a normal SD video is about 6MHz, but VHS is less than 3MHz.

Nyquist has been beaten. A recent development is compressive sampling. It is far below Nyquist. It's been used practically.

My previous post was unclear, I jumped around with different ideas. Simply, I've posted a test of VCR frequency response. I also have another test of ADC linearity.

There's nothing hardcore about findamp, but I was referring to projects in the background. For example I read research articles and use Matlab codes on videos. Even real researchers haven't solved jitter in 2nd gen tapes; the closest is Shake and Bake (seriously)
ftp://ftp.math.ucla.edu/pub/camreport/cam04-60.pdf

[TheFluff]

In those cases, I had 1% relative error.
Relative to what?

I can now measure the distortions added by each piece of equipment.
No, you cannot. You're putting your test picture through five or six different devices (each with its own quirks), converting it from digital to analog and back again and from NTSC/PAL to whatever modulation your tapes use and back again. You then act like you've made a great discovery when you find that this process greatly reduces the input resolution.

I can measure the distortions in the capture card itself. And yes, there is some kind of reference I am comparing against, in my case I'm using a known accurate hd-dvd player.
What in the Christ does a "known accurate HD-DVD player" have to do with measuring analog video signals? What do you even mean by "accurate"?

The sample rate is 27MHz minimum, that's standard for a modern capture card. The bandwidth of a normal SD video is about 6MHz, but VHS is less than 3MHz.
If you sample at 27MHz you get 1404 samples (pixels) per line for PAL video. If your card does indeed sample at 27 MHz, then it obviously downsizes the image afterwards, introducing yet another interesting potential error source.

Nyquist has been beaten.
uh huh

Simply, I've posted a test of VCR frequency response.
I'm not sure what exactly what findampbyline actually measures, but I'm pretty damn sure it's not the "frequency response" of your VCR.

[jmac698]

Hello,
Relative Error is a mathematical term. Please see http://www.wikihow.com/Calculate-Relative-Error.
My absolute error is 1. The size of the thing I'm trying to measure is 110. Therefore my relative error is less than 1%.

The devices I'm putting the test signal through are HD-DVD to capture card or HD-DVD to VCR to capture card. Once I measure HD-DVD to capture card, I have the distortion profile of the capture card, relative to the HD-DVD. I know the profile of the HD-DVD due to a professional measurement *1. Next I measure the profile of the VCR. I can subtract profiles to separate them. Although it's true that each device is complex in itself, I'm using a principle of engineering that treats it as a single black box. This is a standard approach. (http://en.wikipedia.org/wiki/Lumped_circuit_abstraction) I'm not interested in measuring each part of the VCR anyway, just it's total effect

I should note that there is an absolute reference here as well - the test signal itself. The uncompressed video of the test signal gives a perfect frequency response. The test of an analog capture of the test signal from the HD-DVD gives a perfect frequency response, in the first 3MHz. So there is actually no need to worry about the accuracy of the HD-DVD any further, or even to subtract it out. This is what I mean by accurate, for this test. The combined effect of HD-DVD and capture card in this test, to the first 3MHz, is 0.

If your card does indeed sample at 27 MHz, then it obviously downsizes the image afterwards, introducing yet another interesting potential error source.

I can check the crystal on the card to confirm it. The card is using a method called 2x oversampling. This is an accurate and modern way of sampling with good results. There is error of course, but it's a roundoff error only, and the math is done with 24 bit precision. The samples themselves are in 10 bit precision, which are then rounded up to 8 bit precision for the PC. The total error for this "resizing" process is inconsequential.

Worst case error is normally specified for electronic parts, in the datasheet. It's actually tested by the QC department to meet the specification (for the main chip itself). That's irrelvant though, as the whole capture card has it's own error.

Take a look at RMAA which does the same thing but for audio. It's used by many websites to test frequency response of audio cards. It also incorporates the idea of subtracting profiles. http://audio.rightmark.org/products/rmaa.shtml
Before you say that audio has nothing to do with video, what I mean is that it works on similar principles, and in fact I can use this exact program to measure video. For example, the next plugin I plan to write converts video one for one into an audio signal, then I can use RMAA to test video. It's just numbers to the programs. If I get a similar measurement to my own program, I can have more confidence in the measurement.

*1 Professional testing of my HD-DVD player http://www.hdtvmagazine.com/reviews/2008/05/toshiba_hd-a3_hd-a30_hd-a35_hd_dvd_and_sd_dvd_players.php
During testing, the Toshiba excelled, with the DVE test patterns outperforming our reference OPPO DV-981HD for the SD DVD format.

The link has changed to
http://www.hdtvmagazine.com/reviews/2008/05/toshiba-hda3-hda30-hda35-hd-dvd-and-sd-dvd-players.php
and the wording seems to be different

[TheFluff]

Okay, so let me get this straight: you're trying to measure how accurately an analog video cassette playback device reproduces a given input signal, in a way that involves generating the input signal within the device itself. Wait a moment...

Surely you must realize that you can't pretend the VCR is a black box when it's actually processing the signal in two different ways and you're only trying to measure one of them? I mean, you have a high resolution signal that you input to a downscaling device which discards a lot of its resolution (i.e. you record the high resolution signal to tape). Now you input this reduced signal to an upscaling device (i.e. you play it back) that may or may not discard further resolution and/or introduce other artifacts. Now you want to know how the upscaling device affected the original high resolution signal, and the answer is you don't have a clue, because you can't tell the downscaling and the upscaling apart.

Sure, if you only ever play back tapes you recorded on the particular VCR you're measuring (using the same inputs for recording that you use for testing) you'll get some kind of measurement of how recording and playing back on your particular VCR unit affects high resolution signals (disregarding other error sources; I'm not so impressed with your attempts to eliminate them), but somehow I don't think that's what you're really after.

[jmac698]

Great! You're getting it. I've measured the total 'black box' distortion of the VCR when recording and then playing back a signal, combined. In reality, a practical case of this is when I used the same VCR to record rare TV episodes off cable years ago, which haven't been released to DVD, and now I want to digitize them in good quality. This is the process of restoration, which means returning something to as close as it's original state as possible (enhancement is just about making it look better). I've done one step of restoration. It also happens to look better, because VCR distortions look bad.

I can't remove the distortions of the TV tuner or the cable system or the TV station's VCR. I'm only removing distortions within the limits of the VCR. It's the equivalent of a VCR of ideal quality.

You're right about the VCR throwing away most of the high resolution test/source signal. That's a given. I'm dealing with optimizing what is left.

Just think of an equation, (source)+(black box)=(capture). If I know (source) and (capture), I can find (black box). When I know (black box), I can take (capture) and solve for (source) - IF the (black box) remains the same.
Actually I should say in this case, video file+mpeg2 encoding+hd-dvd+capture card+algorithm compared to video file+mpeg2 encoding+hd-dvd+vcr rec/playback+capture card+algorithm, where I've proven that algorithm=0, mpeg2 encoding=0, hd-dvd+capture card=0. I'm left with just vcr rec+playback. And I don't really mean 0's there, just insignificant or below 1% relative error.

The only detail is following the math of how I do this and believing in it.

Warning - I'm going off on a tangent again:
The same principle could be applied to commercial tapes as well. I've done an experiment with this (not talking about findamp here). I bought 3 copies of the same commercial video tape (don't worry they were only $1 :). The idea is that each of these was made from exactly the same source - a master digital copy feeding a duplicator. Each copy of the tape looked a bit different, but if I average them all together, they should become a little bit closer to the original source. This was a practical experiment as well, because that tape hasn't been released on DVD either. Also it's only 10 minutes long, so I wasn't spending hours at this. It's just an experiment, there's few videos that would be worth it.

I could also come up with tests to measure a TV tuner, but there's different kinds of distortions here and I'd need to come up with new ideas.

Here's a simple example of how I could use a black box measurement system. It's also a real example and I used this in my script with findamp as one of the steps. They are also realistic numbers.
I have (source)+(black box)=(capture). The secret answer for (black box) is 1.1*x+10, which is an example of a passthrough device that increases contrast and brightness slightly.
I feed the blackbox these known numbers: 20, 100, 200. I get this coming out: 32, 120, 230 (these would be luma values, I used AverageLuma() in my script).
The formula to solve this is contrast=(Yout2-Yout1)/(Yin2-Yin1). I substitute (230-32)/(200-20)=198/180=1.1. I've correctly solved the black box contrast.
The formula to find brightness is: brightness=Yout1-Yin1*contrast. I substitute 230-200*1.1=230-220=10.

This screws up if there's noise. So I use many pixels (over 1000) and run the formula on each pixel, then average the results. Because I've used 1000 measurements, I've reduced the error to .1%. This is by far enough to completely eliminate noise from the measurement.

I use the same process to check the distortion between the source and the capture card. I can even use the source to measure the distortion of the algorithm itself, due to roundoff errors. Both of these are very small. The black box measurement by far dominates the numbers.

Now for the findamp calculation. I'm not going to go through the whole calculation of the plugin, but I've proved it mathematically. It needs at least 8 measurements to reach full performance, meaning less than 1% relative error regardless of noise, non-linearity. or cropping. Clipping needs a bit more.

[lordsmurf]

If you have questions about anything except TBC, don't be shy.

My plugins start here
http://forum.doom9.org/showthread.php?p=1581813#post1581813

Decomet - remove 'comets' from video tapes
taverage - temporal average of all frames
findpos - find pixels and return their position, by line
dejitter/jdejitter - crop/resize differently by line
jcorr - correlation between two frames
corrbyline - correlation between two lines
slicer - decode digital codes embedded in video
addcode - add digital codes to video
mandelbrot - make a fractal animation video in Avisynth

Update: all my plugins are under the New Plugins thread now.

I really hate that all of jmac's filter downloads have disappeared now. :(

[StainlessS]

Sendspace deletes files not downloaded for (I think) 30 days.

[jmac698]

I noticed that, but the TBC filter is still available for some reason. I thought maybe they rate files by their use and keep them longer. Anyhow, I've also lost them, so I'd have to write them all over again, and indeed I'm learning how to write plugins all over again.

rt_stats now does some of the functions, but I wish I had the tbc source.

[Reel.Deel]

@jmac698

I believe I have most of those plugins. Do you mind if I upload them?

[StainlessS]

Jmac, I was down to only 2 files left on SendSpace (out of 29), have just updated.
Suggest keep an alternative file host, I still prefer MediaFire (despite it insisting on downloading an immense jpg when newly logging in),
other people have complained about advertising on MediaFire, but I dont seem to have that problem (Firefox ad and pop-up blockers installed).
But at least MediaFire dont delete your files and I have rarely had download problems with the site (only twice I think).

[jmac698]

Sure, of course :)

[Reel.Deel]

Ok here they are:

addcode02.zip (https://dl.dropbox.com/s/yaj13afjr5ttpd8/addcode02.zip)
corr03.zip (https://dl.dropbox.com/s/rjnwwz94izl4pyd/corr03.zip)
decomet04.zip (https://dl.dropbox.com/s/67iybsgmah7hnnj/decomet04.zip)
dejitter03.zip (https://dl.dropbox.com/s/1c09rcpbjwmzfd6/dejitter03.zip)
findpos02.zip (https://dl.dropbox.com/s/hpk9n9wkr2i10g6/findpos02.zip)
mandelbrot01a.zip (https://dl.dropbox.com/s/sfyiiir2ptqv6eu/mandelbrot01a.zip)
slicer02.zip (https://dl.dropbox.com/s/n2j8tdhz092m2la/slicer02.zip)
taverage 01.zip (https://dl.dropbox.com/s/9lzco9qggolza64/taverage 01.zip)
taverage 01 src.zip (https://dl.dropbox.com/s/m45ryrmub2zvgxk/taverage 01 src.zip)
tbc061.zip (https://dl.dropbox.com/s/3epcmnd5pyk7xrt/tbc061.zip)

[jmac698]

Thanks :) I was thinking of hosting it on dropbox myself. I'm pouring over my source atm. I have an idea for the next project now, it seems like a plugin framework API would help me (and others) a lot. My idea is to have classes that work on all pixel types, starting with something very basic like pixel.moveright;, then it can handle even 16bit video. I want the programming to be as simple as possible, you shouldn't have to know anything about pixel layout or such, except whether it's rgb or yuv.

So I want things like universal pixel sizing, math operations, iterations, and even automated argument checking and error messages in multi-languages. That would be the ideal, amitious goal, that is. But I can see a lot of possibilities in C++ for this kind of abstraction, so it helps me learn the language.

[jmac698]

So much for that idea, I think I'll find vapoursynth easier to work with now.