Quote:
Originally posted by SansGrip
[i]Either you're being kind or you've only tried low radii (3-5) or you're running it on a quad Xeon system  .
|
Running it on a TBird 1.2Ghz, and I'm comparing the speed to temporalsoften. Speed is relative to the complexity to me.
Quote:
It would be interesting to see the same trick used for spatial smoothing, in which an intervening pixel of a different color would prevent averaging with a pixel further away.
I'm coding it right now
|
This is one of the tricks SmoothHiQ uses - the main problem is that you very seldom have straight lines to the center pixel, except when x or y is the same. I did a test before v1.0, where I actually tested all pixels inbetween pixel x (in the window around the pixel), based on a line drawn from it. It was _painfully_ (and I mean painfully) slow, and gave a very minimal visual improvement (if any).
Testing straight lines (with same x and y) is a posibility, but I don't think it'll give you much. Perhaps as gradiant improver on anim-e?
You should rather try different methods of weighing, and experiment with "frames further away have less influence", and "frames with pixels with bigger difference to the current has less impact on it".
(Example is in "float", but translates to fixed ints)
For the first you could create a table, where:
weight_frame[i] = 1/i, where i is your frame offset from the current frame. Then normalize the values in weight_frame[], so they add up to 1 (or a fixed point value, 65536 for example) .
Use this as a weight table. So you have:
c_frame = current frame number
c_ip = input pixel from frame c
ap = accumulated weighed pixels
aw = accumulated weights
ipw = inverse pixel weight
ip = input pixel (from the current frame 0)
op = output pixel
then for a passed pixels:
ap += weight_table[c_frame] * c_ip
aw += weight_table[c_frame]
For non-passed pixels you do nothing. To calculate the final pixel use:
ipw = 1 - aw
op = (ap + (ipv * ip)) / 1
Divide by one is to show that if you use fixed point you must divide with the accumulated weight value. This is a constant, so there is no divide in the algorithm (use >>16 for example).
So the fewer of the neighboring frames pass, the less the current pixel will be blurred. You can also do a "weigh with difference", where you have another table, where:
diff_table[i] = max(0,(1/threshold)*(threshold-i)). Then calculate ap and aw as:
weight = weight_table[c_frame] * difftable[abs(c_ip-ip)]
ap += weight* c_ip
aw += weight
- This is basicly what I use in SmoothHiQ for better averaging in "Weighed Average" mode.