Kernel Deinterlace filters for Vdub

[pdottz]

are there any kernel type deinterlacing filters for virtual dub?
Ive been capping US ntsc broadcasts and they are interlaced. Ive been
scripting my avs files with the KernelDeInt(order=1,sharp=true) parameter in them. then loading them thru vdub to compress.
KernelDeInt does an awesome job for me, I was just wondering if there is a filter for vdub that will give me the same results and speed that KernelDeInt does through avisynth. the reason Im looking for one is that some of my caps have like 8 episodes per 90minutes. (tom and jerry cartoons) cutting them in vdub then converting the vcf to avs script and adding the KernelDeInt parameters loading them back into vdub and compressing is very time consuming. If I could find a filter that gives me the same speed abd quality, would be awesome. :)
if you have a link please post it.

[jimmy basushi]

curious, why do you only want to use rgb24? i thought most compressers converted to yuv12 anyway.. that would be the only reason i could see why you would want to use vdub's internal filters.

sorry i cant answer your question, im just curious...

[Guest]

Why do you have to cut them in VirtualDub? Why not do everything in your Avisynth scripts? You use the Trim() function to cut frame ranges.

What I do is serve the whole thing into VirtualDub, scan and write down the right cut points, and then edit the Avisynth script for those points.

There is not at this time any VirtualDub equivalent of KernelDeint(). :(

[pdottz]

actually here is the script I use for avisynth.
-----
LoadPlugin("C:\PROGRA~1\GORDIA~1\KernelDeInt.dll")
AVISOURCE GOES IN HERE
ColorYUV(levels="PC->TV")
KernelDeInt(order=1,sharp=true)
-----


and here's why.

http://members.cox.net/pdottz/comparison.jpg

using the above script without the ColorYUV tag makes the image look all washed out. using pixel_type="RGB32" is the same as ColorYUV for my caps anyways.
if there was an equal kerneldeint filter for vdub then I wouldnt use avisynth at all. ( avisynth causes the problem with the washed out colors for me so I have to use that tag if I want to use KernelDeint)

anyways. thanks for the replies. I'll try to see if I can tweak some other deinterlace filters to give me the same speed.
can anyone recomment a good filter?

[fccHandler]

With all due respect to neuron2, he wrote one a long time ago which IMHO is still superior to anything else I've tried, and that is the Smart Deinterlace version 1.7 for VirtualDub.

I believe it suffers from less artifacts than later versions (including KernelDeint), and I keep a copy here (http://fcchandler.home.comcast.net/Smart.zip) because people still ask me for it.

I only wish I had the source code... :(

[Guest]

Originally posted by fccHandler
I only wish I had the source code... :( I have it in my SourceSafe database if you really want it. Send me a PM.

You should be able to achieve version 1.7 functionality with appropriate settings in the current version. I'd be interested to know if that is not so.

[Wilbert]

( avisynth causes the problem with the washed out colors for me so I have to use that tag if I want to use KernelDeint)
It's not AviSynth that is causing this problem. It caused by the color conversion (rgb->yuv) by the codec which decompresses the video (keeping/changing the luma range), when opening the video in AviSynth. You didn't state what codec you use for capping, but I guess it is mjpeg.

[trevlac]

@pdottz

If I may comment on your washed out issue ....

1st some guesses on my part. ;)

- You cap using an mjpeg code (PIC maybe?)
- You are capping something like DishNetwork/DirectTV/Digital Cable s-video out from the receiver.

YUV color has a normal range of ~ 16-235. You are getting an input signal that is out of this range. Let's call it 0-255_YUV. PC RGB has a normal range of 0-255. This is always what you view on a PC. Your issue is all about what happens with the conversion from YUV to RGB, which may or may not do TV->PC.

1) Open in Vdub: Your codec converts from YUV to RGB. It does not change the range (aka no TV->PC). You now get 0-255 RGB. This looks good.

2) Open in AVS: Your codec provides YUV which is out of range. If you don't do any type of ConvertToxxx, AVS outputs YUV. Your OS then converts from YUV to RGB. When it does this, it does a TV->PC, which causes your outer range values to be lost. High Red (V) in the skin is higher than green/blue and is clamped down to the normal max value. The other colors are not as high and thus can go up proportionally more.

3) Open in AVS - do PC->TV: Just like #2 above, but now you pre adjust your out of range YUV back in range. So the TV->PC that happens when you see your YUV as RGB no longer clips red.

4) Open in AVS - do PixelType 32: Your codec converts from YUV to RGB without changing the range (no TV->PC happens). This gives you good looking RGB for PC viewing.

------------------------
So In the end ... Avisynth does not cause you a problem, your source is the problem and your codec kinda fixes it for you.

What to do ? The best thing would be to use an analog proc amp to adjust the signal before you digitize it. The easy thing is PC->TV so you can use YUV in AVS. You could also manually correct things using Tweak/Levels, but you'd have to measure what you have to get (maybe a little) more value than what PC->TV does for you.


Remember ... this was all a bit of guessing on my part. ;)
But maybe it will help you figure out a good method....

[pdottz]

I appreciate everyones help. Ill give smart deinterlace another try. anyone have some good settings to use?

trevlac.
you're right. Im using picvideos mjpeg codec for capture. and to get a good color output I have to specify in avisynth that the source is pixel
type rgb32 or use the colorpc-tv parameter. Until I get another harddrive to be able to use a lossless codec, this is fine enough for me :) thanks again.

[fccHandler]

Originally posted by pdottz
anyone have some good settings to use?
The default threshhold is fine for most things. To blend or interpolate, that is the question. IIRC, "blend" combines the fields, but may produce ghostly images. "Interpolate" expands one field to fill the frame, but may blur the picture too much. I generally use "blend," but "interpolate" might be better for toons. You'll have to try it both ways and decide which looks best to you.

P.S. We had a discussion about PicVideo's color problems on neuron2's forum (http://neuron2.net/ipw-web/bulletin/bb/viewtopic.php?t=288).

[pdottz]

yeah. I should've mentioned that any settings that dont include Blend. :)

[trevlac]

Originally posted by fccHandler
P.S. We had a discussion about PicVideo's color problems on neuron2's forum (http://neuron2.net/ipw-web/bulletin/bb/viewtopic.php?t=288).

@fcc ... you know I think the fact that mjpeg does not change the range is a blessing. If it did, the source would be clamped if pdottz asked for RGB, killing those out of range values. In fact, mjpeg is one of the few ways to get RGB with headroom.

Many knowledgable people have told me I'm talking out my rear. They are probably right. :D

[fccHandler]

Well, my simple gripe was that the output colors don't look like the input colors (at least in VirtualDub). I think your point of view has merit, though. It just depends on what you're using the codec for.