2009/11/1 Ralf Gommers :

...

http://github.com/stefanv/scikits.image/blob/io/scikits/image/io/matplotlib_...

http://github.com/stefanv/scikits.image/blob/io/scikits/image/io/pil_plugin....

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

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 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.

Chris

2009/11/1 Stéfan van der Walt :

...

2009/11/1 Ralf Gommers :

...

...

http://github.com/stefanv/scikits.image/blob/io/scikits/image/io/matplotlib_...

http://github.com/stefanv/scikits.image/blob/io/scikits/image/io/pil_plugin....

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

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 wrote:

On Sun, Nov 1, 2009 at 2:53 PM, Chris Colbert 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 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 :

...

2009/11/1 Ralf Gommers :

...

...

http://github.com/stefanv/scikits.image/blob/io/scikits/image/io/matplotlib_...

http://github.com/stefanv/scikits.image/blob/io/scikits/image/io/pil_plugin....

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