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
[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
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 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
[Gimp-developer] GSoC 2011 Porting GIMP plugins to GEGL operations
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 have begun to use GIMP some years ago for image editing in ubuntu os (as a substitute of photoshop ), but I’m currently using it for my project on algorithmic art, so this would be a huge opportunity to be able to participate in GSoC. So for the algorithm to implement this plugin, i thought that we need to do this in a step by step manner, like first blur the image to remove noise from it, then improve the clearness of the outline with some threshold, detect the main outlines and then finally fill the regions inside those main borders by picking up an suitable color by comparing it with the original image. As per as the current cartoonization plugin of the Gimp is concerned,the mask radius option can be used to determine the degree of the blurriness, and the percentage black option as to choose the value of upper and lower threshold. Besides there should be options like choosing the scale of the transformation user want to use to cartoonize an image, etc. -- 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 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 - 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
[Gimp-developer] GsoC - 2011 - Porting GIMP plugins to GEGL operations
Hello, 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 was also recommended to look at Porting GIMP plugins to GEGL. As I wrote in my last e-mail I have strong C/C++ and algorithms background and I have done some image processing/filtering projects. I've also compiled GIMP from GIT with all the libraries and dependencies. I also looked over the coding style and started to familiarize with the code in GEGL and GIMP. I propose simply to rewrite GIMP plugins in gegl operations as there are many predefined functions, and the implementation is not so hard. How important do you find this project, compared with others for this years GSoC? I would like to know which are the plugins I should start to look at and port to GEGL. I would also ask for some specific information about this project. How did you imagine the porting: by rewriting the entire code for every plugins doing some adaptation to the logic? Thank you, Robert Sasu ___ 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
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 ? And again: how important do you find this project compared to others for this years GSoC? Thank you, 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
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
