From stefan at sun.ac.za  Wed Oct  5 14:02:11 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 5 Oct 2011 11:02:11 -0700
Subject: Release progress
In-Reply-To: <CABDkGQ==S7TWrfVhAt4O_XyRrg=QNxRGDpwgSDGTjukr-dDXuw@mail.gmail.com>
References: <CABDkGQ==S7TWrfVhAt4O_XyRrg=QNxRGDpwgSDGTjukr-dDXuw@mail.gmail.com>
Message-ID: <CABDkGQnORBs9XOrZi4LpP2Jd1a4m=Aq==9gpaz=kHCwxtAryGw@mail.gmail.com>

Hi everyone,

Here's an update on progress towards the 0.3 release.

2011/9/26 St?fan van der Walt <stefan at sun.ac.za>:
> - Merge:
>
> https://github.com/scikits-image/scikits.image/pull/19 [CellProfiler
> morphology] [will also require minor moving around of files]

This turned out to be a much bigger job than anticipated.  The
cpmorphology module is large, and after discussions with Emmanuelle we
decided to integrate it in functional pieces (one PR each).  We've
given ourselves until Thursday to bring over two core pieces of
functionality: watershed and skeletonization.  The rest will have to
wait until 0.4.

> I'd like for 0.3 to also have Debian packaging. ?I was originally
> planning to do our own Windows binary releases, but I don't think I'll
> have time to setup the appropriate environment in time.

The Debian packaging is done, and lives in the 'debian' branch on the
main repo.  Changes still required:

* Update the license file
* Write a man-page for scivi

I'll be tagging 0.3 on Sunday.  What doesn't get in this round will
have to wait until 0.4, but unlike the enormous lag between 0.2.2 and
0.3, we hope to release 0.4 in about a month's time (and keep doing
that!).

Thanks for everyone's help so far!  I've listed the people who
contributed to 0.3 below... if your name is missing, let me know.

Regards
St?fan

Damian Eads
Chris Colbert
Zachary Pincus
Emmanuelle Gouillart
James Turner
Luis Pedro Coelho
Thouis (Ray) Jones
Dan Farmer
Pieter Holtzhausen
Zach Pincus
Tony S Yu
Martin Bergtholdt
Kyle Mandli
Neil Muller
Gael Varoquaux
Andreas Mueller


From stefan at sun.ac.za  Sat Oct  8 16:23:46 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sat, 8 Oct 2011 13:23:46 -0700
Subject: releasing & packaging vs. renaming
In-Reply-To: <20111008192223.GA4834@phare.normalesup.org>
References: <20111008192223.GA4834@phare.normalesup.org>
Message-ID: <CABDkGQk9pvVtV=kUxTAgS5+UmqzCEnQ=TTJVwAug1aRYc_scxA@mail.gmail.com>

On Sat, Oct 8, 2011 at 12:22 PM, Emmanuelle Gouillart
<emmanuelle.gouillart at nsup.org> wrote:
> package, that we had in July (going from scikits.image to skimage, see
> https://groups.google.com/forum/?hl=fr#!topic/scikits-image/TcxVkGqTKOk).
> If we think that we're going to rename one day, then maybe we should do
> it as soon as possible, because otherwise we're going to have problems
> with package names: users will be confused, Yaroslav is going to have to
> make transition packages, and there will be problems on Pypi too. I have
> at home one of the developers of the scikit learn (Ga?l Varoquaux), who's
> telling me that they are happy about the renaming (scikit.learn ->
> sklearn), but that it created a lot of confusion for packaging. If we

I was hesitant to do this initially--'skimage' doesn't sound
particularly appealing; but I think for uniformity across scikits, and
to sort out the namespace issues, we may just as well.

If you're in favour, please raise your hand.

Regards
St?fan


From emmanuelle.gouillart at nsup.org  Sat Oct  8 15:22:23 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Sat, 8 Oct 2011 21:22:23 +0200
Subject: releasing & packaging vs. renaming
Message-ID: <20111008192223.GA4834@phare.normalesup.org>

	Hi all,

	I was very happy to see that St??????fan and Yaroslav had been working
on a debian/ubuntu package, this should really increase the visibility of
our scikit. Then I was reminded of the discussion on renaming the
package, that we had in July (going from scikits.image to skimage, see
https://groups.google.com/forum/?hl=fr#!topic/scikits-image/TcxVkGqTKOk).
If we think that we're going to rename one day, then maybe we should do
it as soon as possible, because otherwise we're going to have problems
with package names: users will be confused, Yaroslav is going to have to
make transition packages, and there will be problems on Pypi too. I have
at home one of the developers of the scikit learn (Ga??????l Varoquaux), who's
telling me that they are happy about the renaming (scikit.learn ->
sklearn), but that it created a lot of confusion for packaging. If we
hope to increase the number of users significantly in the future, maybe
we should rename before the release... (I truly apologize for writing
this one day before the programmed release) Another option would be to
delay the debian packaging to 0.4, and rename in 0.4. 

	What do you think?

	Emmanuelle


From amueller at ais.uni-bonn.de  Sat Oct  8 17:01:42 2011
From: amueller at ais.uni-bonn.de (Andreas Mueller)
Date: Sat, 08 Oct 2011 23:01:42 +0200
Subject: releasing & packaging vs. renaming
In-Reply-To: <CABDkGQk9pvVtV=kUxTAgS5+UmqzCEnQ=TTJVwAug1aRYc_scxA@mail.gmail.com>
References: <20111008192223.GA4834@phare.normalesup.org> <CABDkGQk9pvVtV=kUxTAgS5+UmqzCEnQ=TTJVwAug1aRYc_scxA@mail.gmail.com>
Message-ID: <4E90BA36.60207@ais.uni-bonn.de>

On 10/08/2011 10:23 PM, St??????fan van der Walt wrote:
> On Sat, Oct 8, 2011 at 12:22 PM, Emmanuelle Gouillart
> <emmanuelle.gouillart at nsup.org>  wrote:
>> package, that we had in July (going from scikits.image to skimage, see
>> https://groups.google.com/forum/?hl=fr#!topic/scikits-image/TcxVkGqTKOk).
>> If we think that we're going to rename one day, then maybe we should do
>> it as soon as possible, because otherwise we're going to have problems
>> with package names: users will be confused, Yaroslav is going to have to
>> make transition packages, and there will be problems on Pypi too. I have
>> at home one of the developers of the scikit learn (Ga??????l Varoquaux), who's
>> telling me that they are happy about the renaming (scikit.learn ->
>> sklearn), but that it created a lot of confusion for packaging. If we
> I was hesitant to do this initially--'skimage' doesn't sound
> particularly appealing; but I think for uniformity across scikits, and
> to sort out the namespace issues, we may just as well.
I know about the sklearn rename but what are the other scikits doing?
There seem to be quite a lot of projects: http://scikits.appspot.com/scikits
If the sklearn people are happy with their rename, maybe that's the way 
to go.

Cheers,
Andy


From stefan at sun.ac.za  Sun Oct  9 02:17:32 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sat, 8 Oct 2011 23:17:32 -0700
Subject: releasing & packaging vs. renaming
In-Reply-To: <CAEym_Hq3jCJOD19Zbnx=auAVNYbracXPUEJYqzWOkEh+_mHNNw@mail.gmail.com>
References: <20111008192223.GA4834@phare.normalesup.org> <CABDkGQk9pvVtV=kUxTAgS5+UmqzCEnQ=TTJVwAug1aRYc_scxA@mail.gmail.com>
 <4E90BA36.60207@ais.uni-bonn.de> <20111008220729.GB31828@phare.normalesup.org>
 <CAEym_Hq3jCJOD19Zbnx=auAVNYbracXPUEJYqzWOkEh+_mHNNw@mail.gmail.com>
Message-ID: <CABDkGQn90NmRq9L4X0ScOsmP-YzdQxX=h0J+wC+aj+0+BuaNJg@mail.gmail.com>

On Sat, Oct 8, 2011 at 9:34 PM, Tony Yu <tsyu80 at gmail.com> wrote:
> Agreed: there's definitely a wide range of activity among the scikits.
> sklearn and statsmodels are probably a couple of the more active ones, so
> they'd be good examples to follow. And I also agree that changing the name
> sooner, rather than later, would be best. +1

Is there a preference between `skimage` and `skimg` ?

Regards
St?fan


From emmanuelle.gouillart at nsup.org  Sat Oct  8 18:00:47 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Sun, 9 Oct 2011 00:00:47 +0200
Subject: releasing & packaging vs. renaming
In-Reply-To: <CABDkGQk9pvVtV=kUxTAgS5+UmqzCEnQ=TTJVwAug1aRYc_scxA@mail.gmail.com>
References: <20111008192223.GA4834@phare.normalesup.org>
 <CABDkGQk9pvVtV=kUxTAgS5+UmqzCEnQ=TTJVwAug1aRYc_scxA@mail.gmail.com>
Message-ID: <20111008220047.GA31828@phare.normalesup.org>

> I was hesitant to do this initially--'skimage' doesn't sound
> particularly appealing; but I think for uniformity across scikits, and
> to sort out the namespace issues, we may just as well.

> If you're in favour, please raise your hand.

I'm in favour of renaming (for example to skimage), in order to simplify
the namespace. So I raise my hand :-)

Emmanuelle


From emmanuelle.gouillart at nsup.org  Sat Oct  8 18:07:29 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Sun, 9 Oct 2011 00:07:29 +0200
Subject: releasing & packaging vs. renaming
In-Reply-To: <4E90BA36.60207@ais.uni-bonn.de>
References: <20111008192223.GA4834@phare.normalesup.org>
 <CABDkGQk9pvVtV=kUxTAgS5+UmqzCEnQ=TTJVwAug1aRYc_scxA@mail.gmail.com>
 <4E90BA36.60207@ais.uni-bonn.de>
Message-ID: <20111008220729.GB31828@phare.normalesup.org>

> I know about the sklearn rename but what are the other scikits doing?
> There seem to be quite a lot of projects: http://scikits.appspot.com/scikits
> If the sklearn people are happy with their rename, maybe that's the
> way to go.

Ga??????l tells me that the idea of renaming came from the statmodels scikit
guys (see
http://permalink.gmane.org/gmane.comp.python.scientific.devel/15306). I
don't know about the other scikits; one problem is that there is a great
heterogeneity in the impact or the activity (and quality, I guess) among
the different scikits branded on http://scikits.appspot.com/scikits... 

Emmanuelle


From emmanuelle.gouillart at nsup.org  Sat Oct  8 18:17:28 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Sun, 9 Oct 2011 00:17:28 +0200
Subject: example gallery
Message-ID: <20111008221728.GC31828@phare.normalesup.org>

	Hello,

	I just wanted to bring to your attention that it is now possible
to include in the documentation python scripts (in doc/examples), that
are transformed into a rst page (including the code) when the doc is
built. If the script a) is named `plot_xxx.py` and b) generates a
matplotlib figure, then an image of the figure is displayed on the
corresponding documentation page, and a thumbnail of the figure is added
to the gallery of examples. I think we all love matplotlib's gallery,
which is very useful to find how to do specific stuff, so I hope our
gallery might as well help users to find out how to do specific tasks. It
may be especially useful for someone who doesn't have the right keywords
for a google/sphinx text search. The code for generating the example
pages and the gallery was shamelessly taken from the scikit learn
codebase! (see their gallery on
http://scikit-learn.sourceforge.net/stable/auto_examples/index.html) 

	So, it might be a good idea to a) write more examples for the
gallery, and b) when new functions are added to the scikit, write
systematically such examples for the doc.

	Cheers,
	Emmanuelle



From tsyu80 at gmail.com  Sun Oct  9 00:34:20 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Sun, 9 Oct 2011 00:34:20 -0400
Subject: releasing & packaging vs. renaming
In-Reply-To: <20111008220729.GB31828@phare.normalesup.org>
References: <20111008192223.GA4834@phare.normalesup.org>
	<CABDkGQk9pvVtV=kUxTAgS5+UmqzCEnQ=TTJVwAug1aRYc_scxA@mail.gmail.com>
	<4E90BA36.60207@ais.uni-bonn.de>
	<20111008220729.GB31828@phare.normalesup.org>
Message-ID: <CAEym_Hq3jCJOD19Zbnx=auAVNYbracXPUEJYqzWOkEh+_mHNNw@mail.gmail.com>

On Sat, Oct 8, 2011 at 6:07 PM, Emmanuelle Gouillart <
emmanuelle.gouillart at nsup.org> wrote:

> > I know about the sklearn rename but what are the other scikits doing?
> > There seem to be quite a lot of projects:
> http://scikits.appspot.com/scikits
> > If the sklearn people are happy with their rename, maybe that's the
> > way to go.
>
> Ga?l tells me that the idea of renaming came from the statmodels scikit
> guys (see
> http://permalink.gmane.org/gmane.comp.python.scientific.devel/15306). I
> don't know about the other scikits; one problem is that there is a great
> heterogeneity in the impact or the activity (and quality, I guess) among
> the different scikits branded on http://scikits.appspot.com/scikits...
>

Agreed: there's definitely a wide range of activity among the scikits.
sklearn and statsmodels are probably a couple of the more active ones, so
they'd be good examples to follow. And I also agree that changing the name
sooner, rather than later, would be best. +1

-Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111009/a610be9b/attachment.html>

From amueller at ais.uni-bonn.de  Sat Oct  8 18:42:20 2011
From: amueller at ais.uni-bonn.de (Andreas Mueller)
Date: Sun, 09 Oct 2011 00:42:20 +0200
Subject: example gallery
In-Reply-To: <20111008221728.GC31828@phare.normalesup.org>
References: <20111008221728.GC31828@phare.normalesup.org>
Message-ID: <4E90D1CC.7070406@ais.uni-bonn.de>

Thanks Emmanuell, that's great :)

On 10/09/2011 12:17 AM, Emmanuelle Gouillart wrote:
> 	Hello,
>
> 	I just wanted to bring to your attention that it is now possible
> to include in the documentation python scripts (in doc/examples), that
> are transformed into a rst page (including the code) when the doc is
> built. If the script a) is named `plot_xxx.py` and b) generates a
> matplotlib figure, then an image of the figure is displayed on the
> corresponding documentation page, and a thumbnail of the figure is added
> to the gallery of examples. I think we all love matplotlib's gallery,
> which is very useful to find how to do specific stuff, so I hope our
> gallery might as well help users to find out how to do specific tasks. It
> may be especially useful for someone who doesn't have the right keywords
> for a google/sphinx text search. The code for generating the example
> pages and the gallery was shamelessly taken from the scikit learn
> codebase! (see their gallery on
> http://scikit-learn.sourceforge.net/stable/auto_examples/index.html)
>
> 	So, it might be a good idea to a) write more examples for the
> gallery, and b) when new functions are added to the scikit, write
> systematically such examples for the doc.
>
> 	Cheers,
> 	Emmanuelle
>



From stefan at sun.ac.za  Sun Oct  9 04:56:57 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 9 Oct 2011 01:56:57 -0700
Subject: releasing & packaging vs. renaming
In-Reply-To: <CABDkGQn90NmRq9L4X0ScOsmP-YzdQxX=h0J+wC+aj+0+BuaNJg@mail.gmail.com>
References: <20111008192223.GA4834@phare.normalesup.org> <CABDkGQk9pvVtV=kUxTAgS5+UmqzCEnQ=TTJVwAug1aRYc_scxA@mail.gmail.com>
 <4E90BA36.60207@ais.uni-bonn.de> <20111008220729.GB31828@phare.normalesup.org>
 <CAEym_Hq3jCJOD19Zbnx=auAVNYbracXPUEJYqzWOkEh+_mHNNw@mail.gmail.com> <CABDkGQn90NmRq9L4X0ScOsmP-YzdQxX=h0J+wC+aj+0+BuaNJg@mail.gmail.com>
Message-ID: <CABDkGQmDfTXZ51F_YMaKaJ1tdGwxACaAJrV_u9CebiYq8L2qBg@mail.gmail.com>

2011/10/8 St?fan van der Walt <stefan at sun.ac.za>:
> On Sat, Oct 8, 2011 at 9:34 PM, Tony Yu <tsyu80 at gmail.com> wrote:
>> Agreed: there's definitely a wide range of activity among the scikits.
>> sklearn and statsmodels are probably a couple of the more active ones, so
>> they'd be good examples to follow. And I also agree that changing the name
>> sooner, rather than later, would be best. +1
>
> Is there a preference between `skimage` and `skimg` ?

Actually, `ski` is also available.  Three letters--not too hard to
type, doesn't sound awful (es-kay-eye for scikits image), and after
all--it's just a module name :)

Cheers
St?fan


From stefan at sun.ac.za  Sun Oct  9 05:40:18 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 9 Oct 2011 02:40:18 -0700
Subject: releasing & packaging vs. renaming
In-Reply-To: <CAE-UAvQ4nzffC_Gk8K5zxyhDTEuvnCNJai9zi2G9Ntx3p3_mZA@mail.gmail.com>
References: <20111008192223.GA4834@phare.normalesup.org> <CABDkGQk9pvVtV=kUxTAgS5+UmqzCEnQ=TTJVwAug1aRYc_scxA@mail.gmail.com>
 <4E90BA36.60207@ais.uni-bonn.de> <20111008220729.GB31828@phare.normalesup.org>
 <CAEym_Hq3jCJOD19Zbnx=auAVNYbracXPUEJYqzWOkEh+_mHNNw@mail.gmail.com>
 <CABDkGQn90NmRq9L4X0ScOsmP-YzdQxX=h0J+wC+aj+0+BuaNJg@mail.gmail.com>
 <CABDkGQmDfTXZ51F_YMaKaJ1tdGwxACaAJrV_u9CebiYq8L2qBg@mail.gmail.com> <CAE-UAvQ4nzffC_Gk8K5zxyhDTEuvnCNJai9zi2G9Ntx3p3_mZA@mail.gmail.com>
Message-ID: <CABDkGQn0so6aapQW3ztvX9iEeJxcovK_s=3kf03CcCise4uxJg@mail.gmail.com>

On Sun, Oct 9, 2011 at 2:08 AM, Nelle Varoquaux
<nelle.varoquaux at gmail.com> wrote:
>
> 2011/10/9 St?fan van der Walt <stefan at sun.ac.za>
>>
>> 2011/10/8 St?fan van der Walt <stefan at sun.ac.za>:
>> > On Sat, Oct 8, 2011 at 9:34 PM, Tony Yu <tsyu80 at gmail.com> wrote:
>> >> Agreed: there's definitely a wide range of activity among the scikits.
>> >> sklearn and statsmodels are probably a couple of the more active ones,
>> >> so
>> >> they'd be good examples to follow. And I also agree that changing the
>> >> name
>> >> sooner, rather than later, would be best. +1
>> >
>> > Is there a preference between `skimage` and `skimg` ?
>>
>> Actually, `ski` is also available. ?Three letters--not too hard to
>> type, doesn't sound awful (es-kay-eye for scikits image), and after
>> all--it's just a module name :)
>
> I don't whether you'd take this in account, but it's quite hard to google.
> Googling sklearn directly links to the scikit-learn documentation.
> Same with statsmodels.

Thanks, that's a valid concern.  Seems like skimage is the top vote so
far, then.  Any other votes?

Cheers
St?fan


From stefan at sun.ac.za  Sun Oct  9 06:48:20 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 9 Oct 2011 03:48:20 -0700
Subject: Challenge: Speed up seam carving example
Message-ID: <CABDkGQnwuYDOoQb9uWK6PUVvGLOKpz9zNE0T9eFqTPjE83_vOg@mail.gmail.com>

Hi all,

I have placed an example of seam carving here:

https://github.com/stefanv/scikits.image-1/blob/seam_carving/doc/examples/plot_seam_carving.py

The idea is super simple, but currently it's too slow.  I'm curious to
see if anyone can improve its execution time?

If you haven't seen seam carving before, take a look at the video link
in the docstring.

Regards
St?fan


From tsyu80 at gmail.com  Sun Oct  9 09:57:09 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Sun, 9 Oct 2011 09:57:09 -0400
Subject: releasing & packaging vs. renaming
In-Reply-To: <20111009133820.GA31274@phare.normalesup.org>
References: <20111008192223.GA4834@phare.normalesup.org>
	<CABDkGQk9pvVtV=kUxTAgS5+UmqzCEnQ=TTJVwAug1aRYc_scxA@mail.gmail.com>
	<4E90BA36.60207@ais.uni-bonn.de>
	<20111008220729.GB31828@phare.normalesup.org>
	<CAEym_Hq3jCJOD19Zbnx=auAVNYbracXPUEJYqzWOkEh+_mHNNw@mail.gmail.com>
	<CABDkGQn90NmRq9L4X0ScOsmP-YzdQxX=h0J+wC+aj+0+BuaNJg@mail.gmail.com>
	<CABDkGQmDfTXZ51F_YMaKaJ1tdGwxACaAJrV_u9CebiYq8L2qBg@mail.gmail.com>
	<CAE-UAvQ4nzffC_Gk8K5zxyhDTEuvnCNJai9zi2G9Ntx3p3_mZA@mail.gmail.com>
	<CABDkGQn0so6aapQW3ztvX9iEeJxcovK_s=3kf03CcCise4uxJg@mail.gmail.com>
	<4E91A071.8040303@ais.uni-bonn.de>
	<20111009133820.GA31274@phare.normalesup.org>
Message-ID: <CAEym_HquAw7qGRP6gjOrfyOed3joK19_CbP3x-ck+dximESaKw@mail.gmail.com>

On Sun, Oct 9, 2011 at 9:38 AM, Emmanuelle Gouillart <
emmanuelle.gouillart at nsup.org> wrote:

>
> > Don't know if this is a good argument but people might rather be
> > googleing "python ski", which is easy
> > to google.
> > For this reason I am ambivalent between ski and skimage.
>
> I'm more in favour of skimage (and having 'image' in the name of the
> package), but if we want something short and easy to google, 'skim' might
> be fun!
>
> Emma
>

I agree: having "image" in the name is preferable.

If we start putting more interfaces to code in the top level module (right
now, only functions from `util` are there) or automatically importing
submodules (e.g. `io` would be a good candidate), then adopting/promoting
the convention "import skimage as ski" would be nice (so the one import
would give me `ski.img_as_float` and `ski.io.imread`).

-Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111009/3d402a89/attachment.html>

From emmanuelle.gouillart at nsup.org  Sun Oct  9 04:14:43 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Sun, 9 Oct 2011 10:14:43 +0200
Subject: releasing & packaging vs. renaming
In-Reply-To: <CABDkGQn90NmRq9L4X0ScOsmP-YzdQxX=h0J+wC+aj+0+BuaNJg@mail.gmail.com>
References: <20111008192223.GA4834@phare.normalesup.org>
 <CABDkGQk9pvVtV=kUxTAgS5+UmqzCEnQ=TTJVwAug1aRYc_scxA@mail.gmail.com>
 <4E90BA36.60207@ais.uni-bonn.de>
 <20111008220729.GB31828@phare.normalesup.org>
 <CAEym_Hq3jCJOD19Zbnx=auAVNYbracXPUEJYqzWOkEh+_mHNNw@mail.gmail.com>
 <CABDkGQn90NmRq9L4X0ScOsmP-YzdQxX=h0J+wC+aj+0+BuaNJg@mail.gmail.com>
Message-ID: <20111009081443.GA10141@phare.normalesup.org>

On Sat, Oct 08, 2011 at 11:17:32PM -0700, St??????fan van der Walt wrote:
> On Sat, Oct 8, 2011 at 9:34 PM, Tony Yu <tsyu80 at gmail.com> wrote:
> > Agreed: there's definitely a wide range of activity among the scikits.
> > sklearn and statsmodels are probably a couple of the more active ones, so
> > they'd be good examples to follow. And I also agree that changing the name
> > sooner, rather than later, would be best. +1

> Is there a preference between `skimage` and `skimg` ?

skimage sounds easier to pronounce, I think.

Emmanuelle


From nelle.varoquaux at gmail.com  Sun Oct  9 05:08:16 2011
From: nelle.varoquaux at gmail.com (Nelle Varoquaux)
Date: Sun, 9 Oct 2011 11:08:16 +0200
Subject: releasing & packaging vs. renaming
In-Reply-To: <CABDkGQmDfTXZ51F_YMaKaJ1tdGwxACaAJrV_u9CebiYq8L2qBg@mail.gmail.com>
References: <20111008192223.GA4834@phare.normalesup.org>
	<CABDkGQk9pvVtV=kUxTAgS5+UmqzCEnQ=TTJVwAug1aRYc_scxA@mail.gmail.com>
	<4E90BA36.60207@ais.uni-bonn.de>
	<20111008220729.GB31828@phare.normalesup.org>
	<CAEym_Hq3jCJOD19Zbnx=auAVNYbracXPUEJYqzWOkEh+_mHNNw@mail.gmail.com>
	<CABDkGQn90NmRq9L4X0ScOsmP-YzdQxX=h0J+wC+aj+0+BuaNJg@mail.gmail.com>
	<CABDkGQmDfTXZ51F_YMaKaJ1tdGwxACaAJrV_u9CebiYq8L2qBg@mail.gmail.com>
Message-ID: <CAE-UAvQ4nzffC_Gk8K5zxyhDTEuvnCNJai9zi2G9Ntx3p3_mZA@mail.gmail.com>

2011/10/9 St?fan van der Walt <stefan at sun.ac.za>

> 2011/10/8 St?fan van der Walt <stefan at sun.ac.za>:
> > On Sat, Oct 8, 2011 at 9:34 PM, Tony Yu <tsyu80 at gmail.com> wrote:
> >> Agreed: there's definitely a wide range of activity among the scikits.
> >> sklearn and statsmodels are probably a couple of the more active ones,
> so
> >> they'd be good examples to follow. And I also agree that changing the
> name
> >> sooner, rather than later, would be best. +1
> >
> > Is there a preference between `skimage` and `skimg` ?
>
> Actually, `ski` is also available.  Three letters--not too hard to
> type, doesn't sound awful (es-kay-eye for scikits image), and after
> all--it's just a module name :)
>

I don't whether you'd take this in account, but it's quite hard to google.
Googling sklearn directly links to the scikit-learn documentation.
Same with statsmodels.

Cheers,
Nelle



> Cheers
> St?fan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111009/65593960/attachment.html>

From google at terre-adelie.org  Sun Oct  9 07:33:50 2011
From: google at terre-adelie.org (=?ISO-8859-1?Q?J=E9r=F4me?= Kieffer)
Date: Sun, 9 Oct 2011 13:33:50 +0200
Subject: interpolation issue...
Message-ID: <20111009133350.2e64539e92a5251ff7c18b0f@terre-adelie.org>

Hi all,

This is my first post on this list, but I think I met most participant
at EuroScipy this summer.

I write code for scientists and it seams to be a common problem to do
"interpolation with given constrains" (in tomography, but also in other
fields like [1]). 
A common case is the polar transformation: x,y -> r,theta 
Usually one takes a destination space coordinate (r,theta),
look for input coordinates (x,y) and interpolate the neighbours with
bilinear or bicubic spline. It is a backwards interpolation and plenty
of implementations are available.

First constraint: all signal in input has to appear in output:
interpolation has to be done in "forwards" mode and can be done with 2D
histogramming. Thanks to cython it is even 10x faster than the numpy
implementation (0.5s for 4Mpix float64).

Second constraint is that I need to conserve the surface density in the
transformation. One idea is to cut pixels (4 corners) into triangles (2
minimum), the number of them varying with the spatial extension of the
pixel in destination space (4 triangle if 1 bin boundary, 6 if 2 bin
boundaries, ....) ... then do the histogramming as before but the cost
is likely to be huge. Beside this I am convinced to re-invent the
wheel ... even if I was unable to find anything in google but I am
probably lacking the good keyword.

Do you know this problem and what implementations already exists ??

Thanks for reading this "long email"

-- 
J?r?me Kieffer 
<jerome.kieffer at terre-adelie.org>
[1]: https://forge.epn-campus.eu/attachments/1459/20111010-PyFAI-Poster-A0.pdf


From amueller at ais.uni-bonn.de  Sun Oct  9 09:24:01 2011
From: amueller at ais.uni-bonn.de (Andreas Mueller)
Date: Sun, 09 Oct 2011 15:24:01 +0200
Subject: releasing & packaging vs. renaming
In-Reply-To: <CABDkGQn0so6aapQW3ztvX9iEeJxcovK_s=3kf03CcCise4uxJg@mail.gmail.com>
References: <20111008192223.GA4834@phare.normalesup.org> <CABDkGQk9pvVtV=kUxTAgS5+UmqzCEnQ=TTJVwAug1aRYc_scxA@mail.gmail.com> <4E90BA36.60207@ais.uni-bonn.de> <20111008220729.GB31828@phare.normalesup.org> <CAEym_Hq3jCJOD19Zbnx=auAVNYbracXPUEJYqzWOkEh+_mHNNw@mail.gmail.com> <CABDkGQn90NmRq9L4X0ScOsmP-YzdQxX=h0J+wC+aj+0+BuaNJg@mail.gmail.com> <CABDkGQmDfTXZ51F_YMaKaJ1tdGwxACaAJrV_u9CebiYq8L2qBg@mail.gmail.com> <CAE-UAvQ4nzffC_Gk8K5zxyhDTEuvnCNJai9zi2G9Ntx3p3_mZA@mail.gmail.com> <CABDkGQn0so6aapQW3ztvX9iEeJxcovK_s=3kf03CcCise4uxJg@mail.gmail.com>
Message-ID: <4E91A071.8040303@ais.uni-bonn.de>

On 10/09/2011 11:40 AM, St??????fan van der Walt wrote:
> On Sun, Oct 9, 2011 at 2:08 AM, Nelle Varoquaux
> <nelle.varoquaux at gmail.com>  wrote:
>> 2011/10/9 St??????fan van der Walt<stefan at sun.ac.za>
>>> 2011/10/8 St??????fan van der Walt<stefan at sun.ac.za>:
>>>> On Sat, Oct 8, 2011 at 9:34 PM, Tony Yu<tsyu80 at gmail.com>  wrote:
>>>>> Agreed: there's definitely a wide range of activity among the scikits.
>>>>> sklearn and statsmodels are probably a couple of the more active ones,
>>>>> so
>>>>> they'd be good examples to follow. And I also agree that changing the
>>>>> name
>>>>> sooner, rather than later, would be best. +1
>>>> Is there a preference between `skimage` and `skimg` ?
>>> Actually, `ski` is also available.  Three letters--not too hard to
>>> type, doesn't sound awful (es-kay-eye for scikits image), and after
>>> all--it's just a module name :)
>> I don't whether you'd take this in account, but it's quite hard to google.
>> Googling sklearn directly links to the scikit-learn documentation.
>> Same with statsmodels.
> Thanks, that's a valid concern.  Seems like skimage is the top vote so
> far, then.  Any other votes?
>
Don't know if this is a good argument but people might rather be 
googleing "python ski", which is easy
to google.
For this reason I am ambivalent between ski and skimage.

Cheers,
Andy


From stefan at sun.ac.za  Sun Oct  9 18:36:53 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 9 Oct 2011 15:36:53 -0700
Subject: releasing & packaging vs. renaming
In-Reply-To: <20111009210242.GB13524@phare.normalesup.org>
References: <4E90BA36.60207@ais.uni-bonn.de> <20111008220729.GB31828@phare.normalesup.org>
 <CAEym_Hq3jCJOD19Zbnx=auAVNYbracXPUEJYqzWOkEh+_mHNNw@mail.gmail.com>
 <CABDkGQn90NmRq9L4X0ScOsmP-YzdQxX=h0J+wC+aj+0+BuaNJg@mail.gmail.com>
 <CABDkGQmDfTXZ51F_YMaKaJ1tdGwxACaAJrV_u9CebiYq8L2qBg@mail.gmail.com>
 <CAE-UAvQ4nzffC_Gk8K5zxyhDTEuvnCNJai9zi2G9Ntx3p3_mZA@mail.gmail.com>
 <CABDkGQn0so6aapQW3ztvX9iEeJxcovK_s=3kf03CcCise4uxJg@mail.gmail.com>
 <4E91A071.8040303@ais.uni-bonn.de> <20111009133820.GA31274@phare.normalesup.org>
 <CAEym_HquAw7qGRP6gjOrfyOed3joK19_CbP3x-ck+dximESaKw@mail.gmail.com> <20111009210242.GB13524@phare.normalesup.org>
Message-ID: <CABDkGQnubJieLvd6WYkCyowKrO0f+tzHY3MJF10n-xotuc3spg@mail.gmail.com>

On Sun, Oct 9, 2011 at 2:02 PM, Emmanuelle Gouillart
<emmanuelle.gouillart at nsup.org> wrote:
>
>> ? ?If we start putting more interfaces to code in the top level module (right
>> ? ?now, only functions from `util` are there) or automatically importing
>> ? ?submodules (e.g. `io` would be a good candidate), then adopting/promoting
>> ? ?the convention "import skimage as ski" would be nice (so the one import
>> ? ?would give me `ski.img_as_float` and `ski.io.imread`).
>
> + 1

I propose that we make the 0.3 release today as planned, and then work
in the coming week to bring out 0.4 with the rename.  0.4 will then be
the first version in Debian.

Regards
St?fan


From emmanuelle.gouillart at nsup.org  Sun Oct  9 09:38:20 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Sun, 9 Oct 2011 15:38:20 +0200
Subject: releasing & packaging vs. renaming
In-Reply-To: <4E91A071.8040303@ais.uni-bonn.de>
References: <20111008192223.GA4834@phare.normalesup.org>
 <CABDkGQk9pvVtV=kUxTAgS5+UmqzCEnQ=TTJVwAug1aRYc_scxA@mail.gmail.com>
 <4E90BA36.60207@ais.uni-bonn.de>
 <20111008220729.GB31828@phare.normalesup.org>
 <CAEym_Hq3jCJOD19Zbnx=auAVNYbracXPUEJYqzWOkEh+_mHNNw@mail.gmail.com>
 <CABDkGQn90NmRq9L4X0ScOsmP-YzdQxX=h0J+wC+aj+0+BuaNJg@mail.gmail.com>
 <CABDkGQmDfTXZ51F_YMaKaJ1tdGwxACaAJrV_u9CebiYq8L2qBg@mail.gmail.com>
 <CAE-UAvQ4nzffC_Gk8K5zxyhDTEuvnCNJai9zi2G9Ntx3p3_mZA@mail.gmail.com>
 <CABDkGQn0so6aapQW3ztvX9iEeJxcovK_s=3kf03CcCise4uxJg@mail.gmail.com>
 <4E91A071.8040303@ais.uni-bonn.de>
Message-ID: <20111009133820.GA31274@phare.normalesup.org>


> Don't know if this is a good argument but people might rather be
> googleing "python ski", which is easy
> to google.
> For this reason I am ambivalent between ski and skimage.

I'm more in favour of skimage (and having 'image' in the name of the
package), but if we want something short and easy to google, 'skim' might
be fun!

Emma 


From emmanuelle.gouillart at nsup.org  Sun Oct  9 09:41:05 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Sun, 9 Oct 2011 15:41:05 +0200
Subject: releasing & packaging vs. renaming
In-Reply-To: <20111009133820.GA31274@phare.normalesup.org>
References: <CABDkGQk9pvVtV=kUxTAgS5+UmqzCEnQ=TTJVwAug1aRYc_scxA@mail.gmail.com>
 <4E90BA36.60207@ais.uni-bonn.de>
 <20111008220729.GB31828@phare.normalesup.org>
 <CAEym_Hq3jCJOD19Zbnx=auAVNYbracXPUEJYqzWOkEh+_mHNNw@mail.gmail.com>
 <CABDkGQn90NmRq9L4X0ScOsmP-YzdQxX=h0J+wC+aj+0+BuaNJg@mail.gmail.com>
 <CABDkGQmDfTXZ51F_YMaKaJ1tdGwxACaAJrV_u9CebiYq8L2qBg@mail.gmail.com>
 <CAE-UAvQ4nzffC_Gk8K5zxyhDTEuvnCNJai9zi2G9Ntx3p3_mZA@mail.gmail.com>
 <CABDkGQn0so6aapQW3ztvX9iEeJxcovK_s=3kf03CcCise4uxJg@mail.gmail.com>
 <4E91A071.8040303@ais.uni-bonn.de>
 <20111009133820.GA31274@phare.normalesup.org>
Message-ID: <20111009134105.GB31274@phare.normalesup.org>

> I'm more in favour of skimage (and having 'image' in the name of the
> package), but if we want something short and easy to google, 'skim' might
> be fun!

Update: too bad, skim is already taken on PyPi...


From emmanuelle.gouillart at nsup.org  Sun Oct  9 10:53:39 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Sun, 9 Oct 2011 16:53:39 +0200
Subject: Challenge: Speed up seam carving example
In-Reply-To: <CABDkGQnwuYDOoQb9uWK6PUVvGLOKpz9zNE0T9eFqTPjE83_vOg@mail.gmail.com>
References: <CABDkGQnwuYDOoQb9uWK6PUVvGLOKpz9zNE0T9eFqTPjE83_vOg@mail.gmail.com>
Message-ID: <20111009145338.GC31274@phare.normalesup.org>

Hi,

cool stuff :-).

This is not a large improvement, but you can gain a little by removing
all pixels of a path at one time, by ravelling the array and using fancy
indexing. Something like

sx, sy = img.shape
inds = np.arange(img.size)
removed_inds = p + row_idx * sy
img = img.ravel()[np.setdiff1d(inds, removed_inds)]
img.shape = sx, sy - 1

Also, is it possible to compute at one time several shortest paths from
one side of the array to the other (using MCP), and removing several
paths during a single iteration? You might have problems when paths
intersect, because then you don't have the same number of pixels to
remove for each line, but you might choose a rule for such cases (e.g.
removing the pixel on this line that belongs to the next path that would
be removed) and maybe it won't be so bad... I don't know, I guess I
should have watched the video before giving my advice ;-)

Emma

On Sun, Oct 09, 2011 at 03:48:20AM -0700, St??????fan van der Walt wrote:
> Hi all,

> I have placed an example of seam carving here:

> https://github.com/stefanv/scikits.image-1/blob/seam_carving/doc/examples/plot_seam_carving.py

> The idea is super simple, but currently it's too slow.  I'm curious to
> see if anyone can improve its execution time?

> If you haven't seen seam carving before, take a look at the video link
> in the docstring.

> Regards
> St??????fan


From tsyu80 at gmail.com  Sun Oct  9 20:55:36 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Sun, 9 Oct 2011 20:55:36 -0400
Subject: releasing & packaging vs. renaming
In-Reply-To: <CABDkGQnubJieLvd6WYkCyowKrO0f+tzHY3MJF10n-xotuc3spg@mail.gmail.com>
References: <4E90BA36.60207@ais.uni-bonn.de>
	<20111008220729.GB31828@phare.normalesup.org>
	<CAEym_Hq3jCJOD19Zbnx=auAVNYbracXPUEJYqzWOkEh+_mHNNw@mail.gmail.com>
	<CABDkGQn90NmRq9L4X0ScOsmP-YzdQxX=h0J+wC+aj+0+BuaNJg@mail.gmail.com>
	<CABDkGQmDfTXZ51F_YMaKaJ1tdGwxACaAJrV_u9CebiYq8L2qBg@mail.gmail.com>
	<CAE-UAvQ4nzffC_Gk8K5zxyhDTEuvnCNJai9zi2G9Ntx3p3_mZA@mail.gmail.com>
	<CABDkGQn0so6aapQW3ztvX9iEeJxcovK_s=3kf03CcCise4uxJg@mail.gmail.com>
	<4E91A071.8040303@ais.uni-bonn.de>
	<20111009133820.GA31274@phare.normalesup.org>
	<CAEym_HquAw7qGRP6gjOrfyOed3joK19_CbP3x-ck+dximESaKw@mail.gmail.com>
	<20111009210242.GB13524@phare.normalesup.org>
	<CABDkGQnubJieLvd6WYkCyowKrO0f+tzHY3MJF10n-xotuc3spg@mail.gmail.com>
Message-ID: <CAEym_Hq6dACZMbZ5fHXsdst7Y-=gNR9MkxaN_Z3gyM8=qL_LBw@mail.gmail.com>

2011/10/9 St?fan van der Walt <stefan at sun.ac.za>

> On Sun, Oct 9, 2011 at 2:02 PM, Emmanuelle Gouillart
> <emmanuelle.gouillart at nsup.org> wrote:
> >
> >>    If we start putting more interfaces to code in the top level module
> (right
> >>    now, only functions from `util` are there) or automatically importing
> >>    submodules (e.g. `io` would be a good candidate), then
> adopting/promoting
> >>    the convention "import skimage as ski" would be nice (so the one
> import
> >>    would give me `ski.img_as_float` and `ski.io.imread`).
> >
> > + 1
>
> I propose that we make the 0.3 release today as planned, and then work
> in the coming week to bring out 0.4 with the rename.  0.4 will then be
> the first version in Debian.


release early, release often: +1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111009/265f6225/attachment.html>

From stefan at sun.ac.za  Mon Oct 10 01:47:02 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 9 Oct 2011 22:47:02 -0700
Subject: interpolation issue...
In-Reply-To: <20111009133350.2e64539e92a5251ff7c18b0f@terre-adelie.org>
References: <20111009133350.2e64539e92a5251ff7c18b0f@terre-adelie.org>
Message-ID: <CABDkGQmB7_Xy3hxXXB6UpuHMTLc+sEs88juJ0NpmCWhTygL-Ow@mail.gmail.com>

Hi J?r?me

2011/10/9 J?r?me Kieffer <google at terre-adelie.org>:
> First constraint: all signal in input has to appear in output:
> interpolation has to be done in "forwards" mode and can be done with 2D
> histogramming. Thanks to cython it is even 10x faster than the numpy
> implementation (0.5s for 4Mpix float64).

It's not entirely clear to me how this forward interpolation would
work.  Could you expand?

Regards
St?fan


From emmanuelle.gouillart at nsup.org  Sun Oct  9 17:02:42 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Sun, 9 Oct 2011 23:02:42 +0200
Subject: releasing & packaging vs. renaming
In-Reply-To: <CAEym_HquAw7qGRP6gjOrfyOed3joK19_CbP3x-ck+dximESaKw@mail.gmail.com>
References: <4E90BA36.60207@ais.uni-bonn.de>
 <20111008220729.GB31828@phare.normalesup.org>
 <CAEym_Hq3jCJOD19Zbnx=auAVNYbracXPUEJYqzWOkEh+_mHNNw@mail.gmail.com>
 <CABDkGQn90NmRq9L4X0ScOsmP-YzdQxX=h0J+wC+aj+0+BuaNJg@mail.gmail.com>
 <CABDkGQmDfTXZ51F_YMaKaJ1tdGwxACaAJrV_u9CebiYq8L2qBg@mail.gmail.com>
 <CAE-UAvQ4nzffC_Gk8K5zxyhDTEuvnCNJai9zi2G9Ntx3p3_mZA@mail.gmail.com>
 <CABDkGQn0so6aapQW3ztvX9iEeJxcovK_s=3kf03CcCise4uxJg@mail.gmail.com>
 <4E91A071.8040303@ais.uni-bonn.de>
 <20111009133820.GA31274@phare.normalesup.org>
 <CAEym_HquAw7qGRP6gjOrfyOed3joK19_CbP3x-ck+dximESaKw@mail.gmail.com>
Message-ID: <20111009210242.GB13524@phare.normalesup.org>


>    If we start putting more interfaces to code in the top level module (right
>    now, only functions from `util` are there) or automatically importing
>    submodules (e.g. `io` would be a good candidate), then adopting/promoting
>    the convention "import skimage as ski" would be nice (so the one import
>    would give me `ski.img_as_float` and `ski.io.imread`).

+ 1




From stefan at sun.ac.za  Mon Oct 10 06:58:56 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 10 Oct 2011 03:58:56 -0700
Subject: scikits-image 0.3 release
Message-ID: <CABDkGQkk3uAmZrsQ12rMjqbkm-LvvCzROP6VD0MJFNJe8C22=w@mail.gmail.com>

Announcement: scikits.image 0.3
===============================

After a brief (!) absence, we're back with a new and shiny version of
scikits.image, the image processing toolbox for SciPy.

This release runs under all major operating systems where
Python (>=2.6 or 3.x), NumPy and SciPy can be installed.

For more information, visit our website

  http://scikits-image.org

or the examples gallery at

   http://scikits-image.org/docs/0.3/auto_examples/

New Features
------------
- Shortest paths
- Total variation denoising
- Hough and probabilistic Hough transforms
- Radon transform with reconstruction
- Histogram of gradients
- Morphology, including watershed, connected components
- Faster homography transformations (rotations, zoom, etc.)
- Image dtype conversion routines
- Line drawing
- Better image collection handling
- Constant time median filter
- Edge detection (canny, sobel, etc.)
- IO: Freeimage, FITS, Qt and other image loaders; video support.
- SIFT feature loader
- Example data-sets

... as well as many bug fixes and minor updates.

Contributors for this release
-----------------------------
Martin Bergtholdt
Luis Pedro Coelho
Chris Colbert
Damian Eads
Dan Farmer
Emmanuelle Gouillart
Brian Holt
Pieter Holtzhausen
Thouis (Ray) Jones
Lee Kamentsky
Almar Klein
Kyle Mandli
Andreas Mueller
Neil Muller
Zachary Pincus
James Turner
Stefan van der Walt
Gael Varoquaux
Tony Yu


From stefan at sun.ac.za  Mon Oct 10 07:08:42 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 10 Oct 2011 04:08:42 -0700
Subject: A big thanks for 0.3!
Message-ID: <CABDkGQkp-em12cVYp1hEZq7fyTcZzFwKhe0Ax-ytoWdLCMyONg@mail.gmail.com>

Hi all,

To everyone who contributed to the 0.3 release, a big word of thanks!
We've hit a turning point: more and more people ask about the project,
notice the work that's being done, and--most importantly--use it.
This could not have happened without your valuable contributions.

We've gathered some good momentum; let's keep the ball rolling and
release 0.4 within the next few weeks, after doing the rename to
`skimage`.  There's also a lot of room for new narrative
documentation, although the examples gallery is already a wonderful
addition (thanks Emmanuelle and scikit-learn!):

http://scikits-image.org/docs/dev/auto_examples/

Keep up the good work!

St?fan


From bdholt1 at gmail.com  Mon Oct 10 09:20:45 2011
From: bdholt1 at gmail.com (Brian Holt)
Date: Mon, 10 Oct 2011 06:20:45 -0700 (PDT)
Subject: A big thanks for 0.3!
In-Reply-To: <CABDkGQkp-em12cVYp1hEZq7fyTcZzFwKhe0Ax-ytoWdLCMyONg@mail.gmail.com>
References: <CABDkGQkp-em12cVYp1hEZq7fyTcZzFwKhe0Ax-ytoWdLCMyONg@mail.gmail.com>
Message-ID: <7121876.3189.1318252846072.JavaMail.geo-discussion-forums@yqcs10>

Congratulations on a successful release!

I was just looking through http://scikits-image.org/docs/0.3/contribute.html to 
find out what else is in the pipeline and it seems like many of the tasks 
can already be ticked off.  

What are the next priorities for this project? 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111010/624cfbf8/attachment.html>

From emmanuelle.gouillart at nsup.org  Mon Oct 10 02:27:34 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Mon, 10 Oct 2011 08:27:34 +0200
Subject: releasing & packaging vs. renaming
In-Reply-To: <CABDkGQnubJieLvd6WYkCyowKrO0f+tzHY3MJF10n-xotuc3spg@mail.gmail.com>
References: <CAEym_Hq3jCJOD19Zbnx=auAVNYbracXPUEJYqzWOkEh+_mHNNw@mail.gmail.com>
 <CABDkGQn90NmRq9L4X0ScOsmP-YzdQxX=h0J+wC+aj+0+BuaNJg@mail.gmail.com>
 <CABDkGQmDfTXZ51F_YMaKaJ1tdGwxACaAJrV_u9CebiYq8L2qBg@mail.gmail.com>
 <CAE-UAvQ4nzffC_Gk8K5zxyhDTEuvnCNJai9zi2G9Ntx3p3_mZA@mail.gmail.com>
 <CABDkGQn0so6aapQW3ztvX9iEeJxcovK_s=3kf03CcCise4uxJg@mail.gmail.com>
 <4E91A071.8040303@ais.uni-bonn.de>
 <20111009133820.GA31274@phare.normalesup.org>
 <CAEym_HquAw7qGRP6gjOrfyOed3joK19_CbP3x-ck+dximESaKw@mail.gmail.com>
 <20111009210242.GB13524@phare.normalesup.org>
 <CABDkGQnubJieLvd6WYkCyowKrO0f+tzHY3MJF10n-xotuc3spg@mail.gmail.com>
Message-ID: <20111010062734.GA21165@phare.normalesup.org>

> I propose that we make the 0.3 release today as planned, and then work
> in the coming week to bring out 0.4 with the rename.  0.4 will then be
> the first version in Debian.

Sounds great!


From stefan at sun.ac.za  Mon Oct 10 16:12:20 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 10 Oct 2011 13:12:20 -0700
Subject: A big thanks for 0.3!
In-Reply-To: <7121876.3189.1318252846072.JavaMail.geo-discussion-forums@yqcs10>
References: <CABDkGQkp-em12cVYp1hEZq7fyTcZzFwKhe0Ax-ytoWdLCMyONg@mail.gmail.com>
 <7121876.3189.1318252846072.JavaMail.geo-discussion-forums@yqcs10>
Message-ID: <CABDkGQmXuCXCeu7BCEwH0fXD6O-4-1btw2KLxYPEGnmfPe2MhQ@mail.gmail.com>

On Mon, Oct 10, 2011 at 6:20 AM, Brian Holt <bdholt1 at gmail.com> wrote:
> I was just looking
> through?http://scikits-image.org/docs/0.3/contribute.html?to find out what
> else is in the pipeline and it seems like many of the tasks can already be
> ticked off.
>
> What are the next priorities for this project?

I see two main target audiences for the scikit: educators and
researchers (maybe industry practitioners form a third group, but
they've been quiet on the list so far!).

For education, we need to write more narrative documentation, build
more examples, and implement the algorithms that you'll find in a
standard image processing book, such as Gonzales &Woods.

For research, we want new and exciting algorithms, and great utilities
for augmenting results (e.g. the drawing library just started).
Examples of algorithms would include graph cut segmentation,
structural similarity measures, star features, etc.

On a more mundane front, we need to deal with the renaming and with
updating pull requests accordingly (the rename will probably break all
pending PRs?).  While the scikit can work under Python 3, I was sloppy
in not testing in under 3 before the release, so there are some minor
tweaks necessary to make the test suite pass.

I would love to hear any other suggestions... this is a community
effort, so in the end we all get to decide which way to go.

Cheers
St?fan


From stefan at sun.ac.za  Mon Oct 10 16:20:07 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 10 Oct 2011 13:20:07 -0700
Subject: A big thanks for 0.3!
In-Reply-To: <CAE-UAvQvBydr1OkS54qW=X9RA0HdgpQ49TRuNUfMceMYaksVpA@mail.gmail.com>
References: <CABDkGQkp-em12cVYp1hEZq7fyTcZzFwKhe0Ax-ytoWdLCMyONg@mail.gmail.com>
 <7121876.3189.1318252846072.JavaMail.geo-discussion-forums@yqcs10>
 <20111010184335.GA19194@phare.normalesup.org> <CAE-UAvQvBydr1OkS54qW=X9RA0HdgpQ49TRuNUfMceMYaksVpA@mail.gmail.com>
Message-ID: <CABDkGQmTZQFJz_xj0tjP2=0bMxvwu=g6kN7sXVh0=18ir-7j5g@mail.gmail.com>

Hi Nelle

On Mon, Oct 10, 2011 at 11:51 AM, Nelle Varoquaux
<nelle.varoquaux at gmail.com> wrote:
> I can do that, if it can wait until this week-end! I've used grep in the
> past for such tasks :)

Thanks, that'd be great!  Could you also investigate what happens to
our pull requests when we change the naming?  I have a feeling they
may not appreciate it.

The scikit-learn guys have both scikits.learn and sklearn subpackages,
but we'll stick to one and simply move from scikits.image to skimage
for the next release.

Other low hanging fruit would be to improve the documentation index:

http://scikits-image.org/docs/

(It's currently not themed along with the rest of the website)

Then there's also the compatibility table, where I want to list all
the functionality we provide:

http://scikits-image.org/docs/dev/coverage_table.html

At the moment it mainly contains MATLAB features.  I think that was a
mistake on my part; we should not follow MATLAB, but rather forge our
own exciting route ahead (playing catch-up is boring).

Lots more to be done, but I'll stop here :)

Regards
St?fan


From stefan at sun.ac.za  Mon Oct 10 16:53:03 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 10 Oct 2011 13:53:03 -0700
Subject: Challenge: Speed up seam carving example
In-Reply-To: <20111009145338.GC31274@phare.normalesup.org>
References: <CABDkGQnwuYDOoQb9uWK6PUVvGLOKpz9zNE0T9eFqTPjE83_vOg@mail.gmail.com>
 <20111009145338.GC31274@phare.normalesup.org>
Message-ID: <CABDkGQkPjMg_-NZHBXwXF4mHf-vfy+ya=6EZ0GnR=ma7sfUW0w@mail.gmail.com>

On Sun, Oct 9, 2011 at 7:53 AM, Emmanuelle Gouillart
<emmanuelle.gouillart at nsup.org> wrote:
> This is not a large improvement, but you can gain a little by removing
> all pixels of a path at one time, by ravelling the array and using fancy
> indexing. Something like
>
> sx, sy = img.shape
> inds = np.arange(img.size)
> removed_inds = p + row_idx * sy
> img = img.ravel()[np.setdiff1d(inds, removed_inds)]
> img.shape = sx, sy - 1

Nice idea, thanks!

> Also, is it possible to compute at one time several shortest paths from
> one side of the array to the other (using MCP), and removing several
> paths during a single iteration? You might have problems when paths
> intersect, because then you don't have the same number of pixels to
> remove for each line, but you might choose a rule for such cases (e.g.
> removing the pixel on this line that belongs to the next path that would
> be removed) and maybe it won't be so bad...

I also thought about this idea, but couldn't figure out how to solve
the intersecting lines without some for loop.  I don't mind writing it
in C, but that's not ideal for an example!

Also, I thought about just erasing lines from the edges and the image
at the same time, instead of re-computing the edge detection, but
that's not valid.

St?fan


From emmanuelle.gouillart at nsup.org  Mon Oct 10 07:56:51 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Mon, 10 Oct 2011 13:56:51 +0200
Subject: A big thanks for 0.3!
In-Reply-To: <CABDkGQkp-em12cVYp1hEZq7fyTcZzFwKhe0Ax-ytoWdLCMyONg@mail.gmail.com>
References: <CABDkGQkp-em12cVYp1hEZq7fyTcZzFwKhe0Ax-ytoWdLCMyONg@mail.gmail.com>
Message-ID: <20111010115651.GB21165@phare.normalesup.org>

A big thanks to you, St??????fan, for all your work and the energy that you
devoted to this release! As you say, let's keep up the good work, move
quickly to skimage, write a lot of documentation, and users and
developers will come naturally.

Cheers,
Emmanuelle

On Mon, Oct 10, 2011 at 04:08:42AM -0700, St??????fan van der Walt wrote:
> Hi all,

> To everyone who contributed to the 0.3 release, a big word of thanks!
> We've hit a turning point: more and more people ask about the project,
> notice the work that's being done, and--most importantly--use it.
> This could not have happened without your valuable contributions.

> We've gathered some good momentum; let's keep the ball rolling and
> release 0.4 within the next few weeks, after doing the rename to
> `skimage`.  There's also a lot of room for new narrative
> documentation, although the examples gallery is already a wonderful
> addition (thanks Emmanuelle and scikit-learn!):

> http://scikits-image.org/docs/dev/auto_examples/

> Keep up the good work!

> St??????fan


From stefan at sun.ac.za  Mon Oct 10 17:25:24 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 10 Oct 2011 14:25:24 -0700
Subject: Challenge: Speed up seam carving example
In-Reply-To: <CABDkGQnwuYDOoQb9uWK6PUVvGLOKpz9zNE0T9eFqTPjE83_vOg@mail.gmail.com>
References: <CABDkGQnwuYDOoQb9uWK6PUVvGLOKpz9zNE0T9eFqTPjE83_vOg@mail.gmail.com>
Message-ID: <CABDkGQk_TLrtMSqRKHBP9EWtujxGpZKTsX9jXP1z4zrn8UqpAw@mail.gmail.com>

2011/10/9 St?fan van der Walt <stefan at sun.ac.za>:
> Hi all,
>
> I have placed an example of seam carving here:
>
> https://github.com/stefanv/scikits.image-1/blob/seam_carving/doc/examples/plot_seam_carving.py

Does anybody have a better (copyright free) test image than the
cameraman we can use for this?  Something like two trees, or somesuch.
 If we simply scale the photo down to 256x256, the algorithm is fast
enough.

St?fan


From amueller at ais.uni-bonn.de  Mon Oct 10 14:08:48 2011
From: amueller at ais.uni-bonn.de (Andreas Mueller)
Date: Mon, 10 Oct 2011 20:08:48 +0200
Subject: A big thanks for 0.3!
In-Reply-To: <7121876.3189.1318252846072.JavaMail.geo-discussion-forums@yqcs10>
References: <CABDkGQkp-em12cVYp1hEZq7fyTcZzFwKhe0Ax-ytoWdLCMyONg@mail.gmail.com> <7121876.3189.1318252846072.JavaMail.geo-discussion-forums@yqcs10>
Message-ID: <4E9334B0.2050008@ais.uni-bonn.de>

On 10/10/2011 03:20 PM, Brian Holt wrote:
> Congratulations on a successful release!
>
> I was just looking through 
> http://scikits-image.org/docs/0.3/contribute.html to find out what 
> else is in the pipeline and it seems like many of the tasks can 
> already be ticked off.
>
> What are the next priorities for this project?
I think expanding the user guide should be a priority for the next release.
The examples are already a great step in this direction.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111010/eb205c71/attachment.html>

From emmanuelle.gouillart at nsup.org  Mon Oct 10 14:43:36 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Mon, 10 Oct 2011 20:43:36 +0200
Subject: A big thanks for 0.3!
In-Reply-To: <7121876.3189.1318252846072.JavaMail.geo-discussion-forums@yqcs10>
References: <CABDkGQkp-em12cVYp1hEZq7fyTcZzFwKhe0Ax-ytoWdLCMyONg@mail.gmail.com>
 <7121876.3189.1318252846072.JavaMail.geo-discussion-forums@yqcs10>
Message-ID: <20111010184335.GA19194@phare.normalesup.org>

On Mon, Oct 10, 2011 at 06:20:45AM -0700, Brian Holt wrote:
>    Congratulations on a successful release!

>    I was just looking
>    through??????[1]http://scikits-image.org/docs/0.3/contribute.html??????to find out
>    what else is in the pipeline and it seems like many of the tasks can
>    already be ticked off. ??????

>    What are the next priorities for this project???????

I agree with Andy: writing a lot of documentation (improving the
docstrings, writing examples for the gallery and writing the user guide)
seems a high priority to me. More documentation will also help developers
to know the package better, and to keep it coherent in the future
(avoiding code duplication, etc.)

In the short term, we also need to do the renaming to skimage. By the
way, would someone volunteer to do the (slightly tedious) renaming work?
As I brought back this issue, I reckon I could/should do it :-). But in
the unlikely case of someone having plenty of free time and being keen
on doing it, that'd be great ;-)

Cheers,
Emmanuelle


From nelle.varoquaux at gmail.com  Mon Oct 10 14:51:24 2011
From: nelle.varoquaux at gmail.com (Nelle Varoquaux)
Date: Mon, 10 Oct 2011 20:51:24 +0200
Subject: A big thanks for 0.3!
In-Reply-To: <20111010184335.GA19194@phare.normalesup.org>
References: <CABDkGQkp-em12cVYp1hEZq7fyTcZzFwKhe0Ax-ytoWdLCMyONg@mail.gmail.com>
	<7121876.3189.1318252846072.JavaMail.geo-discussion-forums@yqcs10>
	<20111010184335.GA19194@phare.normalesup.org>
Message-ID: <CAE-UAvQvBydr1OkS54qW=X9RA0HdgpQ49TRuNUfMceMYaksVpA@mail.gmail.com>

On 10 October 2011 20:43, Emmanuelle Gouillart <
emmanuelle.gouillart at nsup.org> wrote:

> On Mon, Oct 10, 2011 at 06:20:45AM -0700, Brian Holt wrote:
> >    Congratulations on a successful release!
>
> >    I was just looking
> >    through [1]http://scikits-image.org/docs/0.3/contribute.html to find
> out
> >    what else is in the pipeline and it seems like many of the tasks can
> >    already be ticked off.
>
> >    What are the next priorities for this project?
>
> I agree with Andy: writing a lot of documentation (improving the
> docstrings, writing examples for the gallery and writing the user guide)
> seems a high priority to me. More documentation will also help developers
> to know the package better, and to keep it coherent in the future
> (avoiding code duplication, etc.)
>
> In the short term, we also need to do the renaming to skimage. By the
> way, would someone volunteer to do the (slightly tedious) renaming work?
> As I brought back this issue, I reckon I could/should do it :-). But in
> the unlikely case of someone having plenty of free time and being keen
> on doing it, that'd be great ;-)
>

I can do that, if it can wait until this week-end! I've used grep in the
past for such tasks :)


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

From stefan at sun.ac.za  Tue Oct 11 11:52:15 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 11 Oct 2011 08:52:15 -0700
Subject: Alternative domain
Message-ID: <CABDkGQ=BLd0ifuJog7+9VYuw3=gkwuxva1t7XKUbJrzk_hO=Hg@mail.gmail.com>

Hi everyone,

A little gift for the 0.3 release :)

http://skimage.org

Regards
St?fan


From emmanuelle.gouillart at nsup.org  Wed Oct 12 04:09:26 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Wed, 12 Oct 2011 10:09:26 +0200
Subject: Alternative domain
In-Reply-To: <CABDkGQ=BLd0ifuJog7+9VYuw3=gkwuxva1t7XKUbJrzk_hO=Hg@mail.gmail.com>
References: <CABDkGQ=BLd0ifuJog7+9VYuw3=gkwuxva1t7XKUbJrzk_hO=Hg@mail.gmail.com>
Message-ID: <20111012080926.GA12615@phare.normalesup.org>

Thanks :-) We owe you a few beers for that!
Emmanuelle

On Tue, Oct 11, 2011 at 08:52:15AM -0700, St??????fan van der Walt wrote:
> Hi everyone,

> A little gift for the 0.3 release :)

> http://skimage.org

> Regards
> St??????fan


From jeanpatrick.pommier at gmail.com  Wed Oct 12 14:50:17 2011
From: jeanpatrick.pommier at gmail.com (jip)
Date: Wed, 12 Oct 2011 11:50:17 -0700 (PDT)
Subject: Alternative domain
In-Reply-To: <20111012080926.GA12615@phare.normalesup.org>
References: <CABDkGQ=BLd0ifuJog7+9VYuw3=gkwuxva1t7XKUbJrzk_hO=Hg@mail.gmail.com>
 <20111012080926.GA12615@phare.normalesup.org>
Message-ID: <31710012.245.1318445417677.JavaMail.geo-discussion-forums@vbmh5>

Thank you

Jean-Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111012/d300ef8c/attachment.html>

From stefan at sun.ac.za  Wed Oct 12 16:06:26 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 12 Oct 2011 13:06:26 -0700
Subject: 'heap_watershed.pxi' not found
In-Reply-To: <CAA-8Ld8W5DwFhTL8TtFTd48p8Ed8WcsCv_QivJeahqF+toGi_w@mail.gmail.com>
References: <CAA-8Ld8W5DwFhTL8TtFTd48p8Ed8WcsCv_QivJeahqF+toGi_w@mail.gmail.com>
Message-ID: <CABDkGQmx9b_6H9Qqtf9Xs2Uude=PyES1=yUkxyFjcWJTiXh99Q@mail.gmail.com>

On Wed, Oct 12, 2011 at 11:00 AM, Klonuo Umom <klonuo at gmail.com> wrote:
> congratulations?for your new release :)

Thanks!

> On Ubuntu I did: `sudo pip install scikits.image` and got this on two
> occasions of installing process:
> ========================================
> ? ? scikits/image/morphology/_watershed.pyx:26:0: 'heap_watershed.pxi' not
> found

This was missing from our manifest file--it's been fixed in the repo.

> ========================================
> Other then that it installed fine and I then tried to run test: `import
> scikits.image as si; si.test()`
> And got this:
> ========================================
> ValueError: Working directory
> /usr/local/lib/python2.7/dist-packages/scikits/image/__init__.pyc/.. not
> found, or not a directory
> ========================================
> Should I worry about it?

Aha, you found a bug :)  This should now be fixed.

Thanks for your feedback!

Cheers
St?fan


From stefan at sun.ac.za  Wed Oct 12 16:28:17 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 12 Oct 2011 13:28:17 -0700
Subject: Bug-fix 0.3.1
Message-ID: <CABDkGQm-eZ_ZtnwfM06YML+NuZsZjJhk=DMcCE_pDR9x9Gt2gw@mail.gmail.com>

Hi everyone,

Thanks to Christoph Gohlke, the package now runs smoothly on Windows
and Python 3.  I've uploaded a 0.3.1 bug-fix release to PyPi.

There's still one segfault in the OpenCV test suite.  If someone files
a bug report against it, I'll try to figure out what is going on, but
that subpackage has already been removed from 0.4dev (it was
deprecated in 0.3).

Regards
St?fan


From stefan at sun.ac.za  Wed Oct 12 18:45:28 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 12 Oct 2011 15:45:28 -0700
Subject: Bug-fix 0.3.1
In-Reply-To: <CAA-8Ld-o4KDu8JxE+yqCBziTL-LhcsEzW5ovBb5hOqnEVhzSKA@mail.gmail.com>
References: <CABDkGQm-eZ_ZtnwfM06YML+NuZsZjJhk=DMcCE_pDR9x9Gt2gw@mail.gmail.com>
 <CAA-8Ld-o4KDu8JxE+yqCBziTL-LhcsEzW5ovBb5hOqnEVhzSKA@mail.gmail.com>
Message-ID: <CABDkGQnFo2UhKhNu6zJe4nHaQ7tBBA=pka3xKWFOhEy5e3C-nw@mail.gmail.com>

Hi,

On Wed, Oct 12, 2011 at 2:53 PM, Klonuo Umom <klonuo at gmail.com> wrote:
> If of any interest here is output of my
> test:?http://pastebin.com/raw.php?i=DJ8JGtGU
> I have opencv 2.3.1 in /usr/local/lib/ with cv2.so for Python in
> dist-packages (on Ubuntu)

The tests look good. To get opencv working, you'll have to symlink
cv2.so to libcv.so.

Stefan


From klonuo at gmail.com  Wed Oct 12 14:00:54 2011
From: klonuo at gmail.com (Klonuo Umom)
Date: Wed, 12 Oct 2011 20:00:54 +0200
Subject: 'heap_watershed.pxi' not found
Message-ID: <CAA-8Ld8W5DwFhTL8TtFTd48p8Ed8WcsCv_QivJeahqF+toGi_w@mail.gmail.com>

Hi,
congratulations for your new release :)

On Ubuntu I did: `sudo pip install scikits.image` and got this on two
occasions of installing process:

========================================
    Error compiling Cython file:
    ------------------------------------------------------------
    ...
    DTYPE_INT32 = np.int32
    ctypedef np.int32_t DTYPE_INT32_t
    DTYPE_BOOL = np.bool
    ctypedef np.int8_t DTYPE_BOOL_t

    include "heap_watershed.pxi"
    ^
    ------------------------------------------------------------

    scikits/image/morphology/_watershed.pyx:26:0: 'heap_watershed.pxi' not
found
========================================

Other then that it installed fine and I then tried to run test: `import
scikits.image as si; si.test()`

And got this:

========================================
ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (47, 0))

ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (23, 0))

... <traceback part>


ValueError: Working directory
/usr/local/lib/python2.7/dist-packages/scikits/image/__init__.pyc/.. not
found, or not a directory
========================================

Should I worry about it?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111012/ee4f0acd/attachment.html>

From stefan at sun.ac.za  Thu Oct 13 02:03:22 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 12 Oct 2011 23:03:22 -0700
Subject: A big thanks for 0.3!
In-Reply-To: <CAE-UAvSwfixjLRHvySmK1RVfde90GZeNCoPBBW_1nJCxwjZpAQ@mail.gmail.com>
References: <CABDkGQkp-em12cVYp1hEZq7fyTcZzFwKhe0Ax-ytoWdLCMyONg@mail.gmail.com>
 <7121876.3189.1318252846072.JavaMail.geo-discussion-forums@yqcs10>
 <20111010184335.GA19194@phare.normalesup.org> <CAE-UAvQvBydr1OkS54qW=X9RA0HdgpQ49TRuNUfMceMYaksVpA@mail.gmail.com>
 <CABDkGQmTZQFJz_xj0tjP2=0bMxvwu=g6kN7sXVh0=18ir-7j5g@mail.gmail.com> <CAE-UAvSwfixjLRHvySmK1RVfde90GZeNCoPBBW_1nJCxwjZpAQ@mail.gmail.com>
Message-ID: <CABDkGQm2s81OuY+xDA9WKZatAWw-SCv+JfCmNgmJm8+4X0Pzfg@mail.gmail.com>

Hi Nelle

On Wed, Oct 12, 2011 at 10:30 PM, Nelle Varoquaux
<nelle.varoquaux at gmail.com> wrote:
> I think that the "merge" button disappears when github can't do the merge
> without manual intervention, so you have to do it "by hand", by fetching the
> code, and rebasing locally on your computer.
> Else, I don't think the pull request themselves are going to be affected. Of
> course, some of the patches will need some reworking.

I was concerned that the directory renaming from 'scikits/image' to
'skimage' would make trouble, but maybe Git can track that.

> I worked on that yesterday, and I almost have a patch running.
> Unfortunately, I seem to have a problem with the cython generated part, that
> I can't import (I can't find the *.so files manually as well). I have the
> same problem on master. I'm using cython 0.15.1.
> As soon as I've sorted that cython problem, I'll have a patch.

Can you elaborate on this problem?  Maybe we can help.

St?fan


From klonuo at gmail.com  Wed Oct 12 17:53:45 2011
From: klonuo at gmail.com (Klonuo Umom)
Date: Wed, 12 Oct 2011 23:53:45 +0200
Subject: Bug-fix 0.3.1
In-Reply-To: <CABDkGQm-eZ_ZtnwfM06YML+NuZsZjJhk=DMcCE_pDR9x9Gt2gw@mail.gmail.com>
References: <CABDkGQm-eZ_ZtnwfM06YML+NuZsZjJhk=DMcCE_pDR9x9Gt2gw@mail.gmail.com>
Message-ID: <CAA-8Ld-o4KDu8JxE+yqCBziTL-LhcsEzW5ovBb5hOqnEVhzSKA@mail.gmail.com>

Thanks for quick fix release.
If of any interest here is output of my test:
http://pastebin.com/raw.php?i=DJ8JGtGU

I have opencv 2.3.1 in /usr/local/lib/ with cv2.so for Python in
dist-packages (on Ubuntu)


Cheers

2011/10/12 St?fan van der Walt <stefan at sun.ac.za>

> Hi everyone,
>
> Thanks to Christoph Gohlke, the package now runs smoothly on Windows
> and Python 3.  I've uploaded a 0.3.1 bug-fix release to PyPi.
>
> There's still one segfault in the OpenCV test suite.  If someone files
> a bug report against it, I'll try to figure out what is going on, but
> that subpackage has already been removed from 0.4dev (it was
> deprecated in 0.3).
>
> Regards
> St?fan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111012/a935d27d/attachment.html>

From yager.neil at gmail.com  Thu Oct 13 09:45:09 2011
From: yager.neil at gmail.com (Neil Yager)
Date: Thu, 13 Oct 2011 06:45:09 -0700 (PDT)
Subject: Skeletonization
Message-ID: <7858a16a-052b-46e2-9069-33d43c9d2d6a@s14g2000vbj.googlegroups.com>

Hi everyone,

I really like the looks of this project and I'm hoping to add a few
things. However, I've never contributed to open source before, so I'll
definitely need some guidance along the way.

I've written some code to perform thinning on binary objects (i.e.
skeletonization). I've created a file that contains the logic, another
file with an example of usage, and one for unit tests.

A few questions:

1. Which package is best for this function? I've put it in the
'morphology' package, but I'm not sure it really belongs there because
I don't use any morphological operations. (note: this implementation
should be significantly faster than a morphology-based approach)

2. Unit test: I've written a few tests checking IO, but I can't see
how to write tests to check if it is creating the "correct" skeleton,
because there isn't really a "correct" skeleton. There's lots of
thinning algorithms out there, and they often give different results
(e.g. the medial axis transform gives different skeletons than this
implementation). How does one write useful unit tests in these cases?

3. github: I've never used git before, and I'm still getting used to
the terminology. What is the best way for someone to review my code?
I've now pushed it to a branch (neil_yager-skeletonize) in my repo
(NeilYager). If you were to test it out, would you fork it or pull it?

In general, any comments about coding style/efficiency/documentation/
etc would be very welcome.

I'm thinking about doing a thresholding algorithm next, followed by
perhaps gabor filters or gray-level co-occurance matrices (if no one
is already working on these).

Cheers,
Neil


From nelle.varoquaux at gmail.com  Thu Oct 13 01:30:39 2011
From: nelle.varoquaux at gmail.com (Nelle Varoquaux)
Date: Thu, 13 Oct 2011 07:30:39 +0200
Subject: A big thanks for 0.3!
In-Reply-To: <CABDkGQmTZQFJz_xj0tjP2=0bMxvwu=g6kN7sXVh0=18ir-7j5g@mail.gmail.com>
References: <CABDkGQkp-em12cVYp1hEZq7fyTcZzFwKhe0Ax-ytoWdLCMyONg@mail.gmail.com>
	<7121876.3189.1318252846072.JavaMail.geo-discussion-forums@yqcs10>
	<20111010184335.GA19194@phare.normalesup.org>
	<CAE-UAvQvBydr1OkS54qW=X9RA0HdgpQ49TRuNUfMceMYaksVpA@mail.gmail.com>
	<CABDkGQmTZQFJz_xj0tjP2=0bMxvwu=g6kN7sXVh0=18ir-7j5g@mail.gmail.com>
Message-ID: <CAE-UAvSwfixjLRHvySmK1RVfde90GZeNCoPBBW_1nJCxwjZpAQ@mail.gmail.com>

2011/10/10 St?fan van der Walt <stefan at sun.ac.za>

> Hi Nelle
>
> On Mon, Oct 10, 2011 at 11:51 AM, Nelle Varoquaux
> <nelle.varoquaux at gmail.com> wrote:
> > I can do that, if it can wait until this week-end! I've used grep in the
> > past for such tasks :)
>
> Thanks, that'd be great!  Could you also investigate what happens to
> our pull requests when we change the naming?  I have a feeling they
> may not appreciate it.
>

I think that the "merge" button disappears when github can't do the merge
without manual intervention, so you have to do it "by hand", by fetching the
code, and rebasing locally on your computer.
Else, I don't think the pull request themselves are going to be affected. Of
course, some of the patches will need some reworking.



> The scikit-learn guys have both scikits.learn and sklearn subpackages,
> but we'll stick to one and simply move from scikits.image to skimage
> for the next release.
>

I worked on that yesterday, and I almost have a patch running.
Unfortunately, I seem to have a problem with the cython generated part, that
I can't import (I can't find the *.so files manually as well). I have the
same problem on master. I'm using cython 0.15.1.
As soon as I've sorted that cython problem, I'll have a patch.


>
> Other low hanging fruit would be to improve the documentation index:
>
> http://scikits-image.org/docs/
>
> (It's currently not themed along with the rest of the website)
>
> Then there's also the compatibility table, where I want to list all
> the functionality we provide:
>
> http://scikits-image.org/docs/dev/coverage_table.html
>
> At the moment it mainly contains MATLAB features.  I think that was a
> mistake on my part; we should not follow MATLAB, but rather forge our
> own exciting route ahead (playing catch-up is boring).
>
> Lots more to be done, but I'll stop here :)
>
> Regards
> St?fan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111013/dce646ce/attachment.html>

From stefan at sun.ac.za  Thu Oct 13 13:32:40 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 13 Oct 2011 10:32:40 -0700
Subject: Skeletonization
In-Reply-To: <7858a16a-052b-46e2-9069-33d43c9d2d6a@s14g2000vbj.googlegroups.com>
References: <7858a16a-052b-46e2-9069-33d43c9d2d6a@s14g2000vbj.googlegroups.com>
Message-ID: <CABDkGQ=_Vmh+73YK+VOA9qBtpZOOur2gKCze22rstc77MWfkkw@mail.gmail.com>

Hi Neil,

On Thu, Oct 13, 2011 at 6:45 AM, Neil Yager <yager.neil at gmail.com> wrote:
> I really like the looks of this project and I'm hoping to add a few
> things. However, I've never contributed to open source before, so I'll
> definitely need some guidance along the way.

Welcome!  We look forward to your contributions.

> I've written some code to perform thinning on binary objects (i.e.
> skeletonization). I've created a file that contains the logic, another
> file with an example of usage, and one for unit tests.

It would be very interesting to compare what you've done with the
skeletonization code already in progress.  We tried to merge it just
before the release, but since it was part of another, massive patch,
it didn't make it.  Have a look here:

http://bit.ly/ski_skeleton

> 1. Which package is best for this function? I've put it in the
> 'morphology' package, but I'm not sure it really belongs there because
> I don't use any morphological operations. (note: this implementation
> should be significantly faster than a morphology-based approach)

We had the other patch in morphology too, so that's probably as good a
place as any.

> 2. Unit test: I've written a few tests checking IO, but I can't see
> how to write tests to check if it is creating the "correct" skeleton,
> because there isn't really a "correct" skeleton. There's lots of
> thinning algorithms out there, and they often give different results
> (e.g. the medial axis transform gives different skeletons than this
> implementation). How does one write useful unit tests in these cases?

In this case, it's quite reasonable to construct a test case, thin it
with your algorithm, and inspect the result to ensure that it is
correct.  You then store that result (e.g. in a .npz or .png file),
and use it in the comparison.

> 3. github: I've never used git before, and I'm still getting used to
> the terminology. What is the best way for someone to review my code?
> I've now pushed it to a branch (neil_yager-skeletonize) in my repo
> (NeilYager). If you were to test it out, would you fork it or pull it?

You previously made a successful pull request against the main
repository--that's exactly the right way to go.  We review the pull
requests on GitHub, and leave comments inline.

> I'm thinking about doing a thresholding algorithm next, followed by
> perhaps gabor filters or gray-level co-occurance matrices (if no one
> is already working on these).

I've got some old grey-level c.o.m. code here, if you want to have a look:

http://mentat.za.net/cgi-bin/hgwebdir.cgi/greycomatrix/

Adaptive / auto-thresholding should be fun!

Regards
St?fan


From tsyu80 at gmail.com  Thu Oct 13 13:41:30 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Thu, 13 Oct 2011 13:41:30 -0400
Subject: Skeletonization
In-Reply-To: <CABDkGQ=_Vmh+73YK+VOA9qBtpZOOur2gKCze22rstc77MWfkkw@mail.gmail.com>
References: <7858a16a-052b-46e2-9069-33d43c9d2d6a@s14g2000vbj.googlegroups.com>
	<CABDkGQ=_Vmh+73YK+VOA9qBtpZOOur2gKCze22rstc77MWfkkw@mail.gmail.com>
Message-ID: <CAEym_Hp1pYot+gG04LrTr+EAt6JSi727Ua1tSBHBxuE5oLpQ1A@mail.gmail.com>

2011/10/13 St?fan van der Walt <stefan at sun.ac.za>

> Hi Neil,
>
> On Thu, Oct 13, 2011 at 6:45 AM, Neil Yager <yager.neil at gmail.com> wrote:
> > I'm thinking about doing a thresholding algorithm next, followed by
> > perhaps gabor filters or gray-level co-occurance matrices (if no one
> > is already working on these).
>
> I've got some old grey-level c.o.m. code here, if you want to have a look:
>
> http://mentat.za.net/cgi-bin/hgwebdir.cgi/greycomatrix/
>
> Adaptive / auto-thresholding should be fun!
>
>
Also, cellprofiler has some thresholding code available:

https://svn.broadinstitute.org/CellProfiler/trunk/CellProfiler/cellprofiler/cpmath/threshold.py

The "contributions" page on the skimage website only mentions converting the
morphology and filter modules from cellprofiler, but I thinking everything
in the cpmath module is BSD licensed. I played around with the thresholding
code a bit: it was a bit slow and the interface was a little confusing, but
it may serve as a good starting point.

Best,
-Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111013/4c0fd801/attachment.html>

From stefan at sun.ac.za  Thu Oct 13 18:36:56 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 13 Oct 2011 15:36:56 -0700
Subject: Challenge: estimate a blurring kernel
Message-ID: <CABDkGQ=46QkjA+1_RqYAdcK6+CDiH+QF_iBxZ-jAO8eb=D0=Eg@mail.gmail.com>

Hi all,

At a recent Adobe MAX conference, people went crazy over their
deblurring demo [1].  I want it in scikits-image!  The authors were
even kind enough to leave us some clues as to how [2].

Who is up for the challenge?

St?fan

[1] http://www.youtube.com/watch?v=xxjiQoTp864t
[2] http://people.csail.mit.edu/sparis/publi/2011/cvpr_radon/Cho_11_Blur_Kernel_Estimation.pdf


From stefan at sun.ac.za  Thu Oct 13 20:38:39 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 13 Oct 2011 17:38:39 -0700
Subject: A bit of history and the bilateral filter
Message-ID: <CABDkGQm2bvJgprJ06vjcOL3SViq7FEep-zE3e1YwxY3YCXqjrw@mail.gmail.com>

Hi all

I just came across a paper in which the author uses the bilateral
filter.  This reminded me that we have an implementation lying around
somewhere; and it so happens that we discussed it in the very e-mail
that led to the formation of this scikit :)

http://comments.gmane.org/gmane.comp.python.numeric.general/28316

Strangely, though, the bilateral filter never made its way in!  If you
are new to scikits-image and would like to make a contribution, this
is an excellent opportunity:

https://github.com/stefanv/bilateral/tree/master/bilateral

Regards
St?fan


From tsyu80 at gmail.com  Thu Oct 13 23:06:46 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Thu, 13 Oct 2011 23:06:46 -0400
Subject: A bit of history and the bilateral filter
In-Reply-To: <CABDkGQm2bvJgprJ06vjcOL3SViq7FEep-zE3e1YwxY3YCXqjrw@mail.gmail.com>
References: <CABDkGQm2bvJgprJ06vjcOL3SViq7FEep-zE3e1YwxY3YCXqjrw@mail.gmail.com>
Message-ID: <CAEym_Hr4DCNdcF7JGX8RA6p7X5TonhYJi70-yO=5z=wrb3C9AA@mail.gmail.com>

2011/10/13 St?fan van der Walt <stefan at sun.ac.za>

> Hi all
>
> I just came across a paper in which the author uses the bilateral
> filter.  This reminded me that we have an implementation lying around
> somewhere; and it so happens that we discussed it in the very e-mail
> that led to the formation of this scikit :)
>
> http://comments.gmane.org/gmane.comp.python.numeric.general/28316
>
> Strangely, though, the bilateral filter never made its way in!  If you
> are new to scikits-image and would like to make a contribution, this
> is an excellent opportunity:
>
> https://github.com/stefanv/bilateral/tree/master/bilateral
>

Just for reference, there's also an implementation of the bilateral filter
in cellprofiler:

https://svn.broadinstitute.org/CellProfiler/trunk/CellProfiler/cellprofiler/cpmath/filter.py

I haven't really looked into either of these, so I'm in no way suggesting
that one is better than the other.

Best,
-Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111013/220ebb26/attachment.html>

From stefan at sun.ac.za  Fri Oct 14 04:53:54 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 14 Oct 2011 01:53:54 -0700
Subject: A bit of history and the bilateral filter
In-Reply-To: <CAEym_Hr4DCNdcF7JGX8RA6p7X5TonhYJi70-yO=5z=wrb3C9AA@mail.gmail.com>
References: <CABDkGQm2bvJgprJ06vjcOL3SViq7FEep-zE3e1YwxY3YCXqjrw@mail.gmail.com>
 <CAEym_Hr4DCNdcF7JGX8RA6p7X5TonhYJi70-yO=5z=wrb3C9AA@mail.gmail.com>
Message-ID: <CABDkGQnKctUHnRmwkfYww=OnsdTQf=M2WyJLKW1-9qZnqB2GEg@mail.gmail.com>

On Thu, Oct 13, 2011 at 8:06 PM, Tony Yu <tsyu80 at gmail.com> wrote:
> Just for reference, there's also an implementation of the bilateral filter
> in cellprofiler:
>
> https://svn.broadinstitute.org/CellProfiler/trunk/CellProfiler/cellprofiler/cpmath/filter.py
>
> I haven't really looked into either of these, so I'm in no way suggesting
> that one is better than the other.

The implementation I referred to is just a na?ve version, without any
optimisation; I know it can be done more efficiently.  We should
benchmark the two, at least.

Cheers
St?fan


From stefan at sun.ac.za  Fri Oct 14 05:16:46 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 14 Oct 2011 02:16:46 -0700
Subject: A bit of history and the bilateral filter
In-Reply-To: <4E97F9F9.40101@ais.uni-bonn.de>
References: <CABDkGQm2bvJgprJ06vjcOL3SViq7FEep-zE3e1YwxY3YCXqjrw@mail.gmail.com>
 <CAEym_Hr4DCNdcF7JGX8RA6p7X5TonhYJi70-yO=5z=wrb3C9AA@mail.gmail.com>
 <CABDkGQnKctUHnRmwkfYww=OnsdTQf=M2WyJLKW1-9qZnqB2GEg@mail.gmail.com> <4E97F9F9.40101@ais.uni-bonn.de>
Message-ID: <CABDkGQnkYJLH4qDfCYHhkKbbkqwY7wt98b66=LoxwsQG0bgt1A@mail.gmail.com>

Hey Andy

On Fri, Oct 14, 2011 at 1:59 AM, Andreas Mueller
<amueller at ais.uni-bonn.de> wrote:
> If any one wants to dig in to bilateral filtering, maybe they are also
> interested
> in non-local means. It is a somewhat generalized version that is quite near
> the state of the art and would also be pretty cool to have :)

It sounds like you're *just* the man for the job :)

Cheers
St?fan


From yager.neil at gmail.com  Fri Oct 14 08:12:01 2011
From: yager.neil at gmail.com (Neil Yager)
Date: Fri, 14 Oct 2011 05:12:01 -0700 (PDT)
Subject: Skeletonization
In-Reply-To: <CABDkGQ=_Vmh+73YK+VOA9qBtpZOOur2gKCze22rstc77MWfkkw@mail.gmail.com>
References: <7858a16a-052b-46e2-9069-33d43c9d2d6a@s14g2000vbj.googlegroups.com>
 <CABDkGQ=_Vmh+73YK+VOA9qBtpZOOur2gKCze22rstc77MWfkkw@mail.gmail.com>
Message-ID: <57ad6f9b-a015-4876-8406-b6c8d8ea6f3f@f5g2000vbz.googlegroups.com>

>
> It would be very interesting to compare what you've done with the
> skeletonization code already in progress. ?We tried to merge it just
> before the release, but since it was part of another, massive patch,
> it didn't make it. ?Have a look here:
>
> http://bit.ly/ski_skeleton
>

Interesting - that's a very nice implementation. It's actually faster
than mine. However, it's tough to do a direct comparison because they
are doing different things. The existing code is closer to a medial
axis transform, while my implementation is a more generic thinning
algorithm. What you prefer will depend on the application. I've
included a document imaging example that is a black and white image of
text characters (it is one of the unit tests). The existing code
creates lots of spurs and wiggly lines, while my code creates smoother
output, which is better for OCR. However, I'm sure there are
applications where the opposite is true. There's a case to be made for
including both.

Once again, any feedback is welcome.

Neil



From amueller at ais.uni-bonn.de  Fri Oct 14 04:59:37 2011
From: amueller at ais.uni-bonn.de (Andreas Mueller)
Date: Fri, 14 Oct 2011 10:59:37 +0200
Subject: A bit of history and the bilateral filter
In-Reply-To: <CABDkGQnKctUHnRmwkfYww=OnsdTQf=M2WyJLKW1-9qZnqB2GEg@mail.gmail.com>
References: <CABDkGQm2bvJgprJ06vjcOL3SViq7FEep-zE3e1YwxY3YCXqjrw@mail.gmail.com> <CAEym_Hr4DCNdcF7JGX8RA6p7X5TonhYJi70-yO=5z=wrb3C9AA@mail.gmail.com> <CABDkGQnKctUHnRmwkfYww=OnsdTQf=M2WyJLKW1-9qZnqB2GEg@mail.gmail.com>
Message-ID: <4E97F9F9.40101@ais.uni-bonn.de>

Am 14.10.2011 10:53, schrieb St??????fan van der Walt:
> On Thu, Oct 13, 2011 at 8:06 PM, Tony Yu<tsyu80 at gmail.com>  wrote:
>> Just for reference, there's also an implementation of the bilateral filter
>> in cellprofiler:
>>
>> https://svn.broadinstitute.org/CellProfiler/trunk/CellProfiler/cellprofiler/cpmath/filter.py
>>
>> I haven't really looked into either of these, so I'm in no way suggesting
>> that one is better than the other.
> The implementation I referred to is just a na??????ve version, without any
> optimisation; I know it can be done more efficiently.  We should
> benchmark the two, at least.
>
> Cheers
> St??????fan
If any one wants to dig in to bilateral filtering, maybe they are also 
interested
in non-local means. 
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.103.9157&rep=rep1&type=pdf> 
It is a somewhat generalized version that is quite near
the state of the art and would also be pretty cool to have :)

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

From stefan at sun.ac.za  Fri Oct 14 14:55:50 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 14 Oct 2011 11:55:50 -0700
Subject: How to construct a compare view on GitHub
Message-ID: <CABDkGQ=2i14u6Thb0EaJX+fiwP5cdHAPNEqMmArUCN3GsvqrJg@mail.gmail.com>

Hi all,

Neil's question earlier this week on how to best get your code
reviewed, reminded me that GitHub has this great thing called a
compare view.

2011/10/13 St?fan van der Walt <stefan at sun.ac.za>:
>> 3. github: I've never used git before, and I'm still getting used to
>> the terminology. What is the best way for someone to review my code?
>> I've now pushed it to a branch (neil_yager-skeletonize) in my repo
>> (NeilYager). If you were to test it out, would you fork it or pull it?

If you want someone to review code that you think is ready to be
included in the scikit, then do a PR (a pull request signals: let's
merge this!).  If, however, you just want a review, you can just make
changes on a branch and then do a compare view on GitHub and send the
link to the mailing list.

To construct a compare view, go to your repository, then to the branch
list, and click "compare" next to your feature branch (see the first
attached screenshot).  For example, here's the compare view between
the debian and master branch of the main repo:

https://github.com/scikits-image/scikits.image/compare/master...debian

Now, it often happens that you rebase one of your feature branches on
the master branch of the main repo, or that your own repository's
master branch falls behind.  In this case, the compare view may
include a bunch of spurious commits.  Fortunately, GitHub now allows
you to compare your changes against another repository.  In the
compare view, click on the "master" button, and in the pop-up box type
"scikits-image:master" (see screenshot 2). This gives you something
like:

https://github.com/stefanv/scikits.image-1/compare/scikits-image:master...emmanuelle_cellprofiler

Hope that's useful!
St?fan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compare_1.png
Type: image/png
Size: 80156 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111014/5c98d4fc/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compare_2.png
Type: image/png
Size: 62618 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111014/5c98d4fc/attachment-0001.png>

From stefan at sun.ac.za  Fri Oct 14 15:00:40 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 14 Oct 2011 12:00:40 -0700
Subject: Skeletonization
In-Reply-To: <57ad6f9b-a015-4876-8406-b6c8d8ea6f3f@f5g2000vbz.googlegroups.com>
References: <7858a16a-052b-46e2-9069-33d43c9d2d6a@s14g2000vbj.googlegroups.com>
 <CABDkGQ=_Vmh+73YK+VOA9qBtpZOOur2gKCze22rstc77MWfkkw@mail.gmail.com> <57ad6f9b-a015-4876-8406-b6c8d8ea6f3f@f5g2000vbz.googlegroups.com>
Message-ID: <CABDkGQkQO78ahygcf1+UQdHRy+6YzB6uAo+49VyWGE-C5Oonmw@mail.gmail.com>

Hi Neil

On Fri, Oct 14, 2011 at 5:12 AM, Neil Yager <yager.neil at gmail.com> wrote:
> Interesting - that's a very nice implementation. It's actually faster
> than mine. However, it's tough to do a direct comparison because they
> are doing different things. The existing code is closer to a medial
> axis transform, while my implementation is a more generic thinning
> algorithm. What you prefer will depend on the application. I've
> included a document imaging example that is a black and white image of
> text characters (it is one of the unit tests). The existing code
> creates lots of spurs and wiggly lines, while my code creates smoother
> output, which is better for OCR. However, I'm sure there are
> applications where the opposite is true. There's a case to be made for
> including both.

Could you maybe show us the output of some examples using both
algorithms?  It would be nice to do a first round of visual comparison
on some handwriting (text) and maybe something like the bone example
in Gonzales & Woods:

http://www.imageprocessingplace.com/DIP-3E/dip3e_book_images_downloads.htm
(Chapter 11, image "leg_bone")

Regards
St?fan


From stefan at sun.ac.za  Fri Oct 14 16:10:43 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 14 Oct 2011 13:10:43 -0700
Subject: Skeletonization
In-Reply-To: <CABDkGQkQO78ahygcf1+UQdHRy+6YzB6uAo+49VyWGE-C5Oonmw@mail.gmail.com>
References: <7858a16a-052b-46e2-9069-33d43c9d2d6a@s14g2000vbj.googlegroups.com>
 <CABDkGQ=_Vmh+73YK+VOA9qBtpZOOur2gKCze22rstc77MWfkkw@mail.gmail.com>
 <57ad6f9b-a015-4876-8406-b6c8d8ea6f3f@f5g2000vbz.googlegroups.com> <CABDkGQkQO78ahygcf1+UQdHRy+6YzB6uAo+49VyWGE-C5Oonmw@mail.gmail.com>
Message-ID: <CABDkGQmp9tbsfdW4ffFdEgCGx419s0M02t39XtAnq+fG3k3srw@mail.gmail.com>

2011/10/14 St?fan van der Walt <stefan at sun.ac.za>:
> Could you maybe show us the output of some examples using both
> algorithms? ?It would be nice to do a first round of visual comparison
> on some handwriting (text) and maybe something like the bone example
> in Gonzales & Woods:
>
> http://www.imageprocessingplace.com/DIP-3E/dip3e_book_images_downloads.htm
> (Chapter 11, image "leg_bone")

Here are those comparisons:

http://mentat.za.net/refer/skel1.png
http://mentat.za.net/refer/skel2.png

Looks good!

St?fan


From stefan at sun.ac.za  Fri Oct 14 18:20:36 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 14 Oct 2011 15:20:36 -0700
Subject: Skeletonization
In-Reply-To: <20111014220743.GD27939@phare.normalesup.org>
References: <7858a16a-052b-46e2-9069-33d43c9d2d6a@s14g2000vbj.googlegroups.com>
 <CABDkGQ=_Vmh+73YK+VOA9qBtpZOOur2gKCze22rstc77MWfkkw@mail.gmail.com>
 <57ad6f9b-a015-4876-8406-b6c8d8ea6f3f@f5g2000vbz.googlegroups.com>
 <CABDkGQkQO78ahygcf1+UQdHRy+6YzB6uAo+49VyWGE-C5Oonmw@mail.gmail.com>
 <CABDkGQmp9tbsfdW4ffFdEgCGx419s0M02t39XtAnq+fG3k3srw@mail.gmail.com> <20111014220743.GD27939@phare.normalesup.org>
Message-ID: <CABDkGQ=55huHAbO9Tp-maJmOiRFhiDFCN9U5YTd7bvbSUYXZjQ@mail.gmail.com>

On Fri, Oct 14, 2011 at 3:07 PM, Emmanuelle Gouillart
<emmanuelle.gouillart at nsup.org> wrote:
>> > http://www.imageprocessingplace.com/DIP-3E/dip3e_book_images_downloads.htm
>> > (Chapter 11, image "leg_bone")
>
>> Here are those comparisons:
>
>> http://mentat.za.net/refer/skel1.png
>> http://mentat.za.net/refer/skel2.png
>
> I only see one output for each image: which one of the skeletonization
> algorithms did you use?

I was having lunch just now when I realised I only did half my
homework!  This is Neil's version.  Maybe someone will volunteer to do
the other half.

Thanks
St?fan


From yager.neil at gmail.com  Sat Oct 15 02:30:30 2011
From: yager.neil at gmail.com (Neil Yager)
Date: Fri, 14 Oct 2011 23:30:30 -0700 (PDT)
Subject: Challenge: estimate a blurring kernel
In-Reply-To: <CABDkGQ=46QkjA+1_RqYAdcK6+CDiH+QF_iBxZ-jAO8eb=D0=Eg@mail.gmail.com>
References: <CABDkGQ=46QkjA+1_RqYAdcK6+CDiH+QF_iBxZ-jAO8eb=D0=Eg@mail.gmail.com>
Message-ID: <55cedf20-b275-4c64-8fa8-6d98e6ca4430@v8g2000vbe.googlegroups.com>

The paper looks good, and I might take a look if I find the time.
However, you have to keep in mind that this approach will only work
when the point spread function is the same throughout the image. There
are sources of blur where this will not work, such as viewing dynamic
scenes. However, it should work well for camera shake during exposure.
If only cameras stored accelerometer data in the image's meta-data
which you could use to derive an initial estimate...

Neil

On Oct 13, 11:36?pm, St?fan van der Walt <ste... at sun.ac.za> wrote:
> Hi all,
>
> At a recent Adobe MAX conference, people went crazy over their
> deblurring demo [1]. ?I want it in scikits-image! ?The authors were
> even kind enough to leave us some clues as to how [2].
>
> Who is up for the challenge?
>
> St?fan
>
> [1]http://www.youtube.com/watch?v=xxjiQoTp864t
> [2]http://people.csail.mit.edu/sparis/publi/2011/cvpr_radon/Cho_11_Blur_...


From yager.neil at gmail.com  Sat Oct 15 02:46:40 2011
From: yager.neil at gmail.com (Neil Yager)
Date: Fri, 14 Oct 2011 23:46:40 -0700 (PDT)
Subject: Skeletonization
In-Reply-To: <CABDkGQ=55huHAbO9Tp-maJmOiRFhiDFCN9U5YTd7bvbSUYXZjQ@mail.gmail.com>
References: <7858a16a-052b-46e2-9069-33d43c9d2d6a@s14g2000vbj.googlegroups.com>
 <CABDkGQ=_Vmh+73YK+VOA9qBtpZOOur2gKCze22rstc77MWfkkw@mail.gmail.com>
 <57ad6f9b-a015-4876-8406-b6c8d8ea6f3f@f5g2000vbz.googlegroups.com>
 <CABDkGQkQO78ahygcf1+UQdHRy+6YzB6uAo+49VyWGE-C5Oonmw@mail.gmail.com>
 <CABDkGQmp9tbsfdW4ffFdEgCGx419s0M02t39XtAnq+fG3k3srw@mail.gmail.com>
 <20111014220743.GD27939@phare.normalesup.org> <CABDkGQ=55huHAbO9Tp-maJmOiRFhiDFCN9U5YTd7bvbSUYXZjQ@mail.gmail.com>
Message-ID: <4f0cebf0-62a1-4a8b-b524-40096610e1d0@q12g2000yqe.googlegroups.com>

Here are the outputs of the existing code for those examples:

http://www.fjolad.com/ngy/img/leg_existing.png
http://www.fjolad.com/ngy/img/text_existing.png

Take note of the squiggles in the text example.

A simple way to illustrate the difference is this example:

http://www.fjolad.com/ngy/img/square_example.png

As you can see, the results are very different. Once again, there are
situations where both are useful. The former keeps an indication of
size, while the latter keeps only topology.

Neil


From emmanuelle.gouillart at nsup.org  Fri Oct 14 17:51:22 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Fri, 14 Oct 2011 23:51:22 +0200
Subject: A bit of history and the bilateral filter
In-Reply-To: <4E97F9F9.40101@ais.uni-bonn.de>
References: <CABDkGQm2bvJgprJ06vjcOL3SViq7FEep-zE3e1YwxY3YCXqjrw@mail.gmail.com>
 <CAEym_Hr4DCNdcF7JGX8RA6p7X5TonhYJi70-yO=5z=wrb3C9AA@mail.gmail.com>
 <CABDkGQnKctUHnRmwkfYww=OnsdTQf=M2WyJLKW1-9qZnqB2GEg@mail.gmail.com>
 <4E97F9F9.40101@ais.uni-bonn.de>
Message-ID: <20111014215122.GB27939@phare.normalesup.org>

Hi Andy,

On Fri, Oct 14, 2011 at 10:59:37AM +0200, Andreas Mueller wrote:
>    If any one wants to dig in to bilateral filtering, maybe they are also
>    interested
>    in [3]non-local means. It is a somewhat generalized version that is quite
>    near
>    the state of the art and would also be pretty cool to have :)

I do have an implementation of the non-local means denoising algorithm
(written in C for 3-D arrays only, and not a very clean implementation!),
because I use it heavily for my research. It is indeed a very good
denoising method when ones want to preserve textures (and not only
edges). Some good examples on
http://www.ipol.im/pub/algo/bcm_non_local_means_denoising/ The basic idea
is to average small patches of the image only with similar patches, that
look the same.  

However, I'm afraid there is a European patent on this algorithm :-( (A.
Buades, B. Coll, J.M. Morel "Image data processing method by reducing
image noise, and camera integrating means for implementing said method",
EP Patent 1,749,278 (Feb. 7), 2007.) so I don't think we can include it
in the scikit...

Nevertheless, there is another algorithm with a related idea that has
recently been implemented in the scikit learn: it's based on the use of
dictionary learning for denoising. The idea is to learn a dictionary of
relevant patches to describe an image, then to try to find an
approximate sparse decomposition of patches of the image onto this basis
of patches. The article is Mairal, J.; Bach, F.; Ponce, J.; Sapiro, G. &
Zisserman, A. Non-local sparse models for image restoration Computer
Vision, 2009 IEEE 12th International Conference on, 2009, 2272-2279. And
there is an example on
http://scikit-learn.sourceforge.net/stable/auto_examples/decomposition/plot_image_denoising.html#example-decomposition-plot-image-denoising-py

Cheers,
Emmanuelle


From yager.neil at gmail.com  Sat Oct 15 02:53:57 2011
From: yager.neil at gmail.com (Neil Yager)
Date: Fri, 14 Oct 2011 23:53:57 -0700 (PDT)
Subject: Skeletonization
In-Reply-To: <4f0cebf0-62a1-4a8b-b524-40096610e1d0@q12g2000yqe.googlegroups.com>
References: <7858a16a-052b-46e2-9069-33d43c9d2d6a@s14g2000vbj.googlegroups.com>
 <CABDkGQ=_Vmh+73YK+VOA9qBtpZOOur2gKCze22rstc77MWfkkw@mail.gmail.com>
 <57ad6f9b-a015-4876-8406-b6c8d8ea6f3f@f5g2000vbz.googlegroups.com>
 <CABDkGQkQO78ahygcf1+UQdHRy+6YzB6uAo+49VyWGE-C5Oonmw@mail.gmail.com>
 <CABDkGQmp9tbsfdW4ffFdEgCGx419s0M02t39XtAnq+fG3k3srw@mail.gmail.com>
 <20111014220743.GD27939@phare.normalesup.org> <CABDkGQ=55huHAbO9Tp-maJmOiRFhiDFCN9U5YTd7bvbSUYXZjQ@mail.gmail.com>
 <4f0cebf0-62a1-4a8b-b524-40096610e1d0@q12g2000yqe.googlegroups.com>
Message-ID: <bae5c783-1e0a-4c65-b95f-ac97f207cb7d@t10g2000yqd.googlegroups.com>


> while the latter keeps only topology.

Actually, on second thought, that's only true for this extreme example
- both methods generally reflect size. I think you see what I mean
though.

Neil


From emmanuelle.gouillart at nsup.org  Fri Oct 14 17:58:56 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Fri, 14 Oct 2011 23:58:56 +0200
Subject: How to construct a compare view on GitHub
In-Reply-To: <CABDkGQ=2i14u6Thb0EaJX+fiwP5cdHAPNEqMmArUCN3GsvqrJg@mail.gmail.com>
References: <CABDkGQ=2i14u6Thb0EaJX+fiwP5cdHAPNEqMmArUCN3GsvqrJg@mail.gmail.com>
Message-ID: <20111014215856.GC27939@phare.normalesup.org>

Thanks, that's very useful!
Emmanuelle

On Fri, Oct 14, 2011 at 11:55:50AM -0700, St??????fan van der Walt wrote:
> Hi all,

> Neil's question earlier this week on how to best get your code
> reviewed, reminded me that GitHub has this great thing called a
> compare view.

> 2011/10/13 St??????fan van der Walt <stefan at sun.ac.za>:
> >> 3. github: I've never used git before, and I'm still getting used to
> >> the terminology. What is the best way for someone to review my code?
> >> I've now pushed it to a branch (neil_yager-skeletonize) in my repo
> >> (NeilYager). If you were to test it out, would you fork it or pull it?

> If you want someone to review code that you think is ready to be
> included in the scikit, then do a PR (a pull request signals: let's
> merge this!).  If, however, you just want a review, you can just make
> changes on a branch and then do a compare view on GitHub and send the
> link to the mailing list.

> To construct a compare view, go to your repository, then to the branch
> list, and click "compare" next to your feature branch (see the first
> attached screenshot).  For example, here's the compare view between
> the debian and master branch of the main repo:

> https://github.com/scikits-image/scikits.image/compare/master...debian

> Now, it often happens that you rebase one of your feature branches on
> the master branch of the main repo, or that your own repository's
> master branch falls behind.  In this case, the compare view may
> include a bunch of spurious commits.  Fortunately, GitHub now allows
> you to compare your changes against another repository.  In the
> compare view, click on the "master" button, and in the pop-up box type
> "scikits-image:master" (see screenshot 2). This gives you something
> like:

> https://github.com/stefanv/scikits.image-1/compare/scikits-image:master...emmanuelle_cellprofiler

> Hope that's useful!
> St??????fan





From emmanuelle.gouillart at nsup.org  Fri Oct 14 18:07:43 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Sat, 15 Oct 2011 00:07:43 +0200
Subject: Skeletonization
In-Reply-To: <CABDkGQmp9tbsfdW4ffFdEgCGx419s0M02t39XtAnq+fG3k3srw@mail.gmail.com>
References: <7858a16a-052b-46e2-9069-33d43c9d2d6a@s14g2000vbj.googlegroups.com>
 <CABDkGQ=_Vmh+73YK+VOA9qBtpZOOur2gKCze22rstc77MWfkkw@mail.gmail.com>
 <57ad6f9b-a015-4876-8406-b6c8d8ea6f3f@f5g2000vbz.googlegroups.com>
 <CABDkGQkQO78ahygcf1+UQdHRy+6YzB6uAo+49VyWGE-C5Oonmw@mail.gmail.com>
 <CABDkGQmp9tbsfdW4ffFdEgCGx419s0M02t39XtAnq+fG3k3srw@mail.gmail.com>
Message-ID: <20111014220743.GD27939@phare.normalesup.org>

On Fri, Oct 14, 2011 at 01:10:43PM -0700, St??????fan van der Walt wrote:
> 2011/10/14 St??????fan van der Walt <stefan at sun.ac.za>:
> > Could you maybe show us the output of some examples using both
> > algorithms? ??????It would be nice to do a first round of visual comparison
> > on some handwriting (text) and maybe something like the bone example
> > in Gonzales & Woods:

> > http://www.imageprocessingplace.com/DIP-3E/dip3e_book_images_downloads.htm
> > (Chapter 11, image "leg_bone")

> Here are those comparisons:

> http://mentat.za.net/refer/skel1.png
> http://mentat.za.net/refer/skel2.png

I only see one output for each image: which one of the skeletonization
algorithms did you use?

Emma


From tsyu80 at gmail.com  Sat Oct 15 04:58:40 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Sat, 15 Oct 2011 04:58:40 -0400
Subject: Pull request: morphology fix
Message-ID: <CAEym_HqFgCWksnMHqRC7Y-Fs8TBnE4=OmR5rZzZaXq8LPcpQNQ@mail.gmail.com>

I just submitted a pull request for a somewhat-subtle bug with some
morphology operations:

https://github.com/scikits-image/scikits.image/pull/62

Overly detailed explanation:

Using a structuring element with one-or-both sides being even-numbered gives
buggy output for morphological open/close and white/black tophat operations.
These issues arise because even-numbered structuring elements (selems)
aren't centered on a pixel. The dilate and erode operations are (correctly)
defined so that they are symmetric (dilation on a white feature is exactly
the opposite of erosion on an equivalent black feature). When chaining them
(e.g. open() = dilate(erode())), however, this symmetry ends up shifting
features. To fix this, one of the operations should be shifted. For example,
if erosion is done with the selem shifted slightly to the lower-right, the
dilation operation should shift the selem to the upper-left. This change
prevents features from being shifted.

The open/close operations aren't that bad: they just shift features. But,
when calling white/black tophat operations, the shifting can lead to
over/underflow of pixels. I've attached examples of the lena image after
calling white tophat, both before and after the fix. The underflow should be
apparent in the first image.

Best,
-Tony


Example code:

import os
import numpy as np
import matplotlib.pyplot as plt

from scikits.image import data_dir
from scikits.image.morphology import *

lena = np.load(os.path.join(data_dir, 'lena_GRAY_U8.npy'))

plt.imshow(greyscale_white_top_hat(lena, square(4)))
plt.show()
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111015/6c89f86d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: white_tophat.png
Type: image/png
Size: 244334 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111015/6c89f86d/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: white_tophat_fixed.png
Type: image/png
Size: 134549 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111015/6c89f86d/attachment-0001.png>

From stefan at sun.ac.za  Sat Oct 15 17:16:26 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sat, 15 Oct 2011 14:16:26 -0700
Subject: Renaming scikits.image to skimage
In-Reply-To: <CAE-UAvSq_2nCh1Cr75EqhhpqBAV45nxL32fBoe-Zoz72-A9Eeg@mail.gmail.com>
References: <CAE-UAvSq_2nCh1Cr75EqhhpqBAV45nxL32fBoe-Zoz72-A9Eeg@mail.gmail.com>
Message-ID: <CABDkGQnSWwJPq3pfty89bBkHZs1dyPCpcbVcnY_C8YYz8yPJVg@mail.gmail.com>

Hi Nelle

On Sat, Oct 15, 2011 at 9:21 AM, Nelle Varoquaux
<nelle.varoquaux at gmail.com> wrote:
> I've worked on renaming scikits.image to skimage. Unfortunately, I have one

Thanks for your hard work; this looks great.

Do you think we should rename the entire repo as well?  I.e.

github.com/scikits-image/skimage.git

?

Regards
St?fan


From tsyu80 at gmail.com  Sat Oct 15 16:17:12 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Sat, 15 Oct 2011 16:17:12 -0400
Subject: Renaming scikits.image to skimage
In-Reply-To: <CAE-UAvSq_2nCh1Cr75EqhhpqBAV45nxL32fBoe-Zoz72-A9Eeg@mail.gmail.com>
References: <CAE-UAvSq_2nCh1Cr75EqhhpqBAV45nxL32fBoe-Zoz72-A9Eeg@mail.gmail.com>
Message-ID: <CAEym_HqVxr2mTiUKODB6zn5w9xWsPVMU7TGn91Gaf3SS0K49OA@mail.gmail.com>

On Sat, Oct 15, 2011 at 12:21 PM, Nelle Varoquaux <nelle.varoquaux at gmail.com
> wrote:

> Hi all,
>
> I've worked on renaming scikits.image to skimage. Unfortunately, I have one
> test failing. I have no clue how to fix that, and would appreciate some help
> on that.
> You can have a look at the patch at :
> https://github.com/NelleV/scikits.image/compare/master...skimage
>
> I'm using numpy 1.6.1 and cython 0.15.1
>
> ======================================================================
> ERROR: test_project.test_homography
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File
> "/home/nelle/Projets/skimage/env/lib/python2.6/site-packages/nose-1.1.2-py2.6.egg/nose/case.py",
> line 197, in runTest
>     self.test(*self.arg)
>   File
> "/home/nelle/Projets/skimage/skimage/transform/tests/test_project.py", line
> 23, in test_homography
>     x90 = homography(x, M, order=1)
>   File "/home/nelle/Projets/skimage/skimage/transform/project.py", line
> 101, in homography
>     mode=mode, order=order, cval=cval)
>   File
> "/home/nelle/Projets/skimage/env/lib/python2.6/site-packages/scipy-0.9.0-py2.6-linux-i686.egg/scipy/ndimage/interpolation.py",
> line 298, in map_coordinates
>     output, order, mode, cval, None, None)
> RuntimeError: data type not supported
>
> Thanks,
> Nelle
>
> Hi Nelle,

Thanks for working on this. I actually don't have any test failures when I
check out your branch. Nose reports 227 tests run (4 skips, but the skips
are b/c I don't have pyfits on my machine).

I'm running cython 14.1 and numpy dev (and scipy dev), so my system isn't
exactly a match. But I can't imagine how these differences could change the
test behavior before and after the renaming. Are you sure the test passed
before the rename?

Also, if anyone else wants to test this branch, just note that git acts a
little weird with it. When I checkout the skimage branch, it adds the
skimage tree, but doesn't remove the scikits.image tree (which can cause
build/test problems). Similarly, switching back adds the scikits.image tree,
but doesn't remove the skimage tree. You'll need to manually remove these
before building/testing.

Best,
-Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111015/75b7910a/attachment.html>

From nelle.varoquaux at gmail.com  Sat Oct 15 12:21:10 2011
From: nelle.varoquaux at gmail.com (Nelle Varoquaux)
Date: Sat, 15 Oct 2011 18:21:10 +0200
Subject: Renaming scikits.image to skimage
Message-ID: <CAE-UAvSq_2nCh1Cr75EqhhpqBAV45nxL32fBoe-Zoz72-A9Eeg@mail.gmail.com>

Hi all,

I've worked on renaming scikits.image to skimage. Unfortunately, I have one
test failing. I have no clue how to fix that, and would appreciate some help
on that.
You can have a look at the patch at :
https://github.com/NelleV/scikits.image/compare/master...skimage

I'm using numpy 1.6.1 and cython 0.15.1

======================================================================
ERROR: test_project.test_homography
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/home/nelle/Projets/skimage/env/lib/python2.6/site-packages/nose-1.1.2-py2.6.egg/nose/case.py",
line 197, in runTest
    self.test(*self.arg)
  File
"/home/nelle/Projets/skimage/skimage/transform/tests/test_project.py", line
23, in test_homography
    x90 = homography(x, M, order=1)
  File "/home/nelle/Projets/skimage/skimage/transform/project.py", line 101,
in homography
    mode=mode, order=order, cval=cval)
  File
"/home/nelle/Projets/skimage/env/lib/python2.6/site-packages/scipy-0.9.0-py2.6-linux-i686.egg/scipy/ndimage/interpolation.py",
line 298, in map_coordinates
    output, order, mode, cval, None, None)
RuntimeError: data type not supported

Thanks,
Nelle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111015/403f9bd8/attachment.html>

From nelle.varoquaux at gmail.com  Sun Oct 16 03:36:13 2011
From: nelle.varoquaux at gmail.com (Nelle Varoquaux)
Date: Sun, 16 Oct 2011 09:36:13 +0200
Subject: Renaming scikits.image to skimage
In-Reply-To: <CAEym_HqVxr2mTiUKODB6zn5w9xWsPVMU7TGn91Gaf3SS0K49OA@mail.gmail.com>
References: <CAE-UAvSq_2nCh1Cr75EqhhpqBAV45nxL32fBoe-Zoz72-A9Eeg@mail.gmail.com>
	<CAEym_HqVxr2mTiUKODB6zn5w9xWsPVMU7TGn91Gaf3SS0K49OA@mail.gmail.com>
Message-ID: <CAE-UAvQHfexHD_tA2O8E3TVvz0Z5e8GX4P94GPGb1emeZX8o0w@mail.gmail.com>

On 15 October 2011 22:17, Tony Yu <tsyu80 at gmail.com> wrote:

>
>
> On Sat, Oct 15, 2011 at 12:21 PM, Nelle Varoquaux <
> nelle.varoquaux at gmail.com> wrote:
>
>> Hi all,
>>
>> I've worked on renaming scikits.image to skimage. Unfortunately, I have
>> one test failing. I have no clue how to fix that, and would appreciate some
>> help on that.
>> You can have a look at the patch at :
>> https://github.com/NelleV/scikits.image/compare/master...skimage
>>
>> I'm using numpy 1.6.1 and cython 0.15.1
>>
>> ======================================================================
>> ERROR: test_project.test_homography
>> ----------------------------------------------------------------------
>> Traceback (most recent call last):
>>   File
>> "/home/nelle/Projets/skimage/env/lib/python2.6/site-packages/nose-1.1.2-py2.6.egg/nose/case.py",
>> line 197, in runTest
>>     self.test(*self.arg)
>>   File
>> "/home/nelle/Projets/skimage/skimage/transform/tests/test_project.py", line
>> 23, in test_homography
>>     x90 = homography(x, M, order=1)
>>   File "/home/nelle/Projets/skimage/skimage/transform/project.py", line
>> 101, in homography
>>     mode=mode, order=order, cval=cval)
>>   File
>> "/home/nelle/Projets/skimage/env/lib/python2.6/site-packages/scipy-0.9.0-py2.6-linux-i686.egg/scipy/ndimage/interpolation.py",
>> line 298, in map_coordinates
>>     output, order, mode, cval, None, None)
>> RuntimeError: data type not supported
>>
>> Thanks,
>> Nelle
>>
>> Hi Nelle,
>
> Thanks for working on this. I actually don't have any test failures when I
> check out your branch. Nose reports 227 tests run (4 skips, but the skips
> are b/c I don't have pyfits on my machine).
>
> I'm running cython 14.1 and numpy dev (and scipy dev), so my system isn't
> exactly a match. But I can't imagine how these differences could change the
> test behavior before and after the renaming. Are you sure the test passed
> before the rename?
>

I still have this installation problem, really annoying with the cython
compiled files, so I have ran the tests on master. I'll try to do that now.


>
> Also, if anyone else wants to test this branch, just note that git acts a
> little weird with it. When I checkout the skimage branch, it adds the
> skimage tree, but doesn't remove the scikits.image tree (which can cause
> build/test problems). Similarly, switching back adds the scikits.image tree,
> but doesn't remove the skimage tree. You'll need to manually remove these
> before building/testing.
>

Git does not remove folders if there are unchecked files in them (*.pyc,
*.so etc. Once we do the merge, it should be easier.


>
> Best,
> -Tony
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111016/ad01b811/attachment.html>

From nelle.varoquaux at gmail.com  Sun Oct 16 03:38:52 2011
From: nelle.varoquaux at gmail.com (Nelle Varoquaux)
Date: Sun, 16 Oct 2011 09:38:52 +0200
Subject: Renaming scikits.image to skimage
In-Reply-To: <CABDkGQnSWwJPq3pfty89bBkHZs1dyPCpcbVcnY_C8YYz8yPJVg@mail.gmail.com>
References: <CAE-UAvSq_2nCh1Cr75EqhhpqBAV45nxL32fBoe-Zoz72-A9Eeg@mail.gmail.com>
	<CABDkGQnSWwJPq3pfty89bBkHZs1dyPCpcbVcnY_C8YYz8yPJVg@mail.gmail.com>
Message-ID: <CAE-UAvQtyCjJehGJ9LQ6g7rU1tzSPFMMV_e-vSQwg4btdxm0Rg@mail.gmail.com>

Hi St?fan,

2011/10/15 St?fan van der Walt <stefan at sun.ac.za>

> Hi Nelle
>
> On Sat, Oct 15, 2011 at 9:21 AM, Nelle Varoquaux
> <nelle.varoquaux at gmail.com> wrote:
> > I've worked on renaming scikits.image to skimage. Unfortunately, I have
> one
>
> Thanks for your hard work; this looks great.
>
> Do you think we should rename the entire repo as well?  I.e.
>
> github.com/scikits-image/skimage.git
>
> ?
>

I think scikit-learn decision was to still do the branding with the name
"scikits-learn". In that case, I don't think it is necessary to rename the
repository.
What do you think about it ?

If we rename the repository, there's a bit more work to do.

Nelle

>
> Regards
> St?fan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111016/a1c6d725/attachment.html>

From stefan at sun.ac.za  Sun Oct 16 15:55:58 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 16 Oct 2011 12:55:58 -0700
Subject: Renaming scikits.image to skimage
In-Reply-To: <CAE-UAvQtyCjJehGJ9LQ6g7rU1tzSPFMMV_e-vSQwg4btdxm0Rg@mail.gmail.com>
References: <CAE-UAvSq_2nCh1Cr75EqhhpqBAV45nxL32fBoe-Zoz72-A9Eeg@mail.gmail.com>
 <CABDkGQnSWwJPq3pfty89bBkHZs1dyPCpcbVcnY_C8YYz8yPJVg@mail.gmail.com> <CAE-UAvQtyCjJehGJ9LQ6g7rU1tzSPFMMV_e-vSQwg4btdxm0Rg@mail.gmail.com>
Message-ID: <CABDkGQ=pcaqNQzcEqczk75h_HUrN_haNSf8u0epJEdhW4A8ECg@mail.gmail.com>

On Sun, Oct 16, 2011 at 12:38 AM, Nelle Varoquaux
<nelle.varoquaux at gmail.com> wrote:
> I think scikit-learn decision was to still do the branding with the name
> "scikits-learn". In that case, I don't think it is necessary to rename the
> repository.
> What do you think about it ?
> If we rename the repository, there's a bit more work to do.

We're going to keep the scikits-image organisation on GitHub, but I
think we need to move the source repo to skimage.git (instead of
scikits.image.git).

St?fan


From tsyu80 at gmail.com  Sun Oct 16 13:31:35 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Sun, 16 Oct 2011 13:31:35 -0400
Subject: Math functions for uint8
Message-ID: <CAEym_HrFAoJMyTd+gypeU7p1UCaAA1=vXGfB_mYeg3=MKL00HA@mail.gmail.com>

This may be a little low-level for skimage, but I just published a branch
with some math operations on uint8 arrays.

https://github.com/tonysyu/scikits.image/compare/master...uint8_math

Basically, it defines add/subtract/multiply/divide for uint8 arrays, but
clips values instead of allowing values to overflow/underflow. I originally
wrote them because I thought they were necessary to fix the underflow
problems in morphological tophat, but it turned out that the underlying
issue was different. Even so, they could be useful elsewhere: For example, I
remember the Sobel filters had issues with underflow or overflow (I think
the functions now cast to float).

I noticed that there were some similar operations written in Cython
(scikits/image/io/_plugins/_colormixer.pyx), but these look specific to the
application (but are probably faster, too).

Any thoughts would be appreciated,
-Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111016/dc4d0f76/attachment.html>

From emmanuelle.gouillart at nsup.org  Sun Oct 16 16:24:30 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Sun, 16 Oct 2011 22:24:30 +0200
Subject: Renaming scikits.image to skimage
In-Reply-To: <CABDkGQ=pcaqNQzcEqczk75h_HUrN_haNSf8u0epJEdhW4A8ECg@mail.gmail.com>
References: <CAE-UAvSq_2nCh1Cr75EqhhpqBAV45nxL32fBoe-Zoz72-A9Eeg@mail.gmail.com>
 <CABDkGQnSWwJPq3pfty89bBkHZs1dyPCpcbVcnY_C8YYz8yPJVg@mail.gmail.com>
 <CAE-UAvQtyCjJehGJ9LQ6g7rU1tzSPFMMV_e-vSQwg4btdxm0Rg@mail.gmail.com>
 <CABDkGQ=pcaqNQzcEqczk75h_HUrN_haNSf8u0epJEdhW4A8ECg@mail.gmail.com>
Message-ID: <20111016202430.GC337@phare.normalesup.org>

On Sun, Oct 16, 2011 at 12:55:58PM -0700, St??????fan van der Walt wrote:
> On Sun, Oct 16, 2011 at 12:38 AM, Nelle Varoquaux
> <nelle.varoquaux at gmail.com> wrote:
> > I think scikit-learn decision was to still do the branding with the name
> > "scikits-learn". In that case, I don't think it is necessary to rename the
> > repository.
> > What do you think about it ?
> > If we rename the repository, there's a bit more work to do.

> We're going to keep the scikits-image organisation on GitHub, but I
> think we need to move the source repo to skimage.git (instead of
> scikits.image.git).

+1

I think we should move "everything" to skimage, except the name of the
source repo, and the name of the mailing list. A few examples of changes
that could be made (from a 'git grep scikits.image' in Nelle's skimage
branch)

TASKS.txt:Developing Open Source is great fun!  Join us on the
`scikits-image mailing-list
doc/source/conf.py:copyright = u'2011, scikits-image team'
doc/Makefile:   --project-url=http://scikits-image.org \
(now that St??????fan kindly provided the new domain name!)
...
and many similar occurrences found by git grep

In some places, we could also use "the Image Scikit", to make clear that
our package is... an image scikit. What do you think?

Emmanuelle


From stefan at sun.ac.za  Mon Oct 17 01:28:04 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 16 Oct 2011 22:28:04 -0700
Subject: Renaming scikits.image to skimage
In-Reply-To: <20111016202430.GC337@phare.normalesup.org>
References: <CAE-UAvSq_2nCh1Cr75EqhhpqBAV45nxL32fBoe-Zoz72-A9Eeg@mail.gmail.com>
 <CABDkGQnSWwJPq3pfty89bBkHZs1dyPCpcbVcnY_C8YYz8yPJVg@mail.gmail.com>
 <CAE-UAvQtyCjJehGJ9LQ6g7rU1tzSPFMMV_e-vSQwg4btdxm0Rg@mail.gmail.com>
 <CABDkGQ=pcaqNQzcEqczk75h_HUrN_haNSf8u0epJEdhW4A8ECg@mail.gmail.com> <20111016202430.GC337@phare.normalesup.org>
Message-ID: <CABDkGQ=erCSV5nVDHcvoPycfdSrZJ0e58XKwAqsJRJHRhqfqLQ@mail.gmail.com>

On Sun, Oct 16, 2011 at 1:24 PM, Emmanuelle Gouillart
<emmanuelle.gouillart at nsup.org> wrote:
> I think we should move "everything" to skimage, except the name of the
> source repo, and the name of the mailing list. A few examples of changes
> that could be made (from a 'git grep scikits.image' in Nelle's skimage
> branch)

When you say source repo, do you agree that the url for the repo should be

https://github.com/scikits-image/skimage

?

St?fan


From nelle.varoquaux at gmail.com  Sun Oct 16 16:51:15 2011
From: nelle.varoquaux at gmail.com (Nelle Varoquaux)
Date: Sun, 16 Oct 2011 22:51:15 +0200
Subject: Renaming scikits.image to skimage
In-Reply-To: <20111016202430.GC337@phare.normalesup.org>
References: <CAE-UAvSq_2nCh1Cr75EqhhpqBAV45nxL32fBoe-Zoz72-A9Eeg@mail.gmail.com>
	<CABDkGQnSWwJPq3pfty89bBkHZs1dyPCpcbVcnY_C8YYz8yPJVg@mail.gmail.com>
	<CAE-UAvQtyCjJehGJ9LQ6g7rU1tzSPFMMV_e-vSQwg4btdxm0Rg@mail.gmail.com>
	<CABDkGQ=pcaqNQzcEqczk75h_HUrN_haNSf8u0epJEdhW4A8ECg@mail.gmail.com>
	<20111016202430.GC337@phare.normalesup.org>
Message-ID: <CAE-UAvQXCx=c88JjQNuVOBGi6VWvjca35+0pq-hU_funC4-8ag@mail.gmail.com>

On 16 October 2011 22:24, Emmanuelle Gouillart <
emmanuelle.gouillart at nsup.org> wrote:

> On Sun, Oct 16, 2011 at 12:55:58PM -0700, St?fan van der Walt wrote:
> > On Sun, Oct 16, 2011 at 12:38 AM, Nelle Varoquaux
> > <nelle.varoquaux at gmail.com> wrote:
> > > I think scikit-learn decision was to still do the branding with the
> name
> > > "scikits-learn". In that case, I don't think it is necessary to rename
> the
> > > repository.
> > > What do you think about it ?
> > > If we rename the repository, there's a bit more work to do.
>
> > We're going to keep the scikits-image organisation on GitHub, but I
> > think we need to move the source repo to skimage.git (instead of
> > scikits.image.git).
>
> +1
>
+1


>
> I think we should move "everything" to skimage, except the name of the
> source repo, and the name of the mailing list. A few examples of changes
> that could be made (from a 'git grep scikits.image' in Nelle's skimage
> branch)
>
> TASKS.txt:Developing Open Source is great fun!  Join us on the
> `scikits-image mailing-list
> doc/source/conf.py:copyright = u'2011, scikits-image team'
> doc/Makefile:   --project-url=http://scikits-image.org \
> (now that St?fan kindly provided the new domain name!)
> ...
> and many similar occurrences found by git grep
>
> In some places, we could also use "the Image Scikit", to make clear that
> our package is... an image scikit. What do you think?
>

+1 too


>
> Emmanuelle
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111016/63478685/attachment.html>

From bdholt1 at gmail.com  Mon Oct 17 01:31:37 2011
From: bdholt1 at gmail.com (bdholt1 at gmail.com)
Date: Mon, 17 Oct 2011 05:31:37 +0000
Subject: Renaming scikits.image to skimage
In-Reply-To: <CABDkGQ=erCSV5nVDHcvoPycfdSrZJ0e58XKwAqsJRJHRhqfqLQ@mail.gmail.com>
References: <CAE-UAvSq_2nCh1Cr75EqhhpqBAV45nxL32fBoe-Zoz72-A9Eeg@mail.gmail.com>
  <CABDkGQnSWwJPq3pfty89bBkHZs1dyPCpcbVcnY_C8YYz8yPJVg@mail.gmail.com>
  <CAE-UAvQtyCjJehGJ9LQ6g7rU1tzSPFMMV_e-vSQwg4btdxm0Rg@mail.gmail.com>
  <CABDkGQ=pcaqNQzcEqczk75h_HUrN_haNSf8u0epJEdhW4A8ECg@mail.gmail.com>
  <20111016202430.GC337@phare.normalesup.org>
  <CABDkGQ=erCSV5nVDHcvoPycfdSrZJ0e58XKwAqsJRJHRhqfqLQ@mail.gmail.com>
Message-ID: <1580353491-1318829499-cardhu_decombobulator_blackberry.rim.net-1395356556-@b15.c4.bise7.blackberry>

My 2c: I think the package name should move to skimage (as decided), and the repo name should be "scikits-image" I.e. 

https://github.com/scikits-image/scikits-image


-----Original Message-----
From: St?fan van der Walt <stefan at sun.ac.za>
Sender: scikits-image at googlegroups.com
Date: Sun, 16 Oct 2011 22:28:04 
To: <scikits-image at googlegroups.com>
Reply-To: scikits-image at googlegroups.com
Subject: Re: Renaming scikits.image to skimage

On Sun, Oct 16, 2011 at 1:24 PM, Emmanuelle Gouillart
<emmanuelle.gouillart at nsup.org> wrote:
> I think we should move "everything" to skimage, except the name of the
> source repo, and the name of the mailing list. A few examples of changes
> that could be made (from a 'git grep scikits.image' in Nelle's skimage
> branch)

When you say source repo, do you agree that the url for the repo should be

https://github.com/scikits-image/skimage

?

St?fan

From stefan at sun.ac.za  Tue Oct 18 15:01:25 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 18 Oct 2011 12:01:25 -0700
Subject: Renaming scikits.image to skimage
In-Reply-To: <1580353491-1318829499-cardhu_decombobulator_blackberry.rim.net-1395356556-@b15.c4.bise7.blackberry>
References: <CAE-UAvSq_2nCh1Cr75EqhhpqBAV45nxL32fBoe-Zoz72-A9Eeg@mail.gmail.com>
 <CABDkGQnSWwJPq3pfty89bBkHZs1dyPCpcbVcnY_C8YYz8yPJVg@mail.gmail.com>
 <CAE-UAvQtyCjJehGJ9LQ6g7rU1tzSPFMMV_e-vSQwg4btdxm0Rg@mail.gmail.com>
 <CABDkGQ=pcaqNQzcEqczk75h_HUrN_haNSf8u0epJEdhW4A8ECg@mail.gmail.com>
 <20111016202430.GC337@phare.normalesup.org> <CABDkGQ=erCSV5nVDHcvoPycfdSrZJ0e58XKwAqsJRJHRhqfqLQ@mail.gmail.com>
 <1580353491-1318829499-cardhu_decombobulator_blackberry.rim.net-1395356556-@b15.c4.bise7.blackberry>
Message-ID: <CABDkGQk7Xxw205oNj77zyZiRyFNQdzHJQ=Wi8mUC_GoPO-+nPw@mail.gmail.com>

On Sun, Oct 16, 2011 at 10:31 PM,  <bdholt1 at gmail.com> wrote:
> My 2c: I think the package name should move to skimage (as decided), and the repo name should be "scikits-image" I.e.
>
> https://github.com/scikits-image/scikits-image

That seems reasonable.  Then the downloaded zip files will be
scikits-image-xx.zip, which contains the skimage package.

Cheers
St?fan


From stefan at sun.ac.za  Tue Oct 18 15:10:47 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 18 Oct 2011 12:10:47 -0700
Subject: Math functions for uint8
In-Reply-To: <CAEym_HrFAoJMyTd+gypeU7p1UCaAA1=vXGfB_mYeg3=MKL00HA@mail.gmail.com>
References: <CAEym_HrFAoJMyTd+gypeU7p1UCaAA1=vXGfB_mYeg3=MKL00HA@mail.gmail.com>
Message-ID: <CABDkGQm=6Y1=r6S95_L4sJ_HSfmVXE4O5VJwyeDXKesZSo=Q-w@mail.gmail.com>

On Sun, Oct 16, 2011 at 10:31 AM, Tony Yu <tsyu80 at gmail.com> wrote:
> This may be a little low-level for skimage, but I just published a branch
> with some math operations on uint8 arrays.
>
> https://github.com/tonysyu/scikits.image/compare/master...uint8_math

Ideally, we do not want to do manipulations that overflow or underflow
(and that probably means avoiding uint8 arithmetic).  It is used in
colormixer, because those values are for display purposes only.
However, let's keep this code around for a while; now that it's been
written, we can easily pull it in if it happens to solve a problem.

Cheers
St?fan


From stefan at sun.ac.za  Tue Oct 18 15:18:00 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 18 Oct 2011 12:18:00 -0700
Subject: Pull request: morphology fix
In-Reply-To: <CAEym_HqFgCWksnMHqRC7Y-Fs8TBnE4=OmR5rZzZaXq8LPcpQNQ@mail.gmail.com>
References: <CAEym_HqFgCWksnMHqRC7Y-Fs8TBnE4=OmR5rZzZaXq8LPcpQNQ@mail.gmail.com>
Message-ID: <CABDkGQkLJW7OyQtY00OvyMrbDEjL+Yv_4W4kkYynE0KFZ5yp=Q@mail.gmail.com>

Hi Tony

On Sat, Oct 15, 2011 at 1:58 AM, Tony Yu <tsyu80 at gmail.com> wrote:>
The open/close operations aren't that bad: they just shift features.
But,
> when calling white/black tophat operations, the shifting can lead to
> over/underflow of pixels. I've attached examples of the lena image after
> calling white tophat, both before and after the fix. The underflow should be
> apparent in the first image.

Thanks for investigating and fixing this subtle bug.  Talking about
data-types, we should gradually move towards using the data type
helper utilities, and thereby avoid possible over and underflow
issues.

Regards
St?fan


From stefan at sun.ac.za  Tue Oct 18 15:20:54 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 18 Oct 2011 12:20:54 -0700
Subject: Skeletonization
In-Reply-To: <4f0cebf0-62a1-4a8b-b524-40096610e1d0@q12g2000yqe.googlegroups.com>
References: <7858a16a-052b-46e2-9069-33d43c9d2d6a@s14g2000vbj.googlegroups.com>
 <CABDkGQ=_Vmh+73YK+VOA9qBtpZOOur2gKCze22rstc77MWfkkw@mail.gmail.com>
 <57ad6f9b-a015-4876-8406-b6c8d8ea6f3f@f5g2000vbz.googlegroups.com>
 <CABDkGQkQO78ahygcf1+UQdHRy+6YzB6uAo+49VyWGE-C5Oonmw@mail.gmail.com>
 <CABDkGQmp9tbsfdW4ffFdEgCGx419s0M02t39XtAnq+fG3k3srw@mail.gmail.com>
 <20111014220743.GD27939@phare.normalesup.org> <CABDkGQ=55huHAbO9Tp-maJmOiRFhiDFCN9U5YTd7bvbSUYXZjQ@mail.gmail.com>
 <4f0cebf0-62a1-4a8b-b524-40096610e1d0@q12g2000yqe.googlegroups.com>
Message-ID: <CABDkGQ=anA1aJ+XQk+CO0ef3r6m9R6gWD_+XxgcCBeUNk8MHfA@mail.gmail.com>

Hi Neil

On Fri, Oct 14, 2011 at 11:46 PM, Neil Yager <yager.neil at gmail.com> wrote:
> As you can see, the results are very different. Once again, there are
> situations where both are useful. The former keeps an indication of
> size, while the latter keeps only topology.

I propose that we merge yours as "skeletonize" and the CellProfiler
version as "medial_axis" if, in fact, that is the algorithm they
implement.

Regards
St?fan


From stefan at sun.ac.za  Tue Oct 18 15:27:00 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 18 Oct 2011 12:27:00 -0700
Subject: Renaming / 0.4 timeline
Message-ID: <CABDkGQ=b2t7gya=Ns_M3HZNfS8XH+4tUrJKe878HzZAKhUWkFg@mail.gmail.com>

Hi all,

Here's a proposed timeline for the renaming and release process:

Tue Oct 18th to Sat Oct 22nd : File and merge PRs of work-in-progress
made against the current repo
Sun Oct 23rd : Rename the repository, update documentation, test
Mon Oct 24th to Fri Oct 21st : Apply bugfixes, add features, etc.
required for 0.4, including polishing the Debian package
Oct 22-23 : Release v0.4

How does that sound?

Regards
St?fan


From stefan at sun.ac.za  Tue Oct 18 15:46:21 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 18 Oct 2011 12:46:21 -0700
Subject: Renaming / 0.4 timeline
In-Reply-To: <20111018193227.GB26732@phare.normalesup.org>
References: <CABDkGQ=b2t7gya=Ns_M3HZNfS8XH+4tUrJKe878HzZAKhUWkFg@mail.gmail.com>
 <20111018193227.GB26732@phare.normalesup.org>
Message-ID: <CABDkGQ=4gsArXEzhhK8KbT62VGCwM1Y+5F=j55iivOiVqiVxvA@mail.gmail.com>

On Tue, Oct 18, 2011 at 12:32 PM, Emmanuelle Gouillart
<emmanuelle.gouillart at nsup.org> wrote:
> On Tue, Oct 18, 2011 at 12:27:00PM -0700, St?fan van der Walt wrote:
>> required for 0.4, including polishing the Debian package
>> Oct 22-23 : Release v0.4
> 28-29 ?

Let me try again:

Tue Oct 18th to Sat Oct 22nd : File and merge PRs of work-in-progress
made against the current repo
Sun Oct 23rd : Rename the repository, update documentation, test
Mon Oct 24th to Fri Oct 28th : Apply bugfixes, add features, etc.
required for 0.4, including polishing the Debian package
Oct 29th to 30th : Release v0.4


From stefan at sun.ac.za  Tue Oct 18 18:50:34 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 18 Oct 2011 15:50:34 -0700
Subject: Pull request: morphology fix
In-Reply-To: <CAEym_Hq3S0X3CoVn0-3gwpNfbJn44=yyU=NdWBc6Nbu9_2ML-w@mail.gmail.com>
References: <CAEym_HqFgCWksnMHqRC7Y-Fs8TBnE4=OmR5rZzZaXq8LPcpQNQ@mail.gmail.com>
 <CABDkGQkLJW7OyQtY00OvyMrbDEjL+Yv_4W4kkYynE0KFZ5yp=Q@mail.gmail.com> <CAEym_Hq3S0X3CoVn0-3gwpNfbJn44=yyU=NdWBc6Nbu9_2ML-w@mail.gmail.com>
Message-ID: <CABDkGQkDn0aq0cUfyN9+sw0_YMj_Cxbj43Z_FYetWAUVYiqRSg@mail.gmail.com>

On Tue, Oct 18, 2011 at 12:53 PM, Tony Yu <tsyu80 at gmail.com> wrote:
> I'm definitely in favor of not requiring specific input dtypes.
> Unfortunately, I believe a lot of extensions assume uint8 (at least those in
> the cmorph.pyx do). Since img_as_uint casts values to uint16, should these
> functions be written to use uint16? Also, are there ways to write fast
> Cython extensions without specifying dtypes?

Unfortunately, I don't know of any way to write type-agnostic code
with Cython (it is very high on my wish-list).  I've even considered
whether we should use C++ to template code, and then simply wrap that
in Cython.

Does anyone here have experience with such approaches?

As for this specific problem, I think it's best to use uint16 or float
as computation types where possible.

Regards
St?fan


From tsyu80 at gmail.com  Tue Oct 18 15:53:53 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Tue, 18 Oct 2011 15:53:53 -0400
Subject: Pull request: morphology fix
In-Reply-To: <CABDkGQkLJW7OyQtY00OvyMrbDEjL+Yv_4W4kkYynE0KFZ5yp=Q@mail.gmail.com>
References: <CAEym_HqFgCWksnMHqRC7Y-Fs8TBnE4=OmR5rZzZaXq8LPcpQNQ@mail.gmail.com>
	<CABDkGQkLJW7OyQtY00OvyMrbDEjL+Yv_4W4kkYynE0KFZ5yp=Q@mail.gmail.com>
Message-ID: <CAEym_Hq3S0X3CoVn0-3gwpNfbJn44=yyU=NdWBc6Nbu9_2ML-w@mail.gmail.com>

2011/10/18 St?fan van der Walt <stefan at sun.ac.za>

> Hi Tony
>
> On Sat, Oct 15, 2011 at 1:58 AM, Tony Yu <tsyu80 at gmail.com> wrote:>
> The open/close operations aren't that bad: they just shift features.
> But,
> > when calling white/black tophat operations, the shifting can lead to
> > over/underflow of pixels. I've attached examples of the lena image after
> > calling white tophat, both before and after the fix. The underflow should
> be
> > apparent in the first image.
>
> Thanks for investigating and fixing this subtle bug.  Talking about
> data-types, we should gradually move towards using the data type
> helper utilities, and thereby avoid possible over and underflow
> issues.
>

I'm definitely in favor of not requiring specific input dtypes.
Unfortunately, I believe a lot of extensions assume uint8 (at least those in
the cmorph.pyx do). Since img_as_uint casts values to uint16, should these
functions be written to use uint16? Also, are there ways to write fast
Cython extensions without specifying dtypes?

Best,
-Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111018/4ce34348/attachment.html>

From emmanuelle.gouillart at nsup.org  Tue Oct 18 15:32:27 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Tue, 18 Oct 2011 21:32:27 +0200
Subject: Renaming / 0.4 timeline
In-Reply-To: <CABDkGQ=b2t7gya=Ns_M3HZNfS8XH+4tUrJKe878HzZAKhUWkFg@mail.gmail.com>
References: <CABDkGQ=b2t7gya=Ns_M3HZNfS8XH+4tUrJKe878HzZAKhUWkFg@mail.gmail.com>
Message-ID: <20111018193227.GB26732@phare.normalesup.org>

On Tue, Oct 18, 2011 at 12:27:00PM -0700, St??????fan van der Walt wrote:
> Hi all,

> Here's a proposed timeline for the renaming and release process:

> Tue Oct 18th to Sat Oct 22nd : File and merge PRs of work-in-progress
> made against the current repo
> Sun Oct 23rd : Rename the repository, update documentation, test
> Mon Oct 24th to Fri Oct 21st : Apply bugfixes, add features, etc.
do you mean: to Fri Oct 28th?

> required for 0.4, including polishing the Debian package
> Oct 22-23 : Release v0.4
28-29 ?



From emmanuelle.gouillart at nsup.org  Tue Oct 18 15:54:07 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Tue, 18 Oct 2011 21:54:07 +0200
Subject: Skeletonization
In-Reply-To: <CABDkGQ=anA1aJ+XQk+CO0ef3r6m9R6gWD_+XxgcCBeUNk8MHfA@mail.gmail.com>
References: <7858a16a-052b-46e2-9069-33d43c9d2d6a@s14g2000vbj.googlegroups.com>
 <CABDkGQ=_Vmh+73YK+VOA9qBtpZOOur2gKCze22rstc77MWfkkw@mail.gmail.com>
 <57ad6f9b-a015-4876-8406-b6c8d8ea6f3f@f5g2000vbz.googlegroups.com>
 <CABDkGQkQO78ahygcf1+UQdHRy+6YzB6uAo+49VyWGE-C5Oonmw@mail.gmail.com>
 <CABDkGQmp9tbsfdW4ffFdEgCGx419s0M02t39XtAnq+fG3k3srw@mail.gmail.com>
 <20111014220743.GD27939@phare.normalesup.org>
 <CABDkGQ=55huHAbO9Tp-maJmOiRFhiDFCN9U5YTd7bvbSUYXZjQ@mail.gmail.com>
 <4f0cebf0-62a1-4a8b-b524-40096610e1d0@q12g2000yqe.googlegroups.com>
 <CABDkGQ=anA1aJ+XQk+CO0ef3r6m9R6gWD_+XxgcCBeUNk8MHfA@mail.gmail.com>
Message-ID: <20111018195407.GC26732@phare.normalesup.org>

On Tue, Oct 18, 2011 at 12:20:54PM -0700, St??????fan van der Walt wrote:
> Hi Neil

> On Fri, Oct 14, 2011 at 11:46 PM, Neil Yager <yager.neil at gmail.com> wrote:
> > As you can see, the results are very different. Once again, there are
> > situations where both are useful. The former keeps an indication of
> > size, while the latter keeps only topology.

> I propose that we merge yours as "skeletonize" and the CellProfiler
> version as "medial_axis" if, in fact, that is the algorithm they
> implement.

Yes, their algorithm computes the medial axis (as the ridges of the
distance transform). I'm currently working on refactoring their
algorithm. 

As for Neil's version, we're not far from merging, there are just a few
minor changes to be done!

Cheers,
Emmanuelle


From amueller at ais.uni-bonn.de  Wed Oct 19 04:18:31 2011
From: amueller at ais.uni-bonn.de (Andreas Mueller)
Date: Wed, 19 Oct 2011 10:18:31 +0200
Subject: A bit of history and the bilateral filter
In-Reply-To: <20111014215122.GB27939@phare.normalesup.org>
References: <CABDkGQm2bvJgprJ06vjcOL3SViq7FEep-zE3e1YwxY3YCXqjrw@mail.gmail.com> <CAEym_Hr4DCNdcF7JGX8RA6p7X5TonhYJi70-yO=5z=wrb3C9AA@mail.gmail.com> <CABDkGQnKctUHnRmwkfYww=OnsdTQf=M2WyJLKW1-9qZnqB2GEg@mail.gmail.com> <4E97F9F9.40101@ais.uni-bonn.de> <20111014215122.GB27939@phare.normalesup.org>
Message-ID: <4E9E87D7.9050307@ais.uni-bonn.de>

Hi Emmanuelle.
Thanks for the info about the Patent. I didn't know about that.
I was also thinking about the Ponce algorithm for denoising,
but I thought the non-local means was easier. Have you used
the dictionarly learning yourself?
I heard a talk by Ponce about it and it looked pretty cool.
I haven't had time to really look at the dictionary learning
in sklearn yet but it looks as if this is nearly what we want.
As far as I can tell, one "only" needs to add the patch-similarity
term in the optimization. I don't know how straight
forward that is.
But this would definitely be a cool feature to have.

What do you think about the lena denoising example
in sklearn?
 From what I saw in papers, I would expect the
denoising to work better, even without the
improvements from the Ponce paper.
Do you think the result would be better other
optimization strategies? Or do you think the
dictionary is to small?
It seems the patches where only trained
on the Lena image. In the talk, Ponce
said it would be good to train on many images
as an initialization and then train again only
on the image on wants to denoise.
Do you have any experience with that?

Cheers,
Andy


From amueller at ais.uni-bonn.de  Wed Oct 19 04:27:39 2011
From: amueller at ais.uni-bonn.de (Andreas Mueller)
Date: Wed, 19 Oct 2011 10:27:39 +0200
Subject: Pull request: morphology fix
In-Reply-To: <CABDkGQkDn0aq0cUfyN9+sw0_YMj_Cxbj43Z_FYetWAUVYiqRSg@mail.gmail.com>
References: <CAEym_HqFgCWksnMHqRC7Y-Fs8TBnE4=OmR5rZzZaXq8LPcpQNQ@mail.gmail.com> <CABDkGQkLJW7OyQtY00OvyMrbDEjL+Yv_4W4kkYynE0KFZ5yp=Q@mail.gmail.com> <CAEym_Hq3S0X3CoVn0-3gwpNfbJn44=yyU=NdWBc6Nbu9_2ML-w@mail.gmail.com> <CABDkGQkDn0aq0cUfyN9+sw0_YMj_Cxbj43Z_FYetWAUVYiqRSg@mail.gmail.com>
Message-ID: <4E9E89FB.4030701@ais.uni-bonn.de>

On 10/19/2011 12:50 AM, St??????fan van der Walt wrote:
> On Tue, Oct 18, 2011 at 12:53 PM, Tony Yu<tsyu80 at gmail.com>  wrote:
>> I'm definitely in favor of not requiring specific input dtypes.
>> Unfortunately, I believe a lot of extensions assume uint8 (at least those in
>> the cmorph.pyx do). Since img_as_uint casts values to uint16, should these
>> functions be written to use uint16? Also, are there ways to write fast
>> Cython extensions without specifying dtypes?
> Unfortunately, I don't know of any way to write type-agnostic code
> with Cython (it is very high on my wish-list).  I've even considered
> whether we should use C++ to template code, and then simply wrap that
> in Cython.
>
> Does anyone here have experience with such approaches?
At my lab we have a heavily templated C++ library that we exposed
to Python with Boost::Python. That takes care of all overloading
and is pretty convenient. Using pyublas one simply gets a ublas
matrix of the type of the numpy array.

I have not much experience with Cython so I don't know how
interfacing the C++ with Cython would work...

Cheers,
Andy


From stefan at sun.ac.za  Wed Oct 19 14:44:03 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 19 Oct 2011 11:44:03 -0700
Subject: Pull request: morphology fix
In-Reply-To: <CABL7CQhOpc1FGd4OEkKPDZ2zOtaozT=SX+w69tg-YFagVf22Sg@mail.gmail.com>
References: <CAEym_HqFgCWksnMHqRC7Y-Fs8TBnE4=OmR5rZzZaXq8LPcpQNQ@mail.gmail.com>
 <CABDkGQkLJW7OyQtY00OvyMrbDEjL+Yv_4W4kkYynE0KFZ5yp=Q@mail.gmail.com>
 <CAEym_Hq3S0X3CoVn0-3gwpNfbJn44=yyU=NdWBc6Nbu9_2ML-w@mail.gmail.com>
 <CABDkGQkDn0aq0cUfyN9+sw0_YMj_Cxbj43Z_FYetWAUVYiqRSg@mail.gmail.com> <CABL7CQhOpc1FGd4OEkKPDZ2zOtaozT=SX+w69tg-YFagVf22Sg@mail.gmail.com>
Message-ID: <CABDkGQ=bjsBDvbwX81dUa=w3N8J4Cw51e4RoCkCbcttuPH626A@mail.gmail.com>

On Wed, Oct 19, 2011 at 9:57 AM, Ralf Gommers
<ralf.gommers at googlemail.com> wrote:
>> Does anyone here have experience with such approaches?
>>
> scipy.interpolate has Cython code with simple Mako templating, look at
> interpnd.pyx and generate_interpnd.py. If it's flexible enough for your
> needs then it'll be a lot more pleasant than using C++.

This definitely gets us some way.  We can modify our _build.cython
call to first run the template engine on any .tpyx files.

But how should we dispatch to different functions, based on dtype?
Let's say we have support for int16, uint16 and double in our
algorithm, so via templating we'll get

myfunc_int16
myfunc_uint16
myfunc_double

for a single input argument (which is the most common case).  We can
then define a dispatch call such as

dtype_call('myfunc', img.dtype)

which calls the appropriate function.  Does this sound about right?

Regards
St?fan


From stefan at sun.ac.za  Wed Oct 19 20:01:34 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 19 Oct 2011 17:01:34 -0700
Subject: Pull request: morphology fix
In-Reply-To: <4E9F1D47.3080305@ais.uni-bonn.de>
References: <CAEym_HqFgCWksnMHqRC7Y-Fs8TBnE4=OmR5rZzZaXq8LPcpQNQ@mail.gmail.com>
 <CABDkGQkLJW7OyQtY00OvyMrbDEjL+Yv_4W4kkYynE0KFZ5yp=Q@mail.gmail.com>
 <CAEym_Hq3S0X3CoVn0-3gwpNfbJn44=yyU=NdWBc6Nbu9_2ML-w@mail.gmail.com>
 <CABDkGQkDn0aq0cUfyN9+sw0_YMj_Cxbj43Z_FYetWAUVYiqRSg@mail.gmail.com>
 <CABL7CQhOpc1FGd4OEkKPDZ2zOtaozT=SX+w69tg-YFagVf22Sg@mail.gmail.com>
 <CABDkGQ=bjsBDvbwX81dUa=w3N8J4Cw51e4RoCkCbcttuPH626A@mail.gmail.com> <4E9F1D47.3080305@ais.uni-bonn.de>
Message-ID: <CABDkGQn1qUyop6=JUUrGGb3KrAUML--zqDCbjgmDtgHukwQdEw@mail.gmail.com>

On Wed, Oct 19, 2011 at 11:56 AM, Andreas Mueller
<amueller at ais.uni-bonn.de> wrote:
> scipy.interpolate has Cython code with simple Mako templating, look at
> interpnd.pyx and generate_interpnd.py. If it's flexible enough for your
> needs then it'll be a lot more pleasant than using C++.

Brian also took this conversation over to the scikit-learn list, where
it came out that Tempita is quite popular.  I've used it before, and
it's lightweight and can be included as a single .py in our
repository.

We now need someone to modify the _build.cython script to convert
.pyx.in files to .pyx files before building, much like in this script:

https://raw.github.com/dagss/private-scipy-refactor/cythonize/cythonize.py

Any takers?

St?fan


From ralf.gommers at googlemail.com  Wed Oct 19 12:57:19 2011
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Wed, 19 Oct 2011 18:57:19 +0200
Subject: Pull request: morphology fix
In-Reply-To: <CABDkGQkDn0aq0cUfyN9+sw0_YMj_Cxbj43Z_FYetWAUVYiqRSg@mail.gmail.com>
References: <CAEym_HqFgCWksnMHqRC7Y-Fs8TBnE4=OmR5rZzZaXq8LPcpQNQ@mail.gmail.com>
	<CABDkGQkLJW7OyQtY00OvyMrbDEjL+Yv_4W4kkYynE0KFZ5yp=Q@mail.gmail.com>
	<CAEym_Hq3S0X3CoVn0-3gwpNfbJn44=yyU=NdWBc6Nbu9_2ML-w@mail.gmail.com>
	<CABDkGQkDn0aq0cUfyN9+sw0_YMj_Cxbj43Z_FYetWAUVYiqRSg@mail.gmail.com>
Message-ID: <CABL7CQhOpc1FGd4OEkKPDZ2zOtaozT=SX+w69tg-YFagVf22Sg@mail.gmail.com>

2011/10/19 St?fan van der Walt <stefan at sun.ac.za>

> On Tue, Oct 18, 2011 at 12:53 PM, Tony Yu <tsyu80 at gmail.com> wrote:
> > I'm definitely in favor of not requiring specific input dtypes.
> > Unfortunately, I believe a lot of extensions assume uint8 (at least those
> in
> > the cmorph.pyx do). Since img_as_uint casts values to uint16, should
> these
> > functions be written to use uint16? Also, are there ways to write fast
> > Cython extensions without specifying dtypes?
>
> Unfortunately, I don't know of any way to write type-agnostic code
> with Cython (it is very high on my wish-list).  I've even considered
> whether we should use C++ to template code, and then simply wrap that
> in Cython.
>
> Does anyone here have experience with such approaches?
>
> scipy.interpolate has Cython code with simple Mako templating, look at
interpnd.pyx and generate_interpnd.py. If it's flexible enough for your
needs then it'll be a lot more pleasant than using C++.

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

From amueller at ais.uni-bonn.de  Wed Oct 19 14:56:07 2011
From: amueller at ais.uni-bonn.de (Andreas Mueller)
Date: Wed, 19 Oct 2011 20:56:07 +0200
Subject: Pull request: morphology fix
In-Reply-To: <CABDkGQ=bjsBDvbwX81dUa=w3N8J4Cw51e4RoCkCbcttuPH626A@mail.gmail.com>
References: <CAEym_HqFgCWksnMHqRC7Y-Fs8TBnE4=OmR5rZzZaXq8LPcpQNQ@mail.gmail.com> <CABDkGQkLJW7OyQtY00OvyMrbDEjL+Yv_4W4kkYynE0KFZ5yp=Q@mail.gmail.com> <CAEym_Hq3S0X3CoVn0-3gwpNfbJn44=yyU=NdWBc6Nbu9_2ML-w@mail.gmail.com> <CABDkGQkDn0aq0cUfyN9+sw0_YMj_Cxbj43Z_FYetWAUVYiqRSg@mail.gmail.com> <CABL7CQhOpc1FGd4OEkKPDZ2zOtaozT=SX+w69tg-YFagVf22Sg@mail.gmail.com> <CABDkGQ=bjsBDvbwX81dUa=w3N8J4Cw51e4RoCkCbcttuPH626A@mail.gmail.com>
Message-ID: <4E9F1D47.3080305@ais.uni-bonn.de>

On 10/19/2011 08:44 PM, St??????fan van der Walt wrote:
> On Wed, Oct 19, 2011 at 9:57 AM, Ralf Gommers
> <ralf.gommers at googlemail.com>  wrote:
>>> Does anyone here have experience with such approaches?
>>>
>> scipy.interpolate has Cython code with simple Mako templating, look at
>> interpnd.pyx and generate_interpnd.py. If it's flexible enough for your
>> needs then it'll be a lot more pleasant than using C++.
> This definitely gets us some way.  We can modify our _build.cython
> call to first run the template engine on any .tpyx files.
>
> But how should we dispatch to different functions, based on dtype?
> Let's say we have support for int16, uint16 and double in our
> algorithm, so via templating we'll get
>
> myfunc_int16
> myfunc_uint16
> myfunc_double
>
> for a single input argument (which is the most common case).  We can
> then define a dispatch call such as
>
> dtype_call('myfunc', img.dtype)
>
> which calls the appropriate function.  Does this sound about right?
Sounds sensible. Doing the overloading "by hand" looks a
bit ugly but it seems cython does not do overloading of
cython functions: http://wiki.cython.org/enhancements/overloading
Overloaded C++ functions on the other hand seem to be no problem 
<http://wiki.cython.org/WrappingCPlusPlus>.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111019/e0eebff6/attachment.html>

From emmanuelle.gouillart at nsup.org  Sun Oct 23 15:34:25 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Sun, 23 Oct 2011 21:34:25 +0200
Subject: Renaming / 0.4 timeline
In-Reply-To: <CABDkGQ=4gsArXEzhhK8KbT62VGCwM1Y+5F=j55iivOiVqiVxvA@mail.gmail.com>
References: <CABDkGQ=b2t7gya=Ns_M3HZNfS8XH+4tUrJKe878HzZAKhUWkFg@mail.gmail.com>
 <20111018193227.GB26732@phare.normalesup.org>
 <CABDkGQ=4gsArXEzhhK8KbT62VGCwM1Y+5F=j55iivOiVqiVxvA@mail.gmail.com>
Message-ID: <20111023193425.GA22486@phare.normalesup.org>


> Tue Oct 18th to Sat Oct 22nd : File and merge PRs of work-in-progress
> made against the current repo

I've merged Neil's skeletonization PR and filed a new PR with a
refactored version of cell profiler's skeletonize algorithm (now called
medial axis). Neil, would you have the time to review this code? 
https://github.com/scikits-image/scikits.image/pull/65

St??????fan, could you make a list of open PRs (as you had done for 0.3) with
priorities (those that have to be merged before the release) and requests
for help on code reviewing, if needed? The renaming PR surely has to be
merged, but it will be the last one. If the authors of open PRs can also
say when they will be finished implementing suggestions / if they have
already done so / if they are waiting for feedback, that would also help
for the planning...

Cheers,
Emmanuelle


From nelle.varoquaux at gmail.com  Sun Oct 23 16:32:34 2011
From: nelle.varoquaux at gmail.com (Nelle Varoquaux)
Date: Sun, 23 Oct 2011 22:32:34 +0200
Subject: Renaming / 0.4 timeline
In-Reply-To: <20111023193425.GA22486@phare.normalesup.org>
References: <CABDkGQ=b2t7gya=Ns_M3HZNfS8XH+4tUrJKe878HzZAKhUWkFg@mail.gmail.com>
	<20111018193227.GB26732@phare.normalesup.org>
	<CABDkGQ=4gsArXEzhhK8KbT62VGCwM1Y+5F=j55iivOiVqiVxvA@mail.gmail.com>
	<20111023193425.GA22486@phare.normalesup.org>
Message-ID: <CAE-UAvTsQoFr6t0cnF7hibginWqWS4cr_oTU-ZxcZQELvD1v2g@mail.gmail.com>

On 23 October 2011 21:34, Emmanuelle Gouillart <
emmanuelle.gouillart at nsup.org> wrote:

>
> > Tue Oct 18th to Sat Oct 22nd : File and merge PRs of work-in-progress
> > made against the current repo
>
> I've merged Neil's skeletonization PR and filed a new PR with a
> refactored version of cell profiler's skeletonize algorithm (now called
> medial axis). Neil, would you have the time to review this code?
> https://github.com/scikits-image/scikits.image/pull/65
>
> St?fan, could you make a list of open PRs (as you had done for 0.3) with
> priorities (those that have to be merged before the release) and requests
> for help on code reviewing, if needed? The renaming PR surely has to be
> merged, but it will be the last one. If the authors of open PRs can also
> say when they will be finished implementing suggestions / if they have
> already done so / if they are waiting for feedback, that would also help
> for the planning...
>

If no one is against, I'll rebase regularly the code, and update the pull
request with the incoming patches.

Cheers,
N.



> Cheers,
> Emmanuelle
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111023/39746e8f/attachment.html>

From stefan at sun.ac.za  Mon Oct 24 02:05:25 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 23 Oct 2011 23:05:25 -0700
Subject: Package rename, repo move complete
Message-ID: <CABDkGQ=p6yraouyHP-96Z8r8st2sdmf3kUOR8fiZotfxbMBn9w@mail.gmail.com>

Hi all,

I've merged the pull request by Nelle Varoquaux for renaming the
package to "skimage".  Please note that:

1) Code needs to be updated to read "from skimage import ..." instead
of "from scikits.image import ...".
2) The repository has moved, and now lives at

https://github.com/scikits-image/scikits-image
git at github.com:scikits-image/scikits-image.git

Please scan the docs, build scripts, etc. and make sure we didn't miss anything!

Nelle, thanks for taking the trouble to do this!

St?fan


From stefan at sun.ac.za  Mon Oct 24 02:34:34 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 23 Oct 2011 23:34:34 -0700
Subject: Roadmap to 0.4
Message-ID: <CABDkGQk33dzMiiOTRx9epz9BU2sQKMmegtT0-yL=4aX6RU4Niw@mail.gmail.com>

Hi all,

Emmanuelle mentioned that it would be useful to have a list of PRs and their
priorities for the next release.  Also read on for design decisions, and
other minor tasks.

*PRs almost ready to merge:
*
- https://github.com/scikits-image/scikits-image/pull/65
 Add medial axis skeletonization.  Neil Yager's skeletonization code has
already been merged, and this is the version from cellprofiler.

*PRs requiring minor refactoring / cleanup:
*
- https://github.com/scikits-image/scikits-image/pull/13
 Template matching.  Needs to be modified to use existing integral_image,
and the example needs to be converted to the right format.

- https://github.com/scikits-image/scikits-image/pull/61
 Fix for correctly converting alpha-layered images to gray.  It's a minor
fix, but this PR does it in the wrong place.

*PRs requiring more work:*

- https://github.com/scikits-image/scikits-image/pull/41
 Structural similarity indices.  Would be great to have, but PR comments
need to be addressed.

- https://github.com/scikits-image/scikits-image/pull/16
 Fast convolution using SSE2 instructions.  This is a proof of concept done
by Pieter Holtzhausen for GSoC.  It needs to be updated to use zeros outside
image boundaries.  We also need benchmarks, and to remove opencv
dependencies in the tests.

*Other remaining tasks:*
*
*
- Update Debian license info (I never finished this)
- Write a man-page for "scivi"
- While our Debian package should probably be "python-scikits-image", the
scikit-learn guys already called theirs "sklearn", so the Debian package
needs to be updated to this convention
- Update Cython build script to generate hashes of .pyx files so that we
don't always re-generate Cython, even on clean builds
- Write examples and docs (especially narrative docs)!

*Design Decisions:
*
- Support for multiple computation back-ends

Pieter Holtzhausen has a PR in the queue for this after his GSoC.  The idea
is to provide a way for users to write code that make use of alternative
computation backends, e.g. OpenCL, but without requiring the scikits-image
developers to pick up that burden.  For example, you could do:

use_backend('opencl')
import skimage as ski
ski.do_some_stuff()
ski.do_some_more_stuff()

The user would provide the OpenCL implementation, but can easily fall back
to pure scikits-image by removing the first line.

The question here is: are we all agreed that this is a good idea?  It
increases the package flexibility a lot, at the cost of some code complexity
(hopefully mostly hidden from the user).


Allright, I think that's about it.  We have another week to include new
changes before 0.4, so feel free to file new pull requests until then.

Thanks, all!

St?fan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111023/18b13cba/attachment.html>

From stefan at sun.ac.za  Mon Oct 24 20:25:45 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 24 Oct 2011 17:25:45 -0700
Subject: Roadmap to 0.4
In-Reply-To: <CABDkGQk33dzMiiOTRx9epz9BU2sQKMmegtT0-yL=4aX6RU4Niw@mail.gmail.com>
References: <CABDkGQk33dzMiiOTRx9epz9BU2sQKMmegtT0-yL=4aX6RU4Niw@mail.gmail.com>
Message-ID: <CABDkGQ=vEt5bmMejccpzycLsmQQiw42kkrLBu+ApxxJoC=UWbA@mail.gmail.com>

2011/10/23 St?fan van der Walt <stefan at sun.ac.za>:
> - Support for multiple computation back-ends

Would anyone like to comment on this issue?

St?fan


From yager.neil at gmail.com  Tue Oct 25 04:05:31 2011
From: yager.neil at gmail.com (Neil Yager)
Date: Tue, 25 Oct 2011 01:05:31 -0700 (PDT)
Subject: Renaming scikits.image to skimage
In-Reply-To: <CAEym_HqVxr2mTiUKODB6zn5w9xWsPVMU7TGn91Gaf3SS0K49OA@mail.gmail.com>
References: <CAE-UAvSq_2nCh1Cr75EqhhpqBAV45nxL32fBoe-Zoz72-A9Eeg@mail.gmail.com>
 <CAEym_HqVxr2mTiUKODB6zn5w9xWsPVMU7TGn91Gaf3SS0K49OA@mail.gmail.com>
Message-ID: <cef27f23-87b8-45f9-b472-d1012b244939@c25g2000yqn.googlegroups.com>

> I'm running cython 14.1 and numpy dev (and scipy dev), so my system isn't
> exactly a match. But I can't imagine how these differences could change the
> test behavior before and after the renaming. Are you sure the test passed
> before the rename?

I'm getting the same error before and after the rename. Numpy 1.6.1
and Cython 0.15

Neil


From stefan at sun.ac.za  Tue Oct 25 04:45:52 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 25 Oct 2011 01:45:52 -0700
Subject: Renaming scikits.image to skimage
In-Reply-To: <cef27f23-87b8-45f9-b472-d1012b244939@c25g2000yqn.googlegroups.com>
References: <CAE-UAvSq_2nCh1Cr75EqhhpqBAV45nxL32fBoe-Zoz72-A9Eeg@mail.gmail.com>
	<CAEym_HqVxr2mTiUKODB6zn5w9xWsPVMU7TGn91Gaf3SS0K49OA@mail.gmail.com>
	<cef27f23-87b8-45f9-b472-d1012b244939@c25g2000yqn.googlegroups.com>
Message-ID: <CABDkGQmUigHgcrs=t9bekftKMgFWqOYxbQo=BDMOP=MZboCaYg@mail.gmail.com>

Remind me which error again?
On Oct 25, 2011 1:15 AM, "Neil Yager" <yager.neil at gmail.com> wrote:

> > I'm running cython 14.1 and numpy dev (and scipy dev), so my system isn't
> > exactly a match. But I can't imagine how these differences could change
> the
> > test behavior before and after the renaming. Are you sure the test passed
> > before the rename?
>
> I'm getting the same error before and after the rename. Numpy 1.6.1
> and Cython 0.15
>
> Neil
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111025/b330fb6f/attachment.html>

From yager.neil at gmail.com  Tue Oct 25 04:58:28 2011
From: yager.neil at gmail.com (Neil Yager)
Date: Tue, 25 Oct 2011 01:58:28 -0700 (PDT)
Subject: Renaming scikits.image to skimage
In-Reply-To: <cef27f23-87b8-45f9-b472-d1012b244939@c25g2000yqn.googlegroups.com>
References: <CAE-UAvSq_2nCh1Cr75EqhhpqBAV45nxL32fBoe-Zoz72-A9Eeg@mail.gmail.com>
 <CAEym_HqVxr2mTiUKODB6zn5w9xWsPVMU7TGn91Gaf3SS0K49OA@mail.gmail.com> <cef27f23-87b8-45f9-b472-d1012b244939@c25g2000yqn.googlegroups.com>
Message-ID: <6a7e2e21-f617-4df9-a58c-65d017a8d5ac@j7g2000yqi.googlegroups.com>

The problem is that the image in test_homography() is of type
numpy.int32, which scipy.ndimage.interpolation.geometric_transform()
doesn't support (at least for scipy 0.9.0).

I've submitted a PR for the fix.

Neil

On Oct 25, 9:05?am, Neil Yager <yager.n... at gmail.com> wrote:
> > I'm running cython 14.1 and numpy dev (and scipy dev), so my system isn't
> > exactly a match. But I can't imagine how these differences could change the
> > test behavior before and after the renaming. Are you sure the test passed
> > before the rename?
>
> I'm getting the same error before and after the rename. Numpy 1.6.1
> and Cython 0.15
>
> Neil


From amueller at ais.uni-bonn.de  Tue Oct 25 03:17:29 2011
From: amueller at ais.uni-bonn.de (Andreas Mueller)
Date: Tue, 25 Oct 2011 09:17:29 +0200
Subject: Roadmap to 0.4
In-Reply-To: <CABDkGQ=vEt5bmMejccpzycLsmQQiw42kkrLBu+ApxxJoC=UWbA@mail.gmail.com>
References: <CABDkGQk33dzMiiOTRx9epz9BU2sQKMmegtT0-yL=4aX6RU4Niw@mail.gmail.com> <CABDkGQ=vEt5bmMejccpzycLsmQQiw42kkrLBu+ApxxJoC=UWbA@mail.gmail.com>
Message-ID: <4EA66289.4010904@ais.uni-bonn.de>

On 10/25/2011 02:25 AM, St??????fan van der Walt wrote:
> 2011/10/23 St??????fan van der Walt<stefan at sun.ac.za>:
>> - Support for multiple computation back-ends
> Would anyone like to comment on this issue?
>
> St??????fan

Could you give an example on how you picture this?
I think I get the general idea but I'm not sure how you would implement it.
You want the user to provide some other computational backend that
is somehow plugged into scikits-image, as far as i understand.

Also: Do you think the easy switching between the implementations
is a good enough reason for the additional complexity?

I often use CUDA functions in my programs but they are usually just
wrapped in some python package. I never really saw the need to fall back
on other implementations once I included them. Why is that important?

Don't get me wrong, I'm not as opposed as it might sound, I'm just
trying to figure the idea out ;)

Andy


From emmanuelle.gouillart at nsup.org  Tue Oct 25 16:20:23 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Tue, 25 Oct 2011 22:20:23 +0200
Subject: documentation marathon :-)
Message-ID: <20111025202023.GA25495@phare.normalesup.org>

	Hello,

as I was browsing through the scikit, I started to make a list of
functions for which we don't have examples (neither in their docstring,
nor an example script for the documentation/example gallery). I copy it
here, since it seems a priority to me that we have more examples in the
documentation. I was thinking of writing an example of edge detection wih
canny and sobel, and completing their docstrings while I'm at this. Any
other volunteer to make this list shrink :-)?

Cheers,
Emmanuelle

------------

feature: hog 

filter: median_filter, canny, sobel, prewitt, wiener

graph: shortest_path, MCP

morphology: 
* structuring elements in selem.py don't have examples in docstrings. 
* In grey.py, Tony added recently examples in all the
docstrings -- it'd be great to have also a few examples for the gallery
* label doesn't have examples

transform: probabilistic_hough, homography, integral_image, integrate
radon and iradon do not have examples in docstrings (but they do have a nice 
example in the gallery)


From yager.neil at gmail.com  Wed Oct 26 04:51:32 2011
From: yager.neil at gmail.com (Neil Yager)
Date: Wed, 26 Oct 2011 01:51:32 -0700 (PDT)
Subject: Image data type ranges
Message-ID: <fd09e75c-357b-4909-9ff5-a4ef564a56ed@m19g2000yqh.googlegroups.com>

I was having conversation about data types with St?fan in the line
comments of a PR, and I thought I should move it here so others can
benefit from his explanations as well.

Being new to the project, I didn't appreciate the intricacies of data
typing. For example, I was surprised to see that this raises a
ValueError:

>>> skimage.img_as_float(np.arange(9).reshape((3, 3)))

The problem is that the default dtype of np.arange is int32, which
isn't supported by skimage, so img_as_float doesn't know how to scale
it to [0, 1]. Perhaps it is correct to fail, as it will force the user
to consider the data type issue. However, it does seem like a
reasonable/common thing to want to do.

A related, but different, issue is the following:

>>> x = np.arange(9, dtype=np.uint8).reshape((3, 3))
>>> x
array([[0, 1, 2],
       [3, 4, 5],
       [6, 7, 8]], dtype=uint8)
>>> y =  skimage.img_as_ubyte(x.astype(np.float32))
WARNING:dtype_converter:Possible precision loss, converting from
float32 to uint8
>>> y
array([[  0, 255, 254],
       [253, 252, 251],
       [250, 249, 248]], dtype=uint8)

The problem here is that the input to img_as_ubyte violates skimage's
assumption that floating point images have the range [0, 1], leading
to an unexpected result (at least for a beginner). There is a warning,
but that's for a different problem. Should img_as_ubyte, img_as_float,
etc. check and enforce ranges? Or raise warnings? Any thoughts?

Neil


From yager.neil at gmail.com  Wed Oct 26 06:51:33 2011
From: yager.neil at gmail.com (Neil Yager)
Date: Wed, 26 Oct 2011 03:51:33 -0700 (PDT)
Subject: Image data type ranges
In-Reply-To: <4EA7DB98.9080005@ais.uni-bonn.de>
References: <fd09e75c-357b-4909-9ff5-a4ef564a56ed@m19g2000yqh.googlegroups.com>
 <4EA7DB98.9080005@ais.uni-bonn.de>
Message-ID: <bf31f402-3556-4d30-970a-8c48e03b2f91@x20g2000vbl.googlegroups.com>

> I do not think that using an np.arange(n) is a reasonable/common
> to do by the way. What is the expected behavior?

I've seen it used for demo/testing for quickly creating an array with
a range of values (it is being used in a unit test). In the context of
this discussion, it is just an example of a way a user may end up with
an array of int32s without really thinking about it, thereby getting
themselves into trouble.

> Maybe we can check whether the upper bound is satisfied. That
> probably wouldn't hurt much if we convert any way.

I think that might be the best way.

> Also, we should stress in the (at the moment not really existing)
> user guide, that users should NEVER EVER use "astype" on an image,
> since that violates all our assumptions.

I completely agree. However, the explicit use of "astype" is just one
of many ways to find yourself in this situation. e.g.:

>>> x = np.arange(9).reshape((3, 3)) + 1.
>>> y = skimage.img_as_ubyte(x)
>>> y
array([[255, 254, 253],
       [252, 251, 250],
       [249, 248, 247]], dtype=uint8)

The core issue is to make sure that users know the assumed range for
floats.

Neil


From yager.neil at gmail.com  Wed Oct 26 07:14:27 2011
From: yager.neil at gmail.com (Neil Yager)
Date: Wed, 26 Oct 2011 04:14:27 -0700 (PDT)
Subject: documentation marathon :-)
In-Reply-To: <20111025202023.GA25495@phare.normalesup.org>
References: <20111025202023.GA25495@phare.normalesup.org>
Message-ID: <6d87a2ca-e6a4-4abc-ba1f-f62fd6a35181@f5g2000vbz.googlegroups.com>

> transform: probabilistic_hough, homography, integral_image, integrate
> radon and iradon do not have examples in docstrings (but they do have a nice
> example in the gallery)

You can knock homography off the list. I've reformatted the docstring
to include a doctest.

Neil


From stefan at sun.ac.za  Wed Oct 26 13:07:17 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 26 Oct 2011 10:07:17 -0700
Subject: Image data type ranges
In-Reply-To: <CAHGWWxEBaeS4QHF+t+QLeVa8NdpDX-PapQUj5xRLagHsOEUKbQ@mail.gmail.com>
References: <fd09e75c-357b-4909-9ff5-a4ef564a56ed@m19g2000yqh.googlegroups.com>
 <4EA7DB98.9080005@ais.uni-bonn.de> <bf31f402-3556-4d30-970a-8c48e03b2f91@x20g2000vbl.googlegroups.com>
 <4EA7ECDF.30607@ais.uni-bonn.de> <CAHGWWxEBaeS4QHF+t+QLeVa8NdpDX-PapQUj5xRLagHsOEUKbQ@mail.gmail.com>
Message-ID: <CABDkGQmgBZ=g7=461s7Le+O1KfF9kL7VxVk=1ETdkQ8PxkmJSg@mail.gmail.com>

On Wed, Oct 26, 2011 at 6:40 AM, Thouis Jones <thouis at gmail.com> wrote:
> On Wed, Oct 26, 2011 at 11:19, Andreas Mueller <amueller at ais.uni-bonn.de> wrote:
>> You're right. Maybe there is no way to avoid having the user create
>> arrays with unexpected types.
>> I think if we check the ranges and throw errors, the users
>> should get the idea.
>
> Where, besides file input and output, does the scikit have algorithmic
> assumptions about images having a particular data format or range?
> How many of these can be wrapped in such a way that there are no
> assumptions about input range (i.e., by prescaling min/max to [0,1]
> and postscaling back to the original range)?

The problem is that you can only scale if you know the lower and upper
bounds of values; in our case, we choose to find that information
through a convention:

uint8 -> [0, 255]; float -> [0,1]; etc.

Now, consider the following routine:

def add_half(x):
    return x + 0.5

That looks innocent enough, but it has at least two subtle problems:
1) It has an entirely different effect on float and int images (both
because of the relative magnitude, and because of data-types) and 2)
It may take an integer image as input and return a float image.  These
are very differently interpreted by, for example, display routines!

After our previous rounds of discussions, we came up with the following policy:

1) Functions should take any input, as far as possible
2) Functions may return output in any format, as long as it's documented

This allows the user to build long pipelines without caring about
data-types, e.g.:

display_image = img_as_ubyte(func1(func2(input_image)))

To support this, functions have to convert the input arguments
appropriately, so the correct way to write add_half would be:

def add_half(x):
    return img_as_float(x) + 0.5

Now, the error messages in the dtype conversion functions may still be
improved a lot.  We may use them to guide users to the problem, e.g.
telling them why there is precision loss, or why we do not convert
from int32 to float.

Apart from floating point dtypes, all others constrain the values they
contain naturally.  So, for float, we can consider ensuring that no
abs-values are greater than one.

St?fan


From stefan at sun.ac.za  Wed Oct 26 14:22:59 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 26 Oct 2011 11:22:59 -0700
Subject: Roadmap to 0.4
In-Reply-To: <4EA66289.4010904@ais.uni-bonn.de>
References: <CABDkGQk33dzMiiOTRx9epz9BU2sQKMmegtT0-yL=4aX6RU4Niw@mail.gmail.com>
 <CABDkGQ=vEt5bmMejccpzycLsmQQiw42kkrLBu+ApxxJoC=UWbA@mail.gmail.com> <4EA66289.4010904@ais.uni-bonn.de>
Message-ID: <CABDkGQkvkQUjUxNDzhczGEsZoN6WOKoDTBGaxRFhKpL1pGMKaw@mail.gmail.com>

Hi Andy,

Sorry for the late reply.

On Tue, Oct 25, 2011 at 12:17 AM, Andreas Mueller
<amueller at ais.uni-bonn.de> wrote:
>>> - Support for multiple computation back-ends
>>
>> Would anyone like to comment on this issue?
>
> Could you give an example on how you picture this?
> I think I get the general idea but I'm not sure how you would implement it.
> You want the user to provide some other computational backend that
> is somehow plugged into scikits-image, as far as i understand.
>
> Also: Do you think the easy switching between the implementations
> is a good enough reason for the additional complexity?

I've learnt that we cannot satisfy all the people all of the time.
Some people want interesting algorithms, other people want very fast
execution times.  Since we can't write code for all those use cases at
the same time, I think our best option is to help them achieve their
goal with minimum effort.

So, all that this framework allows you to do is basically "outsource"
skimage functions.  For example, you can say:

"Instead of calling sobel from skimage, use this sobel implementation
I found in opencv"

Usually, this will require you to write code that can only be run on
an opencv system, but with the plugin system you can easily share that
code with colleagues who do not have opencv installed:

use_backend('my_opencv_routines')
output = sobel(input)

If the opencv backend is not found, the backend gracefully falls back
to the NumPy / Cython implementation.

Yes, the complexity opens some doors for weird things to happen.  For
example, if implementations (say, e.g., opencv vs.
CUDA vs NumPy) return subtly different results, your script won't give
the same result on all machines.  To compensate, we've added utility
functions to the test suite, so that you can do:

@add_backends
def mytest():
    for b in backends:
        output = sobel(input, backend=b)
        [...check_output...]

> Don't get me wrong, I'm not as opposed as it might sound, I'm just
> trying to figure the idea out ;)

All critical feedback is most welcome (and necessary)!  Let's keep the
discussion going.

Cheers
St?fan


From amueller at ais.uni-bonn.de  Wed Oct 26 06:06:16 2011
From: amueller at ais.uni-bonn.de (Andreas Mueller)
Date: Wed, 26 Oct 2011 12:06:16 +0200
Subject: Image data type ranges
In-Reply-To: <fd09e75c-357b-4909-9ff5-a4ef564a56ed@m19g2000yqh.googlegroups.com>
References: <fd09e75c-357b-4909-9ff5-a4ef564a56ed@m19g2000yqh.googlegroups.com>
Message-ID: <4EA7DB98.9080005@ais.uni-bonn.de>

Am 26.10.2011 10:51, schrieb Neil Yager:
> I was having conversation about data types with St??????fan in the line
> comments of a PR, and I thought I should move it here so others can
> benefit from his explanations as well.
>
> Being new to the project, I didn't appreciate the intricacies of data
> typing.

After working with images for some time. This still annoys me.
And I don't know of a library having a good solution.
OpenCV for example is a mess. I think this is a very important
topic since it influences usability a lot.

>   For example, I was surprised to see that this raises a
> ValueError:
>
>>>> skimage.img_as_float(np.arange(9).reshape((3, 3)))
> The problem is that the default dtype of np.arange is int32, which
> isn't supported by skimage, so img_as_float doesn't know how to scale
> it to [0, 1]. Perhaps it is correct to fail, as it will force the user
> to consider the data type issue. However, it does seem like a
> reasonable/common thing to want to do.
>
We briefly discussed this issue on the list and Stefan thought
it would be good to make the user think about what they
want to achieve. I find this not completely satisfying but
I could not come up with a better solution.

I do not think that using an np.arange(n) is a reasonable/common
to do by the way. What is the expected behavior?
By definition, the output can be in any range. If you fix any range,
either you'll get out of it for large n or you'll see nothing for small n.

Maybe the most reasonable thing would be to expect that
img_as_float(np.arange(n)) always returns something with
minimum 0 and maximum 1.
The only way to achieve that would be to determine the range
of an int image by taking the max, each time you use it.
This of course would lead to unexpected behavior in other
places. So I'm not sure if it actually makes things better.

We'd have to be careful.

> A related, but different, issue is the following:
>
>>>> x = np.arange(9, dtype=np.uint8).reshape((3, 3))
>>>> x
> array([[0, 1, 2],
>         [3, 4, 5],
>         [6, 7, 8]], dtype=uint8)
>>>> y =  skimage.img_as_ubyte(x.astype(np.float32))
> WARNING:dtype_converter:Possible precision loss, converting from
> float32 to uint8
>>>> y
> array([[  0, 255, 254],
>         [253, 252, 251],
>         [250, 249, 248]], dtype=uint8)
>
I think this is perfectly fine. You used "astype". That's evil!

> The problem here is that the input to img_as_ubyte violates skimage's
> assumption that floating point images have the range [0, 1], leading
> to an unexpected result (at least for a beginner). There is a warning,
> but that's for a different problem. Should img_as_ubyte, img_as_float,
> etc. check and enforce ranges? Or raise warnings? Any thoughts?
Maybe we can check whether the upper bound is satisfied. That
probably wouldn't hurt much if we convert any way.

Also, we should stress in the (at the moment not really existing)
user guide, that users should NEVER EVER use "astype" on an image,
since that violates all our assumptions.

Cheers,
Andy


From amueller at ais.uni-bonn.de  Wed Oct 26 07:19:59 2011
From: amueller at ais.uni-bonn.de (Andreas Mueller)
Date: Wed, 26 Oct 2011 13:19:59 +0200
Subject: Image data type ranges
In-Reply-To: <bf31f402-3556-4d30-970a-8c48e03b2f91@x20g2000vbl.googlegroups.com>
References: <fd09e75c-357b-4909-9ff5-a4ef564a56ed@m19g2000yqh.googlegroups.com> <4EA7DB98.9080005@ais.uni-bonn.de> <bf31f402-3556-4d30-970a-8c48e03b2f91@x20g2000vbl.googlegroups.com>
Message-ID: <4EA7ECDF.30607@ais.uni-bonn.de>

Am 26.10.2011 12:51, schrieb Neil Yager:
>> I do not think that using an np.arange(n) is a reasonable/common
>> to do by the way. What is the expected behavior?
> I've seen it used for demo/testing for quickly creating an array with
> a range of values (it is being used in a unit test). In the context of
> this discussion, it is just an example of a way a user may end up with
> an array of int32s without really thinking about it, thereby getting
> themselves into trouble.
>
So what do you suggest on the int front?
> The core issue is to make sure that users know the assumed range for
> floats.
You're right. Maybe there is no way to avoid having the user create
arrays with unexpected types.
I think if we check the ranges and throw errors, the users
should get the idea.

Cheers,
Andy


From emmanuelle.gouillart at nsup.org  Wed Oct 26 07:23:53 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Wed, 26 Oct 2011 13:23:53 +0200
Subject: documentation marathon :-)
In-Reply-To: <6d87a2ca-e6a4-4abc-ba1f-f62fd6a35181@f5g2000vbz.googlegroups.com>
References: <20111025202023.GA25495@phare.normalesup.org>
 <6d87a2ca-e6a4-4abc-ba1f-f62fd6a35181@f5g2000vbz.googlegroups.com>
Message-ID: <20111026112353.GB25286@phare.normalesup.org>

On Wed, Oct 26, 2011 at 04:14:27AM -0700, Neil Yager wrote:
> > transform: probabilistic_hough, homography, integral_image, integrate
> > radon and iradon do not have examples in docstrings (but they do have a nice
> > example in the gallery)

> You can knock homography off the list. I've reformatted the docstring
> to include a doctest.

great, thanks :-D!


From thouis at gmail.com  Wed Oct 26 09:40:26 2011
From: thouis at gmail.com (Thouis Jones)
Date: Wed, 26 Oct 2011 13:40:26 +0000
Subject: Image data type ranges
In-Reply-To: <4EA7ECDF.30607@ais.uni-bonn.de>
References: <fd09e75c-357b-4909-9ff5-a4ef564a56ed@m19g2000yqh.googlegroups.com>
 <4EA7DB98.9080005@ais.uni-bonn.de> <bf31f402-3556-4d30-970a-8c48e03b2f91@x20g2000vbl.googlegroups.com>
 <4EA7ECDF.30607@ais.uni-bonn.de>
Message-ID: <CAHGWWxEBaeS4QHF+t+QLeVa8NdpDX-PapQUj5xRLagHsOEUKbQ@mail.gmail.com>

On Wed, Oct 26, 2011 at 11:19, Andreas Mueller <amueller at ais.uni-bonn.de> wrote:
> You're right. Maybe there is no way to avoid having the user create
> arrays with unexpected types.
> I think if we check the ranges and throw errors, the users
> should get the idea.

Where, besides file input and output, does the scikit have algorithmic
assumptions about images having a particular data format or range?
How many of these can be wrapped in such a way that there are no
assumptions about input range (i.e., by prescaling min/max to [0,1]
and postscaling back to the original range)?

This has been an ongoing problem for us in CellProfiler.  We usually
assume that images are [0,1], but try to avoid making it a hard
assumption.  There are times when images are completely ouside this
range, such as when we compute an illumination correction image, which
we put into the range [1,X] so that when a [0,1] image is divided by
the illumination correction, it remains in [0,1].

Ray Jones


From stefan at sun.ac.za  Wed Oct 26 18:35:53 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 26 Oct 2011 15:35:53 -0700
Subject: Image data type ranges
In-Reply-To: <4EA87FCD.4090208@ais.uni-bonn.de>
References: <fd09e75c-357b-4909-9ff5-a4ef564a56ed@m19g2000yqh.googlegroups.com>
 <4EA7DB98.9080005@ais.uni-bonn.de> <bf31f402-3556-4d30-970a-8c48e03b2f91@x20g2000vbl.googlegroups.com>
 <4EA7ECDF.30607@ais.uni-bonn.de> <CAHGWWxEBaeS4QHF+t+QLeVa8NdpDX-PapQUj5xRLagHsOEUKbQ@mail.gmail.com>
 <CABDkGQmgBZ=g7=461s7Le+O1KfF9kL7VxVk=1ETdkQ8PxkmJSg@mail.gmail.com> <4EA87FCD.4090208@ais.uni-bonn.de>
Message-ID: <CABDkGQk3CMuQtdo_=YDkVEOu+m1yy43siha07a8okcPAJ4OobA@mail.gmail.com>

On Wed, Oct 26, 2011 at 2:46 PM, Andreas Mueller
<amueller at ais.uni-bonn.de> wrote:
> On 10/26/2011 07:07 PM, St?fan van der Walt wrote:
>>
>> Apart from floating point dtypes, all others constrain the values they
>> contain naturally. So, for float, we can consider ensuring that no
>> abs-values are greater than one. St?fan

You're right, for floats we don't support negative numbers.


From amueller at ais.uni-bonn.de  Wed Oct 26 09:52:32 2011
From: amueller at ais.uni-bonn.de (Andreas Mueller)
Date: Wed, 26 Oct 2011 15:52:32 +0200
Subject: Image data type ranges
In-Reply-To: <CAHGWWxEBaeS4QHF+t+QLeVa8NdpDX-PapQUj5xRLagHsOEUKbQ@mail.gmail.com>
References: <fd09e75c-357b-4909-9ff5-a4ef564a56ed@m19g2000yqh.googlegroups.com> <4EA7DB98.9080005@ais.uni-bonn.de> <bf31f402-3556-4d30-970a-8c48e03b2f91@x20g2000vbl.googlegroups.com> <4EA7ECDF.30607@ais.uni-bonn.de> <CAHGWWxEBaeS4QHF+t+QLeVa8NdpDX-PapQUj5xRLagHsOEUKbQ@mail.gmail.com>
Message-ID: <4EA810A0.5070101@ais.uni-bonn.de>


> Where, besides file input and output, does the scikit have algorithmic
> assumptions about images having a particular data format or range?
I think most of the algorithms now start with a conversion to
float, which makes assumptions.
> How many of these can be wrapped in such a way that there are no
> assumptions about input range (i.e., by prescaling min/max to [0,1]
> and postscaling back to the original range)?
>
Prescaling between zero and one might distort the image
heavily if the image did not have the full range, for example
if it is mostly white and has no black.

What do you mean by postscaling? Algorithms usually don't
return an image. Even if an algorithm returns an image,
your method would only work correctly if the output
depends linearly on the input.

Cheers,
Andy


From stefan at sun.ac.za  Thu Oct 27 02:36:32 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 26 Oct 2011 23:36:32 -0700
Subject: Pull requests for today
Message-ID: <CABDkGQnwt42MfHGEpq3ZF6qE03PhxsqPTzbGqaUTqL+YwdJpdQ@mail.gmail.com>

Hi all,

As you can see, I've been very distracted from work this evening :)

Binary convex hull goodness:
https://github.com/scikits-image/scikits-image/pull/75

Super-fast re-building of the package for developers, using MD5 hashes
of Python files:
https://github.com/scikits-image/scikits-image/pull/74

Coin dataset--almost as good as the real thing:
https://github.com/scikits-image/scikits-image/pull/76

Please have a look, and let me have your critical yet witty feedback
on GitHub :)

Cheers
St?fan


From amueller at ais.uni-bonn.de  Wed Oct 26 17:45:08 2011
From: amueller at ais.uni-bonn.de (Andreas Mueller)
Date: Wed, 26 Oct 2011 23:45:08 +0200
Subject: Image data type ranges
In-Reply-To: <CABDkGQmgBZ=g7=461s7Le+O1KfF9kL7VxVk=1ETdkQ8PxkmJSg@mail.gmail.com>
References: <fd09e75c-357b-4909-9ff5-a4ef564a56ed@m19g2000yqh.googlegroups.com> <4EA7DB98.9080005@ais.uni-bonn.de> <bf31f402-3556-4d30-970a-8c48e03b2f91@x20g2000vbl.googlegroups.com> <4EA7ECDF.30607@ais.uni-bonn.de> <CAHGWWxEBaeS4QHF+t+QLeVa8NdpDX-PapQUj5xRLagHsOEUKbQ@mail.gmail.com> <CABDkGQmgBZ=g7=461s7Le+O1KfF9kL7VxVk=1ETdkQ8PxkmJSg@mail.gmail.com>
Message-ID: <4EA87F64.6000807@ais.uni-bonn.de>

Apart from floating point dtypes, all others constrain the values they 
contain naturally. So, for float, we can consider ensuring that no 
abs-values are greater than one. St??????fan



From amueller at ais.uni-bonn.de  Wed Oct 26 17:46:53 2011
From: amueller at ais.uni-bonn.de (Andreas Mueller)
Date: Wed, 26 Oct 2011 23:46:53 +0200
Subject: Image data type ranges
In-Reply-To: <CABDkGQmgBZ=g7=461s7Le+O1KfF9kL7VxVk=1ETdkQ8PxkmJSg@mail.gmail.com>
References: <fd09e75c-357b-4909-9ff5-a4ef564a56ed@m19g2000yqh.googlegroups.com> <4EA7DB98.9080005@ais.uni-bonn.de> <bf31f402-3556-4d30-970a-8c48e03b2f91@x20g2000vbl.googlegroups.com> <4EA7ECDF.30607@ais.uni-bonn.de> <CAHGWWxEBaeS4QHF+t+QLeVa8NdpDX-PapQUj5xRLagHsOEUKbQ@mail.gmail.com> <CABDkGQmgBZ=g7=461s7Le+O1KfF9kL7VxVk=1ETdkQ8PxkmJSg@mail.gmail.com>
Message-ID: <4EA87FCD.4090208@ais.uni-bonn.de>

On 10/26/2011 07:07 PM, St??????fan van der Walt wrote:
> Apart from floating point dtypes, all others constrain the values they 
> contain naturally. So, for float, we can consider ensuring that no 
> abs-values are greater than one. St??????fan 
Why abs-values? Shouldn't the values be >0 any way?


From amueller at ais.uni-bonn.de  Wed Oct 26 18:04:10 2011
From: amueller at ais.uni-bonn.de (Andreas Mueller)
Date: Thu, 27 Oct 2011 00:04:10 +0200
Subject: Roadmap to 0.4
In-Reply-To: <CABDkGQkvkQUjUxNDzhczGEsZoN6WOKoDTBGaxRFhKpL1pGMKaw@mail.gmail.com>
References: <CABDkGQk33dzMiiOTRx9epz9BU2sQKMmegtT0-yL=4aX6RU4Niw@mail.gmail.com> <CABDkGQ=vEt5bmMejccpzycLsmQQiw42kkrLBu+ApxxJoC=UWbA@mail.gmail.com> <4EA66289.4010904@ais.uni-bonn.de> <CABDkGQkvkQUjUxNDzhczGEsZoN6WOKoDTBGaxRFhKpL1pGMKaw@mail.gmail.com>
Message-ID: <4EA883DA.6030209@ais.uni-bonn.de>

On 10/26/2011 08:22 PM, St??????fan van der Walt wrote:
> Hi Andy,
>
> Sorry for the late reply.
No problem. As you might have noticed I haven't really
had the time to do anything on scikits-image lately :(

> Usually, this will require you to write code that can only be run on
> an opencv system, but with the plugin system you can easily share that
> code with colleagues who do not have opencv installed:
>
> use_backend('my_opencv_routines')
> output = sobel(input)
>
> If the opencv backend is not found, the backend gracefully falls back
> to the NumPy / Cython implementation.
I do see your point.
On the other hand, if someone found code that was "way better"
than the one in scikits-image, I would rather hope people would
integrate it. Making the backends easy to substitute might
encourage bad scikits-image code.. or rather encourage
not changing it.

The above obviously does not apply to OpenCL and Cuda
implementations. Then again, it _might_ be a good idea
to include OpenCL or Cuda functions in directly into
scikits-image.
I, personally, would love to have a library with gpu
based vision algorithms (except opencv).
If scikits-image is a good place for this is
certainly debatable.

Cheers,
Andy