Crop bug in LeakKernelDeint

[Richard Berg]

Dunno if anyone still maintains this filter...

Using http://www.avisynth.org/warpenterprises/files/leakkerneldeint_25_dll_20050118.zip & AVS 2.56a, this script demonstrates the issue pretty clearly:

ColorBars(720,480)
ConvertToYV12
Crop(20,0,0,0)
LeakKernelDeint(order=1, threshold=10, sharp=true, map=false)


Learning how to use TDeint was my workaround :)

[Kika]

It's not only LeakKernelDeint, also EEDI2 has this bug.
A simple rule: Don't crob before deinterlacing/bobbing

[Richard Berg]

A simple rule: Don't crob before deinterlacing/bobbing
That's not very helpful. Aside from limiting the fundamental power of the script language, I prefer to crop as early as possible in order to (1) speed up the downstream filters (2) avoid feeding bogus data (overscan, VHS head noise, moving tickers uncorrelated to general camera motion, etc.) to them.

[Boulder]

Leak's been around from time to time. Hope he'll notice the bug report:)

[scharfis_brain]

1) never ever convert chroma before a deinterlacer without a good reason.
2) is cropping by non mod8 dimension that important?
A always use two step cropping. A raw one before all the processing and the fine one using a resizer afterwards.

[tsp]

what about Crop(20,0,0,0,align=true)?

[Richard Berg]

never ever convert chroma before a deinterlacer without a good reason.
I'm not converting, just generating a YV12 test clip the fastest way I know how. If I weren't lazy, I'd have passed an extra parameter to ColorBars.

A always use two step cropping. A raw one before all the processing and the fine one using a resizer afterwards.
I do. Even more often, I just nudge things until the "ideal" crop is mod8 :)

what about Crop(20,0,0,0,align=true)?
Still repros, just intermittently (subject to the whims of AVS caching).

[tritical]

It's not only LeakKernelDeint, also EEDI2 has this bug.
Could you post a script that causes the problem with EEDI2? I tried it with the script that Richard posted (which does cause a problem with leakkerneldeint here) and it was fine. Also, what type of processor does your system have? Thanks :)

[Kika]

It was a simple Test, and EEDI2 was used as an Bobber:

AssumeTFF()
SeparateFields().EEDI2(field=3)

Source was cropped while capturing (704x560).
After inserting an AddBorders(0,8,0,8) after the AssumeTFF-Line to get the full resolution of 704x576 back all was fine.

Processor is an old P4 1.9 Ghz (on Win98SE ... ;) )

[tritical]

Just a few questions... What were the cropping values used to get to 704x560? What colorspace was the capture in? What colorspace was the input to eedi2? What type of artifact was produced?

[Kika]

Cropping: 4 on top, 12 on bottom
Colorspace was always YUY2
Too bad, i can't provide a sample (it was a private Video... ;) ).
How to descripe the artifacts ... in fast movements, some picture arays do look like they have a wrong field order.