Request for review / progress updates

Chris Colbert sccolbert at gmail.com
Sun Nov 1 09:56:33 EST 2009


I'm working right now on a wxpython plugin that simply displays the
image in a simple panel.

No tools, no menus, just a box with an image.

Obviously, it wont work unless you are in an ipython -wthread session.

I got prototype working, just have to add robustness now.


Stefan, Great plugin framework! Super easy to use!

Chris

On Sun, Nov 1, 2009 at 3:24 PM, Ralf Gommers
<ralf.gommers at googlemail.com> wrote:
>
>
> On Sun, Nov 1, 2009 at 2:53 PM, Chris Colbert <sccolbert at gmail.com> wrote:
>>
>> Ok, so I was tinkering with getting something to work,
>> and I bombed on this c++ exception:
>>
>> OpenCV Error: Unspecified error (The function is not implemented.
>> Rebuild the library with Windows, GTK+ 2.x or Carbon support. If you
>> are on Ubuntu or Debian, install libgtk2.0-dev and pkg-config, then
>> re-run cmake or configure script) in cvNamedWindow, file
>> /home/brucewayne/builds/OpenCV-2.0.0/src/highgui/window.cpp, line 100
>> terminate called after throwing an instance of 'cv::Exception'
>> Aborted
>>
>> since I think this is likely to happen to a bunch of people, and the
>> checks required to fail gracefully would be near impossible, I suggest
>> we dont use OpenCV for an imshow routine.
>>
>> Chris
>>
>> On Sun, Nov 1, 2009 at 1:35 PM, Chris Colbert <sccolbert at gmail.com> wrote:
>> > How do we want to handle the threading/blocking issues that will
>> > result from  various imshow plugins?
>> >
>> > For example, right now, I could write a plugin that uses OpenCV's
>> > highgui to show an image, but if I dont spawn a worker thread, this
>> > will be a blocking function.
>> > If I do spawn a worker thread, I will need to create a wrapper class
>> > in Cython, so that I can __dealloc__ the appropriate gui bits, once
>> > the thread dies.
>> >
>> > Obviously, the former is easier to get running. But which way should
>> > we handle this?
>> >
>> > Maybe we can think about creating our own universal "gui-thread
>> > service", where we pass a blocking function to be executed and
>> > call-back to be executed once that function returns.
>> > The service can then handle the threading a checking.
>> >
>> > Just an idea.
>> >
>
> Just a quick reply, I won't have time for a closer look till tomorrow
> afternoon.
>
> I see imshow as a convenience function to pop up an image. People that want
> more usually prefer to use the functionality of whatever gui toolkit they're
> using.
>
> MPL already has a toolkit-independent framework, and while it is great that
> MPL works with so many toolkits, it is a pain quite frankly to have a mix of
> MPL events and (for example) PyQt events in a GUI app. To put an extra layer
> on top of that is bad idea IMHO.
>
> So I'd prefer just to have the blocking functions without too much magic.
>
> Cheers,
> Ralf
>
>
>> > Chris
>> >
>> > 2009/11/1 Stéfan van der Walt <stefan at sun.ac.za>:
>> >>
>> >> 2009/11/1 Ralf Gommers <ralf.gommers at googlemail.com>:
>> >>>>
>> >>>> http://github.com/stefanv/scikits.image/blob/io/scikits/image/io/matplotlib_plugin.py
>> >>>>
>> >>>>
>> >>>> http://github.com/stefanv/scikits.image/blob/io/scikits/image/io/pil_plugin.py
>> >>>>
>> >>>
>> >>> That looks promising! It all works for me, and it's easy to
>> >>> understand.
>> >>>
>> >>> The one thing I can think of after quickly looking through it, is some
>> >>> convenience funcs to get/set the defaults for the plugin, both for all
>> >>> keywords in plugin_store or for a single keyword. This will help when
>> >>> plugins start to overlap in functionality. I would for example like to
>> >>> be
>> >>> able to set MPL to be the default for showing/saving, and PIL for
>> >>> loading,
>> >>> without having to use plugin='...' each time.
>> >>
>> >> This is now implemented in
>> >>
>> >> http://github.com/stefanv/scikits.image/tree/io
>> >>
>> >> For example, you can do
>> >>
>> >> plugins.use('PIL')
>> >>
>> >> or
>> >>
>> >> plugins.use('PIL', 'show')
>> >>
>> >> Please review so we can merge / work on it some more.
>> >>
>> >> Cheers
>> >> Stéfan
>> >>
>> >
>
>



More information about the scikit-image mailing list