GSoC GEGL Application
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
GSoC GEGL Application | hansshulo@gmail.com | 08 Apr 08:25 |
GSoC GEGL Application | Hans Lo | 14 Apr 17:25 |
GSoC GEGL Application
Hi, I am applying for the GSoC GEGL operation porting task for GIMP. I am a MS Computer Science student at the University of Massachusetts: Boston. I have experimented with gegl a little bit and have some experience in C. Here is the required information, including a ripple operation that I was experimenting with a few months ago that I cleaned up to submit.
Cubism:
Algorithm Analysis
-Split image up into even tiles
-fill up image with background color
-process each tiles in random order so that the tiles overlap randomly
-shift tile a random amount depending on tile size
-resize width and height of tile by random amounts with constraints
depending on tile size and tile saturation
-rotate tile a random amount
-fill polygon with a color taken by sampling the color of a corner pixel and
then blending so that the rectangle gets progressively lighter from one edge
to the opposite edge.
Code review
There are some calculations that are done many times when once is enough. For example, for each tile, the value cvals.tilesize/2.0 is used both for the x and y positions, but is calculated each time. This makes an additional calculation per tile. In the same loop there is also cvals.tilesize/4.0 and width/2.0 and many others. It would be ore efficient to save these calculation in temporary values in each iteration of the loop.
Fractral Trace:
-Scale down image so that it is workable within the bounds of Mandelbrot
set.
-For each pixel, use the Mandelbrot set definition to determine a pixel to
map from after the user defined number of iterations. This is the pixel that
is confirmed to be in the Mandelbrot set after this many iterations.
-For each pixel, scale the mapping back up so that the image can be drawn,
and then draw the pixel.
Code review
There is a reliance on global values that is somewhat dangerous. In particular the array dpixels, which is written to and then copied to the main pixel region. A better way might be to pass in pointers to the pixel region or the buffer to modify within the functions, which would make debugging easier.
Plasma:
-put random colors into 9 pixels in the area to be drawn on: the corners, the midpoints between the corners, and the pixel in the center. -recursively split the image into four quadrants. For each quadrant, determine the colors of pixels at the midpoints between the corners but averaging the color of the two corner pixels and then adding a random shift in the rgb values that depends on the turbulence parameter. The color for the point in the middle of all four corners is determined by averaging the colors of all four corners (plus the random color shift). For each upper level of recursion, the corner colors will have been determined by the recursive call lower on the recursion tree. At the lowest recursive call, when the quadrant is 2x2 pixels large or less, we are done because the corners are known and there cannot be any midpoints.
Code Review
Plasma does an iteration to determine the colors of evenly spaced pixels across the drawing region. It does recursive calls at each iteration to get to the first pixels that have not been colored yet. These previous recursive calls are probably not needed as they go through work thats already been complete. A better way might be to do everything iteratively and use the depth value to determine which pixels need to be calculated next through an iterative call. This way stack overflow can still be avoided but there is no need to go through many recursive calls at each step.
Gaussian Blur:
-Blur horizontally and then vertically depending on the x and y standard
deviation parameters. How it blurs depends on if it is iir or fir.
-In iir, each pixel's new value is calculated as the weighted average of
three pixels in front and behind it on the row depending on if it is
blurring horizontally or vertically. The weights are calculated using the
standard deviation parameter and values that approximate the relevant values
on a normal curve.
-The fir algorithm is similar but instead of using estimated values,
generates a convolution matrix that stores the weights. The weights in the
matrix are calculated using the Gaussian function so that the higher values
are in the center of the matrix. For each pixel in the row, the matrix is
then iterated through to calculate a weighted average of pixels around it.
Code Review
There are many arbitrary constants in the code. For example the weights in iir are calculated by doing arithmetic on the standard deviation with seemingly arbitrary values. My guess is that these values are used to approximate a normal curve at a few points, but it be better to use named constants or at least document the code so that what these values do are explicit.
---
Thank you for your time,
Hans Lo
GSoC GEGL Application
4pm UTC on Friday is fine for me.
- Hans
On Thu, 2011-04-14 at 19:46 +0530, Mukund Sivaraman wrote:
Hi Hans
Let's have a talk on IRC in #gimp - you, Robert Sasu and me, at around 1600 UTC tomorrow. Tell us if this time is good for you.
Mukund