Hi there!

We have some ideas for Google Summer of Code project in the wiki, but all of tehna re dangling since last year.

Mos t of tehm look good, but some may have been obsoleted in the current devel cycle, or would involve changes in code that is going away in the cycle.

I am posting the full set of ideas bellow and asking for commetns on ideas, new ideas, and overall, people who would be willing to mentor a stundet through some of them.

regards, js
->. A good introduction to the current state of GEGL is the [WWW] presentation given at FOSDEM this year. Possible topics for projects includes: Prototype GEGL backend (with own set of operations) that uses a GPU instead of the CPU for rendering.
Networked buffers (and maybe distributed rendering). Create a paint core and related plug-ins. A paint-core is the system used for drawing tools like paintbrush, airbrush, pencil, clone and other paint tools. The core should be made in a way that facilitates integration with a procedural brush system. Frequency domain processing.
Any [WWW] known bug or a number of bugs fixed SVG brushes
VBR brushes in GIMP - basic shapes like ellipses, rectangles and rhombuses; with additional spikes - are scalable. In SVN trunk, all brushes including the pixmap-based ones can at least be scaled down. We do not yet have means for more advanced brushes (think about a brush consisting of two disjoint circles) that can be scaled up in a lossless way.
Using SVG files as brushes could help to solve this. Benchmarking
In many cases, image manipulation is compute-intensive - many operations are loops which go over all pixels of an image. Sometimes, there are more efficient algorithms for a particular method. But does it have other drawback? Or is the time spent at an entirely different place, e.g. code that does check something on every loop while it would be sufficient to only do it once? Can it be changed safely? Enhancing Painting with parameter curves Currently there are quite a few options to use with the paint tools, however, mapping how these options could vary with pressure, tilt, speed, angle of painting is somewhat limited. A complete tabbed dock, where new curves could be added that would map one input variable to paint option could increase several fold the options available to artists. A request for this is drafted in [WWW] | bug #119240. Categories for brushes, fonts, gradients and palettes If one adds too many fonts or brushes to GIMP, they quickly become un-manageable through the existing UI. Implementing a way of organizing these resources in sub-categories, in a way that one resource could be present in more than one category (like thrugh the use of tags) in a nice UI could overcome these limitations; Font Selector Widget
We need something better. Something that is reusable. Something to turn choosing fonts into a pleasure, rather than a pain. Something to leave the competition on the dust.
Your own proposal
Feel free to come up with other possible projects - the [WWW] enhancement proposals in Bugzilla may contain some additional viable project ideas.

Hi -

here are the ideas listed again. I had trimmed down the previous list, as there are things that simply do not sound attractive enough for anyone to pick.

Ideas for Gimp-python and the UF-Raw plug-in have been added. And we are still lacking mentors for pretty much everything else. :-)

Also, there is still a little time for adding some more ideas, or try to focus some more.

Regards,
js
-> M-x feature).

== Your own proposal ==

Feel free to come up with other possible projects - the [http://bugzilla.gnome.org/buglist.cgi?product=GIMP&bug_status=NEW&bug_status=REOPENED&bug_status=ASSIGNED&bug_status=UNCONFIRMED&bug_severity=enhancement enhancement proposals] in Bugzilla may contain some additional viable project ideas.