GIMP GSoC 2011 - Seamless Cloning Project - Technical Overview & Status

Recently, I was asked by email to help with the status of my GSoC (2011!) project. So before I say anything about that, let me explain a few things about my current situation.

For those of you who didn't figure it out already from the lack of activity on this website (and the lack of my activity on the web in general), due to my current real-life situation, I barely have any free time except for those few precious hours in the weekend in which I try to run my own life.

This means that my open-source activity went to a level which is not enough to do anything which requires long sessions (*cough* coding new stuff *cough*), and only translations of open source software are being kept in progress (very slowly, but they are being worked on and I'll commit them when I have enough material).

Now that I said that, and now that you know why I'm rather unresponsive by email/comments to this site, let us begin a technical overview of the project status. Note that this was originally written as an email, so I'll sometimes write as if I'm addressing someone specific in a conversation, and sometimes I talk in general (3rd person). Please ignore this inconsistency...

Technical Overview & Status

Proposal
Unfortunately, I failed to find the original proposal. However, you can find the proposal which I recorded in the GIMP wiki. The proposal is located here.

Papers
I'm listing them here, it will become clearer once you see the modules listing.

• The paper behind the seamless cloning algorithm: Coordinates for Instant Image Cloning
• Unfortunately, due to open source licensing issues and some other reasons, I had to implement myself an algorithm for creating fine triangular meshes.
• The algorithm I used (and implemented!) was the Delaunay Terminator, as described by Jonathan Richard Shewchuk in his paper Delaunay Refinement Algorithms for Triangular Mesh Generation.
• Some of the code was based on an existing library (poly2tri) which is in turn based on it's own papers

Modules
The project is divided into 3 main modules

• A library for creating fine triangular meshes - poly2tri-c
• The first part of this library is a C port of a library for creating Constrained Delaunay Triangulations, which are basically "nice" triangulations of existing outlines with/without holes.
  The original library is poly2tri, and the C port I wrote can be found in poly2tri-c's repository under the poly2tri-c/p2t folder
• The second part of this library is an implementation of the Delaunay Terminator algorithm for what we call a Delaunay Refinement.
• Delaunay Triangulations are triangulations which are considered "nice", meaning that most triangles are more or less of equal size, without too big or too small angles.
• Delaunay refinement is the process of taking a Constrained Delaunay Triangulation (which is not exactly Delaunay due to constraints such as outline that must be respected) and refining it by inserting more and more points. The process terminates when the resulting triangulation is almost Delaunay.
• The implementation of the algorithm above was made from scratch and in fact was the biggest part of the GSoC project (the assumption was that there was an existing open source library to do this. Apparently it wasn't so...)
• My implementation can be found in poly2tri-c's repository under the poly2tri-c/refine folder
• The third and final part of this library is an implementation of a triangular mesh render. The render basically takes a mesh created from the refinement process, a buffer to fill and a vertex-to-color function, and creates an image of the mesh in the specified resolution and size.
• This is another implementation from zero, although quite trivial and could probably be made more efficient
• The original article used OpenGL to do this rendering, resulting an ultra-fast renderer. Since the project was done when GIMP/GEGL were in an unclear state regarding usage of graphics hardware acceleration, it was done on the CPU purely which is much slower (yet still almost interactive - less than a second for rendering regular objects)
• My implementation can be found in poly2tri-c's repository under the poly2tri-c/render folder

• The second part of the project is a GEGL operation for doing the actual seamless-cloning operation.
• In brief, here is a description of the process (needed to understand the state of the code):
• Do a heavy preprocessing step for creating a fine triangular mesh from the outline of the pasted area
• Now, for each render attempt, compute the color differences between the edges of the paste and the background image, and use the previously created mesh to interpolate the differences in the colors along the entire area of the pasted image. Add the interpolated color differences on-top of the paste and you get a seamless pasting!
• The GEGL implementation of the operation can be found under gegl/operations/common/seamless-clone (in the soc-2011-seamless-clone branch):
• Files beginning with sc-* are part of a "shared library" with the code required to do seamless cloning
• This library is used using the GeglScContext object (sc-context.h) which manages a seamless cloning operation for a specified buffer to use as a paste.
• GeglScContext implements smart logic to notice when a paste doesn't change between rendering sessions (i.e. calls to the process function) in order to avoid re-doing the heavy preprocessing step
• Ideally, GIMP would use this "seamless cloning library" to implement seamless cloning with an internal op that does not need to do this check over and over, since the paste can't change when moving it on the canvas in the GIMP UI. However, currently gimp uses the GEGL op which is described below in a rather dumb way...
• This library even exposes a pkg-config file to be easily linked against later...
• seamless-clone.c implements gegl:seamless-clone - A simple seamless cloning operation using the above library.
• seamless-clone-compose.c implements gegl:seamless-clone-compose - A simple meta-op for GEGL that composes the seamless paste above a given background...
• Finally, in order to have the triangulation algorithm included, a copy of poly2tri-c is included under the libs directory of GEGL. This is since poly2tri-c has no package that can be installed and it was asked for so that developers won't need to download additional source code from more locations. This is not a desired situation, yet I'm unaware of any package owners for various Linux distributions which would be willing to help with distributing poly2tri-c as it's own package. If any such developer would be found, send them to me and I'll give them any access/help to the repositories (and I'll do any code modifications needed)

• A GIMP tool using the seamless cloning GEGL op
• The tool is a bit buggy in terms of refreshing the canvas (sometimes, artifacts are left when dragging the paste)
• Additionally, it is inefficient since it doesn't use the library directly and so it does the check of whether the paste buffer changes each time
• I'm not sure whether the errors regarding non-continuous pastes (with holes and/or composed of several unconnected parts) do find themselves into the GIMP UI in a proper way...

GIMP/GEGL TODO

• Make GIMP check for the presence of the seamless cloning operation on the startup of the tool
• Make GIMP use the library directly (and check for it's presence on compilation time)
• Conditional OpenGL for doing the rendering of the triangular mesh!
• Implementing the OpenGL rendering in poly2tri-c should be very easy for anyone knowing OpenGL. I'll do it if GIMP/GEGL accepts OpenGL (not OpenCL! That's different!) into the pipeline
• Fix the described bugs in the GIMP tool UI

Poly2tri-C TODO

• Code cleanup, prepare for distribution (I'll do that - it requires less coding then the GIMP stuff and does not require a long coding session - so I can do it on my short available time periods)

Trying all my GSoC projects (seamless clone, triangulation)

It's about time I post this. My work is actually useable enough (I even received my first bug report by email recently) so it's the time to explain how to use this.

In this post I will explain you how to compile Poly2tri-C (the triangulation and mesh generation library), how to compile GEGL with the seamless cloning operation and GIMP with the seamless clone tool.

Ready? Then let us begin!

Very big steps towards finishing post GSoC (2011) work

It works!

An outline and it's refinement

If you have been tracking my blog, you saw that I was struggling in the last few weeks to implement a constrained delaunay refinement algorithm. It took ages, as I always encountered lack of available materials and/or programming bugs. But I'm here to say that it works now!
This implementation is in C# (easier to prototype algorithms than in C), and I will convert it to C later for usage with GIMP and the rest of the project. It's based on a paper by Jonathan Shewchuk: Delaunay Refinement Algorithms for Triangular Mesh Generation.

Now, what about the GEGL side of the project?
As you may have all heard, GIMP is progressing onwards to use GEGL as it's image processing core. My seamless clone tool is not different - it was written as a GEGL operation (meaning you can use it outside of GIMP, in your own programs!). The GEGL operation has received lots of work this week, including:

• Working in tiles instead of whole at once (reduces memory usage and makes it scalable for images as large as supported by GEGL)
• Bug Fixing and Compiler calming (making the warnings disappear)
• Removing code duplication

The op is pretty much done now! I will need to use the new triangulation algorithm (as mentioned above), but it should be transparent to the rest of the code.

Now, what about the GIMP side of the project?
Other than a bit nicer looking GUI for tuning some settings, it's already done since the summer.

Remaining TODO:

• Make the GEGL operation handle blank images to paste and images with very thin (1 pixel wide) areas. Also make it handle holes (I would probably warn about these and refuse to paste).
• Port the triangulation algorithm to C
• Also finally make it a standalone package...
• Improve a bit the GIMP user interface for the tool
• Bonuses:
• Implement an OpenGL and/or a OpenCL (I'm unfamiliar with openCL, and this op is actually very easy with OpenGL) version of the seamless clone operations, to speed things up even more.
• Code optimizations....

That's it for now. I'm off to bed...

More progress on poly2tri, Solutions to Linguistic Problems

Time for another update on the GSoC project:

My C port of Poly2Tri (part of my Google summer of code project, see my previous post(s)) has received much work in the last weekend and things start to look pretty good.

One of the problems I had was an incorrect understanding of what is an encroached edge. As someone who don't speak English natively, in university I heard many different (non-English) terms to describe edges and vertices in graph, since it's not really formalized what terms should be used in my language.

When I first came to read about Delaunay Refinement for generating a triangular mesh from an outline, I was sure that the following terms (marked in bold) are used freely without some rules (meaning you can use each one of them to express the same common meaning as the others):

• Edge - Used to describe a connection between two points(/vertices/nodes) in a Mathematical Graph and also used to describe one of the three lines which from a triangle. This term is used in triangles simple because triangular meshes are indeed a form of a graph.
• Segment - Used to describe a straight line between two points of a PSLG.
• Sub-Segment - The result of splitting a Segment into smaller parts (this happens during the refinement of the mesh produced from the outlines described by the PSLG).
  

This confusion is  partially because I haven't deeply understood the concept of Constrained Delaunay Triangulation. Basically, the source of confusion was lingual, due to conflicting terms in my native language (Hebrew) - there are several words used to describe these terms, and the people who use them aren't always exactly consistent in their usage. Anyway, I believe I got it more or less right now - I read all the material in English from scratch, and now I understand the differences between all the three terms above.

And a small teaser - I needed to test if I can detect which points are "visible" from a triangle (to test whether an edge is encroached). To do so I wrote a small and quick algorithm, and here is the demo app I wrote to test it:

Another good announcement is that I have been receiving help from my partner in lots of my university coding assignments, and he has worked on the part which is relevant for the GIMP/GEGL side of the project - a better outline finding algorithm. The current algorithm would crash/freeze on selections with thin areas and randomly in some other cases.

His algorithm finds outlines for every BW image, and it builds an hierarchy of them (so that outlines which actually represent black holes inside of white areas would be associated with the white outline as child outlines). His algorithm also returns points with locations which have sub-pixel accuracy, to prevent the problem that the current algorithm has with thin areas (thin lines would cause a pixel to be marked twice as an edge pixel - one time for each direction that we go around it. This would crash some parts of the library).

I still haven't integrated it or looked at the code, but he showed me the outcomes and they look pretty awesome. You'll hear more on that as soon as I get to work on it.

That's all for now. Stay tuned for more ;)

Post-GSoC work, End(?) of University

I have done the seamless cloning project for GIMP and finished it in August. So, you may ask, why on earth is it not integrated yet? The answer is short and simple - last university semester combined with real life. But, I'm not here to bring excuses, I'm here to bring results:

• On Thursday I had my last university exam (Computational Complexity). Unless I fail, and I hope I don't, I finished university!
• In the last two weeks of university, I had more and more free time so I began working again on my GSoC project. The current things that are waiting to happen are:
• Fix the triangulation refinement implementation. For those who are not familiar with the algorithm behind the scene, the algorithm itself is based on interpolation of image differences in a triangular mesh. Therfor, it is a critical part.
  The algorithm currently would get stuck in an infinite loop of refining the triangulation, even though it was gauranteed to stop (meaning an implementation bug). I think I just fixed it now (now as in 5 minutes ago), more on this below.
• Make the algorithm iterate over tiles inside of allocating a big chunk of memory, and thus limiting the maximal image size for the algorithm.
• Fix memory leaks (there are several known leaks, and hopefully none unknown).
• Improve a small glitch on the borders of the image.
• Optimize the speed!
• Get it reviewed, and merge back to master.
• Being free of university, and free from other work (I have a day work on which I don't work "after-hours"), I'm now free from chores on evenings (if I get home at sane hours) and weekends. For the first time in the last 3.5 years, I really have free time with nothing on my mind. So don't worry, I'll get into GIMP :D

Now, before I get into details on my GSoC bug, a short "what's going on?".

• Last time I left the geometry library, I was completly stuck with no idea what was the bug.
• When I got to it again, I decided to re-write it in a language which is more type-safe (no pointer bugs), with less memory issues (garbage collection), and much easier to debug (no offense, but gdb isn't always ideal). Eventually I chose C# (and not Java, my favorite language) in order to learn a bit.
• I have been spending my free time between the exams, in the last two weekends, to re-write the library. The re-write was something like "look at the code and write it in a different language". Almost no structural changes or anything, so that I'll keep synced with the source.
• And then I found the bug...

Now for the bug, which made me like C much less than I did before:

// Relevant type declarations:
typedef enum
{
  INCIRCLE_ON,
  INCIRCLE_INSIDE,
  INCIRCLE_OUTSIDE
} P2tRInCircle;

// Types from GLib
typedef int  gint;
typedef gint gboolean;

// The function I called
P2tRInCircle p2tr_math_incircle (P2tRPoint* a,
                                 P2tRPoint* b,
                                 P2tRPoint* c,
                                 P2tRPoint* d);

// Somewhere in the code, in the function that I knew that
// was deeply related to the problem:
gboolean inside = p2tr_math_incircle (p, a, q, b);

if (inside)
  {
    ...
  }

I don't even feel like explaining this. It is so trivial (and if not, go learn C!) Other than feeling stupid silly for falling on such a bug for days of debugging, I don't have anything else I can say... So, with all the dislike of some people to high level languages, I like type safety. It saved my here simply since this code, when converted directly to C#, didn't compile and produce an error instead!

So, Hurray for C#, Hurray for end of University (hopefully) at least untill second degree, and just some other random hapiness. And don't worry, I'm not gone yet :)

Edit: More silly bugs found. I'm starting to like re-writing stuff - way better than debugging...
Edit 2 (February 11th, 2012): The geometry library works, at least in C#. Now it's time to re-implement in C.

Video demo of my GSoC project

[If you are reading this from RSS, you may not be able to see the video. Click here to see it]

[GSoC-2011] Final Results and How to Try

I am very glad to announce that I now officially passed the Google-Summer-of-Code 2011 :) The email from Google arrived in the last few days, and the official Google announcements on the GSoC results (of all projects) are supposed to be published tomorrow.

S/He is eyeing you :)
Sources: background, paste

Now, it’s time to publish the instructions on how to get and try it for the people who want to test it. There are some known bugs, and probably some unknown bugs, so be warned.

Compilation and Set-Up Instructions

1. You should know how to build of GIMP and GEGL from Git. A partially outdated guide is available here, and some things are explained in more depth here.
2. Instead of building the GEGL master (main) branch, switch to the soc-2011-seamless-clone branch. You can do this by running git checkout soc-2011-seamless-clone. Compile it with the regular flags – nothing special is needed.
3. After building the updated version of GEGL, it’s time to build the updated version of GIMP. Switch to the soc-2011-seamless-clone2 branch, and build it.
4. Before running GIMP, you must set the environment variable p2t_refine_steps to some number defining the maximal amount of points to be used in the mesh (in plain English, more should theoretically produce better result). I know this is annoying, I will get rid of it as soon as I finish debugging a certain code part. The typical number I use is 500 for pastes of around 200x200 pixels, and you should probably increase it if you wish to work on large pastes. If you are using the bash terminal, do export p2t_refine_steps=500 (and change the number as you wish)
5. Run GIMP.

Usage Instructions

Basically, you can just try copying a part, selecting the Seamless Clone tool (Shift+L) and clicking anywhere on the image to start the tool’s interaction. Click Enter to apply the final result. If this doesn’t work (and/or crash), then the instructions below are for you.

1. Run Gimp :)
2. Open the image that you wish to use as the background, and open the image you wish to paste into the background. Copy the part you want to paste. Note that opacity of that part will be treated as if it was binary – parts under 50% opacity will be removed, parts of more than 50% opacity will be completely opaque. The shape can be any shape, as long as it follows the following rules:
1. It must not have holes (Temporary limitation)
2. It must be continuous, i.e. composed of only one part (Temporary(?) limitation)
3. It must not have any long thin areas (Temporary(!) limitation).
   This means that if you have any area which is 1 pixel wide and is 3 pixels long or more (i.e. a thin spike), it will crash. Solution for this was already devised, I just need to code it. Select the Seamless-Clone Tool (Either by clicking the second tool on the toolbox that has the same icon as the move tool, or by doing Shift+L).
3. Click anywhere on the canvas while the background layer is active. The paste will be centered on the cursor, and so the cursor should be in a place where the entire paste is inside the background boundaries (both inside the rectangle defining the layer, and inside an area where all the background below it is opaque). This limitation will be enforced by the User Interface later.
4. Move the paste by clicking on it, dragging and releasing. If you move it slow enough (which actually shouldn’t be so slow), you’ll see the preview updating while you are moving.
5. Click Enter to Apply the effect.

Known Bugs

• All the above mentioned crashes and bugs :)
• Due to not yet complete memory management, the tool leaks memory from it’s preprocessing.
• Converting to tile-based processing is NOT 100% done, so it may crash on large pastes. Don’t ask me how large since I didn’t try anything more than 300x300 on my machine.

Other TODO’s

• Integrate the tool with the help system
• Test better the interaction when the the active image/display/drawable are switched during the interaction of the tool.
• Get a decent tool icon. Anyone with ideas for the visual metaphor to be used by a seamless paste tool, is more than welcome to leave them here as comments! I do design icons, but I don’t have an idea for this one.

GSoC 2011 - (Almost) Final results and thanks!

The end of Google Summer of Code 2011 is near, and I have failed to post enough updates on my blog. But that does not mean one bit that I failed to make progress. I'm proud to present you with my results:


Result, using my GIMP tool :D

The image to paste (source)

The image to paste into (source)
Licensed under Creative Commons Attribution-Share Alike 3.0 Unported

My tool allows you to move the paste on the image and see it update according to it's environment, so that it will paste seamlessly. It's not real-time yet, since I recompute some values that should be cached everytime, but most work to enable caching is done, and I hope to reach that before the final deadline. (Even if it won't be before the deadline, I will do it even after GSoC ends).

This is also the time to thanks all the people who made this possible:

• The authors of the Coordinates for Seamless Cloning article, who developed this algorithm.
• Prof. Daniel Cohen-Or, the professor who taught me computer graphics at the university, and helped me understanding the article (he is also one of the article authors).
• My GSoC mentor, Michael Natterer (aka mitch), who agreed to mentor me and assisted me when I was stuck.
• Mason Green, the original author of the poly2tri library, which was heavily used in the project for computing interpolation meshes. I would have never reached the project deadline without his amazing library.
• Prof. Jonathan Richard Shewchuk, who developed some of the geometrical algorithms that were used in this project.
• Finally, special thanks to all the great guys on the GIMP and GEGL irc who helped a lot - mitch, Bat`O, pippin, Alexia_Death, Mikachu, and more.

[GSoC-2011] Bi-Weekly update #1

Hi!

After seeing enough student post of weekly updates, I decided that I should probably also give some progress report. I finished porting the poly2tri library to C! My C port can be found here.

Just compiled it today with gcc and not g++, and it feels great to see it working. And when I say to see, I mean that I created an SVG output tester so that you can see it in any modern browser :D
I still have some optimizations that can be done, including maybe some more documentation of the C api (especially for the constructor-destructor conversion from C++ to C), but it's usable enough for the GSoC as it is. Note that most API changes were simply from p2t::SomeClass::GetFoo to p2t_someclass_get_foo (where the object itself was added as a first parameter of the functions).
It was in "almost C" state on wednesday, but then memory leaks happened (solved with valgrind) and some stupid compilation errors...

At the weekend I went to a short vacation on the dead-sea (pictures soon!) and I had 4 people to discuss Chew's second algorithm (which I should implement next) with during the long ride to the hotel. So hopefully with their help it should be quick(er).

That's all for today :)

The end is near, and so is the beginning

Pictures from Yehuda Poliker's Concert on the
Student-Day, and a picture of my GSoC kit. Cellphone
pictures, so low quality :P

There is a feeling of an end in the air. The end of university, another chapter in my life. Yesterday I took part in the Student Day party at our university - there were amazing concerts by fantastic artists, including Yehuda Poliker, Monica Sex, Hadag Nachash and more. The Student Day is a known symbol of the end of the year, which happens 2-3 weeks before the end of the semester. The fact that is practically my last year as a student (I will have one last course left for the next semester, but that doesn't really count) does start to get in, and I am gradually getting used to this.

This week was also the official beginning of the Google Summer of Code coding period! After getting my cool GSoC kit (see the picture) 2 days ago I really felt that I'm a part of this great project - many thanks to google for organizing this! Anyway, I almost finished porting poly2tri to C. Once this is done, I can start coding my project. The milestones for my project are:

1. Port poly2tri to C (from C++), a library for generating Constrained Delaunay triangulations for given polygons.
2. Implement Chew's Second Algorithm to create adaptive meshes from CDT's*
3. Implement code to create polygons from Black/White (1-bit) channels (The edges where the color differs should be described by polygons)*
4. Combine all these to create an adaptive mesh from a Black/White channel (which symbolizes a selection area)
5. Create a triangle mesh renderer with color interpolation between vertices (actually, Cairo may be able to do this!)*
6. Implement the Mean-Value-Coordinate cloning, using these above, as a GEGL operation*
7. Add some GUI and put it as a GIMP tool

Marked with * are the steps that would require the actual work, most other steps should hopefully be trivial. But again, hopes and reallity don't necessarily agree :) When I applied for this GSoC I knew there was code to do adaptive mesh generation from polygon outlines. It's only too bad that none of the code to do this is small and in a GPL compatiable license :(

I hope to finish everything untill step 4 (and parts of 5 if I'll be able to use Cairo) untill the midterm, but I can't really set the midterm goals yet since I haven't started to seriously code yet because there is still a university semester going on for the next week or two.

To all students out there, good luck in the exam period! And for the GSoC students, good luck with the projects! :D

I’m doing a Google Summer of Code!

My application for a Google Summer of Code project for GIMP was accepted! =D
After being around the development team for a year or so (and hanging around the IRC even more), and after I couldn’t apply last year for technical reasons, this year I will get my chance.

Here is the initial description of the project, taken from my project page:

The project I intend to implement is something called Adaptive Cloning (aka Seamless cloning). Basically, the idea is that cloning parts from one image to another usually does not end well. This is because of different exposure/white-balance settings, or simply because of different lighting conditions.

The idea is to implement an algorithm which would allow to copy a part from one image, and paste it seamlessly into the other; the pasted area will be blended to fit the destination image locally. There are several techniques to do that, and the most known one is called poisson image cloning. The problem with most of these algorithms is that they are expensive (computation-wise) and are not suitable for interactive editing and previewing, unless you use hardware acceleration.

The suggested technique for my project is based on an article from Siggraph 2009 (includes demos and videos), which shows realtime performance (both on the GPU and the CPU*). The user would paste a some area from the clipboard and will then be able to "blend it in" according to it's environment.

I'm open for any suggestions regarding usability, ui integration, or anything which relates to the project. Feedback will be more than welcome!

* Note that I'm not sure for which sizes on the CPU it preforms on realtime, but it's still much more cheap computation-wise than most other techniques and a small lag of few seconds is something which should be acceptable for this sort of workflow.

GIMP has 5 projects for this GSoC – if all these projects succeed, GIMP will gain a major boost in it’s capabilities. This year’s projects are:

• Adaptive Cloning (aka Seamless cloning)
  • Student: Barak Itkin (IRC nick: LightningIsMyName)
  • Mentor: Michael Natterer (IRC nick: mitch)
• Replace GimpSizeEntry widget
  • Student: Enrico Schröder (IRC nick: enrico(?))
  • Mentor: Martin Nordholts (IRC nick: Enselic)
• iWarp like tool for Gimp
  • Student: Michael Muré (IRC nick: Bat`O) – the same guy who did the GSoC of the cage tool last year!
  • Mentor: Alexia Death (IRC nick: Alexia_Death)
• Porting GIMP plugins to GEGL operations
  • Student: Robert Sasu (IRC nick: robert)
  • Mentor: Mukund Sivaraman (IRC nick: muks)
• OpenCL in GEGL
  • Student: Victor Oliveira (IRC nick: victorm)
  • Mentor: João S. O. Bueno (IRC nick: gwidion)

I would also like to congratulate Blender (formally, The Blender Foundation) for an astonishing amount of 17 GSoC projects! If there is any project who can do anything with 17 students, it’s Blender. Congrats also for Inkscape for 4 GSoC projects.

Good luck to my fellow GSoC students, especially the GIMP (and Blender) students. I hope I will finish my project – I already learned from Bat`O last year that it is feasible to code something like this ;)

The list of all accepted projects for all organizations for this year’s GSoC can be found here.

Small Help Wanted

I searched without success for a small GPL compatible library for generating quality triangular meshes (example) from a given outline (probably a quality constrained Delaunay triangulations / conforming Delaunay triangulation) - I need this for my project. I haven’t found any library that is both small and GPL compatible. If anyone knows any such library, please tell me - it will save me lots of work and guarantee less bugs in the final result.

Edit: It seems as if poly2tri may do the job of creating a CDT (Constrained Delaunay Triangulation), and on that I can apply Chew's second algorithm. This is not optimal, but it is feasible since creating the CDT was probably the hard pard. If anyone finds something better, I will still be glad to knkow!

GIMP was accepted to GSoC 2011

GIMP was accepted to Google Summer of Code 2011!

Congrats also for Inkscape, Blender, Scribus for making it to GSoC 2011! For the full list of projects, see GSoC 2011 participating projects.