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