Re: [Gimp-developer] enhancement: warnings instead of fatal error for duplicate calls to gimp_env_init
On Sat, 2010-02-27 at 14:35 -0500, lloyd konneker wrote: This is an enhancement request. Repeated calls to gimp_env_init should yield warnings and not fatal errors. It has benefits for gimp plugins written in Python. Currently gimp_env_init() calls g_error (fatal) if called a second time. Instead, pygimp_main(), which calls gimp_env_init(), should check whether this is a repeated call and issue a warning then return an error. (I'm not sure if any changes are needed for ScriptFu, whether Pygimp should check the return from gimp_main and raise a warning exception, etc.) We would definitely have to change gimp_main() then as it must not be called more than once. I have a bad feeling about doing this change. Currently, you can't import a plugin from another plugin unless the imported plugin guards the call to main() to prevent it from being called unless this is a top level invocation: if __name__=='__main__': main() It could be sufficient to have a convention for plugins to guard the call to main(), but the convention is not usually followed. Or you could have a convention that any shared code needs to be in a separate module from the top plugin module, but again, that convention is not often followed. If you could import a plugin from within a Gimp plugin, then you could share more code. You could use classes etc. from imported plugins. You could also invoke the imported plugin's top function without invoking it as a registered PDB procedure. Neither reason is compelling. Importing a plug-in from within a GIMP plug-in only makes sense for Python. So I would suggest that we seek for a solution that only involves changes to the GIMP Python bindings but does not require a change to libgimp or libgimpbase. I haven't looked at the code, but it should be possible to deal with this in pygimp_main(). Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Painting with xinput device strange behavior
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] Hi, Everybody
Hi Everybody: I'm the new guy to the gimp project!~ Nice to meet you all! ^^ 2010-02-28 GimpHammer ___ 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 Sun, 2010-02-28 at 11:23 +0100, Sven Neumann wrote:
On Sat, 2010-02-27 at 14:35 -0500, lloyd konneker wrote:
This is an enhancement request. Repeated calls to gimp_env_init should
yield warnings and not fatal errors. It has benefits for gimp plugins
written in Python.
Currently gimp_env_init() calls g_error (fatal) if called a second time.
Instead, pygimp_main(), which calls gimp_env_init(), should check
whether this is a repeated call and issue a warning then return an
error. (I'm not sure if any changes are needed for ScriptFu, whether
Pygimp should check the return from gimp_main and raise a warning
exception, etc.)
We would definitely have to change gimp_main() then as it must not be
called more than once. I have a bad feeling about doing this change.
Currently, you can't import a plugin from another plugin unless the
imported plugin guards the call to main() to prevent it from being
called unless this is a top level invocation:
if __name__=='__main__':
main()
It could be sufficient to have a convention for plugins to guard the
call to main(), but the convention is not usually followed. Or you could
have a convention that any shared code needs to be in a separate module
from the top plugin module, but again, that convention is not often
followed.
If you could import a plugin from within a Gimp plugin, then you could
share more code. You could use classes etc. from imported plugins. You
could also invoke the imported plugin's top function without invoking it
as a registered PDB procedure. Neither reason is compelling.
Importing a plug-in from within a GIMP plug-in only makes sense for
Python. So I would suggest that we seek for a solution that only
involves changes to the GIMP Python bindings but does not require a
change to libgimp or libgimpbase. I haven't looked at the code, but it
should be possible to deal with this in pygimp_main().
Sven
That seems reasonable.
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.
if (query == Py_None) {
PyErr_SetString(pygimp_error, a query procedure must be
provided);
return NULL;
}
/* lkk 2010 begin enhancement*/
static int was_called_previously = 0;
if (was_called_previously) {
PyErr_WarnEx(PyExc_RuntimeWarning, main() should only be called
once, 1);
Py_INCREF(Py_None);
return Py_None;
}
else {
/* OK to set this here since following code either succeeds in
initializing plugin, or fails hard. */
was_called_previously = 1;
}
/* lkk 2010 end enhancement*/
___
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 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?
--xsdg
if (query == Py_None) {
PyErr_SetString(pygimp_error, a query procedure must be
provided);
return NULL;
}
/* lkk 2010 begin enhancement*/
static int was_called_previously = 0;
if (was_called_previously) {
PyErr_WarnEx(PyExc_RuntimeWarning, main() should only be called
once, 1);
Py_INCREF(Py_None);
return Py_None;
}
else {
/* OK to set this here since following code either succeeds in
initializing plugin, or fails hard. */
was_called_previously = 1;
}
/* lkk 2010 end enhancement*/
___
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
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
