RSS/Atom feed Twitter
Site is read-only, email is disabled

various blurs

This discussion is connected to the gegl-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

7 of 7 messages available
Toggle history

Please log in to manage your subscriptions.

various blurs andy gill 18 Jan 22:43
  various blurs Martin Nordholts 19 Jan 06:43
   various blurs andy gill 19 Jan 10:29
    various blurs " 19 Jan 10:36
    various blurs " 19 Jan 10:39
     various blurs andy gill 26 Jan 20:08
      various blurs Martin Nordholts 31 Jan 16:57
andy gill
2011-01-18 22:43:53 UTC (about 13 years ago)

various blurs

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.

Martin Nordholts
2011-01-19 06:43:59 UTC (about 13 years ago)

various blurs

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

andy gill
2011-01-19 10:29:32 UTC (about 13 years ago)

various blurs

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

"
2011-01-19 10:36:48 UTC (about 13 years ago)

various blurs

On Wed, Jan 19, 2011 at 10:29 AM, andy gill 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
"
2011-01-19 10:39:09 UTC (about 13 years ago)

various blurs

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/
_______________________________________________
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
andy gill
2011-01-26 20:08:31 UTC (about 13 years ago)

various blurs

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/

Martin Nordholts
2011-01-31 16:57:04 UTC (about 13 years ago)

various blurs

On 01/26/2011 09:08 PM, andy gill wrote:

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?

Put them in bugzilla please, that way it's easy to find them when one looks for them.

/ Martin