On Wed, Jan 19, 2011 at 10:29 AM, andy gill <andyggill@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
