Re: [Gimp-developer] Introduction Questions about GSoC2009 Idea: Plugin for image segmentation
Hi Thiago, I agree that we should first merge the GSOC code from this year before we start thinking of a new segmenter. Let me know if you need any help. However, I think both a graph-cut-based segmenter and SIOX could have a place in GIMP side-by-side. Graphcut-based segmenters and SIOX have different complementary properties. It is going to be a GUI challenge though because it requires expert knowledge to know when to use which. I do believe that using both algorithms could be a nice solution. In fact, it was my original proposal and I am willing to try to merge both methods. Except the main issue is that it would require expert knowledge to know which one to use. I think the challenge is to provide the user with a nice way of switching between the two. This will become even more complicated once the detail refinement brush is implemented in the main branch to deal with border inaccuracies. Thiago: I can give you a couple of pictures that you should try with your segmenter and then compare against SIOX... especially those with a lot of texture and semi-transparent layers. The new version of SIOX can cope with them very well. Graph-based segmentation algorithms can't because they look for a minimum cut, which is a problem because especially those highly complicated pictures require a lot of time to do manually. I would be very glad if you could provide me some of these examples, because it would really help me with my research. Also, I would like to state that our approach is *not* based on the min-cut/max-flow algorithm, so it does not suffer with many of its drawbacks. Right now my current job is to deal with soft segmentation in an attempt to cope with the transparency issue, and we already have some good solutions. First: Try any image that works well and add 80% noise. SIOX is pretty good with noise. Last time I tried Grabcut with such an image, I got a segmentation fault... Then: Try images like this one: http://www.bigfoto.com/themes/nature/winter/tree-winter-village.jpg and try to extract the tree. The current GIMP version in the main branch cannot do it, the version from last Google Summer of Code can do it. Graph-based algorithms usually have problems but I think this is an important feature because it saves HOURS of work to be able to do it semi-automatically! Gerald -- Dr. Gerald Friedland International Computer Science Institute 1947 Center Street, Suite 600 CA-94704 Berkeley, USA http://www.gerald-friedland.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Introduction Questions about GSoC2009 Idea: Plugin for image segmentation
Hi all, I agree that we should first merge the GSOC code from this year before we start thinking of a new segmenter. Let me know if you need any help. However, I think both a graph-cut-based segmenter and SIOX could have a place in GIMP side-by-side. Graphcut-based segmenters and SIOX have different complementary properties. It is going to be a GUI challenge though because it requires expert knowledge to know when to use which. Thiago: I can give you a couple of pictures that you should try with your segmenter and then compare against SIOX... especially those with a lot of texture and semi-transparent layers. The new version of SIOX can cope with them very well. Graph-based segmentation algorithms can't because they look for a minimum cut, which is a problem because especially those highly complicated pictures require a lot of time to do manually. Gerald -- Dr. Gerald Friedland International Computer Science Institute 1947 Center Street, Suite 600 CA-94704 Berkeley, USA http://www.gerald-friedland.org -- On Sun, Feb 28, 2010 at 5:54 PM, Thiago Spina thiago.sp...@gmail.com wrote: Hey guys, sorry about the delay. It's been a bit of a busy week. On 21 February 2010 14:05, Sven Neumann s...@gimp.org wrote: Did you compare against SIOX as in the master branch or against the improved version that resulted from last year's GSoC ? It would also be interesting if you could benchmark your algorithm using the benchmark proposed in GrabCut: interactive foreground extraction using iterated graph cuts published in the Proceedings of the 2004 SIGGRAPH Conference. There's a Python script shipped with the GIMP source code that does this with the SIOX tool. I compared against both branches and the results were about the same. Regarding the benchmark, on the papers that I mentioned in my first email [1,2] we used the whole GrabCut segmentation dataset considering the F-measure over the groundtruths (because our approach does not use trimaps). The accuracy result was of over 98% on every paper. In fact, on another work [3] seven users segmented a subset with 20 images from the GrabCut dataset, using different pattern classifiers for one stage of our framework, and the results were still above 97.7%. Also, we used the average number of drawn markers as an indication of user interaction, and part of our current approach (described in [2]) required about 5 markers in average (foreground + background). We are currently working on a paper to detail our final framework, because what was proposed on [2] was further improved to make user interaction even more effective and simple, while maintaining the segmentation quality. I made a video comparing what I am going to implement for GIMP (currently on our research software) and the soc-2009-siox-drb branch, which can be seen here: http://vimeo.com/9803589. In my comparison, I used two images from the GrabCut dataset and one from the Berkeley dataset [4] that present increasing degree of difficulty. I believe that the foreground selection tool requires a lot more user interaction for most common images, because it usually does not handle well cases where foreground and background have similar texture/color (as pointed out on the SIOX paper). In my opinion we should at this point concentrate on merging last year's work on the SIOX tool. If we start to add other segmentation methods before this work is merged, then it will become very difficult to ever get the soc-2009-siox-drb branch merged. I agree that it should be a concern to merge that branch, but I think my framework could be released as a minor version in the future. So, it would be nice to have GSoC support for that. [1] - http://portal.acm.org/citation.cfm?id=1700473 [2] - http://www.springerlink.com/content/7415482725175nm7/ [3] - Spina, T. V.; Montoya-Zegarra, J. A.; Andrijauskas, F.; Faria, F. A.; Zampieri, C. E. A.; Pinto-Cáceres, S. M.; Carvalho, T. J. and Falcão, A. X. A comparative study among pattern classifiers in interactive image segmentation. Brazilian Symposium on Computer Graphics and Image Processing, 22 (SIBGRAPI), Oct 2009, IEEE. To appear in IEEE Xplore. [4] - http://www.eecs.berkeley.edu/Research/Projects/CS/vision/bsds/ -- Thiago Vallin Spina MSc student Laboratory of Visual Informatics Institute of Computing -- Unicamp www.liv.ic.unicamp.br ___ 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] GIMP 2.8 schedule
Hi Martin, I am happy to do that. Last time we asked though people said there is no time... I wonder when you tried integrating it? It should definitely compile... Gerald -- Dr. Gerald Friedland International Computer Science Institute 1947 Center Street, Suite 600 CA-94704 Berkeley, USA http://www.gerald-friedland.org -- Sent from Berkeley, CA, United States On Mon, Jan 11, 2010 at 2:11 PM, Martin Nordholts ense...@gmail.com wrote: Gerald Friedland wrote: Hi, I think we owe it to Google that all the Google Summer of Code stuff be put into GIMP 2.8 (or earlier). Hi Gerald If you want the SIOX improvements in 2.8 you should help us integrate it. For me the code on the branch didn't even compile last time I tried. The first step is to merge 'master' to 'soc-2009-siox-drb' so we get a small diff when we eventually merge 'soc-2009-siox-drb' to 'master'. Thanks for any help! Best regards, Martin Nordholts ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A new
Hi, But SIOX is supposed to be more than a selection tool, isn't it? Isn't it about extracting foreground objects? A selection is not enough for that when the foreground consists of transparent pixels. SIOX is a tool to create a selection, nothing more. I don't see what a foreground extraction tool should do besides selecting the foreground. Perhaps you can explain this? Consider a completely red background with a slightly blurred green filled circle in the foreground [1]. If you want to extract the green foreground object you need to get rid of the red in the pixels with both red and green, but you can't do that with only a selection. A good foreground selection tool would need to get rid of the red in the pixels with both red and green and only leave slightly transparent green pixels. Absolutely. And this is exactly what Jenny has implemented as part of the Google Summer of Code. (So until now SIOX was 'only a selection tool' but now it's not anymore -- at least once Jenny's code makes it's way into the main branch) Gerald -- Dr. Gerald Friedland International Computer Science Institute 1947 Center Street, Suite 600 CA-94704 Berkeley, USA http://www.gerald-friedland.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A new
Hi Alex, Background extraction IS indeed tricky. First, different pictures require different tools. Everything where the foreground color is essentially one color, such as drawings will work best with a tool like Magic Wand. The foreground extraction Jenny was improving is intended to be used on photographs and works best when the fotograph features a clearly distinctive foreground but the foreground can easily contain millions of colors and as of now, the foreground can also have very fine structure. There is virtually no tool that can deal with transparencies, reflections, and other nasty stuff. When extracting objects with these issues you have to be lucky. Second, the way to think of these semi-automatic extraction tools is to compare them with a dish washer. Very often, the dish washer will do a good job and clean your dishes. So it'll save you work and it'll be cleaner than if you'd done it manually in the same time. However, for some pieces, the dish washer just doesn't work. Often these are the pieces that are particularly difficult, sometimes though you ask yourself: Why is this glass still dirty -- it's like all the other glasses? So there are people who do not want a dish washer because they want to be in absolute control of the cleaning process. However, would you stop producing, selling, using, and improving dish washers in general, just because they don't work always? The answer is of course: No because in sum they are useful. Same with automatic foreground extraction methods: For some images they save a lot of work, for others they might cause trouble. Some people will never use the tools because they want to be in complete control of the segmentation process. In sum they are useful though. Gerald On Thu, Sep 17, 2009 at 10:57 PM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On Fri, Sep 18, 2009 at 2:34 AM, SorinN wrote: Well, every background extraction is tricky - I tried PhotoshopCS 4 tools - they seems to be trivial to use and seem to be easy - but for a complex task which need a lot of pixel precision you have to do a lot of manually corrections too so the final feelig is a kind of frustration - (with gimp magic wand progresive selection feature [drag over layer left / right], I can do the same thing quicker). Are you talking about http://help.adobe.com/en_US/Photoshop/11.0/WSFD9BA8C5-31BA-4fec-81F3-CF04EE5295FCa.html ? Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Dr. Gerald Friedland International Computer Science Institute 1947 Center Street, Suite 600 CA-94704 Berkeley, USA http://www.gerald-friedland.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A new
Hi Martin, Conceptually, these pictures should work very well with SIOX -- also with the version that is already productively included in GIMP. Of course, individual cases might sometimes be more tricky. What Jenny added is the capability of a soft segmentation. This means segmenting regions where background and foreground might fall into the same pixel because of texture complexity or blurring of the picture. Gerald -- Dr. Gerald Friedland International Computer Science Institute 1947 Center Street, Suite 600 CA-94704 Berkeley, USA http://www.gerald-friedland.org -- On Mon, Sep 14, 2009 at 9:37 PM, Martin Nordholts ense...@gmail.com wrote: On 09/15/2009 03:50 AM, Jenny wrote: Hi all, In this Google Summer of Code season, a new detail refinement brush was done. This page is a demo: http://sites.google.com/site/gsoc2009/result-demo There might still be some bug. I'd love to get any feedback from you. Hi Jenny, Thanks for making that page. Would it be possible to also get a sample how the new SIOX performs for green screens? A zoom in at the edge of the extracted object to show how it handles alpha would also be interesting. These are the kind of pictures I mean: http://images.google.com/images?q=green+screen BR, Martin -- My GIMP Blog: http://www.chromecode.com/ ___ 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] GSoC: good job Michael
Hi Nicolas and all, Melange or not Melange. Michael did a very good job anyways. When you read Leslie's emails on the mentor list you can read about all the problems that other orgs caused by not paying attention. GIMP so far caused none of them and was always well organized. So again: Good job, Michael! Greetings, Gerald On Sun, Apr 19, 2009 at 7:21 AM, Nicolas Robidoux nrobid...@cs.laurentian.ca wrote: I just want to let everyone know that many organizations fell into an unintended trap having to do the Melange software used by Google to manage the application process, trap in which Michael Schumacher, our GSoC admin, did NOT fall. Nicolas Robidoux Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Dr. Gerald Friedland International Computer Science Institute 1947 Center Street, Suite 600 CA-94704 Berkeley, USA Office: +1/510/666-2987 Mobile: +1/510/529-6514 http://www.gerald-friedland.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
Hi Irena, The general answer is: Yes, of course this is interesting. However, please keep in mind that many research papers might not be easily implementable into GIMP in one summer. Many computer vision papers present conceptual ideas rather than algorithms productively usable by an end user. Therefore my suggestion would be to pick one of your suggested papers, create a paragraph or two on what you want to do and propose it to this mailing list. This way, people who are familiar with the concretely affected parts of the GIMP code can tell you what is doable and how. Gerald On Mon, Mar 23, 2009 at 8:55 AM, Irena Damsky irena.dam...@gmail.com wrote: would appreciate a reaction, anyone? On Sun, Mar 22, 2009 at 11:02 PM, Irena Damsky irena.dam...@gmail.com wrote: Hi all, I'm a Msc student of CS in the Inter diceplinery center in Herzliya, Israel. my main interests are image proccesing, image manipulation, computational photography and 2nd computer graphics. from the list of suggested ideas for the GIMP GSoC I saw that the main project suggestions are mainly for GUI and stuff like that, are there any project idea's that involve image manipulation? for example, there had been papers on gradient domain editing, such as http://www.cs.tau.ac.il/~tommer/extra/adv-graphics/pie2003.pdf and I wonder, can something like this, or like colorization by example such as http://www.cs.tau.ac.il/~dcor/online_papers/papers/colorization05.pdf or natural colorization such as http://luanqing1021.googlepages.com/research can something like that become a GSoC project? Thank you! Irena -- Irena Damsky irena.dam...@gmail.com ++972-57-8165528 ++972-52-3294417 you can also find me on MSN: ira_dam...@hotmail.com Smile! and the world will smile with you! Cry! and you'll cry alone... -- Irena Damsky irena.dam...@gmail.com 057-8165528 052-3294417 you can also find me on MSN: ira_dam...@hotmail.com Smile! and the world will smile with you! Cry! and you'll cry alone... ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Dr. Gerald Friedland International Computer Science Institute 1947 Center Street, Suite 600 CA-94704 Berkeley, USA Office: +1/510/666-2987 Mobile: +1/510/529-6514 http://www.gerald-friedland.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A GSoC Purpose: Improve the Performance of SIOX
Hi, Jenny, nice to meet you! I agree with Sven that implementing the Detail Refinement Brush as described on the http://siox.org website would be something that could be done immediately, i.e. without performing extensive computer vision research and would contribute significantly to the improvement of the SIOX tool. Once it is done, there is still room for research, e.g. how to automate the detail refinement brush further and also HCI issues. I am glad to respond to any questions by email and could be a mentor as far as conceptual questions (as opposed to GIMP code structure) are concerned. Gerald On Sat, Mar 14, 2009 at 5:05 AM, Sven Neumann s...@gimp.org wrote: Hi, On Sat, 2009-03-14 at 19:41 +0800, Jenny wrote: I didn't read the code of SIOX and GIMP yet, and be not sure if the features in this page http://www.siox.org/preview.html has been implemented in GIMP's current development version. The Detail Refinement Brush that is mentioned on this page has not been implemented yet. And I'm still not sure if Gerald want to be a mentor in this GSoC Season. I have forwarded your mail to him and asked him if he'd be interested to help us having a GSoC project on SIOX. Please give him some time to respond. He is probably quite busy in his new job at the International Computer Science Institute (ICSI) in Berkeley. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Dr. Gerald Friedland International Computer Science Institute 1947 Center Street, Suite 600 CA-94704 Berkeley, USA Office: +1/510/666-2987 Mobile: +1/510/529-6514 http://www.gerald-friedland.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for better status bar messages (long)
I guessed from what Sven said, inverting the image colors first might help, and I was right. I made my second try by: * Inverting the image * Selecting the entire image in the initial 'lasso' pass. * Disabling 'Contiguous' * Setting L,a,b sensitivity to 0,707,555 respectively. (a,b was just a guess, but L was 0 to accommodate the harsh brightness contrasts of the widgets) * Switching to background mode * Scrawling a bit (~3 strokes) on the windows Overall it was quite straightforward, actually. http://img.photobucket.com/albums/v449/neota/tech/gimp/screenshot-2006-06-21-try2.png (selected areas marked in blueness -- the window 'shadow' got selected, but otherwise it seems quite satisfactory.) .. My experience above causes me to wonder if 'BGselect' could be made by inverting the L*a*b values before interpreting them; maybe something to try after 2.4. I do not quite understand your problems. I am an aloof developer who has serious problems to understand user's problems. Please help me out, maybe I am misunderstanding something? So please do not get me wrong here. What one defines foreground or background is not a matter of the tool but a matter of the human being who is using the tool. I cut out the windows selecting them all with the lasso. See: http://www.gerald-friedland.de/tmp/multiwindow_sel.png Then I disabled contiguos because the Windows in this image are not connected (may be disconnected would be a better string?). Then I needed a few foreground strokes, mainly to select the KDE toolbar (or was it GNOME) and to include all the colors shown in this GIMP tool dialog. The result is then: http://www.gerald-friedland.de/tmp/multiwindow_cutout.png If you want to have the screen-background instead of the windows, use select/invert and you get the background instead of the foreground... No need to fiddle with color sensitivity? Greetings, 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] proposal for better status bar messages (long)
Hi David! As far as I know, foreground and background are still objectively different from the computer's point of view and our point of view; they have different characteristics. A background tends to be less detailed than a foreground; also, the definition of background is further muddied by the possibility of having multiple overlapping objects at different depths. I see your point. The problem is that humans might have an intuition for background although it does not work for all pictures. If there were any objective difference between background and foreground then a foreground selection tool would exist with a hundert percent robustness and nobody would care about extracting manually or even semi-automatically because the entire problem would not exist. One could just use this objective criterion on any image without any user interaction and let the computer do the segmentation (even in batch mode). The reality is that there is no unique definition to distinguish foreground from background in every picture. You can prove this easily: Given a picture that consist of one white pixel and one black pixel. What is foreground now? Four possible answers: - None or Both pixels = No differentiation possible. Thanks, no further argumentation needed. - White = OK. You define all white pixels to be foreground. Given this definition of foreground, I won't have to show you millions of photographs where this definition does not work, will I? - Black. See white. - You give any other definition. This will not apply to the two-pixel checkerboard. = No unique definition for foreground or background exists that works for all all images. Sorry. You clearly understand the tool(and maybe the algorithym too) better than I. However, my basic point is that 'what is not foreground' may mean something quite different from 'what is background'; the only case in which this will be false is when all objects are all at the same depth. In this point you are right. As it is not clear what foreground and background is, it is well possible for a given picture, that a third, fourth, fifth class exists... SIOX is a heuristics and there are several assumptions behind it: 1.) The user wants to extract one object (one connected pixel area) or a set of objects (several connected pixel areas) of similar color structure [=foreground]. 2.) The foreground has an overall different color structure than the rest of the picture [=background]. 3.) The user provides the algorithm with information of the color structure of the background and gives a spatial hint where the foreground may reside. This is done by drawing the first lasso selection. Everything outside the lass is considered background. 4.) The user provides further information on the color structure of the foreground. This is done using the foreground brush marking. Then the SIOX algorithm classifies those pixels that are not background and not part of the foreground marking by comparing their perceptual similarity to these two classes. Further (foreground or background) markings can be added if SIOX' first guess wasn't satisfying. So given the heuristics defined by SIOX, background is the true opposite of foreground. If for some reason it might be hard to extract background with SIOX: Try to extract the foreground and invert the selection. However, because no unique definition of background or foreground exists, there will always be images where any automatic foreground extraction fails (even the one working in our brains). The good thing about SIOX is that it works better for more images than the other extraction tools that I know. 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
* 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
[Gimp-developer] Re: [Gimp-user] `Bucket fill' ..
I think his problem is that he is trying to bucket fill a natural
image. This doesn`t really work as there are too much colors in
natural images and thresholding doesn`t really work (for example,
try to bucket fill a gradient).
However, this gets me to an idea: We could build a natural bucket
fill tool by reducing the colors using color clustering from SIOX and
then fill. The color reduction would have to be much more radical,
like with limits={5,5,10} or even higher values. I guess it has to be
user controllable at the end... but this is something that I miss in
every image manipulation program. Maybe we can put this on the task
list.
On 3/27/06, Sven Neumann [EMAIL PROTECTED] wrote:
Hi,
John Eadie [EMAIL PROTECTED] writes:
For instance, how can you make the bucket fill tool actually do
anything?
Point and click ?!
Seriously, your question doesn't make a lot of sense to me. The tool
should just work. If it doesn't, you should perhaps describe what
exactly you are trying to do and how.
Sven
___
Gimp-user mailing list
Gimp-user@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
--
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] GimpCon dates
Hi!
As I said, I am looking forward to come. I could give a talk about
siox - whatever people want to hear about it.
Regards,
Gerald
On 9/13/05, David Odin [EMAIL PROTECTED] wrote:
Hi,
The dates for the next GimpCon are march 17h-18th-19th 2006.
Please have a look at http://wiki.gimp.org/GimpCon and confirm if you
will come as soon as possible,
Cheers,
DindinX
--
[EMAIL PROTECTED]
D[4],n,d,*T,l,L;main(i,v)char**v;{if(i3)return;L=atoi(v[1]);l=atoi(v[2]);T=
alloca(4*L*l);while(nL*l){for(i=D[d];i(d1?l:L)-D[d^2];i++)T[!d?i+L*D[1]:d
2?L-D[2]-1+L*i:d3?-i-1+L*(l-D[3]):*D+L*(l-i-1)]=++n;D[d=++d3]++;}while(n)
printf(--n%L?%5d:%5d\n,*T++);}
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
--
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
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Multiple Selections for a Gimp-Plugin
Dear Gimp-Developer-Community! I am new to this list and also to Gimp development so please excuse me if this question is trivial or out-of-topic. We have developed a foreground extraction algorithm that improves substantially over Magic Wand (Photoshop) and also the tool that is inside GIMP. It could be compared to Microsoft Grabcut, but it is a lot faster because our approach was originally intended for video segmentation. A Java 1.4 based demonstration Applet can be found at: http://kazan.inf.fu-berlin.de/echalk/Segmentation/ I want to make this available as a GIMP Plugin, but my problem is that (as you can see in the demonstration) sometimes it requires the user to make multiple selections (region of interest and several foreground samples). I just cannot figure out how to model this in GIMP, as it seems to allow only one selection per Plugin-call. Any help out there from experienced Plug-In or Gimp-developers? Regards, Gerald Friedland -- Gerald Friedland Raum 164 Tel: ++49 (0)30/838-75134 Freie Universität Berlin Takustr. 9 http://www.gerald-friedland.de Institut für Informatik 14195 Berlin [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
