Request for review / progress updates
Hey guys, I finally got around to writing a draft of the proposed plugin system. You'll find this work in the 'io' branch at http://github.com/stefanv/scikits.image It's still a work in progress, but I welcome all comments. Example plugins are 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.... I've merged Ralf's colour space conversions, as well as his code coverage enhancements. Ralf is now documenting the coverage process and will also look at improving the execution time of the slow filter tests. For OpenCV, Chris wrote a docs-decorator that now provides us with links to the OpenCV online reference: http://stefanv.github.com/scikits.image/api/scikits.image.opencv.html#cvlapl... He added more functions to the cv module, and is busy implementing some checks to make sure that even slices out of ndarray's may be passed to OpenCV, whenever possible. Tony Yu (welcome!) did some work on loading paletted images. I'll be sure to review those changes tomorrow. Have yourselves a splendid weekend! Cheers Stéfan
Hi Stefan, 2009/10/31 Stéfan van der Walt <stefan@sun.ac.za>
Hey guys,
I finally got around to writing a draft of the proposed plugin system. You'll find this work in the 'io' branch at
http://github.com/stefanv/scikits.image
It's still a work in progress, but I welcome all comments. Example plugins are
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. Cheers, Ralf
2009/11/1 Ralf Gommers <ralf.gommers@googlemail.com>:
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
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 <stefan@sun.ac.za>:
2009/11/1 Ralf Gommers <ralf.gommers@googlemail.com>:
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 <sccolbert@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.
Chris
2009/11/1 Stéfan van der Walt <stefan@sun.ac.za>:
2009/11/1 Ralf Gommers <ralf.gommers@googlemail.com>:
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
On Sun, Nov 1, 2009 at 2:53 PM, Chris Colbert <sccolbert@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@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@sun.ac.za>:
2009/11/1 Ralf Gommers <ralf.gommers@googlemail.com>:
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 <ralf.gommers@googlemail.com> wrote:
On Sun, Nov 1, 2009 at 2:53 PM, Chris Colbert <sccolbert@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@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@sun.ac.za>:
2009/11/1 Ralf Gommers <ralf.gommers@googlemail.com>:
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
participants (3)
-
Chris Colbert -
Ralf Gommers -
Stéfan van der Walt