You're amazing! This is a reasonable compromise between the
old one (better for motion) and the new one (better for motioneless).
It's not a perfect compromise but I think this warrants a new release
very shortly. I think we should make this Version 1.9.1 ;)
What do you think?
I have an idea... How about doing both algorithms on the
same image? That is, use the old algorithm for blocks
of image that is in motion, and use the new algorithm
for blocks of image that is stationary. Perhaps 4x16
pixel blocks or something.
To do this, will require GetCombFactor to produce a new
buffer that holds a 2-dimensional array of CombFactor's
to represent different blocks of image.
Then CombFactor would return both a full-screen CombFactor,
but also return a 2-dimensional CombFactor array that
represents the CombFactor of small image blocks of a
custom defined size (like 4x4 pixels, 8x8 pixels,
That way, we can execute the new algorithm on blocks that
have a low CombFactor .... And the old algorithm on blocks
that have a high CombFactor ....
What do you think, Steve Grimm? ;-)
Please comment if this idea is feasible!
Steven Grimm wrote:
> I've changed the code so both deinterlace algorithms are available.
> I called the new algorithm "Video Deinterlace (Weave)" and the old
> one "Video Deinterlace (Bob)" to indicate their tendencies to err
> on the side of weaving or bobbing.
> The autodetect code selects between the two algorithms by looking
> at the field difference. I'm currently using the same thresholds
> as the 3:2 pulldown detection, which may or may not be a bright idea.
> The basic idea, ignoring 3:2 pulldown for the sake of clarity, is
> if difference > Threshold32Pulldown
> if difference > ThresholdPulldownMismatch
> video-bob mode
> else if it's been low for a few fields
> video-weave mode
> if it's been low for StaticImageFieldCount fields
> simple-weave mode
> video-weave mode
> I raised the StaticImageFieldCount default to 100 since going from
> video-weave to simple-weave doesn't improve image quality, it just
> cuts down on CPU time.
> This appears to work okay, though it goes into video-bob mode a bit
> more than I'd like. This may be a matter of poor choice of thresholds,
> but what I'd really like to do is get both the field difference and
> the comb factor for each new field, and base the decision of which
> video deinterlace algorithm to use on the comb factor. Trouble is,
> we don't ordinarily compute the comb factor right now, so adding that
> would make the mode detection eat more CPU time.
> What we ought to do, I think, is merge CompareFields() and
> GetCombFactor() into one function, since they repeat each other's
> work to some extent. The PAL code would benefit from this as well;
> right now its autodetection is only based on comb factor, never
> field difference.
> Oh, one other tweak that makes life a lot nicer: I added a
> shift+spacebar accelerator to cycle backwards through the deinterlace
> modes. That way you don't have to walk through all the film modes
> to get from one video mode to another.
> Deinterlace-discuss mailing list
Mark D. Rejhon Win2k.Linux.Win98 \ / mailto:marky@...
http://www.marky.com/ C.C++.VB.Shell \/ AlphaWorld Home 10S 15W
"A friend is someone who will be there without asking anything of you.
A friend is someone you know that knows you, and accepts you."