From tsyu80 at gmail.com  Sat Aug  6 18:04:44 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Sat, 6 Aug 2011 18:04:44 -0400
Subject: Greyscale reconstruction and merging CellProfiler code
In-Reply-To: <CABDkGQmZ+np9LVx0qjDk639LkqwvJ2svpMsMANDUWPcC=MaVcA@mail.gmail.com>
References: <CAEym_HqV5XGA0cG2b0JftrDh-LuQxu31RB07m0mYK9p33N5KpQ@mail.gmail.com>
	<CABDkGQnjamXNc6yzh=s84zJRinrhUzRKZb0XWdoN_Pvs=uhW-A@mail.gmail.com>
	<CAEym_HrA+L1g3U9ACtVycD2pUd0p1KF4e5vxsYhyZasTBzfhUA@mail.gmail.com>
	<CABDkGQmZ+np9LVx0qjDk639LkqwvJ2svpMsMANDUWPcC=MaVcA@mail.gmail.com>
Message-ID: <CAEym_HpEf=sSqh-iNicGb_CH4oJ7X5+Ymgkbq+5BZH8MVXcF8A@mail.gmail.com>

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

> On Thu, Jul 7, 2011 at 6:30 PM, Tony Yu <tsyu80 at gmail.com> wrote:
> > I added a reference and tried to expand on the description, but the
> > description is still poor. Even in the papers I've read, the descriptions
> > are quite difficult for me to understand (the figures in those papers
> really
> > help). I've also added an example to the docstring, but it's quite ...
> > verbose.
>
> I guess the question then becomes whether such a specialised algorithm
> is of enough common interest to include it.  In the end, every piece
> of code requires maintenance, and our aim is to provide a fairly
> generic set of tools that can be used to construct image processing
> experiments.
>
> I don't know this algorithm specifically, so I can't say, but it is an
> aspect worth considering.
>
> > I'd like to add a longer example in the docs, but that will have to wait
> > until I have a bit more time. When I do add it, where should put it? I'd
> > like for it to be more like a tutorial than a function-specific example
> > (specifically, I'd like to compare reconstruction and top-hat for peak
> > detection).
>
> We are eagerly awaiting tutorial contributions for the docs, but no
> one's volunteered so far :)  I'd love to have more of these, as it
> shows common patterns (such as how to use io, displaying images,
> etc.).
>
> Regards
> St?fan
>

Hi again,

I'm still interested in getting greyscale reconstruction into scikits.image.
To that end, I've updated my branch with a tutorial demonstrating peak
detection using reconstruction (
https://github.com/tonysyu/scikits.image/tree/reconstruction), with
comparisons to thresholding and white top hat. This example should
demonstrate reconstruction better than I was able to explain it earlier.

Let me know if you have trouble building the docs. There's still some
changes I want to make, but first I want to know whether this example is
enough to convince you that the reconstruction algorithm is worth including
;)

Best,
- Tony

A couple of random notes:

* This branch adds the ipython_directive (and ipython_console_hightlighting)
sphinx extension, because it allows you to show code examples with text
in-between (and still be able to access variables from previous blocks).
These extensions require the latest ipython (i.e. 0.11).

* morphology.greyscale_white_top_hat has issues with underflow because
there's a subtraction in the algorithm and it requires uint8 images (I
think). A similar issue came up in this thread:
http://groups.google.com/group/scikits-image/browse_thread/thread/c081f18d9e089e6e?pli=1.
But I guess, that applied specifically to functions using ndimage.convolve.

* the morphology names seem a bit clunky to work with. For example, white
top hat is called with "morphology.greyscale_white_top_hat". The greyscale
routines are already isolated to morphology.grey, so maybe
morphology/__init__.py can just call "import grey" (instead of "from grey
import *") and then the "greyscale_" prefix can be removed from the
functions?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20110806/b4b818d8/attachment.html>

From stefan at sun.ac.za  Sat Aug  6 22:01:30 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sat, 6 Aug 2011 19:01:30 -0700
Subject: Greyscale reconstruction and merging CellProfiler code
In-Reply-To: <CAEym_HpEf=sSqh-iNicGb_CH4oJ7X5+Ymgkbq+5BZH8MVXcF8A@mail.gmail.com>
References: <CAEym_HqV5XGA0cG2b0JftrDh-LuQxu31RB07m0mYK9p33N5KpQ@mail.gmail.com>
 <CABDkGQnjamXNc6yzh=s84zJRinrhUzRKZb0XWdoN_Pvs=uhW-A@mail.gmail.com>
 <CAEym_HrA+L1g3U9ACtVycD2pUd0p1KF4e5vxsYhyZasTBzfhUA@mail.gmail.com>
 <CABDkGQmZ+np9LVx0qjDk639LkqwvJ2svpMsMANDUWPcC=MaVcA@mail.gmail.com> <CAEym_HpEf=sSqh-iNicGb_CH4oJ7X5+Ymgkbq+5BZH8MVXcF8A@mail.gmail.com>
Message-ID: <CABDkGQmEGtS+AtbvNQQ0YM4L3wFwfaAX6ukFkvQgPEe+_yQKAA@mail.gmail.com>

Hey Tony

On Sat, Aug 6, 2011 at 3:04 PM, Tony Yu <tsyu80 at gmail.com> wrote:
> I'm still interested in getting greyscale reconstruction into scikits.image.
> To that end, I've updated my branch with a tutorial demonstrating peak
> detection using reconstruction
> (https://github.com/tonysyu/scikits.image/tree/reconstruction), with

Thanks!  I'm very interested to have a look, but I see that one of the
data files (.png) is missing.  Could you add that as well?

> A couple of random notes:
> * This branch adds the ipython_directive (and ipython_console_hightlighting)
> sphinx extension, because it allows you to show code examples with text
> in-between (and still be able to access variables from previous blocks).

No problem.  I saw another pretty cool trick that the IPython and
PyMVPA guys use: they write tutorials as .py files, that are then
parsed to produce an rst file.  I'm not sure what the best way is to
do this, but their approach does have the advantage that tutorials are
simply .py files, ready for distribution, and that we can provide a
template that is super easy to modify (we really need to encourage
more people to use, test, complain and write about this package).

What do you think: what's the best way to do tutorials?

> These extensions require the latest ipython (i.e. 0.11).
> * morphology.greyscale_white_top_hat has issues with underflow because
> there's a subtraction in the algorithm and it requires uint8 images (I
> think). A similar issue came up in this
> thread:?http://groups.google.com/group/scikits-image/browse_thread/thread/c081f18d9e089e6e?pli=1.
> But I guess, that applied specifically to functions using ndimage.convolve.

We should fix any such problems where we can.  I should write up the
proposed guidelines for usage of different image dtypes, but it comes
down to interpreting the different types in a set way (uint8->[0,255],
int8->[-127,127], etc.), providing the necessary utility functions,
and allowing functions to specify what type of input they allow.
Output can be whatever the functions can compute most efficiently, as
long as it is well documented.  Users can also then call a utility
function such as img_as_uint8 to convert to the specified format.

> * the morphology names seem a bit clunky to work with. For example, white
> top hat is called with "morphology.greyscale_white_top_hat". The greyscale
> routines are already isolated to morphology.grey, so maybe
> morphology/__init__.py can just call "import grey" (instead of "from grey
> import *") and then the "greyscale_" prefix can be removed from the
> functions?

Why don't we just shorten those names to morphology.grey_tophat etc.?

Looking forward to reading your tutorial!

Regards
St?fan


From tsyu80 at gmail.com  Sun Aug  7 09:35:03 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Sun, 7 Aug 2011 09:35:03 -0400
Subject: Greyscale reconstruction and merging CellProfiler code
In-Reply-To: <CABDkGQmEGtS+AtbvNQQ0YM4L3wFwfaAX6ukFkvQgPEe+_yQKAA@mail.gmail.com>
References: <CAEym_HqV5XGA0cG2b0JftrDh-LuQxu31RB07m0mYK9p33N5KpQ@mail.gmail.com>
	<CABDkGQnjamXNc6yzh=s84zJRinrhUzRKZb0XWdoN_Pvs=uhW-A@mail.gmail.com>
	<CAEym_HrA+L1g3U9ACtVycD2pUd0p1KF4e5vxsYhyZasTBzfhUA@mail.gmail.com>
	<CABDkGQmZ+np9LVx0qjDk639LkqwvJ2svpMsMANDUWPcC=MaVcA@mail.gmail.com>
	<CAEym_HpEf=sSqh-iNicGb_CH4oJ7X5+Ymgkbq+5BZH8MVXcF8A@mail.gmail.com>
	<CABDkGQmEGtS+AtbvNQQ0YM4L3wFwfaAX6ukFkvQgPEe+_yQKAA@mail.gmail.com>
Message-ID: <CAEym_Hoj--hAARTBJZ1iG99gYt-3BqOeH+YidV81F00nJO4ybA@mail.gmail.com>

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

> Hey Tony
>
> On Sat, Aug 6, 2011 at 3:04 PM, Tony Yu <tsyu80 at gmail.com> wrote:
> > (https://github.com/tonysyu/scikits.image/tree/reconstruction)
>
> Thanks!  I'm very interested to have a look, but I see that one of the
> data files (.png) is missing.  Could you add that as well?
>

That's strange: I can't see any missing files. I don't get any missing image
warnings from Sphinx, and I don't have any uncommitted files on my end.
Also, I checked that all savefig filenames in the tutorial are in the
ipython_images directory on the github repo. Was this from a Sphinx warning?
Any more clues?


> > A couple of random notes:
> > * This branch adds the ipython_directive (and
> ipython_console_hightlighting)
> > sphinx extension, because it allows you to show code examples with text
> > in-between (and still be able to access variables from previous blocks).
>
> No problem.  I saw another pretty cool trick that the IPython and
> PyMVPA guys use: they write tutorials as .py files, that are then
> parsed to produce an rst file.  I'm not sure what the best way is to
> do this, but their approach does have the advantage that tutorials are
> simply .py files, ready for distribution, and that we can provide a
> template that is super easy to modify (we really need to encourage
> more people to use, test, complain and write about this package).
>
> What do you think: what's the best way to do tutorials?
>

That sounds like an interesting idea. I especially like the fact you can
test *.py files without rebuilding all the docs. I can't find any examples
of this on the IPython or PyMVPA github accounts (granted I didn't try
*that* hard). Do you have any more info on this approach?

<snip>

>
> > * the morphology names seem a bit clunky to work with. For example, white
> > top hat is called with "morphology.greyscale_white_top_hat". The
> greyscale
> > routines are already isolated to morphology.grey, so maybe
> > morphology/__init__.py can just call "import grey" (instead of "from grey
> > import *") and then the "greyscale_" prefix can be removed from the
> > functions?
>
> Why don't we just shorten those names to morphology.grey_tophat etc.?
>

I like the flexibility with namespaces, actually. For example, I could be
very verbose and write:

>>> from scikits.image import morphology
>>> morphology.grey.white_tophat(...)

or slightly less verbose and write

>>> from scikits.image.morphology import grey
>>> grey.white_tophat(...)

or just lazy and write

>>> from scikits.image.morphology.grey import *
>>> white_tophat(...)

(BTW, the "white_" prefix is required because there's also a black_tophat).
Plus, "Namespaces are one honking great idea".

That's just my preference, though.

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

From stefan at sun.ac.za  Sun Aug  7 17:00:47 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 7 Aug 2011 14:00:47 -0700
Subject: Greyscale reconstruction and merging CellProfiler code
In-Reply-To: <CAEym_Hoj--hAARTBJZ1iG99gYt-3BqOeH+YidV81F00nJO4ybA@mail.gmail.com>
References: <CAEym_HqV5XGA0cG2b0JftrDh-LuQxu31RB07m0mYK9p33N5KpQ@mail.gmail.com>
 <CABDkGQnjamXNc6yzh=s84zJRinrhUzRKZb0XWdoN_Pvs=uhW-A@mail.gmail.com>
 <CAEym_HrA+L1g3U9ACtVycD2pUd0p1KF4e5vxsYhyZasTBzfhUA@mail.gmail.com>
 <CABDkGQmZ+np9LVx0qjDk639LkqwvJ2svpMsMANDUWPcC=MaVcA@mail.gmail.com>
 <CAEym_HpEf=sSqh-iNicGb_CH4oJ7X5+Ymgkbq+5BZH8MVXcF8A@mail.gmail.com>
 <CABDkGQmEGtS+AtbvNQQ0YM4L3wFwfaAX6ukFkvQgPEe+_yQKAA@mail.gmail.com> <CAEym_Hoj--hAARTBJZ1iG99gYt-3BqOeH+YidV81F00nJO4ybA@mail.gmail.com>
Message-ID: <CABDkGQnEQf85ACo3LksDzOz+z3p+9Bhm2Oy5GPgYAMfwOyM6GQ@mail.gmail.com>

On Sun, Aug 7, 2011 at 6:35 AM, Tony Yu <tsyu80 at gmail.com> wrote:
> That's strange: I can't see any missing files. I don't get any missing image warnings from Sphinx, and I don't have any uncommitted files on my end.

If I look at your Git repo, I don't see noisy_circles.png, for example.

https://github.com/tonysyu/scikits.image/tree/master/scikits/image/data

> That sounds like an interesting idea. I especially like the fact you can test *.py files without rebuilding all the docs. I can't find any examples of this on the IPython or PyMVPA github accounts (granted I didn't try *that* hard). Do you have any more info on this approach?

I can't find them now either, but I'll find out and let you know tomorrow.

>> Why don't we just shorten those names to morphology.grey_tophat etc.?
>
> I like the flexibility with namespaces, actually. For example, I could be very verbose and write:
> >>> from scikits.image import?morphology
> >>> morphology.grey.white_tophat(...)
> or slightly less verbose and write
> >>> from scikits.image.morphology import grey
> >>> grey.white_tophat(...)

It seems like the grey, white and boolean morphology operators share
(or could share) quite a lot of code, and functionally belong
together.  The main problem with a proliferation of namespaces is
helping the user to detangle the package.

How about we just make the grey-level operators default, i.e.
white_tophat etc., and if we then add boolean operators name them
differently?

Regards
St?fan


From tsyu80 at gmail.com  Sun Aug  7 17:55:38 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Sun, 7 Aug 2011 17:55:38 -0400
Subject: Greyscale reconstruction and merging CellProfiler code
In-Reply-To: <CABDkGQnEQf85ACo3LksDzOz+z3p+9Bhm2Oy5GPgYAMfwOyM6GQ@mail.gmail.com>
References: <CAEym_HqV5XGA0cG2b0JftrDh-LuQxu31RB07m0mYK9p33N5KpQ@mail.gmail.com>
	<CABDkGQnjamXNc6yzh=s84zJRinrhUzRKZb0XWdoN_Pvs=uhW-A@mail.gmail.com>
	<CAEym_HrA+L1g3U9ACtVycD2pUd0p1KF4e5vxsYhyZasTBzfhUA@mail.gmail.com>
	<CABDkGQmZ+np9LVx0qjDk639LkqwvJ2svpMsMANDUWPcC=MaVcA@mail.gmail.com>
	<CAEym_HpEf=sSqh-iNicGb_CH4oJ7X5+Ymgkbq+5BZH8MVXcF8A@mail.gmail.com>
	<CABDkGQmEGtS+AtbvNQQ0YM4L3wFwfaAX6ukFkvQgPEe+_yQKAA@mail.gmail.com>
	<CAEym_Hoj--hAARTBJZ1iG99gYt-3BqOeH+YidV81F00nJO4ybA@mail.gmail.com>
	<CABDkGQnEQf85ACo3LksDzOz+z3p+9Bhm2Oy5GPgYAMfwOyM6GQ@mail.gmail.com>
Message-ID: <CAEym_HphsKPSEqL_TW4ed_kxXEmg=23V5AaUT29NM6O8y_fQbA@mail.gmail.com>

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

> On Sun, Aug 7, 2011 at 6:35 AM, Tony Yu <tsyu80 at gmail.com> wrote:
> > That's strange: I can't see any missing files. I don't get any missing
> image warnings from Sphinx, and I don't have any uncommitted files on my
> end.
>
> If I look at your Git repo, I don't see noisy_circles.png, for example.
>
> https://github.com/tonysyu/scikits.image/tree/master/scikits/image/data
>

Oh, the grey_reconstruction stuff is in a separate branch:
https://github.com/tonysyu/scikits.image/tree/reconstruction/scikits/image/data
which does have a file named noisy_circles.jpg.

It seems like the grey, white and boolean morphology operators share
> (or could share) quite a lot of code, and functionally belong
> together.  The main problem with a proliferation of namespaces is
> helping the user to detangle the package.
>
> How about we just make the grey-level operators default, i.e.
> white_tophat etc., and if we then add boolean operators name them
> differently?
>

That sounds good to me.

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

From stefan at sun.ac.za  Mon Aug  8 14:53:59 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 8 Aug 2011 11:53:59 -0700
Subject: Greyscale reconstruction and merging CellProfiler code
In-Reply-To: <CABDkGQnEQf85ACo3LksDzOz+z3p+9Bhm2Oy5GPgYAMfwOyM6GQ@mail.gmail.com>
References: <CAEym_HqV5XGA0cG2b0JftrDh-LuQxu31RB07m0mYK9p33N5KpQ@mail.gmail.com>
 <CABDkGQnjamXNc6yzh=s84zJRinrhUzRKZb0XWdoN_Pvs=uhW-A@mail.gmail.com>
 <CAEym_HrA+L1g3U9ACtVycD2pUd0p1KF4e5vxsYhyZasTBzfhUA@mail.gmail.com>
 <CABDkGQmZ+np9LVx0qjDk639LkqwvJ2svpMsMANDUWPcC=MaVcA@mail.gmail.com>
 <CAEym_HpEf=sSqh-iNicGb_CH4oJ7X5+Ymgkbq+5BZH8MVXcF8A@mail.gmail.com>
 <CABDkGQmEGtS+AtbvNQQ0YM4L3wFwfaAX6ukFkvQgPEe+_yQKAA@mail.gmail.com>
 <CAEym_Hoj--hAARTBJZ1iG99gYt-3BqOeH+YidV81F00nJO4ybA@mail.gmail.com> <CABDkGQnEQf85ACo3LksDzOz+z3p+9Bhm2Oy5GPgYAMfwOyM6GQ@mail.gmail.com>
Message-ID: <CABDkGQk3HsOHJWmTuSxvp_0fy3FA0Kbaztz=9Jgc0mhLOvjNUA@mail.gmail.com>

2011/8/7 St?fan van der Walt <stefan at sun.ac.za>:
> On Sun, Aug 7, 2011 at 6:35 AM, Tony Yu <tsyu80 at gmail.com> wrote:
>> That's strange: I can't see any missing files. I don't get any missing image warnings from Sphinx, and I don't have any uncommitted files on my end.
>
> If I look at your Git repo, I don't see noisy_circles.png, for example.
>
> https://github.com/tonysyu/scikits.image/tree/master/scikits/image/data
>
>> That sounds like an interesting idea. I especially like the fact you can test *.py files without rebuilding all the docs. I can't find any examples of this on the IPython or PyMVPA github accounts (granted I didn't try *that* hard). Do you have any more info on this approach?
>
> I can't find them now either, but I'll find out and let you know tomorrow.

Here we go (I had the projects mixed up):

https://github.com/nipy/nitime/tree/master/doc/examples

There's also a tools directory that show how they are converted.  It's
a quick hack, but it does the job!

Should we adopt something like that for now?  Ideally, we will soon be
able to write IPython worksheets instead.

Cheers
St?fan


From tsyu80 at gmail.com  Tue Aug  9 09:50:04 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Tue, 9 Aug 2011 09:50:04 -0400
Subject: Greyscale reconstruction and merging CellProfiler code
In-Reply-To: <CABDkGQk3HsOHJWmTuSxvp_0fy3FA0Kbaztz=9Jgc0mhLOvjNUA@mail.gmail.com>
References: <CAEym_HqV5XGA0cG2b0JftrDh-LuQxu31RB07m0mYK9p33N5KpQ@mail.gmail.com>
	<CABDkGQnjamXNc6yzh=s84zJRinrhUzRKZb0XWdoN_Pvs=uhW-A@mail.gmail.com>
	<CAEym_HrA+L1g3U9ACtVycD2pUd0p1KF4e5vxsYhyZasTBzfhUA@mail.gmail.com>
	<CABDkGQmZ+np9LVx0qjDk639LkqwvJ2svpMsMANDUWPcC=MaVcA@mail.gmail.com>
	<CAEym_HpEf=sSqh-iNicGb_CH4oJ7X5+Ymgkbq+5BZH8MVXcF8A@mail.gmail.com>
	<CABDkGQmEGtS+AtbvNQQ0YM4L3wFwfaAX6ukFkvQgPEe+_yQKAA@mail.gmail.com>
	<CAEym_Hoj--hAARTBJZ1iG99gYt-3BqOeH+YidV81F00nJO4ybA@mail.gmail.com>
	<CABDkGQnEQf85ACo3LksDzOz+z3p+9Bhm2Oy5GPgYAMfwOyM6GQ@mail.gmail.com>
	<CABDkGQk3HsOHJWmTuSxvp_0fy3FA0Kbaztz=9Jgc0mhLOvjNUA@mail.gmail.com>
Message-ID: <CAEym_Hq+A_V_oGcOY9Gq1i4ZwiixC-VJqizowt1-ScQuW1Qa7Q@mail.gmail.com>

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

>
> Here we go (I had the projects mixed up):
>
> https://github.com/nipy/nitime/tree/master/doc/examples
>
> There's also a tools directory that show how they are converted.  It's
> a quick hack, but it does the job!
>

In case anyone else is following this discussion, here's a specific example.

This python file:
https://github.com/nipy/nitime/blob/master/doc/examples/multi_taper_coh.py

is rendered like this:
http://nipy.sourceforge.net/nitime/examples/multi_taper_coh.html

And here's the script that does most of the work generating rst from py
files:
https://github.com/nipy/nitime/blob/master/tools/ex2rst


Should we adopt something like that for now?
>

I really like this approach. As I mentioned earlier, being able to run the
example code directly (instead of having to build the docs to run the code)
is a huge plus for me. One thing I like about ipython_directive: they define
a "savefig" decorator which saved the current figure and generated rst to
add the image. I presume a similar function can be defined for this approach
(but I'm not sure I'd miss this feature enough to write the code myself).

Cheers,
-Tony

P.S. St?fan: were you able to build the tutorial on my "reconstruction"
branch?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20110809/01d69391/attachment.html>

From emmanuelle.gouillart at normalesup.org  Fri Aug 19 06:07:34 2011
From: emmanuelle.gouillart at normalesup.org (Emmanuelle Gouillart)
Date: Fri, 19 Aug 2011 12:07:34 +0200
Subject: scikits.image sprints at EuroScipy and SciPy 2011
In-Reply-To: <BANLkTikbtrjwMz47jPZVaCmSRiTu-QijPw@mail.gmail.com>
References: <BANLkTikbtrjwMz47jPZVaCmSRiTu-QijPw@mail.gmail.com>
Message-ID: <20110819100734.GB10324@phare.normalesup.org>

Hello,

are we sprinting before Euroscipy, eventually? If people are up for
sprinting, we have rooms and Internet access on Tuesday 23 and Wednesday
24. There will also be rooms available during the conference (25-28), but
this gives less time because we all want to attend to the talks, don't
we ;-)? So, who is available for sprinting? 

Let's start: I'm free on Tuesday 23rd and Wednesday 24th; I'll have much
less time during the conference itself, being one of the organizers.

Cheers,
Emmanuelle

On Mon, Jun 20, 2011 at 04:49:23PM +0200, St??????fan van der Walt wrote:
> Hi everyone

> Just a heads-up about two upcoming scikits.image sprints.

> The first will be at SciPy 2011, held in Austin, Tx from 11 to 16 July.

> Then, we'll do the same at the EuroSciPy conference from 25 to 28
> August in Paris.  Thank you to Emmanuelle Guillart for taking care of
> the arrangements!  At EuroSciPy, we'll be in the room next to the
> scikits.learn guys, so there should be some great cross-pollination
> and collaboration happening.

> If you're around, come and join us to finalise the 3.0 release!

> Here are the important dates again:

> * SciPy: July 11 - July 16 2011, Austin, Tx
> * EuroSciPy: August 25 - 28 2011, Paris

> Regards
> St??????fan


From stefan at sun.ac.za  Fri Aug 19 19:37:33 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 19 Aug 2011 16:37:33 -0700
Subject: scikits.image sprints at EuroScipy and SciPy 2011
In-Reply-To: <20110819100734.GB10324@phare.normalesup.org>
References: <BANLkTikbtrjwMz47jPZVaCmSRiTu-QijPw@mail.gmail.com> <20110819100734.GB10324@phare.normalesup.org>
Message-ID: <CABDkGQmYOC9RSpnDAXR7FVEX9BsFGDBBE754sMgbcYX+DvEC6A@mail.gmail.com>

Hey, Emmanuelle!

On Fri, Aug 19, 2011 at 3:07 AM, Emmanuelle Gouillart
<emmanuelle.gouillart at normalesup.org> wrote:
> are we sprinting before Euroscipy, eventually? If people are up for
> sprinting, we have rooms and Internet access on Tuesday 23 and Wednesday
> 24. There will also be rooms available during the conference (25-28), but
> this gives less time because we all want to attend to the talks, don't
> we ;-)? So, who is available for sprinting?

I'll definitely be there.  I think one of the main aims of the sprint
for me will be to

 - Merge and test Pieter Holtzhausen's GSoC changes
 - Add tools for easy writing of tutorials (we'll borrow from nipy, perhaps)
 - Fill out the MATLAB compatibility chart that Kyle Mandli
implemented at SciPy2011
 - Prepare for the release of 0.3

> Let's start: I'm free on Tuesday 23rd and Wednesday 24th; I'll have much
> less time during the conference itself, being one of the organizers.

I'll definitely be there those days as well.  I'm teaching during the
conference, but apart from that I'll work on this and IPython.

Regards
St?fan


From stefan at sun.ac.za  Sun Aug 21 00:48:23 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sat, 20 Aug 2011 21:48:23 -0700
Subject: Greyscale reconstruction and merging CellProfiler code
In-Reply-To: <CAEym_Hq+A_V_oGcOY9Gq1i4ZwiixC-VJqizowt1-ScQuW1Qa7Q@mail.gmail.com>
References: <CAEym_HqV5XGA0cG2b0JftrDh-LuQxu31RB07m0mYK9p33N5KpQ@mail.gmail.com>
 <CABDkGQnjamXNc6yzh=s84zJRinrhUzRKZb0XWdoN_Pvs=uhW-A@mail.gmail.com>
 <CAEym_HrA+L1g3U9ACtVycD2pUd0p1KF4e5vxsYhyZasTBzfhUA@mail.gmail.com>
 <CABDkGQmZ+np9LVx0qjDk639LkqwvJ2svpMsMANDUWPcC=MaVcA@mail.gmail.com>
 <CAEym_HpEf=sSqh-iNicGb_CH4oJ7X5+Ymgkbq+5BZH8MVXcF8A@mail.gmail.com>
 <CABDkGQmEGtS+AtbvNQQ0YM4L3wFwfaAX6ukFkvQgPEe+_yQKAA@mail.gmail.com>
 <CAEym_Hoj--hAARTBJZ1iG99gYt-3BqOeH+YidV81F00nJO4ybA@mail.gmail.com>
 <CABDkGQnEQf85ACo3LksDzOz+z3p+9Bhm2Oy5GPgYAMfwOyM6GQ@mail.gmail.com>
 <CABDkGQk3HsOHJWmTuSxvp_0fy3FA0Kbaztz=9Jgc0mhLOvjNUA@mail.gmail.com> <CAEym_Hq+A_V_oGcOY9Gq1i4ZwiixC-VJqizowt1-ScQuW1Qa7Q@mail.gmail.com>
Message-ID: <CABDkGQ=1Rv2Lu5AcDhOAnZTnFMuKF7jopgxGf-jmYuB1FSw_Fw@mail.gmail.com>

Hi Tony

On Tue, Aug 9, 2011 at 6:50 AM, Tony Yu <tsyu80 at gmail.com> wrote:
> P.S. St?fan: were you able to build the tutorial on my "reconstruction"
> branch?

This is the result I get (had to fix a small problem in the data_path first):

http://mentat.za.net/refer/pp.tar.gz

Could you verify that that looks right?

Thanks
St?fan


From stefan at sun.ac.za  Sun Aug 21 12:22:40 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 21 Aug 2011 09:22:40 -0700
Subject: scikits.image sprints at EuroScipy and SciPy 2011
In-Reply-To: <20110821143947.GA22640@phare.normalesup.org>
References: <BANLkTikbtrjwMz47jPZVaCmSRiTu-QijPw@mail.gmail.com>
 <20110819100734.GB10324@phare.normalesup.org> <CABDkGQmYOC9RSpnDAXR7FVEX9BsFGDBBE754sMgbcYX+DvEC6A@mail.gmail.com>
 <20110821143947.GA22640@phare.normalesup.org>
Message-ID: <CABDkGQk3DJG2+LoNiM7fmSvgJoHdbDReDCypeR7m8vBAeYP=AA@mail.gmail.com>

On Sun, Aug 21, 2011 at 7:39 AM, Emmanuelle Gouillart >> I'll
definitely be there. ?I think one of the main aims of the sprint
>> for me will be to
>
> Great news! When do you arrive in Paris?

I arrive on the morning of the 23rd, I believe.

> OK, I'll try to give you a hand for this. As for me, I'm particularly
> interested in writing documentation (examples) and merging code from
> CellProfiler.

That'd be great!

Cheers
St?fan


From stefan at sun.ac.za  Sun Aug 21 12:25:12 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 21 Aug 2011 09:25:12 -0700
Subject: Greyscale reconstruction and merging CellProfiler code
In-Reply-To: <CAEym_HofmK1pHPcrMv-W_n5KeyZzxxXKOngY8d7G379jddtYVg@mail.gmail.com>
References: <CAEym_HqV5XGA0cG2b0JftrDh-LuQxu31RB07m0mYK9p33N5KpQ@mail.gmail.com>
 <CABDkGQnjamXNc6yzh=s84zJRinrhUzRKZb0XWdoN_Pvs=uhW-A@mail.gmail.com>
 <CAEym_HrA+L1g3U9ACtVycD2pUd0p1KF4e5vxsYhyZasTBzfhUA@mail.gmail.com>
 <CABDkGQmZ+np9LVx0qjDk639LkqwvJ2svpMsMANDUWPcC=MaVcA@mail.gmail.com>
 <CAEym_HpEf=sSqh-iNicGb_CH4oJ7X5+Ymgkbq+5BZH8MVXcF8A@mail.gmail.com>
 <CABDkGQmEGtS+AtbvNQQ0YM4L3wFwfaAX6ukFkvQgPEe+_yQKAA@mail.gmail.com>
 <CAEym_Hoj--hAARTBJZ1iG99gYt-3BqOeH+YidV81F00nJO4ybA@mail.gmail.com>
 <CABDkGQnEQf85ACo3LksDzOz+z3p+9Bhm2Oy5GPgYAMfwOyM6GQ@mail.gmail.com>
 <CABDkGQk3HsOHJWmTuSxvp_0fy3FA0Kbaztz=9Jgc0mhLOvjNUA@mail.gmail.com>
 <CAEym_Hq+A_V_oGcOY9Gq1i4ZwiixC-VJqizowt1-ScQuW1Qa7Q@mail.gmail.com>
 <CABDkGQ=1Rv2Lu5AcDhOAnZTnFMuKF7jopgxGf-jmYuB1FSw_Fw@mail.gmail.com> <CAEym_HofmK1pHPcrMv-W_n5KeyZzxxXKOngY8d7G379jddtYVg@mail.gmail.com>
Message-ID: <CABDkGQno=32pp_bx9ZH6d0uisBCFRyowT=dAzJgKGra72JTM7w@mail.gmail.com>

On Sun, Aug 21, 2011 at 7:21 AM, Tony Yu <tsyu80 at gmail.com> wrote:
> It sounds like there are plans to decide on a tutorial format at EuroScipy,
> so I'm inclined to wait until the dust has settled. Also, do you think the
> morphological reconstruction routine looks general/useful enough to include?

I'll have to study the technique in a bit more detail.  I'd like to
compare it with the Discrete Pulse Transform, for example:

http://dip.sun.ac.za/~stefan/dpt/
http://scholar.sun.ac.za/handle/10019.1/4883

Regards
St?fan


From tsyu80 at gmail.com  Sun Aug 21 10:21:18 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Sun, 21 Aug 2011 10:21:18 -0400
Subject: Greyscale reconstruction and merging CellProfiler code
In-Reply-To: <CABDkGQ=1Rv2Lu5AcDhOAnZTnFMuKF7jopgxGf-jmYuB1FSw_Fw@mail.gmail.com>
References: <CAEym_HqV5XGA0cG2b0JftrDh-LuQxu31RB07m0mYK9p33N5KpQ@mail.gmail.com>
	<CABDkGQnjamXNc6yzh=s84zJRinrhUzRKZb0XWdoN_Pvs=uhW-A@mail.gmail.com>
	<CAEym_HrA+L1g3U9ACtVycD2pUd0p1KF4e5vxsYhyZasTBzfhUA@mail.gmail.com>
	<CABDkGQmZ+np9LVx0qjDk639LkqwvJ2svpMsMANDUWPcC=MaVcA@mail.gmail.com>
	<CAEym_HpEf=sSqh-iNicGb_CH4oJ7X5+Ymgkbq+5BZH8MVXcF8A@mail.gmail.com>
	<CABDkGQmEGtS+AtbvNQQ0YM4L3wFwfaAX6ukFkvQgPEe+_yQKAA@mail.gmail.com>
	<CAEym_Hoj--hAARTBJZ1iG99gYt-3BqOeH+YidV81F00nJO4ybA@mail.gmail.com>
	<CABDkGQnEQf85ACo3LksDzOz+z3p+9Bhm2Oy5GPgYAMfwOyM6GQ@mail.gmail.com>
	<CABDkGQk3HsOHJWmTuSxvp_0fy3FA0Kbaztz=9Jgc0mhLOvjNUA@mail.gmail.com>
	<CAEym_Hq+A_V_oGcOY9Gq1i4ZwiixC-VJqizowt1-ScQuW1Qa7Q@mail.gmail.com>
	<CABDkGQ=1Rv2Lu5AcDhOAnZTnFMuKF7jopgxGf-jmYuB1FSw_Fw@mail.gmail.com>
Message-ID: <CAEym_HofmK1pHPcrMv-W_n5KeyZzxxXKOngY8d7G379jddtYVg@mail.gmail.com>

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

> Hi Tony
>
> On Tue, Aug 9, 2011 at 6:50 AM, Tony Yu <tsyu80 at gmail.com> wrote:
> > P.S. St?fan: were you able to build the tutorial on my "reconstruction"
> > branch?
>
> This is the result I get (had to fix a small problem in the data_path
> first):
>
> http://mentat.za.net/refer/pp.tar.gz
>
> Could you verify that that looks right?
>

Wow, that's weird. The first 4 images (peak_detection-orig,
peak_detection-smooth, peak_detection-thresh_bg, peak_detection-peaks) are
rendered incorrectly. It looks like the ipython directive is taking a
previous mpl figure (apparently from the Hough transform docs) and plotting
into one of the subplots of that figure. I guess the state of the ipython
directive is maintained across docs, so I should start the doc page by
closing all other figures.

It sounds like there are plans to decide on a tutorial format at EuroScipy,
so I'm inclined to wait until the dust has settled. Also, do you think the
morphological reconstruction routine looks general/useful enough to include?

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

From emmanuelle.gouillart at normalesup.org  Sun Aug 21 10:39:47 2011
From: emmanuelle.gouillart at normalesup.org (Emmanuelle Gouillart)
Date: Sun, 21 Aug 2011 16:39:47 +0200
Subject: scikits.image sprints at EuroScipy and SciPy 2011
In-Reply-To: <CABDkGQmYOC9RSpnDAXR7FVEX9BsFGDBBE754sMgbcYX+DvEC6A@mail.gmail.com>
References: <BANLkTikbtrjwMz47jPZVaCmSRiTu-QijPw@mail.gmail.com>
 <20110819100734.GB10324@phare.normalesup.org>
 <CABDkGQmYOC9RSpnDAXR7FVEX9BsFGDBBE754sMgbcYX+DvEC6A@mail.gmail.com>
Message-ID: <20110821143947.GA22640@phare.normalesup.org>


Hi St??????fan!

> I'll definitely be there.  I think one of the main aims of the sprint
> for me will be to

Great news! When do you arrive in Paris?

>  - Merge and test Pieter Holtzhausen's GSoC changes
>  - Add tools for easy writing of tutorials (we'll borrow from nipy, perhaps)
>  - Fill out the MATLAB compatibility chart that Kyle Mandli
> implemented at SciPy2011
>  - Prepare for the release of 0.3

OK, I'll try to give you a hand for this. As for me, I'm particularly
interested in writing documentation (examples) and merging code from
CellProfiler.

> > Let's start: I'm free on Tuesday 23rd and Wednesday 24th; I'll have much
> > less time during the conference itself, being one of the organizers.

> I'll definitely be there those days as well.  I'm teaching during the
> conference, but apart from that I'll work on this and IPython.

Great; in fact I'll have to be at work either on Tuesday morning or
Wednesday morning, but I'll be at the Ecole Normale Sup??????rieure (Physics
Department) for the rest of the time.

Anybody else? (Ma??????l?)


From stefan at sun.ac.za  Mon Aug 29 05:25:06 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 29 Aug 2011 11:25:06 +0200
Subject: Usage of and relationship to OpenCV
Message-ID: <CABDkGQ=vo4F9_ZL1w8MDo=kCYB3BEnJe4T=oau3KYjGw_mHq8Q@mail.gmail.com>

Hi all,

After merging the GSoC contributions, I think we're in good shape for
a next release.  Before we get there, however, I'd like to ask your
opinions.

Should we declare OpenCV a dependency?  There are two sides to this:
1) I want to stop focusing on optimising low-level routines, and
instead implement interesting algorithms but 2) OpenCV is quite a big
dependency (although it does run on Windows, Linux, Mac etc, comes
with built binaries in all of them, and has a permissive BSD license).

Fact is, our manpower is limited, so we should focus on where we can
make a difference.  My aim is to provide an excellent image processing
toolbox for Python that at least covers the MATLAB functionality and
more, and to reach that goal with our limited manpower, we need to
carefully pick our strategy.

I'd be glad to hear what you have to say.

Regards
St?fan


From stefan at sun.ac.za  Mon Aug 29 05:58:37 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 29 Aug 2011 11:58:37 +0200
Subject: Report from EuroSciPy
Message-ID: <CABDkGQ=D7KF_xSb9aiUdJnBck0xONd-+HM5xkUf=Ut_qk6bamQ@mail.gmail.com>

Hi everyone,

A quick report from EuroSciPy:

- Ray Jones gave a great talk about CellProfiler.  As you may recall,
CellProfiler opened their code under a BSD license so that we may
include it in the scikit.
- There will be a sprint this evening at 19:30 Paris time to move us
closer to our 0.3 release.  Emmanuelle, Ray and myself will be
sprinting from Paris, and you are all invited to join via IRC or chat.
- We've had good conversations with developers of other image
processing packages, so let's hope for some more contributors!

St?fan


From emmanuelle.gouillart at normalesup.org  Mon Aug 29 06:27:11 2011
From: emmanuelle.gouillart at normalesup.org (Emmanuelle Gouillart)
Date: Mon, 29 Aug 2011 12:27:11 +0200
Subject: Usage of and relationship to OpenCV
In-Reply-To: <CABDkGQ=vo4F9_ZL1w8MDo=kCYB3BEnJe4T=oau3KYjGw_mHq8Q@mail.gmail.com>
References: <CABDkGQ=vo4F9_ZL1w8MDo=kCYB3BEnJe4T=oau3KYjGw_mHq8Q@mail.gmail.com>
Message-ID: <20110829102711.GA3348@phare.normalesup.org>

Hi,

having opencv as a dependency has two important drawbacks for me. First,
it makes the installation of the scikit more difficult. Second, the 
documentation of openCV does not match the standards of numpy/scipy 
docstrings (no examples, few references to articles).

Performance is great, but I think we'll gain more users by putting effort
on user-friendliness than if we put it on performance. For examples, a 
large fraction of my colleagues are using image processing, but on
Windows, and they get discouraged by a package with unsufficient 
documentation.                               
 
I'm at the Python for Physics day now and I don't have the time to write
more, but I'll be glad to continue the discussion later.
 
Cheers,
Emmanuelle


On Mon, Aug 29, 2011 at 11:25:06AM +0200, St??????fan van der Walt wrote:
> Hi all,

> After merging the GSoC contributions, I think we're in good shape for
> a next release.  Before we get there, however, I'd like to ask your
> opinions.

> Should we declare OpenCV a dependency?  There are two sides to this:
> 1) I want to stop focusing on optimising low-level routines, and
> instead implement interesting algorithms but 2) OpenCV is quite a big
> dependency (although it does run on Windows, Linux, Mac etc, comes
> with built binaries in all of them, and has a permissive BSD license).

> Fact is, our manpower is limited, so we should focus on where we can
> make a difference.  My aim is to provide an excellent image processing
> toolbox for Python that at least covers the MATLAB functionality and
> more, and to reach that goal with our limited manpower, we need to
> carefully pick our strategy.

> I'd be glad to hear what you have to say.

> Regards
> St??????fan


From stefan at sun.ac.za  Mon Aug 29 06:49:05 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 29 Aug 2011 12:49:05 +0200
Subject: Usage of and relationship to OpenCV
In-Reply-To: <20110829102711.GA3348@phare.normalesup.org>
References: <CABDkGQ=vo4F9_ZL1w8MDo=kCYB3BEnJe4T=oau3KYjGw_mHq8Q@mail.gmail.com>
 <20110829102711.GA3348@phare.normalesup.org>
Message-ID: <CABDkGQ=Ob-=2rRDgt3NkCw7xhuJZthVMqZ7+eK07mu4tkcH0BQ@mail.gmail.com>

Hi,

On Mon, Aug 29, 2011 at 12:27 PM, Emmanuelle Gouillart
<emmanuelle.gouillart at normalesup.org> wrote:
> having opencv as a dependency has two important drawbacks for me. First,
> it makes the installation of the scikit more difficult.

There is certainly a cost; the question is whether that cost comes
with enough advantage to make it worth our while.  There are currently
binary packages available on Windows, in most of the major distros
(and on OSX building is supported, although I saw no binary package).

> Second, the
> documentation of openCV does not match the standards of numpy/scipy
> docstrings (no examples, few references to articles).

When we use it as a dependency, I don't think this needs to matter too
much.  We'll be using it to do things like fast convolution, feature
finding, colour conversions, etc.  We'll still have to write
documentation for anything we want to expose to our users.

> Performance is great, but I think we'll gain more users by putting effort
> on user-friendliness than if we put it on performance. For examples, a
> large fraction of my colleagues are using image processing, but on
> Windows, and they get discouraged by a package with unsufficient
> documentation.

We have two groups of users, and their needs are somewhat different.
Personally, I need accurate algorithms for research, but I know that
many others need speed for doing near real-time processing, for
example.

Regards
St?fan


From thouis at gmail.com  Mon Aug 29 07:33:18 2011
From: thouis at gmail.com (Thouis (Ray) Jones)
Date: Mon, 29 Aug 2011 13:33:18 +0200
Subject: Usage of and relationship to OpenCV
In-Reply-To: <CABDkGQ=vo4F9_ZL1w8MDo=kCYB3BEnJe4T=oau3KYjGw_mHq8Q@mail.gmail.com>
References: <CABDkGQ=vo4F9_ZL1w8MDo=kCYB3BEnJe4T=oau3KYjGw_mHq8Q@mail.gmail.com>
Message-ID: <CAHGWWxEK94yBU9XR69bRXF509HXzf+_X449oo=P1X=+M-d-Z7w@mail.gmail.com>

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

> Should we declare OpenCV a dependency?

If it's made a dependency, is it possible to automate the process of
fetching and installing it (in a directory local to the package?) as
part of the install process?  Only if it's not installed already, of
course.

I think I would prefer:
- not making it a dependency
- adding code to (optionally) download and install it as part of the
scikit install process
- some functionality might require it be installed.  Eventually,
slower non-opencv versions might be added.

Ray


From stefan at sun.ac.za  Mon Aug 29 15:19:05 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 29 Aug 2011 21:19:05 +0200
Subject: Removing OpenCV wrappers
Message-ID: <CABDkGQ=iE+eWdT7k2SJHBcO3y8wQippLtD5tsYAoB89BO2+Q3g@mail.gmail.com>

Hi all,

The OpenCV wrappers currently in scikits.image did a great job, but
since the OpenCV project's wrappers have now caught up (in terms of
not copying data, etc.), it makes sense to deprecate ours for removal
in the next release.

Please let me know if you have any thoughts on the topic.

Regards
St?fan


From holtzhau at gmail.com  Mon Aug 29 16:03:57 2011
From: holtzhau at gmail.com (Pieter Holtzhausen)
Date: Mon, 29 Aug 2011 22:03:57 +0200
Subject: Removing OpenCV wrappers
In-Reply-To: <CABDkGQ=iE+eWdT7k2SJHBcO3y8wQippLtD5tsYAoB89BO2+Q3g@mail.gmail.com>
References: <CABDkGQ=iE+eWdT7k2SJHBcO3y8wQippLtD5tsYAoB89BO2+Q3g@mail.gmail.com>
Message-ID: <CAOA5xCzpkFW+fiKQ633J27QsE535A_OeEcYanVTGqN74=3VB8A@mail.gmail.com>

Our version can prove as example of how it should have been done :)
but yes the opencv wrapper now offers the same functionality while
being more thorough and more actively maintained.

2011/8/29 St?fan van der Walt <stefan at sun.ac.za>:
> Hi all,
>
> The OpenCV wrappers currently in scikits.image did a great job, but
> since the OpenCV project's wrappers have now caught up (in terms of
> not copying data, etc.), it makes sense to deprecate ours for removal
> in the next release.
>
> Please let me know if you have any thoughts on the topic.
>
> Regards
> St?fan
>


From sccolbert at gmail.com  Tue Aug 30 12:00:43 2011
From: sccolbert at gmail.com (Chris Colbert)
Date: Tue, 30 Aug 2011 11:00:43 -0500
Subject: Progress towards the next release
In-Reply-To: <CABDkGQk7uCjLCKAB=FANb7gZ5wCv8-wgeibB6-0qSSRsDUg=8g@mail.gmail.com>
References: <CABDkGQk7uCjLCKAB=FANb7gZ5wCv8-wgeibB6-0qSSRsDUg=8g@mail.gmail.com>
Message-ID: <CAPc_zRWdTdi1tjmHgHfN-OG1xzuBiVd7gFPY4-y7V9ZqVC3D6A@mail.gmail.com>

What? It is was a clean patch :)
On Aug 30, 2011 6:36 AM, "St?fan van der Walt" <stefan at sun.ac.za> wrote:
> Hi all,
>
> We've made some progress at the sprint last night towards the 0.3
> release. Thanks go out to Emmanuelle, Ga?l, Thouis, David as well as
> Chris (whom we never saw, but who merged a patch silently :).
>
> I'll be travelling for the next 10 days, but thereafter I plan to
> round this up and cut the release. Here's what's cooking:
>
> - Emmanuelle is incorporating cellprofiler morphology funcs (watershed &
others)
> - Stefan is creating the Debian packages, sorting out the windows
> builder, and writing up the dtype overview
> - Thouis & Kyle are completing the functionality overview table
> - Gael is improving the implementation of TV denoise using fista
> - David is setting up our bento build script
> - The team (that's you!) is reviewing Pieter's Google Summer of Code
patches
>
> We need to hear from you! If there's anything you need to get in
> before the release, now's a good time.
>
> Also, we need a new logo for the website--I know someone must be able
> to draw prettier pictures than me, so don't be shy!
>
> http://github.com/scikits-image
>
> Regards
> St?fan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20110830/4e36917f/attachment.html>

From stefan at sun.ac.za  Tue Aug 30 07:36:07 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 30 Aug 2011 13:36:07 +0200
Subject: Progress towards the next release
Message-ID: <CABDkGQk7uCjLCKAB=FANb7gZ5wCv8-wgeibB6-0qSSRsDUg=8g@mail.gmail.com>

Hi all,

We've made some progress at the sprint last night towards the 0.3
release.  Thanks go out to Emmanuelle, Ga?l, Thouis, David as well as
Chris (whom we never saw, but who merged a patch silently :).

I'll be travelling for the next 10 days, but thereafter I plan to
round this up and cut the release.  Here's what's cooking:

- Emmanuelle is incorporating cellprofiler morphology funcs (watershed & others)
- Stefan is creating the Debian packages, sorting out the windows
builder, and writing up the dtype overview
- Thouis & Kyle are completing the functionality overview table
- Gael is improving the implementation of TV denoise using fista
- David is setting up our bento build script
- The team (that's you!) is reviewing Pieter's Google Summer of Code patches

We need to hear from you!  If there's anything you need to get in
before the release, now's a good time.

Also, we need a new logo for the website--I know someone must be able
to draw prettier pictures than me, so don't be shy!

http://github.com/scikits-image

Regards
St?fan