Re: [Gimp-developer] GSOC 2013 - n-point image deformation
The reason the cage tool is slow is that a set of coefficient is computed and used to deform every single pixel inside the cage. The plan was indeed to use the poly2tri-C to mesh the cage and move that instead of each pixels. There is not that much work to do that, as most of the code can be reused, and this library is already used in the seamless clone tool. Another thing to look at is the new Free Transform Tool of Krita, wich looks quite awesome: http://krita.org/item/131-free-transform-tool It's based on this paper: http://faculty.cs.tamu.edu/schaefer/research/mls.pdf 2013/3/11 Alexandre Prokoudine > > 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? -- Michael ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] unified transform tool
Add me on this request. Even if you don't generate several texture from a single xcf, you often have a layer with the unwrapped 3D model layout, that you forget to disable every time before exporting. 2013/2/24 Alexandre Prokoudine > On Sun, Feb 24, 2013 at 4:09 PM, peter sikking wrote: > > > meanwhile, I am looking for a new small design project > > to put before my students in a months time. any ideas. > > It seems that folks who create textures for 3D projects really want us > to build advanced features on top of the new save/export model. > > One such feature is mentioned in the GSoC2013 page: being able to > export/overwrite from sets of layers. > > Quoting an artist: > > "It's quite common for texture artists to work with multiple parts of > a texture in the same file. They may for instance have diffuse, spec > and bump all in one xcf or psd file, then they change the visibility > settings of the different layers or layer groups, to save out each > texture type. Being able to define sets, and give them a path and file > format to save to would be quite handy, as once that is set up, you > could literally write out all the different parts of you texture at > the push of a button." > > I've heard this request from 2 or 3 people. That is not a significant > sampling, but the feature will be handy to at least two more groups of > users: > > - web designers (keep design variations in a single file, export all) > - photographers (use global mask for different processing variations, > export all variations to different files) > > Alexandre Prokoudine > http://libregraphicsworld.org > ___ > gimp-developer-list mailing list > gimp-developer-list@gnome.org > https://mail.gnome.org/mailman/listinfo/gimp-developer-list > -- Michael ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] contribution processes...
> > I really have no special opinion on that. I am, however, concerned > about "People can propose patch for the spec without need to have an > account." -- that smells like a welcome sign to spammers. And that's, > as far as I can tell, the only reason we have user registration by > request at wiki.gimp.org and gui.gimp.org. No, that mean that since the wiki IS a Git repository, an alternate way of editing it is to clone this repository and do some commits. That way, people without registration can still work on it and propose a patch. No risk of spam because someone with a valid access still need to accept the changes. -- Michael ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] contribution processes...
I completed the "How to port" section in the wiki. I have a suggestion, what about using a Git based wiki like Gollum ( https://github.com/github/gollum) to host the UI specifications ? This is the wiki system used on Github. It works the same as a classic wiki, but all the data are stored in a Git repository. It would allow: - Still easily usable by non-developers - Facilitate the interaction with the developer team, by having change on the wiki reported in real time in the IRC channel. - People can propose patch for the spec without need to have an account. - Gollum understand the Mediawiki syntax, so the migration should not be too difficult (I never used Gollum though) - UI designer can use website like http://www.ohloh.net/ to track their work and get a more visible recognition. My 2 cents. 2012/5/13 peter sikking > yahvuu wrote: > > > some food for thought from the mozilla folks who have a proud track > record of successful open design: > > I am not that familiar with the mozilla processes (although do I > know the guys from the agency Silver Orange who are/were simply > contracted to design mozilla software, all of it). > > ‘proud track record of successful open design’ > > that is quite a claim. anywhere visible on the net how that works? > > I looked carefully at the 3 links you sent. > > > bugzilla keywords like 'uiwanted' may be useful. Complete list available > here: > > https://bugzilla.mozilla.org/describekeywords.cgi > > yes, already thinking how the new process will integrate with > bugzilla is useful. however I want to avoid that things > needing UI design become a blocking state in bugzilla. > > > Open Design: Five Lessons > > http://www.azarask.in/blog/post/open-design-four-lessons/ > > I can only call this open design in this way: > Sebastiaan de With designed a new logo for Ubiquity. > he did this in the open. they got a lot of ideas and feedback. > then Sebastiaan did all the heavy design work. > > this is how interaction has been designed up to now in GIMP. > for instance: save + export. in the open, loads of feedback > (that made it significantly better) and I did all the heavy > design work. > > what I am trying now is to get beyond that. new, fresh contributors > that can contribute a snippet (or more) of interaction design > without demanding that they are actually interaction designers, > or follow established interaction design processes. > > >--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 > http://mail.gnome.org/mailman/listinfo/gimp-developer-list > -- Michael ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] An update on the menu search
I also think that it does not collide with the product vision. Even a professional user need to learn a tool before using it. Also, I know a lot of people that see GIMP as an enhanced MS Paint, because what GIMP is capable of is not obvious. The menu search allow to answer the question "what can I do with X (layer, selection, image ..)", without needing to search in all the menu. Also, I think you really should display the keyboard shortcut next to the name of each item. It would allow to learn easily these shortcut, to use them later at high speed. My 2 cents. 2012/3/11 Srihari Sriraman > the above requires that GIMP is a tool that gets out of the way > > ...your tool is the opposite of that... >> ...you get right in the way. > > > Very true. We din't have this perspective. > Using keyboard shortcuts indeed gives the 2 operations per second thats > required in production environments. > > However, I guess the video has been a little misleading... > The manner and frequency in which this tool is used, is up to the user. > i.e, the tool is meant to be complementary. It is not meant to be a > substitute for keyboard shortcuts. > So, a power user would be experiencing a smooth workflow (which GIMP > clearly provides) and this tool would help him when he's either stuck or > trying to find something. (i.e, help/explore/documentation) > > "Almost forget that there is a menu-bar" > > > This anyhow, remains true. > > tick-tick-tick-tick > > > So beautifully put. I've quoted this to a few people already! :) > The menu search tool will not give this speed. > > Talking about increasing productivity, we've had ideas of extending the > concept to offer a command execution. > Wrt > http://www.gimpusers.com/forums/gimp-developer/13823-fw-suggestion-for-new-versions-of-gimp#message63546 > that > is. > This perhaps, would really mean "maximising productivity". > > > > > On Sat, Mar 10, 2012 at 12:41 AM, peter sikking wrote: > >> Srihari Sriraman wrote: >> >> > can you give a statement what this is suppose to achieve. >> > >> > Maximize productivity >> > Almost forget that there is a menu-bar. Use the mouse/touchpad lesser. >> >> I accept the 3 points you write below, it is that >> help/explore/documentation system I can see in this. >> >> but the statement above? you do realise what GIMP is being >> (re)designed for, no? it is for serious image manipulation, >> seriously creative working and for production environments. >> >> a lot of this work is hands-on on the canvas, in the context of the >> graphics on the canvas, which are not like vector graphics or files >> in a browser something that can be keyboard transversed. >> >> the above requires that GIMP is a tool that gets out of the way, >> by being visceral, part of motor memory. you tool is the >> oposite of that, by users having to formula what they want >> and type (part) in to get a query going then scan the results >> and pick one, you get right in the way. >> >> GIMP also requires that everything designed for it can support >> working at a speed of 2 operations per second. just for a moment >> say tick-tick-tick-tick-etc. at that speed. I do it every time >> I bring this up in a lecture or when I teach interaction design. >> it gets the point across right away. >> >> so I have given you now 2 concrete requirements in a GIMP >> context how you can prove the phrase "Maximize productivity." >> one is even quantitate, which is rare in user interaction design. >> >> tell me how you meet them. if you don't, you are providing >> anti-usability. (that is apart from the help/explore/documentation >> system below:) >> >> > Intent driven rather than hierarchy driven navigation >> > Focus on 'what' rather than 'how'. >> > Discover functionality >> > For new users >> > Help transition >> > From proprietary software. "What is 'smth' in GIMP?" >> >> sorry to spoil the party, but to see how think this is a good thing, >> when it can be so treacherous, is quite dangerous. >> >>--ps >> >>founder + principal interaction architect >>man + machine interface works >> >>http://blog.mmiworks.net: on interaction architecture >> >> >> >> > > > -- > * > * > *Regards, > * > *Srihari Sriraman > * > > > > ___ > gimp-developer-list mailing list > gimp-developer-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gimp-developer-list > > -- Michael ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] How to get the data out of boundary in area-filter-operations of GIMP?
Hi, As far as I know, the returned value is currently set to 0x00, but you can check that easily. I did some work to be able choose this behavior, but it's not ended yet. This work in the abyss branch in git. More details here: https://mail.gnome.org/archives/gegl-developer-list/2011-October/msg3.html If you would like to complete this work, please go ahead. Best Regards, 2012/3/1 Zhang Peixuan > Hello all, > > > > In GIMP,the area-filter-operations always get more pixel data out of the > input buffer's extent, then output the processed data. > > So, how the pixel datas out of extent are gotten in gegl-buffer-set and > gegl-buffer-get ,maybe they are all set 0x00, or another setting method?? > > such as: > > gegl_buffer_get(input_buffer, 1.0, src_rect, format, > in_data,GEGL_AUTO_ROWSTRIDE); > > if src_rect is larger than input_buffer->extent ,what data will be stored > in in_data? What is the machanism? > > > > Now our progress is slow ,because of the problem. So,can anyone help us > explain it? > > We're so glad to receive any advice from you! > > > > Thanks a lot! > > ___ > gimp-developer-list mailing list > gimp-developer-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gimp-developer-list > > -- Michael ___ gimp-developer-list mailing list gimp-developer-list@gnome.org http://mail.gnome.org/mailman/listinfo/gimp-developer-list
