Re: [Gimp-developer] GSOC-2011 - Gimp plug-ins to Gegl operations
2011/8/26 Robert Sasu sasu.rob...@gmail.com: Hello, Here is the list of op's I ported (made): 1. Color rotate 2. Color to alpha 3. Convolution matrix 4. Cubism 5. Deinterlace 6. Emboss 7. Fractal-trace 8. Lens correct (with Lensfun library) 9. Lens-distortion 10. Plasma 11. Polar-coordinates 12. Red-eye-removal 13. Ripple I also made a showcase: http://sasurobert.github.com/GSoC-2011/ It was a really amazing experience, and I will continue to port plug-ins and/or make some tools (anything you need) after GSoC. Thanks for everything. Hi Robert I must say, really great work! This will be very useful as we fully transition to GEGL. Nice presentation too. BR, Martin -- My GIMP Blog: http://www.chromecode.com/ Single-window mode feature complete ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSOC-2011 - Gimp plug-ins to Gegl operations
On Fri, Aug 26, 2011 at 2:17 PM, Robert Sasu wrote: I also made a showcase: http://sasurobert.github.com/GSoC-2011/ Thanks! Unfortunately with --enable-workshop your branch doesn't build here: CC convolution-matrix.c convolution-matrix.c: In function ‘convolve_pixel’: convolution-matrix.c:277:49: error: incompatible type for argument 4 of ‘gegl_buffer_sample’ ../../gegl/buffer/gegl-buffer.h:336:17: note: expected ‘gdouble’ but argument is of type ‘void *’ make[4]: *** [convolution-matrix.la] Error 1 Also, if you actually make use of lensfun, the configuration script should check for its presence in the system and probably even provide an option to disable building the op that uses it. Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GsoC - 2011 - Porting GIMP plugins to GEGL operations
After writing the code reviews I ported the emboss plug-in to gegl. Should I upload to GIMP bugzilla ? Thanks, Robert Sasu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GsoC - 2011 - Porting GIMP plugins to GEGL operations
2011/4/7 Robert Sasu sasu.rob...@gmail.com: After writing the code reviews I ported the emboss plug-in to gegl. Should I upload to GIMP bugzilla ? Yes please, and don't forget to reference the patch in your GSoC 2011 application. BR, Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GsoC - 2011 - Porting GIMP plugins to GEGL operations
I am also a student working on it. We have to send it. If you already have a account then you can post it. But we are not able to create an account at present on that. So I am also in a confusion as to where to post it. On Thu, Apr 7, 2011 at 12:56 PM, Robert Sasu sasu.rob...@gmail.com wrote: After writing the code reviews I ported the emboss plug-in to gegl. Should I upload to GIMP bugzilla ? Thanks, Robert Sasu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Shivani Maheshwari Under Graduation( BTech.) Indian Institute of Information Technology, Allahabad (Amethi Campus) India ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GsoC - 2011 - Porting GIMP plugins to GEGL operations
Here is my last task. I attached the emboss plug-in ported to gegl. Just
paste in the gegl/operations/common, compile and run it.
If there is something wrong please write it and I will immidiatelly correct
it.
Thank you,
Robert Sasu
#include config.h
#include glib/gi18n-lib.h
#ifdef GEGL_CHANT_PROPERTIES
gegl_chant_double (azimuth, _(Azimuth), 0.0, 360.0, 30.0,
_(The value of azimuth))
gegl_chant_double (elevation, _(Elevation), 0.0, 180.0, 45.0,
_(The value of elevation))
gegl_chant_int(depth, _(Depth), 1, 100, 20,
_(Pixel depth))
gegl_chant_string (filter, _(Filter), emboss,
_(Optional parameter to override automatic selection of emboss filert.
Choices are emboss, blur-map ))
#else
#define GEGL_CHANT_TYPE_AREA_FILTER
#define GEGL_CHANT_C_FILE emboss.c
#define RADIUS 3
#include gegl-chant.h
#include math.h
#include stdio.h
static void
emboss (GeglBuffer *src,
const GeglRectangle *src_rect,
GeglBuffer *dst,
const GeglRectangle *dst_rect,
gchar *text,
gint floats_per_pixel, /*floats per pixel*/
gint alpha,
gdouble azimuth,
gdouble elevation,
gint depth)
{
gfloat *src_buf;
gfloat *dst_buf;
gint x;
gint y;
gintoffset, verify;
gint bytes;
gdouble Lx = cos (azimuth) * cos (elevation);
gdouble Ly = sin (azimuth) * cos (elevation);
gdouble Lz = sin (elevation) ;
gdouble Nz2 = 1 / (depth * depth);
gdouble NzLz = (1 / depth) * Lz;
bytes = (alpha) ? floats_per_pixel - 1 : floats_per_pixel;
src_buf = g_new0 (gfloat, src_rect-width * src_rect-height * floats_per_pixel);
dst_buf = g_new0 (gfloat, dst_rect-width * dst_rect-height * floats_per_pixel);
gegl_buffer_get (src, 1.0, src_rect, babl_format (text),
src_buf, GEGL_AUTO_ROWSTRIDE);
verify = src_rect-width*src_rect-height*floats_per_pixel;
offset = 0;
for (x = 0; x dst_rect-height; x++)
{
for (y = 0; y dst_rect-width; y++)
{
gint i, j, b, count;
gfloat Nx, Ny, NdotL;
gfloat shade;
gfloat M[3][3];
gfloat a;
for (i = 0; i 3; i++)
for (j = 0; j 3; j++)
M[i][j] = 0.0;
for (b = 0; b bytes; b++)
{
for (i = 0; i 3; i++)
for (j = 0; j 3; j++)
{
count = ((x+i-1)*src_rect-width + (y+j-1))*floats_per_pixel + bytes;
/*verify each time that we are in the source image*/
if (alpha count = 0 count verify)
a = src_buf[count];
else
a = 1.0;
/*calculate recalculate the sorrounding pixels by multiplication*/
/*after we have that we can calculate new value of the pixel*/
if ((count - bytes + b) = 0 (count - bytes + b) verify)
M[i][j] += a * src_buf[count - bytes + b];
}
}
Nx = M[0][0] + M[1][0] + M[2][0] - M[0][2] - M[1][2] - M[2][2];
Ny = M[2][0] + M[2][1] + M[2][2] - M[0][0] - M[0][1] - M[0][2];
/*calculating the shading result (same as in gimp)*/
if ( Nx == 0 Ny == 0 )
shade = Lz;
else if ( (NdotL = Nx * Lx + Ny * Ly + NzLz) 0 )
shade = 0;
else
shade = NdotL / sqrt(Nx*Nx + Ny*Ny + Nz2);
count = (x*src_rect-width + y)*floats_per_pixel;
if (bytes == 1)
dst_buf[offset++] = shade; /*setting the destination buffer*/
else
{
for (b = 0; b bytes; b++)
if ((count + b) = 0 (count + b) verify) /*recalculating every byte of a pixel*/
dst_buf[offset++] = (src_buf[count+b] * shade) ; /*by multiplying with the shading result*/
else
dst_buf[offset++] = 1.0;
if (alpha (count + bytes) = 0 (count + bytes) verify) /*preserving alpha*/
dst_buf[offset++] = src_buf[count + bytes];
else
dst_buf[offset++] = 1.0 ;
}
}
}
gegl_buffer_set (dst, dst_rect, babl_format (text),
dst_buf, GEGL_AUTO_ROWSTRIDE);
g_free (src_buf);
g_free (dst_buf);
}
static void prepare (GeglOperation *operation)
{
GeglChantO *o = GEGL_CHANT_PROPERTIES (operation);
GeglOperationAreaFilter *op_area = GEGL_OPERATION_AREA_FILTER (operation);
gchar *type;
gboolean filter_blurmap;
op_area-left=op_area-right=op_area-top=op_area-bottom=3;
filter_blurmap = o-filter !strcmp(o-filter, blur-map);
type = (filter_blurmap) ? RGBA float : Y float;
gegl_operation_set_format (operation, output, babl_format (type));
}
static gboolean
process (GeglOperation *operation,
GeglBuffer *input,
GeglBuffer *output,
const GeglRectangle *result)
{
GeglChantO *o = GEGL_CHANT_PROPERTIES (operation);
GeglOperationAreaFilter *op_area =
Re: [Gimp-developer] GsoC - 2011 - Porting GIMP plugins to GEGL operations
I've revised my code, adding comments and references. If there is anything
to correct please write it.
Thank you,
Robert Sasu
/* 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 http://www.gnu.org/licenses/.
*
* Algorithm 1997 Eric L. Hernes (er...@rrnet.com)
* Copyright 2011 Robert Sasu (sasu.rob...@gmail.com)
*/
#include config.h
#include glib/gi18n-lib.h
#ifdef GEGL_CHANT_PROPERTIES
gegl_chant_double (azimuth, _(Azimuth), 0.0, 360.0, 30.0,
_(The value of azimuth))
gegl_chant_double (elevation, _(Elevation), 0.0, 180.0, 45.0,
_(The value of elevation))
gegl_chant_int(depth, _(Depth), 1, 100, 20,
_(Pixel depth))
gegl_chant_string (filter, _(Filter), emboss,
_(Optional parameter to override automatic selection of emboss filert.
Choices are emboss, blur-map ))
#else
#define GEGL_CHANT_TYPE_AREA_FILTER
#define GEGL_CHANT_C_FILE emboss.c
#define RADIUS 3
#include gegl-chant.h
#include math.h
#include stdio.h
/*
* ANSI C code from the article
* Fast Embossing Effects on Raster Image Data
* by John Schlag, j...@kerner.com
* in Graphics Gems IV, Academic Press, 1994
*
*
* Emboss - shade 24-bit pixels using a single distant light source.
* Normals are obtained by differentiating a monochrome 'bump' image.
* The unary case ('texture' == NULL) uses the shading result as output.
* The binary case multiples the optional 'texture' image by the shade.
* Images are in row major order with interleaved color components (rgbrgb...).
* E.g., component c of pixel x,y of 'dst' is dst[3*(y*width + x) + c].
*
*/
static void
emboss (gfloat *src_buf,
const GeglRectangle *src_rect,
gfloat *dst_buf,
const GeglRectangle *dst_rect,
gint x,
gchar *text,
gint floats_per_pixel,
gint alpha,
gdouble azimuth,
gdouble elevation,
gint depth)
{
gint y;
gintoffset, verify;
gint bytes;
gdouble Lx = cos (azimuth) * cos (elevation);
gdouble Ly = sin (azimuth) * cos (elevation);
gdouble Lz = sin (elevation) ;
gdouble Nz2 = 1 / (depth * depth);
gdouble NzLz = (1 / depth) * Lz;
bytes = (alpha) ? floats_per_pixel - 1 : floats_per_pixel;
verify = src_rect-width*src_rect-height*floats_per_pixel;
offset = x * dst_rect-width * floats_per_pixel;
for (y = 0; y dst_rect-width; y++)
{
gint i, j, b, count;
gfloat Nx, Ny, NdotL;
gfloat shade;
gfloat M[3][3];
gfloat a;
for (i = 0; i 3; i++)
for (j = 0; j 3; j++)
M[i][j] = 0.0;
for (b = 0; b bytes; b++)
{
for (i = 0; i 3; i++)
for (j = 0; j 3; j++)
{
count = ((x+i-1)*src_rect-width + (y+j-1))*floats_per_pixel + bytes;
/*verify each time that we are in the source image*/
if (alpha count = 0 count verify)
a = src_buf[count];
else
a = 1.0;
/*calculate recalculate the sorrounding pixels by multiplication*/
/*after we have that we can calculate new value of the pixel*/
if ((count - bytes + b) = 0 (count - bytes + b) verify)
M[i][j] += a * src_buf[count - bytes + b];
}
}
Nx = M[0][0] + M[1][0] + M[2][0] - M[0][2] - M[1][2] - M[2][2];
Ny = M[2][0] + M[2][1] + M[2][2] - M[0][0] - M[0][1] - M[0][2];
/*calculating the shading result (same as in gimp)*/
if ( Nx == 0 Ny == 0 )
shade = Lz;
else if ( (NdotL = Nx * Lx + Ny * Ly + NzLz) 0 )
shade = 0;
else
shade = NdotL / sqrt(Nx*Nx + Ny*Ny + Nz2);
count = (x*src_rect-width + y)*floats_per_pixel;
/*setting the value of the destination buffer*/
if (bytes == 1)
dst_buf[offset++] = shade;
else
{
/*recalculating every byte of a pixel*/
/*by multiplying with the shading result*/
for (b = 0; b bytes; b++)
if ((count + b) = 0 (count + b) verify)
dst_buf[offset++] = (src_buf[count+b] * shade) ;
else
dst_buf[offset++] = 1.0;
/*preserving alpha*/
if (alpha (count + bytes) = 0 (count + bytes) verify)
dst_buf[offset++] = src_buf[count + bytes];
else
dst_buf[offset++]
Re: [Gimp-developer] GsoC - 2011 - Porting GIMP plugins to GEGL operations
I've revised my code, adding comments and references. If there is anything
to correct please write it.
Thank you,
Robert Sasu
/* 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 http://www.gnu.org/licenses/.
*
* Algorithm 1997 Eric L. Hernes (er...@rrnet.com)
* Copyright 2011 Robert Sasu (sasu.rob...@gmail.com)
*/
#include config.h
#include glib/gi18n-lib.h
#ifdef GEGL_CHANT_PROPERTIES
gegl_chant_double (azimuth, _(Azimuth), 0.0, 360.0, 30.0,
_(The value of azimuth))
gegl_chant_double (elevation, _(Elevation), 0.0, 180.0, 45.0,
_(The value of elevation))
gegl_chant_int(depth, _(Depth), 1, 100, 20,
_(Pixel depth))
gegl_chant_string (filter, _(Filter), emboss,
_(Optional parameter to override automatic selection of emboss filert.
Choices are emboss, blur-map ))
#else
#define GEGL_CHANT_TYPE_AREA_FILTER
#define GEGL_CHANT_C_FILE emboss.c
#define RADIUS 3
#include gegl-chant.h
#include math.h
#include stdio.h
/*
* ANSI C code from the article
* Fast Embossing Effects on Raster Image Data
* by John Schlag, j...@kerner.com
* in Graphics Gems IV, Academic Press, 1994
*
*
* Emboss - shade 24-bit pixels using a single distant light source.
* Normals are obtained by differentiating a monochrome 'bump' image.
* The unary case ('texture' == NULL) uses the shading result as output.
* The binary case multiples the optional 'texture' image by the shade.
* Images are in row major order with interleaved color components (rgbrgb...).
* E.g., component c of pixel x,y of 'dst' is dst[3*(y*width + x) + c].
*
*/
static void
emboss (gfloat *src_buf,
const GeglRectangle *src_rect,
gfloat *dst_buf,
const GeglRectangle *dst_rect,
gint x,
gchar *text,
gint floats_per_pixel,
gint alpha,
gdouble azimuth,
gdouble elevation,
gint depth)
{
gint y;
gintoffset, verify;
gint bytes;
gdouble Lx = cos (azimuth) * cos (elevation);
gdouble Ly = sin (azimuth) * cos (elevation);
gdouble Lz = sin (elevation) ;
gdouble Nz2 = 1 / (depth * depth);
gdouble NzLz = (1 / depth) * Lz;
bytes = (alpha) ? floats_per_pixel - 1 : floats_per_pixel;
verify = src_rect-width*src_rect-height*floats_per_pixel;
offset = x * dst_rect-width * floats_per_pixel;
for (y = 0; y dst_rect-width; y++)
{
gint i, j, b, count;
gfloat Nx, Ny, NdotL;
gfloat shade;
gfloat M[3][3];
gfloat a;
for (i = 0; i 3; i++)
for (j = 0; j 3; j++)
M[i][j] = 0.0;
for (b = 0; b bytes; b++)
{
for (i = 0; i 3; i++)
for (j = 0; j 3; j++)
{
count = ((x+i-1)*src_rect-width + (y+j-1))*floats_per_pixel + bytes;
/*verify each time that we are in the source image*/
if (alpha count = 0 count verify)
a = src_buf[count];
else
a = 1.0;
/*calculate recalculate the sorrounding pixels by multiplication*/
/*after we have that we can calculate new value of the pixel*/
if ((count - bytes + b) = 0 (count - bytes + b) verify)
M[i][j] += a * src_buf[count - bytes + b];
}
}
Nx = M[0][0] + M[1][0] + M[2][0] - M[0][2] - M[1][2] - M[2][2];
Ny = M[2][0] + M[2][1] + M[2][2] - M[0][0] - M[0][1] - M[0][2];
/*calculating the shading result (same as in gimp)*/
if ( Nx == 0 Ny == 0 )
shade = Lz;
else if ( (NdotL = Nx * Lx + Ny * Ly + NzLz) 0 )
shade = 0;
else
shade = NdotL / sqrt(Nx*Nx + Ny*Ny + Nz2);
count = (x*src_rect-width + y)*floats_per_pixel;
/*setting the value of the destination buffer*/
if (bytes == 1)
dst_buf[offset++] = shade;
else
{
/*recalculating every byte of a pixel*/
/*by multiplying with the shading result*/
for (b = 0; b bytes; b++)
if ((count + b) = 0 (count + b) verify)
dst_buf[offset++] = (src_buf[count+b] * shade) ;
else
dst_buf[offset++] = 1.0;
/*preserving alpha*/
if (alpha (count + bytes) = 0 (count + bytes) verify)
dst_buf[offset++] = src_buf[count + bytes];
else
dst_buf[offset++]
Re: [Gimp-developer] GsoC - 2011 - Porting GIMP plugins to GEGL operations
I removed the tabs and rewrite the code again. If there is anything to do,
please let me know.
Thank you,
Robert Sasu
/* 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 http://www.gnu.org/licenses/.
*
* Algorithm 1997 Eric L. Hernes (er...@rrnet.com)
* Copyright 2011 Robert Sasu (sasu.rob...@gmail.com)
*/
#include config.h
#include glib/gi18n-lib.h
#ifdef GEGL_CHANT_PROPERTIES
gegl_chant_double (azimuth, _(Azimuth), 0.0, 360.0, 30.0,
_(The value of azimuth))
gegl_chant_double (elevation, _(Elevation), 0.0, 180.0, 45.0,
_(The value of elevation))
gegl_chant_int(depth, _(Depth), 1, 100, 20,
_(Pixel depth))
gegl_chant_string (filter, _(Filter), emboss,
_(Optional parameter to override automatic selection of emboss filert.
Choices are emboss, blur-map ))
#else
#define GEGL_CHANT_TYPE_AREA_FILTER
#define GEGL_CHANT_C_FILEemboss.c
#define RADIUS 3
#include gegl-chant.h
#include math.h
#include stdio.h
/*
* ANSI C code from the article
* Fast Embossing Effects on Raster Image Data
* by John Schlag, j...@kerner.com
* in Graphics Gems IV, Academic Press, 1994
*
*
* Emboss - shade 24-bit pixels using a single distant light source.
* Normals are obtained by differentiating a monochrome 'bump' image.
* The unary case ('texture' == NULL) uses the shading result as output.
* The binary case multiples the optional 'texture' image by the shade.
* Images are in row major order with interleaved color components (rgbrgb...).
* E.g., component c of pixel x,y of 'dst' is dst[3*(y*width + x) + c].
*
*/
static void
emboss (gfloat *src_buf,
const GeglRectangle *src_rect,
gfloat *dst_buf,
const GeglRectangle *dst_rect,
gint x,
gchar *text,
gint floats_per_pixel,
gint alpha,
gdouble azimuth,
gdouble elevation,
gint depth)
{
gint y;
gint offset, verify;
gint bytes;
gdouble Lx = cos (azimuth) * cos (elevation);
gdouble Ly = sin (azimuth) * cos (elevation);
gdouble Lz = sin (elevation) ;
gdouble Nz2 = 1 / (depth * depth);
gdouble NzLz = (1 / depth) * Lz;
bytes = (alpha) ? floats_per_pixel - 1 : floats_per_pixel;
verify = src_rect-width*src_rect-height*floats_per_pixel;
offset = x * dst_rect-width * floats_per_pixel;
for (y = 0; y dst_rect-width; y++)
{
ginti, j, b, count;
gfloat Nx, Ny, NdotL;
gfloat shade;
gfloat M[3][3];
gfloat a;
for (i = 0; i 3; i++)
for (j = 0; j 3; j++)
M[i][j] = 0.0;
for (b = 0; b bytes; b++)
{
for (i = 0; i 3; i++)
for (j = 0; j 3; j++)
{
count = ((x+i-1)*src_rect-width + (y+j-1))*floats_per_pixel + bytes;
/*verify each time that we are in the source image*/
if (alpha count = 0 count verify)
a = src_buf[count];
else
a = 1.0;
/*calculate recalculate the sorrounding pixels by multiplication*/
/*after we have that we can calculate new value of the pixel*/
if ((count - bytes + b) = 0 (count - bytes + b) verify)
M[i][j] += a * src_buf[count - bytes + b];
}
}
Nx = M[0][0] + M[1][0] + M[2][0] - M[0][2] - M[1][2] - M[2][2];
Ny = M[2][0] + M[2][1] + M[2][2] - M[0][0] - M[0][1] - M[0][2];
/*calculating the shading result (same as in gimp)*/
if ( Nx == 0 Ny == 0 )
shade = Lz;
else if ( (NdotL = Nx * Lx + Ny * Ly + NzLz) 0 )
shade = 0;
else
shade = NdotL / sqrt(Nx*Nx + Ny*Ny + Nz2);
count = (x*src_rect-width + y)*floats_per_pixel;
/*setting the value of the destination buffer*/
if (bytes == 1)
dst_buf[offset++] = shade;
else
{
/*recalculating every byte of a pixel*/
/*by multiplying with the shading result*/
for (b = 0; b bytes; b++)
if ((count + b) = 0 (count + b) verify)
dst_buf[offset++] = (src_buf[count+b] * shade) ;
else
dst_buf[offset++] = 1.0;
/*preserving alpha*/
if (alpha (count + bytes) = 0
Re: [Gimp-developer] GsoC - 2011 - Porting GIMP plugins to GEGL operations
On Sat, Apr 2, 2011 at 3:24 AM, Jim Michaels jmich...@yahoo.com wrote: help me to understand. GIMP plugin authors will now be required to write their plugins in GEGL? GIMP has for a long time (decade) been moving towards using GEGL for it's imaging core. GEGL plugins do support higher bit depths like 16bit and 32bit floating point/high dynamic range. As of GIMP 2.6 you can already use GEGL operations in place of GIMP plug-ins with the GEGL tool, but GIMP has not yet migrated its storage of actual raster layer data to GEGL. There might in the future be a GEGL operation that permits running legacy GIMP plug-ins in a an emulator such emulated execution will however be rather destructive to higher bitdepth images as well as for strictly color managed workflows where the 8bit limitations will be leading to data/precision loss. as of what version of GIMP, if anyone knows? Hard to tell, but the actually useful plug-ins, and in particular the ones shipping with GIMP should be migrated, to gain benefits like on canvas preview, multi-threading and more. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GsoC - 2011 - Porting GIMP plugins to GEGL operations
help me to understand. GIMP plugin authors will now be required to write their plugins in GEGL? as of what version of GIMP, if anyone knows? From: Robert Sasu sasu.rob...@gmail.com To: gimp-developer@lists.XCF.Berkeley.EDU Sent: Wed, March 30, 2011 10:53:09 AM Subject: [Gimp-developer] GsoC - 2011 - Porting GIMP plugins to GEGL operations 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
Re: [Gimp-developer] GSoC 2011 Porting GIMP plugins to GEGL operations
On Tue, Mar 29, 2011 at 11:57 PM, sourav de souravde1...@gmail.com wrote: On Tue, Mar 29, 2011 at 1:15 PM, sourav de souravde1...@gmail.com wrote: On Tue, Mar 29, 2011 at 4:11 AM, Mukund Sivaraman m...@banu.com wrote: Hi Sourav On Tue, Mar 29, 2011 at 12:36:04AM +0530, sourav de wrote: Hi, I am a 2nd year student of the department of Computer Science and Engineering at Indian Institute of Technology, Kharagpur ,and I am interested in the plugin for cartoonization of an image in GIMP. I gather you want to modify the cartoon plug-in in GIMP? The plug-in porting task that you have mentioned in the subject is to directly port GIMP plug-ins to GEGL ops. No modification of functionality is necessary. It is described here: http://gimp-wiki.who.ee/index.php?title=Hacking:GSoC_2011/Ideas#Porting_GIMP_plugins_to_GEGL_operations It is not a task of porting only 1 plug-in, but about 6-10 plug-ins per student. 1 plug-in is a very easy task and will not be sufficiently long for a full summer's work. To apply for this task, please present the items mentioned on the linked wiki page. However, if you wish to modify the cartoon plug-in, that sounds interesting too. It can be a different task. Can you describe what is lacking in the current approach in the GIMP plug-in? What is the algorithm that you plan to use ? You say you are doing a project on algorithmic art.. have you published anything on the methods you wish to use in this cartoon plug-in? Are you using any other published works? Note that we _may_ accomodate more tasks if they are of a high quality and we are satisfied with how the student presents it. Mukund Thank you sir, for your comments, I'll come up with the presentation of those plug-ins mentioned in the wiki page and algorithm for the cartoonization plug-in soon. And for the project on algorithmic art, I took this project in my current semester, I'll have to take the course Computer Graphics in my next semester to complete the project. So far I haven't yet publish any paper. -- Sourav De 2nd Year Student Department of Computer Science and Engineering IIT KHARAGPUR I wrote the code review for gaussian blur as it given here http://git.gnome.org/browse/gegl/tree/operations/common/gaussian-blur.c But I'm not familiar with writing code review and algorithmic description. Here goes my code review. ---code review starts here Gaussian blur operation code review: 1. function-1 : static void iir_young_find_constants (gfloat sigma,gdouble *B,gdouble *b) a. the variable sigma is to avoid unexpected ringing at tile boundaries of an image. b. there exists a variable q, whose value must be remained in between 0 - 1.5, and according to the value of sigma there are two procedures to calculate the value of q. c. lastly it sets the value of the variables b[0] to b[3] and B, and then returns. 2. function-2 : static inline void iir_young_blur_1D (gfloat * buf,gint offset,gint delta_offset,gdouble B,gdouble *b,gfloat * w,gint w_len) a. this function blurrifies an image one dimensionally. b. wlen is the length of the 1d array w passed. c. here an image would be blurrified in two steps, applying forward and backward filter for each pixel, a local variable wcount counts the number of pixels each time. d. the filter would be applied to the image according to the passed array w. 3. function-3 : static void iir_young_hor_blur (GeglBuffer *src,const GeglRectangle *src_rect,GeglBuffer *dst,const GeglRectangle *dst_rect,gdouble B,gdouble *b) a. this function blurrifies an image horizontally. b. first it creates an one dimensional array buf whose length is height*width*4, where height and width is height and width of the source image rectangle. c. then it creates another one dimensional array w with the length of the width of the source image. d. after then it fills the values of buf array according to the source image in RaGaBaA format. e. then it applies the iir_young_blur_1D function to the newly generated ractangles. f. lastly it stores the change in a destination array and returns. 4. function-4 : static void iir_young_ver_blur (GeglBuffer *src,const GeglRectangle *src_rect,GeglBuffer *dst,const GeglRectangle *dst_rect,gdouble B, gdouble *b) a. this function blurrifies an image vertically. b. first it creates an one dimensional array buf whose length is height*width*4, where height and width is height and width of the source image rectangle. c. then it creates another one dimensional array w with the length of the height of the source image. d. after then it fills the values of buf array according to the source image in RaGaBaA format. e. then it applies the iir_young_blur_1D function to the newly generated ractangles. f. lastly it stores the change in a destination array and returns. 5. function-5 : static gint fir_calc_convolve_matrix_length
Re: [Gimp-developer] GsoC - 2011 - Porting GIMP plugins to GEGL operations
I wrote the code review for 2 more plug-ins: Cartoon and Photocopy Gimp dialog function do all almost the same thing: Let the user choose the parameters for each plugin by opening a box with a preview box. While changing the parameters it changes the preview image until the user press the ok or the cancel button. We can say the same thing for run function (almost the same). It gets the drawable in the drawable structure the sets the tile cache size, gets data from the keyboard and run the dialog, if there is no dialog it initiates its own values for the plug-in. Checks if everything is all right, run the plugin and stores the data. 1. Cartoon (in gegl the base class would be AREA FILTER): Algorithm: For each pixel it calculates the pixel intensity by comparing the pixels relative intesity to its neighborhood pixels and to the relative intensity difference to total black . Let say mask radius is equal with radius of pixel neighborhood for intensity comparison, threshold is the relative intensity difference which will result in darkening, ramp is the amount of relative intensity difference before total black and blur radius is mask radius per 3. Then the new intensity of the pixel will be: relative difference = pixel intensity / average (mask radius) If relative difference Threshold intensity multiply = (Ramp - MIN (Ramp, (Threshold - relative difference))) / Ramp pixel intensity =old intensity * intensity mult static void cartoon: Checks for the preview, then sets the width and height of the drawable image, gets the image type (bytes) and the aplha value (has_alpha). It initialize the 5 vectors and 2 destination image structures (dest1 for blur radius and dest2 for mask radius). Calculates the standard deviations from blur and mask radius. Then derives the constant values for calculating the gaussian's from the deviations (via the 4th order approximation of the gaussian operator). Like in the case of gaussian blur the calculation of the new values of the image is linear so the calculation can be devided for 2 directions. First calculates the values for every column then for every row. Calculating for every column: firstly initializes and calculates the first and the last pixel of the column. Then with the help of the gaussian constants it calculates every pixel of the column the transfers the pixels to the destination image. It will do the same calculations in case of the horizontal direction. After calculating the blakc percentage value (ramp). Then calculates the new intensity for each pixel: relative difference = pixel intensity / average (mask radius) intensity multiply=1 If relative difference Threshold intensity multiply = (Ramp - MIN (Ramp, (Threshold - relative difference))) / Ramp pixel intensity =old intensity * intensity multiply Before upgrading the drawable image transfers the calculated destination image structure from RGB format to HLS, sets the lightness and converts back. computer ramp: Calculates the ramp value (intensity difference from total black) by calculating the difference between the destination images (one calculated with blur radius the other with mask radius), and hysterizes the difference. Then compares the hysterized values to the percentage of the black color and calculates the relative intensity via average. 2. Photocopy (in gegl the base class would be AREA FILTER): Propagates dark value in an image based on each pixel's relative darkness to a neighboring average. Sets the remaining pixels to white. The plug-in differs a little from the cartoon plug-in. Algorithm: Using the same notations as in the cartoon plug-in the new intensity of every pixel will be: elative diff = pixel intensity / avg (mask radius) If relative diff Threshold intensity mult = (Ramp - MIN (Ramp, (Threshold - relative diff))) / Ramp pixel intensity *= intensity mult Else pixel intensity = white static void photocopy: It is almost the same as in the cartoon plug-in. Desaturates the image, checks for the preview, then sets the width and height of the drawable image, gets the image type (bytes) and the aplha value (has_alpha). It initialize the 5 vectors and 2 destination image structures (dest1 for blur radius and dest2 for mask radius). Calculates the standard deviations from blur and mask radius. Then derives the constant values for calculating the gaussian's from the deviations (via the 4th order approximation of the gaussian operator). Like in the case of gaussian blur the calculation of the new values of the image is linear so the calculation can be devided for 2 directions. First calculates the values for every column then for every row. Calculating for every column: firstly initializes and calculates the first and the last pixel of the column. Then with the help of the gaussian constants it calculates every pixel of the column the transfers the pixels to the destination image. It will do the same calculations in case
Re: [Gimp-developer] GsoC - 2011 - Porting GIMP plugins to GEGL operations
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
Re: [Gimp-developer] GSoC 2011 Porting GIMP plugins to GEGL operations
On Tue, Mar 29, 2011 at 4:11 AM, Mukund Sivaraman m...@banu.com wrote: Hi Sourav On Tue, Mar 29, 2011 at 12:36:04AM +0530, sourav de wrote: Hi, I am a 2nd year student of the department of Computer Science and Engineering at Indian Institute of Technology, Kharagpur ,and I am interested in the plugin for cartoonization of an image in GIMP. I gather you want to modify the cartoon plug-in in GIMP? The plug-in porting task that you have mentioned in the subject is to directly port GIMP plug-ins to GEGL ops. No modification of functionality is necessary. It is described here: http://gimp-wiki.who.ee/index.php?title=Hacking:GSoC_2011/Ideas#Porting_GIMP_plugins_to_GEGL_operations It is not a task of porting only 1 plug-in, but about 6-10 plug-ins per student. 1 plug-in is a very easy task and will not be sufficiently long for a full summer's work. To apply for this task, please present the items mentioned on the linked wiki page. However, if you wish to modify the cartoon plug-in, that sounds interesting too. It can be a different task. Can you describe what is lacking in the current approach in the GIMP plug-in? What is the algorithm that you plan to use ? You say you are doing a project on algorithmic art.. have you published anything on the methods you wish to use in this cartoon plug-in? Are you using any other published works? Note that we _may_ accomodate more tasks if they are of a high quality and we are satisfied with how the student presents it. Mukund Thank you sir, for your comments, I'll come up with the presentation of those plug-ins mentioned in the wiki page and algorithm for the cartoonization plug-in soon. And for the project on algorithmic art, I took this project in my current semester, I'll have to take the course Computer Graphics in my next semester to complete the project. So far I haven't yet publish any paper. -- Sourav De 2nd Year Student Department of Computer Science and Engineering IIT KHARAGPUR ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSOC 2011 - GEGL: Make OpenGL branch use OpenCL
On Sun, Mar 27, 2011 at 8:08 PM, Victor Oliveira victormath...@gmail.com wrote: Hello everyone. My name is Victor Oliveira. I'm a master's student at the School of Electrical and Computer Engineering - University of Campinas, Brazil. I work with Image Processing and Machine Learning and I've been using GPUs (CUDA) in my work since 2009. More recently, we've migrated our projects to OpenCL, which has given me more experience with GPU programming. I have a strong background in C/C++ and Python. Also, I've been using GEGL for some time in my projects. I noticed a while ago that there is a branch [http://git.gnome.org/browse/gegl/tree?h=gsoc2009-gpu] that wasn't merged in GEGL's main tree. If I understood it correctly, this specific branch is able to do pixelwise operations using OpenGL shaders and automatic memory management beetween the cpu and gpu. My idea is to use this memory management scheme to allow gegl operations with OpenCL. I've already presented this idea in #gegl without further details and I'd like to discuss it here. If moving to OpenCL, (and if OpenCL needs separately managed memory; which I think it does) basing it on the existing unmerged GPU branch would be the best plan moving forward. The general gist of the work that was done in the previous gsoc was to extend GeglBuffer with the ability to have a separate, internal backend/cache of gpu side tiles, that have their own revision; when tiles are requested either on the gpu or cpu side, migration is done automatically to ensure that the newest version is used. This management scheme was succesfully implemented for GLSL based shaders and proof of concept implementations of some point operations were done. Repeating the things that were done in this gsoc for OpenCL should not take as long as it did for the original GPU branch since a lot of the issues would already be solved. If core color correction, compositing ops and gaussian blur have vfuncs for GPU side processing; many simpler compositions would be possible to do fully on the GPU - while compositions with some cpu based ops would do the migration back and forth as needed (with incurred performance impact). Another important issue when implementing a new set of vfunc for the OpenCL code (which would have to be fully conditional at compile time, to keep GEGL buildable without). One thing that could be interesting to do is to make it possible to turn on a runtime flag that tests the OpenCL paths against the cpu paths when running GEGLs test suite, thus ensuring that the results are really interchangeable. The first step would be adapting the existing code and re-implementing the pixelwise operations in OpenCL. Meanwhile, we have to remember that OpenCL can be compiled to run in the cpu also, so we don't need to make memory transfers in this case. I do not know enough details about OpenCL and its data buffers to asses how this best would be done. Though it would be interesting to see how the code generated compares with the existing cpu code; if fully free software toolchains for OpenCL (perhaps using LLVM) emerges, it could be interesting to use OpenCL as the officially encouraged way of implementing GEGL ops. /Øyvind K - GEGL maintainer -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSOC 2011 - GEGL: Make OpenGL branch use OpenCL
On Tue, Mar 29, 2011 at 2:36 PM, Øyvind Kolås pip...@gimp.org wrote: On Sun, Mar 27, 2011 at 8:08 PM, Victor Oliveira victormath...@gmail.com wrote: Hello everyone. My name is Victor Oliveira. I'm a master's student at the School of Electrical and Computer Engineering - University of Campinas, Brazil. I work with Image Processing and Machine Learning and I've been using GPUs (CUDA) in my work since 2009. More recently, we've migrated our projects to OpenCL, which has given me more experience with GPU programming. I have a strong background in C/C++ and Python. Also, I've been using GEGL for some time in my projects. I noticed a while ago that there is a branch [http://git.gnome.org/browse/gegl/tree?h=gsoc2009-gpu] that wasn't merged in GEGL's main tree. If I understood it correctly, this specific branch is able to do pixelwise operations using OpenGL shaders and automatic memory management beetween the cpu and gpu. My idea is to use this memory management scheme to allow gegl operations with OpenCL. I've already presented this idea in #gegl without further details and I'd like to discuss it here. If moving to OpenCL, (and if OpenCL needs separately managed memory; which I think it does) basing it on the existing unmerged GPU branch would be the best plan moving forward. The general gist of the work that was done in the previous gsoc was to extend GeglBuffer with the ability to have a separate, internal backend/cache of gpu side tiles, that have their own revision; when tiles are requested either on the gpu or cpu side, migration is done automatically to ensure that the newest version is used. This management scheme was succesfully implemented for GLSL based shaders and proof of concept implementations of some point operations were done. Repeating the things that were done in this gsoc for OpenCL should not take as long as it did for the original GPU branch since a lot of the issues would already be solved. If core color correction, compositing ops and gaussian blur have vfuncs for GPU side processing; many simpler compositions would be possible to do fully on the GPU - while compositions with some cpu based ops would do the migration back and forth as needed (with incurred performance impact). Another important issue when implementing a new set of vfunc for the OpenCL code (which would have to be fully conditional at compile time, to keep GEGL buildable without). One thing that could be interesting to do is to make it possible to turn on a runtime flag that tests the OpenCL paths against the cpu paths when running GEGLs test suite, thus ensuring that the results are really interchangeable. Maybe we can also use this to benchmark plug-ins and see if the speedup of using OpenCL is greater than the overhead during buffer migrations. The first step would be adapting the existing code and re-implementing the pixelwise operations in OpenCL. Meanwhile, we have to remember that OpenCL can be compiled to run in the cpu also, so we don't need to make memory transfers in this case. I do not know enough details about OpenCL and its data buffers to asses how this best would be done. Though it would be interesting to see how the code generated compares with the existing cpu code; if fully free software toolchains for OpenCL (perhaps using LLVM) emerges, it could be interesting to use OpenCL as the officially encouraged way of implementing GEGL ops. This is a nice topic. A (sufficient smart :) compiler probably is able to generate optimized code for OpenCL in an easier way than C. OpenCL language is naturally data-parallel, which allows vector instructions, for example. So what are the next steps then? Do i have to write a more formal proposal? /Øyvind K - GEGL maintainer -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSoC 2011 Porting GIMP plugins to GEGL operations
On Tue, Mar 29, 2011 at 1:15 PM, sourav de souravde1...@gmail.com wrote: On Tue, Mar 29, 2011 at 4:11 AM, Mukund Sivaraman m...@banu.com wrote: Hi Sourav On Tue, Mar 29, 2011 at 12:36:04AM +0530, sourav de wrote: Hi, I am a 2nd year student of the department of Computer Science and Engineering at Indian Institute of Technology, Kharagpur ,and I am interested in the plugin for cartoonization of an image in GIMP. I gather you want to modify the cartoon plug-in in GIMP? The plug-in porting task that you have mentioned in the subject is to directly port GIMP plug-ins to GEGL ops. No modification of functionality is necessary. It is described here: http://gimp-wiki.who.ee/index.php?title=Hacking:GSoC_2011/Ideas#Porting_GIMP_plugins_to_GEGL_operations It is not a task of porting only 1 plug-in, but about 6-10 plug-ins per student. 1 plug-in is a very easy task and will not be sufficiently long for a full summer's work. To apply for this task, please present the items mentioned on the linked wiki page. However, if you wish to modify the cartoon plug-in, that sounds interesting too. It can be a different task. Can you describe what is lacking in the current approach in the GIMP plug-in? What is the algorithm that you plan to use ? You say you are doing a project on algorithmic art.. have you published anything on the methods you wish to use in this cartoon plug-in? Are you using any other published works? Note that we _may_ accomodate more tasks if they are of a high quality and we are satisfied with how the student presents it. Mukund Thank you sir, for your comments, I'll come up with the presentation of those plug-ins mentioned in the wiki page and algorithm for the cartoonization plug-in soon. And for the project on algorithmic art, I took this project in my current semester, I'll have to take the course Computer Graphics in my next semester to complete the project. So far I haven't yet publish any paper. -- Sourav De 2nd Year Student Department of Computer Science and Engineering IIT KHARAGPUR I wrote the code review for gaussian blur as it given here http://git.gnome.org/browse/gegl/tree/operations/common/gaussian-blur.c But I'm not familiar with writing code review and algorithmic description. Here goes my code review. ---code review starts here Gaussian blur operation code review: 1. function-1 : static void iir_young_find_constants (gfloat sigma,gdouble *B,gdouble *b) a. the variable sigma is to avoid unexpected ringing at tile boundaries of an image. b. there exists a variable q, whose value must be remained in between 0 - 1.5, and according to the value of sigma there are two procedures to calculate the value of q. c. lastly it sets the value of the variables b[0] to b[3] and B, and then returns. 2. function-2 : static inline void iir_young_blur_1D (gfloat * buf,gint offset,gint delta_offset,gdouble B,gdouble *b,gfloat * w,gint w_len) a. this function blurrifies an image one dimensionally. b. wlen is the length of the 1d array w passed. c. here an image would be blurrified in two steps, applying forward and backward filter for each pixel, a local variable wcount counts the number of pixels each time. d. the filter would be applied to the image according to the passed array w. 3. function-3 : static void iir_young_hor_blur (GeglBuffer *src,const GeglRectangle *src_rect,GeglBuffer *dst,const GeglRectangle *dst_rect,gdouble B,gdouble *b) a. this function blurrifies an image horizontally. b. first it creates an one dimensional array buf whose length is height*width*4, where height and width is height and width of the source image rectangle. c. then it creates another one dimensional array w with the length of the width of the source image. d. after then it fills the values of buf array according to the source image in RaGaBaA format. e. then it applies the iir_young_blur_1D function to the newly generated ractangles. f. lastly it stores the change in a destination array and returns. 4. function-4 : static void iir_young_ver_blur (GeglBuffer *src,const GeglRectangle *src_rect,GeglBuffer *dst,const GeglRectangle *dst_rect,gdouble B, gdouble *b) a. this function blurrifies an image vertically. b. first it creates an one dimensional array buf whose length is height*width*4, where height and width is height and width of the source image rectangle. c. then it creates another one dimensional array w with the length of the height of the source image. d. after then it fills the values of buf array according to the source image in RaGaBaA format. e. then it applies the iir_young_blur_1D function to the newly generated ractangles. f. lastly it stores the change in a destination array and returns. 5. function-5 : static gint fir_calc_convolve_matrix_length (gdouble sigma) a. depending upon the value of sigma it returns an integer which partially determines the width and height of the
Re: [Gimp-developer] GSOC 2011 - EXIF data viewer and editor
On 3/30/11, Cameron Christiansen wrote: For my project I propose creating an EXIF/xmp viewer/editor. http://git.gnome.org/browse/gimp/tree/plug-ins/metadata/ Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gsoc 2011] Unified transformation tool
Hi Austin, This sounds pretty neat. I believe that since gimp still has certain tools in which one can undo the individual steps of that tool till one changes the tool, so I believe that there would already be a good enough infra tour for this. Still any ideas who might be a good person to discuss my ideas regarding the ui. The specification for the unified transform tool seem to be added on wiki by guiguru, any idea if he is on the mailing list. Regards, Mohit On Monday, March 28, 2011, Austin Donnelly -- yahoo austin_donne...@yahoo.co.uk wrote: I did the last major changes to the undo system, to support the Undo History dialog. When I last looked, there was only a single stack of undo actions. Some of those actions are special start undo group and end undo group markers: think of them as brackets ( ) around the individual operations. If you have an undo stack: A B (C D) E older - newer Then when you undo the ) operation, it undoes D, then C, then hits ( so it pops that an stops. It would be fairly straightforwards to modify the logic to handle the case when you don't have a closed undo group: A B (C D In fact, the code might already do this. The main problem is that there is no user-accessible way to start a group without also closing it. Mostly, groups are used for running plugins or other composite commands. Good luck! Austin -Original Message- From: gimp-developer-boun...@lists.xcf.berkeley.edu [mailto:gimp-developer-boun...@lists.xcf.berkeley.edu] On Behalf Of David Gowers (kampu) Sent: 27 March 2011 08:31 To: Mohit _ Cc: gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] [Gsoc 2011] Unified transformation tool On Sun, Mar 27, 2011 at 3:42 PM, Mohit _ mtan.n...@gmail.com wrote: David, Thanks for the reply, but in the case of undo group, are the sub components of that group still saved individually in some sort of stack or are there different stacks for the group, and one general stack for all the groups. Also, it would be great if you could point me to the code where it is happening. I have no idea about how the implementation works internally :) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSoC 2011 Porting GIMP plugins to GEGL operations
Hi Sourav On Tue, Mar 29, 2011 at 12:36:04AM +0530, sourav de wrote: Hi, I am a 2nd year student of the department of Computer Science and Engineering at Indian Institute of Technology, Kharagpur ,and I am interested in the plugin for cartoonization of an image in GIMP. I gather you want to modify the cartoon plug-in in GIMP? The plug-in porting task that you have mentioned in the subject is to directly port GIMP plug-ins to GEGL ops. No modification of functionality is necessary. It is described here: http://gimp-wiki.who.ee/index.php?title=Hacking:GSoC_2011/Ideas#Porting_GIMP_plugins_to_GEGL_operations It is not a task of porting only 1 plug-in, but about 6-10 plug-ins per student. 1 plug-in is a very easy task and will not be sufficiently long for a full summer's work. To apply for this task, please present the items mentioned on the linked wiki page. However, if you wish to modify the cartoon plug-in, that sounds interesting too. It can be a different task. Can you describe what is lacking in the current approach in the GIMP plug-in? What is the algorithm that you plan to use ? You say you are doing a project on algorithmic art.. have you published anything on the methods you wish to use in this cartoon plug-in? Are you using any other published works? Note that we _may_ accomodate more tasks if they are of a high quality and we are satisfied with how the student presents it. Mukund pgpXNNaS9ZY5s.pgp Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gsoc 2011] Unified transformation tool
Hello, On Sat, Mar 26, 2011 at 8:20 PM, Mohit _ mtan.n...@gmail.com wrote: Hi, In the undo section it is mentioned that until the final pixel recalculation is done user should be able to undo every single step, though after that user should be able to undo the aggregate transformation only. Does this means that we would have to maintain another action stack just for unified transformation tool, or does gimp currently also maintains two different stacks, one for the current tool and one global stack for actions. If this is the case some reference to where it happens in code would be great. Although I'm nobody official, I believe that this would happen through the undo-group mechanism. That is, when the latest group of undos was not 'closed', we should undo within the group, and once it is 'closed', we should undo the group as a unit (undoing an undo group as a unit is what currently happens in general) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gsoc 2011] Unified transformation tool
David, Thanks for the reply, but in the case of undo group, are the sub components of that group still saved individually in some sort of stack or are there different stacks for the group, and one general stack for all the groups. Also, it would be great if you could point me to the code where it is happening. On Sun, Mar 27, 2011 at 4:14 AM, David Gowers (kampu) 00a...@gmail.comwrote: Hello, On Sat, Mar 26, 2011 at 8:20 PM, Mohit _ mtan.n...@gmail.com wrote: Hi, In the undo section it is mentioned that until the final pixel recalculation is done user should be able to undo every single step, though after that user should be able to undo the aggregate transformation only. Does this means that we would have to maintain another action stack just for unified transformation tool, or does gimp currently also maintains two different stacks, one for the current tool and one global stack for actions. If this is the case some reference to where it happens in code would be great. Although I'm nobody official, I believe that this would happen through the undo-group mechanism. That is, when the latest group of undos was not 'closed', we should undo within the group, and once it is 'closed', we should undo the group as a unit (undoing an undo group as a unit is what currently happens in general) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GsoC - 2011 - Porting GIMP plugins to GEGL operations
On Thu, Mar 24, 2011 at 1:06 AM, LightningIsMyName lightningismyn...@gmail.com wrote: The name cloning is misleading - this tool has nothing to do with regular paint tools. if it reminds anything by interaction, it's the cage tool - you select a shape, move it around (hopefully with a live preview of what will happen if you drop it there) and then release when satisfied. Please see the demo video if you want to see what I mean - it's on the article page. I'm restoring this idea to the wiki's recommended list. Hmm, ok, this is different. It seems this was universally assumed to be an enhancement on top of existing clone tool. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GsoC - 2011 - Porting GIMP plugins to GEGL operations
The best way to think of this, I believe, is as an enhancement of copy-and-paste. We are all familiar with the problem that if you make your selection large enough to include all of an object, you often get a fringe of unwanted colors. If you make the selection small enough to lose the fringe, the object gets unnatural-looking edges. It ought to be possible to use the healing concept to make a copy that suppresses the fringe -- it could never work perfectly, but would be good enough to be very useful. It makes more sense, to me, to first work this out in the context of copy-and-paste before extending it to tools, which bring in a lot of extra machinery. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GsoC - 2011 - Porting GIMP plugins to GEGL operations
On Tue, Mar 22, 2011 at 10:07 PM, Robert Sasu sasu.rob...@gmail.com wrote: I've read the e-mails about this project from the mailing list and I found actually what I have to do. I also looked at the source code and the differences between gimp and gegl implementation. If it is possible I would like a short list of plugins to look at, which are needed to be implemented ? We sort of expect you to come with your own plan :) So make a list of things you find interesting and show it off at IRC. And again: how important do you find this project compared to others for this years GSoC? Importance really hasn't been assigned to tasks. There are couple of projects that if right people pick them up, would probably get preference in slot selection, however you would most likely compete against established contributors on them, so odds of getting a slot would be low. Kevin, cloning was kicked, because welding pixel manipulation code on old paint core is not a good idea, new pixel manipulation should go in gegl and we simply dont have the infrastructure to use that in paint core yet. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GsoC - 2011 - Porting GIMP plugins to GEGL operations
Alexandre Prokoudine wrote: The agreement was not to introduce new tools based on old core, and GEGL based tool here means underlying GEGL painting infrastructure which is simply not ready yet. Ok. The wiki page says it is for this years GSoC. On my machine the Recommended and For a later GSoC headings get lost when you are scrolling down the page as they are appear in a thin regular type face compared to the nice bold fonts used to show project ideas. The ideas for a future GSoC should be moved to a separate page. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GsoC - 2011 - Porting GIMP plugins to GEGL operations
Hi, On Wed, Mar 23, 2011 at 8:32 AM, Alexia Death alexiade...@gmail.com wrote: Kevin, cloning was kicked, because welding pixel manipulation code on old paint core is not a good idea, new pixel manipulation should go in gegl and we simply dont have the infrastructure to use that in paint core yet. The name cloning is misleading - this tool has nothing to do with regular paint tools. if it reminds anything by interaction, it's the cage tool - you select a shape, move it around (hopefully with a live preview of what will happen if you drop it there) and then release when satisfied. Please see the demo video if you want to see what I mean - it's on the article page. I'm restoring this idea to the wiki's recommended list. ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GsoC - 2011 - Porting GIMP plugins to GEGL operations
Robert Sasu wrote: I am Robert Sasu and I wrote an e-mail in the morning about the application for the Adaptive Image Cloning. Since then I've spoken with mentors on IRC, and they said that this project is no more available. I don't know who told you that or why but Adaptive Image Cloning (aka Seamless Cloning) is on the list of possible GSoC projects for this year. The student application period doesn't open until the 28th of this month so all projects are up for grabs at this point. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GsoC - 2011 - Porting GIMP plugins to GEGL operations
On 3/23/11, Kevin Cozens wrote: Robert Sasu wrote: I am Robert Sasu and I wrote an e-mail in the morning about the application for the Adaptive Image Cloning. Since then I've spoken with mentors on IRC, and they said that this project is no more available. I don't know who told you that mitch and Alexia or why The agreement was not to introduce new tools based on old core, and GEGL based tool here means underlying GEGL painting infrastructure which is simply not ready yet. Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSoC 2011
Hi, alexandre.prokoud...@gmail.com (2011-03-20 at 2227.33 +0300): On 3/20/11, Bill Skaggs wrote: I think it would be pretty difficult to figure out the algorithm by looking at the Gimp source code. The algorithm that Gimp uses is based on papers by Todor Georgiev, and you can find a description of the algorithm in a paper he wrote called Photoshop Healing Brush: a Tool for Seamless Cloning -- you can access a PDF version at http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.109.5521rep=rep1type=pdf Note that Gimp only uses the Laplacian method that he describes, not the more sophisticated fourth-order version. GIMP's implementation is prone to errors which is especially visible when you heal near a visible border. I'm not entirely sure it's a good idea to learn from it. Was not that due to running the algorithm per brush stamp instead of for the full paint stroke? IIRC when using a big enough brush tip and just clicking once to cover the error, it worked. And PS applied/s the solver once you end the stroke. In other words, the system is correct internally, but the final touch is missing. GSR ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSoC 2011
@Alexandre Prokoudine Actually I was referring about the algorithm (Existing in current GIMP Versions) to get familiar with... I will look into the source code!!! ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSoC 2011
On Sun, Mar 20, 2011 at 9:22 PM, Ashok1288 asok1...@gmail.com wrote @Alexandre Prokoudine Actually I was referring about the algorithm (Existing in current GIMP Versions) to get familiar with... Do you mean the heal tool? app/tools/gimphealtool.* app/paint/gimpheal.* are where you should look for a start! ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSoC 2011
Well!! I will look into!! Thanks for your Reply!! ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSoC 2011
I think it would be pretty difficult to figure out the algorithm by looking at the Gimp source code. The algorithm that Gimp uses is based on papers by Todor Georgiev, and you can find a description of the algorithm in a paper he wrote called Photoshop Healing Brush: a Tool for Seamless Cloning -- you can access a PDF version at http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.109.5521rep=rep1type=pdf Note that Gimp only uses the Laplacian method that he describes, not the more sophisticated fourth-order version. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSoC 2011
On 3/20/11, Bill Skaggs wrote: I think it would be pretty difficult to figure out the algorithm by looking at the Gimp source code. The algorithm that Gimp uses is based on papers by Todor Georgiev, and you can find a description of the algorithm in a paper he wrote called Photoshop Healing Brush: a Tool for Seamless Cloning -- you can access a PDF version at http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.109.5521rep=rep1type=pdf Note that Gimp only uses the Laplacian method that he describes, not the more sophisticated fourth-order version. GIMP's implementation is prone to errors which is especially visible when you heal near a visible border. I'm not entirely sure it's a good idea to learn from it. Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSoC 2011
On 3/20/11, Ashok1288 wrote: I am interested in your project of implementing adaptive image cloning in Gimp.. Is it possible to get the code for this particular instead of surfing around the whole..to get familiar with Gimp? also about the algorithm used in previous versions and current one.. to get myself familiar? This algorithm isn't implemented yet, that's why it's the potential GSoC project. What exactly do you want to get familiar with? :) Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSoC 2011
On Sunday, March 20, 2011 05:46:56 Alexandre Prokoudine wrote: On 3/20/11, Ashok1288 wrote: I am interested in your project of implementing adaptive image cloning in Gimp.. Is it possible to get the code for this particular instead of surfing around the whole..to get familiar with Gimp? also about the algorithm used in previous versions and current one.. to get myself familiar? http://gimp-wiki.who.ee/index.php/Hacking:GSOC This is my personal list of things that a potential GSOC student should do.The same wiki also has pages some of the most frequend beginner questions. Best, Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSoC 2011 announced
On 26.01.2011 06:51, Martin Nordholts wrote: On 01/25/2011 05:52 AM, Alexandre Prokoudine wrote: Google has just announced GSoC2011. Schumaml: Will you be our GSoC master this year too? If so, that would be great. Thanks for having confidence in me again :) In order to participate successfully, we'll have to care about the following key aspects: 1. Mentors 2. Projects 3. Students 1. Mentors -- Mentors are supposed to help the students with their project, by defining an evaluating goals, any problems they may have, and are responsible for rating the projects at least twice (midterm and end). Usually, the mentors know fairly well what types of projects they'd like to mentor. It would be nice if potential mentors would introduce themselves on the gimp-developer list, and provide some information about the projects they'd like to mentor most - either very specific ideas or generic (beginner-level python plug-in), what they'll expect from their students, what they'd like to have for qualifications tasks, ... 2. Projects --- We'll need some viable and manageable projects for the students. Viable means that if the project is successful, it will be integrated into GIMP as soon as possible* (in the master branch, at least). This means that anything - GUI in particular - has to be approved by guiguru and the inner circle of active developers. Projects suggested by students without prior consulting may be very hard to fit into these requirements. The goal of the projects should always be new contributors, not just the code produced during GSoC. 3. Students --- Due to the recent news items about the lack of developers, there is the chance that we may be a bit overwhelmed by student applications. We should have a very precise idea about the number of projects we can handle, and not sacrifice quality of mentoring for quantity (like one mentor mentoring two students besides a full-time job). --- Please comment on this - there may be much more important aspects I've forgotten to mention. GSoC time line: http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/faqs#timeline Regards, Michael -- GIMP http://www.gimp.org | IRC: irc://irc.gimp.org/gimp Plug-ins http://registry.gimp.org | .de: http://gimpforum.de ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSoC 2011 announced
On 01/25/2011 05:52 AM, Alexandre Prokoudine wrote: Google has just announced GSoC2011. Schumaml: Will you be our GSoC master this year too? If so, that would be great. Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
