Doom9's Forum - View Single Post

tritical · 21st December 2013, 19:53

The main difference between tfm and decomb is the idea of focusing on areas of difference and using pairwise comparisons. Let's assume we have a top field T and two bottom fields A and B. We need to determine which bottom field matches best with T. One approach is to create two frames TA and TB, run our per-pixel combing metric over both frames, accumulate those values over the entire frame, and then make a decision. This will work fine if the combing metric only triggers on real interlacing artifacts. Unfortunately, no metric is perfect, and they will all be susceptible to noise, high vertical frequencies (window blinds for example), etc... So if A and B are very similar except for a small area, think of a static background with a moving object, the difference in metric values from that small area can easily be buried under the accumulated metric values from the rest of the frame. tfm gets around this by first differencing A and B, and then only accumulating the metric values for TA and TB in the areas where A and B are different. To do this, tfm differences A and B using two thresholds, a high threshold and a low threshold (with the idea that the high threshold is less susceptible to noise), if the high threshold gives enough information it uses those values, if not, it uses the values from the low threshold. I'm not saying this is the best way to do it. If I had to rewrite tfm now I would do things a little differently -- probably weight the per-pixel metric values by the difference values (or average difference value from the surrounding local neighborhood) when accumulating instead of using thresholds -- but that is the general idea.

Unfortunately, doing this differencing means extra processing, and it means that to match 3 bottom fields to one top field requires evaluating 2 pairs (A vs B, then winner vs C) instead of just creating 3 frames and calculating the metrics for each. Thus, some amount of slow down is unavoidable. Also, I can't remember how much if any of the processing in tfm is simd optimized so it might be slower than it needs to be. The way I originally implemented it wasn't as simd friendly as it could be with some small changes IIRC.

21st December 2013, 19:53	#2 \| Link
tritical Registered User Join Date: Dec 2003 Location: MO, US Posts: 999	The main difference between tfm and decomb is the idea of focusing on areas of difference and using pairwise comparisons. Let's assume we have a top field T and two bottom fields A and B. We need to determine which bottom field matches best with T. One approach is to create two frames TA and TB, run our per-pixel combing metric over both frames, accumulate those values over the entire frame, and then make a decision. This will work fine if the combing metric only triggers on real interlacing artifacts. Unfortunately, no metric is perfect, and they will all be susceptible to noise, high vertical frequencies (window blinds for example), etc... So if A and B are very similar except for a small area, think of a static background with a moving object, the difference in metric values from that small area can easily be buried under the accumulated metric values from the rest of the frame. tfm gets around this by first differencing A and B, and then only accumulating the metric values for TA and TB in the areas where A and B are different. To do this, tfm differences A and B using two thresholds, a high threshold and a low threshold (with the idea that the high threshold is less susceptible to noise), if the high threshold gives enough information it uses those values, if not, it uses the values from the low threshold. I'm not saying this is the best way to do it. If I had to rewrite tfm now I would do things a little differently -- probably weight the per-pixel metric values by the difference values (or average difference value from the surrounding local neighborhood) when accumulating instead of using thresholds -- but that is the general idea. Unfortunately, doing this differencing means extra processing, and it means that to match 3 bottom fields to one top field requires evaluating 2 pairs (A vs B, then winner vs C) instead of just creating 3 frames and calculating the metrics for each. Thus, some amount of slow down is unavoidable. Also, I can't remember how much if any of the processing in tfm is simd optimized so it might be slower than it needs to be. The way I originally implemented it wasn't as simd friendly as it could be with some small changes IIRC.