On Wed, Jan 19, 2011 at 10:29 AM, andy gill <andygg...@gmail.com> wrote:
> As for the alternative gaussian implementation, it was not my intention that
> we should keep both, only that interested parties may wish to compare them
> side by side before deciding which to keep and which to ditch. Quality wise,
> I don't think there's any difference between the two, and personally I think
> the new implementation has a number of benefits, not the least of which is
> that it works robustly for all blur sizes, and that the code is trivial.
> Whether an 'exact' gaussian is a requirement over a close approximation I
> didn't feel qualified to answer.
> I may be inventing a contention that isn't there, but I didn't want to just
> throw out the old implementation without discussion.

GEGL would prefer to be accurate rather than fast, and when trading
quality for speed - making it optional. It could make sense to allow
toggling a fast path in gegl:gaussian-blur. For now though it could
make sense to keep the alternate gaussian blur in the workshop where
it isn't compiled by default but still kept available.

/Øyvind K.
-- 
«The future is already here. It's just not very evenly distributed»
                                                 -- William Gibson
http://pippin.gimp.org/                            http://ffii.org/
_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

Reply via email to