View Full Version : Stupid ghosting effects
unknownx
8th December 2002, 01:02
hey guys, i need help with some ghosting problems i encountered.
the dvd source is a PAL, and i want to encode the movie to xvid.
i made the d2v file by selecting the field operation- none. The
movie is interlaced. I also choose Swap Field Order, but it was
still interlaced- so i changed back to 'none'. When I selected
the Color Space, I realised that RGB was giving me an interlaced playback in dvd2avi, but when i choose YUV, there was no interlacing
at all. Overall, I choose YUV, because the tutorial told me to use
it. After loading the d2v file in Gknot, I saved the avs file,
using 'Fast Deinterlacing' default settings. I loaded the avs file
in VirtualDub, and searched through frame-by-frame, and realised that
there was some ghosting effects happening even though there were
no interlaced lines. So, i tried to change the avs script abit,
and this is what i came up with:
LoadPlugin("C:\PROGRA~1\GORDIA~1\mpeg2dec.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\decomb.dll")
mpeg2source("C:\new\[divx-ripping-tools]\dvdsource\oloa\oloa.d2v")
Telecide(Blend=false)
FieldDeinterlace()
crop(8,7,704,560)
BicubicResize(544,304,0,0.75)
after encoding this, using this avs script, the avi showed hardly
any ghosting effect but the movie was so jumpy.
Can someone please explain what i am doing wrong? or what i should try?
manono
8th December 2002, 17:16
Hi-
OK-I'll take a stab at it. Your jumpiness is caused by Blend=False. You don't need FieldDeinterlace as you already have deinterlacing in the previous line (Telecide has it in by default-in the Telecide line you have interpolation now, and in the FieldDeinterlace line you have blending-2 kinds of deinterlacing).
Don't use FastDeinterlace-it's lousy. I'd suggest not using FieldDeinterlace and just going with:
Telecide(Guide=2)
Alternatively, you might try the GreedyHMA Deinterlacer built into GKnot, or TomsMoComp and see if you like them any better.
TheWEF
11th December 2002, 06:33
Originally posted by manono
Don't use FastDeinterlace-it's lousy.
are you the guy who's never seen a PAL dvd? ;)
IMHO VerticalReduceBy2 (=FastDeinterlace) is ok for PAL because there are 20% more lines available. after reduction there are 288 left. it's fast as hell and a 100% save method. i "always" use it. and i'm not the only one who even thinks that the result very often is more pleasing to the eye than through other filters (ask doom9).
VerticalReduceBy2 is a great push for compressibility. of course in some cases you really loose detail. mostly it depends on output framesize whether its wise to use it or not. but if you are encoding at the limit it's usually a good choice. if the material is anamorphic you shouldn't think twice.
actually i can't think of a way any deinterlacer can get rid of a ghosting effect that doesn't go away with VerticalReduceBy2. maybe neuron2 or someone could shed light on this?
wef.
manono
11th December 2002, 08:36
Hi WEF-
I think if I'm going to cut the vertical resolution in half that I'd rather use something like:
SeparateFields()
SelectEven()
Then, unless the blending is in the fields to begin with, you've gotten rid of the deinterlacing without any ghosting at all. And yes, I've never seen any PAL DVDs (spying on me, eh?:)), but I've seen plenty of badly sourced and interlaced DVDs and plenty of bad PAL to NTSC conversions. And your point about PAL's greater vertical resolution to begin with is a good one.
I think the main problem with FastDeinterlace (aka VerticalReduceBy2) is that you've got all of the blending that you might get with something like FieldDeinterlace(), but with half the vertical resolution (before resizing). So it is not at all selective about what gets deinterlaced. Yes, there can be drawbacks to adding the 2 lines I mentioned above to the script, including a shimmer sometimes. But if the source is so bad (and you're using a low enough resolution), it can sometimes be the lesser of many evils. It just depends on the situation, and what looks better to the encoder.
I believe that DJ Bobo prefers to add BlendFields() to his scripts in similar situations. And if I can speak for hakko504 (who's certain to see this and is perfectly capable of speaking for himself), I believe he prefers TomsMoComp, with GreedyHMA's deinterlacer a second choice among the commonly used ones.
But the original poster, unknownx, has spotted the 2 problems of the 2 main forms of deinterlacing-the ghosting of the blending deinterlacers such as FastDeinterlace, and the jumpiness of the interpolating deinterlacers such as Telecide(Blend=False). Of course there is no easy answer to the problem, and unknownx can only try out the various solutions and see what looks best to his eyes.
And perhaps I spoke too quickly to condemn FastDeinterlace since, as you said, it's a fast and easy solution to the problem. So, I apologize to you and Doom9 and others that see it as one answer to the problem.
Speaking of neuron2, I believe that he's leaning towards incorporating TomsMoComp into Telecide one of these days.
hakko504
11th December 2002, 10:46
@manono
I think you missed the argument neuron2 and I had in the AviSynth forum last night (http://forum.doom9.org/showthread.php?s=&threadid=40044). Don didn't like the fact that I bashed fielddeinterlace every now and then, and quite frankly he has a valid point. For high quality you should be careful when using TomsMoComp. It has some bugs that might produce strange artifacts sometimes, especially with high settings like (1,15,1). It is also prone to oversmoothing the picture but this makes the final video very compressible so if you're aiming for low bitrate I still think it is worth looking at. And yes, I quite like Greedy as deinterlacer. fielddeinterlace has it's points, especially if you have the time to go through the video time after time in order to find the optimal thresholds and creating manual overrides. In fact, if you intend to keep full vertical resolution, which I almost never do, this might be the preferable solution. The Smoothdeinterlacer is also a very good solution, and have in my recent tests (partly quoted last night) presented me with the best visual quality. I think this may be because it uses bicubic interpolation instead of linear, and that it has the best motion estimation algo.
And whether the quick and dirty solution should be Verticalreduceby2() or Separatefields.selecteven() is easily settled when you open those two scripts in a viewer, as long as the final resolution is quite low. Neither should under any circumstances be used for high resolution video. It should be obvious that the later produces a ghost-free sharp image, enjoyable both on TV and monitor.
manono
11th December 2002, 11:15
Hi hakko504-
Yes, I think I missed it. I guess I should have a look. I'd love to see a good debate between 2 of the people I most admire around here.
When I first tested TomsMoComp. I was put off by the speed drop with (1,15,1), so I always used (1,5,1) with half way decent results. It was only later that tbarry reported the problems with (1,15,1). So I guess I got lucky.
Edit: I just got back from that thread. Very informative. I have to apologize for putting words into your mouth saying you recommended TomsMoComp (my information is old, I guess). And I guess I'll have to investigate SmoothDeinterlace now. But what I wrote previously in this thread wasn't too far off base, and I did write it before reading what my betters had to say on the subject.
Any of you out there in GKnot Land wondering about deinterlacing should study that thread hakko504 linked to.
N_F
11th December 2002, 11:59
Yeap. It's always nice/interesting to read a discussion between two nice and knowledgeble people.
hakko504
11th December 2002, 12:42
Let's not forget the main point:
Everyone have their own idea about what they think look good.
It may also depend on how you intend to use the final video.
All the different deinterlacing methods have their advantages and disadvantages.
Which one you should use depends on what compromises you are willing to do.
Quick overview of methods
SmoothDeinterlacer
+ Good quality with little work
+ Only true smartbob solution available (optional)
0 can choose blend/interpolate
- creates large files
- Not available (yet) in YV12
GreedyHMA
0 Reasonable quality and not too large files
- Not developed anymore
- Not available in YV12
TomsMoComp
+ Small files, very compressible
- Smooths whole picture a lot. Might not always be desireable.
- Have a few minor bugs that will create artifacts
FieldDeinterlace
+ Good quality possible after tweaking
+ Only deinterlacer that can be manually adjusted frame by frame
0 can choose blend/interpolate
- Requires tweaking, or quality can be a dissappointment
- Tends to create large files
Fast Deinterlace, aka VerticalReduceBy2()
+ Fast
0 will create blending/ghosting
- will deinterlace all parts of the picture
- halves the resolution: should not be used for larger final resolutions as it may create shimmering.
Separatefields.selectEven()
+ Fast
+ Will not create any artifacts (with exception as noted below)
- will deinterlace all parts of the picture
- halves the resolution: should not be used for larger final resolutions as it may create shimmering.
Telecide has been excluded from this list because it shouldn't be used on truly interlaced material. It is intended to correct fieldshifts and telecining, not actually deinterlace the picture.
When I speak of large files I mean the total filesize that would be created if we would use a fixed quantizer of 2 in DivX5 or XviD, also corresponding to the first pass of a two pass encode. Thus a larger filesize means a lower % in the compression test.
neuron2
11th December 2002, 14:08
Originally posted by manono
Speaking of neuron2, I believe that he's leaning towards incorporating TomsMoComp into Telecide one of these days. Lots of people like TMC and it is a fine filter. Several people have asked for it to be usable as a postprocessor for Telecide. My thinking is rather than incorporating it directly into Telecide, which is problematic because it needs to see the previous frame and the design of Telecide would need to change, I could modify TMC itself to add a little front end that checks whether the frame is combed and returns right away if it isn't. If it is, the filter runs as normal. Of course, I would coordinate with Tom and get his permission.
neuron2
11th December 2002, 14:14
Originally posted by hakko504
For quality you should not use TomsMoComp.Oops, there you go again. :o
I asked in the other thread that you present your points and let people draw their own conclusions. It applies to TMC as well as FD!
And I don't think it is fair to hang such a label on TMC. (After all, nobody noticed the minor bug Tom confessed to.) And the artifacts that can result from inter-field comparison are matched by some equally ugly artifacts that you can get with FD. In many cases, the smoothing done by TMC is welcome. Conclusion: TMC is a great filter that has an important place in our toolbox.
Originally posted by hakko504
In fact, if you intend to keep full horizontal resolution, which I almost never do, this might be the preferable solution..
Vertical is also relevant. Might be better to say "keep maximum picture resolution".
TheWEF
11th December 2002, 14:20
know what? i actually thought that VerticalReduceBy2 is Separatefields.SelectEven - shame on me!
that's enough to keep my mouth shut in any filter discussion for quite a while... :rolleyes:
Originally posted by manono
And perhaps I spoke too quickly to condemn FastDeinterlace since, as you said, it's a fast and easy solution to the problem. So, I apologize to you and Doom9 and others that see it as one answer to the problem.
guess you are right anyway - have to do some testing and rethink all this. but even if everything you said was bogus:
never ever apologize for offering an opinion!
stand corrected if you find out that you've been wrong, but do not regret having made that statement.
is there a special tool you recommend to compare different frameservers frame by frame side by side or do i have to code one :p
wef.
hakko504
11th December 2002, 14:39
Originally posted by neuron2
Oops, there you go again. :o
I asked in the other thread that you present your points and let people draw their own conclusions. It applies to TMC as well as FD!Shame on me, I'm too quick to label things :(
And I don't think it is fair to hang such a label on TMC. (After all, nobody noticed the minor bug Tom confessed to.) And the artifacts that can result from inter-field comparison are matched by some equally ugly artifacts that you can get with FD. In many cases, the smoothing done by TMC is welcome. Conclusion: TMC is a great filter that has an important place in our toolbox.
I agree, and I'll change the offending lines. I wouldn't want trbarry to start picking on me too. ;) Still, two lines further down I do say that TMC is useful if you want a smoothed picture that compresses well.
Vertical is also relevant. Might be better to say "keep maximum picture resolution". I meant to say vertical! :eek: I just mixed it up. I'll edit that.:stupid:
fixed a spelling mistake, again. piture. now where the **** did that come from. I really wouldn't mind a spell checker here
manono
11th December 2002, 14:58
Hi-
is there a special tool you recommend to compare different frameservers frame by frame side by side
I'm sure there must be. But I'll open VDub twice and squash them down so that only one window of each is visible, and then feed them 2 different .avs scripts. I've done this with VDub opened as many as 4 times, but it really bogs down if you do that.
ArdenDag
11th December 2002, 22:21
I'd love to see something that can show seperate .avs files opened side by side in one program, and even compare differences for you (with numbers) like differences in Chroma, Luminance, colors, etc
With VDub, one thing irks me, and that's that when you go to 2x or 4x size to get closer to the picture, you can't scroll to see more of it. Is there a way around this?
EDIT: I'd love to see a GRAB and MOVE tool maybe ;) Say you can grab the picture and move it to the portion you wish to see when advancing frames. How difficult would it be to put into VDub?
vBulletin® v3.8.5, Copyright ©2000-2012, Jelsoft Enterprises Ltd.