Re: [Gimp-developer] Feature request, - liquid resize
On 8/22/07, Thomas Lytje <[EMAIL PROTECTED]> wrote: > I am not sure you take feature requests like this, - but try to take a look. > It seems quite cool. > I don't know enough about image processing (but I am a software engineer) > but to me it looks like it wouldn't be to hard to implement. Hopefully there > isn't a lot of patens making it impossible Looks like a resizer in which the amount of source pixels per output pixel varies spatially, rather than being roughly constant. It seems to have a few requirements: a) Resizing can only be done on one axis at once b) two scalers would be needed, one iterating over X axis, one over Y. Basically the only change relative to normal accumulators is that the number of pixels resulting in a final pixel would need to be inversely weighted by the significance mask (that is, read more input pixels to produce an output pixel in insignificant areas.) There is also one coefficient involved that would need some experimentation with to get right: the exact ratio of scaling between completely significant pixels and completely insignificant pixels. (I mean, when you shrink that image, the significant features must also shrink somewhat -- at least once they begin to push up against each other.) Anyway, if you give a link to a paper describing the exact workings of the algorithym, then it's much more likely that something will get done in relation to it. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature request, - liquid resize
David Gowers ([EMAIL PROTECTED]) wrote: > Anyway, if you give a link to a paper describing the exact workings of > the algorithym, then it's much more likely that something will get > done in relation to it. It seems to be fairly straightforward and the results are beautiful. The related paper is available at http://www.faculty.idc.ac.il/arik/imret.pdf - but since this page is pretty slow try these URLs: http://www.faculty.idc.ac.il.nyud.net/arik/imret.pdf http://www.faculty.idc.ac.il.nyud.net:8080/arik/imret.pdf Would be cool if someone would tackle this. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] View resampling quality and performance
The code used for showing the image has been changed quite a bit recently. The first modification was that addition of a mipmap pyramid implemented on the tile level that acts as a foundation for more efficient redraws that no longer needs to traverse all the data of the image at full resolution to redisplay it when zoomed out. In 2.4rc1 yielding a performance increase (assuming that the code does indeed cache results between levels correctly.) For 2.4rc1 I added code that did something close to bilinear interpolation from the next larger mipmap level, this yielded even better results at a slight performance penalty. (There might also be a crasher bug introduced for some image size/display size combinations, not fully sure about this though). In current SVN I've committed code that implements a box-filter that uses a 3x3 neighborhood instead of the 2x2 neighborhood that the bilinear filter used, there still are room for some improvements both to the code readability as well as the performance of the re sampling. For many common resolutions these changes should have no impact on the speed compared to the plain pyramid (100%, 50%, 25%, since nearest neighbour re sampling is used directly on the correct pyramid level). It is possible with this implementation to enable anti aliasing between the rectangles representing pixels at zoom levels > 100% using this code, I am not sure if this is desired or not, I have thus left it without anti aliasing in these cases. If others want to help clean up as well as optimize the code, the places to look are in app/display/gimpdisplayshell-render.c The innermost function is compute_sample() , this function should be modified to be as fast as possible since it is the piece of code called most of the time. The shifting being done is done to avoid some integer overflowing issues; it would be nice if these issues could be resolved, there are also some other comments about possible optimizations/reorganization of the code possible here in comments within the function. render_image_tile_fault() this function is a generic function implementing the 3x3 neighbourhood traversal needed for the box filter, this code should probably focus on readability instead of performance since it will most of the time be handing off the actual work to either render_image_tile_fault_nearest or render_image_tile_fault_one_row, render_image_tile_fault_one_row() is the image iteration and tile traversal code that is called for the most common case (all pixels needed can be fetched from a single row of tiles.) Reducing the overhead (number of tiles kept in memory, etc.) for this function will result in a faster display. A general optimization that hasn't been done yet on a more architectural level would be moving the projection to use pre-multiplied alpha, this would remove the premultiply and un-premulitply steps for each level of the pyramid as well as the scaled blit itself, thankfully when I start migrating this last piece of box-filtering code back to GEGL again I already have that, and thus should be able to do slightly faster scaled blitting from the pyramid. /Ø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] Is it too late to send a l10n patch for GIMP 2.4.0?
Choi, Ji-Hui wrote: > Hi. I'm new in gimp development. > > few day ago, I checked gimp 2.4 rc1 source, and then I noticed the > l10n file for korean was so terrible. it means translation was not > apply almostly. > > so I contacted our tongue translator, and got an answer. "it's for you." :-( > BTW, so I fixed, reassigned, etc.. > > now I wonder, can I apply this patch on 2.4.0? > if I'm not late, where and what do I send? > I worked with po file using poedit on windows XP > > please, give me advice > > Greetings > Hello Choi I'm not sure what the Right way of doing this is, but for now you can attach the diff of the language file in reply to this mail, so that a developer can look it through and commit it if it looks ok. - Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Is it too late to send a l10n patch for GIMP2.4.0?
My understanding is that it is never too late for translation improvements, even well after a stable release, and that the correct place to send them is to the person responsible for your language. Often translators don't even *begin* to work until the "string freeze" that comes shortly before a release. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Is it too late to send a l10n patch for GIMP 2.4.0?
On Wed, 2007-08-22 at 10:40 +0900, Choi, Ji-Hui wrote: > Hi. I'm new in gimp development. > > few day ago, I checked gimp 2.4 rc1 source, and then I noticed the > l10n file for korean was so terrible. it means translation was not > apply almostly. > > so I contacted our tongue translator, and got an answer. "it's for you." :-( > BTW, so I fixed, reassigned, etc.. > > now I wonder, can I apply this patch on 2.4.0? > if I'm not late, where and what do I send? > I worked with po file using poedit on windows XP > > please, give me advice It is never too late for translations, however all translations of GNOME SVN modules are handled by the gnome-i18n mailing list. Please contact them, somebody there will give you the right advice or sommit your patches. ciao, --mitch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New option "Use custom quality settings" for JPEG files
On Wed, 15 Aug 2007 10:20:48 -0400, [EMAIL PROTECTED] wrote: > Quoting Robert L Krawitz <[EMAIL PROTECTED]>: > > The problem is that "custom tables" seems very confusing -- it sounds > > like the user's going to be asked to input something she knows nothing > > about. One could argue that "Use existing image quality settings" [...] > My only comment on this issue is that the term "image" is consistently > employed within the GIMP vocabulary to mean the "in-memory" copy of > the picture being edited [...] I think that using the terms "original image" would avoid this problem. We are basically left with two options: 1) "Use custom quality settings" - Hard to understand for most users - Technically correct description - No need to change the code; this is what we have now 2) "Use quality settings from original image" - Easier to understand for most users - Correct description for the most common usage scenario - Requires some small changes to the code - Breaks the string freeze before 2.4 It seems that going for (2) would be better for the users but would annoy some translators. But I got several requests to go for something like option (2), so I would like to know if it is worth breaking the string freeze. Opinions? -Raphaël P.S.: please do not mention bikesheds. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSOC (was: brush manager)
On Sun, 19 Aug 2007 19:28:13 +0200, Karine Delvare <[EMAIL PROTECTED]> wrote: > There was a 2006 Google Summer of Code project for this. If it had been > completed, there would be a brush manager in GIMP 2.4, but it wasn't > (the student is not to blame, he focused on something completely > different instead). > > Maybe the same project can be proposed for the 2008 GSOC? Side note regarding the Google Summer of Code: let's hope that we can be selected in 2008. Although we do not know the reasons why other projects were selected instead of GIMP for GSoC 2007, it seems that most GSoC projects focus on "quick wins". It is likely that we could improve our chances of being selected next year by working on the following things: - Having at least one stable GIMP release per year. - Merging GSoC results faster in the main codebase (if appropriate) and advertising them as new features on our web site, etc. - Being better prepared for GSoC by focusing on a smaller set of ideas but with better descriptions of their scope, etc. - Making it easier for newcomers to contribute to the core. I admit that I do not know how to do that. Maybe we could start by providing a good overview and top-down description of how GIMP works internally? But I don't think I would even be able to write that myself... -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
Hello all, Here is another way I thought I could give some form of "extensibility" to a plugin user. Say, that I want my plugin to be a single entry point to all the Image processing operations possible with GIMP. What I do is display all the GIMP functions to the Plugin user via the Plugin User Interface(GUI). Then the user selects the operation that is to be performed and the plugin sets off to do the necessary job. I am assuming here that the functions of the GIMP that I list for the user is only those for which there exists a API entry in the libGimp. In the background when the user selects a particular operation, the corresponding API function is called. This is of course an assumption to simplify the thought process. Am i thinking in a way that could possibly be implemented? or is the word "extensible" remotely applicable to my idea? Waiting for your comments! -- Amit Kumar Saha [URL]:http://amitsaha.in.googlepages.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
Amit Kumar Saha wrote: > Here is another way I thought I could give some form of > "extensibility" to a plugin user. Say, that I want my plugin to be a > single entry point to all the Image processing operations possible > with GIMP. Now your plug-in seems to become something I'd call GIMP. What use cases are you trying to handle, actually? Regards, Michael -- GIMP > http://www.gimp.org | IRC: irc://irc.gimp.org/gimp Wiki > http://wiki.gimp.org | .de: http://gimpforum.de Plug-ins > http://registry.gimp.org | ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
On Tue, 21 Aug 2007 15:48:15 +0530, "Amit Kumar Saha" <[EMAIL PROTECTED]> wrote: > Is there any way to make GIMP plugins themselves extensible. My point > here is that, can we make a GIMP plugin which allows itself modifiable > by a end-user to include a new functionality without much of a hassle > on part of the end-user. Does any one know of a method to do this or > any GIMP plugin which already does this? Besides the scripting languages mentioned by others, you could also take a look at the MathMap plug-in if you are good at math... MathMap home page: http://www.complang.tuwien.ac.at/schani/mathmap/ Nice examples of MathMap usage: http://www.flickr.com/groups/mathmap/ -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
Amit Kumar Saha wrote: > Am i thinking in a way that could possibly be implemented? or is the > word "extensible" remotely applicable to my idea? > So what you're talking about here is a graphical interface to the API that a user can use to build his own extensions? Essentially, it's a graphical programming language. There are quite a few examples of these in the music world that allow the construction of modular synths (amongst other things). It sounds to me more like a separate companion program that's used to construct plug-ins than a plug-in itself. I like the idea very much. ---AV & Spam Filtering by M+Guardian - Risk Free Email (TM)--- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
On Wed, 22 Aug 2007 23:19:30 +0100, David Marrs <[EMAIL PROTECTED]> wrote: > Amit Kumar Saha wrote: > > Am i thinking in a way that could possibly be implemented? or is the > > word "extensible" remotely applicable to my idea? > > > So what you're talking about here is a graphical interface to the API that a > user can use to build his own extensions? Essentially, it's a graphical > programming language. There are quite a few examples of these in the music > world > that allow the construction of modular synths (amongst other things). Not only in the music world. Around 1993 or so, I remember using a program called Khoros Cantata to design some image filters. A quick search on the web returned this tutorial with screenshots of the old X11 version that I used: http://www.cse.psu.edu/~cg585/cantata-over.html Just imagine that the glyphs (the boxes that can be connected) could be the operations that GIMP offers through the PDB. It seems that Khoros Cantata has been acquired at least twice by different companies, has been ported to Windows, and is now sold as Accusoft VisiQuest: http://www.accusoft.com/products/visiquest/overview.asp The interface has changed a bit, but it is still based on the same ideas of connecting glyphs providing various functions. By the way, this brings back some memories about what I did in 1993 as an exercise for a course in digital imaging. Students were asked to write a new filter for Khoros and use it to perform some interesting image transformations. I decided to write a filter that would use various correlation methods to reconstruct an image in which the lines were shifted horizontally by some random amount. The default method was optimized for "un-shifting" images at TV resolution (PAL) that were shifted by one of three predefined offsets picked at random. The method worked surprisingly well. The code and the results were presented to the professor. He asked if, by any chance, this could be used to decode Canal+ images (a pay TV channel that was popular in several European countries). And the answer was yes. Not in real time because the 486 processors that were common at that time were not fast enough, but the method worked well with recorded TV streams (sometimes even without using inter- frame correlations). Ah, I still have fun when I remember this and when I consider that the professor gave one of the top marks for this exercise. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
Em Qua, 2007-08-22 às 23:19 +0100, David Marrs escreveu: > It sounds to me more like a separate companion program that's used to > construct > plug-ins than a plug-in itself. I like the idea very much. Same with me; I would love something like a node-based editor (e.g. http://pupuedit.sourceforge.net/screenshots/pihlaja_04_04_2007.png and http://imaginit.rand.com/files/water_graph.gif ) This would let non-programmers, or programmers which aren't into image processing, create their own plug-ins. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
On 8/23/07, David Marrs <[EMAIL PROTECTED]> wrote: > Amit Kumar Saha wrote: > > Am i thinking in a way that could possibly be implemented? or is the > > word "extensible" remotely applicable to my idea? > > > So what you're talking about here is a graphical interface to the API that a > user can use to build his own extensions? Essentially, it's a graphical > programming language. There are quite a few examples of these in the music > world > that allow the construction of modular synths (amongst other things). > > It sounds to me more like a separate companion program that's used to > construct > plug-ins than a plug-in itself. I like the idea very much. In some ways, this is essentially what /meta operations/ in GEGL is about, at the moment they are written in C, but they could just as well be created with an XML syntax and edited in a graph based environment. See GEGL (http://www.gegl.org/) and bug #465743. /Ø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] Extending GIMP Plugins
Renan Birck wrote: > Same with me; I would love something like a node-based editor (e.g. > http://pupuedit.sourceforge.net/screenshots/pihlaja_04_04_2007.png and > http://imaginit.rand.com/files/water_graph.gif ) > > This would let non-programmers, or programmers which aren't into image > processing, create their own plug-ins. That looks similar to the types of things one can do with GEGL which is due to be integrated in to GIMP after the 2.4 release. -- Cheers! Kevin. http://www.ve3syb.ca/ |"What are we going to do today, Borg?" Owner of Elecraft K2 #2172 |"Same thing we always do, Pinkutus: | Try to assimilate the world!" #include | -Pinkutus & the Borg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Extending GIMP Plugins
Hello Kevin, On 8/23/07, Kevin Cozens <[EMAIL PROTECTED]> wrote: > > That looks similar to the types of things one can do with GEGL which is due to > be integrated in to GIMP after the 2.4 release. I shall have a look at GEGL. Thanks -- Amit Kumar Saha [URL]:http://amitsaha.in.googlepages.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSOC
Raphaël Quinet wrote: > - Having at least one stable GIMP release per year. That would be nice. I am sure there are a quite a few GIMP users who would like to see some of the changes and new features available in a release version without waiting a couple of years as has happened on occasion with recent releases. > - Making it easier for newcomers to contribute to the core. I admit > that I do not know how to do that. Maybe we could start by > providing a good overview and top-down description of how GIMP > works internally? You beat me to suggesting this on the mailing list. Its something I've been thinking about for a few weeks now. In fact, I recently ran across an open source project (I forget which one) that mentioned on their web site that they had available a document which had an overview to the source tree. I thought this was a great idea. The GIMP source tree has been cleaned up and reorganized over the last few releases which makes it a bit easier to get in to but it is still a huge code base and somewhat impenetrable to someone who doesn't spend a lot of time wading through the directories. It also helps to know about auto-generated files, and what they are for. I have too many projects/interests so I haven't spent a lot of time trying to decipher GIMP's huge source tree. For me it results in my avoiding GIMP related coding that touches on the "internals". The fact I'm not a graphic designer and that GIMP far exceeds my typical needs in an image manipulation program also hasn't helped in my desire to delve too deeply in to GIMP's source. Even delving too deep in to GEGL's relatively small source tree is a bit more than I have time/inclination for at the moment. The only problem with any docs re: the GIMP source tree right now is that they will have to be restricted to GIMP 2.2 for now since the code will undergo some big changes after the 2.4 release. -- Cheers! Kevin. http://www.ve3syb.ca/ |"What are we going to do today, Borg?" Owner of Elecraft K2 #2172 |"Same thing we always do, Pinkutus: | Try to assimilate the world!" #include | -Pinkutus & the Borg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Tile creation and tile caching
hello every one, can any one tell me when a map is tiled, what is the extent of zoom we can specify which does not create any problem for us as developers and users to view the map. please reply to this.. its urgent sudha. [EMAIL PROTECTED] wrote: Send Gimp-developer mailing list submissions to gimp-developer@lists.XCF.Berkeley.EDU To subscribe or unsubscribe via the World Wide Web, visit https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of Gimp-developer digest..." Today's Topics: 1. Re: Is it too late to send a l10n patch for GIMP 2.4.0? (Michael Natterer) 2. Re: New option "Use custom quality settings" for JPEG files (Rapha?l Quinet) 3. Re: GSOC (was: brush manager) (Rapha?l Quinet) 4. Re: Extending GIMP Plugins (Amit Kumar Saha) 5. Re: Extending GIMP Plugins (Michael Schumacher) 6. Re: Extending GIMP Plugins (Rapha?l Quinet) 7. Re: Extending GIMP Plugins (David Marrs) 8. Re: Extending GIMP Plugins (Rapha?l Quinet) -- Message: 1 Date: Wed, 22 Aug 2007 21:56:43 +0200 From: Michael Natterer Subject: Re: [Gimp-developer] Is it too late to send a l10n patch for GIMP 2.4.0? To: "Choi, Ji-Hui" Cc: gimp-developer@lists.XCF.Berkeley.EDU Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain On Wed, 2007-08-22 at 10:40 +0900, Choi, Ji-Hui wrote: > Hi. I'm new in gimp development. > > few day ago, I checked gimp 2.4 rc1 source, and then I noticed the > l10n file for korean was so terrible. it means translation was not > apply almostly. > > so I contacted our tongue translator, and got an answer. "it's for you." :-( > BTW, so I fixed, reassigned, etc.. > > now I wonder, can I apply this patch on 2.4.0? > if I'm not late, where and what do I send? > I worked with po file using poedit on windows XP > > please, give me advice It is never too late for translations, however all translations of GNOME SVN modules are handled by the gnome-i18n mailing list. Please contact them, somebody there will give you the right advice or sommit your patches. ciao, --mitch -- Message: 2 Date: Wed, 22 Aug 2007 22:55:25 +0200 From: Rapha?l Quinet Subject: Re: [Gimp-developer] New option "Use custom quality settings" for JPEG files To: gimp-developer@lists.XCF.Berkeley.EDU Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=UTF-8 On Wed, 15 Aug 2007 10:20:48 -0400, [EMAIL PROTECTED] wrote: > Quoting Robert L Krawitz : > > The problem is that "custom tables" seems very confusing -- it sounds > > like the user's going to be asked to input something she knows nothing > > about. One could argue that "Use existing image quality settings" [...] > My only comment on this issue is that the term "image" is consistently > employed within the GIMP vocabulary to mean the "in-memory" copy of > the picture being edited [...] I think that using the terms "original image" would avoid this problem. We are basically left with two options: 1) "Use custom quality settings" - Hard to understand for most users - Technically correct description - No need to change the code; this is what we have now 2) "Use quality settings from original image" - Easier to understand for most users - Correct description for the most common usage scenario - Requires some small changes to the code - Breaks the string freeze before 2.4 It seems that going for (2) would be better for the users but would annoy some translators. But I got several requests to go for something like option (2), so I would like to know if it is worth breaking the string freeze. Opinions? -Rapha?l P.S.: please do not mention bikesheds. -- Message: 3 Date: Wed, 22 Aug 2007 23:24:10 +0200 From: Rapha?l Quinet Subject: Re: [Gimp-developer] GSOC (was: brush manager) To: gimp-developer@lists.XCF.Berkeley.EDU Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=UTF-8 On Sun, 19 Aug 2007 19:28:13 +0200, Karine Delvare wrote: > There was a 2006 Google Summer of Code project for this. If it had been > completed, there would be a brush manager in GIMP 2.4, but it wasn't > (the student is not to blame, he focused on something completely > different instead). > > Maybe the same project can be proposed for the 2008 GSOC? Side note regarding the Google Summer of Code: let's hope that we can be selected in 2008. Although we do not know the reasons why other projects were selected instead of GIMP for GSoC 2007, it seems that most GSoC projects focus on "quick wins". It is likely that we could improve our chances of being selected next year by working on the following things: - Having at least one stable GIMP
