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.

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

On Tue, Mar 22, 2011 at 10:07 PM, Robert Sasu 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.

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.

Hi,

On Wed, Mar 23, 2011 at 8:32 AM, Alexia Death 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

On Thu, Mar 24, 2011 at 1:06 AM, LightningIsMyName 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.

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

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

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

On Tue, Mar 29, 2011 at 4:11 AM, Mukund Sivaraman 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.

On Tue, Mar 29, 2011 at 1:15 PM, sourav de wrote:

On Tue, Mar 29, 2011 at 4:11 AM, Mukund Sivaraman 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.

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 convolution matrix for image transformation.

6. function-6 : static gint fir_gen_convolve_matrix (gdouble sigma,gdouble **cmatrix_p)

a. first it sets the value of matrix-length by calling fir_calc_convolve_matrix_length function with sigma passed as a variable. b. then it creates the convolution matrix. c. finally it completes the whole convolution matrix by certain calculation, copies it to the cmatrix_p, and returns matrix_length.

7. function-7 : static inline float fir_get_mean_component_1D (gfloat * buf,gint offset,gint delta_offset,gdouble * cmatrix,gint matrix_length)

a. it returns the mean of the 1d array buf created previously,

8. function-8 : static void fir_hor_blur (GeglBuffer *src,const GeglRectangle *src_rect,GeglBuffer *dst,const GeglRectangle *dst_rect, gdouble *cmatrix,gint matrix_length,gint xoff)

a. this function also blurrifies an image horizontally, by creating a buffered array,but it blurrifies with a rectangle of given width and height, and offsets between source and destination array according to the value of xoff and radius.

9. function-9 : static void fir_ver_blur (GeglBuffer *src,const GeglRectangle *src_rect,GeglBuffer *dst,const GeglRectangle *dst_rect, gdouble *cmatrix,gint matrix_length,gint off)

a. this function also blurrifies an image verically, by creating a buffered array,but it blurrifies with a rectangle of given width and height, and offsets between source and destination array according to the value of yoff and radius.

Can anyone please help me with writing code review of a given code, by telling me whether it's a proper way to write code review or not?

On Tue, Mar 29, 2011 at 11:57 PM, sourav de wrote:

On Tue, Mar 29, 2011 at 1:15 PM, sourav de wrote:

On Tue, Mar 29, 2011 at 4:11 AM, Mukund Sivaraman 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.

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 convolution matrix for image transformation.

6. function-6 : static gint fir_gen_convolve_matrix (gdouble sigma,gdouble **cmatrix_p)

a. first it sets the value of matrix-length by calling fir_calc_convolve_matrix_length function with sigma passed as a variable. b. then it creates the convolution matrix. c. finally it completes the whole convolution matrix by certain calculation, copies it to the cmatrix_p, and returns matrix_length.

7. function-7 : static inline float fir_get_mean_component_1D (gfloat * buf,gint offset,gint delta_offset,gdouble * cmatrix,gint matrix_length)

a. it returns the mean of the 1d array buf created previously,

8. function-8 : static void fir_hor_blur (GeglBuffer *src,const GeglRectangle *src_rect,GeglBuffer *dst,const GeglRectangle *dst_rect, gdouble *cmatrix,gint matrix_length,gint xoff)

a. this function also blurrifies an image horizontally, by creating a buffered array,but it blurrifies with a rectangle of given width and height, and offsets between source and destination array according to the value of xoff and radius.

9. function-9 : static void fir_ver_blur (GeglBuffer *src,const GeglRectangle *src_rect,GeglBuffer *dst,const GeglRectangle *dst_rect, gdouble *cmatrix,gint matrix_length,gint off)

a. this function also blurrifies an image verically, by creating a buffered array,but it blurrifies with a rectangle of given width and height, and offsets between source and destination array according to the value of yoff and radius.

Can anyone please help me with writing code review of a given code, by telling me whether it's a proper way to write code review or not?

-- Sourav De
2nd Year Student
Department of Computer Science and Engineering IIT KHARAGPUR

Hi everyone,

here is my code review for some of the plug-ins mentioned in Gsoc-wiki page,

*Cubism plug-in code review*

1. first it creates two structures

a. cvals (of CubismVals ), which includes some tile properties, preview option
b. PLUG_IN_INFO (of GimpPlugInInfo)

2. function 1: static void cubism (GimpDrawable *drawable,GimpPreview *preview)

a. this function first checks whether there is an alpha chanel exits in the image or not.
b. then it goes for the preview option. If it's still not set, then it sets the upper left and lower righthand corners of the bounding box which previews the image operation.
c. then it checks the body color, if it's not already black, it sets it to the original images body color.
d. it then calculates number of tiles and randomizes indices for each tile. e. then it calls gimp_pixel_rgn_init function to initialize the operation. e. after that it calculates the starting point co-odinates, height, width and angel of rotation for each tile and adds them to the desired polygons. f. finally it slightly rotates and translates them.

3. function 2: static void fill_poly_color (Polygon *poly,GimpDrawable *drawable,GimpPreview *preview,guchar *col,guchar *dest)

a. first of all it calculates the distance between two points in a polygon, and define x & y vector between them. b. then by calling polygon_extents it gets the extreme positions of the polygon.
c. from those positions it obtains the size of the polygon, minimum and maximum number of scanlines for it.
d. then it determines the colors suitable for the polygon by comparing with the pixel values of the source image at the polygon's position, and fills the polygon with them.

4. Main function

a. it fetches the image first. b. then it checks for the run mode, if it's interactive then it starts with the default data, else it takes data from user. c. after that it calls the cubism function, proceeds with cubism effects, in the mean time it also keep flushing the display if run mode is non- interactive.

5. static gboolean cubism_dialog (GimpDrawable *drawable) : function

a. it opens up a dialogue box for the cubism and sets it's parameters. b. it keeps on changing, toggling, swapping the display if user does some change in those cubism parameters.
c. lastly it finalizes the event when user hits the OK button or CANCEL button.

*Plasma plug-in code review

*1. first it creates two structures

a. pvals (of PlasmaValues ), which includes some plasma properties like seeds, turbulance, random speed.
b. PLUG_IN_INFO (of GimpPlugInInfo)

2. function 1: static void plasma_seed_changed_callback (GimpDrawable *drawable,gpointer data)

a. this function calls plasma function

3. function 2: static void plasma (GimpDrawable *drawable,gboolean preview_mode)

a. it initializes the plasma operation by calling init_plasma function b. after that it puts seed pixels , one in each corner, and one in the center of each edge, plus one in the center of the image by calling do_plasma function.
c. then it continues to go in further depths as much as possible and keeps up the plasma operation.
d. finally it ceases the procedure by calling end_plasma function

4. function 3: static GimpPixelFetcher* init_plasma (GimpDrawable *drawable,gboolean preview_mode,GRand *gr)

a. it checks for the preview option, alpha channel and initializes the plasma operation.

5. function 4: static gboolean do_plasma (GimpPixelFetcher *pft,gint x1,gint y1,gint x2,gint y2,gint depth,gint scale_depth,GRand *gr)

a. it calculates the medians and for that first it checks the depth. b. if depth=-1, then it generate random colors and put them into the corners and center of the image.
c. else it takes the pixels from the given image and randomly obtain pixel values according to the turbulance,then adds them and obtains average. d. finally it goes for the higher depth by calling itself recursively.

6. Main function

a. it fetches the image first. b. then it checks for the run mode, if it's interactive then it starts with the default data, else it takes data from user. c. after that it calls the plasma function, in the mean time it also keep flushing the display if run mode is non- interactive.

7. static gboolean cubism_dialog (GimpDrawable *drawable) : function

a. it opens up a dialogue box for the plasma and sets it's parameters. b. it keeps on changing, toggling, swapping the display if user does some change in those plasma parameters.
c. lastly it finalizes the event when user hits the OK button or CANCEL button.

*Cartoon plug-in code review

*1. first it creates two structures

a. cvals (of CartoonVals ), with mask radious, threshold and percentage black
b. PLUG_IN_INFO (of GimpPlugInInfo)

2. function 1: static void cartoon (GimpDrawable *drawable,GimpPreview *preview)

a. it checks for the preview option, alpha channel in the given image. b. it also initializes two destination image structure, one for blur radius 1 and another for given mask radius. c. then it calculates the standard deviations from blur radius & mask radious and derives constants from them for calculating the gaussian values. d. then it starts computing pixel values first by vertically then by horizontally.
e. for vertical case, for each vertical strip it initializes the process by dealing with the first and last points of the strip. f. after calculation with the help of those pre calculated gaussians consatnts, it transfers those calculated pixel values to their destination images.
g. similarly it does for the horizontal case. h. then it computes ramp value (for percentage black) by calling the compute_ramp function.
i. then it initializes the procedure for each pixel regions of the image by calculating the relative intensity difference= avg pixel intensity of 1st image(blur radious) / avg pixel intensity of 2nd image(mask radius) j. from this relative difference it calculates the intensity multiplication factor.
if relative diff < Threshold,
intensity mult = (Ramp - MIN (Ramp, (Threshold - relative diff))) / Ramp
else
mult =1.0
k. in the mean time it clamps the value of the lightness of the final image between 0 to 255.
l. then it computes the pixel intensity and finalizes the destination image, but in this case, before writing pixel values to the destination image, it converts the color code first from rgb to hsl, then sets the lightness, and converts it back to rgb.

3. function 2: static gdouble compute_ramp (guchar *dest1,guchar *dest2,gint length,gdouble pct,gint under_threshold)

a. it calculates the ramp value via hysterisis. b. fistly it calculates the difference between the pixel values of the two different destination images and hysterizes it. c. lastly with the obtained hysterized values it compares the percentage black value and determined the relative intensity.

4. function 3: static void find_constants (gdouble n_p[],gdouble n_m[],gdouble d_p[],gdouble d_m[],gdouble bd_p[],gdouble bd_m[],gdouble std_dev)

a. it calculates some constants reqiures for 4th order approximation of the gaussian operator.

5. Main function

a. it fetches the image first. b. then it checks for the run mode, if it's interactive then it starts with the default data, else it takes data from user. c. after that it calls the cartoon function, in the mean time it also keep flushing the display if run mode is non- interactive.

6. static gboolean photocopy_dialog (GimpDrawable *drawable)

a. it opens up a dialogue box for cartoonization and sets it's parameters. b. it keeps on changing, swapping the display if user does some change in those cartoonizing parameters.
c. lastly it finalizes the event when user hits the OK button or CANCEL button.

*Photocopy plug-in code review

*1. first it creates two structures

a. pvals (of PhotocopyVals ), which includes properties of the final image like, sharpness, threshold, % black & % white b. PLUG_IN_INFO (of GimpPlugInInfo)

2. function 1: static void photocopy (GimpDrawable *drawable,GimpPreview *preview)

a. it checks for the preview option, alpha channel in the given image. b. it also initializes two destination image structure, one for blur radius 1 and another for given mask radius. c. then it calculates the standard deviations from blur radius & mask radious and derives constants from them for calculating the gaussian values. d. then it starts computing pixel values first by vertically then by horizontally.
e. for vertical case, for each vertical strip it initializes the process by dealing with the first and last points of the strip. f. after calculation with the help of those pre calculated gaussians consatnts, it transfers those calculated pixel values to their destination images.
g. similarly it does for the horizontal case. h. then it computes ramp values ( ramp down for percentage black & ramp up for percentage white) by calling the compute_ramp function. i. then it initializes the procedure for each pixel regions of the image by calculating the relative intensity difference= avg pixel intensity of 1st image(blur radious) / avg pixel intensity of 2nd image(mask radius) j. from this relative difference it calculates the intensity multiplication factor.
if relative diff < Threshold,
intensity mult = (Ramp_down - MIN (Ramp_down, (Threshold - relative diff))) / Ramp_down
else
mult = MIN (Ramp_up,(diff - Threshold)) / Ramp_up; k. in the mean time it clamps the value of the lightness of the final image between 0 to 255.
l. then it computes the pixel intensity and finalizes the destination image.

3. function 2: static gdouble compute_ramp (guchar *dest1,guchar *dest2,gint length,gdouble pct,gint under_threshold)

a. it calculates the ramp value via hysterisis. b. fistly it calculates the difference between the pixel values of the two different destination images and hysterizes it. c. lastly with the obtained hysterized values it compares the percentage black / white value and determined the relative intensity.

4. function 3: static void find_constants (gdouble n_p[],gdouble n_m[],gdouble d_p[],gdouble d_m[],gdouble bd_p[],gdouble bd_m[],gdouble std_dev)

a. it calculates some constants reqiures for 4th order approximation of the gaussian operator.

5. Main function

a. it fetches the image first. b. then it checks for the run mode, if it's interactive then it starts with the default data, else it takes data from user. c. after that it calls the photocopy function, in the mean time it also keep flushing the display if run mode is non- interactive.

6. static gboolean photocopy_dialog (GimpDrawable *drawable)

a. it opens up a dialogue box for photocopy and sets it's parameters. b. it keeps on changing, swapping the display if user does some change in those photocopy parameters.
c. lastly it finalizes the event when user hits the OK button or CANCEL button.

kindly have a look and let me know if there is any mistake.

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 
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 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 
further depths.
do_plasma: Calculates the mid-point of the rectangle and in case of depht=-1 
(first case) randoms the color values for the corners and the middle of the 
image.
If depth is 0 (in case the rectangle has less then 4 pixels) for every case we 
get the pixel values from the current image, average it and adds a new random 
value for each alpha. 

Else it calls the function recursively for the 4 divided rectangles.

This can also be written using for example a perlin noise function and 
calculating for each component of c sin(f(x,y)*frequency(c)).

Code review and algorithm descrition(GEGL op):


1. Gaussian-blur:
Algorithm: After calculating the Gaussian matrix with the known function for a 
certain radius, we ortonormalize it by dividen each element with the sum of all 
elements. Then apply this to the image and calculating the value of each pixel 
with weighted median.
Using Gaussian linearly separable property we can divide the process into 2 
passes. First a vector is used to blur the image in horizontal or vertical 
direction, then another vector is used to blur the image for the remaining 
direction.
Area Filter base class is used because the color value of every pixel is 
calculated with the help of the surrounding pixels (from the pixels of a certain 
area).

 fir_gen_convolve_matrix calculates the Gaussian matrix for a certain radius, 
and depending on the offset (x or y) fir_ver_blur or fir_hor_blur calculates the 
value of each color byte for each color with weighted median.
iir_young_hor_blur (or ver) calculates the values of each new pixel by 
calculating for each row (column) its new values. The colour vector blur stores 
the calculated color values off the pixels, calculated by weighted media (vector 
b is the weight of a color, buf stores the original color of the pixel).


If there is some problem with code review or anything else please write it and I 
will correct it.

Thanks,
Robert Sasu

On Sat, Apr 2, 2011 at 3:24 AM, Jim Michaels 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

2011/4/7 Robert Sasu :

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

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 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