[Gimp-developer] Some edge filters in GEGL

[Victor Oliveira]

Hello everyone. As a way to learn how GEGL works, I decided to
implement some GIMP plug-ins in it [1,2]. I hope this code can help
someone in the task of making your own plugins.
I've done a sobel and a laplace filter. Both use RGBA float format for
input and output. Basically, I just do a convolution with the
appropriate mask, although in sobel filter I implemented some of the
options of the original GIMP plugin.

There are some differences in the results, but I think this code is
"almost there" to whom wants to port these plugins to GEGL.

[1] http://git.gnome.org/browse/gimp/tree/plug-ins/common/edge-sobel.c
[2] http://git.gnome.org/browse/gimp/tree/plug-ins/common/edge-laplace.c
From b81a2e12a9d6f23c9063e0a42f00940ce1791df2 Mon Sep 17 00:00:00 2001
From: Victor Oliveira 
Date: Tue, 29 Mar 2011 18:15:26 -0300
Subject: [PATCH] edge filters

---
 operations/common/edge-laplace.c |  141 +++
 operations/common/edge-sobel.c   |  199 ++
 2 files changed, 340 insertions(+), 0 deletions(-)
 create mode 100644 operations/common/edge-laplace.c
 create mode 100644 operations/common/edge-sobel.c

diff --git a/operations/common/edge-laplace.c b/operations/common/edge-laplace.c
new file mode 100644
index 000..912720e
--- /dev/null
+++ b/operations/common/edge-laplace.c
@@ -0,0 +1,141 @@
+/* This file is an image processing operation for GEGL
+ *
+ * GEGL is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 3 of the License, or (at your option) any later version.
+ *
+ * GEGL is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with GEGL; if not, see .
+ *
+ */
+
+#include "config.h"
+#include 
+
+
+#ifdef GEGL_CHANT_PROPERTIES
+
+#else
+
+#define GEGL_CHANT_TYPE_AREA_FILTER
+#define GEGL_CHANT_C_FILE   "edge-laplace.c"
+
+#include "gegl-chant.h"
+#include 
+
+#define LAPLACE_RADIUS 1
+
+static void
+edge_laplace (GeglBuffer  *src,
+  const GeglRectangle *src_rect,
+  GeglBuffer  *dst,
+  const GeglRectangle *dst_rect);
+  
+#include 
+
+static void prepare (GeglOperation *operation)
+{
+  GeglOperationAreaFilter *area = GEGL_OPERATION_AREA_FILTER (operation);
+  //GeglChantO  *o = GEGL_CHANT_PROPERTIES (operation);
+
+  area->left = area->right = area->top = area->bottom = LAPLACE_RADIUS;
+  gegl_operation_set_format (operation, "input", babl_format ("RGBA float"));
+  gegl_operation_set_format (operation, "output", babl_format ("RGBA float"));
+}
+
+static gboolean
+process (GeglOperation   *operation,
+ GeglBuffer  *input,
+ GeglBuffer  *output,
+ const GeglRectangle *result)
+{
+  GeglRectangle compute;
+
+  compute = gegl_operation_get_required_for_output (operation, "input",result);
+
+  edge_laplace (input, &compute, output, result);
+
+  return  TRUE;
+}
+
+static void
+edge_laplace (GeglBuffer  *src,
+  const GeglRectangle *src_rect,
+  GeglBuffer  *dst,
+  const GeglRectangle *dst_rect)
+{
+
+  gint x,y;
+  gint offset;
+  gfloat *src_buf;
+  gfloat *dst_buf;
+
+  gint src_width = src_rect->width;
+
+  src_buf = g_new0 (gfloat, src_rect->width * src_rect->height * 4);
+  dst_buf = g_new0 (gfloat, dst_rect->width * dst_rect->height * 4);
+
+  gegl_buffer_get (src, 1.0, src_rect, babl_format ("RGBA float"), src_buf, GEGL_AUTO_ROWSTRIDE);
+
+  offset = 0;
+
+  for (y=0; yheight; y++)
+for (x=0; xwidth; x++)
+  {
+
+gfloat gradient[4] = {0.0f, 0.0f, 0.0f, 0.0f};
+
+gint c;
+
+gint i=x+LAPLACE_RADIUS, j=y+LAPLACE_RADIUS;
+gfloat *src_pix = src_buf + (i + j * src_width) * 4;
+
+for (c=0;c<3;c++)
+  gradient[c] += src_pix[c-4-src_width*4]+ src_pix[c-src_width*4]+src_pix[c+4-src_width*4] + \
+ src_pix[c-4]-8.0f*src_pix[c]+src_pix[c+4] + \
+ src_pix[c-4+src_width*4]+ src_pix[c+src_width*4]+src_pix[c+4+src_width*4];
+
+
+//alpha
+gradient[3] = src_pix[3];
+
+for (c=0; c<4;c++)
+  dst_buf[offset*4+c] = gradient[c];
+  
+offset++;
+  }
+  
+  gegl_buffer_set (dst, dst_rect, babl_format ("RGBA float"), dst_buf,
+   GEGL_AUTO_ROWSTRIDE);
+  g_free (src_buf);
+  g_free (dst_buf);
+}
+
+
+static void
+gegl_chant_class_init (GeglChantClass *klass)
+{
+  GeglOperationClass   *operation_cl

Re: [Gimp-developer] gegl build fails

[Michael J. Hammel]

On Wed, 2011-03-30 at 10:21 +0530, Mukund Sivaraman wrote:
> export XDG_DATA_DIRS=/usr/local/gimpgit/share/

That got me a little further:

  GISCAN Gegl-0.1.gir
WARNING: Skipping unknown interface GeglVisitable
  GICOMP Gegl-0.1.gir
Gegl-0.1.gir: error: Type reference 'GeglMatrix3' not found


-- 
Michael J. Hammel 

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] gegl build fails

[Jon Nordby]

On 30 March 2011 18:28, Michael J. Hammel  wrote:
> On Wed, 2011-03-30 at 10:21 +0530, Mukund Sivaraman wrote:
>> export XDG_DATA_DIRS=/usr/local/gimpgit/share/
>
> That got me a little further:
>
>  GISCAN Gegl-0.1.gir
> WARNING: Skipping unknown interface GeglVisitable
>  GICOMP Gegl-0.1.gir
> Gegl-0.1.gir: error: Type reference 'GeglMatrix3' not found
Yeah, this has been reported by other as well. I'll try to fix it now.
Which distribution are you using, and what is the version of
gobject-introspection?

-- 
Jon Nordby - www.jonnor.com
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] gegl build fails

[Michael J. Hammel]

On Wed, 2011-03-30 at 19:10 +0200, Jon Nordby wrote:
> >  GISCAN Gegl-0.1.gir
> > WARNING: Skipping unknown interface GeglVisitable
> >  GICOMP Gegl-0.1.gir
> > Gegl-0.1.gir: error: Type reference 'GeglMatrix3' not found
> Yeah, this has been reported by other as well. I'll try to fix it now.
> Which distribution are you using, and what is the version of
> gobject-introspection?

Fedora 13.  Is gobject-introspection within gobject-2.0?  If so:
$ pkg-config --modversion gobject-2.0
2.24.1

-- 
Michael J. Hammel 

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Gimp-developer] GsoC - 2011 - Porting GIMP plugins to GEGL operations

[Robert Sasu]

My background:
I am a 1st year student of the department of Computer Science and
Engineering at Polytehnical University of Bucharest. I have started to use
GIMP 2 years ago. I wrote emboss, blur and sharpen tools in C and then in
Octave. I wrote a program which converts images from Targa(for RGB images
with colour map or without) to PPM(type 3) and back.

I would also suggest to generalize the emboss plug-in by using some
operators such as: Sobel, Robert Cross, Prewitt, Scharr or Costella. In case
of Sobel operator we can set 3 types of normalizing (gradient x,y or
magnitude) all 3 making some new effects.

Code review and algorithm description (GIMP plug-ins):


1. Cubism
Function cubism: Initializes the values of alpha and image type, and fills
the image with the background colour, which we get from the drawable
image(current image). After calculating the number of tiles of the asked
rectangle the function randoms the indices and initiates the first
rectangle. For each tile the starting point (x,y),height and with is
randomed between certain limits, depending on the tile saturation and tile
size set by the user. The rotation grad is also randomed. Then for each
polygon it adds the calculated points to the structure for creating the
double perspective, rotates and translates it by adding the starting
points(x,y). It checks if the calculated point is between minimum and
maximum and gets the closest value (CLAMP), and gets the pixel color from
the source. Finally it fills with color the drawable image in the pixels
within the polygon.
fill_poly_color: The colour of a pixel will be calculated by looking at the
backgroung image and the intersection of the polygons.
Firstly calculates the distance between the 2 points of the polygon and
initiates values of vector. By polygon_extent we get the minimum and maximum
position of the pixels. It initiates the the values of the lines which need
to be scanned and for every 2 points in the polynom it calculates the
minimum and maximum of the segment.
For every pixel in the polygon it calculates the colour which will be equal
with the color from the source image which is in the position (x,y). x is
equal with ((size_x-1)/4+min_x. In vals the function keeps if that row was
reached or not. The alpha value of the pixel color is between 0.1 and 0.2,
caculated by the distance between the points in the polygon. Every value we
get from buf which will be equal with the color of the coloumn plus the
color from the position (x,y).



2. Fractal trace
Initialization: source pixel table(guchar **) gets the color values of the
current picture for every column. Destination pixel table gets allocated
memory.
Pixel get: In function of the image type the asked pixel gets the values
from source pixel table for RGBA.
Pixel set: The color of a certain (position c,y) is uploaded to destination
pixel table considering also the image type.
Pixel get biliner: Calculates the values of the colors for the asked pixel,
making median of its neighbour. The alpha value is accumulated, for the
other values after accumulating the color*alpha it divides with the
acumulated alpha.
Mandelbrot: While the iteration number is smaller then it calculates the
position of the pixels with the quadratic polynomial. The new pixel position
will be the values calculated on the last iteration.
Filter: For each pixel in the given rectangle the function calculates its
colour value. First it calculates a position of the asked pixel by the
parameters, then iterates it with the mandelbrot function. If the iterated
pixel position is in within the image then its color value is calculated.
Else if the position escaped to infinite then in function of the Outside
type it calculates its value. In case of WRAP the color of the pixel will be
equal with the pixel being at the position (px-px/width,py-py/height).
At last it saves the value of the color in destination pixel table.

It is written almost the same thing for the dialog-preview, the setpixel
function is differing because it considers every picture to be type RGBA.
Possible optimization:
If the given point lies within the cardioid or in the period-2 buld we can
calculate its color without appealing the mandelbrot function, without
iterating, because it will never escape to infinite. Just have to verify
that: q(q+(x-1/4))<1/4*y^2, where q=(x-1/4)^2+y^2.
Moreover the periodicity checking could also be implemented by using a
little more memory. If by iterating a pixel, that pixel reaches another
pixel which was calculated(iterated) before we know its colour.



3. Plasma
The scientific name would be random midpoint displacemant. For a given
rectangle the function divides it in 4 smaller one calculating the values of
each pixel by median.
Plasma: After initialization and random if the asked rectangle is not a
single pixel then it puts a seed pixel in the corners and in the center.
After that, while the size of the rectangle is not 1 it recurse through the
pixels going in furthe

Re: [Gimp-developer] GsoC - 2011 - Porting GIMP plugins to GEGL operations

[Robert Sasu]

My background:
I am a 1st year student of the department of Computer Science and
Engineering at Polytehnical University of Bucharest. I have started to use
GIMP 2 years ago. I wrote emboss, blur and sharpen tools in C and then in
Octave. I wrote a program which converts images from Targa(for RGB images
with colour map or without) to PPM(type 3) and back.

I would also suggest to generalize the emboss plug-in by using some
operators such as: Sobel, Robert Cross, Prewitt, Scharr or Costella. In case
of Sobel operator we can set 3 types of normalizing (gradient x,y or
magnitude) all 3 making some new effects.

Code review and algorithm description (GIMP plug-ins):


1. Cubism
Function cubism: Initializes the values of alpha and image type, and fills
the image with the background colour, which we get from the drawable
image(current image). After calculating the number of tiles of the asked
rectangle the function randoms the indices and initiates the first
rectangle. For each tile the starting point (x,y),height and with is
randomed between certain limits, depending on the tile saturation and tile
size set by the user. The rotation grad is also randomed. Then for each
polygon it adds the calculated points to the structure for creating the
double perspective, rotates and translates it by adding the starting
points(x,y). It checks if the calculated point is between minimum and
maximum and gets the closest value (CLAMP), and gets the pixel color from
the source. Finally it fills with color the drawable image in the pixels
within the polygon.
fill_poly_color: The colour of a pixel will be calculated by looking at the
backgroung image and the intersection of the polygons.
Firstly calculates the distance between the 2 points of the polygon and
initiates values of vector. By polygon_extent we get the minimum and maximum
position of the pixels. It initiates the the values of the lines which need
to be scanned and for every 2 points in the polynom it calculates the
minimum and maximum of the segment.
For every pixel in the polygon it calculates the colour which will be equal
with the color from the source image which is in the position (x,y). x is
equal with ((size_x-1)/4+min_x. In vals the function keeps if that row was
reached or not. The alpha value of the pixel color is between 0.1 and 0.2,
caculated by the distance between the points in the polygon. Every value we
get from buf which will be equal with the color of the coloumn plus the
color from the position (x,y).



2. Fractal trace
Initialization: source pixel table(guchar **) gets the color values of the
current picture for every column. Destination pixel table gets allocated
memory.
Pixel get: In function of the image type the asked pixel gets the values
from source pixel table for RGBA.
Pixel set: The color of a certain (position c,y) is uploaded to destination
pixel table considering also the image type.
Pixel get biliner: Calculates the values of the colors for the asked pixel,
making median of its neighbour. The alpha value is accumulated, for the
other values after accumulating the color*alpha it divides with the
acumulated alpha.
Mandelbrot: While the iteration number is smaller then it calculates the
position of the pixels with the quadratic polynomial. The new pixel position
will be the values calculated on the last iteration.
Filter: For each pixel in the given rectangle the function calculates its
colour value. First it calculates a position of the asked pixel by the
parameters, then iterates it with the mandelbrot function. If the iterated
pixel position is in within the image then its color value is calculated.
Else if the position escaped to infinite then in function of the Outside
type it calculates its value. In case of WRAP the color of the pixel will be
equal with the pixel being at the position (px-px/width,py-py/height).
At last it saves the value of the color in destination pixel table.

It is written almost the same thing for the dialog-preview, the setpixel
function is differing because it considers every picture to be type RGBA.
Possible optimization:
If the given point lies within the cardioid or in the period-2 buld we can
calculate its color without appealing the mandelbrot function, without
iterating, because it will never escape to infinite. Just have to verify
that: q(q+(x-1/4))<1/4*y^2, where q=(x-1/4)^2+y^2.
Moreover the periodicity checking could also be implemented by using a
little more memory. If by iterating a pixel, that pixel reaches another
pixel which was calculated(iterated) before we know its colour.



3. Plasma
The scientific name would be random midpoint displacemant. For a given
rectangle the function divides it in 4 smaller one calculating the values of
each pixel by median.
Plasma: After initialization and random if the asked rectangle is not a
single pixel then it puts a seed pixel in the corners and in the center.
After that, while the size of the rectangle is not 1 it recurse through the
pixels going in furthe

[Gimp-developer] GSoC2011 project idea

[Александр Белобородов]

Hello, GIMP developers!

My name is Alexander (a student of the Urals State University, Russia).
I'm interested in image processing scientific field for my Diploma work. I
want to offer my idea for GIMP project about *fractal image scaling *(like
Photoshop plug-in "Genuine fractals")*. *
Is it a good idea for GIMP? Is it real work for one student?
If it isn't, please give me advice about tasks useful for GIMP and/or
connected with topics like Image processing or Object (pattern) recognition.

Sorry for my English.
Regards, Alexander Beloborodov.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GSoC2011 project idea

[Kevin Cozens]

Александр Белобородов wrote:
> want to offer my idea for GIMP project about *fractal image scaling *(like
> Photoshop plug-in "Genuine fractals")*. *

You should provide more details about fractal image scaling. Not many people 
on this list will know what the Photoshop plug-in does. I don't know what 
the Photoshop plug-in does but "fractal image scaling" makes me wonder if it 
has any similarities to the "liquid rescale" plug-in for GIMP (which can be 
found at http://liquidrescale.wikidot.com/).
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer