Re: [Gimp-developer] GIMP and Google SoC
* Improve SIOX to give nice anti-aliased result. The current implementation is a nice bulletpoint in a feature-list, but the result is very jaggy and hardly usable as is. Unless you work at 4 times the final resolution perhaps. Perhaps Gerald could elaborate a bit about the Detail Refinement Brush for SIOX. There is already code for this in GIMP CVS. It just isn't used yet. I would be really happy if the implementation of the DRB could be done as a Google SoC project. And there is still room for speed improvements in SIOX...Me or Kristian would be there for any questions. However, as far as I understood, there is still an issue: Is GIMP able to display non-binary alpha values? I loaded in a PNG that I created using the SIOX demonstration Applet and I saw that GIMP binarizes the alpha values Gerald -- Gerald Friedland Raum 164 Tel: ++49 (0)30/838-75134 Freie Universität Berlin Takustr. 9 http://www.gerald-friedland.org Institut für Informatik 14195 Berlin [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and Google SoC
Gerald Friedland ([EMAIL PROTECTED]) wrote: However, as far as I understood, there is still an issue: Is GIMP able to display non-binary alpha values? I loaded in a PNG that I created using the SIOX demonstration Applet and I saw that GIMP binarizes the alpha values This should only happen for indexed images, then indeed GIMP does binarize the alpha values, at least in the display. If the PNG is stored as a RGBA-PNG then everything should be fine. Hope this helps, 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
Re: [Gimp-developer] GIMP and Google SoC
William Skaggs ([EMAIL PROTECTED]) wrote: 4) Vector layers and tools to manipulate them -- allowing adjustable rectangle and ellipse shapes, lines with arrow, etc. Actually my roadmap for vector layers would look something like this: - create the infrastructure to have vector styles, i.e. a vectors object has fill and stroke attributes. Create GUI to edit these styles. - make it possible to create a connection between a vectors object and a drawable, similiar to a text layer: the drawable gets rerendered when the vectors object changes. - probably it should be possible to attach multiple vectors to a single drawable. Each vectors object would have its own style attributes and the order in the paths dialog would determine the rendering order on the drawable. - Try to figure out a workflow for editing this in a sane manner. IMHO the path tool is sufficient to edit the shape of the associated path, but all the other stuff might need some thinking. Stuff like rectangle and ellipse shapes are not inherently connected to the vector layer stuff, they would simply be different stroke types. I already have implemented an proof-of-concept rectangle stroke type, that is a bit weird to edit, but works. I offer to mentor this project. 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
Re: [Gimp-developer] GIMP and Google SoC
On 4/18/06, Dave Neary wrote: I had some ideas: - Scripting languages and the GIMP - work on ruby or python bindings - Plug-ins: Save for web for example (too small to be a project, but could be part of one) - Effect layers - I think this is fairly straightforward with the GIMP as it is, it's a nice chunk of a project, and would be a nice feature for users - Vector layers (or replace GFig plug-in by Inkscape plug-in?) - Tools - shapes, intelligent eraser? Just another idea, simple and useful: on canvas text editing Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and Google SoC
Few tips for SOC: * Something I am guilty of never getting to was speccing out a search based interface to filters (plugins). I believe a search based interface will be more efficient than navigating through a nested structure of a menu. * Improve SIOX to give nice anti-aliased result. The current implementation is a nice bulletpoint in a feature-list, but the result is very jaggy and hardly usable as is. Unless you work at 4 times the final resolution perhaps. * Flowed text. The text tool doesn't allow to create blocks of justified text. cheers -- Jakub Steiner [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Search of Filters [Re: [Gimp-developer] GIMP and Google SoC]
On Fri, 21 Apr 2006, Jakub Steiner wrote: Date: Fri, 21 Apr 2006 14:24:34 +0200 From: Jakub Steiner [EMAIL PROTECTED] To: gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] GIMP and Google SoC Few tips for SOC: * Something I am guilty of never getting to was speccing out a search based interface to filters (plugins). I believe a search based interface will be more efficient than navigating through a nested structure of a menu. I was using the PDB browser for this purpose. I tried to add a button which would bring up the currently selected filter but I didn't get very far with it, although I do think it should be possible to hack together soemthing. Sincerely Alan Horkan Inkscape http://inkscape.org Abiword http://www.abisource.com Open Clip Art http://OpenClipArt.org Alan's Diary http://advogato.org/person/AlanHorkan/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and Google SoC
Hi, Jakub Steiner [EMAIL PROTECTED] writes: * Something I am guilty of never getting to was speccing out a search based interface to filters (plugins). I believe a search based interface will be more efficient than navigating through a nested structure of a menu. That reminds me that with all the recent changes to the plug-in registration, the current Plug-In Browser has become less useful than it used to be. And I think that it could make sense to replace it by a menu browser. Users shouldn't really have to care about whether a function is implemented in the core or in a plug-in or script. We should probably do the following: - Improve the PDB interface for getting plug-in information. The current API doesn't really work well. All it offers is retrieving a list of all plug-ins. There should be an API that allows queries using regular expression similar to gimp-procedural-db-query. This will allow to improve the Plug-In Browser and long-term it will help for tasks such as one-click plug-in installation/deinstallation. Also we will want to show this information in the proposed Menu Browser (see below). - Improve the Plug-In Browser using the new API. This will show that the new API does what it's supposed to do. It includes adding search functionality similar to what the Procedure Browser offsers. Both plug-ins already use the GimpBrowser widget so this should be relatively easy. A menu browser could also be implemented as a plug-in, provided that we added a PDB API to access the menu structure. But soon enough we would want to allow changes to the menus from the browser, turning it into a menu editor. At this point it probably starts to make sense to implement it in the core instead of exposing all the details of the menu system to the PDB and even allowing to edit by means of PDB calls. Not sure if such a menu browser could double as the filter browser you asked for. You probably had something less intrusive in mind. Could this (the plug-in browser changes and the menu editor) perhaps become a SoC project? * Improve SIOX to give nice anti-aliased result. The current implementation is a nice bulletpoint in a feature-list, but the result is very jaggy and hardly usable as is. Unless you work at 4 times the final resolution perhaps. Perhaps Gerald could elaborate a bit about the Detail Refinement Brush for SIOX. There is already code for this in GIMP CVS. It just isn't used yet. * Flowed text. The text tool doesn't allow to create blocks of justified text. Yes, there's quite a bit of improvements that could be done to the text tool. I think this could be a nice SoC project and I would like to mentor it. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and Google SoC
Hi, just a quick idea: How much sense would it make to try to turn Raphael's approach to metadata editing into a SoC project? I suspect that Raphael might be able to find enough time to mentor it. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and Google SoC
Hi, we could try to propose this as a SoC project: - Redesign and reimplementation of Save and Export in GIMP. Change the semantics of Save and Save As so that images are always saved in the XCF file format. Only the native GIMP format really saves all the image information and allows to losslessly continue editing later. So only saving as XCF should clear the dirty flag of the image. Saving to other formats than XCF is done by exporting the image. The File menu should have an Export menu item (and perhaps also Export As). This opens a dialog that asks the user what to export. The projection (what you see), the active drawable, an animation based on the layers of the image, etc. If the image consists of a single layer this step can be skipped. The dialog then gives the user the choice of a file format including options for that format. It also uses a GtkFileChooser widget to pick a save location. The details of this Export dialog could be determined as part of the redesign or we could try to come up with a detailed proposal beforehand. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and Google SoC
Hi, another thing that came to my mind: - Add a (unit) testing framework and tests to GIMP. Details are left out for now but the idea is to get more unit tests and to make it easier to add and maintain them. But also to have more complex test scripts that perform GIMP operation using the PDB. These scripts would be run on a set of test images and the results would be compared against a set of output images. The test framework should also allow to easily test functionality of a certain plug-in. This way errors could easily be spotted and it would make changes to plug-ins a lot safer. Such tests could also be used as benchmarks to help with optimizations. Should we try to turn this into a more detailed proposal? Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and Google SoC
On 4/21/06, Sven Neumann [EMAIL PROTECTED] wrote: Hi, another thing that came to my mind: - Add a (unit) testing framework and tests to GIMP. Details are left out for now but the idea is to get more unit tests and to make it easier to add and maintain them. But also to have more complex test scripts that perform GIMP operation using the PDB. These scripts would be run on a set of test images and the results would be compared against a set of output images. The test framework should also allow to easily test functionality of a certain plug-in. This way errors could easily be spotted and it would make changes to plug-ins a lot safer. Such tests could also be used as benchmarks to help with optimizations. Should we try to turn this into a more detailed proposal? This sounds like an excellent idea. Rockwalrus ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and Google SoC
Hi, William Skaggs [EMAIL PROTECTED] writes: Here are some suggestions I have heard that I like. without credit to the people who first suggested them: 1) Color management. Sven and others have made a start on this, but quite a bit more needs to be done. Color management is supposed to be in the 2.4 release so it should be finished before the SoC starts. 2) Resource management. Currently resources such as brushes, gradients etc are shown to the user in an unstructured way, which greatly limits the number of items a user can deal with. People love to make collections of things, so this would greatly enhance the user experience. That sounds like a reasonable project to me. 3) System for saving presets for plug-ins. Sven and Mitch have been clearing the way for this, but there is good bit still to do to make it happen. We definitely want this to happen right after 2.4. I am not sure if it makes sense to declare an absolut must-have as a SoC project. IMO We should rather try to come up with some tasks that would be nice to have but that we can easily live without. 4) Vector layers and tools to manipulate them -- allowing adjustable rectangle and ellipse shapes, lines with arrow, etc. Fine with me. 5) Create a manager widget that will allow all of GIMP's windows to be contained in a single parent window, as requested hundreds of times by Windows users. (This would be optional, not forced on people who don't want it.) I don't think we will need this when we are done with the changes to the window handling that have been started in CVS. It also doesn't fit into the long-term plan. We could however try to make window handling a SoC project but I am not sure how well suited that would be. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and Google SoC
Hi, Dave Neary [EMAIL PROTECTED] writes: - Scripting languages and the GIMP - work on ruby or python bindings Another language binding would indeed be a nice project and the Python binding could also be improved. What's Yosh's opinion on the latter? - Plug-ins: Save for web for example (too small to be a project, but could be part of one) IMO Save for Web is complex enough for a project. - Effect layers - I think this is fairly straightforward with the GIMP as it is, it's a nice chunk of a project, and would be a nice feature for users How is this fairly straightforward with the current architecture? I would rather say that it is currently almost impossible to implement sanely. 1. Feature freeze 2.4 soon (before the end of May), for release during the Summer 2. Create SoC branches for integration of the SoC projects 3. After release of 2.4, merge successful projects to HEAD, and release 2.5.0 (GIMP-SoC) in September. Let the branch harden for a month or so, and release 2.6.0 off that. 4. Start gegl integration on a branch, if needs be, and integrate that work into HEAD straight after the release of 2.6.0. I don't see why we should wait with GEGL integration. There are people waiting for the 2.4 release to start this work. It would be a huge mistake to postpone this. The amount of GEGL integration that is planned for the next release is small anyway and is unlikely going to delay the 2.6 release. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and Google SoC
Hi, Alexander Rabtchevich [EMAIL PROTECTED] writes: What about official Red eye plug-in, possibly with SIOX, as Sven suggested? Also some kind of healing brush can be useful. Yes, I think that a decent Red Eye plug-in would be nice project. Same for a healing brush tool. Also something like PS's Vanishing Point feature would be nice to have. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and Google SoC
Okay, we are now on Google's list and have begun to put together a project page, which you can find at http://wiki.gimp.org/gimp/SummerOfCode . A couple of important points: 1) Ideally, a mentor for a project would be somebody who is capable of doing the project him/herself without a lot of false starts and hacking around, and only lacks the time for it. If you aren't at this level, you *might* still be a viable mentor, but only if you make this clear and get a commitment from somebody with more knowledge to give you whatever backup you will need. Just because you are interested in an idea does not mean that you are ready to mentor it. 2) If there is a project on the list that you are ready and willing to mentor, please add your initials, or some other unique identifier, to the description somewhere. Multiple volunteers for a single project are acceptable. 3) SoC students will probably be very enthusiastic and prepared to put in hundreds of hours of work. Don't be afraid to ask for things that are difficult. Conversely, be prepared to give regular guidance -- a student with nothing to do because of lack of feedback will get very frustrated very quickly. All this being said, please add your ideas to the page, or modify the ideas that are there. Sven and Mitch should feel free to delete ideas that they see as bad projects. Ultimately we should get this down to not more than a dozen clearly expressed and well-formulated projects. -- 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] GIMP and Google SoC
Von: Dave Neary [EMAIL PROTECTED] Hi all, I have registered the GIMP as a mentoring organisation for the Summer of Code (I had been in contact with Google before the announcement), we should be up on the page over the next couple of days. It would have been nice to know this a bit earlier. As you can see in the other thread, we were already preparing stuff... Michael -- GMX Produkte empfehlen und ganz einfach Geld verdienen! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and Google SoC
What about official Red eye plug-in, possibly with SIOX, as Sven suggested? Also some kind of healing brush can be useful. -- With respect Alexander Rabtchevich ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and Google SoC
On Tue, Apr 18, 2006 at 10:04:27AM +0200, Dave Neary wrote: I have registered the GIMP as a mentoring organisation for the Summer of Code (I had been in contact with Google before the announcement), we should be up on the page over the next couple of days. Maybe there's a big chunk of work in GEGL nobody dared to do yet? Bye, Tino. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and Google SoC
Dave Neary wrote: I have registered the GIMP as a mentoring organisation for the Summer of Code (I had been in contact with Google before the announcement), we should be up on the page over the next couple of days. Thanks Dave for taking the initiative. Does this mean that you are volunteering to be the coordinator, as described in the SoC FAQ? Our next requirement is a list of project ideas for people to take on - these should be: - Suitable for an advanced student, for 10 weeks work (1/2 weeks planning, 4 weeks coding, 2/4 weeks refining, 1/2 weeks for report) - Have a mentor associated - Be on a publicly accessible web-page (the wiki will do) - Be interesting and useful (perhaps it goes without saying, but document the API of library X would not qualify) We should settle on half-a-dozen well-defined project ideas, because having too many choices leads to brain freeze, and people who want to work with GIMP but don't like any of the suggestions are always free to come up with ideas of their own. And it would be nice to put them on a page on the developer web site as opposed to the Wiki. The way I see these projects being integrated into CVS is: [. . .] I think this timeline is unrealistic, and that it would be better to aim for the results of the student projects being incorporated in the 2.4 release. Here are some suggestions I have heard that I like. without credit to the people who first suggested them: 1) Color management. Sven and others have made a start on this, but quite a bit more needs to be done. 2) Resource management. Currently resources such as brushes, gradients etc are shown to the user in an unstructured way, which greatly limits the number of items a user can deal with. People love to make collections of things, so this would greatly enhance the user experience. 3) System for saving presets for plug-ins. Sven and Mitch have been clearing the way for this, but there is good bit still to do to make it happen. 4) Vector layers and tools to manipulate them -- allowing adjustable rectangle and ellipse shapes, lines with arrow, etc. 5) Create a manager widget that will allow all of GIMP's windows to be contained in a single parent window, as requested hundreds of times by Windows users. (This would be optional, not forced on people who don't want it.) -- 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
Background window [was Re: [Gimp-developer] GIMP and Google SoC]
On Tue, 18 Apr 2006, William Skaggs wrote: Date: Tue, 18 Apr 2006 09:41:40 -0700 From: William Skaggs [EMAIL PROTECTED] To: gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] GIMP and Google SoC 5) Create a manager widget that will allow all of GIMP's windows to be contained in a single parent window, as requested hundreds of times by Windows users. (This would be optional, not forced on people who don't want it.) Is there a good reason why something this would need to be done as a whole new project? Gimpshop uses: Gimp Background window version 2.1, Copyright (C) 2004 As far as I can tell is what is less flatteringly but better know as the GIMP Deweirdifyer since the source archive for it is labelled BackgroundWindow. Is there some techincal reason making it impractical to integrate this instead? Sincerely Alan Horkan Inkscape http://inkscape.org Abiword http://www.abisource.com Open Clip Art http://OpenClipArt.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: Background window [was Re: [Gimp-developer] GIMP and Google SoC]
Alan Horkan wrote: Is there some techincal reason making it impractical to integrate this instead? - MS-Windows-only - who will maintain it afterwards? Also, some users have complaint about stability issues after installing this plug-in. This is something that could be handled in the SoC project, however. HTH, Michael -- The 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
