Doom9's Forum - View Single Post - exist any filter specially done for (deinterlace) flicker

Didée · 8th June 2008, 02:19

@ Terka:

Well, where to start ... [deep breath] ...

What you bring up there is by all means valid. But do you realize that, in last instance, the result is something totally different ... ?
You can't just hop in and "change the o's less, and give more weight to the o's when doing the averaging for the b's". Consequentially, one would have to leave the o's perfectly untouched, and give ALL weights to the o's when doing the averaging for the b's. But then, this is nothing else but putting the compensations of the neighbor frames into the "b" lines of the current frame. And that's basically just what MVBob or MCBob are already doing.

The "strength" of TempGaussMC comes from the fact that changing the original data is allowed. This also allows to handle the problem of "the data missing in this frame is also missing in the neighbor frames" (vertical motion by an odd numer of pixels). For a lossless MV-Bobber this case is problematic, whereas TempGaussMC inherently uses a "prophet-and-mountain" - way to handle this case: if the prohet won't come to the mountain, then the mountain has to come to the prophet.

Also, when using the strict way of giving 100% weight to the compensations, then new problems arise from the side of motion-compensation: you then need to be *very* careful in checking whether the compensation is valid or erroneous; and ideally should also check whether the compensation for the current "b" line actually is delivering an "o" from the neighbor, or just the neighbor's "b" in turn.

In contrast, the way TempGaussMC is working is much more fuzzy, that's why it can get away with much less checking of all those things. And that's the bottom line: TempGaussMC works surprisingly good with a rather simplistic approach, and it should be left that way. Trying to make any improvements to the basic methodology will only result in something that we already have, in shape of MV/MC-Bob.

@ WorBry:

Regarding the weightings, I'm not quite sure ... perhaps the easiest way is to just use the "repeating" way (which is a valid way to get gaussian weightings for arbitrary radii), just with your preferred weighting instead:

Code:

t1 = dbdbl.temporalsoften(1,255,255,32,2).merge(dbdbl,0.6)  #  for gauss, this weight is 0.25
t2 = t1   .temporalsoften(1,255,255,32,2),merge(t1,   0.6)  #  for gauss, this weight ALSO is 0.25

t  = (tr0==0) ? dbdbl
 \ : (tr0==1) ? t1
 \            : t2

(BTW, note that those merge-weightings in TempGaussMC are not directly related to gaussian weightings, regarding the numbers as such. They just deal to get the gaussian [1-2-1] or [1-4-6-4-1] out of the linear [..-1-1-1-..] of TemporalSoften.)

Still, for your case of AA'ing progressive input this is a try'n'error thing without obvious justification. For the case of bobbing, the temp-gauss'ing deals a very specific and necessary purpose: to average-away the bob jumping. For your case, the effect (if any) is more or less ~random~. What has to be avoided in your case is that the motion search between frames snaps in to the aliasing. And in the case of zero motion, the effect of the initial temporal averaging is exactly zero. When there is motion, then it may or may not help, IMHO that's unpredictable. My guess is that with exhaustive investigation, you might find that a weight of X is ideal for this spot, weight Y is ideal for that spot, weight Z is ideal for other spots ...

Lately I started looking at something else: Let EDI do a self-validation by using a "back-interpolation" instance, in order to judge whether a given EDI interpolation at a given place seems reasonable or not. Method: construct a frame consisting ONLY of EDI-interpolation. From this constructed frame, again construct a frame consisting ONLY of EDI-interpolation. In places where EDI does "good" interpolation, the 2nd interpolation should be reasonably close to the original frame. In places where EDI does "bad" interpolation, the 2nd interpolation can be expected to be fairly different to the original frame.
Quickly knocking together the first part (full interpolation & back-interpolation) and looking at the resulting differences, it seems pretty reasonable, but I've yet to see if one can get a tight enough grip on the problematic areas.

8th June 2008, 02:19	#64 \| Link
Didée Registered User Join Date: Apr 2002 Location: Germany Posts: 5,391	@ Terka: Well, where to start ... [deep breath] ... What you bring up there is by all means valid. But do you realize that, in last instance, the result is something totally different ... ? You can't just hop in and "change the o's less, and give more weight to the o's when doing the averaging for the b's". Consequentially, one would have to leave the o's perfectly untouched, and give ALL weights to the o's when doing the averaging for the b's. But then, this is nothing else but putting the compensations of the neighbor frames into the "b" lines of the current frame. And that's basically just what MVBob or MCBob are already doing. The "strength" of TempGaussMC comes from the fact that changing the original data is allowed. This also allows to handle the problem of "the data missing in this frame is also missing in the neighbor frames" (vertical motion by an odd numer of pixels). For a lossless MV-Bobber this case is problematic, whereas TempGaussMC inherently uses a "prophet-and-mountain" - way to handle this case: if the prohet won't come to the mountain, then the mountain has to come to the prophet. Also, when using the strict way of giving 100% weight to the compensations, then new problems arise from the side of motion-compensation: you then need to be very careful in checking whether the compensation is valid or erroneous; and ideally should also check whether the compensation for the current "b" line actually is delivering an "o" from the neighbor, or just the neighbor's "b" in turn. In contrast, the way TempGaussMC is working is much more fuzzy, that's why it can get away with much less checking of all those things. And that's the bottom line: TempGaussMC works surprisingly good with a rather simplistic approach, and it should be left that way. Trying to make any improvements to the basic methodology will only result in something that we already have, in shape of MV/MC-Bob. @ WorBry: Regarding the weightings, I'm not quite sure ... perhaps the easiest way is to just use the "repeating" way (which is a valid way to get gaussian weightings for arbitrary radii), just with your preferred weighting instead: Code: t1 = dbdbl.temporalsoften(1,255,255,32,2).merge(dbdbl,0.6) # for gauss, this weight is 0.25 t2 = t1 .temporalsoften(1,255,255,32,2),merge(t1, 0.6) # for gauss, this weight ALSO is 0.25 t = (tr0==0) ? dbdbl \ : (tr0==1) ? t1 \ : t2 (BTW, note that those merge-weightings in TempGaussMC are not directly related to gaussian weightings, regarding the numbers as such. They just deal to get the gaussian [1-2-1] or [1-4-6-4-1] out of the linear [..-1-1-1-..] of TemporalSoften.) Still, for your case of AA'ing progressive input this is a try'n'error thing without obvious justification. For the case of bobbing, the temp-gauss'ing deals a very specific and necessary purpose: to average-away the bob jumping. For your case, the effect (if any) is more or less ~random~. What has to be avoided in your case is that the motion search between frames snaps in to the aliasing. And in the case of zero motion, the effect of the initial temporal averaging is exactly zero. When there is motion, then it may or may not help, IMHO that's unpredictable. My guess is that with exhaustive investigation, you might find that a weight of X is ideal for this spot, weight Y is ideal for that spot, weight Z is ideal for other spots ... Lately I started looking at something else: Let EDI do a self-validation by using a "back-interpolation" instance, in order to judge whether a given EDI interpolation at a given place seems reasonable or not. Method: construct a frame consisting ONLY of EDI-interpolation. From this constructed frame, again construct a frame consisting ONLY of EDI-interpolation. In places where EDI does "good" interpolation, the 2nd interpolation should be reasonably close to the original frame. In places where EDI does "bad" interpolation, the 2nd interpolation can be expected to be fairly different to the original frame. Quickly knocking together the first part (full interpolation & back-interpolation) and looking at the resulting differences, it seems pretty reasonable, but I've yet to see if one can get a tight enough grip on the problematic areas. __________________ - We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!)