PDA

View Full Version : @trbarry: Request for TomsMoComp


bilu
28th August 2003, 18:53
Hi,

I usually don't encode anime but I've been making tests for the last two months. I have a problematic Neo Genesis Evangelion clips that never worked so good with Uncomb/Decimate or Telecide/Decimate as it is now working with SmartDecimate, which leaves combs behind but has no backward match or blended fields match stuttering problem.

I have been testing a lot of deinterlacers as post-processors for SmartDecimate.

FieldDeinterlace blurs too much when blend=true.
FD(blend=false),DGBob,KernelDeint,TomsMoComp all had the same problem: jagged edges, like lower resolution.

Having read this on your TomsMoComp readme:

For Avisynth only, a value of -1 is supported. In this case the TomsMoComp filter will not deinterlace but instead assume you already have progressive frames but want to double the vertical size. I found by accident that this could give slightly better apparent detail than regular scaling algorithms and is useful for low bit rate captures that are hard to IVTC/deinterlace or where you have just kept the even fields for some other reason. I'm considering making a DirectShow version of this to be run at display time, or possibly adding it to ffDshow.


And tried:

b=DGBob(FOrder(),mode=1)
SeparateFields()
SmartDecimate(24,60,b,0.50)
TomsMoComp(FOrder(),-1,0)
SeparateFields()
SelectEven()

The moving parts looked far better than any other deinterlacer I tried, like better resolution, but the static parts looked worse.

Would you consider making a static protection threshold like the one in KernelDeint? ;)


Bilu

neuron2
28th August 2003, 19:39
Tom claims that it is already suppposed to not touch static areas. But it is a known bug that it does so. So you are really asking him to fix that, but it's been asked before. I was going to look at it but haven't found the time/energy for it yet.

vinetu
28th August 2003, 22:37
OT
@neuron2-Nice to see you here again!!!

vinetu

bilu
29th August 2003, 00:18
Originally posted by vinetu
OT
@neuron2-Nice to see you here again!!!

vinetu

I agree. ;)


Bilu

bilu
29th August 2003, 05:00
http://neuron2.net/ipw-web/bulletin/bb/viewtopic.php?p=1357#1357

This method has been proven flawed.


Bilu

JuanC
29th August 2003, 06:44
Originally posted by vinetu
OT
@neuron2-Nice to see you here again!!!

vinetu
I'll drink to that... some wine... ;)

trbarry
1st September 2003, 18:41
Tom claims that it is already suppposed to not touch static areas. But it is a known bug that it does so. So you are really asking him to fix that, but it's been asked before. I was going to look at it but haven't found the time/energy for it yet.

How well TomsMoComp recognizes static areas does not apply in this case since with the -1 option it just doubles the vertical size. The loss of detail or extra jaggies on static areas is because you are using only one field with the -1 option instead of both of them. So there will never be as much detail from, say, 240 lines as there would be from 480. I still mostly recomend TomsMoComp(?,5,1) for most everything as the best compromise.

And sorry for the late response. I've been moving and without net access for a few days. I probably missed a lot of things.

- Tom