From stefan at sun.ac.za  Sun Nov  1 05:49:27 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 1 Nov 2009 12:49:27 +0200
Subject: Request for review / progress updates
In-Reply-To: <dde7764a0910311607l13a5190ax7a42bff548902280@mail.gmail.com>
References: <9457e7c80910311455o40e7439ehe5f7b95da567a8d8@mail.gmail.com> 
	<dde7764a0910311607l13a5190ax7a42bff548902280@mail.gmail.com>
Message-ID: <9457e7c80911010249vc34e3dcq9bd1839bd58fa471@mail.gmail.com>

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


From stefan at sun.ac.za  Sun Nov  1 06:07:10 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 1 Nov 2009 13:07:10 +0200
Subject: reading images in palette mode
In-Reply-To: <CA252399-7B2C-4320-B22C-F10685F3446B@gmail.com>
References: <658358CD-BE2F-45D4-9BD5-ECB0D18AE8D1@gmail.com> 
	<dde7764a0910300831l6fe04780wf14067ba3d62f9b5@mail.gmail.com> 
	<47028081-BAB9-4296-A3CE-569D69299961@gmail.com> <dde7764a0910311048m6d269383vb7ff054af17ad0e6@mail.gmail.com> 
	<CA252399-7B2C-4320-B22C-F10685F3446B@gmail.com>
Message-ID: <9457e7c80911010307x4441608ava571234ac4368e96@mail.gmail.com>

2009/10/31 Tony S Yu <tsyu80 at gmail.com>:
> Looks good overall. I made some minor changes reflecting the comments I made
> above:
> http://github.com/rgommers/scikits.image/commit/a6ad7415d7a43185cea898d3454e087b0b01f105
>
> If you are happy with those, you can pull my palette branch over and send
> Stefan a pull request.
>
> The changes look good. Thanks! Pull request sent.

Thanks, Tony!  I merged your changes into the master branch.

Cheers
St?fan


From sccolbert at gmail.com  Sun Nov  1 07:35:22 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Sun, 1 Nov 2009 13:35:22 +0100
Subject: Request for review / progress updates
In-Reply-To: <9457e7c80911010249vc34e3dcq9bd1839bd58fa471@mail.gmail.com>
References: <9457e7c80910311455o40e7439ehe5f7b95da567a8d8@mail.gmail.com>
	 <dde7764a0910311607l13a5190ax7a42bff548902280@mail.gmail.com>
	 <9457e7c80911010249vc34e3dcq9bd1839bd58fa471@mail.gmail.com>
Message-ID: <7f014ea60911010435o2e483a8cjb34ecbb3c5b5e8c6@mail.gmail.com>

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


From sccolbert at gmail.com  Sun Nov  1 08:53:20 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Sun, 1 Nov 2009 14:53:20 +0100
Subject: Request for review / progress updates
In-Reply-To: <7f014ea60911010435o2e483a8cjb34ecbb3c5b5e8c6@mail.gmail.com>
References: <9457e7c80910311455o40e7439ehe5f7b95da567a8d8@mail.gmail.com>
	 <dde7764a0910311607l13a5190ax7a42bff548902280@mail.gmail.com>
	 <9457e7c80911010249vc34e3dcq9bd1839bd58fa471@mail.gmail.com>
	 <7f014ea60911010435o2e483a8cjb34ecbb3c5b5e8c6@mail.gmail.com>
Message-ID: <7f014ea60911010553r1ae9f102j29beb6d898c85e46@mail.gmail.com>

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


From ralf.gommers at googlemail.com  Sun Nov  1 09:24:25 2009
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Sun, 1 Nov 2009 15:24:25 +0100
Subject: Request for review / progress updates
In-Reply-To: <7f014ea60911010553r1ae9f102j29beb6d898c85e46@mail.gmail.com>
References: <9457e7c80910311455o40e7439ehe5f7b95da567a8d8@mail.gmail.com>
	 <dde7764a0910311607l13a5190ax7a42bff548902280@mail.gmail.com>
	 <9457e7c80911010249vc34e3dcq9bd1839bd58fa471@mail.gmail.com>
	 <7f014ea60911010435o2e483a8cjb34ecbb3c5b5e8c6@mail.gmail.com>
	 <7f014ea60911010553r1ae9f102j29beb6d898c85e46@mail.gmail.com>
Message-ID: <dde7764a0911010624j174349bbteb057757f1be1836@mail.gmail.com>

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
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20091101/3c59ba1f/attachment.html>

From sccolbert at gmail.com  Sun Nov  1 09:56:33 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Sun, 1 Nov 2009 15:56:33 +0100
Subject: Request for review / progress updates
In-Reply-To: <dde7764a0911010624j174349bbteb057757f1be1836@mail.gmail.com>
References: <9457e7c80910311455o40e7439ehe5f7b95da567a8d8@mail.gmail.com>
	 <dde7764a0910311607l13a5190ax7a42bff548902280@mail.gmail.com>
	 <9457e7c80911010249vc34e3dcq9bd1839bd58fa471@mail.gmail.com>
	 <7f014ea60911010435o2e483a8cjb34ecbb3c5b5e8c6@mail.gmail.com>
	 <7f014ea60911010553r1ae9f102j29beb6d898c85e46@mail.gmail.com>
	 <dde7764a0911010624j174349bbteb057757f1be1836@mail.gmail.com>
Message-ID: <7f014ea60911010656j6c78602l31eba3d3f106b936@mail.gmail.com>

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


From sccolbert at gmail.com  Sun Nov  1 19:36:48 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Mon, 2 Nov 2009 01:36:48 +0100
Subject: I/O Plugin infrastructure + wx/qt plugins
In-Reply-To: <9457e7c80911011555i2d1fb22fg7237c2ce9e581b00@mail.gmail.com>
References: <9457e7c80911011555i2d1fb22fg7237c2ce9e581b00@mail.gmail.com>
Message-ID: <7f014ea60911011636x68eed8bbk5bef153643acc1a5@mail.gmail.com>

Just fair warning, the wx plugin still has problems in its current
state, until i can figure out a solution to the threading problem.

As it stands right now in Stefans 'io' branch, you have to run an
ipython session with the -wthread switch in order for the wx imshow
function to work.

This will be fixed hopefully soon....

Chris

2009/11/2 St?fan van der Walt <stefan at sun.ac.za>:
>
> Hi all,
>
> Chris and I have been working towards a more complete plugin framework
> this afternoon. ?Please have a look at
>
> http://github.com/stefanv/scikits.image
>
> in the `io` branch to see what's been done so far. ?You may try the
> new qt or wx image display plugins as follows:
>
> import scikits.image.io as io
> import numpy as np
>
> io.load_plugin('qt') ?# or 'wx'
> io.imshow(np.random.random((200, 200))
>
> All the plugins available may be queried with
>
> io.plugins()
>
> Regards
> St?fan
>


From stefan at sun.ac.za  Sun Nov  1 18:55:33 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 2 Nov 2009 01:55:33 +0200
Subject: I/O Plugin infrastructure + wx/qt plugins
Message-ID: <9457e7c80911011555i2d1fb22fg7237c2ce9e581b00@mail.gmail.com>

Hi all,

Chris and I have been working towards a more complete plugin framework
this afternoon.  Please have a look at

http://github.com/stefanv/scikits.image

in the `io` branch to see what's been done so far.  You may try the
new qt or wx image display plugins as follows:

import scikits.image.io as io
import numpy as np

io.load_plugin('qt')  # or 'wx'
io.imshow(np.random.random((200, 200))

All the plugins available may be queried with

io.plugins()

Regards
St?fan


From stefan at sun.ac.za  Mon Nov  2 17:28:13 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 3 Nov 2009 00:28:13 +0200
Subject: Shortest Path algorithm
Message-ID: <9457e7c80911021428n73fbc3a3yd76fdf4c8851f0d0@mail.gmail.com>

Hi all,

Please review the Shortest Path functionality implemented in branch 'spath' of

http://github.com/stefanv/scikits.image

Thanks
St?fan


From ralf.gommers at googlemail.com  Tue Nov  3 10:44:08 2009
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Tue, 3 Nov 2009 16:44:08 +0100
Subject: Shortest Path algorithm
In-Reply-To: <9457e7c80911021428n73fbc3a3yd76fdf4c8851f0d0@mail.gmail.com>
References: <9457e7c80911021428n73fbc3a3yd76fdf4c8851f0d0@mail.gmail.com>
Message-ID: <dde7764a0911030744p49ed9335w9817a0eccabaa8c7@mail.gmail.com>

Hi Stefan,

2009/11/2 St?fan van der Walt <stefan at sun.ac.za>

>
> Hi all,
>
> Please review the Shortest Path functionality implemented in branch 'spath'
> of
>
> http://github.com/stefanv/scikits.image
>

Looks good, both the shortest path algorithm and the Cython build
improvements.

About the build first, I had to run the setup.py in analysis separately, it
wasn't picked up by the main setup.py. I do not have Cython installed.

Some questions / points to think about for shortest path:

- why only left-to-right through the image? it would be easy to have an axis
keyword and then transpose the image if necessary.
- module name. "analysis" is quite generic, if that is where most algorithms
end up it will be a very large module after a while. maybe that is okay, i'm
not sure.
- docstring is rather incomplete: needs Returns, References, Examples,
Notes: synonym=Dijkstra's algorithm
- for the test, why is path [0, 0, 1] instead of either [1, 0 ,1] or [0, 1,
0]? I would expect path to contain either indices or values of the followed
path.

- and some questions motivated by my lack of knowledge of Cython:
* can you write r_bracket_min = max(r - 1, 0) and leave out the if < 0 check
afterward?
* what is the overhead (if any) of a triple for loop in Cython? I don't see
an obvious way to vectorize things, but if it's possible (even partially),
would that help?

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20091103/74b52104/attachment.html>

From stefan at sun.ac.za  Tue Nov  3 10:54:14 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 3 Nov 2009 17:54:14 +0200
Subject: Shortest Path algorithm
In-Reply-To: <dde7764a0911030744p49ed9335w9817a0eccabaa8c7@mail.gmail.com>
References: <9457e7c80911021428n73fbc3a3yd76fdf4c8851f0d0@mail.gmail.com> 
	<dde7764a0911030744p49ed9335w9817a0eccabaa8c7@mail.gmail.com>
Message-ID: <9457e7c80911030754q36dc068asadaf0565736efa42@mail.gmail.com>

Hi Ralf

2009/11/3 Ralf Gommers <ralf.gommers at googlemail.com>:
> About the build first, I had to run the setup.py in analysis separately, it
> wasn't picked up by the main setup.py. I do not have Cython installed.

I think I fixed that this morning, please confirm.

> - why only left-to-right through the image? it would be easy to have an axis
> keyword and then transpose the image if necessary.

I guess you can manipulate the data any way you like before sending it
in.  This is just the way most algorithms, such as Viterbi, are
defined.

> - module name. "analysis" is quite generic, if that is where most algorithms
> end up it will be a very large module after a while. maybe that is okay, i'm
> not sure.

I'd be glad for some suggestions on a different name -- I wasn't quite
sure myself.

> - docstring is rather incomplete: needs Returns, References, Examples,
> Notes: synonym=Dijkstra's algorithm

I added some of that last night, but it could do with a lot more, you're right!

> - for the test, why is path [0, 0, 1] instead of either [1, 0 ,1] or [0, 1,
> 0]? I would expect path to contain either indices or values of the followed
> path.

It contains the row coordinate for each column.  Using that
information, constructing the values along that path would be easy:

x[path, :] -> values

If there are many equivalent paths, the first is picked.

> * can you write r_bracket_min = max(r - 1, 0) and leave out the if < 0 check
> afterward?

You could, but then you'd need to define max, otherwise a Python call is made.

> * what is the overhead (if any) of a triple for loop in Cython? I don't see
> an obvious way to vectorize things, but if it's possible (even partially),
> would that help?

I don't think there's any advantage in this case -- we're working at
the C level, so vectorising has very little chance on making things
faster (unless you somehow manage to get better cache locality).  When
you vectorise, you just pass the buck to a library lower down the food
chain.

Regards
St?fan


From ralf.gommers at googlemail.com  Tue Nov  3 12:17:09 2009
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Tue, 3 Nov 2009 18:17:09 +0100
Subject: Shortest Path algorithm
In-Reply-To: <9457e7c80911030754q36dc068asadaf0565736efa42@mail.gmail.com>
References: <9457e7c80911021428n73fbc3a3yd76fdf4c8851f0d0@mail.gmail.com>
	 <dde7764a0911030744p49ed9335w9817a0eccabaa8c7@mail.gmail.com>
	 <9457e7c80911030754q36dc068asadaf0565736efa42@mail.gmail.com>
Message-ID: <dde7764a0911030917vdebf98h41b303ed6aa41770@mail.gmail.com>

2009/11/3 St?fan van der Walt <stefan at sun.ac.za>

>
> Hi Ralf
>
> 2009/11/3 Ralf Gommers <ralf.gommers at googlemail.com>:
> > About the build first, I had to run the setup.py in analysis separately,
> it
> > wasn't picked up by the main setup.py. I do not have Cython installed.
>
> I think I fixed that this morning, please confirm.
>

Ah yes, works now. I tested your spath branch and now see you made more
improvements in master. Merging before review eh:)


> > - why only left-to-right through the image? it would be easy to have an
> axis
> > keyword and then transpose the image if necessary.
>
> I guess you can manipulate the data any way you like before sending it
> in.  This is just the way most algorithms, such as Viterbi, are
> defined.
>
> Sure.


> > - module name. "analysis" is quite generic, if that is where most
> algorithms
> > end up it will be a very large module after a while. maybe that is okay,
> i'm
> > not sure.
>
> I'd be glad for some suggestions on a different name -- I wasn't quite
> sure myself.
>

"graph" maybe? or "tree"?


>
> > - for the test, why is path [0, 0, 1] instead of either [1, 0 ,1] or [0,
> 1,
> > 0]? I would expect path to contain either indices or values of the
> followed
> > path.
>

> It contains the row coordinate for each column.  Using that
> information, constructing the values along that path would be easy:
>
> x[path, :] -> values
>
> If there are many equivalent paths, the first is picked.
>

Ah yes, the docstring I looked at was incomplete so I was confused about the
definition of cost. Makes perfect sense now.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20091103/ae091acd/attachment.html>

From sirver at gmx.de  Wed Nov  4 01:44:30 2009
From: sirver at gmx.de (SirVer)
Date: Tue, 3 Nov 2009 22:44:30 -0800 (PST)
Subject: OpenCV 2 or 1
Message-ID: <4111c9d3-6ae0-4c2c-be69-7875043d9b23@p8g2000yqb.googlegroups.com>

Hi,

currently the following test fails on my system:
test_opencv_cv.TestCalibrateCamera2.test_cvCalibrateCamera2_Identity ...
OpenCV ERROR: Bad argument (Distortion coefficients must be 4x1 or 1x4
floating-point matrix)
	in function cvCalibrateCamera2, cvcalibration.cpp(1350)

This is a bit ironic, since it is a test that I initially wrote.

The Problem is that the function cvCalibrateCamera2 now allocates an
distortion array of size 1x5 while before it allocated a distortion
array of 1x4. I guess that opencv2 uses 1x5 while opencv1 (the one i
currently use) uses 1x4.

The Problem (once again!) rises that we do not link against a
particular version of the opencv but instead to our very own
hotlinking when the lib is loaded. This leads to this obscure crash
without any feedback to the user. Thus, I vote again for autodetection
and proper linking against headers.

OR, if this is too much trouble at least deny loading OpenCV 1 at run
time, because we just can not be too sure what the problems are.

Another point: generated c files in the repository are constantly
comming up as changed or merge conflicts for me. What is the reason to
keep .c files in the repository; i think it is fair to assume that
python developers who have a c compiler installed will also have
cython installed to generate the .c files.

Holger



From sirver at gmx.de  Wed Nov  4 01:49:30 2009
From: sirver at gmx.de (SirVer)
Date: Tue, 3 Nov 2009 22:49:30 -0800 (PST)
Subject: io.imshow(fancy=True) and the new color channel mixer!
In-Reply-To: <7f014ea60911031740x4df16f22sfbceda1db2c8681e@mail.gmail.com>
References: <7f014ea60911031740x4df16f22sfbceda1db2c8681e@mail.gmail.com>
Message-ID: <66a26035-c83f-43e8-a6e7-a990b443adef@s31g2000yqs.googlegroups.com>

Hi Chris,

I have not yet have time to check out your work here. But I wonder if
we are not working on the same thing twice. I commited a gui module a
while ago which offers displaying capacities in pyqt. It should have
been very convenient to build this on top of that.

Also, while I agree that the plugin architecture is well layed out, I
feel that this is not a very pythonic way to do things. In Python,
stuff either works because you have everything installed or not. I do
not want to criticize before I completely understand the reason for
the plugin architecture. Could someone point me to the thread were it
was discussed?

Cheers,
Holger


From sirver at gmx.de  Wed Nov  4 01:53:24 2009
From: sirver at gmx.de (SirVer)
Date: Tue, 3 Nov 2009 22:53:24 -0800 (PST)
Subject: Pending release of 0.3
In-Reply-To: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com>
Message-ID: <8d3755aa-4081-4470-b688-65776f2ad765@p35g2000yqh.googlegroups.com>

Hi Stefan,

I do not know were I'm currently at. My gui branch is not merged to
master, so I guess you are unhappy with it. There is other development
based on the plugin architecture and we have now yet another image
viewer in pyqt. Still I feel that a full featured gui module could
lead to much more powerful image processing widgets than the plugin
system could. So I am unsure if and if yes how I should advance with
my gui & camcalib branch.

Cheers,
Holger

On 3 Nov., 22:40, St?fan van der Walt <ste... at sun.ac.za> wrote:
> Hi all,
>
> I am planning to tag version 0.3 by the end of this week or early next
> week. ?Please let me know if there are any branches I should review
> before then.
>
> Happy hacking!
> St?fan


From stefan at sun.ac.za  Tue Nov  3 16:04:09 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 3 Nov 2009 23:04:09 +0200
Subject: Shortest Path algorithm
In-Reply-To: <dde7764a0911030917vdebf98h41b303ed6aa41770@mail.gmail.com>
References: <9457e7c80911021428n73fbc3a3yd76fdf4c8851f0d0@mail.gmail.com> 
	<dde7764a0911030744p49ed9335w9817a0eccabaa8c7@mail.gmail.com> 
	<9457e7c80911030754q36dc068asadaf0565736efa42@mail.gmail.com> 
	<dde7764a0911030917vdebf98h41b303ed6aa41770@mail.gmail.com>
Message-ID: <9457e7c80911031304h1a695d81g31cce1ebe2ef7988@mail.gmail.com>

2009/11/3 Ralf Gommers <ralf.gommers at googlemail.com>:
> Ah yes, works now. I tested your spath branch and now see you made more
> improvements in master. Merging before review eh:)

Disclaimer: I snuck in a review from Chris last night :)

Cheers
St?fan


From stefan at sun.ac.za  Tue Nov  3 16:40:35 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 3 Nov 2009 23:40:35 +0200
Subject: Pending release of 0.3
Message-ID: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com>

Hi all,

I am planning to tag version 0.3 by the end of this week or early next
week.  Please let me know if there are any branches I should review
before then.

Happy hacking!
St?fan


From sccolbert at gmail.com  Tue Nov  3 20:40:01 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Wed, 4 Nov 2009 02:40:01 +0100
Subject: io.imshow(fancy=True) and the new color channel mixer!
Message-ID: <7f014ea60911031740x4df16f22sfbceda1db2c8681e@mail.gmail.com>

Hey Guys,

I worked today on a couple of things.

First, as you all know, we recently added imshow() plugins for pygtk
and pyqt4 backends. The simple imshow() just pops open a window with
the image, nothing more, nothing less.

I've made the start of  a "fancy" imshow for qt.

its called via, imshow(img, fancy=True).

Unlike a matplotlib style imshow, I'm wanting to be a little "cooler" :)

Here is what works so far:

In the status bar of the window, you get your cursor position, as well
as the RGB pixels values of the image over point at which your mouse
is hovering.

To the right of the image are some sliders (Two groups of three for
now, until i can figure out dropdown selector lists :) ). Each of
these three groups controls the RGB channels of the new channel mixer
(more on that in a bit). The first group performs "additive" mixing
and the second group performs a "multiply" operation.

I still need to add a button to save the state when you are done with
an operation, and a revert button, labels yaddy yaddy yadda... it's
just a prototype right now.

Now, the new ColorMixer:

I've implemented the start of a new ColorMixer in io/_plugins/util.py
(the backend is _colormixer.pyx) which handles all of these nifty
color space operations on the channels
of you rgb uint8 numpy array. (sorry, no floating point for you!, its
meant for display operations).

Currently, it performs additive and multiply operations on any given
channel. I will be adding brightness, contrast, and HSV functions in
the coming days.

Its meant to be a general util that can be used by any plugin. Just
hook up your sliders and go!

You can check out all this goodness at my github on the io branch.
http://github.com/sccolbert/scikits.image/tree/io/scikits/image/io/

You'll have to manually build the _colormixer.pyx file cause I havent
hooked in a setup.py yet.

Cheers!

Chris


From sccolbert at gmail.com  Tue Nov  3 20:42:34 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Wed, 4 Nov 2009 02:42:34 +0100
Subject: io.imshow(fancy=True) and the new color channel mixer!
In-Reply-To: <7f014ea60911031740x4df16f22sfbceda1db2c8681e@mail.gmail.com>
References: <7f014ea60911031740x4df16f22sfbceda1db2c8681e@mail.gmail.com>
Message-ID: <7f014ea60911031742k6ece8de8oe6e92650082ea1f@mail.gmail.com>

oh, and I forgot to mention, based on my quick tests, the mixer is
faster than the Gimp :O



On Wed, Nov 4, 2009 at 2:40 AM, Chris Colbert <sccolbert at gmail.com> wrote:
> Hey Guys,
>
> I worked today on a couple of things.
>
> First, as you all know, we recently added imshow() plugins for pygtk
> and pyqt4 backends. The simple imshow() just pops open a window with
> the image, nothing more, nothing less.
>
> I've made the start of ?a "fancy" imshow for qt.
>
> its called via, imshow(img, fancy=True).
>
> Unlike a matplotlib style imshow, I'm wanting to be a little "cooler" :)
>
> Here is what works so far:
>
> In the status bar of the window, you get your cursor position, as well
> as the RGB pixels values of the image over point at which your mouse
> is hovering.
>
> To the right of the image are some sliders (Two groups of three for
> now, until i can figure out dropdown selector lists :) ). Each of
> these three groups controls the RGB channels of the new channel mixer
> (more on that in a bit). The first group performs "additive" mixing
> and the second group performs a "multiply" operation.
>
> I still need to add a button to save the state when you are done with
> an operation, and a revert button, labels yaddy yaddy yadda... it's
> just a prototype right now.
>
> Now, the new ColorMixer:
>
> I've implemented the start of a new ColorMixer in io/_plugins/util.py
> (the backend is _colormixer.pyx) which handles all of these nifty
> color space operations on the channels
> of you rgb uint8 numpy array. (sorry, no floating point for you!, its
> meant for display operations).
>
> Currently, it performs additive and multiply operations on any given
> channel. I will be adding brightness, contrast, and HSV functions in
> the coming days.
>
> Its meant to be a general util that can be used by any plugin. Just
> hook up your sliders and go!
>
> You can check out all this goodness at my github on the io branch.
> http://github.com/sccolbert/scikits.image/tree/io/scikits/image/io/
>
> You'll have to manually build the _colormixer.pyx file cause I havent
> hooked in a setup.py yet.
>
> Cheers!
>
> Chris
>


From sirver at gmx.de  Wed Nov  4 07:57:06 2009
From: sirver at gmx.de (SirVer)
Date: Wed, 4 Nov 2009 04:57:06 -0800 (PST)
Subject: OpenCV 2 or 1
In-Reply-To: <7f014ea60911040328ic79f38aj7304fe1195c7b41f@mail.gmail.com>
References: <4111c9d3-6ae0-4c2c-be69-7875043d9b23@p8g2000yqb.googlegroups.com> 
	<9457e7c80911032321m3499d5b8i9d8058325a04ba23@mail.gmail.com> 
	<dde7764a0911040111n2873f7fek1d6c5a6650db4855@mail.gmail.com> 
	<7f014ea60911040124m46a272b9s7158efe6ce9be4f4@mail.gmail.com> 
	<9457e7c80911040226h537c00b2vdcb68b90c2f4e6e9@mail.gmail.com> 
	<7f014ea60911040228q728d6b25q2b889f54bc2fdc6c@mail.gmail.com> 
	<9457e7c80911040320k675f70a0s2a5872ddbfecfffa@mail.gmail.com> 
	<7f014ea60911040328ic79f38aj7304fe1195c7b41f@mail.gmail.com>
Message-ID: <d0328ba1-8a2b-48c3-b5e7-df6944af0a12@d10g2000yqh.googlegroups.com>

A __version__ function in the future is little help to distinguish
between OCV 1 and OCV 2. BUT the current case is not bearable; for
example the test suite can not be run when you have OpenCV 1
installed, because OpenCV errors always result in a coredump because
of their braindumped I-do-my-own-Exceptions-In-C-Which-Are-Uncatchable
Stuff. That is, as soon as the opencv tests run, the whole python
process is KILLED by opencv throwing an exception because I expects an
array of 1x5 instead of 1x4. (Note that the same is true if we do
stuff vice-versa: making version 1 a dependency and the user has 2
installed).

The only REAL solutions I see for this mess is to either
a) decide which version to build against at build time using IFDEFs.
Which is ugly and not easy to pull off and makes OpenCV a hard build
time dependency. On plus we would have to ship binary versions linked
against OCV1 and OCV2. Ugly code, Ugly distribution, hard to
implement.
b) Determine at run time if the user has OpenCV 1 installed and ABORT
then in a pythonic fashion. I know of no portable way to pull this
off; one could only check for relative positions of functions in the
binaries or so. Nice code, nice distribution, very hard to implement.
c) Rip the parts that we need from the OpenCV source code (if
licensing allows that) and build our own subset of the functionality
into scikit.image. No dependency on the OpenCV anymore, no cranky
void* pointer passing around, no strange exceptions that are
uncatchable. Heaven on earth. Downside: a lot of work. Upside: We
really would provide the image processing capabilities.

What do others think? Personally, I always wanted to have a better
designed Image Library with a smaller, but well tested subset of
ImageProcessing Algos that are really useful.


> Goodluck with getting that done though. I doubt we will see a new
> OpenCV release for awhile... and people will be using 2.0 for a long
> time to come...
No wonder; hacking OpenCV code is as ugly as coding can get.

Cheers,
Holger

>
> 2009/11/4 St?fan van der Walt <ste... at sun.ac.za>:
>
>
>
>
>
> > 2009/11/4 Chris Colbert <sccolb... at gmail.com>:
>
> >> OpenCV has a ___version___ header file.
>
> > We can only access that if it exposed as a function, though, so maybe
> > they can help us out.
>
> > Cheers
> > St?fan


From sirver at gmx.de  Wed Nov  4 08:06:53 2009
From: sirver at gmx.de (SirVer)
Date: Wed, 4 Nov 2009 05:06:53 -0800 (PST)
Subject: Pending release of 0.3
In-Reply-To: <7f014ea60911040326m44bb208cwb77d4f4a1fd19278@mail.gmail.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com> 
	<8d3755aa-4081-4470-b688-65776f2ad765@p35g2000yqh.googlegroups.com> 
	<7f014ea60911040144x709531a2w49677946421ac8e2@mail.gmail.com> 
	<7f014ea60911040147n7593e2d0iaa5da615b421718d@mail.gmail.com> 
	<9457e7c80911040318s505466c9m60b62b8de572241c@mail.gmail.com> 
	<7f014ea60911040326m44bb208cwb77d4f4a1fd19278@mail.gmail.com>
Message-ID: <a2587f3b-7a41-482d-82af-72790e33345f@m16g2000yqc.googlegroups.com>

hi all,

while I agree that the plugin architecture is nice and flexible it is
not suitable for fast image displaying. My GUI stuff was designed for
real live displays of multiple cameras at once and doesn't fit nicely
into the plugin architecture (though the other way round is true: If
you do not need the speed, you could write a plugin using my GUI
display).

Stefan, concerning my GUI branch:
I played around with pyqt and QImages and they just couldn't deliver
what I needed: Speed. The only route to go was OpenGL. I personally
feel that PyOpenGL is not a hard dependency, because it is a Ctypes
wrapper around a library that is installed on all systems per Default
these days. On the other side, I was pretty sure (at design time) that
I only needed to display images; that is convert numpy arrays to
OpenGL textures and I didn't want to introduce another dependency
(Pyglet) for that. I also think Pyglet with its focus on Multi Media
(e.g. also sound, music) is not a wise dependency for an image
processing toolkit.

Cheers,
Holger


On 4 Nov., 12:26, Chris Colbert <sccolb... at gmail.com> wrote:
> Sure, i'll fix my grammar and make a writeup.
>
> 2009/11/4 St?fan van der Walt <ste... at sun.ac.za>:
>
>
>
>
>
> > Hey Chris
>
> > 2009/11/4 Chris Colbert <sccolb... at gmail.com>:
> >> continuing on...
>
> >> for the pygtk plugin:
>
> > Could you take this e-mail and format is as a docstring somewhere in
> > the plugins? ?How to write a plugin is definiately a topic for the
> > docs (we could also put it in a stand-alone file inside docs/source if
> > you prefer).
>
> >> def __app_show():
> >> ? ? window_manager.register_callback(gtk.main_quit)
> >> ? ? gtk.main()
>
> > I think we used _app_show() in the end.
>
> > Cheers
> > St?fan


From stefan at sun.ac.za  Wed Nov  4 00:50:30 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 4 Nov 2009 07:50:30 +0200
Subject: io.imshow(fancy=True) and the new color channel mixer!
In-Reply-To: <7f014ea60911031740x4df16f22sfbceda1db2c8681e@mail.gmail.com>
References: <7f014ea60911031740x4df16f22sfbceda1db2c8681e@mail.gmail.com>
Message-ID: <9457e7c80911032150r3e3da02bmd04cb5c44a21a56@mail.gmail.com>

Hey, Chris

2009/11/4 Chris Colbert <sccolbert at gmail.com>:
> In the status bar of the window, you get your cursor position, as well
> as the RGB pixels values of the image over point at which your mouse
> is hovering.

The viewer is coming along very nicely!

> Now, the new ColorMixer:

[...]

> You'll have to manually build the _colormixer.pyx file cause I havent
> hooked in a setup.py yet.

I've added a setup file for the colour mixer, as well as some
documentation and tests:

http://github.com/stefanv/scikits.image/commits/chris_io

You may pull the changes from there if you like them.

Cheers
St?fan


From stefan at sun.ac.za  Wed Nov  4 02:21:23 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 4 Nov 2009 09:21:23 +0200
Subject: OpenCV 2 or 1
In-Reply-To: <4111c9d3-6ae0-4c2c-be69-7875043d9b23@p8g2000yqb.googlegroups.com>
References: <4111c9d3-6ae0-4c2c-be69-7875043d9b23@p8g2000yqb.googlegroups.com>
Message-ID: <9457e7c80911032321m3499d5b8i9d8058325a04ba23@mail.gmail.com>

Hi Holger

2009/11/4 SirVer <sirver at gmx.de>:
> The Problem is that the function cvCalibrateCamera2 now allocates an
> distortion array of size 1x5 while before it allocated a distortion
> array of 1x4. I guess that opencv2 uses 1x5 while opencv1 (the one i
> currently use) uses 1x4.

Should should make it a priority to figure out which version of OpenCV
is available before releasing 0.3.  Do you have any ideas?   I was
hoping they'd have a function such as version(), but I think I'm out
of luck.

> Another point: generated c files in the repository are constantly
> comming up as changed or merge conflicts for me. What is the reason to
> keep .c files in the repository; i think it is fair to assume that
> python developers who have a c compiler installed will also have
> cython installed to generate the .c files.

This has been a constant source of annoyance, so I wonder whether we
shouldn't just stop tracking the C files.  We could always still
include C files in the source distribution.

Regards
St?fan


From stefan at sun.ac.za  Wed Nov  4 02:27:07 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 4 Nov 2009 09:27:07 +0200
Subject: io.imshow(fancy=True) and the new color channel mixer!
In-Reply-To: <66a26035-c83f-43e8-a6e7-a990b443adef@s31g2000yqs.googlegroups.com>
References: <7f014ea60911031740x4df16f22sfbceda1db2c8681e@mail.gmail.com> 
	<66a26035-c83f-43e8-a6e7-a990b443adef@s31g2000yqs.googlegroups.com>
Message-ID: <9457e7c80911032327m64305d43ha19792a74c283825@mail.gmail.com>

Hi Holger

2009/11/4 SirVer <sirver at gmx.de>:
> Also, while I agree that the plugin architecture is well layed out, I
> feel that this is not a very pythonic way to do things. In Python,
> stuff either works because you have everything installed or not. I do
> not want to criticize before I completely understand the reason for
> the plugin architecture. Could someone point me to the thread were it
> was discussed?

I don't think this is an accurate summary of "pythonic".  Sometimes,
it is impossible not to  have differing behaviour depending on the OS,
available libraries, etc.  In our case, the plugin architecture made
it possible for me to display images on my work machine (that only has
GTK installed), or on my Mac (which only has Qt4 installed).  Another
well-known package that uses a similar architecture is matplotlib,
with backends for GTK, OSX, PDF and so forth.

One aspect of the scikit design that I'd like to preserve is a light
list of dependencies.  This means that someone who simply wants to run
a filter should not have to install OpenCV, Qt, GTK, Cython, etc.

Regards
St?fan


From ralf.gommers at googlemail.com  Wed Nov  4 04:11:49 2009
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Wed, 4 Nov 2009 10:11:49 +0100
Subject: OpenCV 2 or 1
In-Reply-To: <9457e7c80911032321m3499d5b8i9d8058325a04ba23@mail.gmail.com>
References: <4111c9d3-6ae0-4c2c-be69-7875043d9b23@p8g2000yqb.googlegroups.com>
	 <9457e7c80911032321m3499d5b8i9d8058325a04ba23@mail.gmail.com>
Message-ID: <dde7764a0911040111n2873f7fek1d6c5a6650db4855@mail.gmail.com>

2009/11/4 St?fan van der Walt <stefan at sun.ac.za>

>
> > Another point: generated c files in the repository are constantly
> > comming up as changed or merge conflicts for me. What is the reason to
> > keep .c files in the repository; i think it is fair to assume that
> > python developers who have a c compiler installed will also have
> > cython installed to generate the .c files.
>
> This has been a constant source of annoyance, so I wonder whether we
> shouldn't just stop tracking the C files.  We could always still
> include C files in the source distribution.
>

Diffs are also hard to read with C file changes, so +1 for this.

I just discovered that Cython is one of the few non-pure-python packages
that actually easy-installs on my machine, so it looks like a very
light-weight dependency.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20091104/94a7f748/attachment.html>

From sccolbert at gmail.com  Wed Nov  4 04:12:51 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Wed, 4 Nov 2009 10:12:51 +0100
Subject: OpenCV 2 or 1
In-Reply-To: <9457e7c80911032321m3499d5b8i9d8058325a04ba23@mail.gmail.com>
References: <4111c9d3-6ae0-4c2c-be69-7875043d9b23@p8g2000yqb.googlegroups.com>
	 <9457e7c80911032321m3499d5b8i9d8058325a04ba23@mail.gmail.com>
Message-ID: <7f014ea60911040112u235b905eu1aefd96922061385@mail.gmail.com>

There are many minor annoyances that we ran into in some functions
that make it near impossible to support both opencv versions
regardless of whether or not we link header files.

For example, cvIntegral in 2.0 calculates the titlted_sum for any
dtype, while 1.x does not.

Stefan and I realized during the sprint that this would cause us to be
IF_THEn_ELSE'ing all over the place, making the code ugly, just to
support a 5 year old version of the library. (there are more examples
than just this one)

We thought it would be better to make OpenCV 2.0 a dependency, and
lobby ubuntu to update the OpenCV packages.

Cheers,

Chris

2009/11/4 St?fan van der Walt <stefan at sun.ac.za>:
>
> Hi Holger
>
> 2009/11/4 SirVer <sirver at gmx.de>:
>> The Problem is that the function cvCalibrateCamera2 now allocates an
>> distortion array of size 1x5 while before it allocated a distortion
>> array of 1x4. I guess that opencv2 uses 1x5 while opencv1 (the one i
>> currently use) uses 1x4.
>
> Should should make it a priority to figure out which version of OpenCV
> is available before releasing 0.3. ?Do you have any ideas? ? I was
> hoping they'd have a function such as version(), but I think I'm out
> of luck.
>
>> Another point: generated c files in the repository are constantly
>> comming up as changed or merge conflicts for me. What is the reason to
>> keep .c files in the repository; i think it is fair to assume that
>> python developers who have a c compiler installed will also have
>> cython installed to generate the .c files.
>
> This has been a constant source of annoyance, so I wonder whether we
> shouldn't just stop tracking the C files. ?We could always still
> include C files in the source distribution.
>
> Regards
> St?fan
>


From sccolbert at gmail.com  Wed Nov  4 04:24:27 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Wed, 4 Nov 2009 10:24:27 +0100
Subject: OpenCV 2 or 1
In-Reply-To: <dde7764a0911040111n2873f7fek1d6c5a6650db4855@mail.gmail.com>
References: <4111c9d3-6ae0-4c2c-be69-7875043d9b23@p8g2000yqb.googlegroups.com>
	 <9457e7c80911032321m3499d5b8i9d8058325a04ba23@mail.gmail.com>
	 <dde7764a0911040111n2873f7fek1d6c5a6650db4855@mail.gmail.com>
Message-ID: <7f014ea60911040124m46a272b9s7158efe6ce9be4f4@mail.gmail.com>

And the problem with linking header files is that it makes  OpenCV a
dependency.

This brings a couple problems:
1) The user has to install OpenCV. Until 2.0 is in the repos, this is
much to ask of a new user, who could use everything else meantime.
2) We have to find the header files on the users machine, or provide a
way for them to provide it.

For no REAL benefit.

If the opencv API changes, you claim that linking the headers will
allow us to fix these crashing problems. I disagree.
In Cython when you do a:
cdef extern from "whatever.h":
       void cvFunc(IplImage*, IplImage*, CvPoint2D32F*)


That is only for Cythons benefit. It just puts an #include directive
in the foo.c file.
So in the case of this most recent test failing, the error would NEVER
be caught, neither by the C compiler or Cython.

Because neither have a way of knowing how big CvPoint2D32F* array should be.

Now lets say that OpenCV 2.1 comes out, and they change the api for
cvFunc, and we dont realize it. Let's say the new signature becomes:
void cvFunc(IplImage*, IplImage*, IplImage*). Because of how cython
works, the cython module will still compile (it doesnt ever look in
the .c headers). However, the error will likely be caught by GCC.

So now what you have, (if we make the headers a dependency), is
someone who cant install the scikit AT ALL, rather than just a part of
a scikit with some tests that will fail...

This is the entire reason to have a testing framework.


I though about this one for a while. and I vehemently oppose linking
to the cv headers.

Cheers,

Chris

On Wed, Nov 4, 2009 at 10:11 AM, Ralf Gommers
<ralf.gommers at googlemail.com> wrote:
>
>
> 2009/11/4 St?fan van der Walt <stefan at sun.ac.za>
>>
>> > Another point: generated c files in the repository are constantly
>> > comming up as changed or merge conflicts for me. What is the reason to
>> > keep .c files in the repository; i think it is fair to assume that
>> > python developers who have a c compiler installed will also have
>> > cython installed to generate the .c files.
>>
>> This has been a constant source of annoyance, so I wonder whether we
>> shouldn't just stop tracking the C files. ?We could always still
>> include C files in the source distribution.
>
>
> Diffs are also hard to read with C file changes, so +1 for this.
>
> I just discovered that Cython is one of the few non-pure-python packages
> that actually easy-installs on my machine, so it looks like a very
> light-weight dependency.
>
> Cheers,
> Ralf
>
>


From stefan at sun.ac.za  Wed Nov  4 03:30:09 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 4 Nov 2009 10:30:09 +0200
Subject: Pending release of 0.3
In-Reply-To: <8d3755aa-4081-4470-b688-65776f2ad765@p35g2000yqh.googlegroups.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com> 
	<8d3755aa-4081-4470-b688-65776f2ad765@p35g2000yqh.googlegroups.com>
Message-ID: <9457e7c80911040030r677a8eddl65313032cb57080e@mail.gmail.com>

Hi Holger

2009/11/4 SirVer <sirver at gmx.de>:
> I do not know were I'm currently at. My gui branch is not merged to
> master, so I guess you are unhappy with it. There is other development
> based on the plugin architecture and we have now yet another image
> viewer in pyqt. Still I feel that a full featured gui module could
> lead to much more powerful image processing widgets than the plugin
> system could. So I am unsure if and if yes how I should advance with
> my gui & camcalib branch.

I'm sorry, I didn't mean to exclude you in any way: you were pretty
quiet after our last email exchange, so Chris and I developed the
architecture further.  I still see a place for a higher-level GUI,
although I'd be glad if you could explain your vision for such a
module in more detail.

To get back to your GUI branch: is the dependency on OpenGL really
necessary?  We saw in the meantime that QImage's can be created
directly from numpy arrays, so that should give you the kind of
display speed you need (yes, I know, I'm a bit allergic to new
dependencies).  If we do have to bring in OpenGL, I'm still of the
opinion that we should avoid duplicating the work done by Pyglet.

I am also still interested in combining the work you and Andrew Straw
did to provide a good image acquisition module.

Regards
St?fan


From sccolbert at gmail.com  Wed Nov  4 04:44:35 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Wed, 4 Nov 2009 10:44:35 +0100
Subject: Pending release of 0.3
In-Reply-To: <8d3755aa-4081-4470-b688-65776f2ad765@p35g2000yqh.googlegroups.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com>
	 <8d3755aa-4081-4470-b688-65776f2ad765@p35g2000yqh.googlegroups.com>
Message-ID: <7f014ea60911040144x709531a2w49677946421ac8e2@mail.gmail.com>

The plugin system makes it extremely easy to make any kind of display
plugin you want. You just have to provide at least two methods and
shake hands with the window manager.

your plugin must provide the following two functions:

imshow(img, *arg, **kwarge)

and

__app_show()


you must also "shake hands" with the window manager.  A common
occurance in the gui tookits is the windows opened from within
functions during an interactive python session will be garbage
collected after the function returns and they fall out of scope. Thus
the window manager maintains a reference to the window until it is
closed. Also, because the gui toolkits set PyOS_InputHook, we have to
make sure that only one gui kit gets imported in a session (some kits
will trample on other, but not vice-versa) so the window manager also
implements a "gui lock" that you must acquire before using it or your
gui kit:

from util import window_manager

window_manager.acquire('qt')  #or 'gtk' or 'mybadassplugin'

then evertime you create a window, register the main_window handle
with the manager.

window_manager.add_window(mynew_window)

Then, make sure that mynew_window's destroy event, whatever that may
be, makes a call to window_manager.remove_window(mynew_window)

The window manager also implements a callback that can be set, that
will be called when there are no more registered windows.
This was necessary for non-interactive sessions, so you can kill the
event loop. This is also the reason for __app_show():

You're plugin must also define an __app_show() method. When not
running interactively (i.e. from a script), calls to imshow() will
queue up windows, but without a gui mainloop running, they will never
display. When a user calls show(), this calls your plugins
__app_show() method, which should do two things:
1) register a callback with window_manager that will be called when
all windows are closed and will cause the event loop to exit (this may
not be required for some kits. i.e. PyQt4)
2) start the mainloop

for the pygtk plugin, it looks like this:

def __app_show():


On Wed, Nov 4, 2009 at 7:53 AM, SirVer <sirver at gmx.de> wrote:
>
> Hi Stefan,
>
> I do not know were I'm currently at. My gui branch is not merged to
> master, so I guess you are unhappy with it. There is other development
> based on the plugin architecture and we have now yet another image
> viewer in pyqt. Still I feel that a full featured gui module could
> lead to much more powerful image processing widgets than the plugin
> system could. So I am unsure if and if yes how I should advance with
> my gui & camcalib branch.
>
> Cheers,
> Holger
>
> On 3 Nov., 22:40, St?fan van der Walt <ste... at sun.ac.za> wrote:
>> Hi all,
>>
>> I am planning to tag version 0.3 by the end of this week or early next
>> week. ?Please let me know if there are any branches I should review
>> before then.
>>
>> Happy hacking!
>> St?fan


From sccolbert at gmail.com  Wed Nov  4 04:47:14 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Wed, 4 Nov 2009 10:47:14 +0100
Subject: Pending release of 0.3
In-Reply-To: <7f014ea60911040144x709531a2w49677946421ac8e2@mail.gmail.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com>
	 <8d3755aa-4081-4470-b688-65776f2ad765@p35g2000yqh.googlegroups.com>
	 <7f014ea60911040144x709531a2w49677946421ac8e2@mail.gmail.com>
Message-ID: <7f014ea60911040147n7593e2d0iaa5da615b421718d@mail.gmail.com>

crap, I hit send too soon.

continuing on...

for the pygtk plugin:

def __app_show():
     window_manager.register_callback(gtk.main_quit)
     gtk.main()


Thus, the window manager represents a universal manager that is
applicable to every image plugin.

You can make super complex gui window widgets, just register it with
the manager.
Since imshow takes *args, and **kwargs, you could in theory do this:

imshow(img, mybadasswindow=True)

and your plugin behaves appropriately.

Cheers!

Chris

On Wed, Nov 4, 2009 at 10:44 AM, Chris Colbert <sccolbert at gmail.com> wrote:
> The plugin system makes it extremely easy to make any kind of display
> plugin you want. You just have to provide at least two methods and
> shake hands with the window manager.
>
> your plugin must provide the following two functions:
>
> imshow(img, *arg, **kwarge)
>
> and
>
> __app_show()
>
>
> you must also "shake hands" with the window manager. ?A common
> occurance in the gui tookits is the windows opened from within
> functions during an interactive python session will be garbage
> collected after the function returns and they fall out of scope. Thus
> the window manager maintains a reference to the window until it is
> closed. Also, because the gui toolkits set PyOS_InputHook, we have to
> make sure that only one gui kit gets imported in a session (some kits
> will trample on other, but not vice-versa) so the window manager also
> implements a "gui lock" that you must acquire before using it or your
> gui kit:
>
> from util import window_manager
>
> window_manager.acquire('qt') ?#or 'gtk' or 'mybadassplugin'
>
> then evertime you create a window, register the main_window handle
> with the manager.
>
> window_manager.add_window(mynew_window)
>
> Then, make sure that mynew_window's destroy event, whatever that may
> be, makes a call to window_manager.remove_window(mynew_window)
>
> The window manager also implements a callback that can be set, that
> will be called when there are no more registered windows.
> This was necessary for non-interactive sessions, so you can kill the
> event loop. This is also the reason for __app_show():
>
> You're plugin must also define an __app_show() method. When not
> running interactively (i.e. from a script), calls to imshow() will
> queue up windows, but without a gui mainloop running, they will never
> display. When a user calls show(), this calls your plugins
> __app_show() method, which should do two things:
> 1) register a callback with window_manager that will be called when
> all windows are closed and will cause the event loop to exit (this may
> not be required for some kits. i.e. PyQt4)
> 2) start the mainloop
>
> for the pygtk plugin, it looks like this:
>
> def __app_show():
>
>
> On Wed, Nov 4, 2009 at 7:53 AM, SirVer <sirver at gmx.de> wrote:
>>
>> Hi Stefan,
>>
>> I do not know were I'm currently at. My gui branch is not merged to
>> master, so I guess you are unhappy with it. There is other development
>> based on the plugin architecture and we have now yet another image
>> viewer in pyqt. Still I feel that a full featured gui module could
>> lead to much more powerful image processing widgets than the plugin
>> system could. So I am unsure if and if yes how I should advance with
>> my gui & camcalib branch.
>>
>> Cheers,
>> Holger
>>
>> On 3 Nov., 22:40, St?fan van der Walt <ste... at sun.ac.za> wrote:
>>> Hi all,
>>>
>>> I am planning to tag version 0.3 by the end of this week or early next
>>> week. ?Please let me know if there are any branches I should review
>>> before then.
>>>
>>> Happy hacking!
>>> St?fan
>


From sccolbert at gmail.com  Wed Nov  4 05:28:32 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Wed, 4 Nov 2009 11:28:32 +0100
Subject: OpenCV 2 or 1
In-Reply-To: <9457e7c80911040226h537c00b2vdcb68b90c2f4e6e9@mail.gmail.com>
References: <4111c9d3-6ae0-4c2c-be69-7875043d9b23@p8g2000yqb.googlegroups.com>
	 <9457e7c80911032321m3499d5b8i9d8058325a04ba23@mail.gmail.com>
	 <dde7764a0911040111n2873f7fek1d6c5a6650db4855@mail.gmail.com>
	 <7f014ea60911040124m46a272b9s7158efe6ce9be4f4@mail.gmail.com>
	 <9457e7c80911040226h537c00b2vdcb68b90c2f4e6e9@mail.gmail.com>
Message-ID: <7f014ea60911040228q728d6b25q2b889f54bc2fdc6c@mail.gmail.com>

OpenCV has a ___version___ header file.

Catch 22

2009/11/4 St?fan van der Walt <stefan at sun.ac.za>:
>
> 2009/11/4 Chris Colbert <sccolbert at gmail.com>:
>>> I just discovered that Cython is one of the few non-pure-python packages
>>> that actually easy-installs on my machine, so it looks like a very
>>> light-weight dependency.
>
> Could we petition for OpenCV to have a __version__() function?
>
> St?fan
>


From stefan at sun.ac.za  Wed Nov  4 04:32:07 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 4 Nov 2009 11:32:07 +0200
Subject: OpenCV 2 or 1
In-Reply-To: <dde7764a0911040111n2873f7fek1d6c5a6650db4855@mail.gmail.com>
References: <4111c9d3-6ae0-4c2c-be69-7875043d9b23@p8g2000yqb.googlegroups.com> 
	<9457e7c80911032321m3499d5b8i9d8058325a04ba23@mail.gmail.com> 
	<dde7764a0911040111n2873f7fek1d6c5a6650db4855@mail.gmail.com>
Message-ID: <9457e7c80911040132t54a5a11cx784d47db16ff9105@mail.gmail.com>

2009/11/4 Ralf Gommers <ralf.gommers at googlemail.com>:
> Diffs are also hard to read with C file changes, so +1 for this.
>
> I just discovered that Cython is one of the few non-pure-python packages
> that actually easy-installs on my machine, so it looks like a very
> light-weight dependency.

This is now done.  The .c files are still generated for inclusion with
the sdist.

Cheers
St?fan


From stefan at sun.ac.za  Wed Nov  4 05:26:19 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 4 Nov 2009 12:26:19 +0200
Subject: OpenCV 2 or 1
In-Reply-To: <7f014ea60911040124m46a272b9s7158efe6ce9be4f4@mail.gmail.com>
References: <4111c9d3-6ae0-4c2c-be69-7875043d9b23@p8g2000yqb.googlegroups.com> 
	<9457e7c80911032321m3499d5b8i9d8058325a04ba23@mail.gmail.com> 
	<dde7764a0911040111n2873f7fek1d6c5a6650db4855@mail.gmail.com> 
	<7f014ea60911040124m46a272b9s7158efe6ce9be4f4@mail.gmail.com>
Message-ID: <9457e7c80911040226h537c00b2vdcb68b90c2f4e6e9@mail.gmail.com>

2009/11/4 Chris Colbert <sccolbert at gmail.com>:
>> I just discovered that Cython is one of the few non-pure-python packages
>> that actually easy-installs on my machine, so it looks like a very
>> light-weight dependency.

Could we petition for OpenCV to have a __version__() function?

St?fan


From sccolbert at gmail.com  Wed Nov  4 06:26:59 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Wed, 4 Nov 2009 12:26:59 +0100
Subject: Pending release of 0.3
In-Reply-To: <9457e7c80911040318s505466c9m60b62b8de572241c@mail.gmail.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com>
	 <8d3755aa-4081-4470-b688-65776f2ad765@p35g2000yqh.googlegroups.com>
	 <7f014ea60911040144x709531a2w49677946421ac8e2@mail.gmail.com>
	 <7f014ea60911040147n7593e2d0iaa5da615b421718d@mail.gmail.com>
	 <9457e7c80911040318s505466c9m60b62b8de572241c@mail.gmail.com>
Message-ID: <7f014ea60911040326m44bb208cwb77d4f4a1fd19278@mail.gmail.com>

Sure, i'll fix my grammar and make a writeup.



2009/11/4 St?fan van der Walt <stefan at sun.ac.za>:
>
> Hey Chris
>
> 2009/11/4 Chris Colbert <sccolbert at gmail.com>:
>> continuing on...
>>
>> for the pygtk plugin:
>
> Could you take this e-mail and format is as a docstring somewhere in
> the plugins? ?How to write a plugin is definiately a topic for the
> docs (we could also put it in a stand-alone file inside docs/source if
> you prefer).
>
>> def __app_show():
>> ? ? window_manager.register_callback(gtk.main_quit)
>> ? ? gtk.main()
>
> I think we used _app_show() in the end.
>
> Cheers
> St?fan
>


From sccolbert at gmail.com  Wed Nov  4 06:28:06 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Wed, 4 Nov 2009 12:28:06 +0100
Subject: OpenCV 2 or 1
In-Reply-To: <9457e7c80911040320k675f70a0s2a5872ddbfecfffa@mail.gmail.com>
References: <4111c9d3-6ae0-4c2c-be69-7875043d9b23@p8g2000yqb.googlegroups.com>
	 <9457e7c80911032321m3499d5b8i9d8058325a04ba23@mail.gmail.com>
	 <dde7764a0911040111n2873f7fek1d6c5a6650db4855@mail.gmail.com>
	 <7f014ea60911040124m46a272b9s7158efe6ce9be4f4@mail.gmail.com>
	 <9457e7c80911040226h537c00b2vdcb68b90c2f4e6e9@mail.gmail.com>
	 <7f014ea60911040228q728d6b25q2b889f54bc2fdc6c@mail.gmail.com>
	 <9457e7c80911040320k675f70a0s2a5872ddbfecfffa@mail.gmail.com>
Message-ID: <7f014ea60911040328ic79f38aj7304fe1195c7b41f@mail.gmail.com>

its not exposed as a function, just a #DEF

Goodluck with getting that done though. I doubt we will see a new
OpenCV release for awhile... and people will be using 2.0 for a long
time to come...

2009/11/4 St?fan van der Walt <stefan at sun.ac.za>:
>
> 2009/11/4 Chris Colbert <sccolbert at gmail.com>:
>>
>> OpenCV has a ___version___ header file.
>
> We can only access that if it exposed as a function, though, so maybe
> they can help us out.
>
> Cheers
> St?fan
>


From stefan at sun.ac.za  Wed Nov  4 06:18:09 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 4 Nov 2009 13:18:09 +0200
Subject: Pending release of 0.3
In-Reply-To: <7f014ea60911040147n7593e2d0iaa5da615b421718d@mail.gmail.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com> 
	<8d3755aa-4081-4470-b688-65776f2ad765@p35g2000yqh.googlegroups.com> 
	<7f014ea60911040144x709531a2w49677946421ac8e2@mail.gmail.com> 
	<7f014ea60911040147n7593e2d0iaa5da615b421718d@mail.gmail.com>
Message-ID: <9457e7c80911040318s505466c9m60b62b8de572241c@mail.gmail.com>

Hey Chris

2009/11/4 Chris Colbert <sccolbert at gmail.com>:
> continuing on...
>
> for the pygtk plugin:

Could you take this e-mail and format is as a docstring somewhere in
the plugins?  How to write a plugin is definiately a topic for the
docs (we could also put it in a stand-alone file inside docs/source if
you prefer).

> def __app_show():
> ? ? window_manager.register_callback(gtk.main_quit)
> ? ? gtk.main()

I think we used _app_show() in the end.

Cheers
St?fan


From stefan at sun.ac.za  Wed Nov  4 06:20:09 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 4 Nov 2009 13:20:09 +0200
Subject: OpenCV 2 or 1
In-Reply-To: <7f014ea60911040228q728d6b25q2b889f54bc2fdc6c@mail.gmail.com>
References: <4111c9d3-6ae0-4c2c-be69-7875043d9b23@p8g2000yqb.googlegroups.com> 
	<9457e7c80911032321m3499d5b8i9d8058325a04ba23@mail.gmail.com> 
	<dde7764a0911040111n2873f7fek1d6c5a6650db4855@mail.gmail.com> 
	<7f014ea60911040124m46a272b9s7158efe6ce9be4f4@mail.gmail.com> 
	<9457e7c80911040226h537c00b2vdcb68b90c2f4e6e9@mail.gmail.com> 
	<7f014ea60911040228q728d6b25q2b889f54bc2fdc6c@mail.gmail.com>
Message-ID: <9457e7c80911040320k675f70a0s2a5872ddbfecfffa@mail.gmail.com>

2009/11/4 Chris Colbert <sccolbert at gmail.com>:
>
> OpenCV has a ___version___ header file.

We can only access that if it exposed as a function, though, so maybe
they can help us out.

Cheers
St?fan


From sccolbert at gmail.com  Wed Nov  4 08:02:45 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Wed, 4 Nov 2009 14:02:45 +0100
Subject: OpenCV 2 or 1
In-Reply-To: <d0328ba1-8a2b-48c3-b5e7-df6944af0a12@d10g2000yqh.googlegroups.com>
References: <4111c9d3-6ae0-4c2c-be69-7875043d9b23@p8g2000yqb.googlegroups.com>
	 <9457e7c80911032321m3499d5b8i9d8058325a04ba23@mail.gmail.com>
	 <dde7764a0911040111n2873f7fek1d6c5a6650db4855@mail.gmail.com>
	 <7f014ea60911040124m46a272b9s7158efe6ce9be4f4@mail.gmail.com>
	 <9457e7c80911040226h537c00b2vdcb68b90c2f4e6e9@mail.gmail.com>
	 <7f014ea60911040228q728d6b25q2b889f54bc2fdc6c@mail.gmail.com>
	 <9457e7c80911040320k675f70a0s2a5872ddbfecfffa@mail.gmail.com>
	 <7f014ea60911040328ic79f38aj7304fe1195c7b41f@mail.gmail.com>
	 <d0328ba1-8a2b-48c3-b5e7-df6944af0a12@d10g2000yqh.googlegroups.com>
Message-ID: <7f014ea60911040502y7d5a133cqd047a8d9947032ab@mail.gmail.com>

Im all for a big glaring "OpenCV >= 2.0 required if you want to use
opencv extensions"


On Wed, Nov 4, 2009 at 1:57 PM, SirVer <sirver at gmx.de> wrote:
>
> A __version__ function in the future is little help to distinguish
> between OCV 1 and OCV 2. BUT the current case is not bearable; for
> example the test suite can not be run when you have OpenCV 1
> installed, because OpenCV errors always result in a coredump because
> of their braindumped I-do-my-own-Exceptions-In-C-Which-Are-Uncatchable
> Stuff. That is, as soon as the opencv tests run, the whole python
> process is KILLED by opencv throwing an exception because I expects an
> array of 1x5 instead of 1x4. (Note that the same is true if we do
> stuff vice-versa: making version 1 a dependency and the user has 2
> installed).
>
> The only REAL solutions I see for this mess is to either
> a) decide which version to build against at build time using IFDEFs.
> Which is ugly and not easy to pull off and makes OpenCV a hard build
> time dependency. On plus we would have to ship binary versions linked
> against OCV1 and OCV2. Ugly code, Ugly distribution, hard to
> implement.
> b) Determine at run time if the user has OpenCV 1 installed and ABORT
> then in a pythonic fashion. I know of no portable way to pull this
> off; one could only check for relative positions of functions in the
> binaries or so. Nice code, nice distribution, very hard to implement.
> c) Rip the parts that we need from the OpenCV source code (if
> licensing allows that) and build our own subset of the functionality
> into scikit.image. No dependency on the OpenCV anymore, no cranky
> void* pointer passing around, no strange exceptions that are
> uncatchable. Heaven on earth. Downside: a lot of work. Upside: We
> really would provide the image processing capabilities.
>
> What do others think? Personally, I always wanted to have a better
> designed Image Library with a smaller, but well tested subset of
> ImageProcessing Algos that are really useful.
>
>
>> Goodluck with getting that done though. I doubt we will see a new
>> OpenCV release for awhile... and people will be using 2.0 for a long
>> time to come...
> No wonder; hacking OpenCV code is as ugly as coding can get.
>
> Cheers,
> Holger
>
>>
>> 2009/11/4 St?fan van der Walt <ste... at sun.ac.za>:
>>
>>
>>
>>
>>
>> > 2009/11/4 Chris Colbert <sccolb... at gmail.com>:
>>
>> >> OpenCV has a ___version___ header file.
>>
>> > We can only access that if it exposed as a function, though, so maybe
>> > they can help us out.
>>
>> > Cheers
>> > St?fan


From stefan at sun.ac.za  Wed Nov  4 08:55:44 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 4 Nov 2009 15:55:44 +0200
Subject: OpenCV 2 or 1
In-Reply-To: <7f014ea60911040502y7d5a133cqd047a8d9947032ab@mail.gmail.com>
References: <4111c9d3-6ae0-4c2c-be69-7875043d9b23@p8g2000yqb.googlegroups.com> 
	<9457e7c80911032321m3499d5b8i9d8058325a04ba23@mail.gmail.com> 
	<dde7764a0911040111n2873f7fek1d6c5a6650db4855@mail.gmail.com> 
	<7f014ea60911040124m46a272b9s7158efe6ce9be4f4@mail.gmail.com> 
	<9457e7c80911040226h537c00b2vdcb68b90c2f4e6e9@mail.gmail.com> 
	<7f014ea60911040228q728d6b25q2b889f54bc2fdc6c@mail.gmail.com> 
	<9457e7c80911040320k675f70a0s2a5872ddbfecfffa@mail.gmail.com> 
	<7f014ea60911040328ic79f38aj7304fe1195c7b41f@mail.gmail.com> 
	<d0328ba1-8a2b-48c3-b5e7-df6944af0a12@d10g2000yqh.googlegroups.com> 
	<7f014ea60911040502y7d5a133cqd047a8d9947032ab@mail.gmail.com>
Message-ID: <9457e7c80911040555p62a723c4nef2e63fa7fdbb55@mail.gmail.com>

2009/11/4 Chris Colbert <sccolbert at gmail.com>:
>
> Im all for a big glaring "OpenCV >= 2.0 required if you want to use
> opencv extensions"

This does look like the most painless way forward.  Chris, would you
mind putting up a big notice in the OpenCV docs?

Thanks
St?fan


From stefan at sun.ac.za  Wed Nov  4 09:04:20 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 4 Nov 2009 16:04:20 +0200
Subject: Pending release of 0.3
In-Reply-To: <a2587f3b-7a41-482d-82af-72790e33345f@m16g2000yqc.googlegroups.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com> 
	<8d3755aa-4081-4470-b688-65776f2ad765@p35g2000yqh.googlegroups.com> 
	<7f014ea60911040144x709531a2w49677946421ac8e2@mail.gmail.com> 
	<7f014ea60911040147n7593e2d0iaa5da615b421718d@mail.gmail.com> 
	<9457e7c80911040318s505466c9m60b62b8de572241c@mail.gmail.com> 
	<7f014ea60911040326m44bb208cwb77d4f4a1fd19278@mail.gmail.com> 
	<a2587f3b-7a41-482d-82af-72790e33345f@m16g2000yqc.googlegroups.com>
Message-ID: <9457e7c80911040604u74031e6cu189e58a021a70535@mail.gmail.com>

2009/11/4 SirVer <sirver at gmx.de>:
> Stefan, concerning my GUI branch:
> I played around with pyqt and QImages and they just couldn't deliver
> what I needed: Speed.

I'd like to see some benchmarks that support this, because it should
be the cost of 2 python calls + whatever time the GUI uses.  QImage is
fast when loading directly from a numpy array.  I'm not sure, with the
copying that you have to do into a texture, that OpenGL can do any
better.

Regards
St?fan


From ralf.gommers at googlemail.com  Wed Nov  4 10:28:06 2009
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Wed, 4 Nov 2009 16:28:06 +0100
Subject: OpenCV 2 or 1
In-Reply-To: <9457e7c80911040555p62a723c4nef2e63fa7fdbb55@mail.gmail.com>
References: <4111c9d3-6ae0-4c2c-be69-7875043d9b23@p8g2000yqb.googlegroups.com>
	 <dde7764a0911040111n2873f7fek1d6c5a6650db4855@mail.gmail.com>
	 <7f014ea60911040124m46a272b9s7158efe6ce9be4f4@mail.gmail.com>
	 <9457e7c80911040226h537c00b2vdcb68b90c2f4e6e9@mail.gmail.com>
	 <7f014ea60911040228q728d6b25q2b889f54bc2fdc6c@mail.gmail.com>
	 <9457e7c80911040320k675f70a0s2a5872ddbfecfffa@mail.gmail.com>
	 <7f014ea60911040328ic79f38aj7304fe1195c7b41f@mail.gmail.com>
	 <d0328ba1-8a2b-48c3-b5e7-df6944af0a12@d10g2000yqh.googlegroups.com>
	 <7f014ea60911040502y7d5a133cqd047a8d9947032ab@mail.gmail.com>
	 <9457e7c80911040555p62a723c4nef2e63fa7fdbb55@mail.gmail.com>
Message-ID: <dde7764a0911040728g1f9ebbbes4f00336de99129de@mail.gmail.com>

2009/11/4 St?fan van der Walt <stefan at sun.ac.za>

>
> 2009/11/4 Chris Colbert <sccolbert at gmail.com>:
> >
> > Im all for a big glaring "OpenCV >= 2.0 required if you want to use
> > opencv extensions"
>
> This does look like the most painless way forward.  Chris, would you
> mind putting up a big notice in the OpenCV docs?
>
>
A notice is good but does not really solve the issue right? If you need to
have 1.x on your computer for whatever reason, you get crashes anyway when
running the tests.

I like Holger's option b:

> b) Determine at run time if the user has OpenCV 1 installed and ABORT
> then in a pythonic fashion. I know of no portable way to pull this
> off; one could only check for relative positions of functions in the
> binaries or so. Nice code, nice distribution, very hard to implement.

Not sure if this works, but could you use multiprocess to import opencv and
run a function known to fail in 1.x in a separate process. Then if it works,
write something to a file, and read that file. If you avoid any shared
objects this may work.

Alternatively, locate the opencv header somehow, and parse it.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20091104/2a105d00/attachment.html>

From sccolbert at gmail.com  Wed Nov  4 11:32:35 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Wed, 4 Nov 2009 17:32:35 +0100
Subject: Updates to fancy imshow widget and ColorMixer
Message-ID: <7f014ea60911040832r6dea2f61j161b3eed0629a5a3@mail.gmail.com>

Hey Everyone,

I've made some improvements to the fancy imshow widget and the ColorMixer.

The ColorMixer now supports a brightness function.

And the fancy imshow widget now includes labeled sliders, a function
selector combo box, a commit button and a revert button.

Basically, changes will persist between combo-box selections, only if
you commit changes. Otherwise, the image is reverted to the most
recent commit state.

The revert button does a hard reset to the very original image.

Please grab everything from my io branch and give it a run through.

I think the next thing I will add is hsv support and a histogram under
the image.

Let me know what else you want!

Thanks!

Chris


From sccolbert at gmail.com  Wed Nov  4 11:38:22 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Wed, 4 Nov 2009 17:38:22 +0100
Subject: OpenCV 2 or 1
In-Reply-To: <dde7764a0911040728g1f9ebbbes4f00336de99129de@mail.gmail.com>
References: <4111c9d3-6ae0-4c2c-be69-7875043d9b23@p8g2000yqb.googlegroups.com>
	 <7f014ea60911040124m46a272b9s7158efe6ce9be4f4@mail.gmail.com>
	 <9457e7c80911040226h537c00b2vdcb68b90c2f4e6e9@mail.gmail.com>
	 <7f014ea60911040228q728d6b25q2b889f54bc2fdc6c@mail.gmail.com>
	 <9457e7c80911040320k675f70a0s2a5872ddbfecfffa@mail.gmail.com>
	 <7f014ea60911040328ic79f38aj7304fe1195c7b41f@mail.gmail.com>
	 <d0328ba1-8a2b-48c3-b5e7-df6944af0a12@d10g2000yqh.googlegroups.com>
	 <7f014ea60911040502y7d5a133cqd047a8d9947032ab@mail.gmail.com>
	 <9457e7c80911040555p62a723c4nef2e63fa7fdbb55@mail.gmail.com>
	 <dde7764a0911040728g1f9ebbbes4f00336de99129de@mail.gmail.com>
Message-ID: <7f014ea60911040838x7800939dr1c55e4250fda67bd@mail.gmail.com>

I would rather make a global module variable in the OpenCV files that
a user can set to the path of their OpenCV 2.0 libs if they have more
than one version installed.

I see three situations:
1) a user wants to use scikits and doesnt have opencv
 - so they follow the build instructions and build 2.0 - no problems
2) a user wants to use scikits and has opencv 1.x
 - so they remove 1.x and build 2.0 - no problems
3) a user wants to use scikits and has opencv 1.x but CANT get rid of
it because they are using it for other things.
 - THIS user is a power user and shouldnt mind setting a variable in a
file to point to their 2.0 libs.

Cheers!

Chris

On Wed, Nov 4, 2009 at 4:28 PM, Ralf Gommers
<ralf.gommers at googlemail.com> wrote:
>
>
> 2009/11/4 St?fan van der Walt <stefan at sun.ac.za>
>>
>> 2009/11/4 Chris Colbert <sccolbert at gmail.com>:
>> >
>> > Im all for a big glaring "OpenCV >= 2.0 required if you want to use
>> > opencv extensions"
>>
>> This does look like the most painless way forward. ?Chris, would you
>> mind putting up a big notice in the OpenCV docs?
>>
>
> A notice is good but does not really solve the issue right? If you need to
> have 1.x on your computer for whatever reason, you get crashes anyway when
> running the tests.
>
> I like Holger's option b:
>
>> b) Determine at run time if the user has OpenCV 1 installed and ABORT
>> then in a pythonic fashion. I know of no portable way to pull this
>> off; one could only check for relative positions of functions in the
>> binaries or so. Nice code, nice distribution, very hard to implement.
>
> Not sure if this works, but could you use multiprocess to import opencv and
> run a function known to fail in 1.x in a separate process. Then if it works,
> write something to a file, and read that file. If you avoid any shared
> objects this may work.
>
> Alternatively, locate the opencv header somehow, and parse it.
>
> Cheers,
> Ralf
>
>


From sccolbert at gmail.com  Wed Nov  4 11:39:04 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Wed, 4 Nov 2009 17:39:04 +0100
Subject: OpenCV 2 or 1
In-Reply-To: <7f014ea60911040838x7800939dr1c55e4250fda67bd@mail.gmail.com>
References: <4111c9d3-6ae0-4c2c-be69-7875043d9b23@p8g2000yqb.googlegroups.com>
	 <9457e7c80911040226h537c00b2vdcb68b90c2f4e6e9@mail.gmail.com>
	 <7f014ea60911040228q728d6b25q2b889f54bc2fdc6c@mail.gmail.com>
	 <9457e7c80911040320k675f70a0s2a5872ddbfecfffa@mail.gmail.com>
	 <7f014ea60911040328ic79f38aj7304fe1195c7b41f@mail.gmail.com>
	 <d0328ba1-8a2b-48c3-b5e7-df6944af0a12@d10g2000yqh.googlegroups.com>
	 <7f014ea60911040502y7d5a133cqd047a8d9947032ab@mail.gmail.com>
	 <9457e7c80911040555p62a723c4nef2e63fa7fdbb55@mail.gmail.com>
	 <dde7764a0911040728g1f9ebbbes4f00336de99129de@mail.gmail.com>
	 <7f014ea60911040838x7800939dr1c55e4250fda67bd@mail.gmail.com>
Message-ID: <7f014ea60911040839q3e70850nd5f464a192c7fe7f@mail.gmail.com>

There are so many different ways that people can configure their
system. I think it fair for us to say, "if you want to do X you must
have Y, otherwise you have to do Z"



On Wed, Nov 4, 2009 at 5:38 PM, Chris Colbert <sccolbert at gmail.com> wrote:
> I would rather make a global module variable in the OpenCV files that
> a user can set to the path of their OpenCV 2.0 libs if they have more
> than one version installed.
>
> I see three situations:
> 1) a user wants to use scikits and doesnt have opencv
> ?- so they follow the build instructions and build 2.0 - no problems
> 2) a user wants to use scikits and has opencv 1.x
> ?- so they remove 1.x and build 2.0 - no problems
> 3) a user wants to use scikits and has opencv 1.x but CANT get rid of
> it because they are using it for other things.
> ?- THIS user is a power user and shouldnt mind setting a variable in a
> file to point to their 2.0 libs.
>
> Cheers!
>
> Chris
>
> On Wed, Nov 4, 2009 at 4:28 PM, Ralf Gommers
> <ralf.gommers at googlemail.com> wrote:
>>
>>
>> 2009/11/4 St?fan van der Walt <stefan at sun.ac.za>
>>>
>>> 2009/11/4 Chris Colbert <sccolbert at gmail.com>:
>>> >
>>> > Im all for a big glaring "OpenCV >= 2.0 required if you want to use
>>> > opencv extensions"
>>>
>>> This does look like the most painless way forward. ?Chris, would you
>>> mind putting up a big notice in the OpenCV docs?
>>>
>>
>> A notice is good but does not really solve the issue right? If you need to
>> have 1.x on your computer for whatever reason, you get crashes anyway when
>> running the tests.
>>
>> I like Holger's option b:
>>
>>> b) Determine at run time if the user has OpenCV 1 installed and ABORT
>>> then in a pythonic fashion. I know of no portable way to pull this
>>> off; one could only check for relative positions of functions in the
>>> binaries or so. Nice code, nice distribution, very hard to implement.
>>
>> Not sure if this works, but could you use multiprocess to import opencv and
>> run a function known to fail in 1.x in a separate process. Then if it works,
>> write something to a file, and read that file. If you avoid any shared
>> objects this may work.
>>
>> Alternatively, locate the opencv header somehow, and parse it.
>>
>> Cheers,
>> Ralf
>>
>>
>


From ralf.gommers at googlemail.com  Wed Nov  4 14:11:30 2009
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Wed, 4 Nov 2009 20:11:30 +0100
Subject: OpenCV 2 or 1
In-Reply-To: <7f014ea60911040839q3e70850nd5f464a192c7fe7f@mail.gmail.com>
References: <4111c9d3-6ae0-4c2c-be69-7875043d9b23@p8g2000yqb.googlegroups.com>
	 <7f014ea60911040228q728d6b25q2b889f54bc2fdc6c@mail.gmail.com>
	 <9457e7c80911040320k675f70a0s2a5872ddbfecfffa@mail.gmail.com>
	 <7f014ea60911040328ic79f38aj7304fe1195c7b41f@mail.gmail.com>
	 <d0328ba1-8a2b-48c3-b5e7-df6944af0a12@d10g2000yqh.googlegroups.com>
	 <7f014ea60911040502y7d5a133cqd047a8d9947032ab@mail.gmail.com>
	 <9457e7c80911040555p62a723c4nef2e63fa7fdbb55@mail.gmail.com>
	 <dde7764a0911040728g1f9ebbbes4f00336de99129de@mail.gmail.com>
	 <7f014ea60911040838x7800939dr1c55e4250fda67bd@mail.gmail.com>
	 <7f014ea60911040839q3e70850nd5f464a192c7fe7f@mail.gmail.com>
Message-ID: <dde7764a0911041111i29a77687s7c6b7023d6120061@mail.gmail.com>

On Wed, Nov 4, 2009 at 5:39 PM, Chris Colbert <sccolbert at gmail.com> wrote:

>
> There are so many different ways that people can configure their
> system. I think it fair for us to say, "if you want to do X you must
> have Y, otherwise you have to do Z"
>
>
> Sure.

>
> On Wed, Nov 4, 2009 at 5:38 PM, Chris Colbert <sccolbert at gmail.com> wrote:
> > I would rather make a global module variable in the OpenCV files that
> > a user can set to the path of their OpenCV 2.0 libs if they have more
> > than one version installed.
> >
> > I see three situations:
> > 1) a user wants to use scikits and doesnt have opencv
> >  - so they follow the build instructions and build 2.0 - no problems
>

I assume you mean "if he needs this opencv functionality". Please keep it
optional.


> > 2) a user wants to use scikits and has opencv 1.x
> >  - so they remove 1.x and build 2.0 - no problems
> > 3) a user wants to use scikits and has opencv 1.x but CANT get rid of
> > it because they are using it for other things.
> >  - THIS user is a power user and shouldnt mind setting a variable in a
> > file to point to their 2.0 libs.
> >
>

Easy to do, and would only affect a few users. If this file is under version
control that may be very annoying for developing though. If you set the
variable you can never fast-forward anymore.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20091104/0389e2c3/attachment.html>

From ralf.gommers at googlemail.com  Wed Nov  4 14:25:27 2009
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Wed, 4 Nov 2009 20:25:27 +0100
Subject: Updates to fancy imshow widget and ColorMixer
In-Reply-To: <7f014ea60911040832r6dea2f61j161b3eed0629a5a3@mail.gmail.com>
References: <7f014ea60911040832r6dea2f61j161b3eed0629a5a3@mail.gmail.com>
Message-ID: <dde7764a0911041125p58291b41k76014f19be1a7b73@mail.gmail.com>

On Wed, Nov 4, 2009 at 5:32 PM, Chris Colbert <sccolbert at gmail.com> wrote:

>
> Hey Everyone,
>
> I've made some improvements to the fancy imshow widget and the ColorMixer.
>
> The ColorMixer now supports a brightness function.
>
> And the fancy imshow widget now includes labeled sliders, a function
> selector combo box, a commit button and a revert button.
>
> Basically, changes will persist between combo-box selections, only if
> you commit changes. Otherwise, the image is reverted to the most
> recent commit state.
>
> The revert button does a hard reset to the very original image.
>
> Please grab everything from my io branch and give it a run through.
>
> I think the next thing I will add is hsv support and a histogram under
> the image.
>
> You're really on a roll here, thanks Chris.


> Let me know what else you want!
>

Is there a save button? Maybe connected to an imsave plugin function?

I won't be able to try it for a while, but keep it coming!

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20091104/4e9a5348/attachment.html>

From tsyu80 at gmail.com  Wed Nov  4 20:46:41 2009
From: tsyu80 at gmail.com (Tony S Yu)
Date: Wed, 4 Nov 2009 20:46:41 -0500
Subject: Build requirements
Message-ID: <F87EB576-A552-4077-AED2-4D83FC44C7CC@gmail.com>

Hi,

I tried running scikits.image on Python 2.5 and noticed that Python  
2.6 is required. (I got some errors for enhanced property decorators,  
which were introduced in 2.6.) I'm not arguing against this  
requirement, but this error made me think it'd be nice to have a list  
of requirements.

I've added a "doc" branch with a requirements list. I don't really  
know the internals of the scikit, so the list is pretty rough.

On a side note, I'm curious about the overlap of functionality in the  
opencv module and scipy.ndimage. Since scipy is already required, is  
there an advantage to using the duplicated functions in  
scikits.opencv? (Most of the functions in that module have no ndimage  
counterpart, but I'm curious about the ones that do.) Similarly, some  
of the filters provided by CellProfiler (listed as suggested code to  
adapt on the "How to contribute" page) have counterparts in  
scipy.ndimage.

Cheers,
-Tony



From stefan at sun.ac.za  Wed Nov  4 14:14:33 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 4 Nov 2009 21:14:33 +0200
Subject: OpenCV 2 or 1
In-Reply-To: <dde7764a0911041111i29a77687s7c6b7023d6120061@mail.gmail.com>
References: <4111c9d3-6ae0-4c2c-be69-7875043d9b23@p8g2000yqb.googlegroups.com> 
	<9457e7c80911040320k675f70a0s2a5872ddbfecfffa@mail.gmail.com> 
	<7f014ea60911040328ic79f38aj7304fe1195c7b41f@mail.gmail.com> 
	<d0328ba1-8a2b-48c3-b5e7-df6944af0a12@d10g2000yqh.googlegroups.com> 
	<7f014ea60911040502y7d5a133cqd047a8d9947032ab@mail.gmail.com> 
	<9457e7c80911040555p62a723c4nef2e63fa7fdbb55@mail.gmail.com> 
	<dde7764a0911040728g1f9ebbbes4f00336de99129de@mail.gmail.com> 
	<7f014ea60911040838x7800939dr1c55e4250fda67bd@mail.gmail.com> 
	<7f014ea60911040839q3e70850nd5f464a192c7fe7f@mail.gmail.com> 
	<dde7764a0911041111i29a77687s7c6b7023d6120061@mail.gmail.com>
Message-ID: <9457e7c80911041114k64d12a7dj910569d612de9821@mail.gmail.com>

2009/11/4 Ralf Gommers <ralf.gommers at googlemail.com>:
>> > 3) a user wants to use scikits and has opencv 1.x but CANT get rid of
>> > it because they are using it for other things.
>> > ?- THIS user is a power user and shouldnt mind setting a variable in a
>> > file to point to their 2.0 libs.
>> >
> Easy to do, and would only affect a few users. If this file is under version
> control that may be very annoying for developing though. If you set the
> variable you can never fast-forward anymore.

The user already has a variable like this in LD_LIBRARY_PATH, so I
don't think we need to do anything other than document the way we find
the library.

St?fan


From tsyu80 at gmail.com  Wed Nov  4 21:56:41 2009
From: tsyu80 at gmail.com (Tony S Yu)
Date: Wed, 4 Nov 2009 21:56:41 -0500
Subject: Build requirements
In-Reply-To: <7f014ea60911041758t251766a5h79abf1a067bfd31b@mail.gmail.com>
References: <F87EB576-A552-4077-AED2-4D83FC44C7CC@gmail.com> <7f014ea60911041758t251766a5h79abf1a067bfd31b@mail.gmail.com>
Message-ID: <642812AC-9E5D-440B-971E-BF97B25E07DF@gmail.com>


On Nov 4, 2009, at 8:58 PM, Chris Colbert wrote:

>
> Hey Tony,
>
> Thanks for the report.
>
> Can you paste the error you are getting so I know exactly what
> decorator it is concering?, there may be a way to change it to work
> with Python 2.5

The error I got came from importing the io module.

 >>> import scikits.image.io
Traceback (most recent call last):
   File "<string>", line 1, in <module>
   File "/Users/Tony/python/devel/scikits.image/scikits/image/io/ 
__init__.py", line 15, in <module>
     from collection import *
   File "/Users/Tony/python/devel/scikits.image/scikits/image/io/ 
collection.py", line 157, in <module>
     class ImageCollection(object):
   File "/Users/Tony/python/devel/scikits.image/scikits/image/io/ 
collection.py", line 241, in ImageCollection
     @as_grey.setter
AttributeError: 'property' object has no attribute 'setter'

This error should be easy to fix, but I thought that using Python 2.6  
might be intentional; i.e. that was the intended target. I guess it's  
not clear which python the scikit targets---hence the requirements  
file :). Does the scikit target the same python version as scipy?

>
> There is some overlap between scipy.ndimage and the OpenCV stuff. But
> realize, the OpenCV in the scikit are just wrappers for the OpenCV
> libraries, of which you need at least version 2.0 (there were some
> backwards incompatible changes made in 2.0). That said, my personal
> experience is that OpenCV is much faster than the routines in ndimage.
> I have timed the OpenCV 2D convlution at 100x - 1000x faster than
> ndimage.

This performance difference is exactly what I was curious about. Just  
out of curiosity, is it possible to rename the wrapped functions---the  
cv prefix seems redundant. (I don't actually have opencv installed;  
I'm just trying to cause trouble. ;)

>
> OpenCV is not a HARD requirement for the scikit. You can still install
> it and use everything else without having the opencv libs on your
> machine, but if and when you add them, the wrappers will "just work",
> you wont need to rebuild the scikit.

Agreed, I have the requirements separated into required and optional.

Thanks,
-Tony

>
> Cheers!
>
> Chris


From sccolbert at gmail.com  Wed Nov  4 19:33:29 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Thu, 5 Nov 2009 01:33:29 +0100
Subject: OpenCV 2 or 1
In-Reply-To: <9457e7c80911041114k64d12a7dj910569d612de9821@mail.gmail.com>
References: <4111c9d3-6ae0-4c2c-be69-7875043d9b23@p8g2000yqb.googlegroups.com>
	 <7f014ea60911040328ic79f38aj7304fe1195c7b41f@mail.gmail.com>
	 <d0328ba1-8a2b-48c3-b5e7-df6944af0a12@d10g2000yqh.googlegroups.com>
	 <7f014ea60911040502y7d5a133cqd047a8d9947032ab@mail.gmail.com>
	 <9457e7c80911040555p62a723c4nef2e63fa7fdbb55@mail.gmail.com>
	 <dde7764a0911040728g1f9ebbbes4f00336de99129de@mail.gmail.com>
	 <7f014ea60911040838x7800939dr1c55e4250fda67bd@mail.gmail.com>
	 <7f014ea60911040839q3e70850nd5f464a192c7fe7f@mail.gmail.com>
	 <dde7764a0911041111i29a77687s7c6b7023d6120061@mail.gmail.com>
	 <9457e7c80911041114k64d12a7dj910569d612de9821@mail.gmail.com>
Message-ID: <7f014ea60911041633u68ec006cp5e5d8395a2dde9f5@mail.gmail.com>

so let's say this:

1) If you want to use the opencv facilities, you need OpenCV >= 2.0
2) Because people may want more than one OpenCV version installed at a time,
we will first make an attempt to find the variable OPENCV2 in LD_LIBRARY_PATH.
 - If the variable exists, but the dll loads fail, we abort the
library import with a message to stdout.
 - if the variable does not exist, we assume that OpenCV 2.0 is the
only version installed on the system
   and continue with the loading mechanism in place. If the user did
not heed our instructions and
   instead is using OpenCV < 2.0, and something crashes. Shame on them.
- if no library is found, fail gracefully as usual.


How does that sound?

Cheers!

Chris


2009/11/4 St?fan van der Walt <stefan at sun.ac.za>:
>
> 2009/11/4 Ralf Gommers <ralf.gommers at googlemail.com>:
>>> > 3) a user wants to use scikits and has opencv 1.x but CANT get rid of
>>> > it because they are using it for other things.
>>> > ?- THIS user is a power user and shouldnt mind setting a variable in a
>>> > file to point to their 2.0 libs.
>>> >
>> Easy to do, and would only affect a few users. If this file is under version
>> control that may be very annoying for developing though. If you set the
>> variable you can never fast-forward anymore.
>
> The user already has a variable like this in LD_LIBRARY_PATH, so I
> don't think we need to do anything other than document the way we find
> the library.
>
> St?fan
>


From sccolbert at gmail.com  Wed Nov  4 19:42:52 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Thu, 5 Nov 2009 01:42:52 +0100
Subject: Updates to fancy imshow widget and ColorMixer
In-Reply-To: <dde7764a0911041125p58291b41k76014f19be1a7b73@mail.gmail.com>
References: <7f014ea60911040832r6dea2f61j161b3eed0629a5a3@mail.gmail.com>
	 <dde7764a0911041125p58291b41k76014f19be1a7b73@mail.gmail.com>
Message-ID: <7f014ea60911041642h36edf7b2gf2a797a535bb0e0b@mail.gmail.com>

Hey Everyone,

More updates tonight for the ColorMixer and the fancy imshow widget.

I added HSV support to color mixer, so you can now manipulate the
image from HSV space.

I also updated the mouse tracking to display the RGB, HSV, and X-Y pos
of the cursor when your mouse is over the image.

Its in my IO branch, but I have a feeling that Stefan is going to pull it soon.

But please, put it through the grinder and tell me what needs changing.

This is what we have so far in the widget:
- RGB manipulation (additive and multiplicative)
- HSV manipulation (additive and multiplicative)
- Brightness (offset and factor)
- RGB, HSV, X-Y pos data interrogation
- Auto image scaling on resize

Future plans:
- contrast manipulation
- a save to file button
- a save to variable button (this could be tricky)
- Histograms!
- zooming (this could also be harder than it first seems)
- resizing bars

So I'll start with the easy stuff first.

Cheers!

Chris



On Wed, Nov 4, 2009 at 8:25 PM, Ralf Gommers
<ralf.gommers at googlemail.com> wrote:
>
>
> On Wed, Nov 4, 2009 at 5:32 PM, Chris Colbert <sccolbert at gmail.com> wrote:
>>
>> Hey Everyone,
>>
>> I've made some improvements to the fancy imshow widget and the ColorMixer.
>>
>> The ColorMixer now supports a brightness function.
>>
>> And the fancy imshow widget now includes labeled sliders, a function
>> selector combo box, a commit button and a revert button.
>>
>> Basically, changes will persist between combo-box selections, only if
>> you commit changes. Otherwise, the image is reverted to the most
>> recent commit state.
>>
>> The revert button does a hard reset to the very original image.
>>
>> Please grab everything from my io branch and give it a run through.
>>
>> I think the next thing I will add is hsv support and a histogram under
>> the image.
>>
> You're really on a roll here, thanks Chris.
>
>>
>> Let me know what else you want!
>
> Is there a save button? Maybe connected to an imsave plugin function?
>
> I won't be able to try it for a while, but keep it coming!
>
> Cheers,
> Ralf
>


From sccolbert at gmail.com  Wed Nov  4 20:58:04 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Thu, 5 Nov 2009 02:58:04 +0100
Subject: Build requirements
In-Reply-To: <F87EB576-A552-4077-AED2-4D83FC44C7CC@gmail.com>
References: <F87EB576-A552-4077-AED2-4D83FC44C7CC@gmail.com>
Message-ID: <7f014ea60911041758t251766a5h79abf1a067bfd31b@mail.gmail.com>

Hey Tony,

Thanks for the report.

Can you paste the error you are getting so I know exactly what
decorator it is concering?, there may be a way to change it to work
with Python 2.5

There is some overlap between scipy.ndimage and the OpenCV stuff. But
realize, the OpenCV in the scikit are just wrappers for the OpenCV
libraries, of which you need at least version 2.0 (there were some
backwards incompatible changes made in 2.0). That said, my personal
experience is that OpenCV is much faster than the routines in ndimage.
I have timed the OpenCV 2D convlution at 100x - 1000x faster than
ndimage.

OpenCV is not a HARD requirement for the scikit. You can still install
it and use everything else without having the opencv libs on your
machine, but if and when you add them, the wrappers will "just work",
you wont need to rebuild the scikit.

Cheers!

Chris

On Thu, Nov 5, 2009 at 2:46 AM, Tony S Yu <tsyu80 at gmail.com> wrote:
>
> Hi,
>
> I tried running scikits.image on Python 2.5 and noticed that Python 2.6 is
> required. (I got some errors for enhanced property decorators, which were
> introduced in 2.6.) I'm not arguing against this requirement, but this error
> made me think it'd be nice to have a list of requirements.
>
> I've added a "doc" branch with a requirements list. I don't really know the
> internals of the scikit, so the list is pretty rough.
>
> On a side note, I'm curious about the overlap of functionality in the opencv
> module and scipy.ndimage. Since scipy is already required, is there an
> advantage to using the duplicated functions in scikits.opencv? (Most of the
> functions in that module have no ndimage counterpart, but I'm curious about
> the ones that do.) Similarly, some of the filters provided by CellProfiler
> (listed as suggested code to adapt on the "How to contribute" page) have
> counterparts in scipy.ndimage.
>
> Cheers,
> -Tony
>
>


From sirver at gmx.de  Thu Nov  5 09:16:21 2009
From: sirver at gmx.de (SirVer)
Date: Thu, 5 Nov 2009 06:16:21 -0800 (PST)
Subject: Pending release of 0.3
In-Reply-To: <9457e7c80911040604u74031e6cu189e58a021a70535@mail.gmail.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com> 
	<8d3755aa-4081-4470-b688-65776f2ad765@p35g2000yqh.googlegroups.com> 
	<7f014ea60911040144x709531a2w49677946421ac8e2@mail.gmail.com> 
	<7f014ea60911040147n7593e2d0iaa5da615b421718d@mail.gmail.com> 
	<9457e7c80911040318s505466c9m60b62b8de572241c@mail.gmail.com> 
	<7f014ea60911040326m44bb208cwb77d4f4a1fd19278@mail.gmail.com> 
	<a2587f3b-7a41-482d-82af-72790e33345f@m16g2000yqc.googlegroups.com> 
	<9457e7c80911040604u74031e6cu189e58a021a70535@mail.gmail.com>
Message-ID: <5c069b31-2117-45e1-b9d6-0c1bc0021490@j19g2000yqk.googlegroups.com>

Hi,


On 4 Nov., 15:04, St?fan van der Walt <ste... at sun.ac.za> wrote:
> 2009/11/4 SirVer <sir... at gmx.de>:
>
> > Stefan, concerning my GUI branch:
> > I played around with pyqt and QImages and they just couldn't deliver
> > what I needed: Speed.
>
> I'd like to see some benchmarks that support this, because it should
> be the cost of 2 python calls + whatever time the GUI uses. ?QImage is
> fast when loading directly from a numpy array. ?I'm not sure, with the
> copying that you have to do into a texture, that OpenGL can do any
> better.
I did some benchmarks, but unfortunately I do not have the code
around. I created QImages and painted them directly in PyQt. It was
reasonable fast, but I couldn't reach the performance I have with a
QGLWidget which delivers easily 300fps or 60fps in 12 different
windows. I'd rather not hack this again since this issue is somewhat
settled for me and I'd prefer spending my coding time on other itches
I have.

I still think that PyQt is a much bigger dependency then PyOpenGL -
and even so: both are optional and only needed when GUI stuff in real
time should be performed.

Cheers,
Holger


>
> Regards
> St?fan


From sirver at gmx.de  Thu Nov  5 09:44:38 2009
From: sirver at gmx.de (SirVer)
Date: Thu, 5 Nov 2009 06:44:38 -0800 (PST)
Subject: Pending release of 0.3
In-Reply-To: <7f014ea60911050627r2cdfa462odfeb34def299b31e@mail.gmail.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com> 
	<8d3755aa-4081-4470-b688-65776f2ad765@p35g2000yqh.googlegroups.com> 
	<7f014ea60911040144x709531a2w49677946421ac8e2@mail.gmail.com> 
	<7f014ea60911040147n7593e2d0iaa5da615b421718d@mail.gmail.com> 
	<9457e7c80911040318s505466c9m60b62b8de572241c@mail.gmail.com> 
	<7f014ea60911040326m44bb208cwb77d4f4a1fd19278@mail.gmail.com> 
	<a2587f3b-7a41-482d-82af-72790e33345f@m16g2000yqc.googlegroups.com> 
	<9457e7c80911040604u74031e6cu189e58a021a70535@mail.gmail.com> 
	<5c069b31-2117-45e1-b9d6-0c1bc0021490@j19g2000yqk.googlegroups.com> 
	<7f014ea60911050627r2cdfa462odfeb34def299b31e@mail.gmail.com>
Message-ID: <ef0d4d36-32f2-40d8-b1dd-27fa2c052c92@r24g2000yqd.googlegroups.com>



On 5 Nov., 15:27, Chris Colbert <sccolb... at gmail.com> wrote:
> On Thu, Nov 5, 2009 at 3:16 PM, SirVer <sir... at gmx.de> wrote:
>
> > Hi,
>
> > On 4 Nov., 15:04, St?fan van der Walt <ste... at sun.ac.za> wrote:
> >> 2009/11/4 SirVer <sir... at gmx.de>:
>
> >> > Stefan, concerning my GUI branch:
> >> > I played around with pyqt and QImages and they just couldn't deliver
> >> > what I needed: Speed.
>
> >> I'd like to see some benchmarks that support this, because it should
> >> be the cost of 2 python calls + whatever time the GUI uses. ?QImage is
> >> fast when loading directly from a numpy array. ?I'm not sure, with the
> >> copying that you have to do into a texture, that OpenGL can do any
> >> better.
> > I did some benchmarks, but unfortunately I do not have the code
> > around. I created QImages and painted them directly in PyQt. It was
> > reasonable fast, but I couldn't reach the performance I have with a
> > QGLWidget which delivers easily 300fps or 60fps in 12 different
> > windows. I'd rather not hack this again since this issue is somewhat
> > settled for me and I'd prefer spending my coding time on other itches
> > I have.
>
> > I still think that PyQt is a much bigger dependency then PyOpenGL -
> > and even so: both are optional and only needed when GUI stuff in real
> > time should be performed.
>
> I think you're not really grasping the idea of "plugin"
Well, I understood the principle of plugin quite well; BUT the plugin
architecture does not allow real time display of images right now. It
won't be possible to implement it that way.
AND there are users who will need this and might need it in image
processing tasks. The question here is just if and if yes how to
implement this.

If my code and my attempts are not to be included in scikit.image, so
be it. I will continue to use it anyway; i just think they are useful
and WANT to contribute them to the public.

>
>
>
> > Cheers,
> > Holger
>
> >> Regards
> >> St?fan


From sirver at gmx.de  Thu Nov  5 10:05:36 2009
From: sirver at gmx.de (SirVer)
Date: Thu, 5 Nov 2009 07:05:36 -0800 (PST)
Subject: Pending release of 0.3
In-Reply-To: <7f014ea60911050654j4200d8fal306743f81b3fbf55@mail.gmail.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com> 
	<7f014ea60911040144x709531a2w49677946421ac8e2@mail.gmail.com> 
	<7f014ea60911040147n7593e2d0iaa5da615b421718d@mail.gmail.com> 
	<9457e7c80911040318s505466c9m60b62b8de572241c@mail.gmail.com> 
	<7f014ea60911040326m44bb208cwb77d4f4a1fd19278@mail.gmail.com> 
	<a2587f3b-7a41-482d-82af-72790e33345f@m16g2000yqc.googlegroups.com> 
	<9457e7c80911040604u74031e6cu189e58a021a70535@mail.gmail.com> 
	<5c069b31-2117-45e1-b9d6-0c1bc0021490@j19g2000yqk.googlegroups.com> 
	<7f014ea60911050627r2cdfa462odfeb34def299b31e@mail.gmail.com> 
	<ef0d4d36-32f2-40d8-b1dd-27fa2c052c92@r24g2000yqd.googlegroups.com> 
	<7f014ea60911050654j4200d8fal306743f81b3fbf55@mail.gmail.com>
Message-ID: <a0806486-55c4-4060-8a05-9ee08b625baf@m26g2000yqb.googlegroups.com>



On 5 Nov., 15:54, Chris Colbert <sccolb... at gmail.com> wrote:
> On Thu, Nov 5, 2009 at 3:44 PM, SirVer <sir... at gmx.de> wrote:
>
> > On 5 Nov., 15:27, Chris Colbert <sccolb... at gmail.com> wrote:
> >> On Thu, Nov 5, 2009 at 3:16 PM, SirVer <sir... at gmx.de> wrote:
>
> >> > Hi,
>
> >> > On 4 Nov., 15:04, St?fan van der Walt <ste... at sun.ac.za> wrote:
> >> >> 2009/11/4 SirVer <sir... at gmx.de>:
>
> >> >> > Stefan, concerning my GUI branch:
> >> >> > I played around with pyqt and QImages and they just couldn't deliver
> >> >> > what I needed: Speed.
>
> >> >> I'd like to see some benchmarks that support this, because it should
> >> >> be the cost of 2 python calls + whatever time the GUI uses. ?QImage is
> >> >> fast when loading directly from a numpy array. ?I'm not sure, with the
> >> >> copying that you have to do into a texture, that OpenGL can do any
> >> >> better.
> >> > I did some benchmarks, but unfortunately I do not have the code
> >> > around. I created QImages and painted them directly in PyQt. It was
> >> > reasonable fast, but I couldn't reach the performance I have with a
> >> > QGLWidget which delivers easily 300fps or 60fps in 12 different
> >> > windows. I'd rather not hack this again since this issue is somewhat
> >> > settled for me and I'd prefer spending my coding time on other itches
> >> > I have.
>
> >> > I still think that PyQt is a much bigger dependency then PyOpenGL -
> >> > and even so: both are optional and only needed when GUI stuff in real
> >> > time should be performed.
>
> >> I think you're not really grasping the idea of "plugin"
> > Well, I understood the principle of plugin quite well; BUT the plugin
> > architecture does not allow real time display of images right now. It
> > won't be possible to implement it that way.
> > AND there are users who will need this and might need it in image
> > processing tasks. The question here is just if and if yes how to
> > implement this.
>
> I meant that you make the claim that QT is a heavy dependency, when in
> fact its not a dependency at all unless the individual wants to use
> the qt plugins.
> The scikit, and all it's image process, still function without having
> QT installed.
I understood that; and frankly that is out of question. I only mean IF
they want to
display anything in real time, pyopengl is not a heavy dependency
comparing to Pyqt.


> Further, these imshow() type widgets are primarily meant to be used
> from the interactive interpreter, an environment not best suited for
> real time image acquisition and display.
I use live camera display + annotated images in pylab/ipython every
day; I couldn't do my job without it.

>  that said, the plugin
> archiceture can most certainly be used in the method you speak of. You
> just simply have your imshow() function return the window object, and
> implement an update() or similar method that the consumer can call to
> update the image.
I thought that this was not the way it should go. What I would need
was a kind of update() functionality for each image. I would
also need a kind of annotate functionality, so that the user has the
chance to draw things onto the image (the drawing would not be
backend independent, obviously). That said comes a big but: But as a
user, I would not see the reason to use the plugin architecture then
anymore (the same holds for me and matplotlib: they offer a backend
independent signaling library (for mouse events etc), but every time I
tried to use it, I decided to choose the backend to be qt (and no
longer anything else) and use qt directly for enhanced flexibility).
My point is: the current attempt for the plugin architecture is to
make many backends for image displaying and maybe modification simple.
My aim is in another direction: to offer the user a set of base
classes, that he really wants to extend in his own Programs and which
are NOT backend independent. Maybe scikit.images is not the right
place for this, but that's what i'm here to discuss.

>
>
>
>
> > If my code and my attempts are not to be included in scikit.image, so
> > be it. I will continue to use it anyway; i just think they are useful
> > and WANT to contribute them to the public.
>
> >> > Cheers,
> >> > Holger
>
> >> >> Regards
> >> >> St?fan


From sirver at gmx.de  Thu Nov  5 11:14:50 2009
From: sirver at gmx.de (SirVer)
Date: Thu, 5 Nov 2009 08:14:50 -0800 (PST)
Subject: Pending release of 0.3
In-Reply-To: <7f014ea60911050803x58d166b3h2bbcde8d74aaa957@mail.gmail.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com> 
	<a2587f3b-7a41-482d-82af-72790e33345f@m16g2000yqc.googlegroups.com> 
	<9457e7c80911040604u74031e6cu189e58a021a70535@mail.gmail.com> 
	<5c069b31-2117-45e1-b9d6-0c1bc0021490@j19g2000yqk.googlegroups.com> 
	<7f014ea60911050627r2cdfa462odfeb34def299b31e@mail.gmail.com> 
	<ef0d4d36-32f2-40d8-b1dd-27fa2c052c92@r24g2000yqd.googlegroups.com> 
	<7f014ea60911050654j4200d8fal306743f81b3fbf55@mail.gmail.com> 
	<9457e7c80911050703u4f9e11bdmdfc525656161ba34@mail.gmail.com> 
	<7f014ea60911050724p76c8fcbfv680229b589dce7d6@mail.gmail.com> 
	<7f014ea60911050756k7fca1b38s6801361ce60c9b30@mail.gmail.com> 
	<7f014ea60911050803x58d166b3h2bbcde8d74aaa957@mail.gmail.com>
Message-ID: <c33af287-8157-42d8-b836-53ec510fa8f8@w19g2000yqk.googlegroups.com>

> However, i'm afraid that your current gui may rely on ipython
> -q4thread, which is now deprecated (big mailing list discussion on
> this). So that may throw a wrench in the video portion of it, unless
> we can figure out this pyos_input hook thing.
It infact does. Chris, could you please point me at this discussion?
It is most relevant for my work.

Cheers,
Holger

> But as my previous example shows, its definately possible to fit it
> within the plugin framework.
>
> Cheers!
>
> Chris
>
>
>
> On Thu, Nov 5, 2009 at 4:56 PM, Chris Colbert <sccolb... at gmail.com> wrote:
> > So while i havent yet been able to get the pyos_inputhook thing sorted
> > out, I did time a couple loops.
>
> > For a decent sized image, we can easily get 60fps update rates, and
> > thats including the time for the numpy operations:
>
> > In [5]: img = io.imread('/home/brucewayne/Pictures/failboat_4.jpg')
>
> > In [6]: img.shape
> > Out[6]: (503, 790, 3)
>
> > In [7]: win = io.imshow(img, updateable=True)
>
> > In [8]: def test(img, win):
> > ? ...: ? ? for i in range(30):
> > ? ...: ? ? ? ? img[:] += 1
> > ? ...: ? ? ? ? win.update()
> > ? ...:
> > ? ...:
>
> > In [9]: %timeit test(img, win)
> > 1 loops, best of 3: 564 ms per loop
>
> > one thing to note, I bypassed the prepare_for_display() method that we
> > usually call to make sure an array is contiguous, of the right dtype,
> > etc...
> > I assume if someone wants video, they can prepare the arrays themselves.
>
> > This behavior can also be changed by the plugin writer. For this
> > example, i simply took the easy route and subclassed ImageWindow
>
> > Cheers,
>
> > Chris
>
> > On Thu, Nov 5, 2009 at 4:24 PM, Chris Colbert <sccolb... at gmail.com> wrote:
> >> I was just testing out something along these lines, but I run into the
> >> problem of the the python interpreter not considering time.sleep() as
> >> idle time, thus, it never calls PyOS_InputHook inside of for-loops. So
> >> i'm not quite sure how to get video ?feed to run interactively without
> >> hacking out something like ipython -whatever thread.
>
> >> Mind you, this is not a problem with the plugin architecture, its a
> >> problem with the python interpreter...
>
> >> but maybe i can ctypes into the os_hook and call it at the end of a
> >> loop.... <evil grin>
>
> >> 2009/11/5 St?fan van der Walt <ste... at sun.ac.za>:
>
> >>> 2009/11/5 Chris Colbert <sccolb... at gmail.com>:
> >>>> Further, these imshow() type widgets are primarily meant to be used
> >>>> from the interactive interpreter, an environment not best suited for
> >>>> real time image acquisition and display. that said, the plugin
> >>>> archiceture can most certainly be used in the method you speak of. You
> >>>> just simply have your imshow() function return the window object, and
> >>>> implement an update() or similar method that the consumer can call to
> >>>> update the image.
>
> >>> This could even be accomplished using 'imshow' only. ?The
> >>> WindowManager keeps track of the single window produced, and 'imshow'
> >>> simply grabs that window and updates its current content. ?I'd be
> >>> surprised if we couldn't pump out a large number of frames-per-second
> >>> that way.
>
> >>> St?fan


From sccolbert at gmail.com  Thu Nov  5 04:27:39 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Thu, 5 Nov 2009 10:27:39 +0100
Subject: Build requirements
In-Reply-To: <642812AC-9E5D-440B-971E-BF97B25E07DF@gmail.com>
References: <F87EB576-A552-4077-AED2-4D83FC44C7CC@gmail.com>
	 <7f014ea60911041758t251766a5h79abf1a067bfd31b@mail.gmail.com>
	 <642812AC-9E5D-440B-971E-BF97B25E07DF@gmail.com>
Message-ID: <7f014ea60911050127u1f9e05e4ld0506c48586a56b@mail.gmail.com>

It is possible to change the name of the wrapped functions, but I
don't for two reason:

1) they are the same name as the opencv functions they wrap, so If you
know opencv you'll feel right at home
2) if you do from scikits.image.opencv import *, you get quite a few
names into your namespace, the majority of them begin with cv or CV so
the likelyhood of namespace pollution is low.

Let me know if you have other questions.

I will have a look at that error. Thanks!

Cheers!

Chris

On Thu, Nov 5, 2009 at 3:56 AM, Tony S Yu <tsyu80 at gmail.com> wrote:
>
>
> On Nov 4, 2009, at 8:58 PM, Chris Colbert wrote:
>
>>
>> Hey Tony,
>>
>> Thanks for the report.
>>
>> Can you paste the error you are getting so I know exactly what
>> decorator it is concering?, there may be a way to change it to work
>> with Python 2.5
>
> The error I got came from importing the io module.
>
>>>> import scikits.image.io
> Traceback (most recent call last):
> ?File "<string>", line 1, in <module>
> ?File "/Users/Tony/python/devel/scikits.image/scikits/image/io/__init__.py",
> line 15, in <module>
> ? ?from collection import *
> ?File
> "/Users/Tony/python/devel/scikits.image/scikits/image/io/collection.py",
> line 157, in <module>
> ? ?class ImageCollection(object):
> ?File
> "/Users/Tony/python/devel/scikits.image/scikits/image/io/collection.py",
> line 241, in ImageCollection
> ? ?@as_grey.setter
> AttributeError: 'property' object has no attribute 'setter'
>
> This error should be easy to fix, but I thought that using Python 2.6 might
> be intentional; i.e. that was the intended target. I guess it's not clear
> which python the scikit targets---hence the requirements file :). Does the
> scikit target the same python version as scipy?
>
>>
>> There is some overlap between scipy.ndimage and the OpenCV stuff. But
>> realize, the OpenCV in the scikit are just wrappers for the OpenCV
>> libraries, of which you need at least version 2.0 (there were some
>> backwards incompatible changes made in 2.0). That said, my personal
>> experience is that OpenCV is much faster than the routines in ndimage.
>> I have timed the OpenCV 2D convlution at 100x - 1000x faster than
>> ndimage.
>
> This performance difference is exactly what I was curious about. Just out of
> curiosity, is it possible to rename the wrapped functions---the cv prefix
> seems redundant. (I don't actually have opencv installed; I'm just trying to
> cause trouble. ;)
>
>>
>> OpenCV is not a HARD requirement for the scikit. You can still install
>> it and use everything else without having the opencv libs on your
>> machine, but if and when you add them, the wrappers will "just work",
>> you wont need to rebuild the scikit.
>
> Agreed, I have the requirements separated into required and optional.
>
> Thanks,
> -Tony
>
>>
>> Cheers!
>>
>> Chris
>


From sccolbert at gmail.com  Thu Nov  5 06:45:11 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Thu, 5 Nov 2009 12:45:11 +0100
Subject: OpenCV 2 or 1
In-Reply-To: <9457e7c80911050330q79963024u36f7e5e9f5e3f3bc@mail.gmail.com>
References: <4111c9d3-6ae0-4c2c-be69-7875043d9b23@p8g2000yqb.googlegroups.com>
	 <7f014ea60911040502y7d5a133cqd047a8d9947032ab@mail.gmail.com>
	 <9457e7c80911040555p62a723c4nef2e63fa7fdbb55@mail.gmail.com>
	 <dde7764a0911040728g1f9ebbbes4f00336de99129de@mail.gmail.com>
	 <7f014ea60911040838x7800939dr1c55e4250fda67bd@mail.gmail.com>
	 <7f014ea60911040839q3e70850nd5f464a192c7fe7f@mail.gmail.com>
	 <dde7764a0911041111i29a77687s7c6b7023d6120061@mail.gmail.com>
	 <9457e7c80911041114k64d12a7dj910569d612de9821@mail.gmail.com>
	 <7f014ea60911041633u68ec006cp5e5d8395a2dde9f5@mail.gmail.com>
	 <9457e7c80911050330q79963024u36f7e5e9f5e3f3bc@mail.gmail.com>
Message-ID: <7f014ea60911050345j7b96597ew2f0d71b74d923719@mail.gmail.com>

which is already the current behavior :)

2009/11/5 St?fan van der Walt <stefan at sun.ac.za>:
>
> 2009/11/5 Chris Colbert <sccolbert at gmail.com>:
>> 2) Because people may want more than one OpenCV version installed at a time,
>> we will first make an attempt to find the variable OPENCV2 in LD_LIBRARY_PATH.
>> ?- If the variable exists, but the dll loads fail, we abort the
>> library import with a message to stdout.
>> ?- if the variable does not exist, we assume that OpenCV 2.0 is the
>> only version installed on the system
>> ? and continue with the loading mechanism in place. If the user did
>> not heed our instructions and
>> ? instead is using OpenCV < 2.0, and something crashes. Shame on them.
>
> We can even simplify that:
>
> a) scikits.image.opencv requires opencv v2
> b) scikits.image.opencv always loads the first opencv library that can
> be found on LD_LIBRARY_PATH
>
> Regards
> St?fan
>


From stefan at sun.ac.za  Thu Nov  5 06:30:31 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 5 Nov 2009 13:30:31 +0200
Subject: OpenCV 2 or 1
In-Reply-To: <7f014ea60911041633u68ec006cp5e5d8395a2dde9f5@mail.gmail.com>
References: <4111c9d3-6ae0-4c2c-be69-7875043d9b23@p8g2000yqb.googlegroups.com> 
	<d0328ba1-8a2b-48c3-b5e7-df6944af0a12@d10g2000yqh.googlegroups.com> 
	<7f014ea60911040502y7d5a133cqd047a8d9947032ab@mail.gmail.com> 
	<9457e7c80911040555p62a723c4nef2e63fa7fdbb55@mail.gmail.com> 
	<dde7764a0911040728g1f9ebbbes4f00336de99129de@mail.gmail.com> 
	<7f014ea60911040838x7800939dr1c55e4250fda67bd@mail.gmail.com> 
	<7f014ea60911040839q3e70850nd5f464a192c7fe7f@mail.gmail.com> 
	<dde7764a0911041111i29a77687s7c6b7023d6120061@mail.gmail.com> 
	<9457e7c80911041114k64d12a7dj910569d612de9821@mail.gmail.com> 
	<7f014ea60911041633u68ec006cp5e5d8395a2dde9f5@mail.gmail.com>
Message-ID: <9457e7c80911050330q79963024u36f7e5e9f5e3f3bc@mail.gmail.com>

2009/11/5 Chris Colbert <sccolbert at gmail.com>:
> 2) Because people may want more than one OpenCV version installed at a time,
> we will first make an attempt to find the variable OPENCV2 in LD_LIBRARY_PATH.
> ?- If the variable exists, but the dll loads fail, we abort the
> library import with a message to stdout.
> ?- if the variable does not exist, we assume that OpenCV 2.0 is the
> only version installed on the system
> ? and continue with the loading mechanism in place. If the user did
> not heed our instructions and
> ? instead is using OpenCV < 2.0, and something crashes. Shame on them.

We can even simplify that:

a) scikits.image.opencv requires opencv v2
b) scikits.image.opencv always loads the first opencv library that can
be found on LD_LIBRARY_PATH

Regards
St?fan


From stefan at sun.ac.za  Thu Nov  5 06:42:52 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 5 Nov 2009 13:42:52 +0200
Subject: Build requirements
In-Reply-To: <F87EB576-A552-4077-AED2-4D83FC44C7CC@gmail.com>
References: <F87EB576-A552-4077-AED2-4D83FC44C7CC@gmail.com>
Message-ID: <9457e7c80911050342r2328993eh318008e57ff61f45@mail.gmail.com>

Hi Tony

2009/11/5 Tony S Yu <tsyu80 at gmail.com>:
> I tried running scikits.image on Python 2.5 and noticed that Python
> 2.6 is required. (I got some errors for enhanced property decorators,
> which were introduced in 2.6.) I'm not arguing against this
> requirement, but this error made me think it'd be nice to have a list
> of requirements.
>
> I've added a "doc" branch with a requirements list. I don't really
> know the internals of the scikit, so the list is pretty rough.

Thanks, I think a list of dependencies would be good to include in the
docs.  The Python 2.6 dependency must have been accidental, though.

> On a side note, I'm curious about the overlap of functionality in the
> opencv module and scipy.ndimage. Since scipy is already required, is
> there an advantage to using the duplicated functions in
> scikits.opencv? (Most of the functions in that module have no ndimage
> counterpart, but I'm curious about the ones that do.) Similarly, some
> of the filters provided by CellProfiler (listed as suggested code to
> adapt on the "How to contribute" page) have counterparts in
> scipy.ndimage.

Scipy.ndimage provides some low-level image manipulation tools, and we
don't plan to rewrite those unless we have to.  It does not, however,
include a large variety of higher level algorithms, and we wish to
provide those in this scikit.  Like Chris mentioned, the OpenCV
wrappers are a convenient way of exposing an existing well-known
library, but it is not set as a dependency for any of the algorithms
in the scikit.

Regards
St?fan


From sccolbert at gmail.com  Thu Nov  5 09:27:29 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Thu, 5 Nov 2009 15:27:29 +0100
Subject: Pending release of 0.3
In-Reply-To: <5c069b31-2117-45e1-b9d6-0c1bc0021490@j19g2000yqk.googlegroups.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com>
	 <8d3755aa-4081-4470-b688-65776f2ad765@p35g2000yqh.googlegroups.com>
	 <7f014ea60911040144x709531a2w49677946421ac8e2@mail.gmail.com>
	 <7f014ea60911040147n7593e2d0iaa5da615b421718d@mail.gmail.com>
	 <9457e7c80911040318s505466c9m60b62b8de572241c@mail.gmail.com>
	 <7f014ea60911040326m44bb208cwb77d4f4a1fd19278@mail.gmail.com>
	 <a2587f3b-7a41-482d-82af-72790e33345f@m16g2000yqc.googlegroups.com>
	 <9457e7c80911040604u74031e6cu189e58a021a70535@mail.gmail.com>
	 <5c069b31-2117-45e1-b9d6-0c1bc0021490@j19g2000yqk.googlegroups.com>
Message-ID: <7f014ea60911050627r2cdfa462odfeb34def299b31e@mail.gmail.com>

On Thu, Nov 5, 2009 at 3:16 PM, SirVer <sirver at gmx.de> wrote:
>
> Hi,
>
>
> On 4 Nov., 15:04, St?fan van der Walt <ste... at sun.ac.za> wrote:
>> 2009/11/4 SirVer <sir... at gmx.de>:
>>
>> > Stefan, concerning my GUI branch:
>> > I played around with pyqt and QImages and they just couldn't deliver
>> > what I needed: Speed.
>>
>> I'd like to see some benchmarks that support this, because it should
>> be the cost of 2 python calls + whatever time the GUI uses. ?QImage is
>> fast when loading directly from a numpy array. ?I'm not sure, with the
>> copying that you have to do into a texture, that OpenGL can do any
>> better.
> I did some benchmarks, but unfortunately I do not have the code
> around. I created QImages and painted them directly in PyQt. It was
> reasonable fast, but I couldn't reach the performance I have with a
> QGLWidget which delivers easily 300fps or 60fps in 12 different
> windows. I'd rather not hack this again since this issue is somewhat
> settled for me and I'd prefer spending my coding time on other itches
> I have.
>
> I still think that PyQt is a much bigger dependency then PyOpenGL -
> and even so: both are optional and only needed when GUI stuff in real
> time should be performed.

I think you're not really grasping the idea of "plugin"

> Cheers,
> Holger
>
>
>>
>> Regards
>> St?fan


From sccolbert at gmail.com  Thu Nov  5 09:54:22 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Thu, 5 Nov 2009 15:54:22 +0100
Subject: Pending release of 0.3
In-Reply-To: <ef0d4d36-32f2-40d8-b1dd-27fa2c052c92@r24g2000yqd.googlegroups.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com>
	 <7f014ea60911040144x709531a2w49677946421ac8e2@mail.gmail.com>
	 <7f014ea60911040147n7593e2d0iaa5da615b421718d@mail.gmail.com>
	 <9457e7c80911040318s505466c9m60b62b8de572241c@mail.gmail.com>
	 <7f014ea60911040326m44bb208cwb77d4f4a1fd19278@mail.gmail.com>
	 <a2587f3b-7a41-482d-82af-72790e33345f@m16g2000yqc.googlegroups.com>
	 <9457e7c80911040604u74031e6cu189e58a021a70535@mail.gmail.com>
	 <5c069b31-2117-45e1-b9d6-0c1bc0021490@j19g2000yqk.googlegroups.com>
	 <7f014ea60911050627r2cdfa462odfeb34def299b31e@mail.gmail.com>
	 <ef0d4d36-32f2-40d8-b1dd-27fa2c052c92@r24g2000yqd.googlegroups.com>
Message-ID: <7f014ea60911050654j4200d8fal306743f81b3fbf55@mail.gmail.com>

On Thu, Nov 5, 2009 at 3:44 PM, SirVer <sirver at gmx.de> wrote:
>
>
>
> On 5 Nov., 15:27, Chris Colbert <sccolb... at gmail.com> wrote:
>> On Thu, Nov 5, 2009 at 3:16 PM, SirVer <sir... at gmx.de> wrote:
>>
>> > Hi,
>>
>> > On 4 Nov., 15:04, St?fan van der Walt <ste... at sun.ac.za> wrote:
>> >> 2009/11/4 SirVer <sir... at gmx.de>:
>>
>> >> > Stefan, concerning my GUI branch:
>> >> > I played around with pyqt and QImages and they just couldn't deliver
>> >> > what I needed: Speed.
>>
>> >> I'd like to see some benchmarks that support this, because it should
>> >> be the cost of 2 python calls + whatever time the GUI uses. ?QImage is
>> >> fast when loading directly from a numpy array. ?I'm not sure, with the
>> >> copying that you have to do into a texture, that OpenGL can do any
>> >> better.
>> > I did some benchmarks, but unfortunately I do not have the code
>> > around. I created QImages and painted them directly in PyQt. It was
>> > reasonable fast, but I couldn't reach the performance I have with a
>> > QGLWidget which delivers easily 300fps or 60fps in 12 different
>> > windows. I'd rather not hack this again since this issue is somewhat
>> > settled for me and I'd prefer spending my coding time on other itches
>> > I have.
>>
>> > I still think that PyQt is a much bigger dependency then PyOpenGL -
>> > and even so: both are optional and only needed when GUI stuff in real
>> > time should be performed.
>>
>> I think you're not really grasping the idea of "plugin"
> Well, I understood the principle of plugin quite well; BUT the plugin
> architecture does not allow real time display of images right now. It
> won't be possible to implement it that way.
> AND there are users who will need this and might need it in image
> processing tasks. The question here is just if and if yes how to
> implement this.

I meant that you make the claim that QT is a heavy dependency, when in
fact its not a dependency at all unless the individual wants to use
the qt plugins.
The scikit, and all it's image process, still function without having
QT installed.

Further, these imshow() type widgets are primarily meant to be used
from the interactive interpreter, an environment not best suited for
real time image acquisition and display. that said, the plugin
archiceture can most certainly be used in the method you speak of. You
just simply have your imshow() function return the window object, and
implement an update() or similar method that the consumer can call to
update the image.


>
> If my code and my attempts are not to be included in scikit.image, so
> be it. I will continue to use it anyway; i just think they are useful
> and WANT to contribute them to the public.
>
>>
>>
>>
>> > Cheers,
>> > Holger
>>
>> >> Regards
>> >> St?fan


From sccolbert at gmail.com  Thu Nov  5 09:55:45 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Thu, 5 Nov 2009 15:55:45 +0100
Subject: Pending release of 0.3
In-Reply-To: <9457e7c80911050653o4427c8c2j606d5a9b54400443@mail.gmail.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com>
	 <8d3755aa-4081-4470-b688-65776f2ad765@p35g2000yqh.googlegroups.com>
	 <7f014ea60911040144x709531a2w49677946421ac8e2@mail.gmail.com>
	 <7f014ea60911040147n7593e2d0iaa5da615b421718d@mail.gmail.com>
	 <9457e7c80911040318s505466c9m60b62b8de572241c@mail.gmail.com>
	 <7f014ea60911040326m44bb208cwb77d4f4a1fd19278@mail.gmail.com>
	 <a2587f3b-7a41-482d-82af-72790e33345f@m16g2000yqc.googlegroups.com>
	 <9457e7c80911040604u74031e6cu189e58a021a70535@mail.gmail.com>
	 <5c069b31-2117-45e1-b9d6-0c1bc0021490@j19g2000yqk.googlegroups.com>
	 <9457e7c80911050653o4427c8c2j606d5a9b54400443@mail.gmail.com>
Message-ID: <7f014ea60911050655u23b265e4rc7af18fa49d81850@mail.gmail.com>

There is nothing with the plugin framework that prevents somebody from
creating widgets for video feeds...

2009/11/5 St?fan van der Walt <stefan at sun.ac.za>:
>
> Hi Holger
>
> 2009/11/5 SirVer <sirver at gmx.de>:
>> I still think that PyQt is a much bigger dependency then PyOpenGL -
>> and even so: both are optional and only needed when GUI stuff in real
>> time should be performed.
>
> I see the PyOpenGL wrappers nowadays use ctypes, so they can be
> installed without compiling anything (good!). ?The reason I suggested
> Pyglet is because it gives you a higher-level abstraction on things
> such as textures and windows, and allows you to skirt the PyQt
> dependency, if you'd want to.
>
> As for the implementation of a realtime display, I'd be glad to work
> with you to remove any hinderances that prevent the use of the plugin
> framework. ?If it is a fundamental limitation, I'd be glad if we could
> discuss that to get a better idea of your needs.
>
> Regards
> St?fan
>


From sccolbert at gmail.com  Thu Nov  5 10:24:46 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Thu, 5 Nov 2009 16:24:46 +0100
Subject: Pending release of 0.3
In-Reply-To: <9457e7c80911050703u4f9e11bdmdfc525656161ba34@mail.gmail.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com>
	 <9457e7c80911040318s505466c9m60b62b8de572241c@mail.gmail.com>
	 <7f014ea60911040326m44bb208cwb77d4f4a1fd19278@mail.gmail.com>
	 <a2587f3b-7a41-482d-82af-72790e33345f@m16g2000yqc.googlegroups.com>
	 <9457e7c80911040604u74031e6cu189e58a021a70535@mail.gmail.com>
	 <5c069b31-2117-45e1-b9d6-0c1bc0021490@j19g2000yqk.googlegroups.com>
	 <7f014ea60911050627r2cdfa462odfeb34def299b31e@mail.gmail.com>
	 <ef0d4d36-32f2-40d8-b1dd-27fa2c052c92@r24g2000yqd.googlegroups.com>
	 <7f014ea60911050654j4200d8fal306743f81b3fbf55@mail.gmail.com>
	 <9457e7c80911050703u4f9e11bdmdfc525656161ba34@mail.gmail.com>
Message-ID: <7f014ea60911050724p76c8fcbfv680229b589dce7d6@mail.gmail.com>

I was just testing out something along these lines, but I run into the
problem of the the python interpreter not considering time.sleep() as
idle time, thus, it never calls PyOS_InputHook inside of for-loops. So
i'm not quite sure how to get video  feed to run interactively without
hacking out something like ipython -whatever thread.

Mind you, this is not a problem with the plugin architecture, its a
problem with the python interpreter...

but maybe i can ctypes into the os_hook and call it at the end of a
loop.... <evil grin>

2009/11/5 St?fan van der Walt <stefan at sun.ac.za>:
>
> 2009/11/5 Chris Colbert <sccolbert at gmail.com>:
>> Further, these imshow() type widgets are primarily meant to be used
>> from the interactive interpreter, an environment not best suited for
>> real time image acquisition and display. that said, the plugin
>> archiceture can most certainly be used in the method you speak of. You
>> just simply have your imshow() function return the window object, and
>> implement an update() or similar method that the consumer can call to
>> update the image.
>
> This could even be accomplished using 'imshow' only. ?The
> WindowManager keeps track of the single window produced, and 'imshow'
> simply grabs that window and updates its current content. ?I'd be
> surprised if we couldn't pump out a large number of frames-per-second
> that way.
>
> St?fan
>


From stefan at sun.ac.za  Thu Nov  5 09:53:26 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 5 Nov 2009 16:53:26 +0200
Subject: Pending release of 0.3
In-Reply-To: <5c069b31-2117-45e1-b9d6-0c1bc0021490@j19g2000yqk.googlegroups.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com> 
	<8d3755aa-4081-4470-b688-65776f2ad765@p35g2000yqh.googlegroups.com> 
	<7f014ea60911040144x709531a2w49677946421ac8e2@mail.gmail.com> 
	<7f014ea60911040147n7593e2d0iaa5da615b421718d@mail.gmail.com> 
	<9457e7c80911040318s505466c9m60b62b8de572241c@mail.gmail.com> 
	<7f014ea60911040326m44bb208cwb77d4f4a1fd19278@mail.gmail.com> 
	<a2587f3b-7a41-482d-82af-72790e33345f@m16g2000yqc.googlegroups.com> 
	<9457e7c80911040604u74031e6cu189e58a021a70535@mail.gmail.com> 
	<5c069b31-2117-45e1-b9d6-0c1bc0021490@j19g2000yqk.googlegroups.com>
Message-ID: <9457e7c80911050653o4427c8c2j606d5a9b54400443@mail.gmail.com>

Hi Holger

2009/11/5 SirVer <sirver at gmx.de>:
> I still think that PyQt is a much bigger dependency then PyOpenGL -
> and even so: both are optional and only needed when GUI stuff in real
> time should be performed.

I see the PyOpenGL wrappers nowadays use ctypes, so they can be
installed without compiling anything (good!).  The reason I suggested
Pyglet is because it gives you a higher-level abstraction on things
such as textures and windows, and allows you to skirt the PyQt
dependency, if you'd want to.

As for the implementation of a realtime display, I'd be glad to work
with you to remove any hinderances that prevent the use of the plugin
framework.  If it is a fundamental limitation, I'd be glad if we could
discuss that to get a better idea of your needs.

Regards
St?fan


From sccolbert at gmail.com  Thu Nov  5 10:56:18 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Thu, 5 Nov 2009 16:56:18 +0100
Subject: Pending release of 0.3
In-Reply-To: <7f014ea60911050724p76c8fcbfv680229b589dce7d6@mail.gmail.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com>
	 <7f014ea60911040326m44bb208cwb77d4f4a1fd19278@mail.gmail.com>
	 <a2587f3b-7a41-482d-82af-72790e33345f@m16g2000yqc.googlegroups.com>
	 <9457e7c80911040604u74031e6cu189e58a021a70535@mail.gmail.com>
	 <5c069b31-2117-45e1-b9d6-0c1bc0021490@j19g2000yqk.googlegroups.com>
	 <7f014ea60911050627r2cdfa462odfeb34def299b31e@mail.gmail.com>
	 <ef0d4d36-32f2-40d8-b1dd-27fa2c052c92@r24g2000yqd.googlegroups.com>
	 <7f014ea60911050654j4200d8fal306743f81b3fbf55@mail.gmail.com>
	 <9457e7c80911050703u4f9e11bdmdfc525656161ba34@mail.gmail.com>
	 <7f014ea60911050724p76c8fcbfv680229b589dce7d6@mail.gmail.com>
Message-ID: <7f014ea60911050756k7fca1b38s6801361ce60c9b30@mail.gmail.com>

So while i havent yet been able to get the pyos_inputhook thing sorted
out, I did time a couple loops.

For a decent sized image, we can easily get 60fps update rates, and
thats including the time for the numpy operations:

In [5]: img = io.imread('/home/brucewayne/Pictures/failboat_4.jpg')

In [6]: img.shape
Out[6]: (503, 790, 3)

In [7]: win = io.imshow(img, updateable=True)

In [8]: def test(img, win):
   ...:     for i in range(30):
   ...:         img[:] += 1
   ...:         win.update()
   ...:
   ...:

In [9]: %timeit test(img, win)
1 loops, best of 3: 564 ms per loop


one thing to note, I bypassed the prepare_for_display() method that we
usually call to make sure an array is contiguous, of the right dtype,
etc...
I assume if someone wants video, they can prepare the arrays themselves.

This behavior can also be changed by the plugin writer. For this
example, i simply took the easy route and subclassed ImageWindow

Cheers,

Chris


On Thu, Nov 5, 2009 at 4:24 PM, Chris Colbert <sccolbert at gmail.com> wrote:
> I was just testing out something along these lines, but I run into the
> problem of the the python interpreter not considering time.sleep() as
> idle time, thus, it never calls PyOS_InputHook inside of for-loops. So
> i'm not quite sure how to get video ?feed to run interactively without
> hacking out something like ipython -whatever thread.
>
> Mind you, this is not a problem with the plugin architecture, its a
> problem with the python interpreter...
>
> but maybe i can ctypes into the os_hook and call it at the end of a
> loop.... <evil grin>
>
> 2009/11/5 St?fan van der Walt <stefan at sun.ac.za>:
>>
>> 2009/11/5 Chris Colbert <sccolbert at gmail.com>:
>>> Further, these imshow() type widgets are primarily meant to be used
>>> from the interactive interpreter, an environment not best suited for
>>> real time image acquisition and display. that said, the plugin
>>> archiceture can most certainly be used in the method you speak of. You
>>> just simply have your imshow() function return the window object, and
>>> implement an update() or similar method that the consumer can call to
>>> update the image.
>>
>> This could even be accomplished using 'imshow' only. ?The
>> WindowManager keeps track of the single window produced, and 'imshow'
>> simply grabs that window and updates its current content. ?I'd be
>> surprised if we couldn't pump out a large number of frames-per-second
>> that way.
>>
>> St?fan
>>
>


From sccolbert at gmail.com  Thu Nov  5 11:03:51 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Thu, 5 Nov 2009 17:03:51 +0100
Subject: Pending release of 0.3
In-Reply-To: <7f014ea60911050756k7fca1b38s6801361ce60c9b30@mail.gmail.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com>
	 <a2587f3b-7a41-482d-82af-72790e33345f@m16g2000yqc.googlegroups.com>
	 <9457e7c80911040604u74031e6cu189e58a021a70535@mail.gmail.com>
	 <5c069b31-2117-45e1-b9d6-0c1bc0021490@j19g2000yqk.googlegroups.com>
	 <7f014ea60911050627r2cdfa462odfeb34def299b31e@mail.gmail.com>
	 <ef0d4d36-32f2-40d8-b1dd-27fa2c052c92@r24g2000yqd.googlegroups.com>
	 <7f014ea60911050654j4200d8fal306743f81b3fbf55@mail.gmail.com>
	 <9457e7c80911050703u4f9e11bdmdfc525656161ba34@mail.gmail.com>
	 <7f014ea60911050724p76c8fcbfv680229b589dce7d6@mail.gmail.com>
	 <7f014ea60911050756k7fca1b38s6801361ce60c9b30@mail.gmail.com>
Message-ID: <7f014ea60911050803x58d166b3h2bbcde8d74aaa957@mail.gmail.com>

Holger,

There is nothing stopping you from making a pyopengl plugin. Or even
modifying your current gui to fit within the plugin framework.

However, i'm afraid that your current gui may rely on ipython
-q4thread, which is now deprecated (big mailing list discussion on
this). So that may throw a wrench in the video portion of it, unless
we can figure out this pyos_input hook thing.

But as my previous example shows, its definately possible to fit it
within the plugin framework.

Cheers!

Chris

On Thu, Nov 5, 2009 at 4:56 PM, Chris Colbert <sccolbert at gmail.com> wrote:
> So while i havent yet been able to get the pyos_inputhook thing sorted
> out, I did time a couple loops.
>
> For a decent sized image, we can easily get 60fps update rates, and
> thats including the time for the numpy operations:
>
> In [5]: img = io.imread('/home/brucewayne/Pictures/failboat_4.jpg')
>
> In [6]: img.shape
> Out[6]: (503, 790, 3)
>
> In [7]: win = io.imshow(img, updateable=True)
>
> In [8]: def test(img, win):
> ? ...: ? ? for i in range(30):
> ? ...: ? ? ? ? img[:] += 1
> ? ...: ? ? ? ? win.update()
> ? ...:
> ? ...:
>
> In [9]: %timeit test(img, win)
> 1 loops, best of 3: 564 ms per loop
>
>
> one thing to note, I bypassed the prepare_for_display() method that we
> usually call to make sure an array is contiguous, of the right dtype,
> etc...
> I assume if someone wants video, they can prepare the arrays themselves.
>
> This behavior can also be changed by the plugin writer. For this
> example, i simply took the easy route and subclassed ImageWindow
>
> Cheers,
>
> Chris
>
>
> On Thu, Nov 5, 2009 at 4:24 PM, Chris Colbert <sccolbert at gmail.com> wrote:
>> I was just testing out something along these lines, but I run into the
>> problem of the the python interpreter not considering time.sleep() as
>> idle time, thus, it never calls PyOS_InputHook inside of for-loops. So
>> i'm not quite sure how to get video ?feed to run interactively without
>> hacking out something like ipython -whatever thread.
>>
>> Mind you, this is not a problem with the plugin architecture, its a
>> problem with the python interpreter...
>>
>> but maybe i can ctypes into the os_hook and call it at the end of a
>> loop.... <evil grin>
>>
>> 2009/11/5 St?fan van der Walt <stefan at sun.ac.za>:
>>>
>>> 2009/11/5 Chris Colbert <sccolbert at gmail.com>:
>>>> Further, these imshow() type widgets are primarily meant to be used
>>>> from the interactive interpreter, an environment not best suited for
>>>> real time image acquisition and display. that said, the plugin
>>>> archiceture can most certainly be used in the method you speak of. You
>>>> just simply have your imshow() function return the window object, and
>>>> implement an update() or similar method that the consumer can call to
>>>> update the image.
>>>
>>> This could even be accomplished using 'imshow' only. ?The
>>> WindowManager keeps track of the single window produced, and 'imshow'
>>> simply grabs that window and updates its current content. ?I'd be
>>> surprised if we couldn't pump out a large number of frames-per-second
>>> that way.
>>>
>>> St?fan
>>>
>>
>


From stefan at sun.ac.za  Thu Nov  5 10:03:54 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 5 Nov 2009 17:03:54 +0200
Subject: Pending release of 0.3
In-Reply-To: <7f014ea60911050654j4200d8fal306743f81b3fbf55@mail.gmail.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com> 
	<7f014ea60911040147n7593e2d0iaa5da615b421718d@mail.gmail.com> 
	<9457e7c80911040318s505466c9m60b62b8de572241c@mail.gmail.com> 
	<7f014ea60911040326m44bb208cwb77d4f4a1fd19278@mail.gmail.com> 
	<a2587f3b-7a41-482d-82af-72790e33345f@m16g2000yqc.googlegroups.com> 
	<9457e7c80911040604u74031e6cu189e58a021a70535@mail.gmail.com> 
	<5c069b31-2117-45e1-b9d6-0c1bc0021490@j19g2000yqk.googlegroups.com> 
	<7f014ea60911050627r2cdfa462odfeb34def299b31e@mail.gmail.com> 
	<ef0d4d36-32f2-40d8-b1dd-27fa2c052c92@r24g2000yqd.googlegroups.com> 
	<7f014ea60911050654j4200d8fal306743f81b3fbf55@mail.gmail.com>
Message-ID: <9457e7c80911050703u4f9e11bdmdfc525656161ba34@mail.gmail.com>

2009/11/5 Chris Colbert <sccolbert at gmail.com>:
> Further, these imshow() type widgets are primarily meant to be used
> from the interactive interpreter, an environment not best suited for
> real time image acquisition and display. that said, the plugin
> archiceture can most certainly be used in the method you speak of. You
> just simply have your imshow() function return the window object, and
> implement an update() or similar method that the consumer can call to
> update the image.

This could even be accomplished using 'imshow' only.  The
WindowManager keeps track of the single window produced, and 'imshow'
simply grabs that window and updates its current content.  I'd be
surprised if we couldn't pump out a large number of frames-per-second
that way.

St?fan


From sccolbert at gmail.com  Thu Nov  5 11:33:57 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Thu, 5 Nov 2009 17:33:57 +0100
Subject: Pending release of 0.3
In-Reply-To: <c33af287-8157-42d8-b836-53ec510fa8f8@w19g2000yqk.googlegroups.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com>
	 <5c069b31-2117-45e1-b9d6-0c1bc0021490@j19g2000yqk.googlegroups.com>
	 <7f014ea60911050627r2cdfa462odfeb34def299b31e@mail.gmail.com>
	 <ef0d4d36-32f2-40d8-b1dd-27fa2c052c92@r24g2000yqd.googlegroups.com>
	 <7f014ea60911050654j4200d8fal306743f81b3fbf55@mail.gmail.com>
	 <9457e7c80911050703u4f9e11bdmdfc525656161ba34@mail.gmail.com>
	 <7f014ea60911050724p76c8fcbfv680229b589dce7d6@mail.gmail.com>
	 <7f014ea60911050756k7fca1b38s6801361ce60c9b30@mail.gmail.com>
	 <7f014ea60911050803x58d166b3h2bbcde8d74aaa957@mail.gmail.com>
	 <c33af287-8157-42d8-b836-53ec510fa8f8@w19g2000yqk.googlegroups.com>
Message-ID: <7f014ea60911050833k59616558xd28adfa4951d4700@mail.gmail.com>

Here's a couple links on it Holger.

Hopefully the scipy links work for you (its the Ipython part of the
discussion). I cant get to them right now.

http://mail.scipy.org/pipermail/ipython-dev/2009-July/005256.html
http://mail.scipy.org/pipermail/ipython-dev/2009-February/004905.html
http://mail.python.org/pipermail/python-dev/2005-November/057954.html

On Thu, Nov 5, 2009 at 5:14 PM, SirVer <sirver at gmx.de> wrote:
>
>> However, i'm afraid that your current gui may rely on ipython
>> -q4thread, which is now deprecated (big mailing list discussion on
>> this). So that may throw a wrench in the video portion of it, unless
>> we can figure out this pyos_input hook thing.
> It infact does. Chris, could you please point me at this discussion?
> It is most relevant for my work.
>
> Cheers,
> Holger
>
>> But as my previous example shows, its definately possible to fit it
>> within the plugin framework.
>>
>> Cheers!
>>
>> Chris
>>
>>
>>
>> On Thu, Nov 5, 2009 at 4:56 PM, Chris Colbert <sccolb... at gmail.com> wrote:
>> > So while i havent yet been able to get the pyos_inputhook thing sorted
>> > out, I did time a couple loops.
>>
>> > For a decent sized image, we can easily get 60fps update rates, and
>> > thats including the time for the numpy operations:
>>
>> > In [5]: img = io.imread('/home/brucewayne/Pictures/failboat_4.jpg')
>>
>> > In [6]: img.shape
>> > Out[6]: (503, 790, 3)
>>
>> > In [7]: win = io.imshow(img, updateable=True)
>>
>> > In [8]: def test(img, win):
>> > ? ...: ? ? for i in range(30):
>> > ? ...: ? ? ? ? img[:] += 1
>> > ? ...: ? ? ? ? win.update()
>> > ? ...:
>> > ? ...:
>>
>> > In [9]: %timeit test(img, win)
>> > 1 loops, best of 3: 564 ms per loop
>>
>> > one thing to note, I bypassed the prepare_for_display() method that we
>> > usually call to make sure an array is contiguous, of the right dtype,
>> > etc...
>> > I assume if someone wants video, they can prepare the arrays themselves.
>>
>> > This behavior can also be changed by the plugin writer. For this
>> > example, i simply took the easy route and subclassed ImageWindow
>>
>> > Cheers,
>>
>> > Chris
>>
>> > On Thu, Nov 5, 2009 at 4:24 PM, Chris Colbert <sccolb... at gmail.com> wrote:
>> >> I was just testing out something along these lines, but I run into the
>> >> problem of the the python interpreter not considering time.sleep() as
>> >> idle time, thus, it never calls PyOS_InputHook inside of for-loops. So
>> >> i'm not quite sure how to get video ?feed to run interactively without
>> >> hacking out something like ipython -whatever thread.
>>
>> >> Mind you, this is not a problem with the plugin architecture, its a
>> >> problem with the python interpreter...
>>
>> >> but maybe i can ctypes into the os_hook and call it at the end of a
>> >> loop.... <evil grin>
>>
>> >> 2009/11/5 St?fan van der Walt <ste... at sun.ac.za>:
>>
>> >>> 2009/11/5 Chris Colbert <sccolb... at gmail.com>:
>> >>>> Further, these imshow() type widgets are primarily meant to be used
>> >>>> from the interactive interpreter, an environment not best suited for
>> >>>> real time image acquisition and display. that said, the plugin
>> >>>> archiceture can most certainly be used in the method you speak of. You
>> >>>> just simply have your imshow() function return the window object, and
>> >>>> implement an update() or similar method that the consumer can call to
>> >>>> update the image.
>>
>> >>> This could even be accomplished using 'imshow' only. ?The
>> >>> WindowManager keeps track of the single window produced, and 'imshow'
>> >>> simply grabs that window and updates its current content. ?I'd be
>> >>> surprised if we couldn't pump out a large number of frames-per-second
>> >>> that way.
>>
>> >>> St?fan


From sirver at gmx.de  Fri Nov  6 05:10:19 2009
From: sirver at gmx.de (SirVer)
Date: Fri, 6 Nov 2009 02:10:19 -0800 (PST)
Subject: Histograms added to Fancy Imshow and ColorMixer
In-Reply-To: <9457e7c80911052109q606b952bld54db83ca43f9748@mail.gmail.com>
References: <7f014ea60911051731l217416b2s801ce8e156f9f274@mail.gmail.com> 
	<9457e7c80911052109q606b952bld54db83ca43f9748@mail.gmail.com>
Message-ID: <804210e8-31bf-4794-81e8-dd3d171254f3@d10g2000yqh.googlegroups.com>

Hi Chris,

I did not yet have time to check your work out, but it looks fantastic
only judging from the screenshot.
I have some remarks:

- I would very much prefer to have each of the tools you develop in
separate windows that could be enabled (for example) via
menu entries or context menus. Otherwise the window is very cluttered
with stuff that I might not be interested at the moment.
- A very useful additional tool for me would be line cross sections
(e.g. a plot of the RGB values along a line that crosses the
image horizontal or vertical).

Keep up the great work!
Cheers,
Holger


On 6 Nov., 06:09, St?fan van der Walt <ste... at sun.ac.za> wrote:
> Hi Chris
>
> 2009/11/6 Chris Colbert <sccolb... at gmail.com>:
>
> > At any rate, ?you can, you can check out the code from my IO branch on git.
>
> > And here is a screenshot to wet your appetite:
>
> >http://therealstevencolbert.com/dump/histograms.png
>
> That looks really awesome!
>
> Unfortunately, when I try this on my machine, it gobbles up all the
> memory and then exits with
>
> Python(28697,0x7fff70ad2be0) malloc: *** error for object 0x1184f7710:
> incorrect checksum for freed object - object was probably modified
> after being freed.
> *** set a breakpoint in malloc_error_break to debug
>
> The initial display aspect ratio also looks a bit strange.
>
> Cheers
> St?fan


From sirver at gmx.de  Fri Nov  6 05:24:50 2009
From: sirver at gmx.de (SirVer)
Date: Fri, 6 Nov 2009 02:24:50 -0800 (PST)
Subject: Pending release of 0.3
In-Reply-To: <7f014ea60911050833k59616558xd28adfa4951d4700@mail.gmail.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com> 
	<5c069b31-2117-45e1-b9d6-0c1bc0021490@j19g2000yqk.googlegroups.com> 
	<7f014ea60911050627r2cdfa462odfeb34def299b31e@mail.gmail.com> 
	<ef0d4d36-32f2-40d8-b1dd-27fa2c052c92@r24g2000yqd.googlegroups.com> 
	<7f014ea60911050654j4200d8fal306743f81b3fbf55@mail.gmail.com> 
	<9457e7c80911050703u4f9e11bdmdfc525656161ba34@mail.gmail.com> 
	<7f014ea60911050724p76c8fcbfv680229b589dce7d6@mail.gmail.com> 
	<7f014ea60911050756k7fca1b38s6801361ce60c9b30@mail.gmail.com> 
	<7f014ea60911050803x58d166b3h2bbcde8d74aaa957@mail.gmail.com> 
	<c33af287-8157-42d8-b836-53ec510fa8f8@w19g2000yqk.googlegroups.com> 
	<7f014ea60911050833k59616558xd28adfa4951d4700@mail.gmail.com>
Message-ID: <0abf5c7e-42c0-439b-8114-bbb3fc170427@a31g2000yqn.googlegroups.com>

Hi Chris,

thanks for the links! It made for some interesting reading; i wasn't
aware of the System Hook. But I just investigated and my Widget works
just fine in a pure python session as long as a QApplication object
has been created before. So there is no problem here, it will work
fine now in ipython -qt4thread and will continue to work in future
ipython and also in vanilla python as long as QApplication(sys.argv)
has been called before the window is created (which is mandatory for
all QT4 Applications). So no problem here.

I now try to come to a conclusion to this thread. I didn't mean to
start a lengthy discussion of how things should be done differently, I
only want to have direction how to implement this. I try to summarize
my thoughts:

* I am often in need to display images from a camera and annotate them
with some output from algorithms (for example mark detected balls in
my ping pong roboters images in red). For this I've written the code
that can be found in my gui branch.
* I feel that this use case is quite different from the idea of the
imshow() plugin. I also feel that more people than me could profit
from this functionality as I use it ATM.
* I feel that this is hard to pull off with a plugin like
architecture, because the annotation part will be different for all
backends and all individual uses. En plus, this is more a Library kind
of functionality, not a enduser kind like imshow().
* My solution works for me and uses PyQt and PyOpenGL. My experiments
showed me that this is the only combination that offers the drawing
speed I want. I understand that other approaches could be possible or
feasible, but I also think that for use cases like mine, this is a
very common approach; especially since annotating in OpenGL is so easy
to do with PyQt4.
* Please let me state again that I do not plan to corrupt or change
the imshow() plugin architecture which I really like. I am just of the
opinion that something else is needed for my use case.

Now, please note that these are my opinions and thought and not really
subject to discussion. What I now really need is a design decision by
the architect of scikit.image; which I assume to be you, stefan:

How should I contribute this code? In which module should it go or is
this not a direction that scikit.image should evolve in (I'd
understand that and instead bring this code into my pydc1394 library
were it would also fit).

Cheers,
Holger



On 5 Nov., 17:33, Chris Colbert <sccolb... at gmail.com> wrote:
> Here's a couple links on it Holger.
>
> Hopefully the scipy links work for you (its the Ipython part of the
> discussion). I cant get to them right now.
>
> http://mail.scipy.org/pipermail/ipython-dev/2009-July/005256.htmlhttp://mail.scipy.org/pipermail/ipython-dev/2009-February/004905.htmlhttp://mail.python.org/pipermail/python-dev/2005-November/057954.html
>
>
>
> On Thu, Nov 5, 2009 at 5:14 PM, SirVer <sir... at gmx.de> wrote:
>
> >> However, i'm afraid that your current gui may rely on ipython
> >> -q4thread, which is now deprecated (big mailing list discussion on
> >> this). So that may throw a wrench in the video portion of it, unless
> >> we can figure out this pyos_input hook thing.
> > It infact does. Chris, could you please point me at this discussion?
> > It is most relevant for my work.
>
> > Cheers,
> > Holger
>
> >> But as my previous example shows, its definately possible to fit it
> >> within the plugin framework.
>
> >> Cheers!
>
> >> Chris
>
> >> On Thu, Nov 5, 2009 at 4:56 PM, Chris Colbert <sccolb... at gmail.com> wrote:
> >> > So while i havent yet been able to get the pyos_inputhook thing sorted
> >> > out, I did time a couple loops.
>
> >> > For a decent sized image, we can easily get 60fps update rates, and
> >> > thats including the time for the numpy operations:
>
> >> > In [5]: img = io.imread('/home/brucewayne/Pictures/failboat_4.jpg')
>
> >> > In [6]: img.shape
> >> > Out[6]: (503, 790, 3)
>
> >> > In [7]: win = io.imshow(img, updateable=True)
>
> >> > In [8]: def test(img, win):
> >> > ? ...: ? ? for i in range(30):
> >> > ? ...: ? ? ? ? img[:] += 1
> >> > ? ...: ? ? ? ? win.update()
> >> > ? ...:
> >> > ? ...:
>
> >> > In [9]: %timeit test(img, win)
> >> > 1 loops, best of 3: 564 ms per loop
>
> >> > one thing to note, I bypassed the prepare_for_display() method that we
> >> > usually call to make sure an array is contiguous, of the right dtype,
> >> > etc...
> >> > I assume if someone wants video, they can prepare the arrays themselves.
>
> >> > This behavior can also be changed by the plugin writer. For this
> >> > example, i simply took the easy route and subclassed ImageWindow
>
> >> > Cheers,
>
> >> > Chris
>
> >> > On Thu, Nov 5, 2009 at 4:24 PM, Chris Colbert <sccolb... at gmail.com> wrote:
> >> >> I was just testing out something along these lines, but I run into the
> >> >> problem of the the python interpreter not considering time.sleep() as
> >> >> idle time, thus, it never calls PyOS_InputHook inside of for-loops. So
> >> >> i'm not quite sure how to get video ?feed to run interactively without
> >> >> hacking out something like ipython -whatever thread.
>
> >> >> Mind you, this is not a problem with the plugin architecture, its a
> >> >> problem with the python interpreter...
>
> >> >> but maybe i can ctypes into the os_hook and call it at the end of a
> >> >> loop.... <evil grin>
>
> >> >> 2009/11/5 St?fan van der Walt <ste... at sun.ac.za>:
>
> >> >>> 2009/11/5 Chris Colbert <sccolb... at gmail.com>:
> >> >>>> Further, these imshow() type widgets are primarily meant to be used
> >> >>>> from the interactive interpreter, an environment not best suited for
> >> >>>> real time image acquisition and display. that said, the plugin
> >> >>>> archiceture can most certainly be used in the method you speak of. You
> >> >>>> just simply have your imshow() function return the window object, and
> >> >>>> implement an update() or similar method that the consumer can call to
> >> >>>> update the image.
>
> >> >>> This could even be accomplished using 'imshow' only. ?The
> >> >>> WindowManager keeps track of the single window produced, and 'imshow'
> >> >>> simply grabs that window and updates its current content. ?I'd be
> >> >>> surprised if we couldn't pump out a large number of frames-per-second
> >> >>> that way.
>
> >> >>> St?fan


From sccolbert at gmail.com  Thu Nov  5 20:31:35 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Fri, 6 Nov 2009 02:31:35 +0100
Subject: Histograms added to Fancy Imshow and ColorMixer
Message-ID: <7f014ea60911051731l217416b2s801ce8e156f9f274@mail.gmail.com>

Hey All,

I've added preliminary Histogramming to the fancy imshow QT widget. In
the process I added a fast Naive histogrammer to the ColorMixer for
use in this widget.

Unfortunately, I'm now suffering from circular references during
window instantiation. I'm gonna need to refactor the code a bit
because QT likes to fire off event before with main window has
finished intializing.
Everything still works, it just throws a few exceptions while the
window is intializing.

At any rate,  you can, you can check out the code from my IO branch on git.

And here is a screenshot to wet your appetite:

http://therealstevencolbert.com/dump/histograms.png

Cheers!

Chris


From stefan at sun.ac.za  Fri Nov  6 00:09:31 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 6 Nov 2009 07:09:31 +0200
Subject: Histograms added to Fancy Imshow and ColorMixer
In-Reply-To: <7f014ea60911051731l217416b2s801ce8e156f9f274@mail.gmail.com>
References: <7f014ea60911051731l217416b2s801ce8e156f9f274@mail.gmail.com>
Message-ID: <9457e7c80911052109q606b952bld54db83ca43f9748@mail.gmail.com>

Hi Chris

2009/11/6 Chris Colbert <sccolbert at gmail.com>:
> At any rate, ?you can, you can check out the code from my IO branch on git.
>
> And here is a screenshot to wet your appetite:
>
> http://therealstevencolbert.com/dump/histograms.png

That looks really awesome!

Unfortunately, when I try this on my machine, it gobbles up all the
memory and then exits with

Python(28697,0x7fff70ad2be0) malloc: *** error for object 0x1184f7710:
incorrect checksum for freed object - object was probably modified
after being freed.
*** set a breakpoint in malloc_error_break to debug

The initial display aspect ratio also looks a bit strange.

Cheers
St?fan


From stefan at sun.ac.za  Fri Nov  6 09:52:50 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 6 Nov 2009 16:52:50 +0200
Subject: Pending release of 0.3
In-Reply-To: <0abf5c7e-42c0-439b-8114-bbb3fc170427@a31g2000yqn.googlegroups.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com> 
	<ef0d4d36-32f2-40d8-b1dd-27fa2c052c92@r24g2000yqd.googlegroups.com> 
	<7f014ea60911050654j4200d8fal306743f81b3fbf55@mail.gmail.com> 
	<9457e7c80911050703u4f9e11bdmdfc525656161ba34@mail.gmail.com> 
	<7f014ea60911050724p76c8fcbfv680229b589dce7d6@mail.gmail.com> 
	<7f014ea60911050756k7fca1b38s6801361ce60c9b30@mail.gmail.com> 
	<7f014ea60911050803x58d166b3h2bbcde8d74aaa957@mail.gmail.com> 
	<c33af287-8157-42d8-b836-53ec510fa8f8@w19g2000yqk.googlegroups.com> 
	<7f014ea60911050833k59616558xd28adfa4951d4700@mail.gmail.com> 
	<0abf5c7e-42c0-439b-8114-bbb3fc170427@a31g2000yqn.googlegroups.com>
Message-ID: <9457e7c80911060652v7d630e14ve1b4cdeb9aa9cb51@mail.gmail.com>

Hi Holger

I'd suggest that we create a new sub-module for the purpose of
acquisition, and propagate it with all the necessary tools.  The gui
can be a stand-alone script outside the library (we may install it
with the library as an executable, but it won't be importable under,
say, scikits.image.gui).  By separating the script from the library,
we also stand a better chance of developing an easily re-usable API in
the library itself.

In the back of my head, this is where I thought the plugin framework
could slot in handy (this is just a suggestion):

Re-usable components from the GUI may be factored into a plugin, so
that others may also make use of them.  For example, the 'opengl'
plugin may provide 'imshow', that is based on your ImageDisplayWin.
Here follows a fictional code snippet:

User:

import scikits.image.io as io
io.use_plugin('opengl')
ic = io.ImageCollection([img1, img2])
io.imshow(ic)  # imshow based on StillImageDisplay

Gui script:

import scikits.image.io.plugins.opengl as opengl

ld = opengl.LiveImageDisplay()
ld.do_stuff()

etc.

The aim is to maximise code re-use and to break up code into units
that can be tested more easily.

We're all still getting to know the lay of the land here, but as soon
as we start coding, I'm sure the use cases will become more clear.

Regards
St?fan


From sccolbert at gmail.com  Fri Nov  6 14:34:09 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Fri, 6 Nov 2009 20:34:09 +0100
Subject: Aspect Ratio for the fancy imshow, need your opinions!
Message-ID: <7f014ea60911061134l5fcf2f26le3464bffa3773489@mail.gmail.com>

Currently, the simple imshow(), just shows the image at its native
size with no resizing possible.

In the QT plugin version imshow(img, fancy=True), allows the image to
be resized with the window to any aspect ratio.

What is the preference of everyone here? Would you rather I leave it
so it can be resized to any ratio (with the possibility of it not
being the correct aspect ratio on launch, if it is very small, or very
large).
Or would you prefer that the aspect ratio be kept constant?

Cheers,

Chris


From stefan at sun.ac.za  Fri Nov  6 14:41:45 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 6 Nov 2009 21:41:45 +0200
Subject: Aspect Ratio for the fancy imshow, need your opinions!
In-Reply-To: <7f014ea60911061134l5fcf2f26le3464bffa3773489@mail.gmail.com>
References: <7f014ea60911061134l5fcf2f26le3464bffa3773489@mail.gmail.com>
Message-ID: <9457e7c80911061141s5025a979vb3013749db0f2581@mail.gmail.com>

Hi Chris

2009/11/6 Chris Colbert <sccolbert at gmail.com>:
> What is the preference of everyone here? Would you rather I leave it
> so it can be resized to any ratio (with the possibility of it not
> being the correct aspect ratio on launch, if it is very small, or very
> large).
> Or would you prefer that the aspect ratio be kept constant?

My vote goes for constant aspect ratio -- I very seldom need to deform
an image to see the effect of stretching it out.

Regards
St?fan


From sccolbert at gmail.com  Fri Nov  6 16:13:10 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Fri, 6 Nov 2009 22:13:10 +0100
Subject: Fancy imshow and colormixer refactor complete + more functionality
Message-ID: <7f014ea60911061313k3b56b4f0n3107b0527873269a@mail.gmail.com>

Hey Everyone,

I think i've fixed all the problems I mentioned last night concerning
the circular references, etc...

In the process, I managed to speed up the widget quite a bit by
getting rid of unnecessary fluff.

I've also added gamma correction and sigmoidal gamma correction to the
color mixer and the imshow widget.

So if you all would be so kind, please grab it from my IO branch and
give it a thrashing, and let me know if anything breaks.

I'm gonna get working on fixing the aspect ratio, and usings holgers
suggestion of being able to hide widgets...

Cheers!

Chris


From sccolbert at gmail.com  Fri Nov  6 17:12:53 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Fri, 6 Nov 2009 23:12:53 +0100
Subject: Aspect Ratio for the fancy imshow, need your opinions!
In-Reply-To: <9457e7c80911061141s5025a979vb3013749db0f2581@mail.gmail.com>
References: <7f014ea60911061134l5fcf2f26le3464bffa3773489@mail.gmail.com>
	 <9457e7c80911061141s5025a979vb3013749db0f2581@mail.gmail.com>
Message-ID: <7f014ea60911061412t10866510ofcece7e6b68514f0@mail.gmail.com>

Ok,

I've modified the qt imshow and fancy imshow to maintain the aspect
ratio of the image when the window is resized.

Woot!

I'm done for the night!

Chris

2009/11/6 St?fan van der Walt <stefan at sun.ac.za>:
>
> Hi Chris
>
> 2009/11/6 Chris Colbert <sccolbert at gmail.com>:
>> What is the preference of everyone here? Would you rather I leave it
>> so it can be resized to any ratio (with the possibility of it not
>> being the correct aspect ratio on launch, if it is very small, or very
>> large).
>> Or would you prefer that the aspect ratio be kept constant?
>
> My vote goes for constant aspect ratio -- I very seldom need to deform
> an image to see the effect of stretching it out.
>
> Regards
> St?fan
>


From stefan at sun.ac.za  Sat Nov  7 01:45:16 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sat, 7 Nov 2009 08:45:16 +0200
Subject: Aspect Ratio for the fancy imshow, need your opinions!
In-Reply-To: <7f014ea60911061412t10866510ofcece7e6b68514f0@mail.gmail.com>
References: <7f014ea60911061134l5fcf2f26le3464bffa3773489@mail.gmail.com> 
	<9457e7c80911061141s5025a979vb3013749db0f2581@mail.gmail.com> 
	<7f014ea60911061412t10866510ofcece7e6b68514f0@mail.gmail.com>
Message-ID: <9457e7c80911062245l432a006t53462212974834b4@mail.gmail.com>

Hey Chris

2009/11/7 Chris Colbert <sccolbert at gmail.com>:
> I've modified the qt imshow and fancy imshow to maintain the aspect
> ratio of the image when the window is resized.

Having the aspect ratio maintained works very well, thanks!  The
histograms are also really fast now.

You can pull a patch to fix cursor position tracking from my 'io' branch.

Cheers
St?fan


From stefan at sun.ac.za  Sun Nov  8 17:16:30 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 9 Nov 2009 00:16:30 +0200
Subject: Ready to tag 0.2: please give it a whirl
Message-ID: <9457e7c80911081416l7dbb1e1at46405e213d7b4185@mail.gmail.com>

Hi all,

After merging the 'io' branch, I am ready to tag 0.2 after some more
testing (I accidentally called it 0.3 before).  Would you please check
out the master branch from

http://github.com/stefanv/scikits.image

and give it a good thrashing before we release?

I've also updated the docs on github in preparation:

http://stefanv.github.com/scikits.image

- Chris, your io and threaded refactor have been merged.
- Tony, your docs changes have been merged.
- Ralf, your coverage changes have been merged.  I'd love to merge the
filter improvements too, if you're almost done with those.

I added a skeleton for the User Guide
(http://stefanv.github.com/scikits.image/user_guide.html).  I think an
introductory chapter to image processing with examples should be high
on the agenda for the next round of development.

Thanks!
St?fan


From ralf.gommers at googlemail.com  Mon Nov  9 02:41:02 2009
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Mon, 9 Nov 2009 08:41:02 +0100
Subject: Ready to tag 0.2: please give it a whirl
In-Reply-To: <9457e7c80911081416l7dbb1e1at46405e213d7b4185@mail.gmail.com>
References: <9457e7c80911081416l7dbb1e1at46405e213d7b4185@mail.gmail.com>
Message-ID: <dde7764a0911082341v3863723fi8f3fb5cedb468af4@mail.gmail.com>

2009/11/8 St?fan van der Walt <stefan at sun.ac.za>

>
> Hi all,
>
> After merging the 'io' branch, I am ready to tag 0.2 after some more
> testing (I accidentally called it 0.3 before).  Would you please check
> out the master branch from
>
> http://github.com/stefanv/scikits.image
>
> and give it a good thrashing before we release?
>
> I've also updated the docs on github in preparation:
>
> http://stefanv.github.com/scikits.image
>
> - Chris, your io and threaded refactor have been merged.
> - Tony, your docs changes have been merged.
> - Ralf, your coverage changes have been merged.  I'd love to merge the
> filter improvements too, if you're almost done with those.
>

I'm not completely done yet with the filter code, and won't have access to
my computer for the next four days. So I guess that will have to go into
0.3:(

Cheers,
Ralf


> I added a skeleton for the User Guide
> (http://stefanv.github.com/scikits.image/user_guide.html).  I think an
> introductory chapter to image processing with examples should be high
> on the agenda for the next round of development.
>
> Thanks!
> St?fan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20091109/7d9a6d9b/attachment.html>

From sccolbert at gmail.com  Mon Nov  9 05:27:42 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Mon, 9 Nov 2009 11:27:42 +0100
Subject: Pending release of 0.3
In-Reply-To: <0abf5c7e-42c0-439b-8114-bbb3fc170427@a31g2000yqn.googlegroups.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com>
	 <ef0d4d36-32f2-40d8-b1dd-27fa2c052c92@r24g2000yqd.googlegroups.com>
	 <7f014ea60911050654j4200d8fal306743f81b3fbf55@mail.gmail.com>
	 <9457e7c80911050703u4f9e11bdmdfc525656161ba34@mail.gmail.com>
	 <7f014ea60911050724p76c8fcbfv680229b589dce7d6@mail.gmail.com>
	 <7f014ea60911050756k7fca1b38s6801361ce60c9b30@mail.gmail.com>
	 <7f014ea60911050803x58d166b3h2bbcde8d74aaa957@mail.gmail.com>
	 <c33af287-8157-42d8-b836-53ec510fa8f8@w19g2000yqk.googlegroups.com>
	 <7f014ea60911050833k59616558xd28adfa4951d4700@mail.gmail.com>
	 <0abf5c7e-42c0-439b-8114-bbb3fc170427@a31g2000yqn.googlegroups.com>
Message-ID: <7f014ea60911090227t1f04a84btb60ae267f7cf3ef4@mail.gmail.com>

Hey Holger,


Are you able to feed your display widget with images from within a
python loop in the interactive shell?

ie:

while True:
    img = grab_new_image()
    display.new_image(img)


The issue I am having with this PyOS_InputHook, is that for me, that
type of loop never lets the interpreter idle (even with a sleep()
call) and thus the PyOS_InputHook never gets called, and the gui never
updates.

How do you feed images to your widget?

Cheers,

Chris
On Fri, Nov 6, 2009 at 11:24 AM, SirVer <sirver at gmx.de> wrote:
>
> Hi Chris,
>
> thanks for the links! It made for some interesting reading; i wasn't
> aware of the System Hook. But I just investigated and my Widget works
> just fine in a pure python session as long as a QApplication object
> has been created before. So there is no problem here, it will work
> fine now in ipython -qt4thread and will continue to work in future
> ipython and also in vanilla python as long as QApplication(sys.argv)
> has been called before the window is created (which is mandatory for
> all QT4 Applications). So no problem here.
>
> I now try to come to a conclusion to this thread. I didn't mean to
> start a lengthy discussion of how things should be done differently, I
> only want to have direction how to implement this. I try to summarize
> my thoughts:
>
> * I am often in need to display images from a camera and annotate them
> with some output from algorithms (for example mark detected balls in
> my ping pong roboters images in red). For this I've written the code
> that can be found in my gui branch.
> * I feel that this use case is quite different from the idea of the
> imshow() plugin. I also feel that more people than me could profit
> from this functionality as I use it ATM.
> * I feel that this is hard to pull off with a plugin like
> architecture, because the annotation part will be different for all
> backends and all individual uses. En plus, this is more a Library kind
> of functionality, not a enduser kind like imshow().
> * My solution works for me and uses PyQt and PyOpenGL. My experiments
> showed me that this is the only combination that offers the drawing
> speed I want. I understand that other approaches could be possible or
> feasible, but I also think that for use cases like mine, this is a
> very common approach; especially since annotating in OpenGL is so easy
> to do with PyQt4.
> * Please let me state again that I do not plan to corrupt or change
> the imshow() plugin architecture which I really like. I am just of the
> opinion that something else is needed for my use case.
>
> Now, please note that these are my opinions and thought and not really
> subject to discussion. What I now really need is a design decision by
> the architect of scikit.image; which I assume to be you, stefan:
>
> How should I contribute this code? In which module should it go or is
> this not a direction that scikit.image should evolve in (I'd
> understand that and instead bring this code into my pydc1394 library
> were it would also fit).
>
> Cheers,
> Holger
>
>
>
> On 5 Nov., 17:33, Chris Colbert <sccolb... at gmail.com> wrote:
>> Here's a couple links on it Holger.
>>
>> Hopefully the scipy links work for you (its the Ipython part of the
>> discussion). I cant get to them right now.
>>
>> http://mail.scipy.org/pipermail/ipython-dev/2009-July/005256.htmlhttp://mail.scipy.org/pipermail/ipython-dev/2009-February/004905.htmlhttp://mail.python.org/pipermail/python-dev/2005-November/057954.html
>>
>>
>>
>> On Thu, Nov 5, 2009 at 5:14 PM, SirVer <sir... at gmx.de> wrote:
>>
>> >> However, i'm afraid that your current gui may rely on ipython
>> >> -q4thread, which is now deprecated (big mailing list discussion on
>> >> this). So that may throw a wrench in the video portion of it, unless
>> >> we can figure out this pyos_input hook thing.
>> > It infact does. Chris, could you please point me at this discussion?
>> > It is most relevant for my work.
>>
>> > Cheers,
>> > Holger
>>
>> >> But as my previous example shows, its definately possible to fit it
>> >> within the plugin framework.
>>
>> >> Cheers!
>>
>> >> Chris
>>
>> >> On Thu, Nov 5, 2009 at 4:56 PM, Chris Colbert <sccolb... at gmail.com> wrote:
>> >> > So while i havent yet been able to get the pyos_inputhook thing sorted
>> >> > out, I did time a couple loops.
>>
>> >> > For a decent sized image, we can easily get 60fps update rates, and
>> >> > thats including the time for the numpy operations:
>>
>> >> > In [5]: img = io.imread('/home/brucewayne/Pictures/failboat_4.jpg')
>>
>> >> > In [6]: img.shape
>> >> > Out[6]: (503, 790, 3)
>>
>> >> > In [7]: win = io.imshow(img, updateable=True)
>>
>> >> > In [8]: def test(img, win):
>> >> > ? ...: ? ? for i in range(30):
>> >> > ? ...: ? ? ? ? img[:] += 1
>> >> > ? ...: ? ? ? ? win.update()
>> >> > ? ...:
>> >> > ? ...:
>>
>> >> > In [9]: %timeit test(img, win)
>> >> > 1 loops, best of 3: 564 ms per loop
>>
>> >> > one thing to note, I bypassed the prepare_for_display() method that we
>> >> > usually call to make sure an array is contiguous, of the right dtype,
>> >> > etc...
>> >> > I assume if someone wants video, they can prepare the arrays themselves.
>>
>> >> > This behavior can also be changed by the plugin writer. For this
>> >> > example, i simply took the easy route and subclassed ImageWindow
>>
>> >> > Cheers,
>>
>> >> > Chris
>>
>> >> > On Thu, Nov 5, 2009 at 4:24 PM, Chris Colbert <sccolb... at gmail.com> wrote:
>> >> >> I was just testing out something along these lines, but I run into the
>> >> >> problem of the the python interpreter not considering time.sleep() as
>> >> >> idle time, thus, it never calls PyOS_InputHook inside of for-loops. So
>> >> >> i'm not quite sure how to get video ?feed to run interactively without
>> >> >> hacking out something like ipython -whatever thread.
>>
>> >> >> Mind you, this is not a problem with the plugin architecture, its a
>> >> >> problem with the python interpreter...
>>
>> >> >> but maybe i can ctypes into the os_hook and call it at the end of a
>> >> >> loop.... <evil grin>
>>
>> >> >> 2009/11/5 St?fan van der Walt <ste... at sun.ac.za>:
>>
>> >> >>> 2009/11/5 Chris Colbert <sccolb... at gmail.com>:
>> >> >>>> Further, these imshow() type widgets are primarily meant to be used
>> >> >>>> from the interactive interpreter, an environment not best suited for
>> >> >>>> real time image acquisition and display. that said, the plugin
>> >> >>>> archiceture can most certainly be used in the method you speak of. You
>> >> >>>> just simply have your imshow() function return the window object, and
>> >> >>>> implement an update() or similar method that the consumer can call to
>> >> >>>> update the image.
>>
>> >> >>> This could even be accomplished using 'imshow' only. ?The
>> >> >>> WindowManager keeps track of the single window produced, and 'imshow'
>> >> >>> simply grabs that window and updates its current content. ?I'd be
>> >> >>> surprised if we couldn't pump out a large number of frames-per-second
>> >> >>> that way.
>>
>> >> >>> St?fan


From sirver at gmx.de  Tue Nov 10 04:38:09 2009
From: sirver at gmx.de (SirVer)
Date: Tue, 10 Nov 2009 01:38:09 -0800 (PST)
Subject: Pending release of 0.3
In-Reply-To: <9457e7c80911060652v7d630e14ve1b4cdeb9aa9cb51@mail.gmail.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com> 
	<ef0d4d36-32f2-40d8-b1dd-27fa2c052c92@r24g2000yqd.googlegroups.com> 
	<7f014ea60911050654j4200d8fal306743f81b3fbf55@mail.gmail.com> 
	<9457e7c80911050703u4f9e11bdmdfc525656161ba34@mail.gmail.com> 
	<7f014ea60911050724p76c8fcbfv680229b589dce7d6@mail.gmail.com> 
	<7f014ea60911050756k7fca1b38s6801361ce60c9b30@mail.gmail.com> 
	<7f014ea60911050803x58d166b3h2bbcde8d74aaa957@mail.gmail.com> 
	<c33af287-8157-42d8-b836-53ec510fa8f8@w19g2000yqk.googlegroups.com> 
	<7f014ea60911050833k59616558xd28adfa4951d4700@mail.gmail.com> 
	<0abf5c7e-42c0-439b-8114-bbb3fc170427@a31g2000yqn.googlegroups.com> 
	<9457e7c80911060652v7d630e14ve1b4cdeb9aa9cb51@mail.gmail.com>
Message-ID: <16dbaa07-b0f4-4ade-bd65-8b3d258d2434@o10g2000yqa.googlegroups.com>

Hi,

> The aim is to maximise code re-use and to break up code into units
> that can be tested more easily.
This should be the target.

Along these lines, I currently feel uneasy of incorporating my
pydc1394 into scikit images; the compatibility
fixes will be more recent and not everybody doing image processing
need camera acquisition. I'd currently rather
keep the projects seperated, but strongly cooperate (for example, I
would drop the gui stuff in pydc1394 as soon as
the one in scikit.image lands and make the example scripts in pydc1394
depend on scikit.image).

Cheers,
Holger


From sirver at gmx.de  Tue Nov 10 04:49:48 2009
From: sirver at gmx.de (SirVer)
Date: Tue, 10 Nov 2009 01:49:48 -0800 (PST)
Subject: Pending release of 0.3
In-Reply-To: <7f014ea60911090227t1f04a84btb60ae267f7cf3ef4@mail.gmail.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com> 
	<ef0d4d36-32f2-40d8-b1dd-27fa2c052c92@r24g2000yqd.googlegroups.com> 
	<7f014ea60911050654j4200d8fal306743f81b3fbf55@mail.gmail.com> 
	<9457e7c80911050703u4f9e11bdmdfc525656161ba34@mail.gmail.com> 
	<7f014ea60911050724p76c8fcbfv680229b589dce7d6@mail.gmail.com> 
	<7f014ea60911050756k7fca1b38s6801361ce60c9b30@mail.gmail.com> 
	<7f014ea60911050803x58d166b3h2bbcde8d74aaa957@mail.gmail.com> 
	<c33af287-8157-42d8-b836-53ec510fa8f8@w19g2000yqk.googlegroups.com> 
	<7f014ea60911050833k59616558xd28adfa4951d4700@mail.gmail.com> 
	<0abf5c7e-42c0-439b-8114-bbb3fc170427@a31g2000yqn.googlegroups.com> 
	<7f014ea60911090227t1f04a84btb60ae267f7cf3ef4@mail.gmail.com>
Message-ID: <92a1a49d-db47-48a7-bfb6-69ecc650ce34@h34g2000yqm.googlegroups.com>

Hi Chris,

> Are you able to feed your display widget with images from within a
> python loop in the interactive shell?
>
> ie:
>
> while True:
> ? ? img = grab_new_image()
> ? ? display.new_image(img)
> The issue I am having with this PyOS_InputHook, is that for me, that
> type of loop never lets the interpreter idle (even with a sleep()
> call) and thus the PyOS_InputHook never gets called, and the gui never
> updates.
This can't work as you said. PyOS_InputHook is never called. I doesn't
work in ipython -q4thread either
because the thread switch doesn't seem to occure. There are two ways
to do it
1) either call PyOS_InputHook yourself.
2) acquire your images in another thread.

I always use 2) since my image acquisition always takes place
continously in the background. This is also a way were
PyQT really shines (It also works with wxWidgets that way, but it
hurts a bit).

so your above example would look a bit like that (not tested, just
written down like that):

class WorkerThread(QThread):
   def __init__(self, display):
      self.connect(self, SIGNAL("newImage"), self.display.newImage)
      # Keep a copy of display around so that the C object doesn't get
deleted
      self.display = display

   def run(self):
      while True:
         img = grab_new_image()
         self.emit(SIGNAL("newImage"), img)

def acquire_images(display):
   t = WorkerThread(display)
   t.start()

This example should work from the interactive shell provided you
created a QApplication object so that Qt4 has the PyOS_InputHook
acquired. Just call acquire_images(display).

Cheers,
Holger


>
>
> Cheers,
>
> Chris
>
>
>
> On Fri, Nov 6, 2009 at 11:24 AM, SirVer <sir... at gmx.de> wrote:
>
> > Hi Chris,
>
> > thanks for the links! It made for some interesting reading; i wasn't
> > aware of the System Hook. But I just investigated and my Widget works
> > just fine in a pure python session as long as a QApplication object
> > has been created before. So there is no problem here, it will work
> > fine now in ipython -qt4thread and will continue to work in future
> > ipython and also in vanilla python as long as QApplication(sys.argv)
> > has been called before the window is created (which is mandatory for
> > all QT4 Applications). So no problem here.
>
> > I now try to come to a conclusion to this thread. I didn't mean to
> > start a lengthy discussion of how things should be done differently, I
> > only want to have direction how to implement this. I try to summarize
> > my thoughts:
>
> > * I am often in need to display images from a camera and annotate them
> > with some output from algorithms (for example mark detected balls in
> > my ping pong roboters images in red). For this I've written the code
> > that can be found in my gui branch.
> > * I feel that this use case is quite different from the idea of the
> > imshow() plugin. I also feel that more people than me could profit
> > from this functionality as I use it ATM.
> > * I feel that this is hard to pull off with a plugin like
> > architecture, because the annotation part will be different for all
> > backends and all individual uses. En plus, this is more a Library kind
> > of functionality, not a enduser kind like imshow().
> > * My solution works for me and uses PyQt and PyOpenGL. My experiments
> > showed me that this is the only combination that offers the drawing
> > speed I want. I understand that other approaches could be possible or
> > feasible, but I also think that for use cases like mine, this is a
> > very common approach; especially since annotating in OpenGL is so easy
> > to do with PyQt4.
> > * Please let me state again that I do not plan to corrupt or change
> > the imshow() plugin architecture which I really like. I am just of the
> > opinion that something else is needed for my use case.
>
> > Now, please note that these are my opinions and thought and not really
> > subject to discussion. What I now really need is a design decision by
> > the architect of scikit.image; which I assume to be you, stefan:
>
> > How should I contribute this code? In which module should it go or is
> > this not a direction that scikit.image should evolve in (I'd
> > understand that and instead bring this code into my pydc1394 library
> > were it would also fit).
>
> > Cheers,
> > Holger
>
> > On 5 Nov., 17:33, Chris Colbert <sccolb... at gmail.com> wrote:
> >> Here's a couple links on it Holger.
>
> >> Hopefully the scipy links work for you (its the Ipython part of the
> >> discussion). I cant get to them right now.
>
> >>http://mail.scipy.org/pipermail/ipython-dev/2009-July/005256.htmlhttp...
>
> >> On Thu, Nov 5, 2009 at 5:14 PM, SirVer <sir... at gmx.de> wrote:
>
> >> >> However, i'm afraid that your current gui may rely on ipython
> >> >> -q4thread, which is now deprecated (big mailing list discussion on
> >> >> this). So that may throw a wrench in the video portion of it, unless
> >> >> we can figure out this pyos_input hook thing.
> >> > It infact does. Chris, could you please point me at this discussion?
> >> > It is most relevant for my work.
>
> >> > Cheers,
> >> > Holger
>
> >> >> But as my previous example shows, its definately possible to fit it
> >> >> within the plugin framework.
>
> >> >> Cheers!
>
> >> >> Chris
>
> >> >> On Thu, Nov 5, 2009 at 4:56 PM, Chris Colbert <sccolb... at gmail.com> wrote:
> >> >> > So while i havent yet been able to get the pyos_inputhook thing sorted
> >> >> > out, I did time a couple loops.
>
> >> >> > For a decent sized image, we can easily get 60fps update rates, and
> >> >> > thats including the time for the numpy operations:
>
> >> >> > In [5]: img = io.imread('/home/brucewayne/Pictures/failboat_4.jpg')
>
> >> >> > In [6]: img.shape
> >> >> > Out[6]: (503, 790, 3)
>
> >> >> > In [7]: win = io.imshow(img, updateable=True)
>
> >> >> > In [8]: def test(img, win):
> >> >> > ? ...: ? ? for i in range(30):
> >> >> > ? ...: ? ? ? ? img[:] += 1
> >> >> > ? ...: ? ? ? ? win.update()
> >> >> > ? ...:
> >> >> > ? ...:
>
> >> >> > In [9]: %timeit test(img, win)
> >> >> > 1 loops, best of 3: 564 ms per loop
>
> >> >> > one thing to note, I bypassed the prepare_for_display() method that we
> >> >> > usually call to make sure an array is contiguous, of the right dtype,
> >> >> > etc...
> >> >> > I assume if someone wants video, they can prepare the arrays themselves.
>
> >> >> > This behavior can also be changed by the plugin writer. For this
> >> >> > example, i simply took the easy route and subclassed ImageWindow
>
> >> >> > Cheers,
>
> >> >> > Chris
>
> >> >> > On Thu, Nov 5, 2009 at 4:24 PM, Chris Colbert <sccolb... at gmail.com> wrote:
> >> >> >> I was just testing out something along these lines, but I run into the
> >> >> >> problem of the the python interpreter not considering time.sleep() as
> >> >> >> idle time, thus, it never calls PyOS_InputHook inside of for-loops. So
> >> >> >> i'm not quite sure how to get video ?feed to run interactively without
> >> >> >> hacking out something like ipython -whatever thread.
>
> >> >> >> Mind you, this is not a problem with the plugin architecture, its a
> >> >> >> problem with the python interpreter...
>
> >> >> >> but maybe i can ctypes into the os_hook and call it at the end of a
> >> >> >> loop.... <evil grin>
>
> >> >> >> 2009/11/5 St?fan van der Walt <ste... at sun.ac.za>:
>
> >> >> >>> 2009/11/5 Chris Colbert <sccolb... at gmail.com>:
> >> >> >>>> Further, these imshow() type widgets are primarily meant to be used
> >> >> >>>> from the interactive interpreter, an environment not best suited for
> >> >> >>>> real time image acquisition and display. that said, the plugin
> >> >> >>>> archiceture can most certainly be used in the method you speak of. You
> >> >> >>>> just simply have your imshow() function return the window object, and
> >> >> >>>> implement an update() or similar method that the consumer can call to
> >> >> >>>> update the image.
>
> >> >> >>> This could even be accomplished using 'imshow' only. ?The
> >> >> >>> WindowManager keeps track of the single window produced, and 'imshow'
> >> >> >>> simply grabs that window and updates its current content. ?I'd be
> >> >> >>> surprised if we couldn't pump out a large number of frames-per-second
> >> >> >>> that way.
>
> >> >> >>> St?fan


From sccolbert at gmail.com  Tue Nov 10 06:08:26 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Tue, 10 Nov 2009 12:08:26 +0100
Subject: Pending release of 0.3
In-Reply-To: <92a1a49d-db47-48a7-bfb6-69ecc650ce34@h34g2000yqm.googlegroups.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com>
	 <9457e7c80911050703u4f9e11bdmdfc525656161ba34@mail.gmail.com>
	 <7f014ea60911050724p76c8fcbfv680229b589dce7d6@mail.gmail.com>
	 <7f014ea60911050756k7fca1b38s6801361ce60c9b30@mail.gmail.com>
	 <7f014ea60911050803x58d166b3h2bbcde8d74aaa957@mail.gmail.com>
	 <c33af287-8157-42d8-b836-53ec510fa8f8@w19g2000yqk.googlegroups.com>
	 <7f014ea60911050833k59616558xd28adfa4951d4700@mail.gmail.com>
	 <0abf5c7e-42c0-439b-8114-bbb3fc170427@a31g2000yqn.googlegroups.com>
	 <7f014ea60911090227t1f04a84btb60ae267f7cf3ef4@mail.gmail.com>
	 <92a1a49d-db47-48a7-bfb6-69ecc650ce34@h34g2000yqm.googlegroups.com>
Message-ID: <7f014ea60911100308hb2d2cc0pdb39775658c78b21@mail.gmail.com>

Holger,

#2 looks a lot like what I cooked up over here. (#1 always segaults
for me, but i could be doing it wrong.)
I tried the Qthread both with a while loop and a QTimer. I think i
like the timer better...

At least I know i'm heading in the right direction.

Cheers,

Chris!

On Tue, Nov 10, 2009 at 10:49 AM, SirVer <sirver at gmx.de> wrote:
>
> Hi Chris,
>
>> Are you able to feed your display widget with images from within a
>> python loop in the interactive shell?
>>
>> ie:
>>
>> while True:
>> ? ? img = grab_new_image()
>> ? ? display.new_image(img)
>> The issue I am having with this PyOS_InputHook, is that for me, that
>> type of loop never lets the interpreter idle (even with a sleep()
>> call) and thus the PyOS_InputHook never gets called, and the gui never
>> updates.
> This can't work as you said. PyOS_InputHook is never called. I doesn't
> work in ipython -q4thread either
> because the thread switch doesn't seem to occure. There are two ways
> to do it
> 1) either call PyOS_InputHook yourself.
> 2) acquire your images in another thread.
>
> I always use 2) since my image acquisition always takes place
> continously in the background. This is also a way were
> PyQT really shines (It also works with wxWidgets that way, but it
> hurts a bit).
>
> so your above example would look a bit like that (not tested, just
> written down like that):
>
> class WorkerThread(QThread):
> ? def __init__(self, display):
> ? ? ?self.connect(self, SIGNAL("newImage"), self.display.newImage)
> ? ? ?# Keep a copy of display around so that the C object doesn't get
> deleted
> ? ? ?self.display = display
>
> ? def run(self):
> ? ? ?while True:
> ? ? ? ? img = grab_new_image()
> ? ? ? ? self.emit(SIGNAL("newImage"), img)
>
> def acquire_images(display):
> ? t = WorkerThread(display)
> ? t.start()
>
> This example should work from the interactive shell provided you
> created a QApplication object so that Qt4 has the PyOS_InputHook
> acquired. Just call acquire_images(display).
>
> Cheers,
> Holger
>
>
>>
>>
>> Cheers,
>>
>> Chris
>>
>>
>>
>> On Fri, Nov 6, 2009 at 11:24 AM, SirVer <sir... at gmx.de> wrote:
>>
>> > Hi Chris,
>>
>> > thanks for the links! It made for some interesting reading; i wasn't
>> > aware of the System Hook. But I just investigated and my Widget works
>> > just fine in a pure python session as long as a QApplication object
>> > has been created before. So there is no problem here, it will work
>> > fine now in ipython -qt4thread and will continue to work in future
>> > ipython and also in vanilla python as long as QApplication(sys.argv)
>> > has been called before the window is created (which is mandatory for
>> > all QT4 Applications). So no problem here.
>>
>> > I now try to come to a conclusion to this thread. I didn't mean to
>> > start a lengthy discussion of how things should be done differently, I
>> > only want to have direction how to implement this. I try to summarize
>> > my thoughts:
>>
>> > * I am often in need to display images from a camera and annotate them
>> > with some output from algorithms (for example mark detected balls in
>> > my ping pong roboters images in red). For this I've written the code
>> > that can be found in my gui branch.
>> > * I feel that this use case is quite different from the idea of the
>> > imshow() plugin. I also feel that more people than me could profit
>> > from this functionality as I use it ATM.
>> > * I feel that this is hard to pull off with a plugin like
>> > architecture, because the annotation part will be different for all
>> > backends and all individual uses. En plus, this is more a Library kind
>> > of functionality, not a enduser kind like imshow().
>> > * My solution works for me and uses PyQt and PyOpenGL. My experiments
>> > showed me that this is the only combination that offers the drawing
>> > speed I want. I understand that other approaches could be possible or
>> > feasible, but I also think that for use cases like mine, this is a
>> > very common approach; especially since annotating in OpenGL is so easy
>> > to do with PyQt4.
>> > * Please let me state again that I do not plan to corrupt or change
>> > the imshow() plugin architecture which I really like. I am just of the
>> > opinion that something else is needed for my use case.
>>
>> > Now, please note that these are my opinions and thought and not really
>> > subject to discussion. What I now really need is a design decision by
>> > the architect of scikit.image; which I assume to be you, stefan:
>>
>> > How should I contribute this code? In which module should it go or is
>> > this not a direction that scikit.image should evolve in (I'd
>> > understand that and instead bring this code into my pydc1394 library
>> > were it would also fit).
>>
>> > Cheers,
>> > Holger
>>
>> > On 5 Nov., 17:33, Chris Colbert <sccolb... at gmail.com> wrote:
>> >> Here's a couple links on it Holger.
>>
>> >> Hopefully the scipy links work for you (its the Ipython part of the
>> >> discussion). I cant get to them right now.
>>
>> >>http://mail.scipy.org/pipermail/ipython-dev/2009-July/005256.htmlhttp...
>>
>> >> On Thu, Nov 5, 2009 at 5:14 PM, SirVer <sir... at gmx.de> wrote:
>>
>> >> >> However, i'm afraid that your current gui may rely on ipython
>> >> >> -q4thread, which is now deprecated (big mailing list discussion on
>> >> >> this). So that may throw a wrench in the video portion of it, unless
>> >> >> we can figure out this pyos_input hook thing.
>> >> > It infact does. Chris, could you please point me at this discussion?
>> >> > It is most relevant for my work.
>>
>> >> > Cheers,
>> >> > Holger
>>
>> >> >> But as my previous example shows, its definately possible to fit it
>> >> >> within the plugin framework.
>>
>> >> >> Cheers!
>>
>> >> >> Chris
>>
>> >> >> On Thu, Nov 5, 2009 at 4:56 PM, Chris Colbert <sccolb... at gmail.com> wrote:
>> >> >> > So while i havent yet been able to get the pyos_inputhook thing sorted
>> >> >> > out, I did time a couple loops.
>>
>> >> >> > For a decent sized image, we can easily get 60fps update rates, and
>> >> >> > thats including the time for the numpy operations:
>>
>> >> >> > In [5]: img = io.imread('/home/brucewayne/Pictures/failboat_4.jpg')
>>
>> >> >> > In [6]: img.shape
>> >> >> > Out[6]: (503, 790, 3)
>>
>> >> >> > In [7]: win = io.imshow(img, updateable=True)
>>
>> >> >> > In [8]: def test(img, win):
>> >> >> > ? ...: ? ? for i in range(30):
>> >> >> > ? ...: ? ? ? ? img[:] += 1
>> >> >> > ? ...: ? ? ? ? win.update()
>> >> >> > ? ...:
>> >> >> > ? ...:
>>
>> >> >> > In [9]: %timeit test(img, win)
>> >> >> > 1 loops, best of 3: 564 ms per loop
>>
>> >> >> > one thing to note, I bypassed the prepare_for_display() method that we
>> >> >> > usually call to make sure an array is contiguous, of the right dtype,
>> >> >> > etc...
>> >> >> > I assume if someone wants video, they can prepare the arrays themselves.
>>
>> >> >> > This behavior can also be changed by the plugin writer. For this
>> >> >> > example, i simply took the easy route and subclassed ImageWindow
>>
>> >> >> > Cheers,
>>
>> >> >> > Chris
>>
>> >> >> > On Thu, Nov 5, 2009 at 4:24 PM, Chris Colbert <sccolb... at gmail.com> wrote:
>> >> >> >> I was just testing out something along these lines, but I run into the
>> >> >> >> problem of the the python interpreter not considering time.sleep() as
>> >> >> >> idle time, thus, it never calls PyOS_InputHook inside of for-loops. So
>> >> >> >> i'm not quite sure how to get video ?feed to run interactively without
>> >> >> >> hacking out something like ipython -whatever thread.
>>
>> >> >> >> Mind you, this is not a problem with the plugin architecture, its a
>> >> >> >> problem with the python interpreter...
>>
>> >> >> >> but maybe i can ctypes into the os_hook and call it at the end of a
>> >> >> >> loop.... <evil grin>
>>
>> >> >> >> 2009/11/5 St?fan van der Walt <ste... at sun.ac.za>:
>>
>> >> >> >>> 2009/11/5 Chris Colbert <sccolb... at gmail.com>:
>> >> >> >>>> Further, these imshow() type widgets are primarily meant to be used
>> >> >> >>>> from the interactive interpreter, an environment not best suited for
>> >> >> >>>> real time image acquisition and display. that said, the plugin
>> >> >> >>>> archiceture can most certainly be used in the method you speak of. You
>> >> >> >>>> just simply have your imshow() function return the window object, and
>> >> >> >>>> implement an update() or similar method that the consumer can call to
>> >> >> >>>> update the image.
>>
>> >> >> >>> This could even be accomplished using 'imshow' only. ?The
>> >> >> >>> WindowManager keeps track of the single window produced, and 'imshow'
>> >> >> >>> simply grabs that window and updates its current content. ?I'd be
>> >> >> >>> surprised if we couldn't pump out a large number of frames-per-second
>> >> >> >>> that way.
>>
>> >> >> >>> St?fan
>


From sirver at gmx.de  Tue Nov 10 15:48:35 2009
From: sirver at gmx.de (SirVer)
Date: Tue, 10 Nov 2009 12:48:35 -0800 (PST)
Subject: Pending release of 0.3
In-Reply-To: <7f014ea60911100308hb2d2cc0pdb39775658c78b21@mail.gmail.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com> 
	<9457e7c80911050703u4f9e11bdmdfc525656161ba34@mail.gmail.com> 
	<7f014ea60911050724p76c8fcbfv680229b589dce7d6@mail.gmail.com> 
	<7f014ea60911050756k7fca1b38s6801361ce60c9b30@mail.gmail.com> 
	<7f014ea60911050803x58d166b3h2bbcde8d74aaa957@mail.gmail.com> 
	<c33af287-8157-42d8-b836-53ec510fa8f8@w19g2000yqk.googlegroups.com> 
	<7f014ea60911050833k59616558xd28adfa4951d4700@mail.gmail.com> 
	<0abf5c7e-42c0-439b-8114-bbb3fc170427@a31g2000yqn.googlegroups.com> 
	<7f014ea60911090227t1f04a84btb60ae267f7cf3ef4@mail.gmail.com> 
	<92a1a49d-db47-48a7-bfb6-69ecc650ce34@h34g2000yqm.googlegroups.com> 
	<7f014ea60911100308hb2d2cc0pdb39775658c78b21@mail.gmail.com>
Message-ID: <4fd37a7d-bed7-4303-8c5a-ef9f98e5f4f4@a32g2000yqm.googlegroups.com>

Chris,

I forget to point you to a working example in my pydc code. Sorry for
that:

http://bazaar.launchpad.net/%7Esirver/pydc1394/trunk/annotate/head%3A/pydc1394/ui/qt/display.py

That's pretty much all knowledge I have about real time acquistion &
display with PyQt & PyOpenGL.

Cheers,
Holger

On 10 Nov., 12:08, Chris Colbert <sccolb... at gmail.com> wrote:
> Holger,
>
> #2 looks a lot like what I cooked up over here. (#1 always segaults
> for me, but i could be doing it wrong.)
> I tried the Qthread both with a while loop and a QTimer. I think i
> like the timer better...
>
> At least I know i'm heading in the right direction.
>
> Cheers,
>
> Chris!
>
>
>
> On Tue, Nov 10, 2009 at 10:49 AM, SirVer <sir... at gmx.de> wrote:
>
> > Hi Chris,
>
> >> Are you able to feed your display widget with images from within a
> >> python loop in the interactive shell?
>
> >> ie:
>
> >> while True:
> >> ? ? img = grab_new_image()
> >> ? ? display.new_image(img)
> >> The issue I am having with this PyOS_InputHook, is that for me, that
> >> type of loop never lets the interpreter idle (even with a sleep()
> >> call) and thus the PyOS_InputHook never gets called, and the gui never
> >> updates.
> > This can't work as you said. PyOS_InputHook is never called. I doesn't
> > work in ipython -q4thread either
> > because the thread switch doesn't seem to occure. There are two ways
> > to do it
> > 1) either call PyOS_InputHook yourself.
> > 2) acquire your images in another thread.
>
> > I always use 2) since my image acquisition always takes place
> > continously in the background. This is also a way were
> > PyQT really shines (It also works with wxWidgets that way, but it
> > hurts a bit).
>
> > so your above example would look a bit like that (not tested, just
> > written down like that):
>
> > class WorkerThread(QThread):
> > ? def __init__(self, display):
> > ? ? ?self.connect(self, SIGNAL("newImage"), self.display.newImage)
> > ? ? ?# Keep a copy of display around so that the C object doesn't get
> > deleted
> > ? ? ?self.display = display
>
> > ? def run(self):
> > ? ? ?while True:
> > ? ? ? ? img = grab_new_image()
> > ? ? ? ? self.emit(SIGNAL("newImage"), img)
>
> > def acquire_images(display):
> > ? t = WorkerThread(display)
> > ? t.start()
>
> > This example should work from the interactive shell provided you
> > created a QApplication object so that Qt4 has the PyOS_InputHook
> > acquired. Just call acquire_images(display).
>
> > Cheers,
> > Holger
>
> >> Cheers,
>
> >> Chris
>
> >> On Fri, Nov 6, 2009 at 11:24 AM, SirVer <sir... at gmx.de> wrote:
>
> >> > Hi Chris,
>
> >> > thanks for the links! It made for some interesting reading; i wasn't
> >> > aware of the System Hook. But I just investigated and my Widget works
> >> > just fine in a pure python session as long as a QApplication object
> >> > has been created before. So there is no problem here, it will work
> >> > fine now in ipython -qt4thread and will continue to work in future
> >> > ipython and also in vanilla python as long as QApplication(sys.argv)
> >> > has been called before the window is created (which is mandatory for
> >> > all QT4 Applications). So no problem here.
>
> >> > I now try to come to a conclusion to this thread. I didn't mean to
> >> > start a lengthy discussion of how things should be done differently, I
> >> > only want to have direction how to implement this. I try to summarize
> >> > my thoughts:
>
> >> > * I am often in need to display images from a camera and annotate them
> >> > with some output from algorithms (for example mark detected balls in
> >> > my ping pong roboters images in red). For this I've written the code
> >> > that can be found in my gui branch.
> >> > * I feel that this use case is quite different from the idea of the
> >> > imshow() plugin. I also feel that more people than me could profit
> >> > from this functionality as I use it ATM.
> >> > * I feel that this is hard to pull off with a plugin like
> >> > architecture, because the annotation part will be different for all
> >> > backends and all individual uses. En plus, this is more a Library kind
> >> > of functionality, not a enduser kind like imshow().
> >> > * My solution works for me and uses PyQt and PyOpenGL. My experiments
> >> > showed me that this is the only combination that offers the drawing
> >> > speed I want. I understand that other approaches could be possible or
> >> > feasible, but I also think that for use cases like mine, this is a
> >> > very common approach; especially since annotating in OpenGL is so easy
> >> > to do with PyQt4.
> >> > * Please let me state again that I do not plan to corrupt or change
> >> > the imshow() plugin architecture which I really like. I am just of the
> >> > opinion that something else is needed for my use case.
>
> >> > Now, please note that these are my opinions and thought and not really
> >> > subject to discussion. What I now really need is a design decision by
> >> > the architect of scikit.image; which I assume to be you, stefan:
>
> >> > How should I contribute this code? In which module should it go or is
> >> > this not a direction that scikit.image should evolve in (I'd
> >> > understand that and instead bring this code into my pydc1394 library
> >> > were it would also fit).
>
> >> > Cheers,
> >> > Holger
>
> >> > On 5 Nov., 17:33, Chris Colbert <sccolb... at gmail.com> wrote:
> >> >> Here's a couple links on it Holger.
>
> >> >> Hopefully the scipy links work for you (its the Ipython part of the
> >> >> discussion). I cant get to them right now.
>
> >> >>http://mail.scipy.org/pipermail/ipython-dev/2009-July/005256.htmlhttp...
>
> >> >> On Thu, Nov 5, 2009 at 5:14 PM, SirVer <sir... at gmx.de> wrote:
>
> >> >> >> However, i'm afraid that your current gui may rely on ipython
> >> >> >> -q4thread, which is now deprecated (big mailing list discussion on
> >> >> >> this). So that may throw a wrench in the video portion of it, unless
> >> >> >> we can figure out this pyos_input hook thing.
> >> >> > It infact does. Chris, could you please point me at this discussion?
> >> >> > It is most relevant for my work.
>
> >> >> > Cheers,
> >> >> > Holger
>
> >> >> >> But as my previous example shows, its definately possible to fit it
> >> >> >> within the plugin framework.
>
> >> >> >> Cheers!
>
> >> >> >> Chris
>
> >> >> >> On Thu, Nov 5, 2009 at 4:56 PM, Chris Colbert <sccolb... at gmail.com> wrote:
> >> >> >> > So while i havent yet been able to get the pyos_inputhook thing sorted
> >> >> >> > out, I did time a couple loops.
>
> >> >> >> > For a decent sized image, we can easily get 60fps update rates, and
> >> >> >> > thats including the time for the numpy operations:
>
> >> >> >> > In [5]: img = io.imread('/home/brucewayne/Pictures/failboat_4.jpg')
>
> >> >> >> > In [6]: img.shape
> >> >> >> > Out[6]: (503, 790, 3)
>
> >> >> >> > In [7]: win = io.imshow(img, updateable=True)
>
> >> >> >> > In [8]: def test(img, win):
> >> >> >> > ? ...: ? ? for i in range(30):
> >> >> >> > ? ...: ? ? ? ? img[:] += 1
> >> >> >> > ? ...: ? ? ? ? win.update()
> >> >> >> > ? ...:
> >> >> >> > ? ...:
>
> >> >> >> > In [9]: %timeit test(img, win)
> >> >> >> > 1 loops, best of 3: 564 ms per loop
>
> >> >> >> > one thing to note, I bypassed the prepare_for_display() method that we
> >> >> >> > usually call to make sure an array is contiguous, of the right dtype,
> >> >> >> > etc...
> >> >> >> > I assume if someone wants video, they can prepare the arrays themselves.
>
> >> >> >> > This behavior can also be changed by the plugin writer. For this
> >> >> >> > example, i simply took the easy route and subclassed ImageWindow
>
> >> >> >> > Cheers,
>
> >> >> >> > Chris
>
> >> >> >> > On Thu, Nov 5, 2009 at 4:24 PM, Chris Colbert <sccolb... at gmail.com> wrote:
> >> >> >> >> I was just testing out something along these lines, but I run into the
> >> >> >> >> problem of the the python interpreter not considering time.sleep() as
> >> >> >> >> idle time, thus, it never calls PyOS_InputHook inside of for-loops. So
> >> >> >> >> i'm not quite sure how to get video ?feed to run interactively without
> >> >> >> >> hacking out something like ipython -whatever thread.
>
> >> >> >> >> Mind you, this is not a problem with the plugin architecture, its a
> >> >> >> >> problem with the python interpreter...
>
> >> >> >> >> but maybe i can ctypes into the os_hook and call it at the end of a
> >> >> >> >> loop.... <evil grin>
>
> >> >> >> >> 2009/11/5 St?fan van der Walt <ste... at sun.ac.za>:
>
> >> >> >> >>> 2009/11/5 Chris Colbert <sccolb... at gmail.com>:
> >> >> >> >>>> Further, these imshow() type widgets are primarily meant to be used
> >> >> >> >>>> from the interactive interpreter, an environment not best suited for
> >> >> >> >>>> real time image acquisition and display. that said, the plugin
> >> >> >> >>>> archiceture can most certainly be used in the method you speak of. You
> >> >> >> >>>> just simply have your imshow() function return the window object, and
> >> >> >> >>>> implement an update() or similar method that the consumer can call to
> >> >> >> >>>> update the image.
>
> >> >> >> >>> This could even be accomplished using 'imshow' only. ?The
> >> >> >> >>> WindowManager keeps track of the single window produced, and 'imshow'
> >> >> >> >>> simply grabs that window and updates its current content. ?I'd be
> >> >> >> >>> surprised if we couldn't pump out a large number of frames-per-second
> >> >> >> >>> that way.
>
> >> >> >> >>> St?fan


From sirver at gmx.de  Wed Nov 11 04:39:27 2009
From: sirver at gmx.de (SirVer)
Date: Wed, 11 Nov 2009 01:39:27 -0800 (PST)
Subject: Pending release of 0.3
In-Reply-To: <7f014ea60911110108m2e97214cv7d40ac0590d68cfa@mail.gmail.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com> 
	<7f014ea60911050756k7fca1b38s6801361ce60c9b30@mail.gmail.com> 
	<7f014ea60911050803x58d166b3h2bbcde8d74aaa957@mail.gmail.com> 
	<c33af287-8157-42d8-b836-53ec510fa8f8@w19g2000yqk.googlegroups.com> 
	<7f014ea60911050833k59616558xd28adfa4951d4700@mail.gmail.com> 
	<0abf5c7e-42c0-439b-8114-bbb3fc170427@a31g2000yqn.googlegroups.com> 
	<7f014ea60911090227t1f04a84btb60ae267f7cf3ef4@mail.gmail.com> 
	<92a1a49d-db47-48a7-bfb6-69ecc650ce34@h34g2000yqm.googlegroups.com> 
	<7f014ea60911100308hb2d2cc0pdb39775658c78b21@mail.gmail.com> 
	<4fd37a7d-bed7-4303-8c5a-ef9f98e5f4f4@a32g2000yqm.googlegroups.com> 
	<7f014ea60911110108m2e97214cv7d40ac0590d68cfa@mail.gmail.com>
Message-ID: <956a9252-b63e-49bf-8526-9990d2e4cae5@d5g2000yqm.googlegroups.com>

Hi Chris,

> DId you find that you needed the mutex even with the GIL?
Yes I did. The GIL doesn't prevent deadlocks in all cases since we
have no guarantee
when python does a context switch. Shared variables (that can be
written in both threads) still
need protection by something. I am pretty sure it is needed at this
point.

Cheers
Holger

>
> Chris
>
>
>
> On Tue, Nov 10, 2009 at 9:48 PM, SirVer <sir... at gmx.de> wrote:
>
> > Chris,
>
> > I forget to point you to a working example in my pydc code. Sorry for
> > that:
>
> >http://bazaar.launchpad.net/%7Esirver/pydc1394/trunk/annotate/head%3A...
>
> > That's pretty much all knowledge I have about real time acquistion &
> > display with PyQt & PyOpenGL.
>
> > Cheers,
> > Holger
>
> > On 10 Nov., 12:08, Chris Colbert <sccolb... at gmail.com> wrote:
> >> Holger,
>
> >> #2 looks a lot like what I cooked up over here. (#1 always segaults
> >> for me, but i could be doing it wrong.)
> >> I tried the Qthread both with a while loop and a QTimer. I think i
> >> like the timer better...
>
> >> At least I know i'm heading in the right direction.
>
> >> Cheers,
>
> >> Chris!
>
> >> On Tue, Nov 10, 2009 at 10:49 AM, SirVer <sir... at gmx.de> wrote:
>
> >> > Hi Chris,
>
> >> >> Are you able to feed your display widget with images from within a
> >> >> python loop in the interactive shell?
>
> >> >> ie:
>
> >> >> while True:
> >> >> ? ? img = grab_new_image()
> >> >> ? ? display.new_image(img)
> >> >> The issue I am having with this PyOS_InputHook, is that for me, that
> >> >> type of loop never lets the interpreter idle (even with a sleep()
> >> >> call) and thus the PyOS_InputHook never gets called, and the gui never
> >> >> updates.
> >> > This can't work as you said. PyOS_InputHook is never called. I doesn't
> >> > work in ipython -q4thread either
> >> > because the thread switch doesn't seem to occure. There are two ways
> >> > to do it
> >> > 1) either call PyOS_InputHook yourself.
> >> > 2) acquire your images in another thread.
>
> >> > I always use 2) since my image acquisition always takes place
> >> > continously in the background. This is also a way were
> >> > PyQT really shines (It also works with wxWidgets that way, but it
> >> > hurts a bit).
>
> >> > so your above example would look a bit like that (not tested, just
> >> > written down like that):
>
> >> > class WorkerThread(QThread):
> >> > ? def __init__(self, display):
> >> > ? ? ?self.connect(self, SIGNAL("newImage"), self.display.newImage)
> >> > ? ? ?# Keep a copy of display around so that the C object doesn't get
> >> > deleted
> >> > ? ? ?self.display = display
>
> >> > ? def run(self):
> >> > ? ? ?while True:
> >> > ? ? ? ? img = grab_new_image()
> >> > ? ? ? ? self.emit(SIGNAL("newImage"), img)
>
> >> > def acquire_images(display):
> >> > ? t = WorkerThread(display)
> >> > ? t.start()
>
> >> > This example should work from the interactive shell provided you
> >> > created a QApplication object so that Qt4 has the PyOS_InputHook
> >> > acquired. Just call acquire_images(display).
>
> >> > Cheers,
> >> > Holger
>
> >> >> Cheers,
>
> >> >> Chris
>
> >> >> On Fri, Nov 6, 2009 at 11:24 AM, SirVer <sir... at gmx.de> wrote:
>
> >> >> > Hi Chris,
>
> >> >> > thanks for the links! It made for some interesting reading; i wasn't
> >> >> > aware of the System Hook. But I just investigated and my Widget works
> >> >> > just fine in a pure python session as long as a QApplication object
> >> >> > has been created before. So there is no problem here, it will work
> >> >> > fine now in ipython -qt4thread and will continue to work in future
> >> >> > ipython and also in vanilla python as long as QApplication(sys.argv)
> >> >> > has been called before the window is created (which is mandatory for
> >> >> > all QT4 Applications). So no problem here.
>
> >> >> > I now try to come to a conclusion to this thread. I didn't mean to
> >> >> > start a lengthy discussion of how things should be done differently, I
> >> >> > only want to have direction how to implement this. I try to summarize
> >> >> > my thoughts:
>
> >> >> > * I am often in need to display images from a camera and annotate them
> >> >> > with some output from algorithms (for example mark detected balls in
> >> >> > my ping pong roboters images in red). For this I've written the code
> >> >> > that can be found in my gui branch.
> >> >> > * I feel that this use case is quite different from the idea of the
> >> >> > imshow() plugin. I also feel that more people than me could profit
> >> >> > from this functionality as I use it ATM.
> >> >> > * I feel that this is hard to pull off with a plugin like
> >> >> > architecture, because the annotation part will be different for all
> >> >> > backends and all individual uses. En plus, this is more a Library kind
> >> >> > of functionality, not a enduser kind like imshow().
> >> >> > * My solution works for me and uses PyQt and PyOpenGL. My experiments
> >> >> > showed me that this is the only combination that offers the drawing
> >> >> > speed I want. I understand that other approaches could be possible or
> >> >> > feasible, but I also think that for use cases like mine, this is a
> >> >> > very common approach; especially since annotating in OpenGL is so easy
> >> >> > to do with PyQt4.
> >> >> > * Please let me state again that I do not plan to corrupt or change
> >> >> > the imshow() plugin architecture which I really like. I am just of the
> >> >> > opinion that something else is needed for my use case.
>
> >> >> > Now, please note that these are my opinions and thought and not really
> >> >> > subject to discussion. What I now really need is a design decision by
> >> >> > the architect of scikit.image; which I assume to be you, stefan:
>
> >> >> > How should I contribute this code? In which module should it go or is
> >> >> > this not a direction that scikit.image should evolve in (I'd
> >> >> > understand that and instead bring this code into my pydc1394 library
> >> >> > were it would also fit).
>
> >> >> > Cheers,
> >> >> > Holger
>
> >> >> > On 5 Nov., 17:33, Chris Colbert <sccolb... at gmail.com> wrote:
> >> >> >> Here's a couple links on it Holger.
>
> >> >> >> Hopefully the scipy links work for you (its the Ipython part of the
> >> >> >> discussion). I cant get to them right now.
>
> >> >> >>http://mail.scipy.org/pipermail/ipython-dev/2009-July/005256.htmlhttp...
>
> >> >> >> On Thu, Nov 5, 2009 at 5:14 PM, SirVer <sir... at gmx.de> wrote:
>
> >> >> >> >> However, i'm afraid that your current gui may rely on ipython
> >> >> >> >> -q4thread, which is now deprecated (big mailing list discussion on
> >> >> >> >> this). So that may throw a wrench in the video portion of it, unless
> >> >> >> >> we can figure out this pyos_input hook thing.
> >> >> >> > It infact does. Chris, could you please point me at this discussion?
> >> >> >> > It is most relevant for my work.
>
> >> >> >> > Cheers,
> >> >> >> > Holger
>
> >> >> >> >> But as my previous example shows, its definately possible to fit it
> >> >> >> >> within the plugin framework.
>
> >> >> >> >> Cheers!
>
> >> >> >> >> Chris
>
> >> >> >> >> On Thu, Nov 5, 2009 at 4:56 PM, Chris Colbert <sccolb... at gmail.com> wrote:
> >> >> >> >> > So while i havent yet been able to get the pyos_inputhook thing sorted
> >> >> >> >> > out, I did time a couple loops.
>
> >> >> >> >> > For a decent sized image, we can easily get 60fps update rates, and
> >> >> >> >> > thats including the time for the numpy operations:
>
> >> >> >> >> > In [5]: img = io.imread('/home/brucewayne/Pictures/failboat_4.jpg')
>
> >> >> >> >> > In [6]: img.shape
> >> >> >> >> > Out[6]: (503, 790, 3)
>
> >> >> >> >> > In [7]: win = io.imshow(img, updateable=True)
>
> >> >> >> >> > In [8]: def test(img, win):
> >> >> >> >> > ? ...: ? ? for i in range(30):
> >> >> >> >> > ? ...: ? ? ? ? img[:] += 1
> >> >> >> >> > ? ...: ? ? ? ? win.update()
> >> >> >> >> > ? ...:
> >> >> >> >> > ? ...:
>
> >> >> >> >> > In [9]: %timeit test(img, win)
> >> >> >> >> > 1 loops, best of 3: 564 ms per loop
>
> >> >> >> >> > one thing to note, I bypassed the prepare_for_display() method that we
> >> >> >> >> > usually call to make sure an array is contiguous, of the right dtype,
> >> >> >> >> > etc...
> >> >> >> >> > I assume if someone wants video, they can prepare the arrays themselves.
>
> >> >> >> >> > This behavior can also be changed by the plugin writer. For this
> >> >> >> >> > example, i simply took the easy route and subclassed ImageWindow
>
> >> >> >> >> > Cheers,
>
> >> >> >> >> > Chris
>
> >> >> >> >> > On Thu, Nov 5, 2009 at 4:24 PM, Chris Colbert <sccolb... at gmail.com> wrote:
> >> >> >> >> >> I was just testing out something along these lines, but I run into the
> >> >> >> >> >> problem of the the python interpreter not considering time.sleep() as
> >> >> >> >> >> idle time, thus, it never calls PyOS_InputHook inside of for-loops. So
> >> >> >> >> >> i'm not quite sure how to get video ?feed to run interactively without
> >> >> >> >> >> hacking out something like ipython -whatever thread.
>
> >> >> >> >> >> Mind you, this is not a problem with the plugin architecture, its a
> >> >> >> >> >> problem with the python interpreter...
>
> >> >> >> >> >> but maybe i can ctypes into the os_hook and call it at the end of a
> >> >> >> >> >> loop.... <evil grin>
>
> >> >> >> >> >> 2009/11/5 St?fan van der Walt <ste... at sun.ac.za>:
>
> >> >> >> >> >>> 2009/11/5 Chris Colbert <sccolb... at gmail.com>:
> >> >> >> >> >>>> Further, these imshow() type widgets are primarily meant to be used
> >> >> >> >> >>>> from the interactive interpreter, an environment not best suited for
> >> >> >> >> >>>> real time image acquisition and display. that said, the plugin
> >> >> >> >> >>>> archiceture can most certainly be used in the method you speak of. You
> >> >> >> >> >>>> just simply have your imshow() function return the window object, and
> >> >> >> >> >>>> implement an update() or similar method that the consumer can call to
> >> >> >> >> >>>> update the image.
>
> >> >> >> >> >>> This could even be accomplished using 'imshow' only. ?The
> >> >> >> >> >>> WindowManager keeps track of the single window produced, and 'imshow'
> >> >> >> >> >>> simply grabs that window and updates its current content. ?I'd be
> >> >> >> >> >>> surprised if we couldn't pump out a large number of frames-per-second
> >> >> >> >> >>> that way.
>
> >> >> >> >> >>> St?fan


From sirver at gmx.de  Wed Nov 11 05:08:37 2009
From: sirver at gmx.de (SirVer)
Date: Wed, 11 Nov 2009 02:08:37 -0800 (PST)
Subject: Pending release of 0.3
In-Reply-To: <7f014ea60911110144s7458e217s610f73fea82ed6e@mail.gmail.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com> 
	<7f014ea60911050833k59616558xd28adfa4951d4700@mail.gmail.com> 
	<0abf5c7e-42c0-439b-8114-bbb3fc170427@a31g2000yqn.googlegroups.com> 
	<7f014ea60911090227t1f04a84btb60ae267f7cf3ef4@mail.gmail.com> 
	<92a1a49d-db47-48a7-bfb6-69ecc650ce34@h34g2000yqm.googlegroups.com> 
	<7f014ea60911100308hb2d2cc0pdb39775658c78b21@mail.gmail.com> 
	<4fd37a7d-bed7-4303-8c5a-ef9f98e5f4f4@a32g2000yqm.googlegroups.com> 
	<7f014ea60911110108m2e97214cv7d40ac0590d68cfa@mail.gmail.com> 
	<956a9252-b63e-49bf-8526-9990d2e4cae5@d5g2000yqm.googlegroups.com> 
	<7f014ea60911110141k1468f703t604d8b924d97d0de@mail.gmail.com> 
	<7f014ea60911110144s7458e217s610f73fea82ed6e@mail.gmail.com>
Message-ID: <b8be5321-471a-46a1-b9b4-88d545062791@k4g2000yqb.googlegroups.com>

Hi,

> I meant, do you have a QT call that is writing to a python variable?
I do not. I am unsure if QT is killing the thread (because it is a
child of the window) upon window close using the stop() function. This
could have been the reason to add the mutex in the first place.

If you feel bad about the mutex, just remove it and see how it goes. I
assume it is save and portable to use it as i did.

Cheers,
Holger

>
>
>
> On Wed, Nov 11, 2009 at 10:41 AM, Chris Colbert <sccolb... at gmail.com> wrote:
> > right, but the gil ensures that only one piece of python code is
> > executing at a time.
>
> > Perhaps I missed it, did have a qt call that right to a python variable?
>
> > On Wed, Nov 11, 2009 at 10:39 AM, SirVer <sir... at gmx.de> wrote:
>
> >> Hi Chris,
>
> >>> DId you find that you needed the mutex even with the GIL?
> >> Yes I did. The GIL doesn't prevent deadlocks in all cases since we
> >> have no guarantee
> >> when python does a context switch. Shared variables (that can be
> >> written in both threads) still
> >> need protection by something. I am pretty sure it is needed at this
> >> point.
>
> >> Cheers
> >> Holger
>
> >>> Chris
>
> >>> On Tue, Nov 10, 2009 at 9:48 PM, SirVer <sir... at gmx.de> wrote:
>
> >>> > Chris,
>
> >>> > I forget to point you to a working example in my pydc code. Sorry for
> >>> > that:
>
> >>> >http://bazaar.launchpad.net/%7Esirver/pydc1394/trunk/annotate/head%3A...
>
> >>> > That's pretty much all knowledge I have about real time acquistion &
> >>> > display with PyQt & PyOpenGL.
>
> >>> > Cheers,
> >>> > Holger
>
> >>> > On 10 Nov., 12:08, Chris Colbert <sccolb... at gmail.com> wrote:
> >>> >> Holger,
>
> >>> >> #2 looks a lot like what I cooked up over here. (#1 always segaults
> >>> >> for me, but i could be doing it wrong.)
> >>> >> I tried the Qthread both with a while loop and a QTimer. I think i
> >>> >> like the timer better...
>
> >>> >> At least I know i'm heading in the right direction.
>
> >>> >> Cheers,
>
> >>> >> Chris!
>
> >>> >> On Tue, Nov 10, 2009 at 10:49 AM, SirVer <sir... at gmx.de> wrote:
>
> >>> >> > Hi Chris,
>
> >>> >> >> Are you able to feed your display widget with images from within a
> >>> >> >> python loop in the interactive shell?
>
> >>> >> >> ie:
>
> >>> >> >> while True:
> >>> >> >> ? ? img = grab_new_image()
> >>> >> >> ? ? display.new_image(img)
> >>> >> >> The issue I am having with this PyOS_InputHook, is that for me, that
> >>> >> >> type of loop never lets the interpreter idle (even with a sleep()
> >>> >> >> call) and thus the PyOS_InputHook never gets called, and the gui never
> >>> >> >> updates.
> >>> >> > This can't work as you said. PyOS_InputHook is never called. I doesn't
> >>> >> > work in ipython -q4thread either
> >>> >> > because the thread switch doesn't seem to occure. There are two ways
> >>> >> > to do it
> >>> >> > 1) either call PyOS_InputHook yourself.
> >>> >> > 2) acquire your images in another thread.
>
> >>> >> > I always use 2) since my image acquisition always takes place
> >>> >> > continously in the background. This is also a way were
> >>> >> > PyQT really shines (It also works with wxWidgets that way, but it
> >>> >> > hurts a bit).
>
> >>> >> > so your above example would look a bit like that (not tested, just
> >>> >> > written down like that):
>
> >>> >> > class WorkerThread(QThread):
> >>> >> > ? def __init__(self, display):
> >>> >> > ? ? ?self.connect(self, SIGNAL("newImage"), self.display.newImage)
> >>> >> > ? ? ?# Keep a copy of display around so that the C object doesn't get
> >>> >> > deleted
> >>> >> > ? ? ?self.display = display
>
> >>> >> > ? def run(self):
> >>> >> > ? ? ?while True:
> >>> >> > ? ? ? ? img = grab_new_image()
> >>> >> > ? ? ? ? self.emit(SIGNAL("newImage"), img)
>
> >>> >> > def acquire_images(display):
> >>> >> > ? t = WorkerThread(display)
> >>> >> > ? t.start()
>
> >>> >> > This example should work from the interactive shell provided you
> >>> >> > created a QApplication object so that Qt4 has the PyOS_InputHook
> >>> >> > acquired. Just call acquire_images(display).
>
> >>> >> > Cheers,
> >>> >> > Holger
>
> >>> >> >> Cheers,
>
> >>> >> >> Chris
>
> >>> >> >> On Fri, Nov 6, 2009 at 11:24 AM, SirVer <sir... at gmx.de> wrote:
>
> >>> >> >> > Hi Chris,
>
> >>> >> >> > thanks for the links! It made for some interesting reading; i wasn't
> >>> >> >> > aware of the System Hook. But I just investigated and my Widget works
> >>> >> >> > just fine in a pure python session as long as a QApplication object
> >>> >> >> > has been created before. So there is no problem here, it will work
> >>> >> >> > fine now in ipython -qt4thread and will continue to work in future
> >>> >> >> > ipython and also in vanilla python as long as QApplication(sys.argv)
> >>> >> >> > has been called before the window is created (which is mandatory for
> >>> >> >> > all QT4 Applications). So no problem here.
>
> >>> >> >> > I now try to come to a conclusion to this thread. I didn't mean to
> >>> >> >> > start a lengthy discussion of how things should be done differently, I
> >>> >> >> > only want to have direction how to implement this. I try to summarize
> >>> >> >> > my thoughts:
>
> >>> >> >> > * I am often in need to display images from a camera and annotate them
> >>> >> >> > with some output from algorithms (for example mark detected balls in
> >>> >> >> > my ping pong roboters images in red). For this I've written the code
> >>> >> >> > that can be found in my gui branch.
> >>> >> >> > * I feel that this use case is quite different from the idea of the
> >>> >> >> > imshow() plugin. I also feel that more people than me could profit
> >>> >> >> > from this functionality as I use it ATM.
> >>> >> >> > * I feel that this is hard to pull off with a plugin like
> >>> >> >> > architecture, because the annotation part will be different for all
> >>> >> >> > backends and all individual uses. En plus, this is more a Library kind
> >>> >> >> > of functionality, not a enduser kind like imshow().
> >>> >> >> > * My solution works for me and uses PyQt and PyOpenGL. My experiments
> >>> >> >> > showed me that this is the only combination that offers the drawing
> >>> >> >> > speed I want. I understand that other approaches could be possible or
> >>> >> >> > feasible, but I also think that for use cases like mine, this is a
> >>> >> >> > very common approach; especially since annotating in OpenGL is so easy
> >>> >> >> > to do with PyQt4.
> >>> >> >> > * Please let me state again that I do not plan to corrupt or change
> >>> >> >> > the imshow() plugin architecture which I really like. I am just of the
> >>> >> >> > opinion that something else is needed for my use case.
>
> >>> >> >> > Now, please note that these are my opinions and thought and not really
> >>> >> >> > subject to discussion. What I now really need is a design decision by
> >>> >> >> > the architect of scikit.image; which I assume to be you, stefan:
>
> >>> >> >> > How should I contribute this code? In which module should it go or is
> >>> >> >> > this not a direction that scikit.image should evolve in (I'd
> >>> >> >> > understand that and instead bring this code into my pydc1394 library
> >>> >> >> > were it would also fit).
>
> >>> >> >> > Cheers,
> >>> >> >> > Holger
>
> >>> >> >> > On 5 Nov., 17:33, Chris Colbert <sccolb... at gmail.com> wrote:
> >>> >> >> >> Here's a couple links on it Holger.
>
> >>> >> >> >> Hopefully the scipy links work for you (its the Ipython part of the
> >>> >> >> >> discussion). I cant get to them right now.
>
> >>> >> >> >>http://mail.scipy.org/pipermail/ipython-dev/2009-July/005256.htmlhttp...
>
> >>> >> >> >> On Thu, Nov 5, 2009 at 5:14 PM, SirVer <sir... at gmx.de> wrote:
>
> >>> >> >> >> >> However, i'm afraid that your current gui may rely on ipython
> >>> >> >> >> >> -q4thread, which is now deprecated (big mailing list discussion on
> >>> >> >> >> >> this). So that may throw a wrench in the video portion of it, unless
> >>> >> >> >> >> we can figure out this pyos_input hook thing.
> >>> >> >> >> > It infact does. Chris, could you please point me at this discussion?
> >>> >> >> >> > It is most relevant for my work.
>
> >>> >> >> >> > Cheers,
> >>> >> >> >> > Holger
>
> >>> >> >> >> >> But as my previous example shows, its definately possible to fit it
> >>> >> >> >> >> within the plugin framework.
>
> >>> >> >> >> >> Cheers!
>
> >>> >> >> >> >> Chris
>
> >>> >> >> >> >> On Thu, Nov 5, 2009 at 4:56 PM, Chris Colbert <sccolb... at gmail.com> wrote:
> >>> >> >> >> >> > So while i havent yet been able to get the pyos_inputhook thing sorted
> >>> >> >> >> >> > out, I did time a couple loops.
>
> >>> >> >> >> >> > For a decent sized image, we can easily get 60fps update rates, and
> >>> >> >> >> >> > thats including the time for the numpy operations:
>
> >>> >> >> >> >> > In [5]: img = io.imread('/home/brucewayne/Pictures/failboat_4.jpg')
>
> >>> >> >> >> >> > In [6]: img.shape
> >>> >> >> >> >> > Out[6]: (503, 790, 3)
>
> >>> >> >> >> >> > In [7]: win = io.imshow(img, updateable=True)
>
> >>> >> >> >> >> > In [8]: def test(img, win):
> >>> >> >> >> >> > ? ...: ? ? for i in range(30):
> >>> >> >> >> >> > ? ...: ? ? ? ? img[:] += 1
> >>> >> >> >> >> > ? ...: ? ? ? ? win.update()
> >>> >> >> >> >> > ? ...:
> >>> >> >> >> >> > ? ...:
>
> >>> >> >> >> >> > In [9]: %timeit test(img, win)
> >>> >> >> >> >> > 1 loops, best of 3: 564 ms per loop
>
> >>> >> >> >> >> > one thing to note, I bypassed the prepare_for_display() method that we
> >>> >> >> >> >> > usually call to make sure an array is contiguous, of the right dtype,
> >>> >> >> >> >> > etc...
> >>> >> >> >> >> > I assume if someone wants video, they can prepare the arrays themselves.
>
> >>> >> >> >> >> > This behavior can also be changed by the plugin writer. For this
> >>> >> >> >> >> > example, i simply took the easy route and subclassed ImageWindow
>
> >>> >> >> >> >> > Cheers,
>
> >>> >> >> >> >> > Chris
>
> >>> >> >> >> >> > On Thu, Nov 5, 2009 at 4:24 PM, Chris Colbert <sccolb... at gmail.com> wrote:
> >>> >> >> >> >> >> I was just testing out something along these lines, but I run into the
> >>> >> >> >> >> >> problem of the the python interpreter not considering time.sleep() as
> >>> >> >> >> >> >> idle time, thus, it never calls PyOS_InputHook inside of for-loops. So
> >>> >> >> >> >> >> i'm not quite sure how to get video ?feed to run interactively without
> >>> >> >> >> >> >> hacking out something like ipython -whatever thread....
>
> Erfahren Sie mehr ?


From sccolbert at gmail.com  Wed Nov 11 04:08:45 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Wed, 11 Nov 2009 10:08:45 +0100
Subject: Pending release of 0.3
In-Reply-To: <4fd37a7d-bed7-4303-8c5a-ef9f98e5f4f4@a32g2000yqm.googlegroups.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com>
	 <7f014ea60911050756k7fca1b38s6801361ce60c9b30@mail.gmail.com>
	 <7f014ea60911050803x58d166b3h2bbcde8d74aaa957@mail.gmail.com>
	 <c33af287-8157-42d8-b836-53ec510fa8f8@w19g2000yqk.googlegroups.com>
	 <7f014ea60911050833k59616558xd28adfa4951d4700@mail.gmail.com>
	 <0abf5c7e-42c0-439b-8114-bbb3fc170427@a31g2000yqn.googlegroups.com>
	 <7f014ea60911090227t1f04a84btb60ae267f7cf3ef4@mail.gmail.com>
	 <92a1a49d-db47-48a7-bfb6-69ecc650ce34@h34g2000yqm.googlegroups.com>
	 <7f014ea60911100308hb2d2cc0pdb39775658c78b21@mail.gmail.com>
	 <4fd37a7d-bed7-4303-8c5a-ef9f98e5f4f4@a32g2000yqm.googlegroups.com>
Message-ID: <7f014ea60911110108m2e97214cv7d40ac0590d68cfa@mail.gmail.com>

Holger,

DId you find that you needed the mutex even with the GIL?

Chris

On Tue, Nov 10, 2009 at 9:48 PM, SirVer <sirver at gmx.de> wrote:
>
> Chris,
>
> I forget to point you to a working example in my pydc code. Sorry for
> that:
>
> http://bazaar.launchpad.net/%7Esirver/pydc1394/trunk/annotate/head%3A/pydc1394/ui/qt/display.py
>
> That's pretty much all knowledge I have about real time acquistion &
> display with PyQt & PyOpenGL.
>
> Cheers,
> Holger
>
> On 10 Nov., 12:08, Chris Colbert <sccolb... at gmail.com> wrote:
>> Holger,
>>
>> #2 looks a lot like what I cooked up over here. (#1 always segaults
>> for me, but i could be doing it wrong.)
>> I tried the Qthread both with a while loop and a QTimer. I think i
>> like the timer better...
>>
>> At least I know i'm heading in the right direction.
>>
>> Cheers,
>>
>> Chris!
>>
>>
>>
>> On Tue, Nov 10, 2009 at 10:49 AM, SirVer <sir... at gmx.de> wrote:
>>
>> > Hi Chris,
>>
>> >> Are you able to feed your display widget with images from within a
>> >> python loop in the interactive shell?
>>
>> >> ie:
>>
>> >> while True:
>> >> ? ? img = grab_new_image()
>> >> ? ? display.new_image(img)
>> >> The issue I am having with this PyOS_InputHook, is that for me, that
>> >> type of loop never lets the interpreter idle (even with a sleep()
>> >> call) and thus the PyOS_InputHook never gets called, and the gui never
>> >> updates.
>> > This can't work as you said. PyOS_InputHook is never called. I doesn't
>> > work in ipython -q4thread either
>> > because the thread switch doesn't seem to occure. There are two ways
>> > to do it
>> > 1) either call PyOS_InputHook yourself.
>> > 2) acquire your images in another thread.
>>
>> > I always use 2) since my image acquisition always takes place
>> > continously in the background. This is also a way were
>> > PyQT really shines (It also works with wxWidgets that way, but it
>> > hurts a bit).
>>
>> > so your above example would look a bit like that (not tested, just
>> > written down like that):
>>
>> > class WorkerThread(QThread):
>> > ? def __init__(self, display):
>> > ? ? ?self.connect(self, SIGNAL("newImage"), self.display.newImage)
>> > ? ? ?# Keep a copy of display around so that the C object doesn't get
>> > deleted
>> > ? ? ?self.display = display
>>
>> > ? def run(self):
>> > ? ? ?while True:
>> > ? ? ? ? img = grab_new_image()
>> > ? ? ? ? self.emit(SIGNAL("newImage"), img)
>>
>> > def acquire_images(display):
>> > ? t = WorkerThread(display)
>> > ? t.start()
>>
>> > This example should work from the interactive shell provided you
>> > created a QApplication object so that Qt4 has the PyOS_InputHook
>> > acquired. Just call acquire_images(display).
>>
>> > Cheers,
>> > Holger
>>
>> >> Cheers,
>>
>> >> Chris
>>
>> >> On Fri, Nov 6, 2009 at 11:24 AM, SirVer <sir... at gmx.de> wrote:
>>
>> >> > Hi Chris,
>>
>> >> > thanks for the links! It made for some interesting reading; i wasn't
>> >> > aware of the System Hook. But I just investigated and my Widget works
>> >> > just fine in a pure python session as long as a QApplication object
>> >> > has been created before. So there is no problem here, it will work
>> >> > fine now in ipython -qt4thread and will continue to work in future
>> >> > ipython and also in vanilla python as long as QApplication(sys.argv)
>> >> > has been called before the window is created (which is mandatory for
>> >> > all QT4 Applications). So no problem here.
>>
>> >> > I now try to come to a conclusion to this thread. I didn't mean to
>> >> > start a lengthy discussion of how things should be done differently, I
>> >> > only want to have direction how to implement this. I try to summarize
>> >> > my thoughts:
>>
>> >> > * I am often in need to display images from a camera and annotate them
>> >> > with some output from algorithms (for example mark detected balls in
>> >> > my ping pong roboters images in red). For this I've written the code
>> >> > that can be found in my gui branch.
>> >> > * I feel that this use case is quite different from the idea of the
>> >> > imshow() plugin. I also feel that more people than me could profit
>> >> > from this functionality as I use it ATM.
>> >> > * I feel that this is hard to pull off with a plugin like
>> >> > architecture, because the annotation part will be different for all
>> >> > backends and all individual uses. En plus, this is more a Library kind
>> >> > of functionality, not a enduser kind like imshow().
>> >> > * My solution works for me and uses PyQt and PyOpenGL. My experiments
>> >> > showed me that this is the only combination that offers the drawing
>> >> > speed I want. I understand that other approaches could be possible or
>> >> > feasible, but I also think that for use cases like mine, this is a
>> >> > very common approach; especially since annotating in OpenGL is so easy
>> >> > to do with PyQt4.
>> >> > * Please let me state again that I do not plan to corrupt or change
>> >> > the imshow() plugin architecture which I really like. I am just of the
>> >> > opinion that something else is needed for my use case.
>>
>> >> > Now, please note that these are my opinions and thought and not really
>> >> > subject to discussion. What I now really need is a design decision by
>> >> > the architect of scikit.image; which I assume to be you, stefan:
>>
>> >> > How should I contribute this code? In which module should it go or is
>> >> > this not a direction that scikit.image should evolve in (I'd
>> >> > understand that and instead bring this code into my pydc1394 library
>> >> > were it would also fit).
>>
>> >> > Cheers,
>> >> > Holger
>>
>> >> > On 5 Nov., 17:33, Chris Colbert <sccolb... at gmail.com> wrote:
>> >> >> Here's a couple links on it Holger.
>>
>> >> >> Hopefully the scipy links work for you (its the Ipython part of the
>> >> >> discussion). I cant get to them right now.
>>
>> >> >>http://mail.scipy.org/pipermail/ipython-dev/2009-July/005256.htmlhttp...
>>
>> >> >> On Thu, Nov 5, 2009 at 5:14 PM, SirVer <sir... at gmx.de> wrote:
>>
>> >> >> >> However, i'm afraid that your current gui may rely on ipython
>> >> >> >> -q4thread, which is now deprecated (big mailing list discussion on
>> >> >> >> this). So that may throw a wrench in the video portion of it, unless
>> >> >> >> we can figure out this pyos_input hook thing.
>> >> >> > It infact does. Chris, could you please point me at this discussion?
>> >> >> > It is most relevant for my work.
>>
>> >> >> > Cheers,
>> >> >> > Holger
>>
>> >> >> >> But as my previous example shows, its definately possible to fit it
>> >> >> >> within the plugin framework.
>>
>> >> >> >> Cheers!
>>
>> >> >> >> Chris
>>
>> >> >> >> On Thu, Nov 5, 2009 at 4:56 PM, Chris Colbert <sccolb... at gmail.com> wrote:
>> >> >> >> > So while i havent yet been able to get the pyos_inputhook thing sorted
>> >> >> >> > out, I did time a couple loops.
>>
>> >> >> >> > For a decent sized image, we can easily get 60fps update rates, and
>> >> >> >> > thats including the time for the numpy operations:
>>
>> >> >> >> > In [5]: img = io.imread('/home/brucewayne/Pictures/failboat_4.jpg')
>>
>> >> >> >> > In [6]: img.shape
>> >> >> >> > Out[6]: (503, 790, 3)
>>
>> >> >> >> > In [7]: win = io.imshow(img, updateable=True)
>>
>> >> >> >> > In [8]: def test(img, win):
>> >> >> >> > ? ...: ? ? for i in range(30):
>> >> >> >> > ? ...: ? ? ? ? img[:] += 1
>> >> >> >> > ? ...: ? ? ? ? win.update()
>> >> >> >> > ? ...:
>> >> >> >> > ? ...:
>>
>> >> >> >> > In [9]: %timeit test(img, win)
>> >> >> >> > 1 loops, best of 3: 564 ms per loop
>>
>> >> >> >> > one thing to note, I bypassed the prepare_for_display() method that we
>> >> >> >> > usually call to make sure an array is contiguous, of the right dtype,
>> >> >> >> > etc...
>> >> >> >> > I assume if someone wants video, they can prepare the arrays themselves.
>>
>> >> >> >> > This behavior can also be changed by the plugin writer. For this
>> >> >> >> > example, i simply took the easy route and subclassed ImageWindow
>>
>> >> >> >> > Cheers,
>>
>> >> >> >> > Chris
>>
>> >> >> >> > On Thu, Nov 5, 2009 at 4:24 PM, Chris Colbert <sccolb... at gmail.com> wrote:
>> >> >> >> >> I was just testing out something along these lines, but I run into the
>> >> >> >> >> problem of the the python interpreter not considering time.sleep() as
>> >> >> >> >> idle time, thus, it never calls PyOS_InputHook inside of for-loops. So
>> >> >> >> >> i'm not quite sure how to get video ?feed to run interactively without
>> >> >> >> >> hacking out something like ipython -whatever thread.
>>
>> >> >> >> >> Mind you, this is not a problem with the plugin architecture, its a
>> >> >> >> >> problem with the python interpreter...
>>
>> >> >> >> >> but maybe i can ctypes into the os_hook and call it at the end of a
>> >> >> >> >> loop.... <evil grin>
>>
>> >> >> >> >> 2009/11/5 St?fan van der Walt <ste... at sun.ac.za>:
>>
>> >> >> >> >>> 2009/11/5 Chris Colbert <sccolb... at gmail.com>:
>> >> >> >> >>>> Further, these imshow() type widgets are primarily meant to be used
>> >> >> >> >>>> from the interactive interpreter, an environment not best suited for
>> >> >> >> >>>> real time image acquisition and display. that said, the plugin
>> >> >> >> >>>> archiceture can most certainly be used in the method you speak of. You
>> >> >> >> >>>> just simply have your imshow() function return the window object, and
>> >> >> >> >>>> implement an update() or similar method that the consumer can call to
>> >> >> >> >>>> update the image.
>>
>> >> >> >> >>> This could even be accomplished using 'imshow' only. ?The
>> >> >> >> >>> WindowManager keeps track of the single window produced, and 'imshow'
>> >> >> >> >>> simply grabs that window and updates its current content. ?I'd be
>> >> >> >> >>> surprised if we couldn't pump out a large number of frames-per-second
>> >> >> >> >>> that way.
>>
>> >> >> >> >>> St?fan


From sccolbert at gmail.com  Wed Nov 11 04:41:19 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Wed, 11 Nov 2009 10:41:19 +0100
Subject: Pending release of 0.3
In-Reply-To: <956a9252-b63e-49bf-8526-9990d2e4cae5@d5g2000yqm.googlegroups.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com>
	 <c33af287-8157-42d8-b836-53ec510fa8f8@w19g2000yqk.googlegroups.com>
	 <7f014ea60911050833k59616558xd28adfa4951d4700@mail.gmail.com>
	 <0abf5c7e-42c0-439b-8114-bbb3fc170427@a31g2000yqn.googlegroups.com>
	 <7f014ea60911090227t1f04a84btb60ae267f7cf3ef4@mail.gmail.com>
	 <92a1a49d-db47-48a7-bfb6-69ecc650ce34@h34g2000yqm.googlegroups.com>
	 <7f014ea60911100308hb2d2cc0pdb39775658c78b21@mail.gmail.com>
	 <4fd37a7d-bed7-4303-8c5a-ef9f98e5f4f4@a32g2000yqm.googlegroups.com>
	 <7f014ea60911110108m2e97214cv7d40ac0590d68cfa@mail.gmail.com>
	 <956a9252-b63e-49bf-8526-9990d2e4cae5@d5g2000yqm.googlegroups.com>
Message-ID: <7f014ea60911110141k1468f703t604d8b924d97d0de@mail.gmail.com>

right, but the gil ensures that only one piece of python code is
executing at a time.

Perhaps I missed it, did have a qt call that right to a python variable?

On Wed, Nov 11, 2009 at 10:39 AM, SirVer <sirver at gmx.de> wrote:
>
> Hi Chris,
>
>> DId you find that you needed the mutex even with the GIL?
> Yes I did. The GIL doesn't prevent deadlocks in all cases since we
> have no guarantee
> when python does a context switch. Shared variables (that can be
> written in both threads) still
> need protection by something. I am pretty sure it is needed at this
> point.
>
> Cheers
> Holger
>
>>
>> Chris
>>
>>
>>
>> On Tue, Nov 10, 2009 at 9:48 PM, SirVer <sir... at gmx.de> wrote:
>>
>> > Chris,
>>
>> > I forget to point you to a working example in my pydc code. Sorry for
>> > that:
>>
>> >http://bazaar.launchpad.net/%7Esirver/pydc1394/trunk/annotate/head%3A...
>>
>> > That's pretty much all knowledge I have about real time acquistion &
>> > display with PyQt & PyOpenGL.
>>
>> > Cheers,
>> > Holger
>>
>> > On 10 Nov., 12:08, Chris Colbert <sccolb... at gmail.com> wrote:
>> >> Holger,
>>
>> >> #2 looks a lot like what I cooked up over here. (#1 always segaults
>> >> for me, but i could be doing it wrong.)
>> >> I tried the Qthread both with a while loop and a QTimer. I think i
>> >> like the timer better...
>>
>> >> At least I know i'm heading in the right direction.
>>
>> >> Cheers,
>>
>> >> Chris!
>>
>> >> On Tue, Nov 10, 2009 at 10:49 AM, SirVer <sir... at gmx.de> wrote:
>>
>> >> > Hi Chris,
>>
>> >> >> Are you able to feed your display widget with images from within a
>> >> >> python loop in the interactive shell?
>>
>> >> >> ie:
>>
>> >> >> while True:
>> >> >> ? ? img = grab_new_image()
>> >> >> ? ? display.new_image(img)
>> >> >> The issue I am having with this PyOS_InputHook, is that for me, that
>> >> >> type of loop never lets the interpreter idle (even with a sleep()
>> >> >> call) and thus the PyOS_InputHook never gets called, and the gui never
>> >> >> updates.
>> >> > This can't work as you said. PyOS_InputHook is never called. I doesn't
>> >> > work in ipython -q4thread either
>> >> > because the thread switch doesn't seem to occure. There are two ways
>> >> > to do it
>> >> > 1) either call PyOS_InputHook yourself.
>> >> > 2) acquire your images in another thread.
>>
>> >> > I always use 2) since my image acquisition always takes place
>> >> > continously in the background. This is also a way were
>> >> > PyQT really shines (It also works with wxWidgets that way, but it
>> >> > hurts a bit).
>>
>> >> > so your above example would look a bit like that (not tested, just
>> >> > written down like that):
>>
>> >> > class WorkerThread(QThread):
>> >> > ? def __init__(self, display):
>> >> > ? ? ?self.connect(self, SIGNAL("newImage"), self.display.newImage)
>> >> > ? ? ?# Keep a copy of display around so that the C object doesn't get
>> >> > deleted
>> >> > ? ? ?self.display = display
>>
>> >> > ? def run(self):
>> >> > ? ? ?while True:
>> >> > ? ? ? ? img = grab_new_image()
>> >> > ? ? ? ? self.emit(SIGNAL("newImage"), img)
>>
>> >> > def acquire_images(display):
>> >> > ? t = WorkerThread(display)
>> >> > ? t.start()
>>
>> >> > This example should work from the interactive shell provided you
>> >> > created a QApplication object so that Qt4 has the PyOS_InputHook
>> >> > acquired. Just call acquire_images(display).
>>
>> >> > Cheers,
>> >> > Holger
>>
>> >> >> Cheers,
>>
>> >> >> Chris
>>
>> >> >> On Fri, Nov 6, 2009 at 11:24 AM, SirVer <sir... at gmx.de> wrote:
>>
>> >> >> > Hi Chris,
>>
>> >> >> > thanks for the links! It made for some interesting reading; i wasn't
>> >> >> > aware of the System Hook. But I just investigated and my Widget works
>> >> >> > just fine in a pure python session as long as a QApplication object
>> >> >> > has been created before. So there is no problem here, it will work
>> >> >> > fine now in ipython -qt4thread and will continue to work in future
>> >> >> > ipython and also in vanilla python as long as QApplication(sys.argv)
>> >> >> > has been called before the window is created (which is mandatory for
>> >> >> > all QT4 Applications). So no problem here.
>>
>> >> >> > I now try to come to a conclusion to this thread. I didn't mean to
>> >> >> > start a lengthy discussion of how things should be done differently, I
>> >> >> > only want to have direction how to implement this. I try to summarize
>> >> >> > my thoughts:
>>
>> >> >> > * I am often in need to display images from a camera and annotate them
>> >> >> > with some output from algorithms (for example mark detected balls in
>> >> >> > my ping pong roboters images in red). For this I've written the code
>> >> >> > that can be found in my gui branch.
>> >> >> > * I feel that this use case is quite different from the idea of the
>> >> >> > imshow() plugin. I also feel that more people than me could profit
>> >> >> > from this functionality as I use it ATM.
>> >> >> > * I feel that this is hard to pull off with a plugin like
>> >> >> > architecture, because the annotation part will be different for all
>> >> >> > backends and all individual uses. En plus, this is more a Library kind
>> >> >> > of functionality, not a enduser kind like imshow().
>> >> >> > * My solution works for me and uses PyQt and PyOpenGL. My experiments
>> >> >> > showed me that this is the only combination that offers the drawing
>> >> >> > speed I want. I understand that other approaches could be possible or
>> >> >> > feasible, but I also think that for use cases like mine, this is a
>> >> >> > very common approach; especially since annotating in OpenGL is so easy
>> >> >> > to do with PyQt4.
>> >> >> > * Please let me state again that I do not plan to corrupt or change
>> >> >> > the imshow() plugin architecture which I really like. I am just of the
>> >> >> > opinion that something else is needed for my use case.
>>
>> >> >> > Now, please note that these are my opinions and thought and not really
>> >> >> > subject to discussion. What I now really need is a design decision by
>> >> >> > the architect of scikit.image; which I assume to be you, stefan:
>>
>> >> >> > How should I contribute this code? In which module should it go or is
>> >> >> > this not a direction that scikit.image should evolve in (I'd
>> >> >> > understand that and instead bring this code into my pydc1394 library
>> >> >> > were it would also fit).
>>
>> >> >> > Cheers,
>> >> >> > Holger
>>
>> >> >> > On 5 Nov., 17:33, Chris Colbert <sccolb... at gmail.com> wrote:
>> >> >> >> Here's a couple links on it Holger.
>>
>> >> >> >> Hopefully the scipy links work for you (its the Ipython part of the
>> >> >> >> discussion). I cant get to them right now.
>>
>> >> >> >>http://mail.scipy.org/pipermail/ipython-dev/2009-July/005256.htmlhttp...
>>
>> >> >> >> On Thu, Nov 5, 2009 at 5:14 PM, SirVer <sir... at gmx.de> wrote:
>>
>> >> >> >> >> However, i'm afraid that your current gui may rely on ipython
>> >> >> >> >> -q4thread, which is now deprecated (big mailing list discussion on
>> >> >> >> >> this). So that may throw a wrench in the video portion of it, unless
>> >> >> >> >> we can figure out this pyos_input hook thing.
>> >> >> >> > It infact does. Chris, could you please point me at this discussion?
>> >> >> >> > It is most relevant for my work.
>>
>> >> >> >> > Cheers,
>> >> >> >> > Holger
>>
>> >> >> >> >> But as my previous example shows, its definately possible to fit it
>> >> >> >> >> within the plugin framework.
>>
>> >> >> >> >> Cheers!
>>
>> >> >> >> >> Chris
>>
>> >> >> >> >> On Thu, Nov 5, 2009 at 4:56 PM, Chris Colbert <sccolb... at gmail.com> wrote:
>> >> >> >> >> > So while i havent yet been able to get the pyos_inputhook thing sorted
>> >> >> >> >> > out, I did time a couple loops.
>>
>> >> >> >> >> > For a decent sized image, we can easily get 60fps update rates, and
>> >> >> >> >> > thats including the time for the numpy operations:
>>
>> >> >> >> >> > In [5]: img = io.imread('/home/brucewayne/Pictures/failboat_4.jpg')
>>
>> >> >> >> >> > In [6]: img.shape
>> >> >> >> >> > Out[6]: (503, 790, 3)
>>
>> >> >> >> >> > In [7]: win = io.imshow(img, updateable=True)
>>
>> >> >> >> >> > In [8]: def test(img, win):
>> >> >> >> >> > ? ...: ? ? for i in range(30):
>> >> >> >> >> > ? ...: ? ? ? ? img[:] += 1
>> >> >> >> >> > ? ...: ? ? ? ? win.update()
>> >> >> >> >> > ? ...:
>> >> >> >> >> > ? ...:
>>
>> >> >> >> >> > In [9]: %timeit test(img, win)
>> >> >> >> >> > 1 loops, best of 3: 564 ms per loop
>>
>> >> >> >> >> > one thing to note, I bypassed the prepare_for_display() method that we
>> >> >> >> >> > usually call to make sure an array is contiguous, of the right dtype,
>> >> >> >> >> > etc...
>> >> >> >> >> > I assume if someone wants video, they can prepare the arrays themselves.
>>
>> >> >> >> >> > This behavior can also be changed by the plugin writer. For this
>> >> >> >> >> > example, i simply took the easy route and subclassed ImageWindow
>>
>> >> >> >> >> > Cheers,
>>
>> >> >> >> >> > Chris
>>
>> >> >> >> >> > On Thu, Nov 5, 2009 at 4:24 PM, Chris Colbert <sccolb... at gmail.com> wrote:
>> >> >> >> >> >> I was just testing out something along these lines, but I run into the
>> >> >> >> >> >> problem of the the python interpreter not considering time.sleep() as
>> >> >> >> >> >> idle time, thus, it never calls PyOS_InputHook inside of for-loops. So
>> >> >> >> >> >> i'm not quite sure how to get video ?feed to run interactively without
>> >> >> >> >> >> hacking out something like ipython -whatever thread.
>>
>> >> >> >> >> >> Mind you, this is not a problem with the plugin architecture, its a
>> >> >> >> >> >> problem with the python interpreter...
>>
>> >> >> >> >> >> but maybe i can ctypes into the os_hook and call it at the end of a
>> >> >> >> >> >> loop.... <evil grin>
>>
>> >> >> >> >> >> 2009/11/5 St?fan van der Walt <ste... at sun.ac.za>:
>>
>> >> >> >> >> >>> 2009/11/5 Chris Colbert <sccolb... at gmail.com>:
>> >> >> >> >> >>>> Further, these imshow() type widgets are primarily meant to be used
>> >> >> >> >> >>>> from the interactive interpreter, an environment not best suited for
>> >> >> >> >> >>>> real time image acquisition and display. that said, the plugin
>> >> >> >> >> >>>> archiceture can most certainly be used in the method you speak of. You
>> >> >> >> >> >>>> just simply have your imshow() function return the window object, and
>> >> >> >> >> >>>> implement an update() or similar method that the consumer can call to
>> >> >> >> >> >>>> update the image.
>>
>> >> >> >> >> >>> This could even be accomplished using 'imshow' only. ?The
>> >> >> >> >> >>> WindowManager keeps track of the single window produced, and 'imshow'
>> >> >> >> >> >>> simply grabs that window and updates its current content. ?I'd be
>> >> >> >> >> >>> surprised if we couldn't pump out a large number of frames-per-second
>> >> >> >> >> >>> that way.
>>
>> >> >> >> >> >>> St?fan


From sccolbert at gmail.com  Wed Nov 11 04:44:52 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Wed, 11 Nov 2009 10:44:52 +0100
Subject: Pending release of 0.3
In-Reply-To: <7f014ea60911110141k1468f703t604d8b924d97d0de@mail.gmail.com>
References: <9457e7c80911031340p3275cd5ewfbdba8525c7084f7@mail.gmail.com>
	 <7f014ea60911050833k59616558xd28adfa4951d4700@mail.gmail.com>
	 <0abf5c7e-42c0-439b-8114-bbb3fc170427@a31g2000yqn.googlegroups.com>
	 <7f014ea60911090227t1f04a84btb60ae267f7cf3ef4@mail.gmail.com>
	 <92a1a49d-db47-48a7-bfb6-69ecc650ce34@h34g2000yqm.googlegroups.com>
	 <7f014ea60911100308hb2d2cc0pdb39775658c78b21@mail.gmail.com>
	 <4fd37a7d-bed7-4303-8c5a-ef9f98e5f4f4@a32g2000yqm.googlegroups.com>
	 <7f014ea60911110108m2e97214cv7d40ac0590d68cfa@mail.gmail.com>
	 <956a9252-b63e-49bf-8526-9990d2e4cae5@d5g2000yqm.googlegroups.com>
	 <7f014ea60911110141k1468f703t604d8b924d97d0de@mail.gmail.com>
Message-ID: <7f014ea60911110144s7458e217s610f73fea82ed6e@mail.gmail.com>

crap, that last sentence was all sorts of broken...

I meant, do you have a QT call that is writing to a python variable?

On Wed, Nov 11, 2009 at 10:41 AM, Chris Colbert <sccolbert at gmail.com> wrote:
> right, but the gil ensures that only one piece of python code is
> executing at a time.
>
> Perhaps I missed it, did have a qt call that right to a python variable?
>
> On Wed, Nov 11, 2009 at 10:39 AM, SirVer <sirver at gmx.de> wrote:
>>
>> Hi Chris,
>>
>>> DId you find that you needed the mutex even with the GIL?
>> Yes I did. The GIL doesn't prevent deadlocks in all cases since we
>> have no guarantee
>> when python does a context switch. Shared variables (that can be
>> written in both threads) still
>> need protection by something. I am pretty sure it is needed at this
>> point.
>>
>> Cheers
>> Holger
>>
>>>
>>> Chris
>>>
>>>
>>>
>>> On Tue, Nov 10, 2009 at 9:48 PM, SirVer <sir... at gmx.de> wrote:
>>>
>>> > Chris,
>>>
>>> > I forget to point you to a working example in my pydc code. Sorry for
>>> > that:
>>>
>>> >http://bazaar.launchpad.net/%7Esirver/pydc1394/trunk/annotate/head%3A...
>>>
>>> > That's pretty much all knowledge I have about real time acquistion &
>>> > display with PyQt & PyOpenGL.
>>>
>>> > Cheers,
>>> > Holger
>>>
>>> > On 10 Nov., 12:08, Chris Colbert <sccolb... at gmail.com> wrote:
>>> >> Holger,
>>>
>>> >> #2 looks a lot like what I cooked up over here. (#1 always segaults
>>> >> for me, but i could be doing it wrong.)
>>> >> I tried the Qthread both with a while loop and a QTimer. I think i
>>> >> like the timer better...
>>>
>>> >> At least I know i'm heading in the right direction.
>>>
>>> >> Cheers,
>>>
>>> >> Chris!
>>>
>>> >> On Tue, Nov 10, 2009 at 10:49 AM, SirVer <sir... at gmx.de> wrote:
>>>
>>> >> > Hi Chris,
>>>
>>> >> >> Are you able to feed your display widget with images from within a
>>> >> >> python loop in the interactive shell?
>>>
>>> >> >> ie:
>>>
>>> >> >> while True:
>>> >> >> ? ? img = grab_new_image()
>>> >> >> ? ? display.new_image(img)
>>> >> >> The issue I am having with this PyOS_InputHook, is that for me, that
>>> >> >> type of loop never lets the interpreter idle (even with a sleep()
>>> >> >> call) and thus the PyOS_InputHook never gets called, and the gui never
>>> >> >> updates.
>>> >> > This can't work as you said. PyOS_InputHook is never called. I doesn't
>>> >> > work in ipython -q4thread either
>>> >> > because the thread switch doesn't seem to occure. There are two ways
>>> >> > to do it
>>> >> > 1) either call PyOS_InputHook yourself.
>>> >> > 2) acquire your images in another thread.
>>>
>>> >> > I always use 2) since my image acquisition always takes place
>>> >> > continously in the background. This is also a way were
>>> >> > PyQT really shines (It also works with wxWidgets that way, but it
>>> >> > hurts a bit).
>>>
>>> >> > so your above example would look a bit like that (not tested, just
>>> >> > written down like that):
>>>
>>> >> > class WorkerThread(QThread):
>>> >> > ? def __init__(self, display):
>>> >> > ? ? ?self.connect(self, SIGNAL("newImage"), self.display.newImage)
>>> >> > ? ? ?# Keep a copy of display around so that the C object doesn't get
>>> >> > deleted
>>> >> > ? ? ?self.display = display
>>>
>>> >> > ? def run(self):
>>> >> > ? ? ?while True:
>>> >> > ? ? ? ? img = grab_new_image()
>>> >> > ? ? ? ? self.emit(SIGNAL("newImage"), img)
>>>
>>> >> > def acquire_images(display):
>>> >> > ? t = WorkerThread(display)
>>> >> > ? t.start()
>>>
>>> >> > This example should work from the interactive shell provided you
>>> >> > created a QApplication object so that Qt4 has the PyOS_InputHook
>>> >> > acquired. Just call acquire_images(display).
>>>
>>> >> > Cheers,
>>> >> > Holger
>>>
>>> >> >> Cheers,
>>>
>>> >> >> Chris
>>>
>>> >> >> On Fri, Nov 6, 2009 at 11:24 AM, SirVer <sir... at gmx.de> wrote:
>>>
>>> >> >> > Hi Chris,
>>>
>>> >> >> > thanks for the links! It made for some interesting reading; i wasn't
>>> >> >> > aware of the System Hook. But I just investigated and my Widget works
>>> >> >> > just fine in a pure python session as long as a QApplication object
>>> >> >> > has been created before. So there is no problem here, it will work
>>> >> >> > fine now in ipython -qt4thread and will continue to work in future
>>> >> >> > ipython and also in vanilla python as long as QApplication(sys.argv)
>>> >> >> > has been called before the window is created (which is mandatory for
>>> >> >> > all QT4 Applications). So no problem here.
>>>
>>> >> >> > I now try to come to a conclusion to this thread. I didn't mean to
>>> >> >> > start a lengthy discussion of how things should be done differently, I
>>> >> >> > only want to have direction how to implement this. I try to summarize
>>> >> >> > my thoughts:
>>>
>>> >> >> > * I am often in need to display images from a camera and annotate them
>>> >> >> > with some output from algorithms (for example mark detected balls in
>>> >> >> > my ping pong roboters images in red). For this I've written the code
>>> >> >> > that can be found in my gui branch.
>>> >> >> > * I feel that this use case is quite different from the idea of the
>>> >> >> > imshow() plugin. I also feel that more people than me could profit
>>> >> >> > from this functionality as I use it ATM.
>>> >> >> > * I feel that this is hard to pull off with a plugin like
>>> >> >> > architecture, because the annotation part will be different for all
>>> >> >> > backends and all individual uses. En plus, this is more a Library kind
>>> >> >> > of functionality, not a enduser kind like imshow().
>>> >> >> > * My solution works for me and uses PyQt and PyOpenGL. My experiments
>>> >> >> > showed me that this is the only combination that offers the drawing
>>> >> >> > speed I want. I understand that other approaches could be possible or
>>> >> >> > feasible, but I also think that for use cases like mine, this is a
>>> >> >> > very common approach; especially since annotating in OpenGL is so easy
>>> >> >> > to do with PyQt4.
>>> >> >> > * Please let me state again that I do not plan to corrupt or change
>>> >> >> > the imshow() plugin architecture which I really like. I am just of the
>>> >> >> > opinion that something else is needed for my use case.
>>>
>>> >> >> > Now, please note that these are my opinions and thought and not really
>>> >> >> > subject to discussion. What I now really need is a design decision by
>>> >> >> > the architect of scikit.image; which I assume to be you, stefan:
>>>
>>> >> >> > How should I contribute this code? In which module should it go or is
>>> >> >> > this not a direction that scikit.image should evolve in (I'd
>>> >> >> > understand that and instead bring this code into my pydc1394 library
>>> >> >> > were it would also fit).
>>>
>>> >> >> > Cheers,
>>> >> >> > Holger
>>>
>>> >> >> > On 5 Nov., 17:33, Chris Colbert <sccolb... at gmail.com> wrote:
>>> >> >> >> Here's a couple links on it Holger.
>>>
>>> >> >> >> Hopefully the scipy links work for you (its the Ipython part of the
>>> >> >> >> discussion). I cant get to them right now.
>>>
>>> >> >> >>http://mail.scipy.org/pipermail/ipython-dev/2009-July/005256.htmlhttp...
>>>
>>> >> >> >> On Thu, Nov 5, 2009 at 5:14 PM, SirVer <sir... at gmx.de> wrote:
>>>
>>> >> >> >> >> However, i'm afraid that your current gui may rely on ipython
>>> >> >> >> >> -q4thread, which is now deprecated (big mailing list discussion on
>>> >> >> >> >> this). So that may throw a wrench in the video portion of it, unless
>>> >> >> >> >> we can figure out this pyos_input hook thing.
>>> >> >> >> > It infact does. Chris, could you please point me at this discussion?
>>> >> >> >> > It is most relevant for my work.
>>>
>>> >> >> >> > Cheers,
>>> >> >> >> > Holger
>>>
>>> >> >> >> >> But as my previous example shows, its definately possible to fit it
>>> >> >> >> >> within the plugin framework.
>>>
>>> >> >> >> >> Cheers!
>>>
>>> >> >> >> >> Chris
>>>
>>> >> >> >> >> On Thu, Nov 5, 2009 at 4:56 PM, Chris Colbert <sccolb... at gmail.com> wrote:
>>> >> >> >> >> > So while i havent yet been able to get the pyos_inputhook thing sorted
>>> >> >> >> >> > out, I did time a couple loops.
>>>
>>> >> >> >> >> > For a decent sized image, we can easily get 60fps update rates, and
>>> >> >> >> >> > thats including the time for the numpy operations:
>>>
>>> >> >> >> >> > In [5]: img = io.imread('/home/brucewayne/Pictures/failboat_4.jpg')
>>>
>>> >> >> >> >> > In [6]: img.shape
>>> >> >> >> >> > Out[6]: (503, 790, 3)
>>>
>>> >> >> >> >> > In [7]: win = io.imshow(img, updateable=True)
>>>
>>> >> >> >> >> > In [8]: def test(img, win):
>>> >> >> >> >> > ? ...: ? ? for i in range(30):
>>> >> >> >> >> > ? ...: ? ? ? ? img[:] += 1
>>> >> >> >> >> > ? ...: ? ? ? ? win.update()
>>> >> >> >> >> > ? ...:
>>> >> >> >> >> > ? ...:
>>>
>>> >> >> >> >> > In [9]: %timeit test(img, win)
>>> >> >> >> >> > 1 loops, best of 3: 564 ms per loop
>>>
>>> >> >> >> >> > one thing to note, I bypassed the prepare_for_display() method that we
>>> >> >> >> >> > usually call to make sure an array is contiguous, of the right dtype,
>>> >> >> >> >> > etc...
>>> >> >> >> >> > I assume if someone wants video, they can prepare the arrays themselves.
>>>
>>> >> >> >> >> > This behavior can also be changed by the plugin writer. For this
>>> >> >> >> >> > example, i simply took the easy route and subclassed ImageWindow
>>>
>>> >> >> >> >> > Cheers,
>>>
>>> >> >> >> >> > Chris
>>>
>>> >> >> >> >> > On Thu, Nov 5, 2009 at 4:24 PM, Chris Colbert <sccolb... at gmail.com> wrote:
>>> >> >> >> >> >> I was just testing out something along these lines, but I run into the
>>> >> >> >> >> >> problem of the the python interpreter not considering time.sleep() as
>>> >> >> >> >> >> idle time, thus, it never calls PyOS_InputHook inside of for-loops. So
>>> >> >> >> >> >> i'm not quite sure how to get video ?feed to run interactively without
>>> >> >> >> >> >> hacking out something like ipython -whatever thread.
>>>
>>> >> >> >> >> >> Mind you, this is not a problem with the plugin architecture, its a
>>> >> >> >> >> >> problem with the python interpreter...
>>>
>>> >> >> >> >> >> but maybe i can ctypes into the os_hook and call it at the end of a
>>> >> >> >> >> >> loop.... <evil grin>
>>>
>>> >> >> >> >> >> 2009/11/5 St?fan van der Walt <ste... at sun.ac.za>:
>>>
>>> >> >> >> >> >>> 2009/11/5 Chris Colbert <sccolb... at gmail.com>:
>>> >> >> >> >> >>>> Further, these imshow() type widgets are primarily meant to be used
>>> >> >> >> >> >>>> from the interactive interpreter, an environment not best suited for
>>> >> >> >> >> >>>> real time image acquisition and display. that said, the plugin
>>> >> >> >> >> >>>> archiceture can most certainly be used in the method you speak of. You
>>> >> >> >> >> >>>> just simply have your imshow() function return the window object, and
>>> >> >> >> >> >>>> implement an update() or similar method that the consumer can call to
>>> >> >> >> >> >>>> update the image.
>>>
>>> >> >> >> >> >>> This could even be accomplished using 'imshow' only. ?The
>>> >> >> >> >> >>> WindowManager keeps track of the single window produced, and 'imshow'
>>> >> >> >> >> >>> simply grabs that window and updates its current content. ?I'd be
>>> >> >> >> >> >>> surprised if we couldn't pump out a large number of frames-per-second
>>> >> >> >> >> >>> that way.
>>>
>>> >> >> >> >> >>> St?fan
>


From sccolbert at gmail.com  Wed Nov 11 10:46:40 2009
From: sccolbert at gmail.com (Chris Colbert)
Date: Wed, 11 Nov 2009 16:46:40 +0100
Subject: some new updates
Message-ID: <7f014ea60911110746v5859823lebcc40345208e00c@mail.gmail.com>

Hey Everyone,

I've pushed some changes to my master branch on github which yields a
30x speed improvement for the colormixer on large images.

I did it by implementing a LUT for the conversion operations
(something I should have done from the beginning). Thanks to Guy Kloss
for giving me the idea!

If you have time, please check it out and give it a reaming.

I'm still looking for an efficient way to make a LUT for HSV
manipulations, any ideas are welcome!

Cheers!

Chris


From tsyu80 at gmail.com  Thu Nov 12 14:55:15 2009
From: tsyu80 at gmail.com (Tony S Yu)
Date: Thu, 12 Nov 2009 14:55:15 -0500
Subject: ANN: scikits.image v0.2
In-Reply-To: <9457e7c80911120603h6863532cy99499a352c2f6fca@mail.gmail.com>
References: <9457e7c80911120603h6863532cy99499a352c2f6fca@mail.gmail.com>
Message-ID: <BD305489-E206-4A62-AC94-0A5327D4A911@gmail.com>

I believe the most recent release still requires python 2.6.

I've uploaded a fix to remove the dependency on enhanced decorators.  
There are two branches on github (http://github.com/tonysyu/scikits.image 
): one named "compatibility2.5" and and the other "compatibility2.5x".  
The first uses conventional setter and getter methods, while the  
second uses a workaround to hide the setter and getter from the class  
namespace.

Also, I noticed that the doctests in the io package are not really  
maintained. I fixed some file loading issues in my "io_doctest"  
branch. One test still fails because I'm not sure how to rewrite it  
without making it really ugly (the test prints out the filepaths in a  
collection, but you want to test the filename). Also, a doctest for  
io.show fails because there's no default plugin showing images.

Cheers,
-Tony

On Nov 12, 2009, at 9:03 AM, St?fan van der Walt wrote:

>
> I'm glad to announce the second release of `scikits.image`, a
> collection of image processing routines for SciPy.
>
> On top of bug-fixes and improved documentation, the following
> changes/additions were made:
>
> - A new IO plugin infrastructure so that commands like 'imshow' are
> available via multiple backends (PIL, matplotlib, QT4, etc.)
> - ImageCollections (for cached loading of multiple images) and
> MultiImage (for working with multi-layered images)
> - More complete OpenCV wrappers
> - A graphical image viewer (also installed as a script `scivi`), that
> allows colour adjustments
> - Shortest path algorithm
>
> For version 0.3, we aim to
>
> - Incorporate some of the code offered by the Broad institute
> - Implement acquisition (grabbing images from cameras) and intrinsic
> camera calibration
> - Add real time video and camera display with processing
> - Improve filtering code
> - Add morphological operations
>
> More information is available at: http://stefanv.github.com/scikits.image/
>
> Regards
> St?fan



From tsyu80 at gmail.com  Thu Nov 12 16:02:52 2009
From: tsyu80 at gmail.com (Tony S Yu)
Date: Thu, 12 Nov 2009 16:02:52 -0500
Subject: ANN: scikits.image v0.2
In-Reply-To: <9457e7c80911121237x333921eft6f6e8194c0eb40b5@mail.gmail.com>
References: <9457e7c80911120603h6863532cy99499a352c2f6fca@mail.gmail.com>  <BD305489-E206-4A62-AC94-0A5327D4A911@gmail.com> <9457e7c80911121237x333921eft6f6e8194c0eb40b5@mail.gmail.com>
Message-ID: <49D1C7C8-A27B-4B0A-810A-393AAAC4EDC0@gmail.com>


On Nov 12, 2009, at 3:37 PM, St?fan van der Walt wrote:

>
> Hi Tony
>
> 2009/11/12 Tony S Yu <tsyu80 at gmail.com>:
>> I've uploaded a fix to remove the dependency on enhanced decorators.
>
> I just tested @property decorators under 2.5 and they seem to work --
> could you describe the problem you are having?

Hey Stefan,

In io.collections, the setter for as_grey is defined with  
`@as_grey.setter`. 2.5 allows @property, but not @property.setter.

>
> I did fix a "with ..." that slipped in.
>
>> Also, I noticed that the doctests in the io package are not really
>> maintained. I fixed some file loading issues in my "io_doctest"
>> branch. One test still fails because I'm not sure how to rewrite it
>> without making it really ugly (the test prints out the filepaths in a
>> collection, but you want to test the filename). Also, a doctest for
>> io.show fails because there's no default plugin showing images.
>
> Thanks for pointing out these problems.  They should be fixed in the
> master branch.

Thanks for you quick response. I see that you made changes to the  
"show" doctest. Nevertheless, the test still fails on my system  
because there's no plugin specified for imshow when I run the test.  
(If I specify, io.use_plugin and import numpy as np, it sort of works;  
no really b/c it registers a failure since imshow returns objects that  
the doctest checks). I'm not sure if it makes sense to write that  
example as a doctest (because of these complications).

Cheers
-Tony
>
> Cheers
> St?fan



From stefan at sun.ac.za  Thu Nov 12 09:03:34 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 12 Nov 2009 16:03:34 +0200
Subject: ANN: scikits.image v0.2
Message-ID: <9457e7c80911120603h6863532cy99499a352c2f6fca@mail.gmail.com>

I'm glad to announce the second release of `scikits.image`, a
collection of image processing routines for SciPy.

On top of bug-fixes and improved documentation, the following
changes/additions were made:

- A new IO plugin infrastructure so that commands like 'imshow' are
available via multiple backends (PIL, matplotlib, QT4, etc.)
- ImageCollections (for cached loading of multiple images) and
MultiImage (for working with multi-layered images)
- More complete OpenCV wrappers
- A graphical image viewer (also installed as a script `scivi`), that
allows colour adjustments
- Shortest path algorithm

For version 0.3, we aim to

- Incorporate some of the code offered by the Broad institute
- Implement acquisition (grabbing images from cameras) and intrinsic
camera calibration
- Add real time video and camera display with processing
- Improve filtering code
- Add morphological operations

More information is available at: http://stefanv.github.com/scikits.image/

Regards
St?fan


From tsyu80 at gmail.com  Thu Nov 12 16:33:00 2009
From: tsyu80 at gmail.com (Tony S Yu)
Date: Thu, 12 Nov 2009 16:33:00 -0500
Subject: ANN: scikits.image v0.2
In-Reply-To: <9457e7c80911121324v49ad215fx2fc127dcb639740@mail.gmail.com>
References: <9457e7c80911120603h6863532cy99499a352c2f6fca@mail.gmail.com>  <BD305489-E206-4A62-AC94-0A5327D4A911@gmail.com> <9457e7c80911121237x333921eft6f6e8194c0eb40b5@mail.gmail.com>  <49D1C7C8-A27B-4B0A-810A-393AAAC4EDC0@gmail.com> <9457e7c80911121324v49ad215fx2fc127dcb639740@mail.gmail.com>
Message-ID: <487EA22F-BAFF-4E1D-AFD5-A009ED26C40D@gmail.com>


On Nov 12, 2009, at 4:24 PM, St?fan van der Walt wrote:

>
> 2009/11/12 Tony S Yu <tsyu80 at gmail.com>:
>> Thanks for you quick response. I see that you made changes to the
>> "show" doctest. Nevertheless, the test still fails on my system
>> because there's no plugin specified for imshow when I run the test.
>> (If I specify, io.use_plugin and import numpy as np, it sort of  
>> works;
>> no really b/c it registers a failure since imshow returns objects  
>> that
>> the doctest checks). I'm not sure if it makes sense to write that
>> example as a doctest (because of these complications).
>
> Did you reinstall the scikit?

Good point! I was just looking at the commits and copied and pasted  
the stuff you added in the "fix doctests" commit. The null plugin  
works as you describe after pull the your latest revisions.

Thanks,
-Tony

> I added a "null" plugin that should be
> used by default. You should see something like:
>
> In [7]: io.plugins(loaded=True)
> Out[7]: {'null': ['imshow'], 'pil': ['imread', 'imsave']}
>
> Cheers
> St?fan



From stefan at sun.ac.za  Thu Nov 12 15:37:00 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 12 Nov 2009 22:37:00 +0200
Subject: ANN: scikits.image v0.2
In-Reply-To: <BD305489-E206-4A62-AC94-0A5327D4A911@gmail.com>
References: <9457e7c80911120603h6863532cy99499a352c2f6fca@mail.gmail.com> 
	<BD305489-E206-4A62-AC94-0A5327D4A911@gmail.com>
Message-ID: <9457e7c80911121237x333921eft6f6e8194c0eb40b5@mail.gmail.com>

Hi Tony

2009/11/12 Tony S Yu <tsyu80 at gmail.com>:
> I've uploaded a fix to remove the dependency on enhanced decorators.

I just tested @property decorators under 2.5 and they seem to work --
could you describe the problem you are having?

I did fix a "with ..." that slipped in.

> Also, I noticed that the doctests in the io package are not really
> maintained. I fixed some file loading issues in my "io_doctest"
> branch. One test still fails because I'm not sure how to rewrite it
> without making it really ugly (the test prints out the filepaths in a
> collection, but you want to test the filename). Also, a doctest for
> io.show fails because there's no default plugin showing images.

Thanks for pointing out these problems.  They should be fixed in the
master branch.

Cheers
St?fan


From stefan at sun.ac.za  Thu Nov 12 16:24:51 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 12 Nov 2009 23:24:51 +0200
Subject: ANN: scikits.image v0.2
In-Reply-To: <49D1C7C8-A27B-4B0A-810A-393AAAC4EDC0@gmail.com>
References: <9457e7c80911120603h6863532cy99499a352c2f6fca@mail.gmail.com> 
	<BD305489-E206-4A62-AC94-0A5327D4A911@gmail.com> <9457e7c80911121237x333921eft6f6e8194c0eb40b5@mail.gmail.com> 
	<49D1C7C8-A27B-4B0A-810A-393AAAC4EDC0@gmail.com>
Message-ID: <9457e7c80911121324v49ad215fx2fc127dcb639740@mail.gmail.com>

2009/11/12 Tony S Yu <tsyu80 at gmail.com>:
> Thanks for you quick response. I see that you made changes to the
> "show" doctest. Nevertheless, the test still fails on my system
> because there's no plugin specified for imshow when I run the test.
> (If I specify, io.use_plugin and import numpy as np, it sort of works;
> no really b/c it registers a failure since imshow returns objects that
> the doctest checks). I'm not sure if it makes sense to write that
> example as a doctest (because of these complications).

Did you reinstall the scikit?  I added a "null" plugin that should be
used by default. You should see something like:

In [7]: io.plugins(loaded=True)
Out[7]: {'null': ['imshow'], 'pil': ['imread', 'imsave']}

Cheers
St?fan


From stefan at sun.ac.za  Thu Nov 12 16:28:21 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 12 Nov 2009 23:28:21 +0200
Subject: ANN: scikits.image v0.2
In-Reply-To: <BD305489-E206-4A62-AC94-0A5327D4A911@gmail.com>
References: <9457e7c80911120603h6863532cy99499a352c2f6fca@mail.gmail.com> 
	<BD305489-E206-4A62-AC94-0A5327D4A911@gmail.com>
Message-ID: <9457e7c80911121328y4c656979w4248c017f42734bb@mail.gmail.com>

2009/11/12 Tony S Yu <tsyu80 at gmail.com>:
> I've uploaded a fix to remove the dependency on enhanced decorators.
> There are two branches on github (http://github.com/tonysyu/scikits.image
> ): one named "compatibility2.5" and and the other "compatibility2.5x".

Thanks, I've merged compatibility2.5.

Cheers
St?fan


From lev at columbia.edu  Fri Nov 13 10:33:11 2009
From: lev at columbia.edu (Lev Givon)
Date: Fri, 13 Nov 2009 10:33:11 -0500
Subject: ANN: scikits.image v0.2
In-Reply-To: <9457e7c80911120603h6863532cy99499a352c2f6fca@mail.gmail.com>
References: <9457e7c80911120603h6863532cy99499a352c2f6fca@mail.gmail.com>
Message-ID: <20091113153311.GI30016@avicenna.ee.columbia.edu>

Received from St??fan van der Walt on Thu, Nov 12, 2009 at 09:03:34AM EST:
> 
> I'm glad to announce the second release of `scikits.image`, a
> collection of image processing routines for SciPy.
> 

(snip)

When I tried to build the html documentation, I observed the following
error:

Exception occurred:
  File "/usr/lib/python2.6/site-packages/sphinx/jinja2glue.py", line
  128, in get_source
    raise TemplateNotFound(template)
TemplateNotFound: index.html

(I'm using sphinx 0.6.3, jinja2 2.2.1, and docutils 0.5 on Linux.)

     	   	  	 	       	   	    	L.G.


From stefan at sun.ac.za  Fri Nov 13 19:57:09 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sat, 14 Nov 2009 02:57:09 +0200
Subject: ANN: scikits.image v0.2
In-Reply-To: <20091113153311.GI30016@avicenna.ee.columbia.edu>
References: <9457e7c80911120603h6863532cy99499a352c2f6fca@mail.gmail.com> 
	<20091113153311.GI30016@avicenna.ee.columbia.edu>
Message-ID: <9457e7c80911131657rf184086oe4ed66d00a3d3b96@mail.gmail.com>

Hi Lev

2009/11/13 Lev Givon <lev at columbia.edu>:
> When I tried to build the html documentation, I observed the following
> error:

Thanks for the bug report.  I have put new source distribution at

http://pypi.python.org/pypi/scikits.image

that should fix the problem.

Regards
St?fan


From lev at columbia.edu  Sun Nov 15 00:37:44 2009
From: lev at columbia.edu (Lev Givon)
Date: Sun, 15 Nov 2009 00:37:44 -0500
Subject: ANN: scikits.image v0.2
In-Reply-To: <9457e7c80911131657rf184086oe4ed66d00a3d3b96@mail.gmail.com>
References: <9457e7c80911120603h6863532cy99499a352c2f6fca@mail.gmail.com>
 <20091113153311.GI30016@avicenna.ee.columbia.edu>
 <9457e7c80911131657rf184086oe4ed66d00a3d3b96@mail.gmail.com>
Message-ID: <20091115053744.GP30016@avicenna.ee.columbia.edu>

Received from St??fan van der Walt on Fri, Nov 13, 2009 at 07:57:09PM EST:
> 
> Hi Lev
> 
> 2009/11/13 Lev Givon <lev at columbia.edu>:
> > When I tried to build the html documentation, I observed the following
> > error:
> 
> Thanks for the bug report.  I have put new source distribution at
> 
> http://pypi.python.org/pypi/scikits.image
> 
> that should fix the problem.
> 
> Regards
> St??fan

Thanks for the quick fix. One other small item: it seems that
installing the package causes the setup.py files in the source
directory tree to be installed:

/usr/lib/python2.6/site-packages/scikits/image/graph/setup.py
/usr/lib/python2.6/site-packages/scikits/image/graph/setup.pyc
/usr/lib/python2.6/site-packages/scikits/image/io/setup.py
/usr/lib/python2.6/site-packages/scikits/image/io/setup.pyc
/usr/lib/python2.6/site-packages/scikits/image/opencv/setup.py
/usr/lib/python2.6/site-packages/scikits/image/opencv/setup.pyc
/usr/lib/python2.6/site-packages/scikits/image/setup.py
/usr/lib/python2.6/site-packages/scikits/image/setup.pyc

							L.G.


From stefan at sun.ac.za  Sun Nov 15 07:08:52 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 15 Nov 2009 14:08:52 +0200
Subject: ANN: scikits.image v0.2
In-Reply-To: <20091115053744.GP30016@avicenna.ee.columbia.edu>
References: <9457e7c80911120603h6863532cy99499a352c2f6fca@mail.gmail.com> 
	<20091113153311.GI30016@avicenna.ee.columbia.edu> <9457e7c80911131657rf184086oe4ed66d00a3d3b96@mail.gmail.com> 
	<20091115053744.GP30016@avicenna.ee.columbia.edu>
Message-ID: <9457e7c80911150408g617189f9o421b4d507d3d4120@mail.gmail.com>

Hi Lev

2009/11/15 Lev Givon <lev at columbia.edu>:
> Thanks for the quick fix. One other small item: it seems that
> installing the package causes the setup.py files in the source
> directory tree to be installed:

Thanks for the thorough testing.  Unfortunately, I don't know how to
fix this, or whether it should be fixed -- I see numpy also installs
its setup.py files.  The setup.py files need to be included in the
sdist, but excluded from the install, and I'm not aware of setuptools
functionality for that (but please point me in the right direction if
you know how!).

Cheers
St?fan


From stefan at sun.ac.za  Fri Nov 20 04:36:16 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 20 Nov 2009 11:36:16 +0200
Subject: Morphological operators merged
Message-ID: <9457e7c80911200136p1bee77dao583a2f57493f8f31@mail.gmail.com>

Hi all,

I merged Damian's morphology branch, which is now available as
scikits.image.morphology.

The code is here:
http://github.com/stefanv/scikits.image/tree/master/scikits/image/morphology/

Regards
St?fan


From gary.ruben at gmail.com  Sun Nov 22 07:39:13 2009
From: gary.ruben at gmail.com (Gary Ruben)
Date: Sun, 22 Nov 2009 04:39:13 -0800 (PST)
Subject: Trace path
In-Reply-To: <9457e7c80911220331r3f9d36d2i50c40aaca20c04bf@mail.gmail.com>
References: <9457e7c80911220331r3f9d36d2i50c40aaca20c04bf@mail.gmail.com>
Message-ID: <ebb3bdba-3cac-4f40-b5a7-a4779ce2821f@a39g2000pre.googlegroups.com>

Hi St?fan,

Assuming it's not easy to cast the input array to the float32 type,
because I'm guessing it will be called with int arrays if not
explicitly stated, can I suggest changing the documentation like:

costs : (M, N) ndarray of float32

Also, can I suggest a returns section like this:

Returns
-------
tuple : (costs, paths)
         ``costs`` is an (M, N) ndarray of float32 of cumulative
         costs from the starting point
         ``paths`` is a list of paths where each path is a list
         of ``(x, y)`` positions ordered from the start to each
         end point

--

Apart from that, I had a bit of a play with it and it worked nicely
for me. The only other thing is maybe adding a test case with a couple
of different goals might be good, like a goal that is the same as the
start point and two goals that have the same coords (I tried these by
had and they both work correctly)

Gary R.

On Nov 22, 10:31?pm, St?fan van der Walt <ste... at sun.ac.za> wrote:
> Hi all,
>
> Zachary posted code on scipy-dev to trace a shortest path through an
> image, given specified start and end points. ?With the shortest path
> algorithm already in scikits.image.graph, it would be possible to fix
> either the start or the end points, but not both. ?Zach's algorithm
> uses an iterative approach to achieve this goal.
>
> I'd be glad for any review comments. ?The code is here:
>
> http://github.com/stefanv/scikits.image/tree/master/scikits/image/graph
>
> Cheers
> St?fan


From zachary.pincus at yale.edu  Sun Nov 22 07:58:43 2009
From: zachary.pincus at yale.edu (Zachary Pincus)
Date: Sun, 22 Nov 2009 07:58:43 -0500
Subject: Trace path
In-Reply-To: <ebb3bdba-3cac-4f40-b5a7-a4779ce2821f@a39g2000pre.googlegroups.com>
References: <9457e7c80911220331r3f9d36d2i50c40aaca20c04bf@mail.gmail.com> <ebb3bdba-3cac-4f40-b5a7-a4779ce2821f@a39g2000pre.googlegroups.com>
Message-ID: <D71A5CF1-FEC7-4A52-813E-5A987A0EB993@yale.edu>

> Assuming it's not easy to cast the input array to the float32 type,
> because I'm guessing it will be called with int arrays if not
> explicitly stated, can I suggest changing the documentation like:
>
> costs : (M, N) ndarray of float32

This limitation might just be due to my relative inexperience with  
cython... Would it be better to have two identical functions, one  
which takes int costs and one with float costs (and then maybe a  
python wrapper function that selects between the two), or to write it  
so that it casts to float internally?

For that matter, is there a "safe cast" function that would, say,  
upcast ints to float32, but would complain about trying to cast  
float64s to float32? Or just better to document and let the user deal  
with the constraint?


> Also, can I suggest a returns section like this:
>
> Returns
> -------
> tuple : (costs, paths)
>         ``costs`` is an (M, N) ndarray of float32 of cumulative
>         costs from the starting point
>         ``paths`` is a list of paths where each path is a list
>         of ``(x, y)`` positions ordered from the start to each
>         end point

Thanks for helping get this in shape, Gary and St?fan!

Zach


From stefan at sun.ac.za  Sun Nov 22 06:31:03 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 22 Nov 2009 13:31:03 +0200
Subject: Trace path
Message-ID: <9457e7c80911220331r3f9d36d2i50c40aaca20c04bf@mail.gmail.com>

Hi all,

Zachary posted code on scipy-dev to trace a shortest path through an
image, given specified start and end points.  With the shortest path
algorithm already in scikits.image.graph, it would be possible to fix
either the start or the end points, but not both.  Zach's algorithm
uses an iterative approach to achieve this goal.

I'd be glad for any review comments.  The code is here:

http://github.com/stefanv/scikits.image/tree/master/scikits/image/graph

Cheers
St?fan


From stefan at sun.ac.za  Sun Nov 22 08:38:02 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 22 Nov 2009 15:38:02 +0200
Subject: Trace path
In-Reply-To: <ebb3bdba-3cac-4f40-b5a7-a4779ce2821f@a39g2000pre.googlegroups.com>
References: <9457e7c80911220331r3f9d36d2i50c40aaca20c04bf@mail.gmail.com> 
	<ebb3bdba-3cac-4f40-b5a7-a4779ce2821f@a39g2000pre.googlegroups.com>
Message-ID: <9457e7c80911220538p63a6a786gcbf61af616422d24@mail.gmail.com>

Hey Gary

2009/11/22 Gary Ruben <gary.ruben at gmail.com>:
> Assuming it's not easy to cast the input array to the float32 type,
> because I'm guessing it will be called with int arrays if not
> explicitly stated, can I suggest changing the documentation like:

Sure, would you provide a patch, then I'll pull it from your github branch.

Thanks
St?fan


From stefan at sun.ac.za  Sun Nov 22 09:18:11 2009
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 22 Nov 2009 16:18:11 +0200
Subject: Trace path
In-Reply-To: <D71A5CF1-FEC7-4A52-813E-5A987A0EB993@yale.edu>
References: <9457e7c80911220331r3f9d36d2i50c40aaca20c04bf@mail.gmail.com> 
	<ebb3bdba-3cac-4f40-b5a7-a4779ce2821f@a39g2000pre.googlegroups.com> 
	<D71A5CF1-FEC7-4A52-813E-5A987A0EB993@yale.edu>
Message-ID: <9457e7c80911220618l70b31ca4w222e2e4ec1b2bfe1@mail.gmail.com>

Hi Zach

2009/11/22 Zachary Pincus <zachary.pincus at yale.edu>:
>> Assuming it's not easy to cast the input array to the float32 type,
>> because I'm guessing it will be called with int arrays if not
>> explicitly stated, can I suggest changing the documentation like:
>>
>> costs : (M, N) ndarray of float32
>
> This limitation might just be due to my relative inexperience with
> cython... Would it be better to have two identical functions, one
> which takes int costs and one with float costs (and then maybe a
> python wrapper function that selects between the two), or to write it
> so that it casts to float internally?

Since the cast only needs to happen once, you could just insert it in
the Cython function.

> For that matter, is there a "safe cast" function that would, say,
> upcast ints to float32, but would complain about trying to cast
> float64s to float32? Or just better to document and let the user deal
> with the constraint?

np.can_cast(x.dtype, np.float32)

> Thanks for helping get this in shape, Gary and St?fan!

Which reminds me -- I should update the contributors list.

Thanks!
St?fan