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