I've attached 3 more patches, they are:

box-blur. it's now a good deal faster, and also properly supports fractional blur widths.

fast gaussian blur. this is implemented as 3 box filters in series. it approximates a gaussian fairly closely, visually I can't tell the difference between this and the current gaussian blur, although the units don't match exactly. I've put it in a separate file to allow easy comparisons while we decide whether it's worth keeping.

pixelise. a simple pixelise filter like the one in gimp currently.

While I remember there were a couple of issues I came across whilst working on this. Firstly, if you create a transparent layer, and merge it down, then apply a gegl blur operation to the merged layer (all the blurs have the same issue, and probably other filters too), the edges of the image go transparent. I suspect this is something to do with the RaGaBaA=>RGBA conversion not happening properly for some reason, but I haven't looked in to it.
Secondly, the current gaussian blur doesn't work properly for very wide blurs. A std-dev of 200 makes the tile boundaries quite visible.

If any changes are required, just let me know. Andy.

Could you explain how the tests work, it's not obvious to me what I need to add. Do the tests make sure that the results match a reference image in some way?

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.

Cheers, Andy.

On 19 January 2011 06:43, Martin Nordholts wrote:

On 01/18/2011 11:43 PM, andy gill wrote:

I've attached 3 more patches, they are:

box-blur. it's now a good deal faster, and also properly supports fractional blur widths.

fast gaussian blur. this is implemented as 3 box filters in series. it approximates a gaussian fairly closely, visually I can't tell the difference between this and the current gaussian blur, although the units don't match exactly. I've put it in a separate file to allow easy comparisons while we decide whether it's worth keeping.

pixelise. a simple pixelise filter like the one in gimp currently.

Thanks!

You should add regression tests though. In GEGL it's very simple, see tests/compositions. We have a BuildBot that runs all tests every night.

And IMO, we should not have two gaussian blur implementations, we should only have a single high-quality one, so I suggest you try to merge the two.

Best regards, Martin

--

My GIMP Blog:
http://www.chromecode.com/
"Nightly GIMP, GEGL, babl tarball builds" _______________________________________________ Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer

I've redone the patches for the box-blur and pixelise filters to include tests.
the patches now total 300k however, what's the preferred method of submitting them?

On 19 January 2011 10:39, Øyvind Kolås wrote:

On Wed, Jan 19, 2011 at 10:29 AM, andy gill wrote:

Could you explain how the tests work, it's not obvious to me what I need

to

add. Do the tests make sure that the results match a reference image in

some

way?

XML files in gegl/tests/compositions are rendered and their output is tested against the PNG files by the same names in gegl/tests/compositions/reference, visual files indicating where the outputs differ are also produced if the tests are wrong.

It would probably be good to have a section on the website explaining how these regression tests work. There are also bots the build the GEGL code base nightly and will complain to us on IRC if the build breaks or the tests fail passing.

/Øyvind K. --
«The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/