From tsyu80 at gmail.com  Fri Sep  2 09:53:03 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Fri, 2 Sep 2011 09:53:03 -0400
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: <CAEym_Hp0DG7URm-RontHBPvEd2tSVcKErzbyGLgaBxtJqN92oA@mail.gmail.com>

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

> 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!
>
>
I wanted to take a stab at putting together a logo. The basic idea I had was
to combine the scipy logo with some image processing.

I chose an edge filter (Sobel) as the image processing step. As for the
image, a snake was an obvious choice (I picked a public domain image from
pixabay <http://pixabay.com/en/snake-green-toxic-close-yellow-3237/>). I
also, played around with the Lena image, since it's such a common example in
image processing.

I'm still playing around with colors and levels---as you can see in the
first attachment (demo_array). Also, I've attached some mock-ups of a banner
using the logo (demos 1 & 2). demo_2 is in reference to the package
rename<http://groups.google.com/group/scikits-image/browse_frm/thread/4dcc55906a9328e9>discussion.
(Somewhat identifiable with scikits.image and pronounceable; I'm
not sure if I like the way it looks in print, though.)

Best,
-Tony

P.S. if you'd like to play around with this yourself, let me know and I'll
send you the code used to generate the logo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20110902/05966c13/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: demo_array.jpg
Type: image/jpeg
Size: 290951 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20110902/05966c13/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: demo_1.png
Type: image/png
Size: 126023 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20110902/05966c13/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: demo_2.png
Type: image/png
Size: 70002 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20110902/05966c13/attachment-0001.png>

From sccolbert at gmail.com  Fri Sep  2 10:19:24 2011
From: sccolbert at gmail.com (Chris Colbert)
Date: Fri, 2 Sep 2011 10:19:24 -0400
Subject: Progress towards the next release
In-Reply-To: <CAEym_Hp0DG7URm-RontHBPvEd2tSVcKErzbyGLgaBxtJqN92oA@mail.gmail.com>
References: <CABDkGQk7uCjLCKAB=FANb7gZ5wCv8-wgeibB6-0qSSRsDUg=8g@mail.gmail.com>
	<CAEym_Hp0DG7URm-RontHBPvEd2tSVcKErzbyGLgaBxtJqN92oA@mail.gmail.com>
Message-ID: <CAPc_zRW5YXgicvF1Fn0A7s+RYiFAUMZS1fD9MgW4G8WcVAO6AQ@mail.gmail.com>

wow, nice work man! I can't decide which one I like best :-)

On Fri, Sep 2, 2011 at 9:53 AM, Tony Yu <tsyu80 at gmail.com> wrote:

>
> 2011/8/30 St?fan van der Walt <stefan at sun.ac.za>
>
>> 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!
>>
>>
> I wanted to take a stab at putting together a logo. The basic idea I had
> was to combine the scipy logo with some image processing.
>
> I chose an edge filter (Sobel) as the image processing step. As for the
> image, a snake was an obvious choice (I picked a public domain image from
> pixabay <http://pixabay.com/en/snake-green-toxic-close-yellow-3237/>). I
> also, played around with the Lena image, since it's such a common example in
> image processing.
>
> I'm still playing around with colors and levels---as you can see in the
> first attachment (demo_array). Also, I've attached some mock-ups of a banner
> using the logo (demos 1 & 2). demo_2 is in reference to the package rename<http://groups.google.com/group/scikits-image/browse_frm/thread/4dcc55906a9328e9>discussion. (Somewhat identifiable with scikits.image and pronounceable; I'm
> not sure if I like the way it looks in print, though.)
>
> Best,
> -Tony
>
> P.S. if you'd like to play around with this yourself, let me know and I'll
> send you the code used to generate the logo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20110902/a78df09b/attachment.html>

From stefan at sun.ac.za  Sat Sep  3 16:24:00 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sat, 3 Sep 2011 22:24:00 +0200
Subject: Progress towards the next release
In-Reply-To: <CAEym_Hp0DG7URm-RontHBPvEd2tSVcKErzbyGLgaBxtJqN92oA@mail.gmail.com>
References: <CABDkGQk7uCjLCKAB=FANb7gZ5wCv8-wgeibB6-0qSSRsDUg=8g@mail.gmail.com>
 <CAEym_Hp0DG7URm-RontHBPvEd2tSVcKErzbyGLgaBxtJqN92oA@mail.gmail.com>
Message-ID: <CABDkGQmshy0-e4WoPUwK6tyMVtNSUQ3gP=AfyMbohCyM0Y9EHg@mail.gmail.com>

Hi Tony

On Fri, Sep 2, 2011 at 3:53 PM, Tony Yu <tsyu80 at gmail.com> wrote:
> I'm still playing around with colors and levels---as you can see in the
> first attachment (demo_array). Also, I've attached some mock-ups of a banner
> using the logo (demos 1 & 2). demo_2 is in reference to the package rename
> discussion. (Somewhat identifiable with scikits.image and pronounceable; I'm
> not sure if I like the way it looks in print, though.)

This is great!  Thanks so much for your effort.

I know some people don't like the use of the Lena image (several
reasons: some to do with being politically correct, others to do with
its uncertain copyright).  So if we could use another image that is
free and entirely uncontroversial, like the snake, that should be
good.  I also like that that specific snake is a lot faster than a
Python :)

I am currently travelling with a really bad connection, but I'll be
back online in a week or so.  I'm very happy about this, thanks!

Regards
St?fan


From stefan at sun.ac.za  Mon Sep 12 20:29:58 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 12 Sep 2011 17:29:58 -0700
Subject: Progress towards the next release
In-Reply-To: <CABDkGQmshy0-e4WoPUwK6tyMVtNSUQ3gP=AfyMbohCyM0Y9EHg@mail.gmail.com>
References: <CABDkGQk7uCjLCKAB=FANb7gZ5wCv8-wgeibB6-0qSSRsDUg=8g@mail.gmail.com>
 <CAEym_Hp0DG7URm-RontHBPvEd2tSVcKErzbyGLgaBxtJqN92oA@mail.gmail.com> <CABDkGQmshy0-e4WoPUwK6tyMVtNSUQ3gP=AfyMbohCyM0Y9EHg@mail.gmail.com>
Message-ID: <CABDkGQk-Zj8GQQb1mJNEkoTVPgxpivrL5-99dcPGLCr-wpoPGA@mail.gmail.com>

Hi Tony

2011/9/3 St?fan van der Walt <stefan at sun.ac.za>:
> On Fri, Sep 2, 2011 at 3:53 PM, Tony Yu <tsyu80 at gmail.com> wrote:
>> I'm still playing around with colors and levels---as you can see in the
>> first attachment (demo_array). Also, I've attached some mock-ups of a banner
>> using the logo (demos 1 & 2). demo_2 is in reference to the package rename
>> discussion. (Somewhat identifiable with scikits.image and pronounceable; I'm
>> not sure if I like the way it looks in print, though.)

I'm back from Europe and getting things ready for the 0.3 release.
Could you put your scripts on GitHub or somewhere public so that I may
play around with different colour and picture combos?

Thanks!
St?fan


From tsyu80 at gmail.com  Mon Sep 12 22:46:28 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Mon, 12 Sep 2011 22:46:28 -0400
Subject: Progress towards the next release
In-Reply-To: <CABDkGQk-Zj8GQQb1mJNEkoTVPgxpivrL5-99dcPGLCr-wpoPGA@mail.gmail.com>
References: <CABDkGQk7uCjLCKAB=FANb7gZ5wCv8-wgeibB6-0qSSRsDUg=8g@mail.gmail.com>
	<CAEym_Hp0DG7URm-RontHBPvEd2tSVcKErzbyGLgaBxtJqN92oA@mail.gmail.com>
	<CABDkGQmshy0-e4WoPUwK6tyMVtNSUQ3gP=AfyMbohCyM0Y9EHg@mail.gmail.com>
	<CABDkGQk-Zj8GQQb1mJNEkoTVPgxpivrL5-99dcPGLCr-wpoPGA@mail.gmail.com>
Message-ID: <CAEym_Hriqtb1mpUVQA3Sr2kTNqMGF5uCjx4GL7R3J_ezS82gBg@mail.gmail.com>

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

> Hi Tony
>
> 2011/9/3 St?fan van der Walt <stefan at sun.ac.za>:
> > On Fri, Sep 2, 2011 at 3:53 PM, Tony Yu <tsyu80 at gmail.com> wrote:
> >> I'm still playing around with colors and levels---as you can see in the
> >> first attachment (demo_array). Also, I've attached some mock-ups of a
> banner
> >> using the logo (demos 1 & 2). demo_2 is in reference to the package
> rename
> >> discussion. (Somewhat identifiable with scikits.image and pronounceable;
> I'm
> >> not sure if I like the way it looks in print, though.)
>
> I'm back from Europe and getting things ready for the 0.3 release.
> Could you put your scripts on GitHub or somewhere public so that I may
> play around with different colour and picture combos?
>
> Thanks!
> St?fan
>

I just posted the scripts on github:
https://github.com/tonysyu/scikits_image_logo. The code looks (and probably
is) more complicated than it needs to be, but all you probably need to
understand is the bottom part of "scikits_image_logo.py". If you have any
questions, let me know.

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

From emmanuelle.gouillart at normalesup.org  Tue Sep 13 02:26:57 2011
From: emmanuelle.gouillart at normalesup.org (Emmanuelle Gouillart)
Date: Tue, 13 Sep 2011 08:26:57 +0200
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: <20110913062656.GA29984@phare.normalesup.org>

Hi all,

> - Emmanuelle is incorporating cellprofiler morphology funcs (watershed & others)

Done! See my pull request on the github repo. 

Cheers,

Emmanuelle


From stefan at sun.ac.za  Thu Sep 15 20:09:45 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 15 Sep 2011 17:09:45 -0700
Subject: Progress towards the next release
In-Reply-To: <CAEym_Hp0DG7URm-RontHBPvEd2tSVcKErzbyGLgaBxtJqN92oA@mail.gmail.com>
References: <CABDkGQk7uCjLCKAB=FANb7gZ5wCv8-wgeibB6-0qSSRsDUg=8g@mail.gmail.com>
 <CAEym_Hp0DG7URm-RontHBPvEd2tSVcKErzbyGLgaBxtJqN92oA@mail.gmail.com>
Message-ID: <CABDkGQmW5EHGOhNRFPkxPLNv50pe4KaY=9ry-4=NJGnjqw-BDQ@mail.gmail.com>

Hi Tony

On Fri, Sep 2, 2011 at 6:53 AM, Tony Yu <tsyu80 at gmail.com> wrote:
> I'm still playing around with colors and levels---as you can see in the
> first attachment (demo_array). Also, I've attached some mock-ups of a banner
> using the logo (demos 1 & 2). demo_2 is in reference to the package rename
> discussion. (Somewhat identifiable with scikits.image and pronounceable; I'm
> not sure if I like the way it looks in print, though.)

I just read the code you wrote to do this; very cool!  How did you
determine the coefficients for the SciPy spline?

Also, which font did you use for the logos you made?  If you have an
SVG file, maybe also include that in the archive.  I'm thinking of
adding all of this into the main repo.  In fact, we should probably
use this as a tutorial example.

The snake logo + text as it appears on the Lena example will do
perfectly for the webpage.

Thanks!
St?fan


From stefan at sun.ac.za  Thu Sep 15 20:10:49 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 15 Sep 2011 17:10:49 -0700
Subject: Progress towards the next release
In-Reply-To: <20110913062656.GA29984@phare.normalesup.org>
References: <CABDkGQk7uCjLCKAB=FANb7gZ5wCv8-wgeibB6-0qSSRsDUg=8g@mail.gmail.com>
 <20110913062656.GA29984@phare.normalesup.org>
Message-ID: <CABDkGQnxSfJ1NRBXQv+d==dUGk5hpbh0QZEJ-YwV-8JZgTRdjA@mail.gmail.com>

On Mon, Sep 12, 2011 at 11:26 PM, Emmanuelle Gouillart
<emmanuelle.gouillart at normalesup.org> wrote:
>> - Emmanuelle is incorporating cellprofiler morphology funcs (watershed & others)
>
> Done! See my pull request on the github repo.

Thanks for all your effort on this, Emmanuelle.  I reviewed the
changes and made some comments on how I'd like to integrate it; let me
know what you think.

Regards
St?fan


From tsyu80 at gmail.com  Thu Sep 15 23:16:19 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Thu, 15 Sep 2011 23:16:19 -0400
Subject: Progress towards the next release
In-Reply-To: <CABDkGQmW5EHGOhNRFPkxPLNv50pe4KaY=9ry-4=NJGnjqw-BDQ@mail.gmail.com>
References: <CABDkGQk7uCjLCKAB=FANb7gZ5wCv8-wgeibB6-0qSSRsDUg=8g@mail.gmail.com>
	<CAEym_Hp0DG7URm-RontHBPvEd2tSVcKErzbyGLgaBxtJqN92oA@mail.gmail.com>
	<CABDkGQmW5EHGOhNRFPkxPLNv50pe4KaY=9ry-4=NJGnjqw-BDQ@mail.gmail.com>
Message-ID: <CAEym_Hp7yZvjnCZbE7jcufi9nz_j+L03uxNkhxGR9ynTUPi+hw@mail.gmail.com>

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

> Hi Tony
>
> On Fri, Sep 2, 2011 at 6:53 AM, Tony Yu <tsyu80 at gmail.com> wrote:
> > I'm still playing around with colors and levels---as you can see in the
> > first attachment (demo_array). Also, I've attached some mock-ups of a
> banner
> > using the logo (demos 1 & 2). demo_2 is in reference to the package
> rename
> > discussion. (Somewhat identifiable with scikits.image and pronounceable;
> I'm
> > not sure if I like the way it looks in print, though.)
>
> I just read the code you wrote to do this; very cool!  How did you
> determine the coefficients for the SciPy spline?
>

I actually did that manually; i.e. I kind of knew where I wanted the anchor
points and approximated the angles, then adjusted from there. The smarter
thing to do would've been to trace it with a drawing program and then export
the Bezier points, but I didn't know a good way of doing it.

Also, which font did you use for the logos you made?  If you have an
> SVG file, maybe also include that in the archive.


In the samples I sent, I used Helvetica Neue Light. Unfortunately, I drew
those up with Keynote---just because it was easier for me---so I don't have
an SVG file (Keynote and Preview don't have SVG export options). Ideally, I
would've just drawn the text in Matplotlib, but at the time, I didn't feel
like manually manipulating the text coordinates.

I'm thinking of
> adding all of this into the main repo.  In fact, we should probably
> use this as a tutorial example.
>
> The snake logo + text as it appears on the Lena example will do
> perfectly for the webpage.
>

I hope a PDF is OK. If not, I can work on a fully Matplotlib solution, but
it'll have to wait until I have some free time.

Best,
-T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20110915/51d550ad/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scikits_logo.pdf
Type: application/pdf
Size: 205546 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20110915/51d550ad/attachment.pdf>

From stefan at sun.ac.za  Fri Sep 16 16:43:37 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 16 Sep 2011 13:43:37 -0700
Subject: Integrate cellprofiler (#19) and release schedule
Message-ID: <CABDkGQkUSfL+V2q-KK0icxhRiM8-B=R4+4KK7kHPxkgDBu2sBw@mail.gmail.com>

Hi Emmanuelle

[This in reply to the discussion from
https://github.com/scikits-image/scikits.image/pull/19 ]

On Fri, Sep 16, 2011 at 11:20 AM, emmanuelle
<reply+i-1613972-89d62c860f1868f0cf5f68ffc7b222a2e568a670 at reply.github.com>
wrote:
> 1. Yes, it seems a good idea to centralize these files in a utility
> module. In the future, maybe we can keep only one implementation of
> heaps, either the one by Almar Klein/Zach Pincus, or the cellprofiler
> one. But it would take some time to refactor this code, and the files
> that depend on these modules, so we'd better keep that for the next
> release. In the meantime, we can use a util module to store these files.

Agreed.  I'll all move them to the same place for now (maybe _util to
discourage their use by users for the time being), but we'll leave the
refactoring until later.

> 2. I don't really see the point in separating the cellprofiler code in a
> submodule. For example, cpmorphology contains a lot of core routines
> (skeletonization for example) that should be directly under morphology.

I don't think I expressed my idea clearly.  I just wanted to move all
the .pyx files etc. to a sub-directory of morphology, and them import
them in the __init__ into the morphology namespace.  The only reason
for that was because the cp code had so many files--I thought it might
make it difficult to follow the morphology code if we didn't separate
it in some way.

> 3. I was thinking of stealing the Scikit learn config for generating
> Sphinx documentation from python example files (+ their way to generate a
> gallery). It doesn't seem to hard to reuse.

That would be great.  The current tutorial system is cumbersome.  I'd
like something fairly simple and transparent, and if we can borrow it
from them so much the better.

> I can help you with that, but not this week-end! Next week I can find
> some time. When do you plan to do the release?

I'm having a mini-sprint at Stanford today and will be working all day
Sunday on completing the release.  Realistically, I won't get
everything done on Sunday, but we should be much closer (I'll try and
merge as many PR as possible).

The week thereafter, we can round things up.  Due to time zone
differences, we probably won't all be able to meet at the same time,
but let's coordinate so that, by latest, we release next weekend (24,
25 September).

Regards
St?fan


From stefan at sun.ac.za  Fri Sep 16 16:44:58 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 16 Sep 2011 13:44:58 -0700
Subject: Stanford sprint, Friday 16 September
Message-ID: <CABDkGQnBEe=GphbBcuKenh-Z0NnYB43Q92nCTP8ET=7eW0rnrg@mail.gmail.com>

Hi all,

There'll be a mini sprint at Stanford today.  If you're in the
vicinity, feel free to join in!

We're busy preparing for the September 24 release.

Regards
St?fan


From stefan at sun.ac.za  Sat Sep 17 01:50:08 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 16 Sep 2011 22:50:08 -0700
Subject: Progress towards the next release
In-Reply-To: <CAEym_Hq55GOivPp70KGfnURyxsnXeS_Livy07AvNT=mhf3VLCA@mail.gmail.com>
References: <CABDkGQk7uCjLCKAB=FANb7gZ5wCv8-wgeibB6-0qSSRsDUg=8g@mail.gmail.com>
 <CAEym_Hp0DG7URm-RontHBPvEd2tSVcKErzbyGLgaBxtJqN92oA@mail.gmail.com>
 <CABDkGQmW5EHGOhNRFPkxPLNv50pe4KaY=9ry-4=NJGnjqw-BDQ@mail.gmail.com>
 <CAEym_Hp7yZvjnCZbE7jcufi9nz_j+L03uxNkhxGR9ynTUPi+hw@mail.gmail.com> <CAEym_Hq55GOivPp70KGfnURyxsnXeS_Livy07AvNT=mhf3VLCA@mail.gmail.com>
Message-ID: <CABDkGQkQA1y7D4XdnFyOtjZWQbYRtAvOG+qu4aiFNWixTuC+4w@mail.gmail.com>

On Fri, Sep 16, 2011 at 8:17 PM, Tony Yu <tsyu80 at gmail.com> wrote:
>>> I'm thinking of
>>> adding all of this into the main repo.
>
> That sounds good to me.

Thanks, I've added the code and updated the logo on the main webpage.
It looks very pretty!

>>> ?In fact, we should probably
>>> use this as a tutorial example.
>
> I could go either way on this. On the one hand, I think there's some
> interesting image-processing-related code here. On the other hand, a lot of
> the code *isn't* related to image processing (e.g. creating a class to draw
> Bezier curves, tracing the scipy logo), which makes it's
> usefullness-to-code-length ratio a bit low. That being said, I'd be happy if
> it was added as a tutorial.

Point taken--I'll leave it as is for now.  Besides, there are a
million-and-one things to do before release!

St?fan


From tsyu80 at gmail.com  Fri Sep 16 23:17:30 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Fri, 16 Sep 2011 23:17:30 -0400
Subject: Progress towards the next release
In-Reply-To: <CAEym_Hp7yZvjnCZbE7jcufi9nz_j+L03uxNkhxGR9ynTUPi+hw@mail.gmail.com>
References: <CABDkGQk7uCjLCKAB=FANb7gZ5wCv8-wgeibB6-0qSSRsDUg=8g@mail.gmail.com>
	<CAEym_Hp0DG7URm-RontHBPvEd2tSVcKErzbyGLgaBxtJqN92oA@mail.gmail.com>
	<CABDkGQmW5EHGOhNRFPkxPLNv50pe4KaY=9ry-4=NJGnjqw-BDQ@mail.gmail.com>
	<CAEym_Hp7yZvjnCZbE7jcufi9nz_j+L03uxNkhxGR9ynTUPi+hw@mail.gmail.com>
Message-ID: <CAEym_Hq55GOivPp70KGfnURyxsnXeS_Livy07AvNT=mhf3VLCA@mail.gmail.com>

Oh, I forgot to reply to a couple more comments:

On Thu, Sep 15, 2011 at 11:16 PM, Tony Yu <tsyu80 at gmail.com> wrote:

> 2011/9/15 St?fan van der Walt <stefan at sun.ac.za>
>
> I'm thinking of
>> adding all of this into the main repo.
>>
>
That sounds good to me.


>  In fact, we should probably
>> use this as a tutorial example.
>>
>
I could go either way on this. On the one hand, I think there's some
interesting image-processing-related code here. On the other hand, a lot of
the code *isn't* related to image processing (e.g. creating a class to draw
Bezier curves, tracing the scipy logo), which makes it's
usefullness-to-code-length ratio a bit low. That being said, I'd be happy if
it was added as a tutorial.

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

From stefan at sun.ac.za  Sat Sep 17 13:52:43 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sat, 17 Sep 2011 10:52:43 -0700
Subject: Please review PR21: Summed area table
Message-ID: <CABDkGQ=DSLce_R-Uq66ATqs_619-2c=8yqGOd-O9b_Mtwd8LHQ@mail.gmail.com>

Hi all,

Two of the pull requests waiting to be merged make use of summed area
tables.  I've proposed a Cython implementation here:

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

Please review and tell me what you think.  I'd like this to be
integrated fairly soon, if possible, because it is a bottleneck for
the histogram of gradients and template matching PRs.

Regards
St?fan


From stefan at sun.ac.za  Wed Sep 21 12:27:55 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 21 Sep 2011 09:27:55 -0700
Subject: Link on appspot
In-Reply-To: <4E79A20E.5000800@ais.uni-bonn.de>
References: <4E79A20E.5000800@ais.uni-bonn.de>
Message-ID: <CABDkGQnWBnhNxvJxKAAYsXgwgpyGRZ1DHz9yUWDPMqjuE4Kw5Q@mail.gmail.com>

Hi Andreas

On Wed, Sep 21, 2011 at 1:36 AM, Andreas Mueller
<amueller at ais.uni-bonn.de> wrote:
> First of all, let me congratulate everybody involved on this great project
> :)

Thank you!  We've got room for plenty more :)

> I'm writing since I noticed that when you google the project ("scikits
> image"),
> you'll get scikits.appspot.com/image as your first hit.
> They have a link to the old homepage, which makes you click a link to the
> new homepage.

Yeah, this is an unfortunate side-effect of not having released for so
long.  Luckily, we should have it remedied by this weekend, when we
push out 0.3.  We've been working hard on reviewing patches, writing
documentation, updating the build system, etc. -- but getting there
slowly but surely.

> Another thing I was wondering: Is this the only mailing list for this
> project or is
> there also a developers list?

At the moment, we only have this mailing list.  A lot of the
development conversation also happens on GitHub, inside pull request
comments and so forth.

I see that you've worked on vlfeat wrappers.  I've been thinking of
the best way to provide a scikits.image.feature module, with things
like star features, FAST corner detection (wrappers already written),
etc.  If you have any ideas, I'd love to hear them.

Regards
St?fan


From stefan at sun.ac.za  Wed Sep 21 13:02:45 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 21 Sep 2011 10:02:45 -0700
Subject: Link on appspot
In-Reply-To: <4E7A123D.5090608@ais.uni-bonn.de>
References: <4E79A20E.5000800@ais.uni-bonn.de> <CABDkGQnWBnhNxvJxKAAYsXgwgpyGRZ1DHz9yUWDPMqjuE4Kw5Q@mail.gmail.com>
 <4E7A123D.5090608@ais.uni-bonn.de>
Message-ID: <CABDkGQk4S6MHyQnb47XMRjFU5g93PWsgX7-WAAV=E_5ic9LeKQ@mail.gmail.com>

Hi Andy

On Wed, Sep 21, 2011 at 9:35 AM, Andreas Mueller
<amueller at ais.uni-bonn.de> wrote:
> vlfeat is gpl. Is it possible to include gpl code int scikits.image
> and still release it under BSD license (which is the current
> scikits.image license, right?) ?

Unfortunately not.  Almost the entire scientific software stack
(python, numpy, scipy, ipython, matplotlib, scikit-learn, etc.) are
all BSD; we have great interaction with people from industry (who shy
away from the GPL due to its viral nature), and we do not want to risk
those collaborations.  I also don't like that GPL projects can take
from BSD projects, but that any improvements they make then cannot be
contributed back.

That said, many open source projects are simply unaware of these
issues, and gladly re-license certain portions of their code upon
request.  Some good examples are the CellProfiler team's great
morphology code (currently a pull request, being merged), or Nocedal's
BFGS code that he relicensed BSD for inclusion in SciPy.

> I saw there was also a discussion about making opencv
> an dependency. Wouldn't it be possible to just include some
> of the optimized code without actually using the whole library?
> Or is there to much infrastructure in opencv that gets used?

After conversing with several people at the EuroSciPy conference, I
realised that this would be a bad idea.  People simply don't want such
a heavy dependency.  But your suggestion is the right one: we'll
borrow code where needed (e.g. star features), and send improvements
back to the opencv team as they come up.

> I'm not a big fan of opencv but I guess there is some fairly
> optimized code there that scikits.images might want to use.

OpenCV is crazy fast.  Pieter Holtzhausen, as part of his google
summer of code, implemented an SSE2 convolution, which almost gets to
the OpenCV speed; point is--it takes a lot of manual effort to beat
their code speedwise.  Of course, with all the Python scientific tools
at our disposal, we gain plenty of other benefits that C cannot
provide.

Regards
St?fan


From stefan at sun.ac.za  Wed Sep 21 13:11:18 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 21 Sep 2011 10:11:18 -0700
Subject: Mahotas
In-Reply-To: <4E7A1526.6070101@ais.uni-bonn.de>
References: <4E7A1526.6070101@ais.uni-bonn.de>
Message-ID: <CABDkGQ=gyLryjR6mGPeZsSCHuCrE7HxdZbyJ2EPTN_Nq1B6cxA@mail.gmail.com>

Hi Andy

On Wed, Sep 21, 2011 at 9:47 AM, Andreas Mueller
<amueller at ais.uni-bonn.de> wrote:
> Sorry for spamming the list but I was wondering whether you know about
> mahotas:
> http://luispedro.org/software/mahotas

This ties in with my previous e-mail.  Because of its GPL license,
Mahotas would be allowed to use code from scikits.image, but not the
other way around.

That said, Luis (the author of Mahotas) has kindly contributed back
two patches to scikits.image in the past.

> It seems to be a project with similar goals as scikits.image. There are some
> very
> useful algorithms in there and I was wondering in how far people are
> replicating
> these in scikits.image.

We can always ask Luis whether he would relicense certain portions of
his code, although I think he is well informed about the different
licenses and probably had his reasons for choosing the GPL.

Regards
St?fan


From amueller at ais.uni-bonn.de  Wed Sep 21 04:36:30 2011
From: amueller at ais.uni-bonn.de (Andreas Mueller)
Date: Wed, 21 Sep 2011 10:36:30 +0200
Subject: Link on appspot
Message-ID: <4E79A20E.5000800@ais.uni-bonn.de>

Hi Everybody.

First of all, let me congratulate everybody involved on this great 
project :)

I'm writing since I noticed that when you google the project ("scikits 
image"),
you'll get scikits.appspot.com/image as your first hit.
They have a link to the old homepage, which makes you click a link to 
the new homepage.
This seems somewhat annoying (three clicks until I'm there) which could 
be somewhat
improved by providing the correct link at scikits.appspot.com.

Another thing I was wondering: Is this the only mailing list for this 
project or is
there also a developers list?

Cheers,
Andy


From amueller at ais.uni-bonn.de  Wed Sep 21 12:35:09 2011
From: amueller at ais.uni-bonn.de (Andreas Mueller)
Date: Wed, 21 Sep 2011 18:35:09 +0200
Subject: Link on appspot
In-Reply-To: <CABDkGQnWBnhNxvJxKAAYsXgwgpyGRZ1DHz9yUWDPMqjuE4Kw5Q@mail.gmail.com>
References: <4E79A20E.5000800@ais.uni-bonn.de> <CABDkGQnWBnhNxvJxKAAYsXgwgpyGRZ1DHz9yUWDPMqjuE4Kw5Q@mail.gmail.com>
Message-ID: <4E7A123D.5090608@ais.uni-bonn.de>

Hi Stefan.
> I see that you've worked on vlfeat wrappers.  I've been thinking of
> the best way to provide a scikits.image.feature module, with things
> like star features, FAST corner detection (wrappers already written),
> etc.  If you have any ideas, I'd love to hear them.
I'm only roughly familiar with keypoint detection.
But I thought about integrating SIFT code from vlfeat.
I love vlfeat but it's to much matlab...
And I'm pretty sure it's hard to beat the vlfeat SSE2 code.

I guess similar things apply to corner detection.

vlfeat is gpl. Is it possible to include gpl code int scikits.image
and still release it under BSD license (which is the current
scikits.image license, right?) ?

I saw there was also a discussion about making opencv
an dependency. Wouldn't it be possible to just include some
of the optimized code without actually using the whole library?
Or is there to much infrastructure in opencv that gets used?

I'm not a big fan of opencv but I guess there is some fairly
optimized code there that scikits.images might want to use.

Cheers,
Andy


From amueller at ais.uni-bonn.de  Wed Sep 21 12:47:34 2011
From: amueller at ais.uni-bonn.de (Andreas Mueller)
Date: Wed, 21 Sep 2011 18:47:34 +0200
Subject: Mahotas
Message-ID: <4E7A1526.6070101@ais.uni-bonn.de>

Hi scikits-image people.
Sorry for spamming the list but I was wondering whether you know about 
mahotas:
http://luispedro.org/software/mahotas

It seems to be a project with similar goals as scikits.image. There are 
some very
useful algorithms in there and I was wondering in how far people are 
replicating
these in scikits.image.

Cheers,
Andy


From stefan at sun.ac.za  Sun Sep 25 21:26:41 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 25 Sep 2011 18:26:41 -0700
Subject: PR 26 and 27
Message-ID: <CABDkGQkxkggH4NQ8xerA-opfZkRB+ACVzCa90hWBkX0GFrQQZQ@mail.gmail.com>

Hi all,

The radon transform code written by Pieter works well, but currently
depends on PIL.  I've added "fast_homography" to
scikits.image.transform:

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

The idea is to eventually replace scikits.image.transform.homography
by fast_homography.
With the new function in place, the radon transform code can run
without using PIL:

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

As a bonus, the results are also more accurate, because we don't
convert to uint8 afterwards.

Please review!  We're making good progress to the release; thanks to
everyone who has helped out so far.

Thanks
St?fan


From stefan at sun.ac.za  Mon Sep 26 04:04:16 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 26 Sep 2011 01:04:16 -0700
Subject: Brian Holt's histogram of gradient code: ready for merging
Message-ID: <CABDkGQmnps3mdrT1h-d1BGaU2nhfdppO63hHsfVuuXmoNtb20A@mail.gmail.com>

Hi all

I'm ready to merge Brian's histogram of gradient code.  In order to
remove the PIL dependency, I've added a new submodule called
"scikits.image.draw", with Bresenheim's algorithm (used to determine
the coordinates for plotting a line [or circle--not implemented]).

Please have a look and send any comments my way.  I'll merge this
tomorrow if I don't hear anything back.

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

Also, I think the new draw module could be a fun place for people who
are new to the project to make a good contribution.  For example, I'd
like to see a NumPy implementation of Wu's algorithm for drawing lines
and circles.

Regards
St?fan


From stefan at sun.ac.za  Mon Sep 26 13:23:52 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 26 Sep 2011 10:23:52 -0700
Subject: Image data types and conversions
In-Reply-To: <4E803C53.4030502@ais.uni-bonn.de>
References: <4E803C53.4030502@ais.uni-bonn.de>
Message-ID: <CABDkGQk6TEffZHVRaHcfTgCn+2a63UOguZEwSj4+x8im2BPxyQ@mail.gmail.com>

Hi Andy

On Mon, Sep 26, 2011 at 1:48 AM, Andreas Mueller
<amueller at ais.uni-bonn.de> wrote:
> Since I am new to the project I am not sure whether that has been discussed
> before, but
> I think there is still some work to do concerning data types of images.

Yes, you're right.  This is an issue that came up for discussion at
SciPy2011 as well, and I've put a first draft proposal for handing
data types here:

http://scikits-image.org/docs/dev/user_guide/data_types.html

> As far as I can tell, most algorithms work with either uchar in the range
> 0-255 or
> float in the range 0-1.
> As far as I could see, no conversion was done between them and if the input
> to an
> algorithm was not in the right type, it just gave a garbage result (for
> example
> some edge detection or color space conversion).

Hopefully, as soon as we've agree to the data type guidelines, we can
start adding in the necessary conversion functions.

> I personally believe that the library should be written in a way that a user
> can
> build a pipeline without doing any explicit type conversions.
> What do you think about that?

In an ideal world, yes.  Unfortunately, there's often a cost involved
to doing the conversions, so the suggestion is to allow almost any
kind of input, but to not specify the output format.  You'd therefore
be able to do something like

result = img_as_uint(some_func(x))

Let me know what you think of the proposal, then we work from there.

Regards
St?fan


From stefan at sun.ac.za  Mon Sep 26 13:37:56 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 26 Sep 2011 10:37:56 -0700
Subject: Release progress
Message-ID: <CABDkGQ==S7TWrfVhAt4O_XyRrg=QNxRGDpwgSDGTjukr-dDXuw@mail.gmail.com>

Hi all,

We're making good progress on the release.  Here's a summary of what
still needs to happen:

- Pull-request review:

https://github.com/scikits-image/scikits.image/pull/28 [Histogram of
Gradients + draw]
https://github.com/scikits-image/scikits.image/pull/27 [Radon + fast_homography]

- Merge:

https://github.com/scikits-image/scikits.image/pull/19 [CellProfiler
morphology] [will also require minor moving around of files]
https://github.com/scikits-image/scikits.image/pull/14 [New backend system]
https://github.com/scikits-image/scikits.image/pull/12 [Probabilistic hough]
https://github.com/scikits-image/scikits.image/pull/12 [Video IO]

- PRs that can possibly still make this release, with little effort:

https://github.com/scikits-image/scikits.image/pull/7 [Colour channels
are currently returned in the wrong order]
https://github.com/scikits-image/scikits.image/pull/13 [Needs some
minor cleanup; remove default cv dependency]

- PRs that will have to wait until the next release:

https://github.com/scikits-image/scikits.image/pull/16 [Fast
convolution; boundary modes need to be added]


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.

>From now until release, we'll stop considering PRs other than minor
updates or documentation.

Regards
St?fan


From amueller at ais.uni-bonn.de  Mon Sep 26 04:48:19 2011
From: amueller at ais.uni-bonn.de (Andreas Mueller)
Date: Mon, 26 Sep 2011 10:48:19 +0200
Subject: Image data types and conversions
Message-ID: <4E803C53.4030502@ais.uni-bonn.de>

Hi everybody.

Since I am new to the project I am not sure whether that has been 
discussed before, but
I think there is still some work to do concerning data types of images.

As far as I can tell, most algorithms work with either uchar in the 
range 0-255 or
float in the range 0-1.
As far as I could see, no conversion was done between them and if the 
input to an
algorithm was not in the right type, it just gave a garbage result (for 
example
some edge detection or color space conversion).

I personally believe that the library should be written in a way that a 
user can
build a pipeline without doing any explicit type conversions.
What do you think about that?

That would mean that the algorithms would do automatic type conversion
when needed. From the doc it seems like something similar is planned.

To do automatic type conversions, there needs to be some way for the
algorithms to figure out what range the data has. I would assume
that float numbers should always be between 0 and 1 and
ubyte is always between 0 and 255.

At the moment, if you give an ubyte image to (for example) the
color space transforms, you get a _float_ in the range 0-255.
After that, I think it is impossible to automatically find out the range
of the data.
I think given ubyte data, either the algorithms should return a ubyte
(loosing precision) or return a float between 0 and 1.

Do you think this is a good approach?
Or is there already some other concept planned?

I think this is an important issue for an image library since
having to do explicit type conversions really hinders usability.

Cheers,
Andy



From stefan at sun.ac.za  Mon Sep 26 14:01:19 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 26 Sep 2011 11:01:19 -0700
Subject: Image data types and conversions
In-Reply-To: <4E80B955.6050706@ais.uni-bonn.de>
References: <4E803C53.4030502@ais.uni-bonn.de> <CABDkGQk6TEffZHVRaHcfTgCn+2a63UOguZEwSj4+x8im2BPxyQ@mail.gmail.com>
 <4E80B955.6050706@ais.uni-bonn.de>
Message-ID: <CABDkGQkFwfdZgWc3N3upMx--GFDUKOue9NJ+wmYNnUB7+4N+Fg@mail.gmail.com>

Hi Andreas

On Mon, Sep 26, 2011 at 10:41 AM, Andreas Mueller
<amueller at ais.uni-bonn.de> wrote:
> I feel there is still something missing, though.
>
> Going back to the colorspace example, given a ubyte input,
> the current algorithm produces a float 0.-255..
> I'm not sure whether it is more expensive to divide by 255.
> or to round to uint.

That's wrong, obviously.  If we implemented the suggestion above, the
output would always have been properly scaled to [0, 1].

> But what should the output be? I think this is a very common case
> since often a loaded image is in ubyte and then some continous
> operation is applied.

In this case it's easy, since rgb2gray cannot produce accurate results
unless using floats.

> Personally, I think I would round which would correspond to
> the principle of least surprise. But maybe someone else
> feels the precision lost is important?

Maybe I should just write the conversion functions quickly, then we
have something to work from.  They should definitely complain when you
go from float to uint, but not the other way around.

> So maybe the guidline I would like is either:
> - go for precision
> - go for consistency with input
> - go for speed an then pick one of the others?

Accuracy is definitely #1.  That's why the suggestion is that
algorithms choose for themselves.  Sometimes it makes sense to return
the same type as the input, sometimes it doesn't.  What is important
is that images remain scaled, and can again be interpreted by the next
function in the pipeline.  Where possible, we do not want to make
copies in memory.  So, in rgb2gray's case, e.g., the conversion gives
floating point numbers by default.  We do not need to convert those
numbers to uint for the user and, actually, we shouldn't--because that
would destroy accuracy.

I'll whip up the conversion functions and offer them as a PR.  This is
probably important, since it will influence the code written for 0.4 a
lot.

Cheers
St?fan


From stefan at sun.ac.za  Mon Sep 26 19:38:17 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 26 Sep 2011 16:38:17 -0700
Subject: Image data types and conversions
In-Reply-To: <4E80BF66.1040403@ais.uni-bonn.de>
References: <4E803C53.4030502@ais.uni-bonn.de> <CABDkGQk6TEffZHVRaHcfTgCn+2a63UOguZEwSj4+x8im2BPxyQ@mail.gmail.com>
 <4E80B955.6050706@ais.uni-bonn.de> <CABDkGQkFwfdZgWc3N3upMx--GFDUKOue9NJ+wmYNnUB7+4N+Fg@mail.gmail.com>
 <4E80BF66.1040403@ais.uni-bonn.de>
Message-ID: <CABDkGQm-=tBqE_uDynmXR_y=yXQhXeHYmEk+KxuuhsWJt0d-_g@mail.gmail.com>

On Mon, Sep 26, 2011 at 11:07 AM, Andreas Mueller
<amueller at ais.uni-bonn.de> wrote:
>> I'll whip up the conversion functions and offer them as a PR. ?This is
>> probably important, since it will influence the code written for 0.4 a
>> lot.
>>
> Thanks for tanking my concern seriously. Sounds great :)

Here we go:

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

Regards
St?fan


From amueller at ais.uni-bonn.de  Mon Sep 26 13:41:41 2011
From: amueller at ais.uni-bonn.de (Andreas Mueller)
Date: Mon, 26 Sep 2011 19:41:41 +0200
Subject: Image data types and conversions
In-Reply-To: <CABDkGQk6TEffZHVRaHcfTgCn+2a63UOguZEwSj4+x8im2BPxyQ@mail.gmail.com>
References: <4E803C53.4030502@ais.uni-bonn.de> <CABDkGQk6TEffZHVRaHcfTgCn+2a63UOguZEwSj4+x8im2BPxyQ@mail.gmail.com>
Message-ID: <4E80B955.6050706@ais.uni-bonn.de>

Hi Stefan.
> Yes, you're right.  This is an issue that came up for discussion at
> SciPy2011 as well, and I've put a first draft proposal for handing
> data types here:
>
> http://scikits-image.org/docs/dev/user_guide/data_types.html
>
I saw that but I felt it did not really answer my questions ;)


>
>> I personally believe that the library should be written in a way that a user
>> can
>> build a pipeline without doing any explicit type conversions.
>> What do you think about that?
> In an ideal world, yes.  Unfortunately, there's often a cost involved
> to doing the conversions, so the suggestion is to allow almost any
> kind of input, but to not specify the output format.  You'd therefore
> be able to do something like
>
> result = img_as_uint(some_func(x))

There is certainly a tradeoff there.
And I think the suggestion sounds reasonable.

I feel there is still something missing, though.

Going back to the colorspace example, given a ubyte input,
the current algorithm produces a float 0.-255..
I'm not sure whether it is more expensive to divide by 255.
or to round to uint.

As I understand the draft, the current output is not legal, which
is reasonable.
But what should the output be? I think this is a very common case
since often a loaded image is in ubyte and then some continous
operation is applied.

Personally, I think I would round which would correspond to
the principle of least surprise. But maybe someone else
feels the precision lost is important?

So maybe the guidline I would like is either:
- go for precision
- go for consistency with input
- go for speed an then pick one of the others?


I hope I made my question clear ;)

Cheers,
Andy


From amueller at ais.uni-bonn.de  Mon Sep 26 14:07:34 2011
From: amueller at ais.uni-bonn.de (Andreas Mueller)
Date: Mon, 26 Sep 2011 20:07:34 +0200
Subject: Image data types and conversions
In-Reply-To: <CABDkGQkFwfdZgWc3N3upMx--GFDUKOue9NJ+wmYNnUB7+4N+Fg@mail.gmail.com>
References: <4E803C53.4030502@ais.uni-bonn.de> <CABDkGQk6TEffZHVRaHcfTgCn+2a63UOguZEwSj4+x8im2BPxyQ@mail.gmail.com> <4E80B955.6050706@ais.uni-bonn.de> <CABDkGQkFwfdZgWc3N3upMx--GFDUKOue9NJ+wmYNnUB7+4N+Fg@mail.gmail.com>
Message-ID: <4E80BF66.1040403@ais.uni-bonn.de>

Hi Stefan.

> Accuracy is definitely #1.  That's why the suggestion is that
> algorithms choose for themselves.  Sometimes it makes sense to return
> the same type as the input, sometimes it doesn't.  What is important
> is that images remain scaled, and can again be interpreted by the next
> function in the pipeline.  Where possible, we do not want to make
> copies in memory.  So, in rgb2gray's case, e.g., the conversion gives
> floating point numbers by default.  We do not need to convert those
> numbers to uint for the user and, actually, we shouldn't--because that
> would destroy accuracy.
>

Thanks. That definitely answers my question.

> I'll whip up the conversion functions and offer them as a PR.  This is
> probably important, since it will influence the code written for 0.4 a
> lot.
>
Thanks for tanking my concern seriously. Sounds great :)

Cheers,
Andy