Thank you for poking around looking for more things to bring over to GEGL. I do not know much about the GIMP plug-in, but can tell you some other bits of information that could be relevant ;)

The core part of "selective gaussian blur" is what is normally called "bilateral filtering" in academic image processing circles. GEGL already has a (rather slow) bilateral filter implemented contained in operations/common/bilateral-filter.c

The specifics of the behavior of GIMPs selective-gaussian blur is something I'd consider a historic artifact - that we might not want to preserve in future versions.

(As to the lines you've pointed out, looking at them in isolation.. this seems to be code that deals with correctly handling alpha; GEGL does this normally by processing buffers with premultiplied alpha, this seems to be manual hacks that scales the contribution of pixels to the sum by the alpha.. and since legacy GIMP is 8bpc, >>= 8, is the same as /256 and 256 is 1.0, which normalizes the effect of multiplying by the alpha values between 0 and 255.)

/Ø

On Sat, Apr 6, 2013 at 12:14 PM, Karthikeyan S wrote:

Hi all,
I am trying to port the selective gaussian blur filter to gegl. I do not understand the following lines in the original gimp code and what purpose they serve.

---

Line 668 if (has_alpha)
d *= src_b[nb - b]; // ?
---

Line 676if (has_alpha)
{
rowsum >>= 8; // why?
rowfact >>= 8;}

---

Also, as of now, my implementation correctly maintains edges in checker board images while blurring other areas. I am trying to debug another issue wherein I see that the noise pixels (in complete dark background in the checkerboard image) seem to get smeared out to neighbourhood areas and we get large patches of white arround the blurred pixel (This does not happen in gimp implementation). I am trying to see if the above lines have some clue to that.

Thanks,
Karthik

_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

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

Just a comment, I implemented recently a much faster version of the bilateral-filter. Though I think there is still some polishing to do, it is basically working in the CPU and the GPU.

On Sat, Apr 6, 2013 at 4:39 PM, yvind Kols wrote:

Thank you for poking around looking for more things to bring over to GEGL. I do not know much about the GIMP plug-in, but can tell you some other bits of information that could be relevant ;)

The core part of "selective gaussian blur" is what is normally called "bilateral filtering" in academic image processing circles. GEGL already has a (rather slow) bilateral filter implemented contained in operations/common/bilateral-filter.c

The specifics of the behavior of GIMPs selective-gaussian blur is something I'd consider a historic artifact - that we might not want to preserve in future versions.

(As to the lines you've pointed out, looking at them in isolation.. this seems to be code that deals with correctly handling alpha; GEGL does this normally by processing buffers with premultiplied alpha, this seems to be manual hacks that scales the contribution of pixels to the sum by the alpha.. and since legacy GIMP is 8bpc, >>= 8, is the same as /256 and 256 is 1.0, which normalizes the effect of multiplying by the alpha values between 0 and 255.)

/

On Sat, Apr 6, 2013 at 12:14 PM, Karthikeyan S wrote:

Hi all,
I am trying to port the selective gaussian blur filter to gegl. I do not understand the following lines in the original gimp code and what purpose they serve.

---

Line 668 if (has_alpha)
d *= src_b[nb - b]; // ?
---

Line 676
if (has_alpha)
{
rowsum >>= 8; // why?
rowfact >>= 8;
}

---

Also, as of now, my implementation correctly maintains edges in checker board images while blurring other areas. I am trying to debug another issue wherein I see that the noise pixels (in complete dark background in the checkerboard image) seem to get smeared out to neighbourhood areas and we get large patches of white arround the blurred pixel (This does not happen in gimp implementation). I am trying to see if the above lines have some clue to that.

Thanks,
Karthik

_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

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

_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

On Sun, 2013-04-07 at 20:39 +0530, Karthikeyan S wrote:

GEGL already has a (rather slow) bilateral filter implemented contained

in operations/common/bilateral-filter.c Doh! Thanks Øyvind.

I implemented recently a much faster version of the bilateral-filter.

I am stopping right away. Taking a look at your code.

I should stop relying on http://wiki.gimp.org/index.php/Hacking:Porting_filters_to_GEGL for latest info.

While I am at it, why does edge-sobel add extra pixels to the original image? Is it a 'don't care' thing.

Just because something is in git doesn't mean it's correct :)

If there is strange behavior, a look at the code, a bug report, or even a patch are appreciated.

--mitch

On Sun, Apr 7, 2013 at 11:11 PM, Michael Natterer wrote:

While I am at it.

Please start new threads, or change the topic - when changing the topic.

, why does edge-sobel add extra pixels to the original

image? Is it a 'don't care' thing.

No - for the same reason that gaussian blur adds extra pixels to the original buffer; assuming an abyss behavior of zeroed pixels around the buffer. Both of these filters have well defined results. For a drop-shadow added to a layer you do intend to blur the contents out into nothingness - all such area filters with a dependendant neighbourhood are at the core - at GEGL graph level is concerned, growing their defined inputs.

Just because something is in git doesn't mean it's correct :)

If there is strange behavior, a look at the code, a bug report, or even a patch are appreciated.

--mitch

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