Re: [Gimp-developer] GSOC-2013
On Mon, Mar 4, 2013 at 11:39 AM, Kim Malar wrote: > Hii, > > I would like to participate in this year's gsoc under gimp. Any help on your > part would be highly appreciated. Plz send me a few bugs that i could start > dissecting and any other pointers would be useful.Thankyou Kim, You can have a look at https://bugzilla.gnome.org/browse.cgi?product=GIMP for the complete list. However, you will probably want to know some specifics, and for that I recommend joining #gimp around evening in a west european timezone. Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] GSOC 2013 - n-point image deformation
Well, I'm not really trained to talk of such things, but one thing worth thinking of is how precise your method is trying to be. One of the reasons why Cage Transform is so slow is that it's trying to be too smart and does too much computation. The plan was to eventually start using poly2tri-C library that implements Delaunay triangulations. Does it ring a bell? I'm sure, Michael Muré can provide much more useful info :) Alexandre On Tue, Mar 12, 2013 at 1:36 AM, Marek Dvoroznak wrote: > I have it currently written in Java and performance on fairly large > images isn't so good. I suppose that in C and with more optimizations it > will be much better. Performance and behavior of the algorithm very > depends on a size of mesh's squares (or triangles). I'll try to do some > performance tests. > > Marek > > On Mon, 11 Mar 2013 18:03:11 +0400, Alexandre Prokoudine wrote: >> So this is more like Puppet Warp really :) And it does look very impressive! >> >> IMHO, it would be a great GSoC project. >> >> How is it performance-wise? How well does it work on fairly large images? ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] GSOC 2013 - n-point image deformation
I have it currently written in Java and performance on fairly large images isn't so good. I suppose that in C and with more optimizations it will be much better. Performance and behavior of the algorithm very depends on a size of mesh's squares (or triangles). I'll try to do some performance tests. Marek On Mon, 11 Mar 2013 18:03:11 +0400, Alexandre Prokoudine wrote: > So this is more like Puppet Warp really :) And it does look very impressive! > > IMHO, it would be a great GSoC project. > > How is it performance-wise? How well does it work on fairly large images? > ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Posibility to filter fonts
On Mon, Mar 11, 2013 at 11:46 PM, Liam R E Quin wrote: > FontMatrix is a Linux font manager packaged for most Linux > distributions. It has a somewhat idiosyncratic user interface and uses > Qt (not sure if it uses KDE stuff too) No KDE stuff. Just Qt, Webkit and SQLite. Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Posibility to filter fonts
On Mon, 2013-03-11 at 16:27 +0100, Anke Lange wrote: > For windows there seems to be a possibility to blend out fonts via > font-manager, FontMatrix is a Linux font manager packaged for most Linux distributions. It has a somewhat idiosyncratic user interface and uses Qt (not sure if it uses KDE stuff too) but you can deactivate fonts with it, and filter by category, name, etc. You could combine it with the possibility GIMP has of a gimp-specific font folder. Note also that the icon in the gimp text tool options at the bottom of the font list lets you bring up a stand-alone font browser. -- 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 freenode/#xml ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp gradients
Alexandre wrote: > On Mon, Mar 11, 2013 at 6:32 PM, peter sikking wrote: > >> it is not only the unified transform tool, although that is the one >> that broke my back, certainly after our Vienna BOF. it is the string >> of these things, and the ‘that’s the way it is’ cheerfulness that >> developers display with it, that is exhausting me. > > AFAIK, the latest issue here was a missing rationale for duplicating > transformation tools (Unified Transform as "feel" tool + separate > "precision" tools). OK, in all craftsmanship, and GIMP is all about craftsmanship and getting there, there is a balance between doing the next task totally free (take a hand tool, start and it will come out 100%) and totally controlled (using jigs). every individual craftsman takes depending on the next task and her/his skills and experience a unique decision. as a tool supplier (GIMP) we we end up aiming for a 50/50 mix of free + controlled. this is for instance a reason why in the paint system we need an equal balance between working with presets (controlled) or knocking up/adjusting setting on the spot (free). it is elementary. you can read much more about this in ‘the nature and art of workmanship’ by David Pye. very thorough. you can read it online at google books. and talking about duplication: we would end up with much less tools: unified transform, rotation and perspective tools. and then we take it from there (now is my time to say that). what about having it ‘all’ in one tool? not what 2 decades of experience in interaction design says. and having designed this tool and actually made the hundreds of decisions in it, I can tell you that not having precision and _useful_ number entry (read that again, not the #$%^&* 3x3 matrix) as requirements made important things possible, like combining all the geometry operations at random, and optimising the free part. > I hope we can work through these different points of view. well, as long as I get shown the middle finger where it comes to implementing the control frame of the tool, I think the situation is completely out of whack here where it comes to interaction design and usability. remember, it is open source: only successful contribution counts. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] Posibility to filter fonts
Hi I'm using gimp for quite a while now, and I thought, I know gimp inside out by now :) So there is a little wish, that most of the users on gimp-werkstatt.de and I have: Would it be possible, to put a filter to the font-dialog, like there is for brushes, patterns an other resources-dialogs? So you can select a specific variety of font. For windows there seems to be a possibility to blend out fonts via font-manager, (Here I got the link to that tutorial --> http://www.support-ing.de/2011-03-02/wie-man-ueberfluessige-schriftarten-aus-windows-entfernt/ ) but it looks like it courses some trouble with some displays in Gimp, like the zoom-Icon on the bottom of the work-window in Gimp. I use Linux, and so I haven't tried that tutorial. It would be great to have a smaller number of fonts to be displayed. Thanks a lot and my apologies for the rotton English Anke -- Anke Lange An der Landwehr 25 49076 Osnabrück Telefon 0541 6004299 gimp-werkst...@gmx.de www.kreativ-workshops.net www.gimp-werkstatt.de www.kompozer-web.de ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp gradients
On Mon, Mar 11, 2013 at 6:32 PM, peter sikking wrote: > it is not only the unified transform tool, although that is the one > that broke my back, certainly after our Vienna BOF. it is the string > of these things, and the ‘that’s the way it is’ cheerfulness that > developers display with it, that is exhausting me. AFAIK, the latest issue here was a missing rationale for duplicating transformation tools (Unified Transform as "feel" tool + separate "precision" tools). I hope we can work through these different points of view. Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp gradients
Michael Schumacher wrote: >> spec writing seems to be a waste of time, competence and enthusiasm >> at the moment. developers simply throw away a third of it and do what >> they want. this pattern has been growing at GIMP over the last years. > > My feeling as only occasional contributor is that it is currently hard > to determine if a spec is fully implemented or not, and if not, what > parts are missing. > > Some specs, like e.g., Save & Export, seem to be next to complete. it is not about incomplete implementation. although that happens, is no fulfilling, but it at least gives a chance of ‘can be taken further, also in the design, next time.’ the problem is complete substitution of a third of the design by developer-made stuff. although the reasons for this may vary—straightforward implementation; ‘I know better’; or the need for tinkering—the result is always the same: a significant shift in the users-tech-project balance, in favour of tech and at the cost of users and the project. > Others, like the Unified Transform Tool, are implemented up to a point > where any further steps felt like removing existing functionality - and > have thus are thus left the tool in an inconsistent state. it is not only the unified transform tool, although that is the one that broke my back, certainly after our Vienna BOF. it is the string of these things, and the ‘that’s the way it is’ cheerfulness that developers display with it, that is exhausting me. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp-plugin profiling
Well, I have a lot of if/then in code, but they are essential. So probably no opportunity here. I will look on the links you provided anyway, thanks... 2013/3/11 Jon Nordby > > Yes, if you have branches in inner loops eliminating them can give > large speedups. > A quick google search gave this reference which looks like an OK start: > > http://software.intel.com/en-us/articles/avoiding-the-cost-of-branch-misprediction > Less branching may also allow the compiler to auto-vectorize more. > If you are unable to remove the branches in your inner loop, you can > try to guide the branch predictor using > GCCs __builtin_expect: > http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html > > Note that not just if/case statements introduce branching, > do/while/for do as well. > > -- > Jon Nordby - www.jonnor.com > ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp gradients
El 11/03/13 11:20, Alexandre Prokoudine escribió: In a nutshell, and that's my personal view, the gradient editing should happen on canvas, much like in Inkscape (0.49 also places numerical input for colors stops position on the tools settings toolbar). And in GEGL-based GIMP a gradient fill should be re-editable. That was my point in my first reply. The tool itself could be extended in the future and the current limitations in gradient editor aren't that critical to justify an overhaul (at least not now). This is also my personal view as a user, but I can live with the current tool waiting for a more flexible, non destructive on-canvas tool. Gez. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp gradients
On Mon, Mar 11, 2013 at 5:43 PM, free wrote: > Well, if I could say something about creating gradients in gimp (as a > regular user), there are some issues that I think that can get the user > confused or frustrated: > > - using right mouse button to change colors and to split segments: > Intuitivelly, I see the right mouse button as "more options" for anything. > Having to access the main funcions of the editor with right mouse button is > strange (and I just discovered it after reading a tutorial). > - not allowing the movement of the endpoints is a little frustrating. If you > want to extend the endpoint color a little, you have to create a new > segment. > - there's a color box in the gradient editor that is only for previewing > colors. It would be great if it could be used to change the selected segment > color. Have to use foreground/background color slows a little the proccess, > i think. > - a numerical input for the position for the segment would be great too, > just like Blender's ramp editor. > > Well, maybe I am missing some functionality here because I never used too > much the gradient editor, as I did not knew the drag and drop from palette > as described here... My apologies if I addressed something that is wrong :) In a nutshell, and that's my personal view, the gradient editing should happen on canvas, much like in Inkscape (0.49 also places numerical input for colors stops position on the tools settings toolbar). And in GEGL-based GIMP a gradient fill should be re-editable. Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] GSOC 2013 - n-point image deformation
On Mon, Mar 11, 2013 at 5:40 PM, Marek Dvoroznak wrote: > Hello, > > I would like to participate in this year's GSOC. As a school project, I > implemented as-rigid-as-possible (and as-similar-as-possible) n-point > image deformation. I've thought it would be useful to have a tool > implementing this in GIMP. I know that at the moment similar effect can > be achieved with Cage Transform tool, but with n-point image deformation > it's much easier. > > I planned to make a plugin implementing this type of deformation as a > part of my thesis, but unfortunately I had to change my thesis' topic. > > Could this be a suitable project for GSOC under GIMP? > > I'm attaching a link to a video clip showing a character deformed using > Cage Transform tool and also using as-rigid-as-possible deformation: > http://youtu.be/ieaHvHAcNRE So this is more like Puppet Warp really :) And it does look very impressive! IMHO, it would be a great GSoC project. How is it performance-wise? How well does it work on fairly large images? Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp gradients
Well, if I could say something about creating gradients in gimp (as a regular user), there are some issues that I think that can get the user confused or frustrated: - using right mouse button to change colors and to split segments: Intuitivelly, I see the right mouse button as "more options" for anything. Having to access the main funcions of the editor with right mouse button is strange (and I just discovered it after reading a tutorial). - not allowing the movement of the endpoints is a little frustrating. If you want to extend the endpoint color a little, you have to create a new segment. - there's a color box in the gradient editor that is only for previewing colors. It would be great if it could be used to change the selected segment color. Have to use foreground/background color slows a little the proccess, i think. - a numerical input for the position for the segment would be great too, just like Blender's ramp editor. Well, maybe I am missing some functionality here because I never used too much the gradient editor, as I did not knew the drag and drop from palette as described here... My apologies if I addressed something that is wrong :) ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp gradients
> Von: "peter sikking" > An: "gimp-developer list" > Betreff: Re: [Gimp-developer] gimp gradients > > Alexandre wrote: > > > I wrote: > > > >> I must say I am thinking of picking either the gradient or align tool > >> as the module for my students to design. > >> > >> both are simply up for grabs. > > > > That would be great if a spec will come out of it. > > > > *cough* selection tool *cough* > spec writing seems to be a waste of time, competence and enthusiasm > at the moment. developers simply throw away a third of it and do what > they want. this pattern has been growing at GIMP over the last years. My feeling as only occasional contributor is that it is currently hard to determine if a spec is fully implemented or not, and if not, what parts are missing. Some specs, like e.g., Save & Export, seem to be next to complete. Others, like the Unified Transform Tool, are implemented up to a point where any further steps felt like removing existing functionality - and have thus are thus left the tool in an inconsistent state. Would it help if the state of the implementation was tracked in the gui wiki itself, by marking paragraphs and sections as implemented or missing? Regards, Michael ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Gimp-developer] GSOC 2013 - n-point image deformation
Hello, I would like to participate in this year's GSOC. As a school project, I implemented as-rigid-as-possible (and as-similar-as-possible) n-point image deformation. I've thought it would be useful to have a tool implementing this in GIMP. I know that at the moment similar effect can be achieved with Cage Transform tool, but with n-point image deformation it's much easier. I planned to make a plugin implementing this type of deformation as a part of my thesis, but unfortunately I had to change my thesis' topic. Could this be a suitable project for GSOC under GIMP? I'm attaching a link to a video clip showing a character deformed using Cage Transform tool and also using as-rigid-as-possible deformation: http://youtu.be/ieaHvHAcNRE Regards, Marek ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp-plugin profiling
On 10 March 2013 22:55, Tibor Bamhor wrote: > Hi, > > Thank for you interest. Today I spent some time reading about perf - it is > quite complex tool or rather it measures things that I am not familiar with. > However I did some primitive testing and got this output: > > 7729.437618_task-clock#0.386_CPUs_utilized__ > ___8556_context-switches__#0.001_M/sec__ > __0_cpu-migrations#0.000_K/sec__ > 899_page-faults___#0.116_K/sec__ > 20346686795_cycles#2.632_GHz_[92.65%] > __0_stalled-cycles-frontend___#0.00%_frontend_cycles_idle[99.92%] > __51284_stalled-cycles-backend#2.89%_backend__cycles_idle[67.69%] > _2234245557_instructions__#0.11__insns_per_cycle > __#0.26__stalled_cycles_per_insn_[71.21%] > __931561726_branches__#__120.521_M/sec___[77.62%] > _1877007958_branch-misses_#__201.49%_of_all_branches_[84.88%] > > I dont dare to interpret it, but the "201.49%" in last line was in red so > there is obviously a problem there. Here I would start. > > If you (or anybody else) can point me at some source on internet I would be > thankfull. Or perhaps shortly explain how to mitigate the problem. But I > understand this is not gimp-specific issue... Yes, if you have branches in inner loops eliminating them can give large speedups. A quick google search gave this reference which looks like an OK start: http://software.intel.com/en-us/articles/avoiding-the-cost-of-branch-misprediction Less branching may also allow the compiler to auto-vectorize more. If you are unable to remove the branches in your inner loop, you can try to guide the branch predictor using GCCs __builtin_expect: http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html Note that not just if/case statements introduce branching, do/while/for do as well. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp gradients
Alexandre wrote: > I wrote: > >> I must say I am thinking of picking either the gradient or align tool >> as the module for my students to design. >> >> both are simply up for grabs. > > That would be great if a spec will come out of it. > > *cough* selection tool *cough* spec writing seems to be a waste of time, competence and enthusiasm at the moment. developers simply throw away a third of it and do what they want. this pattern has been growing at GIMP over the last years. so yes, the student exercises that I publish in my blog are not designs for implementations. that takes more, especially fully experienced interaction designer involvement. so at the moment I am limiting my GIMP activities to parts where the contribution vs. return ratio is worth it. apart from the ‘teaching using GIMP as real software’, I have to figure out where else that is. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp gradients
On Mon, Mar 11, 2013 at 3:20 PM, peter sikking wrote: >>> Gradients in gimp are very very painful thing. Are you >>> planing make gradient tool more user friendly? >> >> Planning would be a too strong word, perhaps, but we do want to >> improve that in the future. > > I must say I am thinking of picking either the gradient or align tool > as the module for my students to design. > > both are simply up for grabs. That would be great if a spec will come out of it. *cough* selection tool *cough* :) Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp gradients
Alexandre wrote: >> Gradients in gimp are very very painful thing. Are you >> planing make gradient tool more user friendly? > > Planning would be a too strong word, perhaps, but we do want to > improve that in the future. I must say I am thinking of picking either the gradient or align tool as the module for my students to design. both are simply up for grabs. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp-plugin profiling
I find it difficult to read perf output so I use https://code.google.com/p/jrfonseca/wiki/Gprof2Dot to create a callgraph. I think branch misses is related to branch prediction https://en.wikipedia.org/wiki/Branch_prediction it's a micro-optimization and difficult to get right. I'm not an expert and don't know if it's worth spending time on that. On Sun, Mar 10, 2013 at 11:55 PM, Tibor Bamhor wrote: > Hi, > > Thank for you interest. Today I spent some time reading about perf - it is > quite complex tool or rather it measures things that I am not familiar with. > However I did some primitive testing and got this output: > > 7729.437618_task-clock#0.386_CPUs_utilized__ > ___8556_context-switches__#0.001_M/sec__ > __0_cpu-migrations#0.000_K/sec__ > 899_page-faults___#0.116_K/sec__ > 20346686795_cycles#2.632_GHz_[92.65%] > __0_stalled-cycles-frontend___#0.00%_frontend_cycles_idle[99.92%] > __51284_stalled-cycles-backend#2.89%_backend__cycles_idle[67.69%] > _2234245557_instructions__#0.11__insns_per_cycle > __#0.26__stalled_cycles_per_insn_[71.21%] > __931561726_branches__#__120.521_M/sec___[77.62%] > _1877007958_branch-misses_#__201.49%_of_all_branches_[84.88%] > > I dont dare to interpret it, but the "201.49%" in last line was in red so > there is obviously a problem there. Here I would start. > > If you (or anybody else) can point me at some source on internet I would be > thankfull. Or perhaps shortly explain how to mitigate the problem. But I > understand this is not gimp-specific issue... > > BTW, I consider my question answered now, thanks :) > > > Tibor ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
