On 08/18/10 01:20, Bill Skaggs wrote:
> I just looked over the code -- if I understand it correctly, it creates
> an arc of the specified angle
> passing through each point of the image, generates a set of points
> equally spaced along the arc,
> uses interpolation to get the color for each of these points, and then
> averages all the colors together,
> with equal weighting. The number of points is proportional to the
> length of the arc, with adjustments
> if it is too large or too small. If you need more detail, please ask.
> -- Bill
I'm sure you are right in reading the code, so this feature seems more
like a rotation blur than motion blur.
A motion blur is a retinal effect that has a time dependence. This does
not seem to be what is done. The equal weighting is wrong.
The retinal retention of the image fades with time (my guess would be
exponentially if we're going to be rigorous). This means the weighting
of each point should be diminished as we work back along the arc. This
reduction should be angular and at least a linear reduction of weight
w.r.t. the angular coord would probably be a decent approximation.
Otherwise a lookup table of exponential decay would mean very little
overhead in doing a fairly rigorous model of the real effect.
This effect will vary dependant on speed of the movement (as everyone
knows intuitively) so this parameter needs to be adjustable in the tool UI.
I assume the same points could be made about the motion blur , though I
have not looked at the code.
I'd don't have the time to get into coding an improvement but thought
it worth noting the apparent shortcomings of the "motion" blur and how
it could be improved.
Gimp-developer mailing list