Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
On 2/13/11, LightningIsMyName wrote: I'm starting this thread to list ideas for Google Summer of Code 2011, for the GIMP project. Since in the last year collecting ideas was done partially by the mailing list, let's try it again this year and keep most ideas here. In 2009 and 2010 guiguru did GIMP related usability workshops that haven't resulted in a spec yet (the 2008 one has), but some useful material presumably is available: - vector layers and drawing geometric primitives [1] - unification of selection tools (no reports from it, IIRC) [1] http://blog.mmiworks.net/2009_07_01_archive.html Could those be GSoC projects as well? At least unification of selection tools could become a project to povide infrastructure for gegl based selection tools (or am I missing an existing one?). Another idea was, IIRC, an on-canvas iWarp implementation on top of improved gegl op implemented last GSoC for cage transform so that it worked out of cage. Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
I could think of fully hardware accelerated rendering. Most modern hardware provides accelerated rendering and many tools could be speed up significantly. The CPU just doesn't scale well when it comes to current image resolutions and some brush types (smooth, smear, etc.). Also the performance to display multiple layers or adjusting them could be much faster. Just remembering my last work (a drawing), that i barely could finish, since it got very slow over time. Am 08.03.2011 19:21, schrieb Alexandre Prokoudine: On 2/13/11, LightningIsMyName wrote: I'm starting this thread to list ideas for Google Summer of Code 2011, for the GIMP project. Since in the last year collecting ideas was done partially by the mailing list, let's try it again this year and keep most ideas here. In 2009 and 2010 guiguru did GIMP related usability workshops that haven't resulted in a spec yet (the 2008 one has), but some useful material presumably is available: - vector layers and drawing geometric primitives [1] - unification of selection tools (no reports from it, IIRC) [1] http://blog.mmiworks.net/2009_07_01_archive.html Could those be GSoC projects as well? At least unification of selection tools could become a project to povide infrastructure for gegl based selection tools (or am I missing an existing one?). Another idea was, IIRC, an on-canvas iWarp implementation on top of improved gegl op implemented last GSoC for cage transform so that it worked out of cage. Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
I could think of fully hardware accelerated rendering. Most modern hardware provides accelerated rendering and many tools could be speed up significantly. The CPU just doesn't scale well when it comes to current image resolutions and some brush types (smooth, smear, etc.). Also the performance to display multiple layers or adjusting them could be much faster. I think it would be more of a wish for GEGL as the GIMP's engine of tomorrow ;). My best! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
On 2/13/11, LightningIsMyName wrote: I'm starting this thread to list ideas for Google Summer of Code 2011, for the GIMP project. Since in the last year collecting ideas was done partially by the mailing list, let's try it again this year and keep most ideas here. In 2009 and 2010 guiguru did GIMP related usability workshops that haven't resulted in a spec yet (the 2008 one has), but some useful material presumably is available: - vector layers and drawing geometric primitives [1] I'm not convinced of the notion of vector layers. Sure they can be nice addition but I fear they'll end up being quite frustrating. I think so because to make them as ellastic and usable as in vector graphics editors one'd have to double such editor in GIMP. If one won't do that then there's a danger of whole tool being not much more than a toy. I'm not generally enemy of the idea, but I've got my fears and doubts if it hase to be done that way. I've got a dream about visual editing program consisting of different components, each taking care of one of presentation aspects with one underlaying rendering engine (target aware angine—I don't like cairo's “I don't care what's on the end” attitude ;)). Such program would load dynamically a set of editing tools if needed and only the needed. So if one's editing vector there'll be full blown toolset for that–no compromises, no implementation doubling. If one's to typeset a book, there would be loaded typesetting engine loaded with all controls available and so on. But I digress :). - unification of selection tools (no reports from it, IIRC) [1] http://blog.mmiworks.net/2009_07_01_archive.html Could those be GSoC projects as well? At least unification of selection tools could become a project to povide infrastructure for gegl based selection tools (or am I missing an existing one?). I think that could do some good :). Another idea was, IIRC, an on-canvas iWarp implementation on top of improved gegl op implemented last GSoC for cage transform so that it worked out of cage. I like that :). Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
On 3/8/11, Bogdan Szczurek wrote: I could think of fully hardware accelerated rendering. Most modern hardware provides accelerated rendering and many tools could be speed up significantly. The CPU just doesn't scale well when it comes to current image resolutions and some brush types (smooth, smear, etc.). Also the performance to display multiple layers or adjusting them could be much faster. I think it would be more of a wish for GEGL as the GIMP's engine of tomorrow ;). Awww, well, come on over, baby, step into my time machine. (c) GFR http://git.gnome.org/browse/gegl/log/?h=gsoc2009-gpu Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
I really miss some basic vector functionality in Gimp. In my last works i used Inkscape and Gimp together. Drawing sharp outlines in Inkscape, exporting them to PNG and imported them into Gimp again, to work with brushes and colors. Basically i used Inkscape to create Alpha-Layers for accurate strokes. The exporting and importing was some kind of pain. Just the ability to create basic shapes (Bezier contours), would be a great improvement. It doesn't need to provide anything. But it should be as simple as the Polygon-Tool and the Node-Tool from Inkscape. That would basically all i would need. Opening Inkscape, drawing a simple Shape (outline), exporting it, importing it and then fill it in Gimp is not a comfortable way. Am 08.03.2011 20:23, schrieb Bogdan Szczurek: On 2/13/11, LightningIsMyName wrote: I'm starting this thread to list ideas for Google Summer of Code 2011, for the GIMP project. Since in the last year collecting ideas was done partially by the mailing list, let's try it again this year and keep most ideas here. In 2009 and 2010 guiguru did GIMP related usability workshops that haven't resulted in a spec yet (the 2008 one has), but some useful material presumably is available: - vector layers and drawing geometric primitives [1] I'm not convinced of the notion of vector layers. Sure they can be nice addition but I fear they'll end up being quite frustrating. I think so because to make them as ellastic and usable as in vector graphics editors one'd have to double such editor in GIMP. If one won't do that then there's a danger of whole tool being not much more than a toy. I'm not generally enemy of the idea, but I've got my fears and doubts if it hase to be done that way. I've got a dream about visual editing program consisting of different components, each taking care of one of presentation aspects with one underlaying rendering engine (target aware angine—I don't like cairo's “I don't care what's on the end” attitude ;)). Such program would load dynamically a set of editing tools if needed and only the needed. So if one's editing vector there'll be full blown toolset for that–no compromises, no implementation doubling. If one's to typeset a book, there would be loaded typesetting engine loaded with all controls available and so on. But I digress :). - unification of selection tools (no reports from it, IIRC) [1] http://blog.mmiworks.net/2009_07_01_archive.html Could those be GSoC projects as well? At least unification of selection tools could become a project to povide infrastructure for gegl based selection tools (or am I missing an existing one?). I think that could do some good :). Another idea was, IIRC, an on-canvas iWarp implementation on top of improved gegl op implemented last GSoC for cage transform so that it worked out of cage. I like that :). Best regards! thebodzio ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
I could think of fully hardware accelerated rendering. Most modern hardware provides accelerated rendering and many tools could be speed up significantly. The CPU just doesn't scale well when it comes to current image resolutions and some brush types (smooth, smear, etc.). Also the performance to display multiple layers or adjusting them could be much faster. I think it would be more of a wish for GEGL as the GIMP's engine of tomorrow ;). Awww, well, come on over, baby, step into my time machine. (c) GFR buehhehehehe :D Best! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
- vector layers and drawing geometric primitives [1] I'm not convinced of the notion of vector layers. Sure they can be nice addition but I fear they'll end up being quite frustrating. I think so because to make them as ellastic and usable as in vector graphics editors one'd have to double such editor in GIMP. If one won't do that then there's a danger of whole tool being not much more than a toy. I'm not generally enemy of the idea, but I've got my fears and doubts if it hase to be done that way. There are, in fact, different proposal, if you read the page. Each of the three groups came up with a different idea. So there is not *one* way, but actually three ways for you to have fears and doubts about :) Oh dear! ;) I've got a dream about visual editing program consisting of different components, each taking care of one of presentation aspects with one underlaying rendering engine (target aware angine—I don't like cairo's “I don't care what's on the end” attitude ;)). It's what we, utter geeks, call a framework :) That adds +10 to coolness but don't let everybody know ;) Deneba/ACD Canvas was an attempt to create such one, but it was done on top of software started in mid 80s. Sometimes a whole week passes when I don't wake up in cold sweat seeing it in my dreams. Funny stuff… :). But seriously, sometimes it's good for somebody to try a thing that didn't work out last time. Because of that stubborness we're able to fly by airplanes nowadays ;). I consider idea of one flexible uberapp much more sensible and appealing than implementing wee bit of “alien world” in different apps—just seems half-solution for me. Best! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
I really miss some basic vector functionality in Gimp. In my last works i used Inkscape and Gimp together. Drawing sharp outlines in Inkscape, exporting them to PNG and imported them into Gimp again, to work with brushes and colors. Basically i used Inkscape to create Alpha-Layers for accurate strokes. The exporting and importing was some kind of pain. Just the ability to create basic shapes (Bezier contours), would be a great improvement. It doesn't need to provide anything. But it should be as simple as the Polygon-Tool and the Node-Tool from Inkscape. That would basically all i would need. Opening Inkscape, drawing a simple Shape (outline), exporting it, importing it and then fill it in Gimp is not a comfortable way. Skippping back and forth from Inkscape to GIMP doesn't sound good to me either, but wasn't existing “path” tool sufficient in your case? Don't get me wrong, I'm just trying to understand the task you were up to do. My best! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
On Tue, Mar 8, 2011 at 8:00 PM, Bogdan Szczurek thebod...@gmail.com wrote: I've got a dream about visual editing program consisting of different components, each taking care of one of presentation aspects with one underlaying rendering engine (target aware angine—I don't like cairo's “I don't care what's on the end” attitude ;)). It's what we, utter geeks, call a framework :) That adds +10 to coolness but don't let everybody know ;) Deneba/ACD Canvas was an attempt to create such one, but it was done on top of software started in mid 80s. Sometimes a whole week passes when I don't wake up in cold sweat seeing it in my dreams. Funny stuff… :). But seriously, sometimes it's good for somebody to try a thing that didn't work out last time. Because of that stubborness we're able to fly by airplanes nowadays ;). I consider idea of one flexible uberapp much more sensible and appealing than implementing wee bit of “alien world” in different apps—just seems half-solution for me. So do I,. and a framework that can make something like that happen is called GEGL ;) http://pippin.gimp.org/tmp/gegl-foo/ Buried in history of the GEGL repo is a GTK+ based UI with at various revisions both freehand painting with simple dynamics, as well as.. node based both bezier and spiro curve editing bits, integrated with generic layer filters and more.. it is/was not really that much code, but it was sloppy code thrown together with left-over pieces from a video editor. I am from time to time toying with resurrecting that project as a minimal thing show-casing what is possible to achieve. If I do get around to do that I would probably avoid doing it with C though, so it would be a complete rewrite and not really a resurrection. /Ø -- «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] Google Summer of Code 2011 - Project Ideas/Suggestions
On Tue, Mar 8, 2011 at 8:00 PM, Bogdan Szczurek thebod...@gmail.com wrote: I've got a dream about visual editing program consisting of different components, each taking care of one of presentation aspects with one underlaying rendering engine (target aware angine—I don't like cairo's “I don't care what's on the end” attitude ;)). It's what we, utter geeks, call a framework :) That adds +10 to coolness but don't let everybody know ;) Deneba/ACD Canvas was an attempt to create such one, but it was done on top of software started in mid 80s. Sometimes a whole week passes when I don't wake up in cold sweat seeing it in my dreams. Funny stuff… :). But seriously, sometimes it's good for somebody to try a thing that didn't work out last time. Because of that stubborness we're able to fly by airplanes nowadays ;). I consider idea of one flexible uberapp much more sensible and appealing than implementing wee bit of “alien world” in different apps—just seems half-solution for me. So do I,. and a framework that can make something like that happen is called GEGL ;) I'm happy to hear that! :) http://pippin.gimp.org/tmp/gegl-foo/ Buried in history of the GEGL repo is a GTK+ based UI with at various revisions both freehand painting with simple dynamics, as well as.. node based both bezier and spiro curve editing bits, integrated with generic layer filters and more.. it is/was not really that much code, but it was sloppy code thrown together with left-over pieces from a video editor. I am from time to time toying with resurrecting that project as a minimal thing show-casing what is possible to achieve. If I do get around to do that I would probably avoid doing it with C though, so it would be a complete rewrite and not really a resurrection. Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
Am 08.03.2011 21:07, schrieb Bogdan Szczurek: I really miss some basic vector functionality in Gimp. In my last works i used Inkscape and Gimp together. Drawing sharp outlines in Inkscape, exporting them to PNG and imported them into Gimp again, to work with brushes and colors. Basically i used Inkscape to create Alpha-Layers for accurate strokes. The exporting and importing was some kind of pain. Just the ability to create basic shapes (Bezier contours), would be a great improvement. It doesn't need to provide anything. But it should be as simple as the Polygon-Tool and the Node-Tool from Inkscape. That would basically all i would need. Opening Inkscape, drawing a simple Shape (outline), exporting it, importing it and then fill it in Gimp is not a comfortable way. Skippping back and forth from Inkscape to GIMP doesn't sound good to me either, but wasn't existing “path” tool sufficient in your case? Don't get me wrong, I'm just trying to understand the task you were up to do. My best! thebodzio At first i have to note, that the usage of the current path tool in Gimp is a pain. Its really hard, needlessly complicated to work with. The behavior of Inkscape is way superior, even if it is not perfect. Also it is hard to manage multiple paths at once. I won't say that Gimp is missing a feature you could use for the same things, but i just don't want to use it, since it takes me longer to work with it as Skipping back and forth between Inkscape and Gimp... (not a good sign for useability) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
On 3/2/11, Alexander Rabtchevich wrote: I can remember there was an intention to rewrite iwarp plug-in as a tool... It's doable on top of the gegl op that powers Cage transform tool. That op only :) has to be tought working outside of the cage. Sounds like a good GSoC project to me. Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
On Tue, Mar 1, 2011 at 1:52 PM, LightningIsMyName lightningismyn...@gmail.com wrote: Hello, The nearly finalised project list for GSoC 2011 is available at the wiki: http://gimp-wiki.who.ee/index.php/Hacking:GSoC_2011/Ideas Users who have a comment on the list should raise it now. The ideas list was divided in to two parts, as discussed on IRC. Developers who wish to make small corrections should feel free to do so, but please do not move projects between the lists / add/remove projects or do any other major change without a discussion first. GIMP on! ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
For some reason my text disappeared when I hit send for the previous message -- sorry! Here is what I wrote: It is very important to make sure that each project in the list has a developer who is prepared to sign up to mentor it. There are two reasons for this. First, because it is a waste of time and effort for students to apply for a project that nobody is prepared to mentor. Second, because I am afraid that some of the proposals are actually ill-conceived, and that will become apparent because no developer will be willing to mentor them in the form as written. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
Hello, The nearly finalised project list for GSoC 2011 is available at the wiki: http://gimp-wiki.who.ee/index.php/Hacking:GSoC_2011/Ideas Users who have a comment on the list should raise it now. The ideas list was divided in to two parts, as discussed on IRC. Developers who wish to make small corrections should feel free to do so, but please do not move projects between the lists / add/remove projects or do any other major change without a discussion first. GIMP on! ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
LightningIsMyName wrote: Users who have a comment on the list should raise it now. I did mention one possible GSoC idea was a rewrite of gimp-perl. The binding seems to be a bit of a mess and could stand some clean up. I may squeeze in a bit more time to make sure it at least works with 2.6 and git master but I won't attempt a rewrite until after I do some of the planned work for TinyFu version 2. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
Users who have a comment on the list should raise it now. The ideas list was divided in to two parts, as discussed on IRC. Developers who wish to make small corrections should feel free to do so, but please do not move projects between the lists / add/remove projects or do any other major change without a discussion first. Great to have such list! :) I've got a word about slicing tools. I think it would be even nicer if slices as that: --- | - | | | | | | - | --- didn't have to be considered as nested. If they'd be treated as independent entities it would be easy to have e.g.: - | | --+---+-- | | | | | - | | | - Each slice could have, as one of properties, list of layers brought into account when generating final slice image. That way one would be able to easily “cut” some slice for background, even if the background is overlayed with some content. Furthermore, slices could have been able to create “stacks” of graphics exported as one image. I mean a situation when “idle” for of menu is on one layer, “hover” on another and finally “clicked” on third. So: one slice is created, “stack” for that slice is defined in such a way that first layer is topmost part of exported graphics, second layer is the middle and so on. It would give from single slice final image of: --- |idle | +-+ |hover| +-+ | clicked | --- Vertical alignment is choosen purely for the example's sake. Heck! One could even make some tool to visually place such images from different slices. Details remain to be discussed :). I think that gain from such solution is great. This way one could easily create not only menus but also sets of icons cropped from source image with css. And to do it without creating another image or layer on page layout project with icons packed accordingly, but “cut” them directly from layout. Elements could be then placed only once, so possibility of making a mistake while exporting them would lower considerably. That's just a couple of simple things that “traditional” slices make somewhat horrid to achieve :). I'd love to see something like that in GIMP! :D Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
I can remember there was an intention to rewrite iwarp plug-in as a tool... Kevin Cozens wrote: LightningIsMyName wrote: Users who have a comment on the list should raise it now. I did mention one possible GSoC idea was a rewrite of gimp-perl. The binding seems to be a bit of a mess and could stand some clean up. I may squeeze in a bit more time to make sure it at least works with 2.6 and git master but I won't attempt a rewrite until after I do some of the planned work for TinyFu version 2. 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] Google Summer of Code 2011 - Project Ideas/Suggestions
On Tue, Mar 1, 2011 at 22:52, LightningIsMyName lightningismyn...@gmail.com wrote: Users who have a comment on the list should raise it now. Sven had some time ago the idea of a PDB to D-Bus bridge. Wouldn't that a nice GSoC project? Regards, Tobias ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
And let me throw in another thing. It's been in my head for some time but now I think it's good to show it to the world. Just in the matter of shear curiosity: I'd like to see some conceptual work/code/working example/whatever about automatically configurable grid processing. It may be more of GEGL project than GIMP one, but I believe still beneficial in the end. Since 3D rendering engines do that, maybe it would work nice in 2D world too. Of course a metric and some kind of benchmark would be needed to decide if sending some part of work over network to another node is beneficial. Anyway I think it have chances to make things snappy even on slow machines. I see it as a something between freakin' fat workstations, thin clients with some heavy “mother goose” and mighty cluster. It would (hopefully ;)) help to use what is at hand more optimally. GEGL is designed to be able to split up the rendering requests from the public part of it's API internally and to distribute it among threads/processes/hosts without needing changes to the application using GEGL. At the moment there is only experimental support for using threads in this fashion, but the architecture has been made with distributed processing in mind. This also applies to the GeglBuffers for which there a few years ago already was done experiments with doing multi process/user concurrent manipulation of the same buffers. All of which makes a great opportunity to go from “some experiments” to “actual application” :). Agreed such project would fit GEGL better but some GUI to control GEGL behaviour in that matter would be required nevertheless. Besides… design with delegating processing to multiple threads in mind is one thing and “making it just work” over net is another. That's why I think some (at least conceptual) work is needed to make such thing automatically configurable (avahi shouting about such service available maybe, some metric to decide if letting a node to take part of work is beneficial). Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
On Fri, Feb 25, 2011 at 1:30 AM, Bogdan Szczurek thebod...@gmail.com wrote: And let me throw in another thing. It's been in my head for some time but now I think it's good to show it to the world. Just in the matter of shear curiosity: I'd like to see some conceptual work/code/working example/whatever about automatically configurable grid processing. It may be more of GEGL project than GIMP one, but I believe still beneficial in the end. Since 3D rendering engines do that, maybe it would work nice in 2D world too. Of course a metric and some kind of benchmark would be needed to decide if sending some part of work over network to another node is beneficial. Anyway I think it have chances to make things snappy even on slow machines. I see it as a something between freakin' fat workstations, thin clients with some heavy “mother goose” and mighty cluster. It would (hopefully ;)) help to use what is at hand more optimally. GEGL is designed to be able to split up the rendering requests from the public part of it's API internally and to distribute it among threads/processes/hosts without needing changes to the application using GEGL. At the moment there is only experimental support for using threads in this fashion, but the architecture has been made with distributed processing in mind. This also applies to the GeglBuffers for which there a few years ago already was done experiments with doing multi process/user concurrent manipulation of the same buffers. /Ø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] Google Summer of Code 2011 - Project Ideas/Suggestions
Great thing to bring this up! cut Implement the free transform tool For exact specifications, see: http://gui.gimp.org/index.php/Transformation_tool_specification Oh yeah, thumbs up for that! :) cut Replace the GimpSizeEntry widget Right now both the code and the UI is a mess. The unit should for example be in the text entry itself instead of in a combo box How about a new type of widget “SizeArea” or somethin' that would remeber value along with entered measurement unit? I know this is a long shot and thing more feasible in vector editing app but still I've been in a couple of situations when I'd love to have such thing. Currently all I can have is widgets that get value and mercilessly convert it to default units no matter what. I think it would be cute if such widget could hold equation leading to some answer e.g. “2 * .25 in + 6 in”. It would display then “6.5 in” but it would allow to correct equation if clicked upon. “.25” could be for example bleeds. cut Slicing tool One of the most requested features by web designers and/or interface designers, is the addition of a slice tool. Currently slicing images inside GIMP can only be done in grids (using guides and the guillotine action) and you can't split just one rectangle in the middle. For example, the following slice can not be achieved: --- ||| ||| ||| ||| -|| ||| --- Am I the only one who feels that current notion of slices is well… a bit retarded? I'm often in a position when I've got to make slices that are overlapping or take only some selected layers into account when producing output images. In such cases slices like shown and widely implemented are nothing short of being useless. Agreed: the slices type presented make producing “WYSIWYG” sites easy but I don't think they're much use for HTML writers. So, long story short I propose making slices that could look something like that: - | --- | | | | | | | | | | | | --- | | | | | - The biggest would be e.g. background, next (in the terms of size) would be menu and the smallest would be some icon. cut And let me throw in another thing. It's been in my head for some time but now I think it's good to show it to the world. Just in the matter of shear curiosity: I'd like to see some conceptual work/code/working example/whatever about automatically configurable grid processing. It may be more of GEGL project than GIMP one, but I believe still beneficial in the end. Since 3D rendering engines do that, maybe it would work nice in 2D world too. Of course a metric and some kind of benchmark would be needed to decide if sending some part of work over network to another node is beneficial. Anyway I think it have chances to make things snappy even on slow machines. I see it as a something between freakin' fat workstations, thin clients with some heavy “mother goose” and mighty cluster. It would (hopefully ;)) help to use what is at hand more optimally. Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
On Sun, 2011-02-13 at 18:55 +0100, Martin Nordholts wrote: On 02/13/2011 12:04 AM, LightningIsMyName wrote: I'm starting this thread to list ideas for Google Summer of Code 2011, for the GIMP project. Since in the last year collecting ideas was done partially by the mailing list, let's try it again this year and keep most ideas here. Thanks for a good start on this Barak I would like to add: Port UI code to a non-low level language Hacking UI code in C is a resource eater for us, we should use C for quick and efficient pixel processing but not for creating buttons. It would be interesting to make changes to the GIMP codebase that would allow us for example write the Pointer Information Dialog in JavaScript. We (or actually you) added support for defining plug-in dialog UIs using GtkBuilder some time ago. But there has been no progress on this since then. As far as I can see there is still no support for using GIMP specific widgets from GtkBuilder and no other plug-ins have been ported yet. Perhaps that would be an area that should get some attention from a GSoC developer. Definitely sounds more useful to me than introducing Javascript to GIMP. I somewhat doubt that we would get more developers hacking on the core if we added JS as another entry barrier. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
On Sun, 2011-02-13 at 08:26 +, Michael Grosberg wrote: Automatic layer Boundary management. In essence just let the program deal with layer boundary - expand it whenever a layer is moved so that you can ALWAYS paint on any area you wish. If there's some memory or files size issue, perhaps add some automatic layer cropping on save. I want to stress that such a feature is really, really, useful. I believe there are some cases (scripts, maybe?) in which manual layer boundary management is necessary, so it should be just an option or something that can be deactivated temporarily. Note, when I suggested that gimp should always start with a blank canvas, ready to paint on, people said it was impossible because they didn't know how big to make the default document. Why it couldn't be an option (e.g. if you normally work on indexed or greyscale images) or a template, I couldn't figure out, but this would remove that objection at least. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
LightningIsMyName lightningismyname at gmail.com writes: I'm starting this thread to list ideas for Google Summer of Code 2011, for the GIMP project. Since in the last year collecting ideas was done partially by the mailing list, let's try it again this year and keep most ideas here. Automatic layer Boundary management. In essence just let the program deal with layer boundary - expand it whenever a layer is moved so that you can ALWAYS paint on any area you wish. If there's some memory or files size issue, perhaps add some automatic layer cropping on save. I want to stress that such a feature is really, really, useful. I believe there are some cases (scripts, maybe?) in which manual layer boundary management is necessary, so it should be just an option or something that can be deactivated temporarily. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
On Sat, Feb 12, 2011 at 11:31 PM, Liam R E Quin l...@holoweb.net wrote: On Sun, 2011-02-13 at 01:04 +0200, LightningIsMyName wrote: Integrate vector layers with gegl GEGL already has all the support for rendering vector layers, so it is a case of adding the code to deal with as part of the nodes in the projection. Thus doing work on this would not really be possible until compositing the layers using GEGL is the default (or only) way this is done by GIMP. Better HDR support - e.g. aligning layers, (I think there may be patents on the various hugin algorithms for combining images though) Through gsoc last year, GEGL already has operations to combine multiple exposures into a HDR image as well as operations for tonemapping HDR images to standard dynamic range. Thus this is a task mostly about integrating UI bits with GIMP, once the drawables in GIMP are (and are backed by) GeglBuffers. /Ø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] Google Summer of Code 2011 - Project Ideas/Suggestions
On 2/13/11, LightningIsMyName wrote: Slicing tool One of the most requested features by web designers and/or interface designers, is the addition of a slice tool. Currently slicing images inside GIMP can only be done in grids (using guides and the guillotine action) and you can't split just one rectangle in the middle. For example, the following slice can not be achieved: --- ||| ||| ||| ||| -|| ||| --- Oh come on, just port Slice tool from gimp-sharp to GIMP. All it takes is rewriting from C# to C + cairofication. *Then*, additionally, someone could rewrite it to work on canvas and save the slicing info in XCF. That's all, really. Adaptive Image Cloning (aka Semaless Cloning) As already stated in #gimp, it's an awesome idea. You only forgot to link to the paper :) http://www.cs.huji.ac.il/~danix/mvclone/ Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
On 02/13/2011 12:04 AM, LightningIsMyName wrote: I'm starting this thread to list ideas for Google Summer of Code 2011, for the GIMP project. Since in the last year collecting ideas was done partially by the mailing list, let's try it again this year and keep most ideas here. Thanks for a good start on this Barak I would like to add: Port UI code to a non-low level language Hacking UI code in C is a resource eater for us, we should use C for quick and efficient pixel processing but not for creating buttons. It would be interesting to make changes to the GIMP codebase that would allow us for example write the Pointer Information Dialog in JavaScript. / Martin -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
On Sun, 2011-02-13 at 15:57 +, Øyvind Kolås wrote: On Sat, Feb 12, 2011 at 11:31 PM, Liam R E Quin l...@holoweb.net wrote: On Sun, 2011-02-13 at 01:04 +0200, LightningIsMyName wrote: Integrate vector layers with gegl GEGL already has all the support for rendering vector layers, so it is a case of adding the code to deal with as part of the nodes in the projection. Thus doing work on this would not really be possible until compositing the layers using GEGL is the default (or only) way this is done by GIMP. Or is _a_ way available even if not the default. Better HDR support - e.g. aligning layers, (I think there may be patents on the various hugin algorithms for combining images though) Through gsoc last year, GEGL already has operations to combine multiple exposures into a HDR image as well as operations for tonemapping HDR images to standard dynamic range. Thus this is a task mostly about integrating UI bits with GIMP, once the drawables in GIMP are (and are backed by) GeglBuffers. So it would make a good project, and fits within the Grand Vision. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ On the Internet no-one can touch your feet. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
On Sun, 2011-02-13 at 01:04 +0200, LightningIsMyName wrote: a couple of comments Make menus searchable ... i.e. have a textbox, in te menu for example, and anything typed will be matched against all menu items and their blurbs and maybe something more (like procedures not registered in menus). I still think the right way to do this is to have all the menus constructed through scripting, or at least to have ways to override and inspect all the menus from scripting. Implement the free transform tool For exact specifications, see: http://gui.gimp.org/index.php/Transformation_tool_specification (may be offline at the moment) It had better not be :-) Let me know if there are problems with it. [...] -- Porting GIMP plugins to GEGL operations Implementing a compatibility framework to run older plugins and scripts once gegl is in place might be the best way to go here. Think of all those scripts on the gimp.org Web site... Adaptive Image Cloning (aka Semaless Cloning) Sounds interesting. I'd add maybe Macro recording (actions), possibly with pop-up dialogue boxes to ask for values; Font selection using tags (preferably compatibly with fontmatrix and inkscape at least) Undo/redo/again Integrate vector layers with gegl Better HDR support - e.g. aligning layers, (I think there may be patents on the various hugin algorithms for combining images though) Fractal image upscaling (required by many stock agencies these days) PhotoShop CS6 :-) import/export But right now, some of the most important areas are (1) single window mode design and implementation and subsequent redesign :-) (2) ability to do at least basic 8bit-per-channel processing, preferably using gegl (3) user interface design for everything else -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
On Sat, 2011-02-12 at 18:31 -0500, Liam R E Quin wrote: On Sun, 2011-02-13 at 01:04 +0200, LightningIsMyName wrote: a couple of comments Make menus searchable ... i.e. have a textbox, in te menu for example, and anything typed will be matched against all menu items and their blurbs and maybe something more (like procedures not registered in menus). I still think the right way to do this is to have all the menus constructed through scripting, or at least to have ways to override and inspect all the menus from scripting. The menus are defined in XML files which bind code-defined actions to menu items. This stuff if fully introspectable and an experienced GIMP coder can hack up a usable menu search in one day. Hardly a GSoC project that would keep a new GIMP hacker busy for longer than two weeks. Tumbs down from here. As to creating menus by scripting, I really don't see what would be the purpose of that. The way we construct menus is completely to GTK+ standards, with some GIMP specific additions. Overriding menus from scripts feels like over-configurability to me and hardly like a way to foster usability. ciao, --mitch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
