Re: [Gimp-developer] Painting with xinput device strange behavior
afterall I fixed it by posting Button event with valuators in driver 於 2010年02月28日 20:59, Sam Lin 提到: yes I tried git version and it works nice with disabling event-history. but still can't find how to make the driver work under enabling event-history. Thanks, Sam 於 2010年02月28日 20:01, Alexia Death 提到: History buffer is triggered on high loads when tablet produces more events than can be handled. I think motion buffer is not the same as history buffer. all I can recommend is to try git gimp and play with the history buffer switch in the gimpc file to see if my guess is right. On Sun, Feb 28, 2010 at 2:18 AM, Sam Linitrs@gmail.com wrote: I checked wacom driver and can't found anything noticable. Both wacom and my driver set motion buffer size 0. I noticed that the strange behavior happens with relative high cpu load. Sam 於 2010年02月26日 16:08, Alexia Death 提到: On Fri, Feb 26, 2010 at 9:09 AM, Sam Linitrs@gmail.com wrote: Hi Alexia, I don't know much about the history buffer filling. Would you please share some doc on how to fill it in driver ? Im not a diver developr so I dont have the information you need... You can take look at how wacom does it. Las I checked they did it right. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] observations about the git version
1. Shrink wrap, up to version 2.6 on Ctrl+E, then on Ctrl+R, is now on Ctrl+J. 2. Right-click in the image window no longer does anything. 3. When you open an image narrower than the menu bar, it is now flushed to the left of the canvas, instead of being centered. Just to be sure that all this is on purpose... -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] observations about the git version
On Tue, 2010-03-02 at 13:35 +0100, Olivier wrote: 1. Shrink wrap, up to version 2.6 on Ctrl+E, then on Ctrl+R, is now on Ctrl+J. Intentional. 2. Right-click in the image window no longer does anything. Works just fine here. 3. When you open an image narrower than the menu bar, it is now flushed to the left of the canvas, instead of being centered. Bug, will be fixed. ciao, --mitch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] enhancement: warnings instead of fatal error for duplicate calls to gimp_env_init
Yes, I will submit a proper patch. I'm new but I can figure it out. I mainly wanted to get feedback whether it was desirable. I'm not clear when a discussion of an enhancement should move to Bugzilla. More testing reveals other issues and test cases: First, most plugins have unguarded calls to register(), so importing some plugins from a plugin ends up reregistering a plugin, with a warning to stderr from the Gimp PDB but apparently harmlessly. I'm still exploring, eg whether the order in which plugins are loaded matters, whether the warning is only for local plugins, whether Gimp supports multiple registrations of different plugins from the same Python source, etc. Second, what paths to plugins are set when a plugin is invoked? Apparently only to local plugins, and not to plugins distributed with Gimp. So to import a distributed plugin from any plugin requires the importing plugin to extend the path. Not difficult but annoying. On Tue, 2010-03-02 at 08:49 +0100, Sven Neumann wrote: On Sun, 2010-02-28 at 17:18 +, Omari Stephens wrote: On 02/28/2010 02:43 PM, lloyd konneker wrote: ::snip? SNIP!:: Here is proposed addition for plug-ins/gimpmodule.c in pygimp_main() that I have lightly tested. Note it raises a warning (Python prints warning on stderr once, on the second call), not an exception. Note it compiles with a C90 warning about mixing declarations and code. Just move the variable declaration to the top of the function. We should strive to make the codebase compile with as few meaningful warnings as possible. Also, is that proper code style? No, it isn't. First of all, a gboolean should be used instead of an int and the code should use the macros TRUE and FALSE. And of course it should follow the GIMP coding style guidelines. We can certainly adjust the few lines ourselves. But it would make our life easier if you could submit a proper patch. Thanks, Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Saving settings for a plug-in
Greetings, A plug-in I'm currently developing may require writing a small file somewhere to save its 'last-used' and 'default' settings: those settings can theoritically use lots of memory (typically just a few bytes though), so I need to allocate the appropriate amount of memory everytime the plug-in is run. I was wondering if it is ethically correct for a plug-in to save such a file, and if so, what would be the best directory to save said file to. Thank you! François Gingras ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Saving settings for a plug-in
Other plugins that save things go to the user profile directory root (.gimp-2.6). For example, I have: focusblurrc pspirc Check the source of any of these for examples. Alternately, if there is not much data, you could use parasites. some plugins also create/require a subdirectory under the plugin installed directory where things like presets are saved. An exmpl of this is mathmap or felimage. -Rob A On Tue, Mar 2, 2010 at 11:16 AM, François Gingras francois.gingra...@ulaval.ca wrote: Greetings, A plug-in I'm currently developing may require writing a small file somewhere to save its 'last-used' and 'default' settings: those settings can theoritically use lots of memory (typically just a few bytes though), so I need to allocate the appropriate amount of memory everytime the plug-in is run. I was wondering if it is ethically correct for a plug-in to save such a file, and if so, what would be the best directory to save said file to. Thank you! François Gingras ___ 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] enhancement: warnings instead of fatal error for duplicate calls to gimp_env_init
On Tue, 2010-03-02 at 08:01 -0500, lloyd konneker wrote: Yes, I will submit a proper patch. I'm new but I can figure it out. I mainly wanted to get feedback whether it was desirable. I'm not clear when a discussion of an enhancement should move to Bugzilla. More testing reveals other issues and test cases: First, most plugins have unguarded calls to register(), so importing some plugins from a plugin ends up reregistering a plugin, with a warning to stderr from the Gimp PDB but apparently harmlessly. I'm still exploring, eg whether the order in which plugins are loaded matters, whether the warning is only for local plugins, whether Gimp supports multiple registrations of different plugins from the same Python source, etc. I wonder if importing a plug-in from another plug-in is really something that we want to support. If the goal is to share code, then perhaps the code that is worth sharing should be factored out into a Python module that the plug-ins can import. Sven ___ 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
On 2 March 2010 04:56, Sven Neumann s...@gimp.org wrote: The current code is prepared for multiple algorithms as backend for the segmentation tool. It's not foreseen that you switch between algorithms, but that you pick one, but even that could probably be changed. As there is currently only the SIOX backend, there's no choice of algorithm exposed in the user interface. But it wouldn't be too difficult to add a toggle or combo-box for that. The question is how much does the user interaction depend on the chosen algorithm? My algorithm is quite flexible about that. For instance, the lasso + markers used for SIOX could be the form of interaction chosen for IFT (I would only need to select a set of foreground and background pixels as initial markers), although I think that showing the pre-segmentation and selecting markers is helpful and more simple. Then, maybe both algorithms could run in parallel and the results would be somehow merged. For most cases (highly textured images, similar foreground and background, variation in illumination, multiple objects, etc.) our algorithm works fine. However, to solve the transparency issue I am doing some experiments on a solution which is similar to SIOX. We currently use a pattern classifier to fuzzy classify all the pixels in order to estimate the arc-weights of the IFT graph. Thus, we form a fuzzy map with values between 0 and 1. This map can be straightforwardly used as an alpha channel, but I'm working on a piece of code which will allow the user to select, after the hard segmentation, markers where the fuzzy map values should be considered. Also, those markers would be used to refine the local fuzzy classification in order to obtain better values, because our current fuzzy classification considers global information (the foreground and background markers on the first iteration). In a nutshell, first the user would do the binary segmentation and then s/he would select where soft values should be computed. Therefore, what I mean is that there will be a nice solution for the transparency problem soon. Thiago -- 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
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
[Gimp-developer] Fwd: Introduction Questions about GSoC2009 Idea: Plugin for image segmentation
Hi Gerald, I believe we were writing emails at the same time, and you didn't get to read my last one. On 2 March 2010 21:49, Gerald Friedland frac...@gmail.com wrote: 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... Here is an example with heavy noise to show that we can cope with it: http://www.liv.ic.unicamp.br/~tvspina/images/flower_noisy_result.png(original: http://www.liv.ic.unicamp.br/~tvspina/images/flower_original.png). Once again, I must say that *we do not use GrabCut nor any graph-cut-based method. *That's why you cannot assume that we have the same weaknesses. In a way we do perform a cut in our graph, but we *do not use the min-cut/max-flow algorithm*. In fact, a paper by a coleague of mine and my advisor [1] proved that the best result graph-cut can achieve is the one IFT already provides. Furthermore, although I do believe that being noise resistant is very important, and SIOX does a very good job at it, I do not think that regular GIMP users would want to segment an image with 80% noise. 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! Given that you probably did not see my previous email, because we exchanged them almost at the same time, you missed the fact that I am working to solve that problem and that I already have a good solution for semi-transparent images. Please refer to my last email for more information. Working with such images is paramount to my research and that problem will not remain unsolved for long. In fact, I believe that within the month or less I should have a good solution ready. Thiago [1] - http://portal.acm.org/citation.cfm?id=1574529 -- 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
