From stefan at sun.ac.za  Thu Dec  1 16:14:10 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 1 Dec 2011 13:14:10 -0800
Subject: Preparing for 0.4 and updated gallery
Message-ID: <CABDkGQm9QL4ptPGbXmwT9piSWRE2cStTk-0NhX3FCjw7_aOwKQ@mail.gmail.com>

Hi all,

I think we are basically ready to tag 0.4!  If you know of any issue
that needs to be addressed urgently, let me know.

The gallery is also filling up very nicely!

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

E.g, you'll see the contour finding by Zach Pincus that was merged
today, and the grey-level co-occurrence matrix work by Neil Yager.

According to Ohloh, we now have about 10,000 lines of Python code, vs,
e.g., scikit-learn's 30,000.  Keep it coming!

Cheers
St?fan


From dfarmernv at gmail.com  Thu Dec  1 16:34:40 2011
From: dfarmernv at gmail.com (Dan Farmer)
Date: Thu, 1 Dec 2011 13:34:40 -0800
Subject: Preparing for 0.4 and updated gallery
In-Reply-To: <CABDkGQm9QL4ptPGbXmwT9piSWRE2cStTk-0NhX3FCjw7_aOwKQ@mail.gmail.com>
References: <CABDkGQm9QL4ptPGbXmwT9piSWRE2cStTk-0NhX3FCjw7_aOwKQ@mail.gmail.com>
Message-ID: <CAHJ7L4_uN6KnO_DEdKvKf5wu2X9=N9puXX+E+ooOiCjK42Njxw@mail.gmail.com>

That is looking fantastic. Hopefully when winter break gets here I'll
have some time to make some more contributions. Great job!

-Dan

2011/12/1 St?fan van der Walt <stefan at sun.ac.za>:
> Hi all,
>
> I think we are basically ready to tag 0.4! ?If you know of any issue
> that needs to be addressed urgently, let me know.
>
> The gallery is also filling up very nicely!
>
> http://scikits-image.org/docs/dev/auto_examples/index.html
>
> E.g, you'll see the contour finding by Zach Pincus that was merged
> today, and the grey-level co-occurrence matrix work by Neil Yager.
>
> According to Ohloh, we now have about 10,000 lines of Python code, vs,
> e.g., scikit-learn's 30,000. ?Keep it coming!
>
> Cheers
> St?fan


From emmanuelle.gouillart at nsup.org  Fri Dec  2 12:26:22 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Fri, 2 Dec 2011 18:26:22 +0100
Subject: Preparing for 0.4 and updated gallery
In-Reply-To: <CABDkGQm9QL4ptPGbXmwT9piSWRE2cStTk-0NhX3FCjw7_aOwKQ@mail.gmail.com>
References: <CABDkGQm9QL4ptPGbXmwT9piSWRE2cStTk-0NhX3FCjw7_aOwKQ@mail.gmail.com>
Message-ID: <20111202172622.GC17302@phare.normalesup.org>

Great! These will be very exciting news to disclose in my talk @ Scipy
India on this Sunday!

Cheers,
Emmanuelle

On Thu, Dec 01, 2011 at 01:14:10PM -0800, St??????fan van der Walt wrote:
> Hi all,

> I think we are basically ready to tag 0.4!  If you know of any issue
> that needs to be addressed urgently, let me know.

> The gallery is also filling up very nicely!

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

> E.g, you'll see the contour finding by Zach Pincus that was merged
> today, and the grey-level co-occurrence matrix work by Neil Yager.

> According to Ohloh, we now have about 10,000 lines of Python code, vs,
> e.g., scikit-learn's 30,000.  Keep it coming!

> Cheers
> St??????fan


From stefan at sun.ac.za  Sat Dec  3 17:42:41 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sat, 3 Dec 2011 14:42:41 -0800
Subject: scikits-image 0.4 release
Message-ID: <CABDkGQkUJY-sH-R=wGH1KTu64kfG2e-4o7hxDqwTftGfZn19RQ@mail.gmail.com>

Announcement: scikits-image 0.4
===============================

We're happy to announce the 0.4 release of scikits-image, an image processing
toolbox for SciPy.

Please visit our examples gallery to see what we've been up to:

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

Note that, in this release, we renamed the module from ``scikits.image`` to
``skimage``, to work around name space conflicts with other scikits (similarly,
the machine learning scikit is now imported as ``sklearn``).

A big shout-out also to everyone currently at SciPy India; have fun, and
remember to join the scikits-image sprint!

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

New Features
------------
- Module rename from ``scikits.image`` to ``skimage``
- Contour finding
- Grey-level co-occurrence matrices
- Skeletonization and medial axis transform
- Convex hull images
- New test data sets
- GDAL I/O plugin

... as well as some bug fixes.

Contributors to this release
----------------------------
* Andreas Mueller
* Christopher Gohlke
* Emmanuelle Gouillart
* Neil Yager
* Nelle Varoquaux
* Riaan van den Dool
* Stefan van der Walt
* Thouis (Ray) Jones
* Tony S Yu
* Zachary Pincus


From stefan at sun.ac.za  Sat Dec  3 17:46:28 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sat, 3 Dec 2011 14:46:28 -0800
Subject: sprint @Scipy India on Thursday 8th
In-Reply-To: <20111203162838.GA2350@phare.normalesup.org>
References: <20111203162838.GA2350@phare.normalesup.org>
Message-ID: <CABDkGQkxiN17OaMpx3u6RzAA1ss94RiWtc9-DYc2v9VdBogbSw@mail.gmail.com>

Hey Emmanuelle

On Sat, Dec 3, 2011 at 8:28 AM, Emmanuelle Gouillart
<emmanuelle.gouillart at nsup.org> wrote:
> ? ? ? ?the day for sprints at Scipy India is next Thursday (Dec 8th).
> How about having a skimage sprint during this day? Tomorrow is the first
> day of the conference, I'll try to see if some attendees could be
> interested. If some people here use image processing for their work,
> I'll try to make them write examples about their usecases. I'm only
> catching up after two weeks of travelling in India, but I'll try to make
> more precise suggestions for the sprint in the next few days.

Thanks for organising this!  I'll try my best to join, depending on
how the time zones work out.

I think you're right: building examples may be the most productive use
of newcomers' time.  Also, if anyone wants to spruce up the webpage,
write some docs, work on the Debian packaging etc., we can easily get
them started.

Enjoy the conference!
St?fan


From emmanuelle.gouillart at nsup.org  Sat Dec  3 11:28:38 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Sat, 3 Dec 2011 17:28:38 +0100
Subject: sprint @Scipy India on Thursday 8th
Message-ID: <20111203162838.GA2350@phare.normalesup.org>

	Hi all,

	the day for sprints at Scipy India is next Thursday (Dec 8th).
How about having a skimage sprint during this day? Tomorrow is the first
day of the conference, I'll try to see if some attendees could be
interested. If some people here use image processing for their work,
I'll try to make them write examples about their usecases. I'm only
catching up after two weeks of travelling in India, but I'll try to make
more precise suggestions for the sprint in the next few days.

	Anyone interested in joining in?

	Cheers,
	Emmanuelle



From jeanpatrick.pommier at gmail.com  Sun Dec  4 12:58:30 2011
From: jeanpatrick.pommier at gmail.com (jip)
Date: Sun, 4 Dec 2011 09:58:30 -0800 (PST)
Subject: scikits-image 0.4 release
In-Reply-To: <CABDkGQkUJY-sH-R=wGH1KTu64kfG2e-4o7hxDqwTftGfZn19RQ@mail.gmail.com>
References: <CABDkGQkUJY-sH-R=wGH1KTu64kfG2e-4o7hxDqwTftGfZn19RQ@mail.gmail.com>
Message-ID: <28464018.75.1323021510222.JavaMail.geo-discussion-forums@vbjs5>

Thank you,
I just upgrade


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

From stefan at sun.ac.za  Mon Dec  5 05:20:30 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 5 Dec 2011 02:20:30 -0800
Subject: scikits-image 0.4 release
In-Reply-To: <20111205095057.GA17331@phare.normalesup.org>
References: <CABDkGQkUJY-sH-R=wGH1KTu64kfG2e-4o7hxDqwTftGfZn19RQ@mail.gmail.com>
 <20111205095057.GA17331@phare.normalesup.org>
Message-ID: <CABDkGQ=K_-_AKMP=FtdGbBPsvaWE9UEM9X-kLrMDcROr=zd2Xw@mail.gmail.com>

On Mon, Dec 5, 2011 at 1:50 AM, Emmanuelle Gouillart
<emmanuelle.gouillart at nsup.org> wrote:
> Very cool :-). I was very excited to talk about the new release during my
> talk at Scipy India (a few hours ago), thanks for the opportunity to
> advertise the release!

Thanks for mentioning the package during your talk; much appreciated!
I hope you're having a good time at the conference, and I'm sorry I
can't be there to sprint along.

> During questions, I was asked if during the sprint, it would be possible
> to contribute to the Debian/Ubuntu packaging. I don't know the status of
> the packaging, and if something could be done to help with the packaging.
> What should I answer to the person who asked about packaging?

Absolutely!  The biggest problem at the moment is that the package
needs to be scanned carefully, and the (Debian) license file update
accordingly.  Furthermore, the package needs to be changed to handle
the module rename to skimage.  Then we also need a man page for scivi,
the image viewer.  See this PR for a summary:

https://github.com/stefanv/scikits-image/pull/1

The latest Debian package files are kept here:

https://github.com/stefanv/scikits-image/tree/debian

I'd be really happy if someone could help with this, so that we can
get 0.4 included in Debian (and hopefully in time for the next Ubuntu
download).

Regards
St?fan


From jeanpatrick.pommier at gmail.com  Mon Dec  5 08:21:17 2011
From: jeanpatrick.pommier at gmail.com (jip)
Date: Mon, 5 Dec 2011 05:21:17 -0800 (PST)
Subject: io plugin issue (8bits 16bits)
Message-ID: <26552631.1394.1323091277849.JavaMail.geo-discussion-forums@yqcc19>

Dear all,

I meet some problem to open/display 12bits tif (16 bits) gray images.
I can open an image but I fail to display it:
import skimage
path='/media/Elements__/Science/Biologie/QTeloFISH/myoblastes 
HPS/JPP55_nFF/16/DAPI'
image='/1.tif'
from skimage import io as io

print skimage.io.plugin_info('matplotlib')
#skimage.io.use_plugin('matplotlib', 'read')

#dapi=io.imread(path+image,plugin='matplotlib')
dapi=io.imread(path+image)

print type(dapi)
print type(dapi)
print 'dapi.dtype',dapi.dtype

io.imshow(dapi)
#import pylab
#pylab.imshow(dapi)
#pylab.show()
Then I get the following error:
*<type 'numpy.ndarray'>
<type 'numpy.ndarray'>
dapi.dtype object
Traceback (most recent call last):
  File "/home/claire/.spyder2/.temp.py", line 28, in <module>
    io.imshow(dapi)
  File 
"/usr/local/lib/python2.6/dist-packages/skimage-0.4-py2.6-linux-i686.egg/skimage/io/_io.py", 
line 149, in imshow
    return call_plugin('imshow', arr, plugin=plugin, **plugin_args)
  File 
"/usr/local/lib/python2.6/dist-packages/skimage-0.4-py2.6-linux-i686.egg/skimage/io/_plugins/plugin.py", 
line 88, in call
    return func(*args, **kwargs)
  File 
"/usr/local/lib/python2.6/dist-packages/skimage-0.4-py2.6-linux-i686.egg/skimage/io/_plugins/pil_plugin.py", 
line 108, in imshow
    Image.fromarray(arr).show()
  File "/usr/lib/python2.6/dist-packages/PIL/Image.py", line 1886, in 
fromarray
    raise TypeError("Cannot handle this data type")
TypeError: Cannot handle this data type
*
The default plugin is PIL.If I try to switch to matplotlib (or freeimage), 
the plugin doesn't seem available:
*Traceback (most recent call last):
  File "/home/claire/.spyder2/.temp.py", line 16, in <module>
    dapi=io.imread(path+image,plugin='matplotlib')
  File 
"/usr/local/lib/python2.6/dist-packages/skimage-0.4-py2.6-linux-i686.egg/skimage/io/_io.py", 
line 72, in imread
    img = call_plugin('imread', fname, plugin=plugin, **plugin_args)
  File 
"/usr/local/lib/python2.6/dist-packages/skimage-0.4-py2.6-linux-i686.egg/skimage/io/_plugins/plugin.py", 
line 86, in call
    (plugin, kind))
RuntimeError: Could not find the plugin "matplotlib" for imread.*
I can open the same image with plugin='pil' but I fail to display it:
*uint16
(1024, 1536)
Traceback (most recent call last):
  File "/home/claire/.spyder2/.temp.py", line 28, in <module>
    io.imshow(dapi0)
  File 
"/usr/local/lib/python2.6/dist-packages/skimage-0.4-py2.6-linux-i686.egg/skimage/io/_io.py", 
line 149, in imshow
    return call_plugin('imshow', arr, plugin=plugin, **plugin_args)
  File 
"/usr/local/lib/python2.6/dist-packages/skimage-0.4-py2.6-linux-i686.egg/skimage/io/_plugins/plugin.py", 
line 88, in call
    return func(*args, **kwargs)
  File 
"/usr/local/lib/python2.6/dist-packages/skimage-0.4-py2.6-linux-i686.egg/skimage/io/_plugins/pil_plugin.py", 
line 108, in imshow
    Image.fromarray(arr).show()
  File "/usr/lib/python2.6/dist-packages/PIL/Image.py", line 1886, in 
fromarray
    raise TypeError("Cannot handle this data type")
TypeError: Cannot handle this data type*

Does io.imshow() support only 8bits image?

I can open and display the image with readmagick/pylab.

Best regards
Jean-Patrick


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

From emmanuelle.gouillart at nsup.org  Mon Dec  5 04:50:57 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Mon, 5 Dec 2011 10:50:57 +0100
Subject: scikits-image 0.4 release
In-Reply-To: <CABDkGQkUJY-sH-R=wGH1KTu64kfG2e-4o7hxDqwTftGfZn19RQ@mail.gmail.com>
References: <CABDkGQkUJY-sH-R=wGH1KTu64kfG2e-4o7hxDqwTftGfZn19RQ@mail.gmail.com>
Message-ID: <20111205095057.GA17331@phare.normalesup.org>

Very cool :-). I was very excited to talk about the new release during my
talk at Scipy India (a few hours ago), thanks for the opportunity to
advertise the release!

During questions, I was asked if during the sprint, it would be possible
to contribute to the Debian/Ubuntu packaging. I don't know the status of
the packaging, and if something could be done to help with the packaging.
What should I answer to the person who asked about packaging?

Cheers,
Emmanuelle 

On Sat, Dec 03, 2011 at 02:42:41PM -0800, St??????fan van der Walt wrote:
> Announcement: scikits-image 0.4
> ===============================

> We're happy to announce the 0.4 release of scikits-image, an image processing
> toolbox for SciPy.

> Please visit our examples gallery to see what we've been up to:

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

> Note that, in this release, we renamed the module from ``scikits.image`` to
> ``skimage``, to work around name space conflicts with other scikits (similarly,
> the machine learning scikit is now imported as ``sklearn``).

> A big shout-out also to everyone currently at SciPy India; have fun, and
> remember to join the scikits-image sprint!

> 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

> New Features
> ------------
> - Module rename from ``scikits.image`` to ``skimage``
> - Contour finding
> - Grey-level co-occurrence matrices
> - Skeletonization and medial axis transform
> - Convex hull images
> - New test data sets
> - GDAL I/O plugin

> ... as well as some bug fixes.

> Contributors to this release
> ----------------------------
> * Andreas Mueller
> * Christopher Gohlke
> * Emmanuelle Gouillart
> * Neil Yager
> * Nelle Varoquaux
> * Riaan van den Dool
> * Stefan van der Walt
> * Thouis (Ray) Jones
> * Tony S Yu
> * Zachary Pincus


From stefan at sun.ac.za  Mon Dec  5 14:08:36 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 5 Dec 2011 11:08:36 -0800
Subject: io plugin issue (8bits 16bits)
In-Reply-To: <26552631.1394.1323091277849.JavaMail.geo-discussion-forums@yqcc19>
References: <26552631.1394.1323091277849.JavaMail.geo-discussion-forums@yqcc19>
Message-ID: <CABDkGQk9DfzzOf-g5wDA77iL9hYAR_qfrTBBqgiVJCNEj42SUg@mail.gmail.com>

Hi JP

Thanks for finding this issue. Would you mind placing a small 12-bit tiff
online somewhere so that I can use it in the test suite?

It's strange that the matplotlib plugin is not available, since you mention
that you have pylab.  Can you import matplotlib without problems?

Regards
St?fan
On Dec 5, 2011 5:30 AM, "jip" <jeanpatrick.pommier at gmail.com> wrote:

> Dear all,
>
> I meet some problem to open/display 12bits tif (16 bits) gray images.
> I can open an image but I fail to display it:
> import skimage
> path='/media/Elements__/Science/Biologie/QTeloFISH/myoblastes
> HPS/JPP55_nFF/16/DAPI'
> image='/1.tif'
> from skimage import io as io
>
> print skimage.io.plugin_info('matplotlib')
> #skimage.io.use_plugin('matplotlib', 'read')
>
> #dapi=io.imread(path+image,plugin='matplotlib')
> dapi=io.imread(path+image)
>
> print type(dapi)
> print type(dapi)
> print 'dapi.dtype',dapi.dtype
>
> io.imshow(dapi)
> #import pylab
> #pylab.imshow(dapi)
> #pylab.show()
> Then I get the following error:
> *<type 'numpy.ndarray'>
> <type 'numpy.ndarray'>
> dapi.dtype object
> Traceback (most recent call last):
>   File "/home/claire/.spyder2/.temp.py", line 28, in <module>
>     io.imshow(dapi)
>   File
> "/usr/local/lib/python2.6/dist-packages/skimage-0.4-py2.6-linux-i686.egg/skimage/io/_io.py",
> line 149, in imshow
>     return call_plugin('imshow', arr, plugin=plugin, **plugin_args)
>   File
> "/usr/local/lib/python2.6/dist-packages/skimage-0.4-py2.6-linux-i686.egg/skimage/io/_plugins/plugin.py",
> line 88, in call
>     return func(*args, **kwargs)
>   File
> "/usr/local/lib/python2.6/dist-packages/skimage-0.4-py2.6-linux-i686.egg/skimage/io/_plugins/pil_plugin.py",
> line 108, in imshow
>     Image.fromarray(arr).show()
>   File "/usr/lib/python2.6/dist-packages/PIL/Image.py", line 1886, in
> fromarray
>     raise TypeError("Cannot handle this data type")
> TypeError: Cannot handle this data type
> *
> The default plugin is PIL.If I try to switch to matplotlib (or freeimage),
> the plugin doesn't seem available:
> *Traceback (most recent call last):
>   File "/home/claire/.spyder2/.temp.py", line 16, in <module>
>     dapi=io.imread(path+image,plugin='matplotlib')
>   File
> "/usr/local/lib/python2.6/dist-packages/skimage-0.4-py2.6-linux-i686.egg/skimage/io/_io.py",
> line 72, in imread
>     img = call_plugin('imread', fname, plugin=plugin, **plugin_args)
>   File
> "/usr/local/lib/python2.6/dist-packages/skimage-0.4-py2.6-linux-i686.egg/skimage/io/_plugins/plugin.py",
> line 86, in call
>     (plugin, kind))
> RuntimeError: Could not find the plugin "matplotlib" for imread.*
> I can open the same image with plugin='pil' but I fail to display it:
> *uint16
> (1024, 1536)
> Traceback (most recent call last):
>   File "/home/claire/.spyder2/.temp.py", line 28, in <module>
>     io.imshow(dapi0)
>   File
> "/usr/local/lib/python2.6/dist-packages/skimage-0.4-py2.6-linux-i686.egg/skimage/io/_io.py",
> line 149, in imshow
>     return call_plugin('imshow', arr, plugin=plugin, **plugin_args)
>   File
> "/usr/local/lib/python2.6/dist-packages/skimage-0.4-py2.6-linux-i686.egg/skimage/io/_plugins/plugin.py",
> line 88, in call
>     return func(*args, **kwargs)
>   File
> "/usr/local/lib/python2.6/dist-packages/skimage-0.4-py2.6-linux-i686.egg/skimage/io/_plugins/pil_plugin.py",
> line 108, in imshow
>     Image.fromarray(arr).show()
>   File "/usr/lib/python2.6/dist-packages/PIL/Image.py", line 1886, in
> fromarray
>     raise TypeError("Cannot handle this data type")
> TypeError: Cannot handle this data type*
>
> Does io.imshow() support only 8bits image?
>
> I can open and display the image with readmagick/pylab.
>
> Best regards
> Jean-Patrick
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111205/c88d2d4d/attachment.html>

From jeanpatrick.pommier at gmail.com  Mon Dec  5 16:20:34 2011
From: jeanpatrick.pommier at gmail.com (jip)
Date: Mon, 5 Dec 2011 13:20:34 -0800 (PST)
Subject: io plugin issue (8bits 16bits)
In-Reply-To: <CABDkGQk9DfzzOf-g5wDA77iL9hYAR_qfrTBBqgiVJCNEj42SUg@mail.gmail.com>
References: <26552631.1394.1323091277849.JavaMail.geo-discussion-forums@yqcc19>
 <CABDkGQk9DfzzOf-g5wDA77iL9hYAR_qfrTBBqgiVJCNEj42SUg@mail.gmail.com>
Message-ID: <33523723.333.1323120034931.JavaMail.geo-discussion-forums@vbgw2>

dear St?fan,

 I joined an image with that message.
<https://docs.google.com/open?id=0B-YDFMbEy1grYTMzMGRiZDUtNzk2OC00YTAwLTk5NTItZTczZTk3YWM2ZmEz>

Le lundi 5 d?cembre 2011 20:08:36 UTC+1, Stefan van der Walt a ?crit :
>
> Hi JP
>
> Thanks for finding this issue. Would you mind placing a small 12-bit tiff 
> online somewhere so that I can use it in the test suite?
>
> It's strange that the matplotlib plugin is not available, since you 
> mention that you have pylab.  Can you import matplotlib without problems?
>
I can use pylab if the image is loaded with readmagick. I can check 
skimage.io on an other configuration.

Best regards

Jean-Patrick

>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111205/31086baa/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.tif.tar.gz
Type: application/octet-stream
Size: 1636244 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111205/31086baa/attachment.obj>

From stefan at sun.ac.za  Mon Dec  5 16:23:44 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 5 Dec 2011 13:23:44 -0800
Subject: Nowozin
In-Reply-To: <4EDCE767.8040702@ais.uni-bonn.de>
References: <4EDCE767.8040702@ais.uni-bonn.de>
Message-ID: <CABDkGQkN3w1Y2VyYKSCU29F8UDYBgpeBYH36sGYa6UY=U2YyzQ@mail.gmail.com>

Hey Andy

On Mon, Dec 5, 2011 at 7:46 AM, Andreas M?ller <amueller at ais.uni-bonn.de> wrote:
> Sorry I didn't have much time to contribute.
> Does anyone of you know this library:
> http://www.nowozin.net/sebastian/tuwo/
> It is a C++ computer vision library under MIT
> license and contains many great features.

Thanks for the pointer.  We already cover a sizable portion of their
features, but the one thing I really want to see is good graph-cut
based segmentation, as well as tri-mapping.  I was thinking of
implementing them from scratch, but if we can find an easy way of
leveraging their code, that may save a lot of time.

If anyone here has experience with graph cuts, please get in touch.

Regards
St?fan


From stefan at sun.ac.za  Mon Dec  5 16:52:39 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 5 Dec 2011 13:52:39 -0800
Subject: io plugin issue (8bits 16bits)
In-Reply-To: <33523723.333.1323120034931.JavaMail.geo-discussion-forums@vbgw2>
References: <26552631.1394.1323091277849.JavaMail.geo-discussion-forums@yqcc19>
 <CABDkGQk9DfzzOf-g5wDA77iL9hYAR_qfrTBBqgiVJCNEj42SUg@mail.gmail.com> <33523723.333.1323120034931.JavaMail.geo-discussion-forums@vbgw2>
Message-ID: <CABDkGQmHS0iu4r6sohQDDDETLyikZ6_YBLt9ybzrun-QyGOwrA@mail.gmail.com>

On Mon, Dec 5, 2011 at 1:20 PM, jip <jeanpatrick.pommier at gmail.com> wrote:
> ?I joined an image with that message.

Thanks, JP.  This allowed me to narrow down the problem.  We currently
do not have logic to support PIL Tiff objects, so they end up embedded
in an object array.

In the meantime, the matplotlib plugin does work for me:

import skimage.io as sio
sio.use_plugin('matplotlib')
img = sio.imread('1.tiff')

Cheers
St?fan


From cjgohlke at gmail.com  Mon Dec  5 17:40:28 2011
From: cjgohlke at gmail.com (Christoph Gohlke)
Date: Mon, 05 Dec 2011 14:40:28 -0800
Subject: io plugin issue (8bits 16bits)
In-Reply-To: <CABDkGQmHS0iu4r6sohQDDDETLyikZ6_YBLt9ybzrun-QyGOwrA@mail.gmail.com>
References: <26552631.1394.1323091277849.JavaMail.geo-discussion-forums@yqcc19> <CABDkGQk9DfzzOf-g5wDA77iL9hYAR_qfrTBBqgiVJCNEj42SUg@mail.gmail.com> <33523723.333.1323120034931.JavaMail.geo-discussion-forums@vbgw2> <CABDkGQmHS0iu4r6sohQDDDETLyikZ6_YBLt9ybzrun-QyGOwrA@mail.gmail.com>
Message-ID: <4EDD485C.8060302@gmail.com>

On 12/5/2011 1:52 PM, St??????fan van der Walt wrote:
> On Mon, Dec 5, 2011 at 1:20 PM, jip<jeanpatrick.pommier at gmail.com>  wrote:
>>   I joined an image with that message.
> Thanks, JP.  This allowed me to narrow down the problem.  We currently
> do not have logic to support PIL Tiff objects, so they end up embedded
> in an object array.
>
> In the meantime, the matplotlib plugin does work for me:
>
> import skimage.io as sio
> sio.use_plugin('matplotlib')
> img = sio.imread('1.tiff')
>
> Cheers
> St??????fan
>

Hello,

Matplotlib's imread uses PIL and also does not read 16 bit TIFFs 
correctly. The FreeImage, Qt, and GDAL plugins do.

With scikits-image 0.4.2, the following works correctly for me on Windows:

     import skimage.io
     skimage.io.use_plugin('freeimage')
     skimage.io.use_plugin('matplotlib')
     image = skimage.io.imread('1.tif', plugin='freeimage')
     skimage.io.imshow(image, cmap='gray')
     skimage.io.show()


skimage.io.use_plugin is somewhat broken (I think). It replaces all 
previously defined default imread, imwrite, and imshow functions, 
regardless whether a `kind` argument is provided. For example:

     skimage.io.use_plugin('freeimage', 'imread')
     skimage.io.use_plugin('matplotlib', 'imshow')

the second call replaces freeimage.imread as the default imread function 
with matplotlib.imread.

Christoph


From stefan at sun.ac.za  Mon Dec  5 19:32:43 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 5 Dec 2011 16:32:43 -0800
Subject: io plugin issue (8bits 16bits)
In-Reply-To: <4EDD485C.8060302@gmail.com>
References: <26552631.1394.1323091277849.JavaMail.geo-discussion-forums@yqcc19>
 <CABDkGQk9DfzzOf-g5wDA77iL9hYAR_qfrTBBqgiVJCNEj42SUg@mail.gmail.com>
 <33523723.333.1323120034931.JavaMail.geo-discussion-forums@vbgw2>
 <CABDkGQmHS0iu4r6sohQDDDETLyikZ6_YBLt9ybzrun-QyGOwrA@mail.gmail.com> <4EDD485C.8060302@gmail.com>
Message-ID: <CABDkGQnBHFEEKCA5bt+9FLqC05OMmOzGWnv6pRy1Reqo+esrzQ@mail.gmail.com>

On Mon, Dec 5, 2011 at 2:40 PM, Christoph Gohlke <cjgohlke at gmail.com> wrote:
> skimage.io.use_plugin is somewhat broken (I think). It replaces all
> previously defined default imread, imwrite, and imshow functions, regardless
> whether a `kind` argument is provided. For example:

Between Chris and myself, we should have this fixed tonight.  Follow along here:

https://github.com/scikits-image/scikits-image/pull/88
https://github.com/scikits-image/scikits-image/pull/90

PR90 provides a new function called "plugin_order", which allows the
user to see under the hood which function skimage will try to use.

Cheers
St?fan


From amueller at ais.uni-bonn.de  Mon Dec  5 10:46:47 2011
From: amueller at ais.uni-bonn.de (=?ISO-8859-1?Q?Andreas_M=FCller?=)
Date: Mon, 05 Dec 2011 16:46:47 +0100
Subject: Nowozin
Message-ID: <4EDCE767.8040702@ais.uni-bonn.de>

Hi everybody.
Sorry I didn't have much time to contribute.
Does anyone of you know this library:
http://www.nowozin.net/sebastian/tuwo/
It is a C++ computer vision library under MIT
license and contains many great features.

Maybe it is worth looking into.
Cheers,
Andy


From stefan at sun.ac.za  Mon Dec  5 19:51:20 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 5 Dec 2011 16:51:20 -0800
Subject: Feature requests for 0.5
Message-ID: <CABDkGQ=fsUTBZD_7KZ92d2E7nUvVBo61-eZwsQHsZ+9Sm7z8cA@mail.gmail.com>

Hi all,

With 0.4 (and 0.4.1, 0.4.2) out the door, we can start setting
priorities for 0.5.

Personally, I'd like to see

- An expansion of the user guide
- Completion of the Debian packaging
- Object convex hulls and
- Graph cut segmentation and/or tri-mapping

Feel free to weigh in with your own suggestions, then we'll come to an
agreement on the best way forward.

Regards
St?fan


From stefan at sun.ac.za  Tue Dec  6 01:40:56 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 5 Dec 2011 22:40:56 -0800
Subject: Feature requests for 0.5
In-Reply-To: <CAE-UAvSEAq_qybfW3+PdSBjuwdtJHTokFyAfmptcecgOqXNpRg@mail.gmail.com>
References: <CABDkGQ=fsUTBZD_7KZ92d2E7nUvVBo61-eZwsQHsZ+9Sm7z8cA@mail.gmail.com>
 <CAE-UAvSEAq_qybfW3+PdSBjuwdtJHTokFyAfmptcecgOqXNpRg@mail.gmail.com>
Message-ID: <CABDkGQmO0Sy1tabSswj-9L71e+2BmZ0gzqJDaSx7391X-n9_KA@mail.gmail.com>

Hi Nelle

On Mon, Dec 5, 2011 at 10:23 PM, Nelle Varoquaux
<nelle.varoquaux at gmail.com> wrote:
> I have a Harris affine region detector I'd like to integrate, and

Great, that would be a very useful addition!

> potentially a panorama stitching example using hogs and harris I'd
> like to integrate (might be slightly to complicated for the user guide
> ?). It's work in progress, but I should have time to work on that
> during the christmas holidays.

We could make this an example chapter in the user guide, since it
would illustrate a number of things.  For that, we may want to modify
the auto example generator to allow text snippets to appear between
code.  I did quite a bit of work on stitching during my phd, so I'd be
interested to help out with this, if you want.

Regards
St?fan


From yager.neil at gmail.com  Tue Dec  6 01:52:45 2011
From: yager.neil at gmail.com (Neil Yager)
Date: Mon, 5 Dec 2011 22:52:45 -0800 (PST)
Subject: io plugin issue (8bits 16bits)
In-Reply-To: <CABDkGQnBHFEEKCA5bt+9FLqC05OMmOzGWnv6pRy1Reqo+esrzQ@mail.gmail.com>
References: <26552631.1394.1323091277849.JavaMail.geo-discussion-forums@yqcc19>
 <CABDkGQk9DfzzOf-g5wDA77iL9hYAR_qfrTBBqgiVJCNEj42SUg@mail.gmail.com>
 <33523723.333.1323120034931.JavaMail.geo-discussion-forums@vbgw2>
 <CABDkGQmHS0iu4r6sohQDDDETLyikZ6_YBLt9ybzrun-QyGOwrA@mail.gmail.com>
 <4EDD485C.8060302@gmail.com> <CABDkGQnBHFEEKCA5bt+9FLqC05OMmOzGWnv6pRy1Reqo+esrzQ@mail.gmail.com>
Message-ID: <9c194b87-729a-4756-bb80-42b38f5d06af@z1g2000vbx.googlegroups.com>

Coincidentally, I also noticed the 16-bit tiff issue the other day,
and started working on a fix. I was using an approach based on this:

http://stackoverflow.com/questions/7684695/numpy-array-of-an-i16-image-file

Changing the last line of imread in pil_plugin to:

return np.array(im.getdata()).reshape(im.size[::-1])

fixes that specific problems, but causes others (e.g. can't load
colour images). At that point I got side-tracked by something else, so
I'm not sure if it's a good fix.

Neil

On Dec 6, 12:32?am, St?fan van der Walt <ste... at sun.ac.za> wrote:
> On Mon, Dec 5, 2011 at 2:40 PM, Christoph Gohlke <cjgoh... at gmail.com> wrote:
> > skimage.io.use_plugin is somewhat broken (I think). It replaces all
> > previously defined default imread, imwrite, and imshow functions, regardless
> > whether a `kind` argument is provided. For example:
>
> Between Chris and myself, we should have this fixed tonight. ?Follow along here:
>
> https://github.com/scikits-image/scikits-image/pull/88https://github.com/scikits-image/scikits-image/pull/90
>
> PR90 provides a new function called "plugin_order", which allows the
> user to see under the hood which function skimage will try to use.
>
> Cheers
> St?fan


From stefan at sun.ac.za  Tue Dec  6 04:28:34 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 6 Dec 2011 01:28:34 -0800
Subject: installation -- error on the download webpage
In-Reply-To: <20111206090538.GA4072@phare.normalesup.org>
References: <20111206090538.GA4072@phare.normalesup.org>
Message-ID: <CABDkGQnKuv1Tp_i9EHkJep0zjqYSUf=Prg61yfcSf=d0F8mVhw@mail.gmail.com>

On Tue, Dec 6, 2011 at 1:05 AM, Emmanuelle Gouillart
<emmanuelle.gouillart at nsup.org> wrote:
> ? ? ? ?in the download webpage http://scikits-image.org/download.html,
> the PyPi link points to http://pypi.python.org/pypi/scikits.image (this
> produces an error), whereas it should be

Woops, my mistake--fixed!

St?fan


From stefan at sun.ac.za  Tue Dec  6 04:30:49 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 6 Dec 2011 01:30:49 -0800
Subject: installation -- error on the download webpage
In-Reply-To: <20111206090538.GA4072@phare.normalesup.org>
References: <20111206090538.GA4072@phare.normalesup.org>
Message-ID: <CABDkGQkQfY2DQGxS82_9o6jRiapJEKs0tHE1kSvzq+ygPWaixw@mail.gmail.com>

On Tue, Dec 6, 2011 at 1:05 AM, Emmanuelle Gouillart
<emmanuelle.gouillart at nsup.org> wrote:
> ? ? ? ?in the download webpage http://scikits-image.org/download.html,
> the PyPi link points to http://pypi.python.org/pypi/scikits.image (this
> produces an error), whereas it should be
> http://pypi.python.org/pypi/scikits-image I'll try to correct this but I
> first have to understand how this webpage is generated, so if anybody is
> quicker than me, it'd be good to correct this ASAP.

For future reference:

To start, clone git at github.com:scikits-image/scikits-image-web.git

1. Make the changes necessary.
2. "make html" and check that the build/html output looks ok.
3. "make gh-pages"
4. If all looks ok, "cd gh-pages ; git commit"

St?fan


From stefan at sun.ac.za  Tue Dec  6 04:39:31 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 6 Dec 2011 01:39:31 -0800
Subject: io plugin issue (8bits 16bits)
In-Reply-To: <9c194b87-729a-4756-bb80-42b38f5d06af@z1g2000vbx.googlegroups.com>
References: <26552631.1394.1323091277849.JavaMail.geo-discussion-forums@yqcc19>
 <CABDkGQk9DfzzOf-g5wDA77iL9hYAR_qfrTBBqgiVJCNEj42SUg@mail.gmail.com>
 <33523723.333.1323120034931.JavaMail.geo-discussion-forums@vbgw2>
 <CABDkGQmHS0iu4r6sohQDDDETLyikZ6_YBLt9ybzrun-QyGOwrA@mail.gmail.com>
 <4EDD485C.8060302@gmail.com> <CABDkGQnBHFEEKCA5bt+9FLqC05OMmOzGWnv6pRy1Reqo+esrzQ@mail.gmail.com>
 <9c194b87-729a-4756-bb80-42b38f5d06af@z1g2000vbx.googlegroups.com>
Message-ID: <CABDkGQnyOFfSPd=UM4oPmJoHH3SOf-Qgj=-2x8VSPHepn=T8zQ@mail.gmail.com>

Hi Neil

On Mon, Dec 5, 2011 at 10:52 PM, Neil Yager <yager.neil at gmail.com> wrote:
> Coincidentally, I also noticed the 16-bit tiff issue the other day,
> and started working on a fix.

Can you check the fixes we committed, and make sure they do the trick?

To display the images properly, you'll also need

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

I'll commit that as soon as it has been reviewed by at least one other person.

Thanks
St?fan


From nelle.varoquaux at gmail.com  Tue Dec  6 01:23:08 2011
From: nelle.varoquaux at gmail.com (Nelle Varoquaux)
Date: Tue, 6 Dec 2011 07:23:08 +0100
Subject: Feature requests for 0.5
In-Reply-To: <CABDkGQ=fsUTBZD_7KZ92d2E7nUvVBo61-eZwsQHsZ+9Sm7z8cA@mail.gmail.com>
References: <CABDkGQ=fsUTBZD_7KZ92d2E7nUvVBo61-eZwsQHsZ+9Sm7z8cA@mail.gmail.com>
Message-ID: <CAE-UAvSEAq_qybfW3+PdSBjuwdtJHTokFyAfmptcecgOqXNpRg@mail.gmail.com>

Hi St?fan,

I have a Harris affine region detector I'd like to integrate, and
potentially a panorama stitching example using hogs and harris I'd
like to integrate (might be slightly to complicated for the user guide
?). It's work in progress, but I should have time to work on that
during the christmas holidays.

Cheers,
Nelle

2011/12/6 St?fan van der Walt <stefan at sun.ac.za>:
> Hi all,
>
> With 0.4 (and 0.4.1, 0.4.2) out the door, we can start setting
> priorities for 0.5.
>
> Personally, I'd like to see
>
> - An expansion of the user guide
> - Completion of the Debian packaging
> - Object convex hulls and
> - Graph cut segmentation and/or tri-mapping
>
> Feel free to weigh in with your own suggestions, then we'll come to an
> agreement on the best way forward.
>
> Regards
> St?fan


From yager.neil at gmail.com  Tue Dec  6 11:32:39 2011
From: yager.neil at gmail.com (Neil Yager)
Date: Tue, 6 Dec 2011 08:32:39 -0800 (PST)
Subject: io plugin issue (8bits 16bits)
In-Reply-To: <CABDkGQnyOFfSPd=UM4oPmJoHH3SOf-Qgj=-2x8VSPHepn=T8zQ@mail.gmail.com>
References: <26552631.1394.1323091277849.JavaMail.geo-discussion-forums@yqcc19>
 <CABDkGQk9DfzzOf-g5wDA77iL9hYAR_qfrTBBqgiVJCNEj42SUg@mail.gmail.com>
 <33523723.333.1323120034931.JavaMail.geo-discussion-forums@vbgw2>
 <CABDkGQmHS0iu4r6sohQDDDETLyikZ6_YBLt9ybzrun-QyGOwrA@mail.gmail.com>
 <4EDD485C.8060302@gmail.com> <CABDkGQnBHFEEKCA5bt+9FLqC05OMmOzGWnv6pRy1Reqo+esrzQ@mail.gmail.com>
 <9c194b87-729a-4756-bb80-42b38f5d06af@z1g2000vbx.googlegroups.com> <CABDkGQnyOFfSPd=UM4oPmJoHH3SOf-Qgj=-2x8VSPHepn=T8zQ@mail.gmail.com>
Message-ID: <8d7c347a-363b-476b-a1f6-730a65e3c716@gl2g2000vbb.googlegroups.com>

> I'll commit that as soon as it has been reviewed by at least one other person.

I just pulled 88, 90 and 91, and everything works for me.

Neli


From thouis at gmail.com  Tue Dec  6 04:04:17 2011
From: thouis at gmail.com (Thouis (Ray) Jones)
Date: Tue, 6 Dec 2011 10:04:17 +0100
Subject: io plugin issue (8bits 16bits)
In-Reply-To: <9c194b87-729a-4756-bb80-42b38f5d06af@z1g2000vbx.googlegroups.com>
References: <26552631.1394.1323091277849.JavaMail.geo-discussion-forums@yqcc19>
 <CABDkGQk9DfzzOf-g5wDA77iL9hYAR_qfrTBBqgiVJCNEj42SUg@mail.gmail.com>
 <33523723.333.1323120034931.JavaMail.geo-discussion-forums@vbgw2>
 <CABDkGQmHS0iu4r6sohQDDDETLyikZ6_YBLt9ybzrun-QyGOwrA@mail.gmail.com>
 <4EDD485C.8060302@gmail.com> <CABDkGQnBHFEEKCA5bt+9FLqC05OMmOzGWnv6pRy1Reqo+esrzQ@mail.gmail.com>
 <9c194b87-729a-4756-bb80-42b38f5d06af@z1g2000vbx.googlegroups.com>
Message-ID: <CAHGWWxEZqYBXYf6DH8kA09T=Z7aWjezN+scBYePtr1fjkkM5XQ@mail.gmail.com>

On Tue, Dec 6, 2011 at 07:52, Neil Yager <yager.neil at gmail.com> wrote:
> Coincidentally, I also noticed the 16-bit tiff issue the other day,
> and started working on a fix. I was using an approach based on this:
>
> http://stackoverflow.com/questions/7684695/numpy-array-of-an-i16-image-file
>
> Changing the last line of imread in pil_plugin to:
>
> return np.array(im.getdata()).reshape(im.size[::-1])
>
> fixes that specific problems, but causes others (e.g. can't load
> colour images). At that point I got side-tracked by something else, so
> I'm not sure if it's a good fix.

The CellProfiler project used to use PIL, though we've moved to
bioformats.  The (potentially) stale code for dealing with TIF and
other images is here:
https://raw.github.com/thouis/CellProfiler/master/cellprofiler/modules/loadimages.py
(search  for load_using_PIL).

For color images, we end up using matplotlib.image.pil_to_array(),
located in this file:
https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/image.py

As I said, our code is potentially stale, and some parts may not be
needed or even functional.  But it has had the benefit of having been
tested on a fairly wide variety of formats.  If you're looking for
potentially problematic images, you might snoop around our the
CellProfiler examples:
https://svn.broadinstitute.org/CellProfiler/trunk/ExampleImages/

Ray Jones


From emmanuelle.gouillart at nsup.org  Tue Dec  6 04:05:38 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Tue, 6 Dec 2011 10:05:38 +0100
Subject: installation -- error on the download webpage
Message-ID: <20111206090538.GA4072@phare.normalesup.org>

	Hi all,

	in the download webpage http://scikits-image.org/download.html,
the PyPi link points to http://pypi.python.org/pypi/scikits.image (this
produces an error), whereas it should be
http://pypi.python.org/pypi/scikits-image I'll try to correct this but I
first have to understand how this webpage is generated, so if anybody is
quicker than me, it'd be good to correct this ASAP.

	Emmanuelle



From emmanuelle.gouillart at nsup.org  Tue Dec  6 04:36:09 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Tue, 6 Dec 2011 10:36:09 +0100
Subject: installation -- error on the download webpage
In-Reply-To: <CABDkGQkQfY2DQGxS82_9o6jRiapJEKs0tHE1kSvzq+ygPWaixw@mail.gmail.com>
References: <20111206090538.GA4072@phare.normalesup.org>
 <CABDkGQkQfY2DQGxS82_9o6jRiapJEKs0tHE1kSvzq+ygPWaixw@mail.gmail.com>
Message-ID: <20111206093609.GB4072@phare.normalesup.org>


> For future reference:

> To start, clone git at github.com:scikits-image/scikits-image-web.git

> 1. Make the changes necessary.
> 2. "make html" and check that the build/html output looks ok.
> 3. "make gh-pages"
> 4. If all looks ok, "cd gh-pages ; git commit"

Thanks, this will be useful!
Emmanuelle


From stefan at sun.ac.za  Tue Dec  6 19:19:18 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 6 Dec 2011 16:19:18 -0800
Subject: The asymmetry of licensing
Message-ID: <CABDkGQk+jBu8sXATo7R0MhfW2mtBPw9RvQMX=zqiyLPn1BGz2Q@mail.gmail.com>

Hi all,

Here's a link to a (potentially controversial) post I made on Google Plus:

https://plus.google.com/104831275312843762750/posts/fcdAoLarutu

Basically, it briefly touches on why we are using BSD and not GPL.
Your comments are welcome.

Regards
St?fan


From yager.neil at gmail.com  Wed Dec  7 12:37:22 2011
From: yager.neil at gmail.com (Neil Yager)
Date: Wed, 7 Dec 2011 09:37:22 -0800 (PST)
Subject: Feature requests for 0.5
In-Reply-To: <CAEym_HoOa4Xu=TcVbXm_mYrQuXr_XAdWCNwFEqAXQ3FcAb7-aQ@mail.gmail.com>
References: <CABDkGQ=fsUTBZD_7KZ92d2E7nUvVBo61-eZwsQHsZ+9Sm7z8cA@mail.gmail.com>
 <CAE-UAvSEAq_qybfW3+PdSBjuwdtJHTokFyAfmptcecgOqXNpRg@mail.gmail.com>
 <CABDkGQmO0Sy1tabSswj-9L71e+2BmZ0gzqJDaSx7391X-n9_KA@mail.gmail.com> <CAEym_HoOa4Xu=TcVbXm_mYrQuXr_XAdWCNwFEqAXQ3FcAb7-aQ@mail.gmail.com>
Message-ID: <7366c3a4-2421-40be-bbfa-4e6a32dbf664@z17g2000vbe.googlegroups.com>

> * Automatic threshold algorithms. I started to integrate some code from
> CellProfiler, but I got bogged down with some of the details. I can give it
> another go, unless someone else wants to do it.

I agree that thresholding should be a priority, as it is widely used.
I also started to look at the CellProfiler. It has a lot of
functionality, but even a subset of this would be a good start.
Unfortunately I don't think I'll have much time for this in the next
few weeks.

Another useful method would be histogram equalization. Here's a nice
implementation:

http://www.janeriksolem.net/2009/06/histogram-equalization-with-python-and.html

but we'd have to contact the author about using it.

Neil


From tsyu80 at gmail.com  Wed Dec  7 11:52:09 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Wed, 7 Dec 2011 11:52:09 -0500
Subject: Feature requests for 0.5
In-Reply-To: <CABDkGQmO0Sy1tabSswj-9L71e+2BmZ0gzqJDaSx7391X-n9_KA@mail.gmail.com>
References: <CABDkGQ=fsUTBZD_7KZ92d2E7nUvVBo61-eZwsQHsZ+9Sm7z8cA@mail.gmail.com>
	<CAE-UAvSEAq_qybfW3+PdSBjuwdtJHTokFyAfmptcecgOqXNpRg@mail.gmail.com>
	<CABDkGQmO0Sy1tabSswj-9L71e+2BmZ0gzqJDaSx7391X-n9_KA@mail.gmail.com>
Message-ID: <CAEym_HoOa4Xu=TcVbXm_mYrQuXr_XAdWCNwFEqAXQ3FcAb7-aQ@mail.gmail.com>

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

> Hi Nelle
>
> On Mon, Dec 5, 2011 at 10:23 PM, Nelle Varoquaux
> <nelle.varoquaux at gmail.com> wrote:
> > I have a Harris affine region detector I'd like to integrate, and
>
> Great, that would be a very useful addition!
>
> > potentially a panorama stitching example using hogs and harris I'd
> > like to integrate (might be slightly to complicated for the user guide
> > ?). It's work in progress, but I should have time to work on that
> > during the christmas holidays.
>
> We could make this an example chapter in the user guide, since it
> would illustrate a number of things.  For that, we may want to modify
> the auto example generator to allow text snippets to appear between
> code.  I did quite a bit of work on stitching during my phd, so I'd be
> interested to help out with this, if you want.
>
> Regards
> St?fan
>

A stitching/image-registration example would be great.

Other wish-list items:

* A while back, I mentioned the possibility of automatically importing some
submodules (but leaving them in their own namespace). For example, I'd vote
for automatic import of the io module. If we can agree on which submodules
(if any), I could throw together a pull request.

* Automatic threshold algorithms. I started to integrate some code from
CellProfiler, but I got bogged down with some of the details. I can give it
another go, unless someone else wants to do it.

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

From anders.c.klint at gmail.com  Wed Dec  7 17:41:14 2011
From: anders.c.klint at gmail.com (Anders Klint)
Date: Wed, 7 Dec 2011 23:41:14 +0100
Subject: Feature requests for 0.5
In-Reply-To: <CABDkGQ=fsUTBZD_7KZ92d2E7nUvVBo61-eZwsQHsZ+9Sm7z8cA@mail.gmail.com>
References: <CABDkGQ=fsUTBZD_7KZ92d2E7nUvVBo61-eZwsQHsZ+9Sm7z8cA@mail.gmail.com>
Message-ID: <ECDB5231-F5A2-4D68-8AB7-A33C4293FC45@gmail.com>

Hi,

More of a question than a request:
Rather long ago I used an image analysis tool called Image Pro which had a rather large set
of measurements that could be applied to identified objects. So a possible scenario there could
be something like:
* Grab image
* Segment objects from background
* Measure objects
* Filter out only objects with a size between 1.5 and 3.3 mm^2 (or relevant pixel measurement)
 and a roundness (defined in terms of length of object's periphery vs periphery of a circle with same area)
 over 0.85
* ...and further processing on matching objects

Other measurements included for example major and minor axis direction and length, average greyscale
value etc etc

Could something like this, ie a more comprehensive set of measurements be valuable for skimage users?

Regards
/Anders

On 6 dec 2011, at 01:51, St?fan van der Walt wrote:

> Hi all,
> 
> With 0.4 (and 0.4.1, 0.4.2) out the door, we can start setting
> priorities for 0.5.
> 
> Personally, I'd like to see
> 
> - An expansion of the user guide
> - Completion of the Debian packaging
> - Object convex hulls and
> - Graph cut segmentation and/or tri-mapping
> 
> Feel free to weigh in with your own suggestions, then we'll come to an
> agreement on the best way forward.
> 
> Regards
> St?fan



From stefan at sun.ac.za  Thu Dec  8 04:21:43 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 8 Dec 2011 01:21:43 -0800
Subject: Feature requests for 0.5
In-Reply-To: <CAEym_HoOa4Xu=TcVbXm_mYrQuXr_XAdWCNwFEqAXQ3FcAb7-aQ@mail.gmail.com>
References: <CABDkGQ=fsUTBZD_7KZ92d2E7nUvVBo61-eZwsQHsZ+9Sm7z8cA@mail.gmail.com>
 <CAE-UAvSEAq_qybfW3+PdSBjuwdtJHTokFyAfmptcecgOqXNpRg@mail.gmail.com>
 <CABDkGQmO0Sy1tabSswj-9L71e+2BmZ0gzqJDaSx7391X-n9_KA@mail.gmail.com> <CAEym_HoOa4Xu=TcVbXm_mYrQuXr_XAdWCNwFEqAXQ3FcAb7-aQ@mail.gmail.com>
Message-ID: <CABDkGQmNtC5h_E8jiEPsehRmFMnpCd1YdHKkPhBUc1MV8QLZPw@mail.gmail.com>

Hi Tony

On Wed, Dec 7, 2011 at 8:52 AM, Tony Yu <tsyu80 at gmail.com> wrote:
> * A while back, I mentioned the possibility of automatically importing some
> submodules (but leaving them in their own namespace). For example, I'd vote
> for automatic import of the io module. If we can agree on which submodules
> (if any), I could throw together a pull request.

This was the original model for NumPy and SciPy, but whenever redesign
comes up this is mentioned, and I think those projects would
eventually like to step away from it.  The important thing to improve
may be the root docstring for skimage, so that you can inspect that to
know what is available below.

> * Automatic threshold algorithms. I started to integrate some code from
> CellProfiler, but I got bogged down with some of the details. I can give it
> another go, unless someone else wants to do it.

We could maybe start with an implementation of Otsu's method, which is
really simple:

http://en.wikipedia.org/wiki/Otsu's_method

Regards
St?fan


From stefan at sun.ac.za  Thu Dec  8 04:27:10 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 8 Dec 2011 01:27:10 -0800
Subject: Feature requests for 0.5
In-Reply-To: <ECDB5231-F5A2-4D68-8AB7-A33C4293FC45@gmail.com>
References: <CABDkGQ=fsUTBZD_7KZ92d2E7nUvVBo61-eZwsQHsZ+9Sm7z8cA@mail.gmail.com>
 <ECDB5231-F5A2-4D68-8AB7-A33C4293FC45@gmail.com>
Message-ID: <CABDkGQndqKKh7B9Yvuy=A4_PWHeH=hpORivA4VEOj7YR+5XAsw@mail.gmail.com>

Hi Anders

On Wed, Dec 7, 2011 at 2:41 PM, Anders Klint <anders.c.klint at gmail.com> wrote:
> Rather long ago I used an image analysis tool called Image Pro which had a rather large set
> of measurements that could be applied to identified objects. So a possible scenario there could
> be something like:
> * Grab image
> * Segment objects from background
> * Measure objects
> * Filter out only objects with a size between 1.5 and 3.3 mm^2 (or relevant pixel measurement)
> ?and a roundness (defined in terms of length of object's periphery vs periphery of a circle with same area)
> ?over 0.85
> * ...and further processing on matching objects

This process is very much like the one described in my EuroScipy
tutorial (http://mentat.za.net/euroscipy2011/intro_notes.tar.gz) and
the User Guide tutorial Emmanuelle submitted as a pull request today
(https://github.com/scikits-image/scikits-image/pull/93).  That
details the basic process.

As for the different measures, I think we could benefit from having
some of those grouped together.  Things like getting the area (after
labelling is trivial), but computing circularity etc. can get more
interesting.  Do you know of a good list of such desired measurements?
 Maybe also have a look at the MATLAB docs online to see what they
provide as a point of reference.

Regards
St?fan


From stefan at sun.ac.za  Thu Dec  8 04:31:46 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 8 Dec 2011 01:31:46 -0800
Subject: Feature requests for 0.5
In-Reply-To: <20111208051016.GB30211@phare.normalesup.org>
References: <CABDkGQ=fsUTBZD_7KZ92d2E7nUvVBo61-eZwsQHsZ+9Sm7z8cA@mail.gmail.com>
 <20111208051016.GB30211@phare.normalesup.org>
Message-ID: <CABDkGQ==0Q72rMs52p0Qv1r2zAx0wRD4y5EG4KQh8fYuMgaOTg@mail.gmail.com>

On Wed, Dec 7, 2011 at 9:10 PM, Emmanuelle Gouillart
<emmanuelle.gouillart at nsup.org> wrote:
> Regarding graph-cut segmentation, it's not exactly graph-cut, but I have
> some code (purely Python) implementing the random walker segmentation
> algorithm
> (http://cns.bu.edu/~lgrady/Random_Walker_Image_Segmentation.html). It's a
> very nice algorithm that overcomes some of the limitations of the
> watershed, and it can label more than two phases. So I could clean up
> this code a bit for skimage, I guess this could be my contribution to 0.5

Thanks for the link; I haven't seen this method before.  Does it
vectorize fairly well?  I wonder, if we start doing seeded
segmentation, whether it might be worth building a Qt or Matplotlib
GUI along with it.  I have other uses for a "Paint" component too,
such as modifying the FFT spectrum and watching the changes in place
(wouldn't FFT painting be fun? :).

This is turning into a very informative thread; we must remember to
update the todo list accordingly.

Cheers
St?fan


From kmichael.aye at gmail.com  Thu Dec  8 08:43:33 2011
From: kmichael.aye at gmail.com (Michael Aye)
Date: Thu, 8 Dec 2011 05:43:33 -0800 (PST)
Subject: scikits-image 0.4 release
In-Reply-To: <CABDkGQkUJY-sH-R=wGH1KTu64kfG2e-4o7hxDqwTftGfZn19RQ@mail.gmail.com>
References: <CABDkGQkUJY-sH-R=wGH1KTu64kfG2e-4o7hxDqwTftGfZn19RQ@mail.gmail.com>
Message-ID: <1a5dd325-2359-4d44-bf5e-cf1f841c64a3@n10g2000vbg.googlegroups.com>

>
> Please visit our examples gallery to see what we've been up to:
>
> ? ?http://scikits-image.org/docs/0.3/auto_examples/
>
This should be http://scikits-image.org/docs/0.4/auto_examples/
,right?

Michael


From emmanuelle.gouillart at nsup.org  Thu Dec  8 00:10:16 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Thu, 8 Dec 2011 06:10:16 +0100
Subject: Feature requests for 0.5
In-Reply-To: <CABDkGQ=fsUTBZD_7KZ92d2E7nUvVBo61-eZwsQHsZ+9Sm7z8cA@mail.gmail.com>
References: <CABDkGQ=fsUTBZD_7KZ92d2E7nUvVBo61-eZwsQHsZ+9Sm7z8cA@mail.gmail.com>
Message-ID: <20111208051016.GB30211@phare.normalesup.org>


> - An expansion of the user guide
> - Completion of the Debian packaging
> - Object convex hulls and
> - Graph cut segmentation and/or tri-mapping

Regarding graph-cut segmentation, it's not exactly graph-cut, but I have
some code (purely Python) implementing the random walker segmentation
algorithm
(http://cns.bu.edu/~lgrady/Random_Walker_Image_Segmentation.html). It's a
very nice algorithm that overcomes some of the limitations of the
watershed, and it can label more than two phases. So I could clean up
this code a bit for skimage, I guess this could be my contribution to 0.5

Emmanuelle


From jeanpatrick.pommier at gmail.com  Thu Dec  8 09:17:02 2011
From: jeanpatrick.pommier at gmail.com (jip)
Date: Thu, 8 Dec 2011 06:17:02 -0800 (PST)
Subject: io plugin issue (8bits 16bits)
In-Reply-To: <26552631.1394.1323091277849.JavaMail.geo-discussion-forums@yqcc19>
References: <26552631.1394.1323091277849.JavaMail.geo-discussion-forums@yqcc19>
Message-ID: <4538990.458.1323353822216.JavaMail.geo-discussion-forums@vbmr10>

Hi,
I compared skimage.io on an other ubuntu box (10.10), with 
readmagick//mahotas for 8 bits and 12 bits images.
The script and the image are joined.
As you can see, displaying a 16 bits image yield a saturated image and the 
orientation is mirrored.
When a 8 bit png image is loaded the three libs (sio, readmagick mahotas), 
no difference can be seen.

Should I use a github version to fix that issue?
Thanks

JP

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111208/17f7406d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: opendisplay.py
Type: text/x-python
Size: 1648 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111208/17f7406d/attachment.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imdisplayTest12bits_8bits.png
Type: image/png
Size: 119671 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111208/17f7406d/attachment.png>

From thouis.jones at curie.fr  Thu Dec  8 05:17:03 2011
From: thouis.jones at curie.fr (Thouis Jones)
Date: Thu, 8 Dec 2011 11:17:03 +0100
Subject: Feature requests for 0.5
In-Reply-To: <CABDkGQndqKKh7B9Yvuy=A4_PWHeH=hpORivA4VEOj7YR+5XAsw@mail.gmail.com>
References: <CABDkGQ=fsUTBZD_7KZ92d2E7nUvVBo61-eZwsQHsZ+9Sm7z8cA@mail.gmail.com>
 <ECDB5231-F5A2-4D68-8AB7-A33C4293FC45@gmail.com> <CABDkGQndqKKh7B9Yvuy=A4_PWHeH=hpORivA4VEOj7YR+5XAsw@mail.gmail.com>
Message-ID: <CAHGWWxHmU+rfGcRr-82s82vCAtixbEeXDm7u-msZw4-abHPH-g@mail.gmail.com>

2011/12/8 St?fan van der Walt <stefan at sun.ac.za>:
> As for the different measures, I think we could benefit from having
> some of those grouped together. ?Things like getting the area (after
> labelling is trivial), but computing circularity etc. can get more
> interesting. ?Do you know of a good list of such desired measurements?
> ?Maybe also have a look at the MATLAB docs online to see what they
> provide as a point of reference.

>From the bio corner of the world, I would suggest nearly everything here:
http://murphylab.cbi.cmu.edu/services/SLF/
Specific papers:
http://murphylab.web.cmu.edu/publications/81-boland2001.pdf
http://murphylab.web.cmu.edu/publications/87-murphy2002.pdf
http://murphylab.cbi.cmu.edu/services/SLF/
Also see the table at the end of:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.33.9697

These are all for cells, but many of the features are generally useful, I think.

Ray


From emmanuelle.gouillart at nsup.org  Thu Dec  8 09:44:16 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Thu, 8 Dec 2011 15:44:16 +0100
Subject: Feature requests for 0.5
In-Reply-To: <CABDkGQ==0Q72rMs52p0Qv1r2zAx0wRD4y5EG4KQh8fYuMgaOTg@mail.gmail.com>
References: <CABDkGQ=fsUTBZD_7KZ92d2E7nUvVBo61-eZwsQHsZ+9Sm7z8cA@mail.gmail.com>
 <20111208051016.GB30211@phare.normalesup.org>
 <CABDkGQ==0Q72rMs52p0Qv1r2zAx0wRD4y5EG4KQh8fYuMgaOTg@mail.gmail.com>
Message-ID: <20111208144416.GA25555@phare.normalesup.org>

On Thu, Dec 08, 2011 at 01:31:46AM -0800, St??????fan van der Walt wrote:
> On Wed, Dec 7, 2011 at 9:10 PM, Emmanuelle Gouillart
> <emmanuelle.gouillart at nsup.org> wrote:
> > Regarding graph-cut segmentation, it's not exactly graph-cut, but I have
> > some code (purely Python) implementing the random walker segmentation
> > algorithm
> > (http://cns.bu.edu/~lgrady/Random_Walker_Image_Segmentation.html). It's a
> > very nice algorithm that overcomes some of the limitations of the
> > watershed, and it can label more than two phases. So I could clean up
> > this code a bit for skimage, I guess this could be my contribution to 0.5

> Thanks for the link; I haven't seen this method before.  Does it
> vectorize fairly well?  

The implementation that I use is based on solving a large sparse linear
system, so there is no for loop or anything like this. Does this answer
your question?

> I wonder, if we start doing seeded segmentation, whether it might be
> worth building a Qt or Matplotlib GUI along with it.  I have other uses
> for a "Paint" component too, such as modifying the FFT spectrum and
> watching the changes in place (wouldn't FFT painting be fun? :).

I've got mixed feelings about this. Having some interactive GUIs for
adjusting parameters like for thresholding, or Canny filtering, would be
great and save a lot of time. Sometimes I get quite frustrated when
typing several commands in Ipython to test different parameters, whereas
the algorithm is actually fast enough so that I could just move a handle
and see the result. I asked Eric Jones during Scipy India if he could
make a small example using traitsUI for interactive thresholding.

The question is: should these interfaces go in skimage or elsewhere? If
yes, we would have to make sure that this does not introduce additional
dependencies (only optional ones). I think it's very important that
skimage stays a toolkit, and a package that it is easy to depend on for
other projects.

Cheers,

Emmanuelle


From stefan at sun.ac.za  Thu Dec  8 19:10:56 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 8 Dec 2011 16:10:56 -0800
Subject: scikits-image 0.4 release
In-Reply-To: <1a5dd325-2359-4d44-bf5e-cf1f841c64a3@n10g2000vbg.googlegroups.com>
References: <CABDkGQkUJY-sH-R=wGH1KTu64kfG2e-4o7hxDqwTftGfZn19RQ@mail.gmail.com>
 <1a5dd325-2359-4d44-bf5e-cf1f841c64a3@n10g2000vbg.googlegroups.com>
Message-ID: <CABDkGQ=XatBrAS1F8sgd0pQcZJyzQq8+bmmJm7yzWWCRz8-1Vw@mail.gmail.com>

On Thu, Dec 8, 2011 at 5:43 AM, Michael Aye <kmichael.aye at gmail.com> wrote:
>>
>> Please visit our examples gallery to see what we've been up to:
>>
>> ? ?http://scikits-image.org/docs/0.3/auto_examples/
>>
> This should be http://scikits-image.org/docs/0.4/auto_examples/
> ,right?

Ouch, well, that's embarrassing!  I've sent updates to the scipy list.

Thanks!
St?fan


From stefan at sun.ac.za  Thu Dec  8 21:59:26 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 8 Dec 2011 18:59:26 -0800
Subject: Feature requests for 0.5
In-Reply-To: <20111208144416.GA25555@phare.normalesup.org>
References: <CABDkGQ=fsUTBZD_7KZ92d2E7nUvVBo61-eZwsQHsZ+9Sm7z8cA@mail.gmail.com>
 <20111208051016.GB30211@phare.normalesup.org> <CABDkGQ==0Q72rMs52p0Qv1r2zAx0wRD4y5EG4KQh8fYuMgaOTg@mail.gmail.com>
 <20111208144416.GA25555@phare.normalesup.org>
Message-ID: <CABDkGQ=Qa-rS1uEv1S9fidwTpOPi=O27p2kG0SnT0Kbkgj9fRg@mail.gmail.com>

On Thu, Dec 8, 2011 at 6:44 AM, Emmanuelle Gouillart
<emmanuelle.gouillart at nsup.org> wrote:
>> Thanks for the link; I haven't seen this method before. ?Does it
>> vectorize fairly well?
>
> The implementation that I use is based on solving a large sparse linear
> system, so there is no for loop or anything like this. Does this answer
> your question?

Yes, thank you.

>> I wonder, if we start doing seeded segmentation, whether it might be
>> worth building a Qt or Matplotlib GUI along with it. ?I have other uses
>> for a "Paint" component too, such as modifying the FFT spectrum and
>> watching the changes in place (wouldn't FFT painting be fun? :).
>
> I've got mixed feelings about this. Having some interactive GUIs for
> adjusting parameters like for thresholding, or Canny filtering, would be
> great and save a lot of time. Sometimes I get quite frustrated when
> typing several commands in Ipython to test different parameters, whereas
> the algorithm is actually fast enough so that I could just move a handle
> and see the result. I asked Eric Jones during Scipy India if he could
> make a small example using traitsUI for interactive thresholding.

We need a generic version of something like

http://dip.sun.ac.za/~stefan/dpt/

That one was built with traits, but we can probably hack up something
in Qt without too much trouble.

> The question is: should these interfaces go in skimage or elsewhere? If
> yes, we would have to make sure that this does not introduce additional
> dependencies (only optional ones). I think it's very important that
> skimage stays a toolkit, and a package that it is easy to depend on for
> other projects.

There's no doubt about that.  These will always be add-on utilities,
never requirements!

Regards
St?fan


From stefan at sun.ac.za  Thu Dec  8 22:18:32 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 8 Dec 2011 19:18:32 -0800
Subject: Feature requests for 0.5
In-Reply-To: <CAHGWWxHmU+rfGcRr-82s82vCAtixbEeXDm7u-msZw4-abHPH-g@mail.gmail.com>
References: <CABDkGQ=fsUTBZD_7KZ92d2E7nUvVBo61-eZwsQHsZ+9Sm7z8cA@mail.gmail.com>
 <ECDB5231-F5A2-4D68-8AB7-A33C4293FC45@gmail.com> <CABDkGQndqKKh7B9Yvuy=A4_PWHeH=hpORivA4VEOj7YR+5XAsw@mail.gmail.com>
 <CAHGWWxHmU+rfGcRr-82s82vCAtixbEeXDm7u-msZw4-abHPH-g@mail.gmail.com>
Message-ID: <CABDkGQm5hr1pkQhxOif3AdjEKd-f2WFzdvQdprN5BdXwm4i4Lw@mail.gmail.com>

On Thu, Dec 8, 2011 at 2:17 AM, Thouis Jones <thouis.jones at curie.fr> wrote:
> From the bio corner of the world, I would suggest nearly everything here:
> http://murphylab.cbi.cmu.edu/services/SLF/

Thanks, Ray.  For my own future reference, here's the actual list:

http://murphylab.web.cmu.edu/services/SLF/features.html

Luckily, many of these are easy to compute once the object has been
isolated (a one or two-liner) in NumPy.  So we just have to define a
standard API to calculate features, something like:

feature(values, positions)

Around that, we can then build an additional layer that handles them
per labeled object, e.g.

each(feature, labeled_image)

We'll probably borrow heavily from cpmath where we can.  Since you
have a lot of experience with this stuff, your feedback is appreciated
(because, in the end, it would be great if you guys could actually use
these tools!).

Cheers
St?fan


From jeanpatrick.pommier at gmail.com  Fri Dec  9 05:47:25 2011
From: jeanpatrick.pommier at gmail.com (jip)
Date: Fri, 9 Dec 2011 02:47:25 -0800 (PST)
Subject: 12 bits tif image issue with skimage 0.5dev
Message-ID: <30282296.720.1323427645424.JavaMail.geo-discussion-forums@vbbeq1>

Dear all,
I update skimage to 0.5 dev on my ubuntu box. ipython startup gives:
Imported NumPy 1.3.0, SciPy 0.7.2, Matplotlib 0.99.3 + guidata 1.2.5, 
guiqwt 2.0.8.1
Type "scientific" for more details.
>>> import skimage
>>> skimage.version
<module 'skimage.version' from 
'/usr/local/lib/python2.6/dist-packages/scikits_image-0.5dev-py2.6-linux-i686.egg/skimage/version.pyc'>

A 12 bits tif image when loaded with skimage do not behave like the same 
image loaded with an other library (readmagick, mahotas), as shown above. 
When a 8 bits png image is loaded, the differences (orientation, 
saturation) vanish.

In a previous message Neil Yager said that the issue was fixed<https://groups.google.com/forum/#%21topic/scikits-image/JSvqMzOgTEE>. 
What should I do to fix the problem on my machine?
Thank you.

Jean-Patrick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111209/501cbfd5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imdisplayTest12bits_8bits-skimage0.5dev.png
Type: image/png
Size: 122647 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111209/501cbfd5/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: opendisplay.py
Type: text/x-python
Size: 1648 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111209/501cbfd5/attachment.py>

From cjgohlke at gmail.com  Fri Dec  9 11:12:54 2011
From: cjgohlke at gmail.com (Christoph Gohlke)
Date: Fri, 09 Dec 2011 08:12:54 -0800
Subject: 12 bits tif image issue with skimage 0.5dev
In-Reply-To: <30282296.720.1323427645424.JavaMail.geo-discussion-forums@vbbeq1>
References: <30282296.720.1323427645424.JavaMail.geo-discussion-forums@vbbeq1>
Message-ID: <4EE23386.5000401@gmail.com>

On 12/9/2011 2:47 AM, jip wrote:
> Dear all,
> I update skimage to 0.5 dev on my ubuntu box. ipython startup gives:
> Imported NumPy 1.3.0, SciPy 0.7.2, Matplotlib 0.99.3 + guidata 1.2.5, 
> guiqwt 2.0.8.1
> Type "scientific" for more details.
> >>> import skimage
> >>> skimage.version
> <module 'skimage.version' from 
> '/usr/local/lib/python2.6/dist-packages/scikits_image-0.5dev-py2.6-linux-i686.egg/skimage/version.pyc'>
>
> A 12 bits tif image when loaded with skimage do not behave like the 
> same image loaded with an other library (readmagick, mahotas), as 
> shown above. When a 8 bits png image is loaded, the differences 
> (orientation, saturation) vanish.
>
> In a previous message Neil Yager said thatthe issue was fixed 
> <https://groups.google.com/forum/#%21topic/scikits-image/JSvqMzOgTEE>. 
> What should I do to fix the problem on my machine?
> Thank you.
>
> Jean-Patrick
>

Hi,

the PIL plugin has been fixed to correctly read 16 bit images. A PR for 
imshow is pending. The matplotlib plugin, which internally also uses 
PIL, is still broken. Matplotlib returns 8 bit, flipped images (by 
design it seems).

The problem is that PIL does not handle 16 bit images well. The solution 
in this case is to use more capable plugins for reading (e.g. FreeImage) 
and show (matplotlib ):

skimage.io.use_plugin('matplotlib', 'imshow')
skimage.io.use_plugin('freeimage', 'imread')

Christoph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111209/50a06b3e/attachment.html>

From thouis.jones at curie.fr  Fri Dec  9 05:24:08 2011
From: thouis.jones at curie.fr (Thouis Jones)
Date: Fri, 9 Dec 2011 11:24:08 +0100
Subject: Feature requests for 0.5
In-Reply-To: <CABDkGQm5hr1pkQhxOif3AdjEKd-f2WFzdvQdprN5BdXwm4i4Lw@mail.gmail.com>
References: <CABDkGQ=fsUTBZD_7KZ92d2E7nUvVBo61-eZwsQHsZ+9Sm7z8cA@mail.gmail.com>
 <ECDB5231-F5A2-4D68-8AB7-A33C4293FC45@gmail.com> <CABDkGQndqKKh7B9Yvuy=A4_PWHeH=hpORivA4VEOj7YR+5XAsw@mail.gmail.com>
 <CAHGWWxHmU+rfGcRr-82s82vCAtixbEeXDm7u-msZw4-abHPH-g@mail.gmail.com> <CABDkGQm5hr1pkQhxOif3AdjEKd-f2WFzdvQdprN5BdXwm4i4Lw@mail.gmail.com>
Message-ID: <CAHGWWxHGoq9YjEw_MXOxzUSm8UGRk7ytWFDYRmjBYMp+GB0qWQ@mail.gmail.com>

2011/12/9 St?fan van der Walt <stefan at sun.ac.za>:
> We'll probably borrow heavily from cpmath where we can. ?Since you
> have a lot of experience with this stuff, your feedback is appreciated
> (because, in the end, it would be great if you guys could actually use
> these tools!).

That's certainly our hope, as well.  We'd like to be able to trim down
CP as well as take advantage of a more widely deployed and therefore
(hopefully) better-tested codebase.

While we're on the subject of measuring objects...

You might consider supporting overlapping segmentations, using an ijk
(ij=position, k=label) scheme.  This has started to become necessary
for many of our experiments, and we're starting down the road of
making all the feature measurements compatible with this labeling
scheme.  This is the sort of thing to add earlier rather than later,
though I think Lee has some code to wrap a feature measurement
function in the non-overlapping style to make it ijk-compatible (by
looping over noninteracting sets of labels in the ijk matrix).

Ray


From stefan at sun.ac.za  Fri Dec  9 15:58:55 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 9 Dec 2011 12:58:55 -0800
Subject: New module for thresholding
In-Reply-To: <CAEym_HorW=jT6T_M47n_c=j2RP1kJ1acdoq6CVNrtQzbu6VBUg@mail.gmail.com>
References: <CAEym_HorW=jT6T_M47n_c=j2RP1kJ1acdoq6CVNrtQzbu6VBUg@mail.gmail.com>
Message-ID: <CABDkGQkqpgZjmSJwoo6xOz5BTcXajjB2HGAmxwKXkYqpB85c0w@mail.gmail.com>

On Fri, Dec 9, 2011 at 12:42 PM, Tony Yu <tsyu80 at gmail.com> wrote:
> It doesn't really make sense to add a separate thresholding module, so where
> should I put this thresholding function?

Another place it could fit is in the filter sub-module, since it is
just a per-pixel operation.

You also mentioned histogram equalisation, but that we may want to put
in an "exposure" module, along with things like dynamic range imaging
etc.

St?fan


From jeanpatrick.pommier at gmail.com  Fri Dec  9 16:02:05 2011
From: jeanpatrick.pommier at gmail.com (jip)
Date: Fri, 9 Dec 2011 13:02:05 -0800 (PST)
Subject: 12 bits tif image issue with skimage 0.5dev
In-Reply-To: <4EE23386.5000401@gmail.com>
References: <30282296.720.1323427645424.JavaMail.geo-discussion-forums@vbbeq1> <4EE23386.5000401@gmail.com>
Message-ID: <35055ed8-a2b9-420a-bffc-ed87201cf921@b32g2000yqn.googlegroups.com>

Hi,
Thank you for your explanations.
Jean-Patrick

On 9 d?c, 17:12, Christoph Gohlke <cjgoh... at gmail.com> wrote:
> On 12/9/2011 2:47 AM, jip wrote:
>
>
>
>
>
>
>
>
>
> > Dear all,
> > I update skimage to 0.5 dev on my ubuntu box. ipython startup gives:
> > Imported NumPy 1.3.0, SciPy 0.7.2, Matplotlib 0.99.3 + guidata 1.2.5,
> > guiqwt 2.0.8.1
> > Type "scientific" for more details.
> > >>> import skimage
> > >>> skimage.version
> > <module 'skimage.version' from
> > '/usr/local/lib/python2.6/dist-packages/scikits_image-0.5dev-py2.6-linux-i686.egg/skimage/version.pyc'>
>
> > A 12 bits tif image when loaded with skimage do not behave like the
> > same image loaded with an other library (readmagick, mahotas), as
> > shown above. When a 8 bits png image is loaded, the differences
> > (orientation, saturation) vanish.
>
> > In a previous message Neil Yager said thatthe issue was fixed
> > <https://groups.google.com/forum/#%21topic/scikits-image/JSvqMzOgTEE>.
> > What should I do to fix the problem on my machine?
> > Thank you.
>
> > Jean-Patrick
>
> Hi,
>
> the PIL plugin has been fixed to correctly read 16 bit images. A PR for
> imshow is pending. The matplotlib plugin, which internally also uses
> PIL, is still broken. Matplotlib returns 8 bit, flipped images (by
> design it seems).
>
> The problem is that PIL does not handle 16 bit images well. The solution
> in this case is to use more capable plugins for reading (e.g. FreeImage)
> and show (matplotlib ):
>
> skimage.io.use_plugin('matplotlib', 'imshow')
> skimage.io.use_plugin('freeimage', 'imread')
>
> Christoph


From tsyu80 at gmail.com  Fri Dec  9 15:42:08 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Fri, 9 Dec 2011 15:42:08 -0500
Subject: New module for thresholding
Message-ID: <CAEym_HorW=jT6T_M47n_c=j2RP1kJ1acdoq6CVNrtQzbu6VBUg@mail.gmail.com>

This came up in a pull request to add
thresholding<https://github.com/scikits-image/scikits-image/pull/98>to
skimage, but I thought it'd be good to move the discussion to the
mailing list.

It doesn't really make sense to add a separate thresholding module, so
where should I put this thresholding function? My proposal is to add a
"levels" module and put thresholding there. Then, for example, we could add
some functions to adjust contrast/brightness/gamma. Someone suggested a
histogram equalization function, which would also fit in a levels module.
On the other hand, "levels" is often used by photo-editing programs to
denote a specific tool for adjusting color/intensity levels.

Thoughts/ideas?

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

From stefan at sun.ac.za  Fri Dec  9 19:07:06 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 9 Dec 2011 16:07:06 -0800
Subject: New module for thresholding
In-Reply-To: <CAEym_HoiMA1V7dnmc2zeTgHMfH1O7QxwFh75EQPjtknMBr+B4g@mail.gmail.com>
References: <CAEym_HorW=jT6T_M47n_c=j2RP1kJ1acdoq6CVNrtQzbu6VBUg@mail.gmail.com>
 <CABDkGQkqpgZjmSJwoo6xOz5BTcXajjB2HGAmxwKXkYqpB85c0w@mail.gmail.com> <CAEym_HoiMA1V7dnmc2zeTgHMfH1O7QxwFh75EQPjtknMBr+B4g@mail.gmail.com>
Message-ID: <CABDkGQkDsh=HWSCd+KXP-emT6xhc6PVNd+X8x8LMz0OaCaDTCw@mail.gmail.com>

On Fri, Dec 9, 2011 at 3:04 PM, Tony Yu <tsyu80 at gmail.com> wrote:
> Putting thresholding in filter is a little strange to me (for some reason).
> But if there's no other suggestions, I'm fine with it.

It's not perfect... any other suggestions anyone?


From stefan at sun.ac.za  Fri Dec  9 19:37:44 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 9 Dec 2011 16:37:44 -0800
Subject: Feature requests for 0.5
In-Reply-To: <CAHGWWxHGoq9YjEw_MXOxzUSm8UGRk7ytWFDYRmjBYMp+GB0qWQ@mail.gmail.com>
References: <CABDkGQ=fsUTBZD_7KZ92d2E7nUvVBo61-eZwsQHsZ+9Sm7z8cA@mail.gmail.com>
 <ECDB5231-F5A2-4D68-8AB7-A33C4293FC45@gmail.com> <CABDkGQndqKKh7B9Yvuy=A4_PWHeH=hpORivA4VEOj7YR+5XAsw@mail.gmail.com>
 <CAHGWWxHmU+rfGcRr-82s82vCAtixbEeXDm7u-msZw4-abHPH-g@mail.gmail.com>
 <CABDkGQm5hr1pkQhxOif3AdjEKd-f2WFzdvQdprN5BdXwm4i4Lw@mail.gmail.com> <CAHGWWxHGoq9YjEw_MXOxzUSm8UGRk7ytWFDYRmjBYMp+GB0qWQ@mail.gmail.com>
Message-ID: <CABDkGQk6jDnVvSUQjs7QF=D8ZNG2cJUZrPzyZ_LG90NbUqgH8A@mail.gmail.com>

On Fri, Dec 9, 2011 at 2:24 AM, Thouis Jones <thouis.jones at curie.fr> wrote:
> While we're on the subject of measuring objects...
>
> You might consider supporting overlapping segmentations, using an ijk
> (ij=position, k=label) scheme.

Thanks, that's exactly the kind of design input we need.

St?fan


From tsyu80 at gmail.com  Fri Dec  9 18:04:24 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Fri, 9 Dec 2011 18:04:24 -0500
Subject: New module for thresholding
In-Reply-To: <CABDkGQkqpgZjmSJwoo6xOz5BTcXajjB2HGAmxwKXkYqpB85c0w@mail.gmail.com>
References: <CAEym_HorW=jT6T_M47n_c=j2RP1kJ1acdoq6CVNrtQzbu6VBUg@mail.gmail.com>
	<CABDkGQkqpgZjmSJwoo6xOz5BTcXajjB2HGAmxwKXkYqpB85c0w@mail.gmail.com>
Message-ID: <CAEym_HoiMA1V7dnmc2zeTgHMfH1O7QxwFh75EQPjtknMBr+B4g@mail.gmail.com>

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

> On Fri, Dec 9, 2011 at 12:42 PM, Tony Yu <tsyu80 at gmail.com> wrote:
> > It doesn't really make sense to add a separate thresholding module, so
> where
> > should I put this thresholding function?
>
> Another place it could fit is in the filter sub-module, since it is
> just a per-pixel operation.
>
> You also mentioned histogram equalisation, but that we may want to put
> in an "exposure" module, along with things like dynamic range imaging
> etc.
>
> St?fan
>

I like the idea of an "exposure" module, and it definitely has a clear
meaning, unlike "levels".

Putting thresholding in filter is a little strange to me (for some reason).
But if there's no other suggestions, I'm fine with it.

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

From tsyu80 at gmail.com  Sun Dec 11 11:13:48 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Sun, 11 Dec 2011 11:13:48 -0500
Subject: Measure and graph subpackages
Message-ID: <CAEym_HoUoL0pi__9nmQeQxQhdh0KQWYbGepjh0cZK+drjtrpKg@mail.gmail.com>

I don't know anything about graph theory, but from my (naive) perspective,
it seems that the graph subpackage should be part of the measure
subpackage. Is this correct?

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

From stefan at sun.ac.za  Sun Dec 11 14:55:44 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 11 Dec 2011 11:55:44 -0800
Subject: Measure and graph subpackages
In-Reply-To: <CAEym_HqbV0qdYA6-xMkG6itq69XDZ2kSarPSj69OKZDcFm3y=Q@mail.gmail.com>
References: <CAEym_HoUoL0pi__9nmQeQxQhdh0KQWYbGepjh0cZK+drjtrpKg@mail.gmail.com>
	<74679EFD-FAAC-4CEF-8CE4-FED35C3FF3C0@yale.edu>
	<CAEym_HqbV0qdYA6-xMkG6itq69XDZ2kSarPSj69OKZDcFm3y=Q@mail.gmail.com>
Message-ID: <CABDkGQmPm1qz=ODudS731msFbNuvwpMd5dwYy8LO5CJ5a0-EKg@mail.gmail.com>

On Dec 11, 2011 10:26 AM, "Tony Yu" <tsyu80 at gmail.com> wrote:
>
> On Sun, Dec 11, 2011 at 12:46 PM, Zachary Pincus <zachary.pincus at yale.edu>
wrote:
>>
>> St?fan may be able to amplify, but IIRC he has some other code to put
into measure that should more clearly differentiate the two sub-modules.
Right now it's correct that both the content in 'measure' (marching-squares
contour-finding) and in 'graph' (Dijkstra's algorithm on a lattice) are
both about tracing paths through pixel arrays, albeit in very different
contexts. So it might not be bad to re-organize.
>>
>> But contour-finding is not a graph operation, so such a re-org should be
more than putting that code in the 'graph' package.
>
> Oh, I meant the other way around: getting the minimum-cost path seems
like something you measure in an image. (Sort of.) That was under the
assumption that nothing else was planned for the graph package.

I was thinking of putting things like graph cuts in there, but placing an
emphasis on the way a function is implemented rather than what it does may
be the wrong approach. E.g., we don't put image filters in the Fourier
submodule. What can go in there is maybe graph handling utilities for other
functions.

So, where would a good home for shortest path be? We'll keep a link to the
original location for backward compatibility too.

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

From zachary.pincus at yale.edu  Sun Dec 11 12:46:09 2011
From: zachary.pincus at yale.edu (Zachary Pincus)
Date: Sun, 11 Dec 2011 12:46:09 -0500
Subject: Measure and graph subpackages
In-Reply-To: <CAEym_HoUoL0pi__9nmQeQxQhdh0KQWYbGepjh0cZK+drjtrpKg@mail.gmail.com>
References: <CAEym_HoUoL0pi__9nmQeQxQhdh0KQWYbGepjh0cZK+drjtrpKg@mail.gmail.com>
Message-ID: <74679EFD-FAAC-4CEF-8CE4-FED35C3FF3C0@yale.edu>

St?fan may be able to amplify, but IIRC he has some other code to put into measure that should more clearly differentiate the two sub-modules. Right now it's correct that both the content in 'measure' (marching-squares contour-finding) and in 'graph' (Dijkstra's algorithm on a lattice) are both about tracing paths through pixel arrays, albeit in very different contexts. So it might not be bad to re-organize.

But contour-finding is not a graph operation, so such a re-org should be more than putting that code in the 'graph' package.

Zach


On Dec 11, 2011, at 11:13 AM, Tony Yu wrote:

> I don't know anything about graph theory, but from my (naive) perspective, it seems that the graph subpackage should be part of the measure subpackage. Is this correct?
> 
> -Tony



From tsyu80 at gmail.com  Sun Dec 11 13:15:53 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Sun, 11 Dec 2011 13:15:53 -0500
Subject: Measure and graph subpackages
In-Reply-To: <74679EFD-FAAC-4CEF-8CE4-FED35C3FF3C0@yale.edu>
References: <CAEym_HoUoL0pi__9nmQeQxQhdh0KQWYbGepjh0cZK+drjtrpKg@mail.gmail.com>
	<74679EFD-FAAC-4CEF-8CE4-FED35C3FF3C0@yale.edu>
Message-ID: <CAEym_HqbV0qdYA6-xMkG6itq69XDZ2kSarPSj69OKZDcFm3y=Q@mail.gmail.com>

On Sun, Dec 11, 2011 at 12:46 PM, Zachary Pincus <zachary.pincus at yale.edu>wrote:

> St?fan may be able to amplify, but IIRC he has some other code to put into
> measure that should more clearly differentiate the two sub-modules. Right
> now it's correct that both the content in 'measure' (marching-squares
> contour-finding) and in 'graph' (Dijkstra's algorithm on a lattice) are
> both about tracing paths through pixel arrays, albeit in very different
> contexts. So it might not be bad to re-organize.
>
> But contour-finding is not a graph operation, so such a re-org should be
> more than putting that code in the 'graph' package.
>
> Zach
>

Oh, I meant the other way around: getting the minimum-cost path seems like
something you measure in an image. (Sort of.) That was under the assumption
that nothing else was planned for the graph package.

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

From tj.takei at gmail.com  Mon Dec 12 17:27:14 2011
From: tj.takei at gmail.com (karoyakani)
Date: Mon, 12 Dec 2011 14:27:14 -0800 (PST)
Subject: skeletonize question
Message-ID: <b146676c-2d06-455e-8ce9-8d831efc36ca@e8g2000prb.googlegroups.com>

Hi,

I'm new to this mailing list.
skimage version 0.4.2 has morphology.skeletonize() that works almost
as good as Matlab bwmorph('thin').
However the output seems transposed when I tested a Matlab's example
image 'circles.png':
http://www.mathworks.com/help/toolbox/images/ref/bwmorph.html
Is this a bug?

########
import numpy as np
from scipy import ndimage
from scipy.io import loadmat
from skimage.morphology import skeletonize
import matplotlib.pyplot as plt

# test image from Matlab bwmorph('skel') demo
bw = loadmat('circles.mat')['BW']
sk = skeletonize(bw)

plt.figure()
plt.imshow(bw+sk.transpose(), cmap=plt.cm.gray,
interpolation='nearest')
plt.show()
########

Thanks,
- TJ


From stefan at sun.ac.za  Mon Dec 12 18:34:01 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 12 Dec 2011 15:34:01 -0800
Subject: skeletonize question
In-Reply-To: <b146676c-2d06-455e-8ce9-8d831efc36ca@e8g2000prb.googlegroups.com>
References: <b146676c-2d06-455e-8ce9-8d831efc36ca@e8g2000prb.googlegroups.com>
Message-ID: <CABDkGQkjxyAKDsiS7_ji6HA0+kzSM-1=4gx6VAp0Kr-WBH1WdA@mail.gmail.com>

Hi TJ

On Mon, Dec 12, 2011 at 2:27 PM, karoyakani <tj.takei at gmail.com> wrote:
> I'm new to this mailing list.

Welcome!  We're glad to have you.

> skimage version 0.4.2 has morphology.skeletonize() that works almost
> as good as Matlab bwmorph('thin').

We'd certainly love to remedy that...

> However the output seems transposed when I tested a Matlab's example
> image 'circles.png':
> http://www.mathworks.com/help/toolbox/images/ref/bwmorph.html
> Is this a bug?

In order to reproduce this bug, I've put a repo online with your code:

https://github.com/stefanv/skimage_circles

Here is the output I get:

http://mentat.za.net/refer/skeletonize_compare.png

(Before running the experiment, run fetch_data to download the matlab
test image; or just grab it by hand from their website.  I don't know
what the license is, so I didn't want to put it in the repo directly.)

I am glad you showed me this example, because it also pointed out a
problem with paletted image reading in PIL.  I'm seriously considering
just making matplotlib our default backend (except that they also have
a PNG reading bug in older versions where images are flipped upside
down!).

Regards
St?fan


From stefan at sun.ac.za  Mon Dec 12 20:28:49 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 12 Dec 2011 17:28:49 -0800
Subject: io plugin issue (8bits 16bits)
In-Reply-To: <4538990.458.1323353822216.JavaMail.geo-discussion-forums@vbmr10>
References: <26552631.1394.1323091277849.JavaMail.geo-discussion-forums@yqcc19>
 <4538990.458.1323353822216.JavaMail.geo-discussion-forums@vbmr10>
Message-ID: <CABDkGQmDnyL0vkVCy7PA-vOgBHs9m+1aHw1=hBrvZEhwoq49Lw@mail.gmail.com>

Hi JP

On Thu, Dec 8, 2011 at 6:17 AM, jip <jeanpatrick.pommier at gmail.com> wrote:
> As you can see, displaying a 16 bits image yield a saturated image and the
> orientation is mirrored.
> When a 8 bit png image is loaded the three libs (sio, readmagick mahotas),
> no difference can be seen.

This seems to be a matplotlib bug; I can reproduce it on my machine.
I've filed a PR against matplotlib:

https://github.com/matplotlib/matplotlib/pull/622

Cheers
St?fan


From stefan at sun.ac.za  Mon Dec 12 20:56:12 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 12 Dec 2011 17:56:12 -0800
Subject: skeletonize question
In-Reply-To: <CAEym_HrDLDQ8zFoU54_69GR_nux8B3Diaat3KVvjvergppfPbw@mail.gmail.com>
References: <b146676c-2d06-455e-8ce9-8d831efc36ca@e8g2000prb.googlegroups.com>
 <CABDkGQkjxyAKDsiS7_ji6HA0+kzSM-1=4gx6VAp0Kr-WBH1WdA@mail.gmail.com> <CAEym_HrDLDQ8zFoU54_69GR_nux8B3Diaat3KVvjvergppfPbw@mail.gmail.com>
Message-ID: <CABDkGQmP3P5jeFWMQa7TS2C_8wXZR1-uzgy+p0bf9h1sQQNO1w@mail.gmail.com>

On Mon, Dec 12, 2011 at 5:13 PM, Tony Yu <tsyu80 at gmail.com> wrote:
>
> Strange: when I open "circles.png" using the matplotlib backend, I get a
> float32 array (with the white pixels equal to 0.00392157). With the PIL
> backend, I get a bool array (before your recent bug fix) or uint8 (after the
> fix). Are you not having the same issue with matplotlib?

While the bool type is fine (it's a black and white image), the pixel
order was completely messed up; try to display it!

In mpl, I see the same thing you do.  It is because matplotlib assumes
that all images with depth < 8 is 8-bit, and therefore returns 1/255
instead of 1.  Filed here:

https://github.com/matplotlib/matplotlib/pull/623

Cheers
St?fan


From tsyu80 at gmail.com  Mon Dec 12 20:13:04 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Mon, 12 Dec 2011 20:13:04 -0500
Subject: skeletonize question
In-Reply-To: <CABDkGQkjxyAKDsiS7_ji6HA0+kzSM-1=4gx6VAp0Kr-WBH1WdA@mail.gmail.com>
References: <b146676c-2d06-455e-8ce9-8d831efc36ca@e8g2000prb.googlegroups.com>
	<CABDkGQkjxyAKDsiS7_ji6HA0+kzSM-1=4gx6VAp0Kr-WBH1WdA@mail.gmail.com>
Message-ID: <CAEym_HrDLDQ8zFoU54_69GR_nux8B3Diaat3KVvjvergppfPbw@mail.gmail.com>

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

> Hi TJ
>
> On Mon, Dec 12, 2011 at 2:27 PM, karoyakani <tj.takei at gmail.com> wrote:
> > I'm new to this mailing list.
>
> Welcome!  We're glad to have you.
>
> > skimage version 0.4.2 has morphology.skeletonize() that works almost
> > as good as Matlab bwmorph('thin').
>
> We'd certainly love to remedy that...
>
> > However the output seems transposed when I tested a Matlab's example
> > image 'circles.png':
> > http://www.mathworks.com/help/toolbox/images/ref/bwmorph.html
> > Is this a bug?
>
> In order to reproduce this bug, I've put a repo online with your code:
>
> https://github.com/stefanv/skimage_circles
>
> Here is the output I get:
>
> http://mentat.za.net/refer/skeletonize_compare.png
>
> (Before running the experiment, run fetch_data to download the matlab
> test image; or just grab it by hand from their website.  I don't know
> what the license is, so I didn't want to put it in the repo directly.)
>
> I am glad you showed me this example, because it also pointed out a
> problem with paletted image reading in PIL.  I'm seriously considering
> just making matplotlib our default backend (except that they also have
> a PNG reading bug in older versions where images are flipped upside
> down!).
>
> Regards
> St?fan


Strange: when I open "circles.png" using the matplotlib backend, I get a
float32 array (with the white pixels equal to 0.00392157). With the PIL
backend, I get a bool array (before your recent bug fix) or uint8 (after
the fix). Are you not having the same issue with matplotlib?

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

From tsyu80 at gmail.com  Mon Dec 12 21:22:13 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Mon, 12 Dec 2011 21:22:13 -0500
Subject: skeletonize question
In-Reply-To: <CABDkGQmP3P5jeFWMQa7TS2C_8wXZR1-uzgy+p0bf9h1sQQNO1w@mail.gmail.com>
References: <b146676c-2d06-455e-8ce9-8d831efc36ca@e8g2000prb.googlegroups.com>
	<CABDkGQkjxyAKDsiS7_ji6HA0+kzSM-1=4gx6VAp0Kr-WBH1WdA@mail.gmail.com>
	<CAEym_HrDLDQ8zFoU54_69GR_nux8B3Diaat3KVvjvergppfPbw@mail.gmail.com>
	<CABDkGQmP3P5jeFWMQa7TS2C_8wXZR1-uzgy+p0bf9h1sQQNO1w@mail.gmail.com>
Message-ID: <CAEym_Hra61yEzpag0fsNtJyNUzmvj1fQHtPCHZaxi3iJCzv2kg@mail.gmail.com>

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

> On Mon, Dec 12, 2011 at 5:13 PM, Tony Yu <tsyu80 at gmail.com> wrote:
> >
> > Strange: when I open "circles.png" using the matplotlib backend, I get a
> > float32 array (with the white pixels equal to 0.00392157). With the PIL
> > backend, I get a bool array (before your recent bug fix) or uint8 (after
> the
> > fix). Are you not having the same issue with matplotlib?
>
> While the bool type is fine (it's a black and white image), the pixel
> order was completely messed up; try to display it!
>

Wow, when you said the pixel order was messed up, I thought you meant that
it was just transposed, but it *really* is screwed up.


>
> In mpl, I see the same thing you do.  It is because matplotlib assumes
> that all images with depth < 8 is 8-bit, and therefore returns 1/255
> instead of 1.  Filed here:
>
> https://github.com/matplotlib/matplotlib/pull/623
>

Good, I thought it was just me.


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

From zachary.pincus at yale.edu  Tue Dec 13 10:09:41 2011
From: zachary.pincus at yale.edu (Zachary Pincus)
Date: Tue, 13 Dec 2011 10:09:41 -0500
Subject: skeletonize question
In-Reply-To: <CAHGWWxFeFjKJDaoaoY+ZysYy2wgpjsW9R44J38XKnscS9tPmNA@mail.gmail.com>
References: <b146676c-2d06-455e-8ce9-8d831efc36ca@e8g2000prb.googlegroups.com> <CABDkGQkjxyAKDsiS7_ji6HA0+kzSM-1=4gx6VAp0Kr-WBH1WdA@mail.gmail.com> <CAHGWWxFeFjKJDaoaoY+ZysYy2wgpjsW9R44J38XKnscS9tPmNA@mail.gmail.com>
Message-ID: <DE131EA3-C429-4AC3-AF99-C6CB54433EA4@yale.edu>

On Dec 13, 2011, at 5:23 AM, Thouis (Ray) Jones wrote:
> 2011/12/13 St?fan van der Walt <stefan at sun.ac.za>:
>> I am glad you showed me this example, because it also pointed out a
>> problem with paletted image reading in PIL.  I'm seriously considering
>> just making matplotlib our default backend (except that they also have
>> a PNG reading bug in older versions where images are flipped upside
>> down!).
> 
> Having fought this fight far too many times, I'm beginning to think
> there's a need for a simple, small, and fast python module wrapping
> libtiff, libpng, and libjpeg and talking to numpy.  This would handle
> 90% or more of everyone's needs and would hopefully be simpler to
> install and use than PIL (and would have a faster development cycle).
> 
> Ray Jones

That's why I wrote that FreeImage backend... But maybe asking people to get libfreeimage (lightweight and dependency-free as it may be) is harder than ensuring they have libs tiff, png, and jpeg?

There are win32 DLLs available for FreeImage, but no pre-built binaries for OS X, and I don't know if many/any/all linux distros provide packages for FreeImage. Does anyone know this? Similarly, I'm not sure what the licensing issues would be for providing pre-built FreeImage libraries -- FreeImage is GPL (v2), not LGPL, and so I don't actually know whether that means pre-build FreeImage libs can be distributed with skimage or not.

Zach


From cjgohlke at gmail.com  Tue Dec 13 13:15:04 2011
From: cjgohlke at gmail.com (Christoph Gohlke)
Date: Tue, 13 Dec 2011 10:15:04 -0800
Subject: skeletonize question
In-Reply-To: <B92F3EF9-23EA-4C3F-8735-F8200465784A@yale.edu>
References: <b146676c-2d06-455e-8ce9-8d831efc36ca@e8g2000prb.googlegroups.com> <CABDkGQkjxyAKDsiS7_ji6HA0+kzSM-1=4gx6VAp0Kr-WBH1WdA@mail.gmail.com> <CAHGWWxFeFjKJDaoaoY+ZysYy2wgpjsW9R44J38XKnscS9tPmNA@mail.gmail.com> <DE131EA3-C429-4AC3-AF99-C6CB54433EA4@yale.edu> <CAHGWWxHd4GisBicWzBE4kcvvr0RnoeVxgzLCbjz1dzeX8ShFCA@mail.gmail.com> <B92F3EF9-23EA-4C3F-8735-F8200465784A@yale.edu>
Message-ID: <4EE79628.7090704@gmail.com>

On 12/13/2011 8:54 AM, Zachary Pincus wrote:
>> Your wrapper is read-only, right?  Any sense on how much work to make
>> it able to write some of these formats, as well?
> Nope, read-write, with basic handling for multipage files (read-write also), though I've only tested this with TIFFs.
>
> FreeImage supports a ton of image formats (read and write), all of which should work via the wrappers I wrote:
> http://freeimage.sourceforge.net/features.html
>
> Moreover, the library supports read/write for most of the exotic pixel types supported by some file formats. See the appendix of the documentation PDF for a full list of filetypes/pixel-types supported:
> http://freeimage.sourceforge.net/documentation.html
>
> Of specific interest for scientific imaging, pretty much every numpy dtype can be read/written in TIFF format, including signed/unsigned ints (8/16/32) and floats (32/64), and even complex too, for what that's worth.

FWIW, writing numpy arrays to TIFF files can be done in pure Python in 
less lines than the GPL license. Reading is more complicated, just 
because there are so many options, extensions, and broken files out 
there. No single library handles them all.

Christoph

> PNGs support greyscale/RGB/RGBA for uint8/16, and JPEGs support greyscale/RGB uint8.
>
> Filetype-specific compression options are selectable via IO flags. There's also rudimentary support in my wrappers for reading strings from image metadata (which I use for getting the info out of OME-TIFF files). This could easily be beefed up.
>
> Overall, FreeImage is a decent little library, with a reasonably clean API. I tried to keep the ctypes wrappers as simple and thin as possible:
> https://github.com/scikits-image/scikits-image/blob/master/skimage/io/_plugins/freeimage_plugin.py
>
> There's a lot more functionality of FreeImage than is currently exposed, but this is a pretty good start.
>
>
> Zach
>
>
>
> On Dec 13, 2011, at 10:45 AM, Thouis (Ray) Jones wrote:
>
>> On Tue, Dec 13, 2011 at 16:09, Zachary Pincus<zachary.pincus at yale.edu>  wrote:
>>> On Dec 13, 2011, at 5:23 AM, Thouis (Ray) Jones wrote:
>>>> Having fought this fight far too many times, I'm beginning to think
>>>> there's a need for a simple, small, and fast python module wrapping
>>>> libtiff, libpng, and libjpeg and talking to numpy.  This would handle
>>>> 90% or more of everyone's needs and would hopefully be simpler to
>>>> install and use than PIL (and would have a faster development cycle).
>>> That's why I wrote that FreeImage backend... But maybe asking people to get libfreeimage (lightweight and dependency-free as it may be) is harder than ensuring they have libs tiff, png, and jpeg?
>> This is probably good enough.  I admit we never tried this option with
>> CellProfiler.
>>
>> Your wrapper is read-only, right?  Any sense on how much work to make
>> it able to write some of these formats, as well?
>>
>> Ray
>



From thouis at gmail.com  Tue Dec 13 05:23:01 2011
From: thouis at gmail.com (Thouis (Ray) Jones)
Date: Tue, 13 Dec 2011 11:23:01 +0100
Subject: skeletonize question
In-Reply-To: <CABDkGQkjxyAKDsiS7_ji6HA0+kzSM-1=4gx6VAp0Kr-WBH1WdA@mail.gmail.com>
References: <b146676c-2d06-455e-8ce9-8d831efc36ca@e8g2000prb.googlegroups.com> <CABDkGQkjxyAKDsiS7_ji6HA0+kzSM-1=4gx6VAp0Kr-WBH1WdA@mail.gmail.com>
Message-ID: <CAHGWWxFeFjKJDaoaoY+ZysYy2wgpjsW9R44J38XKnscS9tPmNA@mail.gmail.com>

2011/12/13 St?fan van der Walt <stefan at sun.ac.za>:
> I am glad you showed me this example, because it also pointed out a
> problem with paletted image reading in PIL. ?I'm seriously considering
> just making matplotlib our default backend (except that they also have
> a PNG reading bug in older versions where images are flipped upside
> down!).

Having fought this fight far too many times, I'm beginning to think
there's a need for a simple, small, and fast python module wrapping
libtiff, libpng, and libjpeg and talking to numpy.  This would handle
90% or more of everyone's needs and would hopefully be simpler to
install and use than PIL (and would have a faster development cycle).

Ray Jones


From zachary.pincus at yale.edu  Tue Dec 13 11:54:54 2011
From: zachary.pincus at yale.edu (Zachary Pincus)
Date: Tue, 13 Dec 2011 11:54:54 -0500
Subject: skeletonize question
In-Reply-To: <CAHGWWxHd4GisBicWzBE4kcvvr0RnoeVxgzLCbjz1dzeX8ShFCA@mail.gmail.com>
References: <b146676c-2d06-455e-8ce9-8d831efc36ca@e8g2000prb.googlegroups.com> <CABDkGQkjxyAKDsiS7_ji6HA0+kzSM-1=4gx6VAp0Kr-WBH1WdA@mail.gmail.com> <CAHGWWxFeFjKJDaoaoY+ZysYy2wgpjsW9R44J38XKnscS9tPmNA@mail.gmail.com> <DE131EA3-C429-4AC3-AF99-C6CB54433EA4@yale.edu> <CAHGWWxHd4GisBicWzBE4kcvvr0RnoeVxgzLCbjz1dzeX8ShFCA@mail.gmail.com>
Message-ID: <B92F3EF9-23EA-4C3F-8735-F8200465784A@yale.edu>

> Your wrapper is read-only, right?  Any sense on how much work to make
> it able to write some of these formats, as well?

Nope, read-write, with basic handling for multipage files (read-write also), though I've only tested this with TIFFs.

FreeImage supports a ton of image formats (read and write), all of which should work via the wrappers I wrote:
http://freeimage.sourceforge.net/features.html

Moreover, the library supports read/write for most of the exotic pixel types supported by some file formats. See the appendix of the documentation PDF for a full list of filetypes/pixel-types supported:
http://freeimage.sourceforge.net/documentation.html

Of specific interest for scientific imaging, pretty much every numpy dtype can be read/written in TIFF format, including signed/unsigned ints (8/16/32) and floats (32/64), and even complex too, for what that's worth. PNGs support greyscale/RGB/RGBA for uint8/16, and JPEGs support greyscale/RGB uint8. 

Filetype-specific compression options are selectable via IO flags. There's also rudimentary support in my wrappers for reading strings from image metadata (which I use for getting the info out of OME-TIFF files). This could easily be beefed up.

Overall, FreeImage is a decent little library, with a reasonably clean API. I tried to keep the ctypes wrappers as simple and thin as possible:
https://github.com/scikits-image/scikits-image/blob/master/skimage/io/_plugins/freeimage_plugin.py

There's a lot more functionality of FreeImage than is currently exposed, but this is a pretty good start.


Zach



On Dec 13, 2011, at 10:45 AM, Thouis (Ray) Jones wrote:

> On Tue, Dec 13, 2011 at 16:09, Zachary Pincus <zachary.pincus at yale.edu> wrote:
>> On Dec 13, 2011, at 5:23 AM, Thouis (Ray) Jones wrote:
>>> Having fought this fight far too many times, I'm beginning to think
>>> there's a need for a simple, small, and fast python module wrapping
>>> libtiff, libpng, and libjpeg and talking to numpy.  This would handle
>>> 90% or more of everyone's needs and would hopefully be simpler to
>>> install and use than PIL (and would have a faster development cycle).
>> 
>> That's why I wrote that FreeImage backend... But maybe asking people to get libfreeimage (lightweight and dependency-free as it may be) is harder than ensuring they have libs tiff, png, and jpeg?
> 
> This is probably good enough.  I admit we never tried this option with
> CellProfiler.
> 
> Your wrapper is read-only, right?  Any sense on how much work to make
> it able to write some of these formats, as well?
> 
> Ray



From zachary.pincus at yale.edu  Tue Dec 13 12:03:17 2011
From: zachary.pincus at yale.edu (Zachary Pincus)
Date: Tue, 13 Dec 2011 12:03:17 -0500
Subject: skeletonize question
In-Reply-To: <B92F3EF9-23EA-4C3F-8735-F8200465784A@yale.edu>
References: <b146676c-2d06-455e-8ce9-8d831efc36ca@e8g2000prb.googlegroups.com> <CABDkGQkjxyAKDsiS7_ji6HA0+kzSM-1=4gx6VAp0Kr-WBH1WdA@mail.gmail.com> <CAHGWWxFeFjKJDaoaoY+ZysYy2wgpjsW9R44J38XKnscS9tPmNA@mail.gmail.com> <DE131EA3-C429-4AC3-AF99-C6CB54433EA4@yale.edu> <CAHGWWxHd4GisBicWzBE4kcvvr0RnoeVxgzLCbjz1dzeX8ShFCA@mail.gmail.com> <B92F3EF9-23EA-4C3F-8735-F8200465784A@yale.edu>
Message-ID: <D1D1FF59-7D6B-4165-8082-9FC7D58FF048@yale.edu>

Also, can anyone explain decide the FreeImage Public License is compatible with skimage? Maybe it would be possible to provide some pre-built binary libraries for win/os x.
http://freeimage.sourceforge.net/license.html



On Dec 13, 2011, at 11:54 AM, Zachary Pincus wrote:

>> Your wrapper is read-only, right?  Any sense on how much work to make
>> it able to write some of these formats, as well?
> 
> Nope, read-write, with basic handling for multipage files (read-write also), though I've only tested this with TIFFs.
> 
> FreeImage supports a ton of image formats (read and write), all of which should work via the wrappers I wrote:
> http://freeimage.sourceforge.net/features.html
> 
> Moreover, the library supports read/write for most of the exotic pixel types supported by some file formats. See the appendix of the documentation PDF for a full list of filetypes/pixel-types supported:
> http://freeimage.sourceforge.net/documentation.html
> 
> Of specific interest for scientific imaging, pretty much every numpy dtype can be read/written in TIFF format, including signed/unsigned ints (8/16/32) and floats (32/64), and even complex too, for what that's worth. PNGs support greyscale/RGB/RGBA for uint8/16, and JPEGs support greyscale/RGB uint8. 
> 
> Filetype-specific compression options are selectable via IO flags. There's also rudimentary support in my wrappers for reading strings from image metadata (which I use for getting the info out of OME-TIFF files). This could easily be beefed up.
> 
> Overall, FreeImage is a decent little library, with a reasonably clean API. I tried to keep the ctypes wrappers as simple and thin as possible:
> https://github.com/scikits-image/scikits-image/blob/master/skimage/io/_plugins/freeimage_plugin.py
> 
> There's a lot more functionality of FreeImage than is currently exposed, but this is a pretty good start.
> 
> 
> Zach
> 
> 
> 
> On Dec 13, 2011, at 10:45 AM, Thouis (Ray) Jones wrote:
> 
>> On Tue, Dec 13, 2011 at 16:09, Zachary Pincus <zachary.pincus at yale.edu> wrote:
>>> On Dec 13, 2011, at 5:23 AM, Thouis (Ray) Jones wrote:
>>>> Having fought this fight far too many times, I'm beginning to think
>>>> there's a need for a simple, small, and fast python module wrapping
>>>> libtiff, libpng, and libjpeg and talking to numpy.  This would handle
>>>> 90% or more of everyone's needs and would hopefully be simpler to
>>>> install and use than PIL (and would have a faster development cycle).
>>> 
>>> That's why I wrote that FreeImage backend... But maybe asking people to get libfreeimage (lightweight and dependency-free as it may be) is harder than ensuring they have libs tiff, png, and jpeg?
>> 
>> This is probably good enough.  I admit we never tried this option with
>> CellProfiler.
>> 
>> Your wrapper is read-only, right?  Any sense on how much work to make
>> it able to write some of these formats, as well?
>> 
>> Ray



From stefan at sun.ac.za  Tue Dec 13 18:58:58 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 13 Dec 2011 15:58:58 -0800
Subject: skeletonize question
In-Reply-To: <D1D1FF59-7D6B-4165-8082-9FC7D58FF048@yale.edu>
References: <b146676c-2d06-455e-8ce9-8d831efc36ca@e8g2000prb.googlegroups.com>
 <CABDkGQkjxyAKDsiS7_ji6HA0+kzSM-1=4gx6VAp0Kr-WBH1WdA@mail.gmail.com>
 <CAHGWWxFeFjKJDaoaoY+ZysYy2wgpjsW9R44J38XKnscS9tPmNA@mail.gmail.com>
 <DE131EA3-C429-4AC3-AF99-C6CB54433EA4@yale.edu> <CAHGWWxHd4GisBicWzBE4kcvvr0RnoeVxgzLCbjz1dzeX8ShFCA@mail.gmail.com>
 <B92F3EF9-23EA-4C3F-8735-F8200465784A@yale.edu> <D1D1FF59-7D6B-4165-8082-9FC7D58FF048@yale.edu>
Message-ID: <CABDkGQkSSWyEHSJe616ZsaRvD+CEvKVp5FFnYTpaL89wMwTdQQ@mail.gmail.com>

On Tue, Dec 13, 2011 at 9:03 AM, Zachary Pincus <zachary.pincus at yale.edu> wrote:
> Also, can anyone explain decide the FreeImage Public License is compatible with skimage? Maybe it would be possible to provide some pre-built binary libraries for win/os x.
> http://freeimage.sourceforge.net/license.html

I think we should be fine.  The two relevant items are:

3.1. Application of License.
The Modifications which You create or to which You contribute are
governed by the terms of this License, including without limitation
Section 2.2. The Source Code version of Covered Code may be
distributed only under the terms of this License or a future version
of this License released under Section 6.1, and You must include a
copy of this License with every copy of the Source Code You
distribute. You may not offer or impose any terms on any Source Code
version that alters or
restricts the applicable version of this License or the recipients'
rights hereunder. However, You may include an additional document
offering the additional rights described in Section 3.5.

3.7. Larger Works.
You may create a Larger Work by combining Covered Code with other code
not governed by the terms of this License and distribute the Larger
Work as a single product. In such a case, You must make sure the
requirements of this License are fulfilled for the Covered Code.

We do not place any restrictions on the code, so I believe we are compliant.

St?fan


From thouis at gmail.com  Tue Dec 13 10:45:37 2011
From: thouis at gmail.com (Thouis (Ray) Jones)
Date: Tue, 13 Dec 2011 16:45:37 +0100
Subject: skeletonize question
In-Reply-To: <DE131EA3-C429-4AC3-AF99-C6CB54433EA4@yale.edu>
References: <b146676c-2d06-455e-8ce9-8d831efc36ca@e8g2000prb.googlegroups.com>
 <CABDkGQkjxyAKDsiS7_ji6HA0+kzSM-1=4gx6VAp0Kr-WBH1WdA@mail.gmail.com>
 <CAHGWWxFeFjKJDaoaoY+ZysYy2wgpjsW9R44J38XKnscS9tPmNA@mail.gmail.com> <DE131EA3-C429-4AC3-AF99-C6CB54433EA4@yale.edu>
Message-ID: <CAHGWWxHd4GisBicWzBE4kcvvr0RnoeVxgzLCbjz1dzeX8ShFCA@mail.gmail.com>

On Tue, Dec 13, 2011 at 16:09, Zachary Pincus <zachary.pincus at yale.edu> wrote:
> On Dec 13, 2011, at 5:23 AM, Thouis (Ray) Jones wrote:
>> Having fought this fight far too many times, I'm beginning to think
>> there's a need for a simple, small, and fast python module wrapping
>> libtiff, libpng, and libjpeg and talking to numpy. ?This would handle
>> 90% or more of everyone's needs and would hopefully be simpler to
>> install and use than PIL (and would have a faster development cycle).
>
> That's why I wrote that FreeImage backend... But maybe asking people to get libfreeimage (lightweight and dependency-free as it may be) is harder than ensuring they have libs tiff, png, and jpeg?

This is probably good enough.  I admit we never tried this option with
CellProfiler.

Your wrapper is read-only, right?  Any sense on how much work to make
it able to write some of these formats, as well?

Ray


From stefan at sun.ac.za  Tue Dec 13 21:38:12 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 13 Dec 2011 18:38:12 -0800
Subject: Travel
Message-ID: <CABDkGQmxmmLZY=HfO3_6APh4mM4mnXckd0fWfCFDVmwU2JxTqQ@mail.gmail.com>

Hi all,

I'll be traveling to South Africa over the next few days, so until I
arrive I won't have a good internet connection.  If any issues arise,
please ping Emmanuelle or Tony.

I look forward to an inbox full of PRs upon arrival :)

Cheers
St?fan


From tsyu80 at gmail.com  Thu Dec 15 21:02:03 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Thu, 15 Dec 2011 21:02:03 -0500
Subject: Add exposure module
Message-ID: <CAEym_HoABkHt5_E5yhX_2K+=AyGWOrn2idsBCrLk5zYovNdyog@mail.gmail.com>

As suggested in the feature requests for
0.5<http://groups.google.com/group/scikits-image/msg/ddda01a609f41fd5>,
I just added an exposure
module<https://github.com/scikits-image/scikits-image/pull/103>with
histogram equalization based on code by Jan
Erik Solem<http://www.janeriksolem.net/2009/06/histogram-equalization-with-python-and.html>(with
the author's permission).

Anyway, please look over the pull request. It's probably a lot more
complicated than it needs to (especially given the terse code that it was
derived from). I took some pains to return an image of the same type as the
input, and I added a histogram function which tries to figure out the
correct binning for image intensities (there's probably an established way
of doing this that I'm missing). Enjoy!

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

From tj.takei at gmail.com  Fri Dec 16 20:16:16 2011
From: tj.takei at gmail.com (karoyakani)
Date: Fri, 16 Dec 2011 17:16:16 -0800 (PST)
Subject: morphology.label() bug?
Message-ID: <ee7ee98f-4d0f-4785-9f29-5da9830f09b5@d5g2000prf.googlegroups.com>

Hi Group,

lable() of my skimage 0.4.2 generates a wierd label value "2" at the
bottom-right corner.

a = np.array([
    [0,1,1,0,0,0],
    [0,1,1,0,1,0],
    [0,0,0,1,1,1],
    [0,0,0,0,1,0]])

from skimage import morphology
morphology.label(a)

Out[]:
array([
 [0, 1, 1, 0, 0, 0],
       [0, 1, 1, 0, 1, 0],
       [0, 0, 0, 1, 1, 1],
       [0, 0, 0, 0, 1, 2]])

Is this a bug or a feature?
Documentation virtually tells nothing and no example.

In comparison, scipy.ndimage.label() looks behaving better in this
testcase.
It also allows an optional arg of 4-connected and 8-connected se and
it outputs the number of labels.
So I would say it appears more matured and useful to me.

I may be too new and know too little about the current status and the
roadmap in a big picture.

Regards,
TJ


From stefan at sun.ac.za  Sat Dec 17 02:50:01 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 16 Dec 2011 23:50:01 -0800
Subject: morphology.label() bug?
In-Reply-To: <ee7ee98f-4d0f-4785-9f29-5da9830f09b5@d5g2000prf.googlegroups.com>
References: <ee7ee98f-4d0f-4785-9f29-5da9830f09b5@d5g2000prf.googlegroups.com>
Message-ID: <CABDkGQkZUXP_95gCckY_86K2AL6F6UUUULb1xOgEN3_Uj7jXQQ@mail.gmail.com>

Hi TJ

On Fri, Dec 16, 2011 at 5:16 PM, karoyakani <tj.takei at gmail.com> wrote:
> lable() of my skimage 0.4.2 generates a wierd label value "2" at the
> bottom-right corner.
>
> a = np.array([
> ? ?[0,1,1,0,0,0],
> ? ?[0,1,1,0,1,0],
> ? ?[0,0,0,1,1,1],
> ? ?[0,0,0,0,1,0]])
>
> from skimage import morphology
> morphology.label(a)
>
> Out[]:
> array([
> ?[0, 1, 1, 0, 0, 0],
> ? ? ? [0, 1, 1, 0, 1, 0],
> ? ? ? [0, 0, 0, 1, 1, 1],
> ? ? ? [0, 0, 0, 0, 1, 2]])

This is the correct output, since the zero is not connected to any
other region.    In fact, ndimage labels it incorrectly as:

array([[0, 1, 1, 0, 0, 0],
       [0, 1, 1, 0, 1, 0],
       [0, 0, 0, 1, 1, 1],
       [0, 0, 0, 0, 1, 0]])

> Is this a bug or a feature?
> Documentation virtually tells nothing and no example.

It's a feature, but you are right that the documentation is sloppy!
I've made a pull request to add 4/8 connectivity and update the docs:

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

Regards
St?fan


From stefan at sun.ac.za  Sat Dec 17 06:27:39 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sat, 17 Dec 2011 03:27:39 -0800
Subject: morphology.label() bug?
In-Reply-To: <20111217111317.GC5521@phare.normalesup.org>
References: <ee7ee98f-4d0f-4785-9f29-5da9830f09b5@d5g2000prf.googlegroups.com>
 <CABDkGQkZUXP_95gCckY_86K2AL6F6UUUULb1xOgEN3_Uj7jXQQ@mail.gmail.com> <20111217111317.GC5521@phare.normalesup.org>
Message-ID: <CABDkGQ=5eJAd7r2ZjQ14_m34ng-WQBhGsYywU6jtw4V_BAOCgw@mail.gmail.com>

On Sat, Dec 17, 2011 at 3:13 AM, Emmanuelle Gouillart
<emmanuelle.gouillart at nsup.org> wrote:
>> > a = np.array([
>> > ? ?[0,1,1,0,0,0],
>> > ? ?[0,1,1,0,1,0],
>> > ? ?[0,0,0,1,1,1],
>> > ? ?[0,0,0,0,1,0]])
>
>> This is the correct output, since the zero is not connected to any
>> other region. ? ?In fact, ndimage labels it incorrectly as:
>
>> array([[0, 1, 1, 0, 0, 0],
>> ? ? ? ?[0, 1, 1, 0, 1, 0],
>> ? ? ? ?[0, 0, 0, 1, 1, 1],
>> ? ? ? ?[0, 0, 0, 0, 1, 0]])
>
> Well, this is not incorrect, since ndimage.label only labels connected
> components of the foreground (True pixels).

Right, so zero is a magical value.  I guess it's pretty easy to get
the same out of our implementation by simply masking out all
uninteresting values, and calling "unique" to get the remaining
labels?


From emmanuelle.gouillart at nsup.org  Sat Dec 17 06:13:17 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Sat, 17 Dec 2011 12:13:17 +0100
Subject: morphology.label() bug?
In-Reply-To: <CABDkGQkZUXP_95gCckY_86K2AL6F6UUUULb1xOgEN3_Uj7jXQQ@mail.gmail.com>
References: <ee7ee98f-4d0f-4785-9f29-5da9830f09b5@d5g2000prf.googlegroups.com>
 <CABDkGQkZUXP_95gCckY_86K2AL6F6UUUULb1xOgEN3_Uj7jXQQ@mail.gmail.com>
Message-ID: <20111217111317.GC5521@phare.normalesup.org>


> > a = np.array([
> > ?????? ??????[0,1,1,0,0,0],
> > ?????? ??????[0,1,1,0,1,0],
> > ?????? ??????[0,0,0,1,1,1],
> > ?????? ??????[0,0,0,0,1,0]])

> This is the correct output, since the zero is not connected to any
> other region.    In fact, ndimage labels it incorrectly as:

> array([[0, 1, 1, 0, 0, 0],
>        [0, 1, 1, 0, 1, 0],
>        [0, 0, 0, 1, 1, 1],
>        [0, 0, 0, 0, 1, 0]])

Well, this is not incorrect, since ndimage.label only labels connected
components of the foreground (True pixels). 

Emmanuelle


From stefan at sun.ac.za  Sat Dec 17 17:55:38 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sat, 17 Dec 2011 14:55:38 -0800
Subject: Video io, 'get' not working with OpenCv
In-Reply-To: <4EECBA62.8030005@netscape.net>
References: <4EECBA62.8030005@netscape.net>
Message-ID: <CABDkGQ=PMP-ZUDhsd9JoupjVMhOO0cjR2CvM4UgzNj+btf1ZAA@mail.gmail.com>

Hi Robbert

On Sat, Dec 17, 2011 at 7:50 AM, robbert <superslimme at netscape.net> wrote:
> I've wrote a little test program to a extract a frame of a video file (for
> processing), but I can't get it work.

Thanks for the report.  This works using GStreamer, so tomorrow I'll
compile OpenCV and determine what the problem is.

Regards
St?fan


From cjgohlke at gmail.com  Sat Dec 17 19:34:19 2011
From: cjgohlke at gmail.com (Christoph Gohlke)
Date: Sat, 17 Dec 2011 16:34:19 -0800
Subject: Video io, 'get' not working with OpenCv
In-Reply-To: <4EECBA62.8030005@netscape.net>
References: <4EECBA62.8030005@netscape.net>
Message-ID: <4EED350B.1020703@gmail.com>

I don't think skimage 0.4.2 works with OpenCv 2.3.1.  Video.py tries 
`import cv` but in OpenCv 2.3.1 the cv module was moved to cv2.cv. Try 
change `import cv` to `from cv2 import cv` in video.py.

Christoph


On 12/17/2011 7:50 AM, robbert wrote:
> Hi All,
>
> I've wrote a little test program to a extract a frame of a video file 
> (for processing), but I can't get it work.
> The video file is a compressed avi file, and can be played by the 
> camshift.py demo of OpenCv.
> So I think the OpenCv bindings for python are installed correctly.
>
> import skimage
> from skimage.io import Video
> vid = Video('c:\\test.avi')
> frame0 = vid.get()
>
> However the above test program gives the following error:
>
> Traceback (most recent call last):
>   File "C:\prog\skimage-test.py", line 8, in <module>
>     frame0 = vid.get()
>   File 
> "C:\Python\lib\site-packages\scikits_image-0.4.2-py2.6-win32.egg\skimage\io\video.py", 
> line 279, in get
>     return self.video.get()
>   File 
> "C:\Python\lib\site-packages\scikits_image-0.4.2-py2.6-win32.egg\skimage\io\video.py", 
> line 54, in get
>     cv.Copy(img, img_mat)
> TypeError: CvArr argument 'dst' must be IplImage, CvMat or CvMatND. 
> Use fromarray() to convert numpy arrays to CvMat or cvMatND
>
> I used the following versions of the software
> Python 2.6.4
> Numpy 1.6.1
> Scipy 0.9.0
> skimage 0.4.2
> OpenCv  2.3.1    (Rev: 4557)
> PyQt 4.6.2
> WinXp Sp3
>
> Am I doing something wrong? Or is there just a specific version of 
> OpenCv required?
> Note that OpenCv isn't on the (optional) requirements list.
>
> I also tried to install the alternative backend, gstreamer+python 
> bindings, but under windows this seems to be troublesome.
>
>
> kind regards,
>
> Robbert
>
>



From superslimme at netscape.net  Sat Dec 17 10:50:58 2011
From: superslimme at netscape.net (robbert)
Date: Sat, 17 Dec 2011 16:50:58 +0100
Subject: Video io, 'get' not working with OpenCv
Message-ID: <4EECBA62.8030005@netscape.net>

Hi All,

I've wrote a little test program to a extract a frame of a video file 
(for processing), but I can't get it work.
The video file is a compressed avi file, and can be played by the 
camshift.py demo of OpenCv.
So I think the OpenCv bindings for python are installed correctly.

import skimage
from skimage.io import Video
vid = Video('c:\\test.avi')
frame0 = vid.get()

However the above test program gives the following error:

Traceback (most recent call last):
   File "C:\prog\skimage-test.py", line 8, in <module>
     frame0 = vid.get()
   File 
"C:\Python\lib\site-packages\scikits_image-0.4.2-py2.6-win32.egg\skimage\io\video.py", 
line 279, in get
     return self.video.get()
   File 
"C:\Python\lib\site-packages\scikits_image-0.4.2-py2.6-win32.egg\skimage\io\video.py", 
line 54, in get
     cv.Copy(img, img_mat)
TypeError: CvArr argument 'dst' must be IplImage, CvMat or CvMatND. Use 
fromarray() to convert numpy arrays to CvMat or cvMatND

I used the following versions of the software
Python 2.6.4
Numpy 1.6.1
Scipy 0.9.0
skimage 0.4.2
OpenCv  2.3.1    (Rev: 4557)
PyQt 4.6.2
WinXp Sp3

Am I doing something wrong? Or is there just a specific version of 
OpenCv required?
Note that OpenCv isn't on the (optional) requirements list.

I also tried to install the alternative backend, gstreamer+python 
bindings, but under windows this seems to be troublesome.


kind regards,

Robbert



From tj.takei at gmail.com  Sat Dec 17 22:36:17 2011
From: tj.takei at gmail.com (karoyakani)
Date: Sat, 17 Dec 2011 19:36:17 -0800 (PST)
Subject: morphology.label() bug?
In-Reply-To: <CABDkGQ=5eJAd7r2ZjQ14_m34ng-WQBhGsYywU6jtw4V_BAOCgw@mail.gmail.com>
References: <ee7ee98f-4d0f-4785-9f29-5da9830f09b5@d5g2000prf.googlegroups.com>
 <CABDkGQkZUXP_95gCckY_86K2AL6F6UUUULb1xOgEN3_Uj7jXQQ@mail.gmail.com>
 <20111217111317.GC5521@phare.normalesup.org> <CABDkGQ=5eJAd7r2ZjQ14_m34ng-WQBhGsYywU6jtw4V_BAOCgw@mail.gmail.com>
Message-ID: <47f58493-b9b2-4909-8af7-e4b89779f0c9@f11g2000yql.googlegroups.com>



On Dec 17, 3:27?am, St?fan van der Walt <ste... at sun.ac.za> wrote:
> On Sat, Dec 17, 2011 at 3:13 AM, Emmanuelle Gouillart
>
> <emmanuelle.gouill... at nsup.org> wrote:
> >> > a = np.array([
> >> > ? ?[0,1,1,0,0,0],
> >> > ? ?[0,1,1,0,1,0],
> >> > ? ?[0,0,0,1,1,1],
> >> > ? ?[0,0,0,0,1,0]])
>
> >> This is the correct output, since the zero is not connected to any
> >> other region. ? ?In fact, ndimage labels it incorrectly as:
>
> >> array([[0, 1, 1, 0, 0, 0],
> >> ? ? ? ?[0, 1, 1, 0, 1, 0],
> >> ? ? ? ?[0, 0, 0, 1, 1, 1],
> >> ? ? ? ?[0, 0, 0, 0, 1, 0]])
>
> > Well, this is not incorrect, since ndimage.label only labels connected
> > components of the foreground (True pixels).
>
> Right, so zero is a magical value. ?I guess it's pretty easy to get
> the same out of our implementation by simply masking out all
> uninteresting values, and calling "unique" to get the remaining
> labels?

It's very useful and common that we assume Background:="0"-value
pixels.
ndimage and matlab do so.
I don't know why skimage doesn't.

Regarding connectedness, both matlab and ndimage have options of 8-
connect and 4-connect.
Meantime skimage has only 8-connect.
Why don't we add 4-connect as an option?

Regarding number of labeled regions (not counting the background
regions), again matlab and ndimage compute and return it.
Why don't we add it to the skimage, as it would be very useful to
users?
I suspect the reason why the skimage doesn't is because it currently
has a vague notion on the background regions, isn't it?

Regards,
TJ




From cjgohlke at gmail.com  Sun Dec 18 02:21:27 2011
From: cjgohlke at gmail.com (Christoph Gohlke)
Date: Sat, 17 Dec 2011 23:21:27 -0800
Subject: Video io, 'get' not working with OpenCv
In-Reply-To: <4EED350B.1020703@gmail.com>
References: <4EECBA62.8030005@netscape.net> <4EED350B.1020703@gmail.com>
Message-ID: <4EED9477.3070708@gmail.com>

Correction: OpenCV 2.3.1 provides a compatibility module, cv.py, which 
does `from cv2.cv import *`. So this is not the problem.

Christoph


On 12/17/2011 4:34 PM, Christoph Gohlke wrote:
> I don't think skimage 0.4.2 works with OpenCv 2.3.1.  Video.py tries 
> `import cv` but in OpenCv 2.3.1 the cv module was moved to cv2.cv. Try 
> change `import cv` to `from cv2 import cv` in video.py.
>
> Christoph
>
>
> On 12/17/2011 7:50 AM, robbert wrote:
>> Hi All,
>>
>> I've wrote a little test program to a extract a frame of a video file 
>> (for processing), but I can't get it work.
>> The video file is a compressed avi file, and can be played by the 
>> camshift.py demo of OpenCv.
>> So I think the OpenCv bindings for python are installed correctly.
>>
>> import skimage
>> from skimage.io import Video
>> vid = Video('c:\\test.avi')
>> frame0 = vid.get()
>>
>> However the above test program gives the following error:
>>
>> Traceback (most recent call last):
>>   File "C:\prog\skimage-test.py", line 8, in <module>
>>     frame0 = vid.get()
>>   File 
>> "C:\Python\lib\site-packages\scikits_image-0.4.2-py2.6-win32.egg\skimage\io\video.py", 
>> line 279, in get
>>     return self.video.get()
>>   File 
>> "C:\Python\lib\site-packages\scikits_image-0.4.2-py2.6-win32.egg\skimage\io\video.py", 
>> line 54, in get
>>     cv.Copy(img, img_mat)
>> TypeError: CvArr argument 'dst' must be IplImage, CvMat or CvMatND. 
>> Use fromarray() to convert numpy arrays to CvMat or cvMatND
>>
>> I used the following versions of the software
>> Python 2.6.4
>> Numpy 1.6.1
>> Scipy 0.9.0
>> skimage 0.4.2
>> OpenCv  2.3.1    (Rev: 4557)
>> PyQt 4.6.2
>> WinXp Sp3
>>
>> Am I doing something wrong? Or is there just a specific version of 
>> OpenCv required?
>> Note that OpenCv isn't on the (optional) requirements list.
>>
>> I also tried to install the alternative backend, gstreamer+python 
>> bindings, but under windows this seems to be troublesome.
>>
>>
>> kind regards,
>>
>> Robbert
>>
>>
>



From stefan at sun.ac.za  Tue Dec 20 03:19:49 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 20 Dec 2011 00:19:49 -0800
Subject: A bug in skimage.io
In-Reply-To: <CA+oBP_vW-ffaGBnw933a5x1_FRAOK56b1deGsLjrL1++xCGuZw@mail.gmail.com>
References: <CA+oBP_vW-ffaGBnw933a5x1_FRAOK56b1deGsLjrL1++xCGuZw@mail.gmail.com>
Message-ID: <CABDkGQkQ9OJwwWy+5mMJrQO4QrN3jdd+JbigpxQQ7E5jafasww@mail.gmail.com>

On Mon, Dec 19, 2011 at 11:00 PM, Nadav Horesh <nadavh.horesh at gmail.com> wrote:
> the for loop should be changed to
>
> ?for i in range(len(self.chunks)):

Good catch, thanks Nadav.  Please verify that I made the correct change:

https://github.com/scikits-image/scikits-image/commit/4df36631f64285b88bdfd044a64a34547b152b17

Cheers
St?fan


From stefan at sun.ac.za  Tue Dec 20 11:31:55 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 20 Dec 2011 08:31:55 -0800
Subject: New Doodle poll: "Scientific Python packages: Popularity check" (fwd)
In-Reply-To: <20111220121056.GA13610@phare.normalesup.org>
References: <20111220121056.GA13610@phare.normalesup.org>
Message-ID: <CABDkGQn9veLynKOCGnJE1XouFzSLyizFyQGOuQ+xQy3Kd2H_RA@mail.gmail.com>

----- Forwarded message from Pierre Raybaut <> -----

Date: Tue, 20 Dec 2011 11:17:50 +0100
Subject: [SciPy-User] New Doodle poll: "Scientific Python packages:
Popularity check"

Hi all,

Three years ago (day for day... that's weird!), I made a Doodle poll
for estimating ~scientific Python packages popularity.

Things have changed since then and I propose a new poll here:
http://www.doodle.com/rzssq2dbnus4a34r

This poll is intended to identify the most popular scientific Python
packages to be included in the Python(x,y) distribution. However, even
if the package list is *not* exhaustive, I'm sure that people who are
not interested in Python(x,y) will find the poll results interesting
anyway.

Thank you for your participation, and please spread the word!

-Pierre


From stefan at sun.ac.za  Tue Dec 20 11:32:33 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 20 Dec 2011 08:32:33 -0800
Subject: New Doodle poll: "Scientific Python packages: Popularity check" (fwd)
In-Reply-To: <CABDkGQn9veLynKOCGnJE1XouFzSLyizFyQGOuQ+xQy3Kd2H_RA@mail.gmail.com>
References: <20111220121056.GA13610@phare.normalesup.org> <CABDkGQn9veLynKOCGnJE1XouFzSLyizFyQGOuQ+xQy3Kd2H_RA@mail.gmail.com>
Message-ID: <CABDkGQkbUKco2ubgvmxJYv_VFyazzGEZi0FrKWzTD28g5FcpMQ@mail.gmail.com>

Oops, sorry about the double posting.  I didn't see Emmanuelle had
already forwarded it!

2011/12/20 St?fan van der Walt <stefan at sun.ac.za>:
> ----- Forwarded message from Pierre Raybaut <> -----
>
> Date: Tue, 20 Dec 2011 11:17:50 +0100
> Subject: [SciPy-User] New Doodle poll: "Scientific Python packages:
> Popularity check"
>
> Hi all,
>
> Three years ago (day for day... that's weird!), I made a Doodle poll
> for estimating ~scientific Python packages popularity.
>
> Things have changed since then and I propose a new poll here:
> http://www.doodle.com/rzssq2dbnus4a34r
>
> This poll is intended to identify the most popular scientific Python
> packages to be included in the Python(x,y) distribution. However, even
> if the package list is *not* exhaustive, I'm sure that people who are
> not interested in Python(x,y) will find the poll results interesting
> anyway.
>
> Thank you for your participation, and please spread the word!
>
> -Pierre


From nadavh.horesh at gmail.com  Tue Dec 20 02:00:42 2011
From: nadavh.horesh at gmail.com (Nadav Horesh)
Date: Tue, 20 Dec 2011 09:00:42 +0200
Subject: A bug in skimage.io
Message-ID: <CA+oBP_vW-ffaGBnw933a5x1_FRAOK56b1deGsLjrL1++xCGuZw@mail.gmail.com>

In the file
skimage/io/_plugins/util.py

line 215

the for loop should be changed to

 for i in range(len(self.chunks)):


this change let it work on my PC (linux, 4 real core + 4 virtual (with
hyperthreading)),
since there there self.cores == 8 and len(self(chunks)) == 4

  Nadav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111220/56cbbe5c/attachment.html>

From emmanuelle.gouillart at nsup.org  Tue Dec 20 07:14:06 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Tue, 20 Dec 2011 13:14:06 +0100
Subject: [SciPy-User] New Doodle poll: "Scientific Python packages:
 Popularity check" (fwd)
Message-ID: <20111220121406.GA12951@phare.normalesup.org>

----- Forwarded message from Pierre Raybaut <pierre.raybaut at gmail.com> -----

Date: Tue, 20 Dec 2011 11:17:50 +0100
From: Pierre Raybaut <pierre.raybaut at gmail.com>
To: pythonxy at googlegroups.com, scipy-user <scipy-user at scipy.org>
Subject: [SciPy-User] New Doodle poll: "Scientific Python packages:
	Popularity check"
Reply-To: SciPy Users List <scipy-user at scipy.org>

Hi all,

Three years ago (day for day... that's weird!), I made a Doodle poll
for estimating ~scientific Python packages popularity.

Things have changed since then and I propose a new poll here:
http://www.doodle.com/rzssq2dbnus4a34r

This poll is intended to identify the most popular scientific Python
packages to be included in the Python(x,y) distribution. However, even
if the package list is *not* exhaustive, I'm sure that people who are
not interested in Python(x,y) will find the poll results interesting
anyway.

Thank you for your participation, and please spread the word!

-Pierre
_______________________________________________
SciPy-User mailing list
SciPy-User at scipy.org
http://mail.scipy.org/mailman/listinfo/scipy-user

----- End forwarded message -----


From tsyu80 at gmail.com  Wed Dec 21 04:30:46 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Wed, 21 Dec 2011 01:30:46 -0800
Subject: Asymmetric behavior in dtype conversion
Message-ID: <CAEym_HrBuqLrM6kwfxcCWUqB1arDa-Qu8hvfj31CTH5pUhtPGA@mail.gmail.com>

I noticed that---when converting unsigned integers to (signed)
integers---the values of the uint are simply scaled to fit into the
positive range of the int array. On the other hand, when converting from
int to uint, the *full range* (i.e. negative and positive) values of the
int array get scaled to fit into the uint. The result is asymmetric, and it
can lead to drift when converting between types; e.g.:

#~~~
In [55]: skimage.img_as_ubyte(skimage.img_as_int(np.uint8([0])))
WARNING:dtype_converter:Possible sign loss when converting negative image
of type int16 to positive image of type uint8.
WARNING:dtype_converter:Possible precision loss when converting from int16
to uint8
Out[55]: array([128], dtype=uint8)
#~~~

I think one of two things should happen:

1)
    [uint -> int]: expand uint to *full* range of int.
    [int -> uint]: unchanged (squeeze into range of uint)

2)
    [uint -> int]: unchanged (fill *positive* range of int)
    [int -> uint]: clip negative values from int

Thoughts?
-Tony

P.S. This change would either have to wait for PR
99<https://github.com/scikits-image/scikits-image/pull/99>,
or it could be integrated into that pull request. (I haven't yet looked at
what it would take to make this change.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111221/7e26ff64/attachment.html>

From cjgohlke at gmail.com  Wed Dec 21 10:03:40 2011
From: cjgohlke at gmail.com (Christoph Gohlke)
Date: Wed, 21 Dec 2011 07:03:40 -0800
Subject: Asymmetric behavior in dtype conversion
In-Reply-To: <CAEym_HrBuqLrM6kwfxcCWUqB1arDa-Qu8hvfj31CTH5pUhtPGA@mail.gmail.com>
References: <CAEym_HrBuqLrM6kwfxcCWUqB1arDa-Qu8hvfj31CTH5pUhtPGA@mail.gmail.com>
Message-ID: <4EF1F54C.5030906@gmail.com>

On 12/21/2011 1:30 AM, Tony Yu wrote:
> I noticed that---when converting unsigned integers to (signed) 
> integers---the values of the uint are simply scaled to fit into the 
> positive range of the int array. On the other hand, when converting 
> from int to uint, the *full range* (i.e. negative and positive) values 
> of the int array get scaled to fit into the uint. The result is 
> asymmetric, and it can lead to drift when converting between types; e.g.:
>
> #~~~
> In [55]: skimage.img_as_ubyte(skimage.img_as_int(np.uint8([0])))
> WARNING:dtype_converter:Possible sign loss when converting negative 
> image of type int16 to positive image of type uint8.
> WARNING:dtype_converter:Possible precision loss when converting from 
> int16 to uint8
> Out[55]: array([128], dtype=uint8)
> #~~~
>
> I think one of two things should happen:
>
> 1)
>     [uint -> int]: expand uint to *full* range of int.
>     [int -> uint]: unchanged (squeeze into range of uint)
>
> 2)
>     [uint -> int]: unchanged (fill *positive* range of int)
>     [int -> uint]: clip negative values from int
>
> Thoughts?
> -Tony
>
> P.S. This change would either have to wait for PR 99 
> <https://github.com/scikits-image/scikits-image/pull/99>, or it could 
> be integrated into that pull request. (I haven't yet looked at what it 
> would take to make this change.)

My original implementation of PR99 had 1) implemented but skimage tests 
failed.

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

From nadavh.horesh at gmail.com  Wed Dec 21 01:09:06 2011
From: nadavh.horesh at gmail.com (Nadav Horesh)
Date: Wed, 21 Dec 2011 08:09:06 +0200
Subject: A bug in skimage.io
In-Reply-To: <CABDkGQkQ9OJwwWy+5mMJrQO4QrN3jdd+JbigpxQQ7E5jafasww@mail.gmail.com>
References: <CA+oBP_vW-ffaGBnw933a5x1_FRAOK56b1deGsLjrL1++xCGuZw@mail.gmail.com>
	<CABDkGQkQ9OJwwWy+5mMJrQO4QrN3jdd+JbigpxQQ7E5jafasww@mail.gmail.com>
Message-ID: <CA+oBP_tKrjok3G1FwBhuQ6aUCUTCUdojDsGzr4cAK2Jwbjij=w@mail.gmail.com>

That is it.

  Nadav

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

> On Mon, Dec 19, 2011 at 11:00 PM, Nadav Horesh <nadavh.horesh at gmail.com>
> wrote:
> > the for loop should be changed to
> >
> >  for i in range(len(self.chunks)):
>
> Good catch, thanks Nadav.  Please verify that I made the correct change:
>
>
> https://github.com/scikits-image/scikits-image/commit/4df36631f64285b88bdfd044a64a34547b152b17
>
> Cheers
> St?fan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111221/1c07d392/attachment.html>

From stefan at sun.ac.za  Wed Dec 21 11:41:17 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 21 Dec 2011 08:41:17 -0800
Subject: Asymmetric behavior in dtype conversion
In-Reply-To: <CAEym_HrBuqLrM6kwfxcCWUqB1arDa-Qu8hvfj31CTH5pUhtPGA@mail.gmail.com>
References: <CAEym_HrBuqLrM6kwfxcCWUqB1arDa-Qu8hvfj31CTH5pUhtPGA@mail.gmail.com>
Message-ID: <CABDkGQnpajPQC93yhDoFomZ20JV57S+o17wy7Sys0XFUWw1sXA@mail.gmail.com>

On Wed, Dec 21, 2011 at 1:30 AM, Tony Yu <tsyu80 at gmail.com> wrote:
> I think one of two things should happen:
>
> 1)
> ??? [uint -> int]: expand uint to *full* range of int.
> ??? [int -> uint]: unchanged (squeeze into range of uint)
>
> 2)
> ??? [uint -> int]: unchanged (fill *positive* range of int)
> ??? [int -> uint]: clip negative values from int

People very often represent images in signed integers, even though
they only manipulate positive values, e.g. storing 0-255 in int8.  So
the conversion to signed should not spread those values over the
entire range.  However, I think you're right that we should add the
clipping in 2 to avoid the conversion bias, along with a nice big
warning.

Regards
St?fan


From cjgohlke at gmail.com  Wed Dec 21 12:15:50 2011
From: cjgohlke at gmail.com (Christoph Gohlke)
Date: Wed, 21 Dec 2011 09:15:50 -0800
Subject: Asymmetric behavior in dtype conversion
In-Reply-To: <CABDkGQnpajPQC93yhDoFomZ20JV57S+o17wy7Sys0XFUWw1sXA@mail.gmail.com>
References: <CAEym_HrBuqLrM6kwfxcCWUqB1arDa-Qu8hvfj31CTH5pUhtPGA@mail.gmail.com> <CABDkGQnpajPQC93yhDoFomZ20JV57S+o17wy7Sys0XFUWw1sXA@mail.gmail.com>
Message-ID: <4EF21446.7070100@gmail.com>

On 12/21/2011 8:41 AM, St??????fan van der Walt wrote:
> On Wed, Dec 21, 2011 at 1:30 AM, Tony Yu<tsyu80 at gmail.com>  wrote:
>> I think one of two things should happen:
>>
>> 1)
>>      [uint ->  int]: expand uint to *full* range of int.
>>      [int ->  uint]: unchanged (squeeze into range of uint)
>>
>> 2)
>>      [uint ->  int]: unchanged (fill *positive* range of int)
>>      [int ->  uint]: clip negative values from int
> People very often represent images in signed integers, even though
> they only manipulate positive values, e.g. storing 0-255 in int8.  So
> the conversion to signed should not spread those values over the
> entire range.  However, I think you're right that we should add the
> clipping in 2 to avoid the conversion bias, along with a nice big
> warning.
>
> Regards
> St??????fan
>

At this point it might be worth considering other cases that are 
currently not well handled by skimage dtype conversions. For example:

1) float images in the range 0.0 - 255.0
2) 1 bit images stored as (u)int
3) 10 and 12 bit images stored as uint16

Christoph


From tsyu80 at gmail.com  Wed Dec 21 14:16:34 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Wed, 21 Dec 2011 11:16:34 -0800
Subject: Asymmetric behavior in dtype conversion
In-Reply-To: <4EF21446.7070100@gmail.com>
References: <CAEym_HrBuqLrM6kwfxcCWUqB1arDa-Qu8hvfj31CTH5pUhtPGA@mail.gmail.com>
	<CABDkGQnpajPQC93yhDoFomZ20JV57S+o17wy7Sys0XFUWw1sXA@mail.gmail.com>
	<4EF21446.7070100@gmail.com>
Message-ID: <CAEym_Ho=2Qi8snYPvYFQdphUmwRMmmL4nzsDanhFJUX0vwaNWQ@mail.gmail.com>

On Wed, Dec 21, 2011 at 9:15 AM, Christoph Gohlke <cjgohlke at gmail.com>wrote:

> On 12/21/2011 8:41 AM, St?fan van der Walt wrote:
>
>> On Wed, Dec 21, 2011 at 1:30 AM, Tony Yu<tsyu80 at gmail.com>  wrote:
>>
>>> I think one of two things should happen:
>>>
>>> 1)
>>>     [uint ->  int]: expand uint to *full* range of int.
>>>     [int ->  uint]: unchanged (squeeze into range of uint)
>>>
>>> 2)
>>>     [uint ->  int]: unchanged (fill *positive* range of int)
>>>     [int ->  uint]: clip negative values from int
>>>
>> People very often represent images in signed integers, even though
>> they only manipulate positive values, e.g. storing 0-255 in int8.  So
>> the conversion to signed should not spread those values over the
>> entire range.  However, I think you're right that we should add the
>> clipping in 2 to avoid the conversion bias, along with a nice big
>> warning.
>>
>> Regards
>> St?fan
>>
>>
> At this point it might be worth considering other cases that are currently
> not well handled by skimage dtype conversions. For example:
>
> 1) float images in the range 0.0 - 255.0
> 2) 1 bit images stored as (u)int
> 3) 10 and 12 bit images stored as uint16
>
> Christoph
>

I've definitely been bit by example 1 many times.

I think we should check that float images are between 0 and 1 in
``util.dtype._convert`` (and either warn or raise an error), but we
shouldn't have to worry about it elsewhere. That doesn't really solve the
issue, so...

Presumably, the user would know that their data is in a slightly weird
format (especially for examples 2 and 3), correct? If so, we could just add
a function (maybe "rescale_intensity" or "stretch_intensity" or
"normalize_intensity" or something similar) that takes the image and the
input intensity range as inputs. For example: ``norm_intensity(image_u12,
(0, 4096))``. Then, we could rescale the intensity to fit into the
intensity range of the input dtype. We could also add special values [e.g.
1) 'uint8', 2) 'bool', 3) 'uint10'/'uint12'] for the second parameter, and
these values could pull the associated range from a table.

Then, it would be the responsibility of the user to call this function
before converting dtypes.

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

From tsyu80 at gmail.com  Wed Dec 21 15:36:45 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Wed, 21 Dec 2011 12:36:45 -0800
Subject: morphology.label() bug?
In-Reply-To: <47f58493-b9b2-4909-8af7-e4b89779f0c9@f11g2000yql.googlegroups.com>
References: <ee7ee98f-4d0f-4785-9f29-5da9830f09b5@d5g2000prf.googlegroups.com>
	<CABDkGQkZUXP_95gCckY_86K2AL6F6UUUULb1xOgEN3_Uj7jXQQ@mail.gmail.com>
	<20111217111317.GC5521@phare.normalesup.org>
	<CABDkGQ=5eJAd7r2ZjQ14_m34ng-WQBhGsYywU6jtw4V_BAOCgw@mail.gmail.com>
	<47f58493-b9b2-4909-8af7-e4b89779f0c9@f11g2000yql.googlegroups.com>
Message-ID: <CAEym_HqWuh3yZhyX-afuQmGVgoXuhuMSD5+hFtndAhqfgzctYA@mail.gmail.com>

On Sat, Dec 17, 2011 at 7:36 PM, karoyakani <tj.takei at gmail.com> wrote:

>
>
> On Dec 17, 3:27 am, St?fan van der Walt <ste... at sun.ac.za> wrote:
> > On Sat, Dec 17, 2011 at 3:13 AM, Emmanuelle Gouillart
> >
> > <emmanuelle.gouill... at nsup.org> wrote:
> > >> > a = np.array([
> > >> >    [0,1,1,0,0,0],
> > >> >    [0,1,1,0,1,0],
> > >> >    [0,0,0,1,1,1],
> > >> >    [0,0,0,0,1,0]])
> >
> > >> This is the correct output, since the zero is not connected to any
> > >> other region.    In fact, ndimage labels it incorrectly as:
> >
> > >> array([[0, 1, 1, 0, 0, 0],
> > >>        [0, 1, 1, 0, 1, 0],
> > >>        [0, 0, 0, 1, 1, 1],
> > >>        [0, 0, 0, 0, 1, 0]])
> >
> > > Well, this is not incorrect, since ndimage.label only labels connected
> > > components of the foreground (True pixels).
> >
> > Right, so zero is a magical value.  I guess it's pretty easy to get
> > the same out of our implementation by simply masking out all
> > uninteresting values, and calling "unique" to get the remaining
> > labels?
>
> It's very useful and common that we assume Background:="0"-value
> pixels.
> ndimage and matlab do so.
> I don't know why skimage doesn't.
>
> Regarding connectedness, both matlab and ndimage have options of 8-
> connect and 4-connect.
> Meantime skimage has only 8-connect.
> Why don't we add 4-connect as an option?
>
> Regarding number of labeled regions (not counting the background
> regions), again matlab and ndimage compute and return it.
> Why don't we add it to the skimage, as it would be very useful to
> users?
>

Actually, I've always found the return values for `ndimage.label` to be
surprising. Every time I use it, I expect to just get the labeled array.
Isn't the number of labeled regions equal to the max value of the labeled
array?

-Tony


> I suspect the reason why the skimage doesn't is because it currently
> has a vague notion on the background regions, isn't it?
>
> Regards,
> TJ
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111221/74bccd55/attachment.html>

From stefan at sun.ac.za  Wed Dec 21 17:02:20 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 21 Dec 2011 14:02:20 -0800
Subject: morphology.label() bug?
In-Reply-To: <47f58493-b9b2-4909-8af7-e4b89779f0c9@f11g2000yql.googlegroups.com>
References: <ee7ee98f-4d0f-4785-9f29-5da9830f09b5@d5g2000prf.googlegroups.com>
 <CABDkGQkZUXP_95gCckY_86K2AL6F6UUUULb1xOgEN3_Uj7jXQQ@mail.gmail.com>
 <20111217111317.GC5521@phare.normalesup.org> <CABDkGQ=5eJAd7r2ZjQ14_m34ng-WQBhGsYywU6jtw4V_BAOCgw@mail.gmail.com>
 <47f58493-b9b2-4909-8af7-e4b89779f0c9@f11g2000yql.googlegroups.com>
Message-ID: <CABDkGQ=i8A_B37J=1cWymQowNM5Fts4Knm1AfAz+Tpe2mNQckw@mail.gmail.com>

On Sat, Dec 17, 2011 at 7:36 PM, karoyakani <tj.takei at gmail.com> wrote:
> It's very useful and common that we assume Background:="0"-value
> pixels.
> ndimage and matlab do so.
> I don't know why skimage doesn't.

I don't like having background == 0, but I'll settle for background ==
-1 as a default.

> Regarding connectedness, both matlab and ndimage have options of 8-
> connect and 4-connect.
> Meantime skimage has only 8-connect.
> Why don't we add 4-connect as an option?

That's been added in the patch I proposed.

> Regarding number of labeled regions (not counting the background
> regions), again matlab and ndimage compute and return it.
> Why don't we add it to the skimage, as it would be very useful to
> users?

This is a one-liner: len(np.unique(labels))

Cheers
St?fan


From stefan at sun.ac.za  Wed Dec 21 17:06:48 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 21 Dec 2011 14:06:48 -0800
Subject: Asymmetric behavior in dtype conversion
In-Reply-To: <CAEym_Ho=2Qi8snYPvYFQdphUmwRMmmL4nzsDanhFJUX0vwaNWQ@mail.gmail.com>
References: <CAEym_HrBuqLrM6kwfxcCWUqB1arDa-Qu8hvfj31CTH5pUhtPGA@mail.gmail.com>
 <CABDkGQnpajPQC93yhDoFomZ20JV57S+o17wy7Sys0XFUWw1sXA@mail.gmail.com>
 <4EF21446.7070100@gmail.com> <CAEym_Ho=2Qi8snYPvYFQdphUmwRMmmL4nzsDanhFJUX0vwaNWQ@mail.gmail.com>
Message-ID: <CABDkGQkeLTAs5rB31Hf2Lap5oF076qbP-LLBDqxoS8FM4_Q1aA@mail.gmail.com>

On Wed, Dec 21, 2011 at 11:16 AM, Tony Yu <tsyu80 at gmail.com> wrote:
> I've definitely been bit by example 1 many times.
>
> I think we should check that float images are between 0 and 1 in
> ``util.dtype._convert`` (and either warn or raise an error), but we
> shouldn't have to worry about it elsewhere. That doesn't really solve the
> issue, so...

This check is cheap enough that we should just add it (it may save
more time than it costs in the end).  The rest of the examples are
fairly unusual, and since there's no way to automatically detect those
situations, we'll just expect the users to correctly scale their data
before using it (I am not opposed to adding utility functions for that
purpose, though).

St?fan


From tj.takei at gmail.com  Thu Dec 22 01:39:21 2011
From: tj.takei at gmail.com (karoyakani)
Date: Wed, 21 Dec 2011 22:39:21 -0800 (PST)
Subject: morphology.label() bug?
In-Reply-To: <CABDkGQ=i8A_B37J=1cWymQowNM5Fts4Knm1AfAz+Tpe2mNQckw@mail.gmail.com>
References: <ee7ee98f-4d0f-4785-9f29-5da9830f09b5@d5g2000prf.googlegroups.com>
 <CABDkGQkZUXP_95gCckY_86K2AL6F6UUUULb1xOgEN3_Uj7jXQQ@mail.gmail.com>
 <20111217111317.GC5521@phare.normalesup.org> <CABDkGQ=5eJAd7r2ZjQ14_m34ng-WQBhGsYywU6jtw4V_BAOCgw@mail.gmail.com>
 <47f58493-b9b2-4909-8af7-e4b89779f0c9@f11g2000yql.googlegroups.com> <CABDkGQ=i8A_B37J=1cWymQowNM5Fts4Knm1AfAz+Tpe2mNQckw@mail.gmail.com>
Message-ID: <78d107c3-be4a-403b-b17e-57f316b8c167@b20g2000pro.googlegroups.com>

On Dec 21, 2:02?pm, St?fan van der Walt <ste... at sun.ac.za> wrote:
...
> I don't like having background == 0, but I'll settle for background ==
> -1 as a default.

Thanks!


> > Regarding connectedness, both matlab and ndimage have options of 8-
> > connect and 4-connect.
...
>
> That's been added in the patch I proposed.

Thanks!!


> > Regarding number of labeled regions (not counting the background
> > regions), again matlab and ndimage compute and return it.
...
>
> This is a one-liner: len(np.unique(labels))

Or, len(np.unique(labels)) - 1, if we do not count the background in.
I tend to think that is a norm when we consider the background
special.
Yet who cares if the output does not include the number of regions.

Regards,
TJ


From stefan at sun.ac.za  Thu Dec 22 05:57:47 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 22 Dec 2011 02:57:47 -0800
Subject: Video io, 'get' not working with OpenCv
In-Reply-To: <CAOA5xCzW+aak7JJB07j5-UWkgK=9k3Y5KbF7o_=urr1uy9LUKA@mail.gmail.com>
References: <4EECBA62.8030005@netscape.net> <CABDkGQ=PMP-ZUDhsd9JoupjVMhOO0cjR2CvM4UgzNj+btf1ZAA@mail.gmail.com>
 <4EF2EF9F.9000905@netscape.net> <CAOA5xCwk+wiWNNxBp7pg7drrA_DhCama7wKkXXsoYrwFDgxX0Q@mail.gmail.com>
 <CAOA5xCzW+aak7JJB07j5-UWkgK=9k3Y5KbF7o_=urr1uy9LUKA@mail.gmail.com>
Message-ID: <CABDkGQ=kaHVuaPtn+rBAT5otx9umijsEQ+YLdZOXUtwhyyB2=w@mail.gmail.com>

Hi Pieter

On Thu, Dec 22, 2011 at 2:40 AM, Pieter Holtzhausen <holtzhau at gmail.com> wrote:
> Seems like the python bindings disabled that functionality
> https://code.ros.org/trac/opencv/changeset/6358

Could you perhaps put together a PR to address this issue?  That'd be
much appreciated.

St?fan


From stefan at sun.ac.za  Thu Dec 22 06:07:01 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 22 Dec 2011 03:07:01 -0800
Subject: morphology.label() bug?
In-Reply-To: <CAEym_HqWuh3yZhyX-afuQmGVgoXuhuMSD5+hFtndAhqfgzctYA@mail.gmail.com>
References: <ee7ee98f-4d0f-4785-9f29-5da9830f09b5@d5g2000prf.googlegroups.com>
 <CABDkGQkZUXP_95gCckY_86K2AL6F6UUUULb1xOgEN3_Uj7jXQQ@mail.gmail.com>
 <20111217111317.GC5521@phare.normalesup.org> <CABDkGQ=5eJAd7r2ZjQ14_m34ng-WQBhGsYywU6jtw4V_BAOCgw@mail.gmail.com>
 <47f58493-b9b2-4909-8af7-e4b89779f0c9@f11g2000yql.googlegroups.com> <CAEym_HqWuh3yZhyX-afuQmGVgoXuhuMSD5+hFtndAhqfgzctYA@mail.gmail.com>
Message-ID: <CABDkGQnVY=mn3MOdJJRr1k4WxOyQF6j9v3uCBV1FKx3zb_Nz=Q@mail.gmail.com>

On Wed, Dec 21, 2011 at 12:36 PM, Tony Yu <tsyu80 at gmail.com> wrote:
> Actually, I've always found the return values for `ndimage.label` to be
> surprising. Every time I use it, I expect to just get the labeled array.
> Isn't the number of labeled regions equal to the max value of the labeled
> array?

That's correct.

Cheers
St?fan


From stefan at sun.ac.za  Thu Dec 22 07:49:58 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 22 Dec 2011 04:49:58 -0800
Subject: morphology.label() bug?
In-Reply-To: <78d107c3-be4a-403b-b17e-57f316b8c167@b20g2000pro.googlegroups.com>
References: <ee7ee98f-4d0f-4785-9f29-5da9830f09b5@d5g2000prf.googlegroups.com>
 <CABDkGQkZUXP_95gCckY_86K2AL6F6UUUULb1xOgEN3_Uj7jXQQ@mail.gmail.com>
 <20111217111317.GC5521@phare.normalesup.org> <CABDkGQ=5eJAd7r2ZjQ14_m34ng-WQBhGsYywU6jtw4V_BAOCgw@mail.gmail.com>
 <47f58493-b9b2-4909-8af7-e4b89779f0c9@f11g2000yql.googlegroups.com>
 <CABDkGQ=i8A_B37J=1cWymQowNM5Fts4Knm1AfAz+Tpe2mNQckw@mail.gmail.com> <78d107c3-be4a-403b-b17e-57f316b8c167@b20g2000pro.googlegroups.com>
Message-ID: <CABDkGQn6AxkB0pDwiQeanW2FwgHg-tW=hHxWmh0FRbjUun13Mg@mail.gmail.com>

On Wed, Dec 21, 2011 at 10:39 PM, karoyakani <tj.takei at gmail.com> wrote:
>> I don't like having background == 0, but I'll settle for background ==
>> -1 as a default.
>
> Thanks!

Please review the PR at:

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

> Or, len(np.unique(labels)) - 1, if we do not count the background in.

Or, as Tony mentioned: labels.max()

Cheers
St?fan


From jeanpatrick.pommier at gmail.com  Thu Dec 22 08:51:18 2011
From: jeanpatrick.pommier at gmail.com (jip)
Date: Thu, 22 Dec 2011 05:51:18 -0800 (PST)
Subject: plugin freeimage vs gdal on 0.5dev
Message-ID: <edfd25ff-dff3-46ce-96cd-69b14a038375@z1g2000vbx.googlegroups.com>

Dear all,
If I try to load a 12bits TIF image:
sk.io.use_plugin('freeimage', 'imread')
sk.io.use_plugin('matplotlib', 'imshow')
dapi=io.imread(path+CC+im)

I have the following message:
** Message: pygobject_register_sinkfunc is deprecated (GstObject)
Traceback (most recent call last):
  File "/home/claire/Applications/ProjetPython/projet particule et
objet/Nuclei/QuantSpots-skimage.py", line 49, in <module>
    sk.io.use_plugin('freeimage', 'imread')
  File "/usr/local/lib/python2.6/dist-packages/scikits_image-0.5dev-
py2.6-linux-i686.egg/skimage/io/_plugins/plugin.py", line 128, in use
    _load(name)
  File "/usr/local/lib/python2.6/dist-packages/scikits_image-0.5dev-
py2.6-linux-i686.egg/skimage/io/_plugins/plugin.py", line 190, in
_load
    fromlist=[modname])
  File "/usr/local/lib/python2.6/dist-packages/scikits_image-0.5dev-
py2.6-linux-i686.egg/skimage/io/_plugins/freeimage_plugin.py", line 6,
in <module>
    from numpy.compat import asbytes
ImportError: No module named compat

What is that compat module? I have numpy 1.30 installed.

Anyway,I can load the image with gdal  (sk.io.use_plugin('gdal',
'imread') with some warnings:
** Message: pygobject_register_sinkfunc is deprecated (GstObject)
Warning 1: TIFFReadDirectory:Unknown field with tag 34959 (0x888f)
encountered
Warning 1: TIFFReadDirectory:Unknown field with tag 34960 (0x8890)
encountered
Warning 1: TIFFReadDirectory:Unknown field with tag 34959 (0x888f)
encountered
Warning 1: TIFFReadDirectory:Unknown field with tag 34960 (0x8890)
encountered

best regards
Jean-Patrick


From jeanpatrick.pommier at gmail.com  Thu Dec 22 08:58:37 2011
From: jeanpatrick.pommier at gmail.com (jip)
Date: Thu, 22 Dec 2011 05:58:37 -0800 (PST)
Subject: How to update skimage 0.5dev
Message-ID: <fe80c11d-ac74-468d-8d15-ad419f453a27@j9g2000vby.googlegroups.com>

Dear all,
I'd like to update skimage 0.5dev.
I read somewhere that I need not to download the whole archive from
github and rebuild from scratch for every update.
sudo easy_install -U skimage fails

I there a command to do the work?
Thank you.

Jean-Patrick Pommier


From stefan at sun.ac.za  Thu Dec 22 12:33:36 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 22 Dec 2011 09:33:36 -0800
Subject: plugin freeimage vs gdal on 0.5dev
In-Reply-To: <edfd25ff-dff3-46ce-96cd-69b14a038375@z1g2000vbx.googlegroups.com>
References: <edfd25ff-dff3-46ce-96cd-69b14a038375@z1g2000vbx.googlegroups.com>
Message-ID: <CABDkGQ=SCfPNen7CBg3=5u+ef6FCsLs1G3phS7XbJdH5MDaujg@mail.gmail.com>

Hi JP

It seems like there is something wrong with your numpy.  Could you
please execute the following:

import numpy as np
print np.__version__
print np

import numpy.compat
print numpy.compat

Thanks
St?fan

On Thu, Dec 22, 2011 at 5:51 AM, jip <jeanpatrick.pommier at gmail.com> wrote:
> Dear all,
> If I try to load a 12bits TIF image:
> sk.io.use_plugin('freeimage', 'imread')
> sk.io.use_plugin('matplotlib', 'imshow')
> dapi=io.imread(path+CC+im)
>
> I have the following message:
> ** Message: pygobject_register_sinkfunc is deprecated (GstObject)
> Traceback (most recent call last):
> ?File "/home/claire/Applications/ProjetPython/projet particule et
> objet/Nuclei/QuantSpots-skimage.py", line 49, in <module>
> ? ?sk.io.use_plugin('freeimage', 'imread')
> ?File "/usr/local/lib/python2.6/dist-packages/scikits_image-0.5dev-
> py2.6-linux-i686.egg/skimage/io/_plugins/plugin.py", line 128, in use
> ? ?_load(name)
> ?File "/usr/local/lib/python2.6/dist-packages/scikits_image-0.5dev-
> py2.6-linux-i686.egg/skimage/io/_plugins/plugin.py", line 190, in
> _load
> ? ?fromlist=[modname])
> ?File "/usr/local/lib/python2.6/dist-packages/scikits_image-0.5dev-
> py2.6-linux-i686.egg/skimage/io/_plugins/freeimage_plugin.py", line 6,
> in <module>
> ? ?from numpy.compat import asbytes
> ImportError: No module named compat
>
> What is that compat module? I have numpy 1.30 installed.
>
> Anyway,I can load the image with gdal ?(sk.io.use_plugin('gdal',
> 'imread') with some warnings:
> ** Message: pygobject_register_sinkfunc is deprecated (GstObject)
> Warning 1: TIFFReadDirectory:Unknown field with tag 34959 (0x888f)
> encountered
> Warning 1: TIFFReadDirectory:Unknown field with tag 34960 (0x8890)
> encountered
> Warning 1: TIFFReadDirectory:Unknown field with tag 34959 (0x888f)
> encountered
> Warning 1: TIFFReadDirectory:Unknown field with tag 34960 (0x8890)
> encountered
>
> best regards
> Jean-Patrick


From stefan at sun.ac.za  Thu Dec 22 12:35:12 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 22 Dec 2011 09:35:12 -0800
Subject: How to update skimage 0.5dev
In-Reply-To: <fe80c11d-ac74-468d-8d15-ad419f453a27@j9g2000vby.googlegroups.com>
References: <fe80c11d-ac74-468d-8d15-ad419f453a27@j9g2000vby.googlegroups.com>
Message-ID: <CABDkGQmJF0jUU+EfzTKdmJFnAQhyM81iKz81dPZwdwbH=cYUBA@mail.gmail.com>

Hi JP

On Thu, Dec 22, 2011 at 5:58 AM, jip <jeanpatrick.pommier at gmail.com> wrote:
> I'd like to update skimage 0.5dev.
> I read somewhere that I need not to download the whole archive from
> github and rebuild from scratch for every update.
> sudo easy_install -U skimage fails

After installing git, you can clone the git repo with:

git clone git://github.com/scikits-image/scikits-image.git

Change into the scikits-image directory, and do "python setup.py
install" from there.

Regards
St?fan


From superslimme at netscape.net  Thu Dec 22 03:51:43 2011
From: superslimme at netscape.net (robbert)
Date: Thu, 22 Dec 2011 09:51:43 +0100
Subject: Video io, 'get' not working with OpenCv
In-Reply-To: <CABDkGQ=PMP-ZUDhsd9JoupjVMhOO0cjR2CvM4UgzNj+btf1ZAA@mail.gmail.com>
References: <4EECBA62.8030005@netscape.net> <CABDkGQ=PMP-ZUDhsd9JoupjVMhOO0cjR2CvM4UgzNj+btf1ZAA@mail.gmail.com>
Message-ID: <4EF2EF9F.9000905@netscape.net>

On 17-12-11 23:55, St??????fan van der Walt wrote:
> Hi Robbert
>
> On Sat, Dec 17, 2011 at 7:50 AM, robbert<superslimme at netscape.net>  wrote:
>> I've wrote a little test program to a extract a frame of a video file (for
>> processing), but I can't get it work.
> Thanks for the report.  This works using GStreamer, so tomorrow I'll
> compile OpenCV and determine what the problem is.

Thanks St??????fan & Christoph for your responses.
If this problem is solved, I've probably all the necessary toolboxes to 
leave matlab behind!

In the meanwhile I tried to install the alternative back-end, GStreamer, 
but without success.
The python demo's (of GStreamer) wont work, so there is no point in 
posting the error that scikits-image generates.

kind regards,

Robbert


From jeanpatrick.pommier at gmail.com  Thu Dec 22 14:10:14 2011
From: jeanpatrick.pommier at gmail.com (jip)
Date: Thu, 22 Dec 2011 11:10:14 -0800 (PST)
Subject: plugin freeimage vs gdal on 0.5dev
In-Reply-To: <CABDkGQ=SCfPNen7CBg3=5u+ef6FCsLs1G3phS7XbJdH5MDaujg@mail.gmail.com>
References: <edfd25ff-dff3-46ce-96cd-69b14a038375@z1g2000vbx.googlegroups.com> <CABDkGQ=SCfPNen7CBg3=5u+ef6FCsLs1G3phS7XbJdH5MDaujg@mail.gmail.com>
Message-ID: <65ebe513-9bc7-4634-ba1b-924670a3e671@q11g2000vbq.googlegroups.com>

Hi St?fan,
my numpy install seems to be broken:

In [1]: import numpy as np

In [2]: print np.__version__
1.3.0

In [3]: import numpy.compat
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call
last)
/home/claire/Applications/ProjetPython/<ipython-input-3-2f9167a96fc7>
in <module>()
----> 1 import numpy.compat

ImportError: No module named compat

Thanks
JP

On 22 d?c, 18:33, St?fan van der Walt <ste... at sun.ac.za> wrote:
> Hi JP
>
> It seems like there is something wrong with your numpy. ?Could you
> please execute the following:
>
> import numpy as np
> print np.__version__
> print np
>
> import numpy.compat
> print numpy.compat
>
> Thanks
> St?fan
>
>
>
>
>
>
>
> On Thu, Dec 22, 2011 at 5:51 AM, jip <jeanpatrick.pomm... at gmail.com> wrote:
> > Dear all,
> > If I try to load a 12bits TIF image:
> > sk.io.use_plugin('freeimage', 'imread')
> > sk.io.use_plugin('matplotlib', 'imshow')
> > dapi=io.imread(path+CC+im)
>
> > I have the following message:
> > ** Message: pygobject_register_sinkfunc is deprecated (GstObject)
> > Traceback (most recent call last):
> > ?File "/home/claire/Applications/ProjetPython/projet particule et
> > objet/Nuclei/QuantSpots-skimage.py", line 49, in <module>
> > ? ?sk.io.use_plugin('freeimage', 'imread')
> > ?File "/usr/local/lib/python2.6/dist-packages/scikits_image-0.5dev-
> > py2.6-linux-i686.egg/skimage/io/_plugins/plugin.py", line 128, in use
> > ? ?_load(name)
> > ?File "/usr/local/lib/python2.6/dist-packages/scikits_image-0.5dev-
> > py2.6-linux-i686.egg/skimage/io/_plugins/plugin.py", line 190, in
> > _load
> > ? ?fromlist=[modname])
> > ?File "/usr/local/lib/python2.6/dist-packages/scikits_image-0.5dev-
> > py2.6-linux-i686.egg/skimage/io/_plugins/freeimage_plugin.py", line 6,
> > in <module>
> > ? ?from numpy.compat import asbytes
> > ImportError: No module named compat
>
> > What is that compat module? I have numpy 1.30 installed.
>
> > Anyway,I can load the image with gdal ?(sk.io.use_plugin('gdal',
> > 'imread') with some warnings:
> > ** Message: pygobject_register_sinkfunc is deprecated (GstObject)
> > Warning 1: TIFFReadDirectory:Unknown field with tag 34959 (0x888f)
> > encountered
> > Warning 1: TIFFReadDirectory:Unknown field with tag 34960 (0x8890)
> > encountered
> > Warning 1: TIFFReadDirectory:Unknown field with tag 34959 (0x888f)
> > encountered
> > Warning 1: TIFFReadDirectory:Unknown field with tag 34960 (0x8890)
> > encountered
>
> > best regards
> > Jean-Patrick


From holtzhau at gmail.com  Thu Dec 22 05:31:09 2011
From: holtzhau at gmail.com (Pieter Holtzhausen)
Date: Thu, 22 Dec 2011 12:31:09 +0200
Subject: Video io, 'get' not working with OpenCv
In-Reply-To: <4EF2EF9F.9000905@netscape.net>
References: <4EECBA62.8030005@netscape.net>
	<CABDkGQ=PMP-ZUDhsd9JoupjVMhOO0cjR2CvM4UgzNj+btf1ZAA@mail.gmail.com>
	<4EF2EF9F.9000905@netscape.net>
Message-ID: <CAOA5xCwk+wiWNNxBp7pg7drrA_DhCama7wKkXXsoYrwFDgxX0Q@mail.gmail.com>

Hello

Yeah opencv made their python bindings work a bit less well with 2.3.1
A workaround is to use cv.fromarray(img_mat) instead of img_mat
wherever it complains in video.py. It is strange since automatic
conversion was one of the cool features of the binding system...but
I'll investigate a bit further.

Regards
Pieter

On Thu, Dec 22, 2011 at 10:51 AM, robbert <superslimme at netscape.net> wrote:
> On 17-12-11 23:55, St?fan van der Walt wrote:
>>
>> Hi Robbert
>>
>> On Sat, Dec 17, 2011 at 7:50 AM, robbert<superslimme at netscape.net> ?wrote:
>>>
>>> I've wrote a little test program to a extract a frame of a video file
>>> (for
>>> processing), but I can't get it work.
>>
>> Thanks for the report. ?This works using GStreamer, so tomorrow I'll
>> compile OpenCV and determine what the problem is.
>
>
> Thanks St?fan & Christoph for your responses.
> If this problem is solved, I've probably all the necessary toolboxes to
> leave matlab behind!
>
> In the meanwhile I tried to install the alternative back-end, GStreamer, but
> without success.
> The python demo's (of GStreamer) wont work, so there is no point in posting
> the error that scikits-image generates.
>
> kind regards,
>
> Robbert


From holtzhau at gmail.com  Thu Dec 22 05:40:39 2011
From: holtzhau at gmail.com (Pieter Holtzhausen)
Date: Thu, 22 Dec 2011 12:40:39 +0200
Subject: Video io, 'get' not working with OpenCv
In-Reply-To: <CAOA5xCwk+wiWNNxBp7pg7drrA_DhCama7wKkXXsoYrwFDgxX0Q@mail.gmail.com>
References: <4EECBA62.8030005@netscape.net>
	<CABDkGQ=PMP-ZUDhsd9JoupjVMhOO0cjR2CvM4UgzNj+btf1ZAA@mail.gmail.com>
	<4EF2EF9F.9000905@netscape.net>
	<CAOA5xCwk+wiWNNxBp7pg7drrA_DhCama7wKkXXsoYrwFDgxX0Q@mail.gmail.com>
Message-ID: <CAOA5xCzW+aak7JJB07j5-UWkgK=9k3Y5KbF7o_=urr1uy9LUKA@mail.gmail.com>

Seems like the python bindings disabled that functionality
https://code.ros.org/trac/opencv/changeset/6358

On Thu, Dec 22, 2011 at 12:31 PM, Pieter Holtzhausen <holtzhau at gmail.com> wrote:
> Hello
>
> Yeah opencv made their python bindings work a bit less well with 2.3.1
> A workaround is to use cv.fromarray(img_mat) instead of img_mat
> wherever it complains in video.py. It is strange since automatic
> conversion was one of the cool features of the binding system...but
> I'll investigate a bit further.
>
> Regards
> Pieter
>
> On Thu, Dec 22, 2011 at 10:51 AM, robbert <superslimme at netscape.net> wrote:
>> On 17-12-11 23:55, St?fan van der Walt wrote:
>>>
>>> Hi Robbert
>>>
>>> On Sat, Dec 17, 2011 at 7:50 AM, robbert<superslimme at netscape.net> ?wrote:
>>>>
>>>> I've wrote a little test program to a extract a frame of a video file
>>>> (for
>>>> processing), but I can't get it work.
>>>
>>> Thanks for the report. ?This works using GStreamer, so tomorrow I'll
>>> compile OpenCV and determine what the problem is.
>>
>>
>> Thanks St?fan & Christoph for your responses.
>> If this problem is solved, I've probably all the necessary toolboxes to
>> leave matlab behind!
>>
>> In the meanwhile I tried to install the alternative back-end, GStreamer, but
>> without success.
>> The python demo's (of GStreamer) wont work, so there is no point in posting
>> the error that scikits-image generates.
>>
>> kind regards,
>>
>> Robbert


From jeanpatrick.pommier at gmail.com  Thu Dec 22 16:00:29 2011
From: jeanpatrick.pommier at gmail.com (jip)
Date: Thu, 22 Dec 2011 13:00:29 -0800 (PST)
Subject: plugin freeimage vs gdal on 0.5dev
In-Reply-To: <CAE-UAvTK6QX1ChQgdViqiZHnbNTKzykX5OeuJL56MERbkQS8zQ@mail.gmail.com>
References: <edfd25ff-dff3-46ce-96cd-69b14a038375@z1g2000vbx.googlegroups.com>
 <CABDkGQ=SCfPNen7CBg3=5u+ef6FCsLs1G3phS7XbJdH5MDaujg@mail.gmail.com>
 <65ebe513-9bc7-4634-ba1b-924670a3e671@q11g2000vbq.googlegroups.com> <CAE-UAvTK6QX1ChQgdViqiZHnbNTKzykX5OeuJL56MERbkQS8zQ@mail.gmail.com>
Message-ID: <2549b129-a0b1-46a8-aff2-063aded04ef0@m10g2000vbc.googlegroups.com>

thanks,
JP

On 22 d?c, 20:18, Nelle Varoquaux <nelle.varoqu... at gmail.com> wrote:
> Hi JP,
>
> You need to upgrade numpy to at least 1.4
>
> Thanks,
> N
>
> On 22 December 2011 20:10, jip <jeanpatrick.pomm... at gmail.com> wrote:
>
>
>
>
>
>
>
> > Hi St?fan,
> > my numpy install seems to be broken:
>
> > In [1]: import numpy as np
>
> > In [2]: print np.__version__
> > 1.3.0
>
> > In [3]: import numpy.compat
> > ---------------------------------------------------------------------------
> > ImportError ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Traceback (most recent call
> > last)
> > /home/claire/Applications/ProjetPython/<ipython-input-3-2f9167a96fc7>
> > in <module>()
> > ----> 1 import numpy.compat
>
> > ImportError: No module named compat
>
> > Thanks
> > JP
>
> > On 22 d?c, 18:33, St?fan van der Walt <ste... at sun.ac.za> wrote:
> > > Hi JP
>
> > > It seems like there is something wrong with your numpy. ?Could you
> > > please execute the following:
>
> > > import numpy as np
> > > print np.__version__
> > > print np
>
> > > import numpy.compat
> > > print numpy.compat
>
> > > Thanks
> > > St?fan
>
> > > On Thu, Dec 22, 2011 at 5:51 AM, jip <jeanpatrick.pomm... at gmail.com>
> > wrote:
> > > > Dear all,
> > > > If I try to load a 12bits TIF image:
> > > > sk.io.use_plugin('freeimage', 'imread')
> > > > sk.io.use_plugin('matplotlib', 'imshow')
> > > > dapi=io.imread(path+CC+im)
>
> > > > I have the following message:
> > > > ** Message: pygobject_register_sinkfunc is deprecated (GstObject)
> > > > Traceback (most recent call last):
> > > > ?File "/home/claire/Applications/ProjetPython/projet particule et
> > > > objet/Nuclei/QuantSpots-skimage.py", line 49, in <module>
> > > > ? ?sk.io.use_plugin('freeimage', 'imread')
> > > > ?File "/usr/local/lib/python2.6/dist-packages/scikits_image-0.5dev-
> > > > py2.6-linux-i686.egg/skimage/io/_plugins/plugin.py", line 128, in use
> > > > ? ?_load(name)
> > > > ?File "/usr/local/lib/python2.6/dist-packages/scikits_image-0.5dev-
> > > > py2.6-linux-i686.egg/skimage/io/_plugins/plugin.py", line 190, in
> > > > _load
> > > > ? ?fromlist=[modname])
> > > > ?File "/usr/local/lib/python2.6/dist-packages/scikits_image-0.5dev-
> > > > py2.6-linux-i686.egg/skimage/io/_plugins/freeimage_plugin.py", line 6,
> > > > in <module>
> > > > ? ?from numpy.compat import asbytes
> > > > ImportError: No module named compat
>
> > > > What is that compat module? I have numpy 1.30 installed.
>
> > > > Anyway,I can load the image with gdal ?(sk.io.use_plugin('gdal',
> > > > 'imread') with some warnings:
> > > > ** Message: pygobject_register_sinkfunc is deprecated (GstObject)
> > > > Warning 1: TIFFReadDirectory:Unknown field with tag 34959 (0x888f)
> > > > encountered
> > > > Warning 1: TIFFReadDirectory:Unknown field with tag 34960 (0x8890)
> > > > encountered
> > > > Warning 1: TIFFReadDirectory:Unknown field with tag 34959 (0x888f)
> > > > encountered
> > > > Warning 1: TIFFReadDirectory:Unknown field with tag 34960 (0x8890)
> > > > encountered
>
> > > > best regards
> > > > Jean-Patrick


From nelle.varoquaux at gmail.com  Thu Dec 22 14:18:59 2011
From: nelle.varoquaux at gmail.com (Nelle Varoquaux)
Date: Thu, 22 Dec 2011 20:18:59 +0100
Subject: plugin freeimage vs gdal on 0.5dev
In-Reply-To: <65ebe513-9bc7-4634-ba1b-924670a3e671@q11g2000vbq.googlegroups.com>
References: <edfd25ff-dff3-46ce-96cd-69b14a038375@z1g2000vbx.googlegroups.com>
	<CABDkGQ=SCfPNen7CBg3=5u+ef6FCsLs1G3phS7XbJdH5MDaujg@mail.gmail.com>
	<65ebe513-9bc7-4634-ba1b-924670a3e671@q11g2000vbq.googlegroups.com>
Message-ID: <CAE-UAvTK6QX1ChQgdViqiZHnbNTKzykX5OeuJL56MERbkQS8zQ@mail.gmail.com>

Hi JP,

You need to upgrade numpy to at least 1.4

Thanks,
N

On 22 December 2011 20:10, jip <jeanpatrick.pommier at gmail.com> wrote:

> Hi St?fan,
> my numpy install seems to be broken:
>
> In [1]: import numpy as np
>
> In [2]: print np.__version__
> 1.3.0
>
> In [3]: import numpy.compat
> ---------------------------------------------------------------------------
> ImportError                               Traceback (most recent call
> last)
> /home/claire/Applications/ProjetPython/<ipython-input-3-2f9167a96fc7>
> in <module>()
> ----> 1 import numpy.compat
>
> ImportError: No module named compat
>
> Thanks
> JP
>
> On 22 d?c, 18:33, St?fan van der Walt <ste... at sun.ac.za> wrote:
> > Hi JP
> >
> > It seems like there is something wrong with your numpy.  Could you
> > please execute the following:
> >
> > import numpy as np
> > print np.__version__
> > print np
> >
> > import numpy.compat
> > print numpy.compat
> >
> > Thanks
> > St?fan
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Dec 22, 2011 at 5:51 AM, jip <jeanpatrick.pomm... at gmail.com>
> wrote:
> > > Dear all,
> > > If I try to load a 12bits TIF image:
> > > sk.io.use_plugin('freeimage', 'imread')
> > > sk.io.use_plugin('matplotlib', 'imshow')
> > > dapi=io.imread(path+CC+im)
> >
> > > I have the following message:
> > > ** Message: pygobject_register_sinkfunc is deprecated (GstObject)
> > > Traceback (most recent call last):
> > >  File "/home/claire/Applications/ProjetPython/projet particule et
> > > objet/Nuclei/QuantSpots-skimage.py", line 49, in <module>
> > >    sk.io.use_plugin('freeimage', 'imread')
> > >  File "/usr/local/lib/python2.6/dist-packages/scikits_image-0.5dev-
> > > py2.6-linux-i686.egg/skimage/io/_plugins/plugin.py", line 128, in use
> > >    _load(name)
> > >  File "/usr/local/lib/python2.6/dist-packages/scikits_image-0.5dev-
> > > py2.6-linux-i686.egg/skimage/io/_plugins/plugin.py", line 190, in
> > > _load
> > >    fromlist=[modname])
> > >  File "/usr/local/lib/python2.6/dist-packages/scikits_image-0.5dev-
> > > py2.6-linux-i686.egg/skimage/io/_plugins/freeimage_plugin.py", line 6,
> > > in <module>
> > >    from numpy.compat import asbytes
> > > ImportError: No module named compat
> >
> > > What is that compat module? I have numpy 1.30 installed.
> >
> > > Anyway,I can load the image with gdal  (sk.io.use_plugin('gdal',
> > > 'imread') with some warnings:
> > > ** Message: pygobject_register_sinkfunc is deprecated (GstObject)
> > > Warning 1: TIFFReadDirectory:Unknown field with tag 34959 (0x888f)
> > > encountered
> > > Warning 1: TIFFReadDirectory:Unknown field with tag 34960 (0x8890)
> > > encountered
> > > Warning 1: TIFFReadDirectory:Unknown field with tag 34959 (0x888f)
> > > encountered
> > > Warning 1: TIFFReadDirectory:Unknown field with tag 34960 (0x8890)
> > > encountered
> >
> > > best regards
> > > Jean-Patrick
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111222/80977e13/attachment.html>

From nadavh.horesh at gmail.com  Thu Dec 22 15:12:59 2011
From: nadavh.horesh at gmail.com (Nadav Horesh)
Date: Thu, 22 Dec 2011 22:12:59 +0200
Subject: Need an advice
Message-ID: <CA+oBP_tF5YvsH9Nws1ha1BzVa_CXr=BhXZmW7PnhL=ah8O4J=w@mail.gmail.com>

I have several scripts dealing with image procession of digital cameras raw
data. Currently in use are filters and array processing from numpy,
scipy.signal, scipy.ndimage and numexpr. I am looking for faster tools that
cold be used without any extensive learning period. I came up of the
following options:
1, Theano: Can be very fast, but missing some important features  like a
median filter
2. OpenCV: Fast and features rich, but the interface is not easy to learn.

Any recommendation for alternative libraries or easy interfaces to opencv?
(I looked at pyopencv, but the project doen't seems to be alive these days)

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

From emmanuelle.gouillart at nsup.org  Thu Dec 22 16:27:22 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Thu, 22 Dec 2011 22:27:22 +0100
Subject: Need an advice
In-Reply-To: <CA+oBP_tF5YvsH9Nws1ha1BzVa_CXr=BhXZmW7PnhL=ah8O4J=w@mail.gmail.com>
References: <CA+oBP_tF5YvsH9Nws1ha1BzVa_CXr=BhXZmW7PnhL=ah8O4J=w@mail.gmail.com>
Message-ID: <20111222212722.GB8906@phare.normalesup.org>

Hi Nadav,

would you need everything to be faster, or do you have some identified
bottlenecks that take most of the computing time? In the latter case,
you may want to keep using the most standard tools for most image
processing steps, and pick a specialized and fast module for the most
critical steps, like OpenCV. Also, the algorithms in scikits-image
shouldn't do too bad in terms of executing speed, since they rely either
on numpy arrays or on Cython code: what speed factor would you expect to
gain with another library such as OpenCV?

As for alternative librairies, ITK is very powerful and fast and has
Python bindings. The learning curve looks a bit steep, though.

Cheers,
Emmanuelle

On Thu, Dec 22, 2011 at 10:12:59PM +0200, Nadav Horesh wrote:
>    I have several scripts dealing with image procession of digital cameras
>    raw data. Currently in use are filters and array processing from numpy,
>    scipy.signal, scipy.ndimage and numexpr. I am looking for faster tools
>    that cold be used without any extensive learning period. I came up of the
>    following options:
>    1, Theano: Can be very fast, but missing some important features? like a
>    median filter
>    2. OpenCV: Fast and features rich, but the interface is not easy to learn.

>    Any recommendation for alternative libraries or easy interfaces to opencv?
>    (I looked at pyopencv, but the project doen't seems to be alive these
>    days)

>    ?? Nadav


From stefan at sun.ac.za  Fri Dec 23 03:46:32 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 23 Dec 2011 00:46:32 -0800
Subject: Need an advice
In-Reply-To: <CA+oBP_tRVj29jgmyije3uEjg9tHMAqtB1e_y0XKgzaCBuL=pZQ@mail.gmail.com>
References: <CA+oBP_tF5YvsH9Nws1ha1BzVa_CXr=BhXZmW7PnhL=ah8O4J=w@mail.gmail.com>
 <CAB=suEnTxQ+ibJ+58dL4XmvqwY+zVP3pRmvDis15b6Th3z3dQQ@mail.gmail.com> <CA+oBP_tRVj29jgmyije3uEjg9tHMAqtB1e_y0XKgzaCBuL=pZQ@mail.gmail.com>
Message-ID: <CABDkGQmU4-OtonbngS6wEzqE85M++Tz0Lr9VRO_B4HySS2HT+g@mail.gmail.com>

On Thu, Dec 22, 2011 at 10:44 PM, Nadav Horesh <nadavh.horesh at gmail.com> wrote:
> The application is not too sophisticated, and I do use numpy, scipy and
> skimage for all I need. The only problem is speed, I need the processing to
> be at l5-10 time faster. Convolutions take most of the processing time. I
> prefer a flexible solution that would speed up also common nonlinear filters
> (i.e. a median filter).

We have a PR in the pipeline for doing really, really fast
convolutions... but it needs a bit of work.  Would you like to have a
look at it?

St?fan


From deshpande.jaidev at gmail.com  Thu Dec 22 15:25:05 2011
From: deshpande.jaidev at gmail.com (Jaidev Deshpande)
Date: Fri, 23 Dec 2011 01:55:05 +0530
Subject: Need an advice
In-Reply-To: <CA+oBP_tF5YvsH9Nws1ha1BzVa_CXr=BhXZmW7PnhL=ah8O4J=w@mail.gmail.com>
References: <CA+oBP_tF5YvsH9Nws1ha1BzVa_CXr=BhXZmW7PnhL=ah8O4J=w@mail.gmail.com>
Message-ID: <CAB=suEnTxQ+ibJ+58dL4XmvqwY+zVP3pRmvDis15b6Th3z3dQQ@mail.gmail.com>

On Fri, Dec 23, 2011 at 1:42 AM, Nadav Horesh <nadavh.horesh at gmail.com> wrote:
>
>Currently in use are filters and array processing from numpy, scipy.signal, scipy.ndimage and numexpr. I am looking for faster tools that cold be used without any extensive learning period.

Are filters all you're looking for? If yes, and if your application
isn't too sophisticated, you can simply use NumPy arrays as filters.
Or else try scikits-image.

What kind of filtering is it, and what's the application?

Best,
Jaidev


From nadavh.horesh at gmail.com  Fri Dec 23 01:44:48 2011
From: nadavh.horesh at gmail.com (Nadav Horesh)
Date: Fri, 23 Dec 2011 08:44:48 +0200
Subject: Need an advice
In-Reply-To: <CAB=suEnTxQ+ibJ+58dL4XmvqwY+zVP3pRmvDis15b6Th3z3dQQ@mail.gmail.com>
References: <CA+oBP_tF5YvsH9Nws1ha1BzVa_CXr=BhXZmW7PnhL=ah8O4J=w@mail.gmail.com>
	<CAB=suEnTxQ+ibJ+58dL4XmvqwY+zVP3pRmvDis15b6Th3z3dQQ@mail.gmail.com>
Message-ID: <CA+oBP_tRVj29jgmyije3uEjg9tHMAqtB1e_y0XKgzaCBuL=pZQ@mail.gmail.com>

The application is not too sophisticated, and I do use numpy, scipy and
skimage for all I need. The only problem is speed, I need the processing to
be at l5-10 time faster. Convolutions take most of the processing time. I
prefer a flexible solution that would speed up also common nonlinear
filters (i.e. a median filter).

   Nadav,

2011/12/22 Jaidev Deshpande <deshpande.jaidev at gmail.com>

> On Fri, Dec 23, 2011 at 1:42 AM, Nadav Horesh <nadavh.horesh at gmail.com>
> wrote:
> >
> >Currently in use are filters and array processing from numpy,
> scipy.signal, scipy.ndimage and numexpr. I am looking for faster tools that
> cold be used without any extensive learning period.
>
> Are filters all you're looking for? If yes, and if your application
> isn't too sophisticated, you can simply use NumPy arrays as filters.
> Or else try scikits-image.
>
> What kind of filtering is it, and what's the application?
>
> Best,
> Jaidev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111223/a07a3387/attachment.html>

From nadavh.horesh at gmail.com  Fri Dec 23 05:04:40 2011
From: nadavh.horesh at gmail.com (Nadav Horesh)
Date: Fri, 23 Dec 2011 12:04:40 +0200
Subject: Need an advice
In-Reply-To: <CABDkGQmU4-OtonbngS6wEzqE85M++Tz0Lr9VRO_B4HySS2HT+g@mail.gmail.com>
References: <CA+oBP_tF5YvsH9Nws1ha1BzVa_CXr=BhXZmW7PnhL=ah8O4J=w@mail.gmail.com>
	<CAB=suEnTxQ+ibJ+58dL4XmvqwY+zVP3pRmvDis15b6Th3z3dQQ@mail.gmail.com>
	<CA+oBP_tRVj29jgmyije3uEjg9tHMAqtB1e_y0XKgzaCBuL=pZQ@mail.gmail.com>
	<CABDkGQmU4-OtonbngS6wEzqE85M++Tz0Lr9VRO_B4HySS2HT+g@mail.gmail.com>
Message-ID: <CA+oBP_vX1UiogY+pEm1677jy=TKU4C9reSGWbYKgqdOqdrhfxQ@mail.gmail.com>

Of course.


  Thank you,
    Nadav.

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

> On Thu, Dec 22, 2011 at 10:44 PM, Nadav Horesh <nadavh.horesh at gmail.com>
> wrote:
> > The application is not too sophisticated, and I do use numpy, scipy and
> > skimage for all I need. The only problem is speed, I need the processing
> to
> > be at l5-10 time faster. Convolutions take most of the processing time. I
> > prefer a flexible solution that would speed up also common nonlinear
> filters
> > (i.e. a median filter).
>
> We have a PR in the pipeline for doing really, really fast
> convolutions... but it needs a bit of work.  Would you like to have a
> look at it?
>
> St?fan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111223/b143a528/attachment.html>

From harishbadrinath at gmail.com  Fri Dec 23 01:58:33 2011
From: harishbadrinath at gmail.com (harish badrinath)
Date: Fri, 23 Dec 2011 12:28:33 +0530
Subject: PKG: Cant seem to build scikits debian package from source
Message-ID: <CAFUoqbfGwQQSgaMX06U=-O-bQ-uJmfqKHFSJRavfEnNfNW_T1g@mail.gmail.com>

Hello,
I cant seem to build scikits-image from source using debuild.

Here are the steps i followed:
a)I checkout master and debian branches in seprate directories.
b) export master branch as a tar ball
c) run dh_make (a debian specific packaging helper script)
d) copy the contents of the debian directory to the directory in which
i ran dh_make
e) run debbuild

The log of the build is
<snip>
dh clean --buildsystem python_distutils
   dh_testdir -O--buildsystem=python_distutils
   dh_auto_clean -O--buildsystem=python_distutils
Traceback (most recent call last):
  File "setup.py", line 101, in <module>
    cmdclass={'build_py': build_py},
  File "/usr/lib/pymodules/python2.5/numpy/distutils/core.py", line
152, in setup
    config = configuration()
  File "setup.py", line 42, in configuration
    config.add_subpackage('skimage')
  File "/usr/lib/pymodules/python2.5/numpy/distutils/misc_util.py",
line 957, in add_subpackage
    caller_level = 2)
  File "/usr/lib/pymodules/python2.5/numpy/distutils/misc_util.py",
line 926, in get_subpackage
    caller_level = caller_level + 1)
  File "/usr/lib/pymodules/python2.5/numpy/distutils/misc_util.py",
line 863, in _get_configuration_from_setup_py
    config = setup_module.configuration(*args)
  File "skimage/setup.py", line 8, in configuration
    config.add_subpackage('graph')
  File "/usr/lib/pymodules/python2.5/numpy/distutils/misc_util.py",
line 957, in add_subpackage
    caller_level = 2)
  File "/usr/lib/pymodules/python2.5/numpy/distutils/misc_util.py",
line 926, in get_subpackage
    caller_level = caller_level + 1)
  File "/usr/lib/pymodules/python2.5/numpy/distutils/misc_util.py",
line 848, in _get_configuration_from_setup_py
    ('.py', 'U', 1))
  File "skimage/graph/setup.py", line 3, in <module>
    from skimage._build import cython
  File "/home/code/projs/scikits-image-master/scikits-image-0.4/skimage/__init__.py",
line 64
    from .util.dtype import *
SyntaxError: 'import *' not allowed with 'from .'
dh_auto_clean: python2.5 setup.py clean -a returned exit code 1
make: *** [clean] Error 1
dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2
debuild: fatal error at line 1325:
dpkg-buildpackage -rfakeroot -D -us -uc failed
</snip>
Since i have very little experience with python, its build system, etc
any help would be appreciated.

Regards,
Harish


From nadavh.horesh at gmail.com  Fri Dec 23 05:48:07 2011
From: nadavh.horesh at gmail.com (Nadav Horesh)
Date: Fri, 23 Dec 2011 12:48:07 +0200
Subject: PKG: Cant seem to build scikits debian package from source
In-Reply-To: <CAFUoqbfGwQQSgaMX06U=-O-bQ-uJmfqKHFSJRavfEnNfNW_T1g@mail.gmail.com>
References: <CAFUoqbfGwQQSgaMX06U=-O-bQ-uJmfqKHFSJRavfEnNfNW_T1g@mail.gmail.com>
Message-ID: <CA+oBP_s_9C3CX2R1rpyh66Pw0F6x6Surew-8LiezutdqgtBdTA@mail.gmail.com>

There is a new import statement syntax. I think you should upgrade your
python. I have no experience with Debian, but on the seveal other linux
distros I used this upgrade is easy and harmless.

   Nadav.

2011/12/23 harish badrinath <harishbadrinath at gmail.com>

> Hello,
> I cant seem to build scikits-image from source using debuild.
>
> Here are the steps i followed:
> a)I checkout master and debian branches in seprate directories.
> b) export master branch as a tar ball
> c) run dh_make (a debian specific packaging helper script)
> d) copy the contents of the debian directory to the directory in which
> i ran dh_make
> e) run debbuild
>
> The log of the build is
> <snip>
> dh clean --buildsystem python_distutils
>   dh_testdir -O--buildsystem=python_distutils
>   dh_auto_clean -O--buildsystem=python_distutils
> Traceback (most recent call last):
>  File "setup.py", line 101, in <module>
>    cmdclass={'build_py': build_py},
>  File "/usr/lib/pymodules/python2.5/numpy/distutils/core.py", line
> 152, in setup
>    config = configuration()
>  File "setup.py", line 42, in configuration
>    config.add_subpackage('skimage')
>  File "/usr/lib/pymodules/python2.5/numpy/distutils/misc_util.py",
> line 957, in add_subpackage
>    caller_level = 2)
>  File "/usr/lib/pymodules/python2.5/numpy/distutils/misc_util.py",
> line 926, in get_subpackage
>    caller_level = caller_level + 1)
>  File "/usr/lib/pymodules/python2.5/numpy/distutils/misc_util.py",
> line 863, in _get_configuration_from_setup_py
>    config = setup_module.configuration(*args)
>  File "skimage/setup.py", line 8, in configuration
>    config.add_subpackage('graph')
>  File "/usr/lib/pymodules/python2.5/numpy/distutils/misc_util.py",
> line 957, in add_subpackage
>    caller_level = 2)
>  File "/usr/lib/pymodules/python2.5/numpy/distutils/misc_util.py",
> line 926, in get_subpackage
>    caller_level = caller_level + 1)
>  File "/usr/lib/pymodules/python2.5/numpy/distutils/misc_util.py",
> line 848, in _get_configuration_from_setup_py
>    ('.py', 'U', 1))
>  File "skimage/graph/setup.py", line 3, in <module>
>    from skimage._build import cython
>  File
> "/home/code/projs/scikits-image-master/scikits-image-0.4/skimage/__init__.py",
> line 64
>    from .util.dtype import *
> SyntaxError: 'import *' not allowed with 'from .'
> dh_auto_clean: python2.5 setup.py clean -a returned exit code 1
> make: *** [clean] Error 1
> dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit
> status 2
> debuild: fatal error at line 1325:
> dpkg-buildpackage -rfakeroot -D -us -uc failed
> </snip>
> Since i have very little experience with python, its build system, etc
> any help would be appreciated.
>
> Regards,
> Harish
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111223/58fd7dbf/attachment.html>

From google at terre-adelie.org  Fri Dec 23 12:14:49 2011
From: google at terre-adelie.org (Jerome Kieffer)
Date: Fri, 23 Dec 2011 18:14:49 +0100
Subject: PKG: Cant seem to build scikits debian package from source
In-Reply-To: <CAFUoqbfGwQQSgaMX06U=-O-bQ-uJmfqKHFSJRavfEnNfNW_T1g@mail.gmail.com>
References: <CAFUoqbfGwQQSgaMX06U=-O-bQ-uJmfqKHFSJRavfEnNfNW_T1g@mail.gmail.com>
Message-ID: <20111223181449.795d983f.google@terre-adelie.org>

On Fri, 23 Dec 2011 12:28:33 +0530
harish badrinath <harishbadrinath at gmail.com> wrote:

> Hello,
> I cant seem to build scikits-image from source using debuild.
> 
> Here are the steps i followed:
> a)I checkout master and debian branches in seprate directories.
> b) export master branch as a tar ball
> c) run dh_make (a debian specific packaging helper script)
> d) copy the contents of the debian directory to the directory in which
> i ran dh_make
> e) run debbuild


I suggest you to install python-stdeb (on recent ubuntu/debian systems) then simply use the setup.py:

python setup.py --command-packages=stdeb.command bdist_deb

to create a debian package. Most of the case it works out of the box (I just tested on scikits-git and it is OK).

Cheers
-- 
Jerome Kieffer <google at terre-adelie.org>


From stefan at sun.ac.za  Mon Dec 26 09:50:55 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 26 Dec 2011 06:50:55 -0800
Subject: Pull request visualisation
Message-ID: <CABDkGQmfxPVmjzPcaQEV-uLKdBD8DDaGK-WJQr0B5o+PW73OTg@mail.gmail.com>

Here's an illustration of our GitHub pull-request activity over the
last while. It's modest, still, but those humps are good news!

https://plus.google.com/u/0/104831275312843762750/posts/dHzc6cQfyhV


From jeanpatrick.pommier at gmail.com  Tue Dec 27 10:03:08 2011
From: jeanpatrick.pommier at gmail.com (jip)
Date: Tue, 27 Dec 2011 07:03:08 -0800 (PST)
Subject: plugin freeimage vs gdal on 0.5dev
In-Reply-To: <2549b129-a0b1-46a8-aff2-063aded04ef0@m10g2000vbc.googlegroups.com>
References: <edfd25ff-dff3-46ce-96cd-69b14a038375@z1g2000vbx.googlegroups.com>
 <CABDkGQ=SCfPNen7CBg3=5u+ef6FCsLs1G3phS7XbJdH5MDaujg@mail.gmail.com>
 <65ebe513-9bc7-4634-ba1b-924670a3e671@q11g2000vbq.googlegroups.com>
 <CAE-UAvTK6QX1ChQgdViqiZHnbNTKzykX5OeuJL56MERbkQS8zQ@mail.gmail.com> <2549b129-a0b1-46a8-aff2-063aded04ef0@m10g2000vbc.googlegroups.com>
Message-ID: <dea9c9de-c987-4e6d-aaa4-69ed8db20d0d@p9g2000vbb.googlegroups.com>

Hi,

The script works after updating numpy to 1.6.1 (sudo easy_install -U
numpy)

Thank you again.

Jean-Patrick


On 22 d?c, 22:00, jip <jeanpatrick.pomm... at gmail.com> wrote:
> thanks,
> JP
>
> On 22 d?c, 20:18, Nelle Varoquaux <nelle.varoqu... at gmail.com> wrote:
>
>
>
>
>
>
>
> > Hi JP,
>
> > You need to upgrade numpy to at least 1.4
>
> > Thanks,
> > N
>
> > On 22 December 2011 20:10, jip <jeanpatrick.pomm... at gmail.com> wrote:
>
> > > Hi St?fan,
> > > my numpy install seems to be broken:
>
> > > In [1]: import numpy as np
>
> > > In [2]: print np.__version__
> > > 1.3.0
>
> > > In [3]: import numpy.compat
> > > ---------------------------------------------------------------------------
> > > ImportError ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Traceback (most recent call
> > > last)
> > > /home/claire/Applications/ProjetPython/<ipython-input-3-2f9167a96fc7>
> > > in <module>()
> > > ----> 1 import numpy.compat
>
> > > ImportError: No module named compat
>
> > > Thanks
> > > JP
>
> > > On 22 d?c, 18:33, St?fan van der Walt <ste... at sun.ac.za> wrote:
> > > > Hi JP
>
> > > > It seems like there is something wrong with your numpy. ?Could you
> > > > please execute the following:
>
> > > > import numpy as np
> > > > print np.__version__
> > > > print np
>
> > > > import numpy.compat
> > > > print numpy.compat
>
> > > > Thanks
> > > > St?fan
>
> > > > On Thu, Dec 22, 2011 at 5:51 AM, jip <jeanpatrick.pomm... at gmail.com>
> > > wrote:
> > > > > Dear all,
> > > > > If I try to load a 12bits TIF image:
> > > > > sk.io.use_plugin('freeimage', 'imread')
> > > > > sk.io.use_plugin('matplotlib', 'imshow')
> > > > > dapi=io.imread(path+CC+im)
>
> > > > > I have the following message:
> > > > > ** Message: pygobject_register_sinkfunc is deprecated (GstObject)
> > > > > Traceback (most recent call last):
> > > > > ?File "/home/claire/Applications/ProjetPython/projet particule et
> > > > > objet/Nuclei/QuantSpots-skimage.py", line 49, in <module>
> > > > > ? ?sk.io.use_plugin('freeimage', 'imread')
> > > > > ?File "/usr/local/lib/python2.6/dist-packages/scikits_image-0.5dev-
> > > > > py2.6-linux-i686.egg/skimage/io/_plugins/plugin.py", line 128, in use
> > > > > ? ?_load(name)
> > > > > ?File "/usr/local/lib/python2.6/dist-packages/scikits_image-0.5dev-
> > > > > py2.6-linux-i686.egg/skimage/io/_plugins/plugin.py", line 190, in
> > > > > _load
> > > > > ? ?fromlist=[modname])
> > > > > ?File "/usr/local/lib/python2.6/dist-packages/scikits_image-0.5dev-
> > > > > py2.6-linux-i686.egg/skimage/io/_plugins/freeimage_plugin.py", line 6,
> > > > > in <module>
> > > > > ? ?from numpy.compat import asbytes
> > > > > ImportError: No module named compat
>
> > > > > What is that compat module? I have numpy 1.30 installed.
>
> > > > > Anyway,I can load the image with gdal ?(sk.io.use_plugin('gdal',
> > > > > 'imread') with some warnings:
> > > > > ** Message: pygobject_register_sinkfunc is deprecated (GstObject)
> > > > > Warning 1: TIFFReadDirectory:Unknown field with tag 34959 (0x888f)
> > > > > encountered
> > > > > Warning 1: TIFFReadDirectory:Unknown field with tag 34960 (0x8890)
> > > > > encountered
> > > > > Warning 1: TIFFReadDirectory:Unknown field with tag 34959 (0x888f)
> > > > > encountered
> > > > > Warning 1: TIFFReadDirectory:Unknown field with tag 34960 (0x8890)
> > > > > encountered
>
> > > > > best regards
> > > > > Jean-Patrick


From nadavh.horesh at gmail.com  Tue Dec 27 11:29:17 2011
From: nadavh.horesh at gmail.com (Nadav Horesh)
Date: Tue, 27 Dec 2011 18:29:17 +0200
Subject: Need an advice
In-Reply-To: <CABDkGQmU4-OtonbngS6wEzqE85M++Tz0Lr9VRO_B4HySS2HT+g@mail.gmail.com>
References: <CA+oBP_tF5YvsH9Nws1ha1BzVa_CXr=BhXZmW7PnhL=ah8O4J=w@mail.gmail.com>
	<CAB=suEnTxQ+ibJ+58dL4XmvqwY+zVP3pRmvDis15b6Th3z3dQQ@mail.gmail.com>
	<CA+oBP_tRVj29jgmyije3uEjg9tHMAqtB1e_y0XKgzaCBuL=pZQ@mail.gmail.com>
	<CABDkGQmU4-OtonbngS6wEzqE85M++Tz0Lr9VRO_B4HySS2HT+g@mail.gmail.com>
Message-ID: <CA+oBP_vMAar=0Rd3xHtJff_y8V=+o_Sa47MvJ4OU5dsqN-oN2w@mail.gmail.com>

How can I get it?

  Nadav

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

> On Thu, Dec 22, 2011 at 10:44 PM, Nadav Horesh <nadavh.horesh at gmail.com>
> wrote:
> > The application is not too sophisticated, and I do use numpy, scipy and
> > skimage for all I need. The only problem is speed, I need the processing
> to
> > be at l5-10 time faster. Convolutions take most of the processing time. I
> > prefer a flexible solution that would speed up also common nonlinear
> filters
> > (i.e. a median filter).
>
> We have a PR in the pipeline for doing really, really fast
> convolutions... but it needs a bit of work.  Would you like to have a
> look at it?
>
> St?fan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111227/fd32f12b/attachment.html>

From tsyu80 at gmail.com  Tue Dec 27 23:24:12 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Tue, 27 Dec 2011 20:24:12 -0800
Subject: Need an advice
In-Reply-To: <CA+oBP_vMAar=0Rd3xHtJff_y8V=+o_Sa47MvJ4OU5dsqN-oN2w@mail.gmail.com>
References: <CA+oBP_tF5YvsH9Nws1ha1BzVa_CXr=BhXZmW7PnhL=ah8O4J=w@mail.gmail.com>
	<CAB=suEnTxQ+ibJ+58dL4XmvqwY+zVP3pRmvDis15b6Th3z3dQQ@mail.gmail.com>
	<CA+oBP_tRVj29jgmyije3uEjg9tHMAqtB1e_y0XKgzaCBuL=pZQ@mail.gmail.com>
	<CABDkGQmU4-OtonbngS6wEzqE85M++Tz0Lr9VRO_B4HySS2HT+g@mail.gmail.com>
	<CA+oBP_vMAar=0Rd3xHtJff_y8V=+o_Sa47MvJ4OU5dsqN-oN2w@mail.gmail.com>
Message-ID: <CAEym_Ho86DawGzVq9LRLFm-eOugjKo0neVRa3MbFPtyR34k9Dw@mail.gmail.com>

On Tue, Dec 27, 2011 at 8:29 AM, Nadav Horesh <nadavh.horesh at gmail.com>wrote:

> How can I get it?
>
>   Nadav
>

The code Stefan mentioned is in an old pull request (PR
#16<https://github.com/scikits-image/scikits-image/pull/16>).
That PR is from before the switch from scikits.image to skimage. I've made
a new branch<https://github.com/tonysyu/scikits-image/commits/skimage-convolution>in
my git repo with the convolution code in the new namespace.

If you're already running skimage from git, then you can use git to clone
this branch:

git remote -f add tonysyu git at github.com:tonysyu/scikits-image.git
git checkout -b convolution tonysyu/skimage-convolution


In case this isn't familiar: The first line adds my git repo to your list
of remotes, and the "-f" flag fetches the tags from my repo (this ensures
that you have the info about my branches). My repo is now added to your
repo as a remote with the name "tonysyu" (you can change this). The second
line creates a new branch "convolution", clones my "skimage-convolution"
branch into it, and checks it out.

Hope that helps,
-Tony


> 2011/12/23 St?fan van der Walt <stefan at sun.ac.za>
>
>> On Thu, Dec 22, 2011 at 10:44 PM, Nadav Horesh <nadavh.horesh at gmail.com>
>> wrote:
>> > The application is not too sophisticated, and I do use numpy, scipy and
>> > skimage for all I need. The only problem is speed, I need the
>> processing to
>> > be at l5-10 time faster. Convolutions take most of the processing time.
>> I
>> > prefer a flexible solution that would speed up also common nonlinear
>> filters
>> > (i.e. a median filter).
>>
>> We have a PR in the pipeline for doing really, really fast
>> convolutions... but it needs a bit of work.  Would you like to have a
>> look at it?
>>
>> St?fan
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111227/173e07d3/attachment.html>

From tsyu80 at gmail.com  Wed Dec 28 02:43:19 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Tue, 27 Dec 2011 23:43:19 -0800
Subject: Need an advice
In-Reply-To: <CAEym_Ho86DawGzVq9LRLFm-eOugjKo0neVRa3MbFPtyR34k9Dw@mail.gmail.com>
References: <CA+oBP_tF5YvsH9Nws1ha1BzVa_CXr=BhXZmW7PnhL=ah8O4J=w@mail.gmail.com>
	<CAB=suEnTxQ+ibJ+58dL4XmvqwY+zVP3pRmvDis15b6Th3z3dQQ@mail.gmail.com>
	<CA+oBP_tRVj29jgmyije3uEjg9tHMAqtB1e_y0XKgzaCBuL=pZQ@mail.gmail.com>
	<CABDkGQmU4-OtonbngS6wEzqE85M++Tz0Lr9VRO_B4HySS2HT+g@mail.gmail.com>
	<CA+oBP_vMAar=0Rd3xHtJff_y8V=+o_Sa47MvJ4OU5dsqN-oN2w@mail.gmail.com>
	<CAEym_Ho86DawGzVq9LRLFm-eOugjKo0neVRa3MbFPtyR34k9Dw@mail.gmail.com>
Message-ID: <CAEym_HqMM8h_eTm9vCDvJC1Xj1dg79Es22r_gZ6zm30TWnU2MQ@mail.gmail.com>

On Tue, Dec 27, 2011 at 8:24 PM, Tony Yu <tsyu80 at gmail.com> wrote:

>
>
> On Tue, Dec 27, 2011 at 8:29 AM, Nadav Horesh <nadavh.horesh at gmail.com>wrote:
>
>> How can I get it?
>>
>>   Nadav
>>
>
> The code Stefan mentioned is in an old pull request (PR #16<https://github.com/scikits-image/scikits-image/pull/16>).
> That PR is from before the switch from scikits.image to skimage. I've made
> a new branch<https://github.com/tonysyu/scikits-image/commits/skimage-convolution>in my git repo with the convolution code in the new namespace.
>
> If you're already running skimage from git, then you can use git to clone
> this branch:
>
> git remote -f add tonysyu git at github.com:tonysyu/scikits-image.git
> git checkout -b convolution tonysyu/skimage-convolution
>
>
> In case this isn't familiar: The first line adds my git repo to your list
> of remotes, and the "-f" flag fetches the tags from my repo (this ensures
> that you have the info about my branches). My repo is now added to your
> repo as a remote with the name "tonysyu" (you can change this). The second
> line creates a new branch "convolution", clones my "skimage-convolution"
> branch into it, and checks it out.
>
> Hope that helps,
> -Tony
>

Oops, I forgot to mention: I added a compile flag that is specific to my
system (In convolution/setup.py there's an include flag '-I/usr/...') that
should probably be removed. Also, I should mention that I haven't gotten
this branch to compile on my system (OSX). I believe it should compile OK
on Linux (after removing the '-I/usr/...' compile flag).

Good luck,
-Tony

>
> 2011/12/23 St?fan van der Walt <stefan at sun.ac.za>
>
>> On Thu, Dec 22, 2011 at 10:44 PM, Nadav Horesh <nadavh.horesh at gmail.com>
>> wrote:
>> > The application is not too sophisticated, and I do use numpy, scipy and
>> > skimage for all I need. The only problem is speed, I need the
>> processing to
>> > be at l5-10 time faster. Convolutions take most of the processing time.
>> I
>> > prefer a flexible solution that would speed up also common nonlinear
>> filters
>> > (i.e. a median filter).
>>
>> We have a PR in the pipeline for doing really, really fast
>> convolutions... but it needs a bit of work.  Would you like to have a
>> look at it?
>>
>> St?fan
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111227/cfdbf18e/attachment.html>

From jeanpatrick.pommier at gmail.com  Wed Dec 28 14:05:50 2011
From: jeanpatrick.pommier at gmail.com (jip)
Date: Wed, 28 Dec 2011 11:05:50 -0800 (PST)
Subject: watershed issue
Message-ID: <7455907.1194.1325099150777.JavaMail.geo-discussion-forums@vbad17>

Dear all,
I try to use watershed implemenation in skimage, compared with scipy as 
follow:

# -*- coding: utf-8 -*-
"""
Created on Thu Dec 22 13:45:46 2011

@author: Jean-Patrick Pommier
Telomeres quantification at low resolution with skimage
"""

import scipy.ndimage as nd
import pylab as plb
import numpy as np

import skimage as sk
import skimage.morphology as mo
import skimage.io as io
import skimage.filter.edges as edges

#import mahotas as mh
#import pymorph


def gray12_to_8(im):
    '''Converts a 12 bits image to 8 bits '''
    i=0.062271062*im
    return np.uint8(i)
    
def Hipass(im,size=9):
    '''returns a hipass filtered image with background >=0 with a gaussian 
filter 
    of size size=9 by default'''
    blur=blur=nd.gaussian_filter(im,size)
    hi=im-1.0*blur-5
    mask=np.copy(hi)
    hi[mask<0]=0
    return hi
    
def gray_dist(im):
    '''Build a pseudo distance map from a high pass filtered image suitable
    for watershed'''
    f=Hipass(im,9)
    dist=f.max()-f
    dist -= dist.min()
    dist = dist/float(dist.ptp()) * 255
    dist = dist.astype(np.uint8)
    return dist
#==============================================================================
# images 
#==============================================================================
path="/home/claire/Applications/ImagesTest/JPP50/16/"
CC="DAPI/"
PR="CY3/" 
im="1.TIF"

#sk.io.use_plugin('gdal', 'imread') 
sk.io.use_plugin('freeimage', 'imread') 
sk.io.use_plugin('matplotlib', 'imshow') 
dapi=io.imread(path+CC+im)
cy3=io.imread(path+PR+im)

#=============================================================================
# Extracting known nuclei
#==============================================================================
nuc=dapi[215:264,1151:1198]
telo=cy3[215:264,1151:1198]
telo=np.uint16(telo)
#==============================================================================
# Telomeres Segmentation with skimage & ndimage
print telo.dtype

se=mo.disk(7)
top=mo.greyscale_white_top_hat(gray12_to_8(telo),se)
#print top.min(),top.max(),top.dtype
hi=np.uint8(Hipass(top,size=9))
#print hi.min(), hi.max(),hi.dtype
dist=nd.distance_transform_bf(top>10)
bassin_dist=np.uint16(dist.max()-dist)
bassin_hi=hi.max()-hi
remax=mo.is_local_maximum(bassin_hi,hi>6)
markers,n=nd.label(remax)
print n, 'spots detected'
edgesmap=edges.sobel(hi)
seg=sk.morphology.watershed(edgesmap,markers,top>30)
segn=nd.watershed_ift(bassin_hi,markers)
segn_mark_dist=nd.watershed_ift(bassin_dist,markers)
#==============================================================================
# Quantification
#==============================================================================
print top.shape,top.dtype
#print np.shape(seg),np.dtype(seg)
#spots_I=nd.measurements.sum(top,seg)
#print spots_I
#==============================================================================
# 
#==============================================================================
plb.figure(1)
plb.subplot(341,frameon=False, xticks=[], yticks=[])
plb.title('raw 12bits')
plb.imshow(telo)
plb.subplot(342,frameon=False, xticks=[], yticks=[])
plb.title('top Hat')
plb.imshow(top)
plb.subplot(343,frameon=False, xticks=[], yticks=[])
plb.title('hiP')
plb.imshow(hi)
plb.subplot(344,frameon=False, xticks=[], yticks=[])
plb.title('regional max')
plb.imshow(remax,interpolation=None)
plb.subplot(345,frameon=False, xticks=[], yticks=[])
plb.title('markers')
plb.imshow(markers,interpolation=None)
plb.subplot(346,frameon=False, xticks=[], yticks=[])
plb.title('bassin=hi')
plb.imshow(bassin_hi,interpolation=None)
plb.subplot(347,frameon=False, xticks=[], yticks=[])
plb.title('bassin dist')
plb.imshow(bassin_dist,interpolation=None)
plb.subplot(348,frameon=False, xticks=[], yticks=[])
plb.title('hi+mark (nd)')
plb.imshow(segn,interpolation=None)
plb.subplot(349,frameon=False, xticks=[], yticks=[])
plb.title('sobel (sk)')
plb.imshow(edgesmap,interpolation=None)
plb.subplot(3,4,10,frameon=False, xticks=[], yticks=[])
plb.title('sob+mark (sk)')
plb.imshow(seg,interpolation=None)
plb.subplot(3,4,12,frameon=False, xticks=[], yticks=[])
plb.title('dist+mark (nd)')
plb.imshow(segn_mark_dist,interpolation=None)
 
plb.show()


<https://lh5.googleusercontent.com/-OBPfUOGJNok/TvtKO_6q20I/AAAAAAAAAqw/6VX7eIrySXA/s1600/watershedissue.png>

I get a strange result, see the "sob+mark (sk)" image, compared to the 
segmentations obtained with the scipy implementation.

Is it a skimage bug ? Best regards.

Jean-Patrick 

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

From nadavh.horesh at gmail.com  Wed Dec 28 10:38:32 2011
From: nadavh.horesh at gmail.com (Nadav Horesh)
Date: Wed, 28 Dec 2011 17:38:32 +0200
Subject: Need an advice
In-Reply-To: <CAEym_HqMM8h_eTm9vCDvJC1Xj1dg79Es22r_gZ6zm30TWnU2MQ@mail.gmail.com>
References: <CA+oBP_tF5YvsH9Nws1ha1BzVa_CXr=BhXZmW7PnhL=ah8O4J=w@mail.gmail.com>
	<CAB=suEnTxQ+ibJ+58dL4XmvqwY+zVP3pRmvDis15b6Th3z3dQQ@mail.gmail.com>
	<CA+oBP_tRVj29jgmyije3uEjg9tHMAqtB1e_y0XKgzaCBuL=pZQ@mail.gmail.com>
	<CABDkGQmU4-OtonbngS6wEzqE85M++Tz0Lr9VRO_B4HySS2HT+g@mail.gmail.com>
	<CA+oBP_vMAar=0Rd3xHtJff_y8V=+o_Sa47MvJ4OU5dsqN-oN2w@mail.gmail.com>
	<CAEym_Ho86DawGzVq9LRLFm-eOugjKo0neVRa3MbFPtyR34k9Dw@mail.gmail.com>
	<CAEym_HqMM8h_eTm9vCDvJC1Xj1dg79Es22r_gZ6zm30TWnU2MQ@mail.gmail.com>
Message-ID: <CA+oBP_u0D+0NKp=Wsdsvr9iJAY7Kv+6wZBQ17=SCUu=78MM_hw@mail.gmail.com>

I compiled after setting the flags for a core2 linux machine.  A quick and
dirty benchmark showed a x2 improvement over scipy.signal.sepfir2d.
I think that are some declaration errors in the python code (for instance I
think that the convolution __init__.py should be

from ext import pyconvolve

instead of

from ext import convolve

 I'll take a closer look later.

Thank you,

   Nadav.


2011/12/28 Tony Yu <tsyu80 at gmail.com>

>
>
> On Tue, Dec 27, 2011 at 8:24 PM, Tony Yu <tsyu80 at gmail.com> wrote:
>
>>
>>
>> On Tue, Dec 27, 2011 at 8:29 AM, Nadav Horesh <nadavh.horesh at gmail.com>wrote:
>>
>>> How can I get it?
>>>
>>>   Nadav
>>>
>>
>> The code Stefan mentioned is in an old pull request (PR #16<https://github.com/scikits-image/scikits-image/pull/16>).
>> That PR is from before the switch from scikits.image to skimage. I've made
>> a new branch<https://github.com/tonysyu/scikits-image/commits/skimage-convolution>in my git repo with the convolution code in the new namespace.
>>
>> If you're already running skimage from git, then you can use git to clone
>> this branch:
>>
>> git remote -f add tonysyu git at github.com:tonysyu/scikits-image.git
>> git checkout -b convolution tonysyu/skimage-convolution
>>
>>
>> In case this isn't familiar: The first line adds my git repo to your list
>> of remotes, and the "-f" flag fetches the tags from my repo (this ensures
>> that you have the info about my branches). My repo is now added to your
>> repo as a remote with the name "tonysyu" (you can change this). The second
>> line creates a new branch "convolution", clones my "skimage-convolution"
>> branch into it, and checks it out.
>>
>> Hope that helps,
>> -Tony
>>
>
> Oops, I forgot to mention: I added a compile flag that is specific to my
> system (In convolution/setup.py there's an include flag '-I/usr/...') that
> should probably be removed. Also, I should mention that I haven't gotten
> this branch to compile on my system (OSX). I believe it should compile OK
> on Linux (after removing the '-I/usr/...' compile flag).
>
> Good luck,
> -Tony
>
>>
>> 2011/12/23 St?fan van der Walt <stefan at sun.ac.za>
>>
>>> On Thu, Dec 22, 2011 at 10:44 PM, Nadav Horesh <nadavh.horesh at gmail.com>
>>> wrote:
>>> > The application is not too sophisticated, and I do use numpy, scipy and
>>> > skimage for all I need. The only problem is speed, I need the
>>> processing to
>>> > be at l5-10 time faster. Convolutions take most of the processing
>>> time. I
>>> > prefer a flexible solution that would speed up also common nonlinear
>>> filters
>>> > (i.e. a median filter).
>>>
>>> We have a PR in the pipeline for doing really, really fast
>>> convolutions... but it needs a bit of work.  Would you like to have a
>>> look at it?
>>>
>>> St?fan
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111228/c0fd6975/attachment.html>

From emmanuelle.gouillart at nsup.org  Wed Dec 28 15:00:44 2011
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Wed, 28 Dec 2011 21:00:44 +0100
Subject: watershed issue
In-Reply-To: <7455907.1194.1325099150777.JavaMail.geo-discussion-forums@vbad17>
References: <7455907.1194.1325099150777.JavaMail.geo-discussion-forums@vbad17>
Message-ID: <20111228200044.GA31953@phare.normalesup.org>

Hello Jean-Patrick,

could you please send a minimal self-contained example (including data)
that reproduces the behaviour you observe? Right now it's quite difficult
to understand what's going on, because there are a lot of pre-processing
steps before the watershed, and we don't have the data to run the script.

In the code below you don't use the same elevation function (1st argument
of the watershed) for scipy's and skimage's watersheds, do you also get
different results when you use the same array for the two watersheds?

Cheers,
Emmanuelle


On Wed, Dec 28, 2011 at 11:05:50AM -0800, jip wrote:
>    Dear all,
>    I try to use watershed implemenation in skimage, compared with scipy as
>    follow:

>    # -*- coding: utf-8 -*-
>    """
>    Created on Thu Dec 22 13:45:46 2011

>    @author: Jean-Patrick Pommier
>    Telomeres quantification at low resolution with skimage
>    """

>    import scipy.ndimage as nd
>    import pylab as plb
>    import numpy as np

>    import skimage as sk
>    import skimage.morphology as mo
>    import skimage.io as io
>    import skimage.filter.edges as edges

>    #import mahotas as mh
>    #import pymorph

>    def gray12_to_8(im):
>    ?????????????????? '''Converts a 12 bits image to 8 bits '''
>    ?????????????????? i=0.062271062*im
>    ?????????????????? return np.uint8(i)
>    ??????????????????
>    def Hipass(im,size=9):
>    ?????????????????? '''returns a hipass filtered image with background >=0 with a gaussian
>    filter
>    ?????????????????? of size size=9 by default'''
>    ?????????????????? blur=blur=nd.gaussian_filter(im,size)
>    ?????????????????? hi=im-1.0*blur-5
>    ?????????????????? mask=np.copy(hi)
>    ?????????????????? hi[mask<0]=0
>    ?????????????????? return hi
>    ??????????????????
>    def gray_dist(im):
>    ?????????????????? '''Build a pseudo distance map from a high pass filtered image
>    suitable
>    ?????????????????? for watershed'''
>    ?????????????????? f=Hipass(im,9)
>    ?????????????????? dist=f.max()-f
>    ?????????????????? dist -= dist.min()
>    ?????????????????? dist = dist/float(dist.ptp()) * 255
>    ?????????????????? dist = dist.astype(np.uint8)
>    ?????????????????? return dist
>    #==============================================================================
>    # images
>    #==============================================================================
>    path="/home/claire/Applications/ImagesTest/JPP50/16/"
>    CC="DAPI/"
>    PR="CY3/"
>    im="1.TIF"

>    #sk.io.use_plugin('gdal', 'imread')
>    sk.io.use_plugin('freeimage', 'imread')
>    sk.io.use_plugin('matplotlib', 'imshow')
>    dapi=io.imread(path+CC+im)
>    cy3=io.imread(path+PR+im)

>    #=============================================================================
>    # Extracting known nuclei
>    #==============================================================================
>    nuc=dapi[215:264,1151:1198]
>    telo=cy3[215:264,1151:1198]
>    telo=np.uint16(telo)
>    #==============================================================================
>    # Telomeres Segmentation with skimage & ndimage
>    print telo.dtype

>    se=mo.disk(7)
>    top=mo.greyscale_white_top_hat(gray12_to_8(telo),se)
>    #print top.min(),top.max(),top.dtype
>    hi=np.uint8(Hipass(top,size=9))
>    #print hi.min(), hi.max(),hi.dtype
>    dist=nd.distance_transform_bf(top>10)
>    bassin_dist=np.uint16(dist.max()-dist)
>    bassin_hi=hi.max()-hi
>    remax=mo.is_local_maximum(bassin_hi,hi>6)
>    markers,n=nd.label(remax)
>    print n, 'spots detected'
>    edgesmap=edges.sobel(hi)
>    seg=sk.morphology.watershed(edgesmap,markers,top>30)
>    segn=nd.watershed_ift(bassin_hi,markers)
>    segn_mark_dist=nd.watershed_ift(bassin_dist,markers)
>    #==============================================================================
>    # Quantification
>    #==============================================================================
>    print top.shape,top.dtype
>    #print np.shape(seg),np.dtype(seg)
>    #spots_I=nd.measurements.sum(top,seg)
>    #print spots_I
>    #==============================================================================

>    #==============================================================================
>    plb.figure(1)
>    plb.subplot(341,frameon=False, xticks=[], yticks=[])
>    plb.title('raw 12bits')
>    plb.imshow(telo)
>    plb.subplot(342,frameon=False, xticks=[], yticks=[])
>    plb.title('top Hat')
>    plb.imshow(top)
>    plb.subplot(343,frameon=False, xticks=[], yticks=[])
>    plb.title('hiP')
>    plb.imshow(hi)
>    plb.subplot(344,frameon=False, xticks=[], yticks=[])
>    plb.title('regional max')
>    plb.imshow(remax,interpolation=None)
>    plb.subplot(345,frameon=False, xticks=[], yticks=[])
>    plb.title('markers')
>    plb.imshow(markers,interpolation=None)
>    plb.subplot(346,frameon=False, xticks=[], yticks=[])
>    plb.title('bassin=hi')
>    plb.imshow(bassin_hi,interpolation=None)
>    plb.subplot(347,frameon=False, xticks=[], yticks=[])
>    plb.title('bassin dist')
>    plb.imshow(bassin_dist,interpolation=None)
>    plb.subplot(348,frameon=False, xticks=[], yticks=[])
>    plb.title('hi+mark (nd)')
>    plb.imshow(segn,interpolation=None)
>    plb.subplot(349,frameon=False, xticks=[], yticks=[])
>    plb.title('sobel (sk)')
>    plb.imshow(edgesmap,interpolation=None)
>    plb.subplot(3,4,10,frameon=False, xticks=[], yticks=[])
>    plb.title('sob+mark (sk)')
>    plb.imshow(seg,interpolation=None)
>    plb.subplot(3,4,12,frameon=False, xticks=[], yticks=[])
>    plb.title('dist+mark (nd)')
>    plb.imshow(segn_mark_dist,interpolation=None)

>    plb.show()

>                                     [1][IMG]

>    I get a strange result, see the "sob+mark (sk)" image, compared to the
>    segmentations obtained with the scipy implementation.

>    Is it a skimage bug ?  Best regards.

>    Jean-Patrick

> References

>    Visible links
>    1. https://lh5.googleusercontent.com/-OBPfUOGJNok/TvtKO_6q20I/AAAAAAAAAqw/6VX7eIrySXA/s1600/watershedissue.png


From tsyu80 at gmail.com  Thu Dec 29 14:26:33 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Thu, 29 Dec 2011 11:26:33 -0800
Subject: Rescale intensity function [was: Asymmetric behavior in dtype conversion]
Message-ID: <CAEym_HpCCeYwMavJbuo=O_tTRdi4wbnYycDuGzc8pDsYLTnhEA@mail.gmail.com>

On Wed, Dec 21, 2011 at 11:16 AM, Tony Yu <tsyu80 at gmail.com> wrote:

>
>
> On Wed, Dec 21, 2011 at 9:15 AM, Christoph Gohlke <cjgohlke at gmail.com>wrote:
>
>> On 12/21/2011 8:41 AM, St?fan van der Walt wrote:
>>
>>> On Wed, Dec 21, 2011 at 1:30 AM, Tony Yu<tsyu80 at gmail.com>  wrote:
>>>
>>>> I think one of two things should happen:
>>>>
>>>> 1)
>>>>     [uint ->  int]: expand uint to *full* range of int.
>>>>     [int ->  uint]: unchanged (squeeze into range of uint)
>>>>
>>>> 2)
>>>>     [uint ->  int]: unchanged (fill *positive* range of int)
>>>>     [int ->  uint]: clip negative values from int
>>>>
>>> People very often represent images in signed integers, even though
>>> they only manipulate positive values, e.g. storing 0-255 in int8.  So
>>> the conversion to signed should not spread those values over the
>>> entire range.  However, I think you're right that we should add the
>>> clipping in 2 to avoid the conversion bias, along with a nice big
>>> warning.
>>>
>>> Regards
>>> St?fan
>>>
>>>
>> At this point it might be worth considering other cases that are
>> currently not well handled by skimage dtype conversions. For example:
>>
>> 1) float images in the range 0.0 - 255.0
>> 2) 1 bit images stored as (u)int
>> 3) 10 and 12 bit images stored as uint16
>>
>> Christoph
>>
>
> I've definitely been bit by example 1 many times.
>
> I think we should check that float images are between 0 and 1 in
> ``util.dtype._convert`` (and either warn or raise an error), but we
> shouldn't have to worry about it elsewhere. That doesn't really solve the
> issue, so...
>
> Presumably, the user would know that their data is in a slightly weird
> format (especially for examples 2 and 3), correct? If so, we could just add
> a function (maybe "rescale_intensity" or "stretch_intensity" or
> "normalize_intensity" or something similar) that takes the image and the
> input intensity range as inputs. For example: ``norm_intensity(image_u12,
> (0, 4096))``. Then, we could rescale the intensity to fit into the
> intensity range of the input dtype. We could also add special values [e.g.
> 1) 'uint8', 2) 'bool', 3) 'uint10'/'uint12'] for the second parameter, and
> these values could pull the associated range from a table.
>
> Then, it would be the responsibility of the user to call this function
> before converting dtypes.
>
> -Tony
>


I forget that not everyone gets notified when I post a pull request. In PR
107 <https://github.com/scikits-image/scikits-image/pull/107> I add a
`rescale_intensity` function, which implements my earlier suggestion.
Christoph: Does this solve (or at least mitigate) the problems with weird
data types?

I have yet to implement "special" input ranges---i.e. input range can be a
dtype string and map that string to a range. The implementation is easy,
but I'm not sure what data types should be supported: 1bit (or bool?),
uint10, uint12,...

Comments/suggestions?

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

From jeanpatrick.pommier at gmail.com  Fri Dec 30 08:39:25 2011
From: jeanpatrick.pommier at gmail.com (jip)
Date: Fri, 30 Dec 2011 05:39:25 -0800 (PST)
Subject: watershed issue
In-Reply-To: <20111228200044.GA31953@phare.normalesup.org>
References: <7455907.1194.1325099150777.JavaMail.geo-discussion-forums@vbad17>
 <20111228200044.GA31953@phare.normalesup.org>
Message-ID: <31888480.2012.1325252365968.JavaMail.geo-discussion-forums@vbgw2>

Dear Emmanuelle,

Sorry for the delay.
I have rewritten a clearer script 
<https://docs.google.com/open?id=0B-YDFMbEy1grODU1Y2U0OTgtMzk1MS00MzkxLTliOWItYmMyOTNlOGI3ODRj>I 
hope. 
First, it takes a 12bits image<https://docs.google.com/open?id=0B-YDFMbEy1grNWJlYTkwYzYtMjk0ZS00NGVlLWFjMzktMmU3OWU1ODgwMDhm>(cy3 in the archive), isolates a region andremoves the background<https://docs.google.com/open?id=0B-YDFMbEy1grNDZjOWZjZjAtMGVmMS00ZTM2LTgwYzctMjZkM2JiMjFmYjBh>
.
Regional maxima are found to get markers for watershed.
Three kind of maps are also prepared.
Each map, with the markers image, is submitted to the watershed 
algorithm.Segmentation is performed with watershed as indicated here<http://scikits-image.org/docs/dev/auto_examples/plot_watershed.html#example-plot-watershed-py>, 
as follow:
segmentation=watershed(map,markers,mask)
map:grayscale image
markers:label image
mask:binary image

The skimage and the scipy implementation are tested with the following 
result (see image<https://docs.google.com/open?id=0B-YDFMbEy1grZmExNjU5NTAtMWIyZi00ZTAxLWJjZGUtYmNiY2ZkODdmN2Fh>
).

Thank you for your help.
Best regards

Jean-Patrick Pommier
http://dip4fish.blogspot.com/

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

From tsyu80 at gmail.com  Fri Dec 30 11:01:16 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Fri, 30 Dec 2011 08:01:16 -0800
Subject: watershed issue
In-Reply-To: <31888480.2012.1325252365968.JavaMail.geo-discussion-forums@vbgw2>
References: <7455907.1194.1325099150777.JavaMail.geo-discussion-forums@vbad17>
	<20111228200044.GA31953@phare.normalesup.org>
	<31888480.2012.1325252365968.JavaMail.geo-discussion-forums@vbgw2>
Message-ID: <CAEym_HpG25PrtCHtQbg41iMvyKei5his6seZpqJbOzEiqzq3FA@mail.gmail.com>

On Fri, Dec 30, 2011 at 5:39 AM, jip <jeanpatrick.pommier at gmail.com> wrote:

> Dear Emmanuelle,
>
> Sorry for the delay.
> I have rewritten a clearer script
> <https://docs.google.com/open?id=0B-YDFMbEy1grODU1Y2U0OTgtMzk1MS00MzkxLTliOWItYmMyOTNlOGI3ODRj>I
> hope.
> First, it takes a 12bits image<https://docs.google.com/open?id=0B-YDFMbEy1grNWJlYTkwYzYtMjk0ZS00NGVlLWFjMzktMmU3OWU1ODgwMDhm>(cy3 in the archive), isolates a region andremoves the background<https://docs.google.com/open?id=0B-YDFMbEy1grNDZjOWZjZjAtMGVmMS00ZTM2LTgwYzctMjZkM2JiMjFmYjBh>
> .
> Regional maxima are found to get markers for watershed.
> Three kind of maps are also prepared.
> Each map, with the markers image, is submitted to the watershed
> algorithm.Segmentation is performed with watershed as indicated here<http://scikits-image.org/docs/dev/auto_examples/plot_watershed.html#example-plot-watershed-py>,
> as follow:
> segmentation=watershed(map,markers,mask)
> map:grayscale image
> markers:label image
> mask:binary image
>
>
There's a small typo here: watershed should be called as:

     watershed(map, makers, mask=mask)

More specifically, in your code, you have:

    sk.morphology.watershed(bassin_hi,markers,top>30)

but it should be called as:

    sk.morphology.watershed(bassin_hi,markers,mask=top>30)

Without specifying `mask=`, you're setting the connectivity parameter in
watershed. Even with this correction, something seems to be off since
watershed seems to return blank images. Without the masks, it gives what I
would expect. I'm not sure what's going on the masked output.

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

From tsyu80 at gmail.com  Fri Dec 30 11:22:18 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Fri, 30 Dec 2011 08:22:18 -0800
Subject: watershed issue
In-Reply-To: <CAEym_HpG25PrtCHtQbg41iMvyKei5his6seZpqJbOzEiqzq3FA@mail.gmail.com>
References: <7455907.1194.1325099150777.JavaMail.geo-discussion-forums@vbad17>
	<20111228200044.GA31953@phare.normalesup.org>
	<31888480.2012.1325252365968.JavaMail.geo-discussion-forums@vbgw2>
	<CAEym_HpG25PrtCHtQbg41iMvyKei5his6seZpqJbOzEiqzq3FA@mail.gmail.com>
Message-ID: <CAEym_HpN-h_sP9SgL=1OHTapcGAqKe2s9NX3-tbseayuC4TsbQ@mail.gmail.com>

On Fri, Dec 30, 2011 at 8:01 AM, Tony Yu <tsyu80 at gmail.com> wrote:

>
>
> On Fri, Dec 30, 2011 at 5:39 AM, jip <jeanpatrick.pommier at gmail.com>wrote:
>
>> Dear Emmanuelle,
>>
>> Sorry for the delay.
>> I have rewritten a clearer script
>> <https://docs.google.com/open?id=0B-YDFMbEy1grODU1Y2U0OTgtMzk1MS00MzkxLTliOWItYmMyOTNlOGI3ODRj>I
>> hope.
>> First, it takes a 12bits image<https://docs.google.com/open?id=0B-YDFMbEy1grNWJlYTkwYzYtMjk0ZS00NGVlLWFjMzktMmU3OWU1ODgwMDhm>(cy3 in the archive), isolates a region andremoves the background<https://docs.google.com/open?id=0B-YDFMbEy1grNDZjOWZjZjAtMGVmMS00ZTM2LTgwYzctMjZkM2JiMjFmYjBh>
>> .
>> Regional maxima are found to get markers for watershed.
>> Three kind of maps are also prepared.
>> Each map, with the markers image, is submitted to the watershed
>> algorithm.Segmentation is performed with watershed as indicated here<http://scikits-image.org/docs/dev/auto_examples/plot_watershed.html#example-plot-watershed-py>,
>> as follow:
>> segmentation=watershed(map,markers,mask)
>> map:grayscale image
>> markers:label image
>> mask:binary image
>>
>>
> There's a small typo here: watershed should be called as:
>
>      watershed(map, makers, mask=mask)
>
> More specifically, in your code, you have:
>
>     sk.morphology.watershed(bassin_hi,markers,top>30)
>
> but it should be called as:
>
>     sk.morphology.watershed(bassin_hi,markers,mask=top>30)
>
> Without specifying `mask=`, you're setting the connectivity parameter in
> watershed. Even with this correction, something seems to be off since
> watershed seems to return blank images. Without the masks, it gives what I
> would expect. I'm not sure what's going on the masked output.
>
> -Tony
>
>
Actually, I think this masked output is correct: All the markers seem to
land in the masked-out regions.

>>> mask = top > 30
>>> print np.any(marker * mask)
False

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

From tsyu80 at gmail.com  Fri Dec 30 11:46:31 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Fri, 30 Dec 2011 08:46:31 -0800
Subject: Need an advice
In-Reply-To: <CA+oBP_uLt-2WWh65CCt1Q7LsipamDvE65=9-uZWMRUtgA8xoAQ@mail.gmail.com>
References: <CA+oBP_tF5YvsH9Nws1ha1BzVa_CXr=BhXZmW7PnhL=ah8O4J=w@mail.gmail.com>
	<CAB=suEnTxQ+ibJ+58dL4XmvqwY+zVP3pRmvDis15b6Th3z3dQQ@mail.gmail.com>
	<CA+oBP_tRVj29jgmyije3uEjg9tHMAqtB1e_y0XKgzaCBuL=pZQ@mail.gmail.com>
	<CABDkGQmU4-OtonbngS6wEzqE85M++Tz0Lr9VRO_B4HySS2HT+g@mail.gmail.com>
	<CA+oBP_vMAar=0Rd3xHtJff_y8V=+o_Sa47MvJ4OU5dsqN-oN2w@mail.gmail.com>
	<CAEym_Ho86DawGzVq9LRLFm-eOugjKo0neVRa3MbFPtyR34k9Dw@mail.gmail.com>
	<CAEym_HqMM8h_eTm9vCDvJC1Xj1dg79Es22r_gZ6zm30TWnU2MQ@mail.gmail.com>
	<CA+oBP_u0D+0NKp=Wsdsvr9iJAY7Kv+6wZBQ17=SCUu=78MM_hw@mail.gmail.com>
	<CA+oBP_uLt-2WWh65CCt1Q7LsipamDvE65=9-uZWMRUtgA8xoAQ@mail.gmail.com>
Message-ID: <CAEym_HoaxTgzUBCYMtjNtyeqc=dnDvyb0i+mFUPtbVznGVWRnQ@mail.gmail.com>

On Fri, Dec 30, 2011 at 8:20 AM, Nadav Horesh <nadavh.horesh at gmail.com>wrote:

> Remarks for the convolution subpackage:
> 1. The __init__.py should be probably changed to
>
> from ext import pyconvolve as convolve
>

Agreed. Alternatively, the c-method could be renamed so that the python
method in ext can be named convolve.

>
> 2. The test_convolution.py file is very instructive. It should be polished
> a bit. I think it would be worthwhile to add also scipy.signal.sepfir2d
> and cv2.sepFilter2D to the test.
>

> 3. I found the convolve speed in par with cv.convolve2d (it can be slower
> or faster depending on the kernel)
>
>    Nadav
>

Thanks for testing the code.

I've got the code compiling on my system now, so I was able to clean up a
few things. Could you update to what's currently on my skimage-convolution
branch to check that it builds on your system? If not, what flags do you
have to change/add to get it to compile?

-Tony

P.S. If any one else is building this on OS X: ppc compatible builds is
turned on by default (at least on my system). This should be turned off
before building. Add the following line to ~/.profile, or just run it right
before building:

export ARCH_FLAGS="-arch i386 -arch x86_64"




>
> 2011/12/28 Nadav Horesh <nadavh.horesh at gmail.com>
>
>> I compiled after setting the flags for a core2 linux machine.  A quick
>> and dirty benchmark showed a x2 improvement over scipy.signal.sepfir2d.
>> I think that are some declaration errors in the python code (for instance
>> I think that the convolution __init__.py should be
>>
>> from ext import pyconvolve
>>
>> instead of
>>
>> from ext import convolve
>>
>>  I'll take a closer look later.
>>
>> Thank you,
>>
>>    Nadav.
>>
>>
>>
>> 2011/12/28 Tony Yu <tsyu80 at gmail.com>
>>
>>>
>>>
>>> On Tue, Dec 27, 2011 at 8:24 PM, Tony Yu <tsyu80 at gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Dec 27, 2011 at 8:29 AM, Nadav Horesh <nadavh.horesh at gmail.com>wrote:
>>>>
>>>>> How can I get it?
>>>>>
>>>>>   Nadav
>>>>>
>>>>
>>>> The code Stefan mentioned is in an old pull request (PR #16<https://github.com/scikits-image/scikits-image/pull/16>).
>>>> That PR is from before the switch from scikits.image to skimage. I've made
>>>> a new branch<https://github.com/tonysyu/scikits-image/commits/skimage-convolution>in my git repo with the convolution code in the new namespace.
>>>>
>>>> If you're already running skimage from git, then you can use git to
>>>> clone this branch:
>>>>
>>>> git remote -f add tonysyu git at github.com:tonysyu/scikits-image.git
>>>> git checkout -b convolution tonysyu/skimage-convolution
>>>>
>>>>
>>>> In case this isn't familiar: The first line adds my git repo to your
>>>> list of remotes, and the "-f" flag fetches the tags from my repo (this
>>>> ensures that you have the info about my branches). My repo is now added to
>>>> your repo as a remote with the name "tonysyu" (you can change this). The
>>>> second line creates a new branch "convolution", clones my
>>>> "skimage-convolution" branch into it, and checks it out.
>>>>
>>>> Hope that helps,
>>>> -Tony
>>>>
>>>
>>> Oops, I forgot to mention: I added a compile flag that is specific to my
>>> system (In convolution/setup.py there's an include flag '-I/usr/...') that
>>> should probably be removed. Also, I should mention that I haven't gotten
>>> this branch to compile on my system (OSX). I believe it should compile OK
>>> on Linux (after removing the '-I/usr/...' compile flag).
>>>
>>> Good luck,
>>> -Tony
>>>
>>>>
>>>> 2011/12/23 St?fan van der Walt <stefan at sun.ac.za>
>>>>
>>>>> On Thu, Dec 22, 2011 at 10:44 PM, Nadav Horesh <
>>>>> nadavh.horesh at gmail.com> wrote:
>>>>> > The application is not too sophisticated, and I do use numpy, scipy
>>>>> and
>>>>> > skimage for all I need. The only problem is speed, I need the
>>>>> processing to
>>>>> > be at l5-10 time faster. Convolutions take most of the processing
>>>>> time. I
>>>>> > prefer a flexible solution that would speed up also common nonlinear
>>>>> filters
>>>>> > (i.e. a median filter).
>>>>>
>>>>> We have a PR in the pipeline for doing really, really fast
>>>>> convolutions... but it needs a bit of work.  Would you like to have a
>>>>> look at it?
>>>>>
>>>>> St?fan
>>>>>
>>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111230/32ce2e75/attachment.html>

From stefan at sun.ac.za  Fri Dec 30 12:13:52 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 30 Dec 2011 09:13:52 -0800
Subject: Need an advice
In-Reply-To: <CA+oBP_uLt-2WWh65CCt1Q7LsipamDvE65=9-uZWMRUtgA8xoAQ@mail.gmail.com>
References: <CA+oBP_tF5YvsH9Nws1ha1BzVa_CXr=BhXZmW7PnhL=ah8O4J=w@mail.gmail.com>
 <CAB=suEnTxQ+ibJ+58dL4XmvqwY+zVP3pRmvDis15b6Th3z3dQQ@mail.gmail.com>
 <CA+oBP_tRVj29jgmyije3uEjg9tHMAqtB1e_y0XKgzaCBuL=pZQ@mail.gmail.com>
 <CABDkGQmU4-OtonbngS6wEzqE85M++Tz0Lr9VRO_B4HySS2HT+g@mail.gmail.com>
 <CA+oBP_vMAar=0Rd3xHtJff_y8V=+o_Sa47MvJ4OU5dsqN-oN2w@mail.gmail.com>
 <CAEym_Ho86DawGzVq9LRLFm-eOugjKo0neVRa3MbFPtyR34k9Dw@mail.gmail.com>
 <CAEym_HqMM8h_eTm9vCDvJC1Xj1dg79Es22r_gZ6zm30TWnU2MQ@mail.gmail.com>
 <CA+oBP_u0D+0NKp=Wsdsvr9iJAY7Kv+6wZBQ17=SCUu=78MM_hw@mail.gmail.com> <CA+oBP_uLt-2WWh65CCt1Q7LsipamDvE65=9-uZWMRUtgA8xoAQ@mail.gmail.com>
Message-ID: <CABDkGQkvCvc00QXyKeG07iqX=zNSm0t_tWUvMSaQLko2B786wQ@mail.gmail.com>

On Fri, Dec 30, 2011 at 8:20 AM, Nadav Horesh <nadavh.horesh at gmail.com> wrote:
> Remarks for the convolution subpackage:
> 1. The __init__.py should be probably changed to
>
> from ext import pyconvolve as convolve
>
> 2. The test_convolution.py file is very instructive. It should be polished a
> bit. I think it would be worthwhile to add also scipy.signal.sepfir2d
> and?cv2.sepFilter2D to the test.
>
> 3. I found the convolve speed in par with cv.convolve2d (it can be slower or
> faster depending on the kernel)

That's great.  Do you know how we can reliably make this code compile
on all supported platforms?

St?fan


From tsyu80 at gmail.com  Fri Dec 30 14:05:02 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Fri, 30 Dec 2011 14:05:02 -0500
Subject: Need an advice
In-Reply-To: <CABL7CQjhRbe=yXHed5C-WQYgrfKvEpj1t_YeihGUMxigEaf2Zg@mail.gmail.com>
References: <CA+oBP_tF5YvsH9Nws1ha1BzVa_CXr=BhXZmW7PnhL=ah8O4J=w@mail.gmail.com>
	<CAB=suEnTxQ+ibJ+58dL4XmvqwY+zVP3pRmvDis15b6Th3z3dQQ@mail.gmail.com>
	<CA+oBP_tRVj29jgmyije3uEjg9tHMAqtB1e_y0XKgzaCBuL=pZQ@mail.gmail.com>
	<CABDkGQmU4-OtonbngS6wEzqE85M++Tz0Lr9VRO_B4HySS2HT+g@mail.gmail.com>
	<CA+oBP_vMAar=0Rd3xHtJff_y8V=+o_Sa47MvJ4OU5dsqN-oN2w@mail.gmail.com>
	<CAEym_Ho86DawGzVq9LRLFm-eOugjKo0neVRa3MbFPtyR34k9Dw@mail.gmail.com>
	<CAEym_HqMM8h_eTm9vCDvJC1Xj1dg79Es22r_gZ6zm30TWnU2MQ@mail.gmail.com>
	<CA+oBP_u0D+0NKp=Wsdsvr9iJAY7Kv+6wZBQ17=SCUu=78MM_hw@mail.gmail.com>
	<CA+oBP_uLt-2WWh65CCt1Q7LsipamDvE65=9-uZWMRUtgA8xoAQ@mail.gmail.com>
	<CAEym_HoaxTgzUBCYMtjNtyeqc=dnDvyb0i+mFUPtbVznGVWRnQ@mail.gmail.com>
	<CABL7CQjhRbe=yXHed5C-WQYgrfKvEpj1t_YeihGUMxigEaf2Zg@mail.gmail.com>
Message-ID: <CAEym_Hqzj1wX9i27Y64Wr135h_kehNVh=rm70rv2y1jKf2rqPA@mail.gmail.com>

On Fri, Dec 30, 2011 at 1:19 PM, Ralf Gommers
<ralf.gommers at googlemail.com>wrote:

>
>
> On Fri, Dec 30, 2011 at 5:46 PM, Tony Yu <tsyu80 at gmail.com> wrote:
>
>>
>>
>> On Fri, Dec 30, 2011 at 8:20 AM, Nadav Horesh <nadavh.horesh at gmail.com>wrote:
>>
>>> Remarks for the convolution subpackage:
>>> 1. The __init__.py should be probably changed to
>>>
>>> from ext import pyconvolve as convolve
>>>
>>
>> Agreed. Alternatively, the c-method could be renamed so that the python
>> method in ext can be named convolve.
>>
>>>
>>> 2. The test_convolution.py file is very instructive. It should be
>>> polished a bit. I think it would be worthwhile to add also
>>> scipy.signal.sepfir2d and cv2.sepFilter2D to the test.
>>>
>>
>>> 3. I found the convolve speed in par with cv.convolve2d (it can be
>>> slower or faster depending on the kernel)
>>>
>>>    Nadav
>>>
>>
>> Thanks for testing the code.
>>
>> I've got the code compiling on my system now, so I was able to clean up a
>> few things. Could you update to what's currently on my skimage-convolution
>> branch to check that it builds on your system? If not, what flags do you
>> have to change/add to get it to compile?
>>
>> -Tony
>>
>> P.S. If any one else is building this on OS X: ppc compatible builds is
>> turned on by default (at least on my system). This should be turned off
>> before building. Add the following line to ~/.profile, or just run it right
>> before building:
>>
>> export ARCH_FLAGS="-arch i386 -arch x86_64"
>>
>
> Can you explain why is this necessary?
>
> In convolution/setup.py I also see you add "-ffast-math", which is a
> GCC-specific flag. It's better to remove it I think, it may give problems
> with other compilers.
>
> Ralf
>

On my system at least, running gcc will, by default, add "-arch ppc" along
with i386 and x86_64. As far as I can tell, PPC doesn't support SSE, which
is used by this implementation.

The flag is left over from the original implementation. Removing
"-ffast-math" works fine on my system. To be honest, I don't do much
non-Python coding so I don't know the implications of adding/removing the
flag.

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

From nadavh.horesh at gmail.com  Fri Dec 30 11:20:22 2011
From: nadavh.horesh at gmail.com (Nadav Horesh)
Date: Fri, 30 Dec 2011 18:20:22 +0200
Subject: Need an advice
In-Reply-To: <CA+oBP_u0D+0NKp=Wsdsvr9iJAY7Kv+6wZBQ17=SCUu=78MM_hw@mail.gmail.com>
References: <CA+oBP_tF5YvsH9Nws1ha1BzVa_CXr=BhXZmW7PnhL=ah8O4J=w@mail.gmail.com>
	<CAB=suEnTxQ+ibJ+58dL4XmvqwY+zVP3pRmvDis15b6Th3z3dQQ@mail.gmail.com>
	<CA+oBP_tRVj29jgmyije3uEjg9tHMAqtB1e_y0XKgzaCBuL=pZQ@mail.gmail.com>
	<CABDkGQmU4-OtonbngS6wEzqE85M++Tz0Lr9VRO_B4HySS2HT+g@mail.gmail.com>
	<CA+oBP_vMAar=0Rd3xHtJff_y8V=+o_Sa47MvJ4OU5dsqN-oN2w@mail.gmail.com>
	<CAEym_Ho86DawGzVq9LRLFm-eOugjKo0neVRa3MbFPtyR34k9Dw@mail.gmail.com>
	<CAEym_HqMM8h_eTm9vCDvJC1Xj1dg79Es22r_gZ6zm30TWnU2MQ@mail.gmail.com>
	<CA+oBP_u0D+0NKp=Wsdsvr9iJAY7Kv+6wZBQ17=SCUu=78MM_hw@mail.gmail.com>
Message-ID: <CA+oBP_uLt-2WWh65CCt1Q7LsipamDvE65=9-uZWMRUtgA8xoAQ@mail.gmail.com>

Remarks for the convolution subpackage:
1. The __init__.py should be probably changed to

from ext import pyconvolve as convolve

2. The test_convolution.py file is very instructive. It should be polished
a bit. I think it would be worthwhile to add also scipy.signal.sepfir2d
and cv2.sepFilter2D to the test.

3. I found the convolve speed in par with cv.convolve2d (it can be slower
or faster depending on the kernel)

   Nadav

2011/12/28 Nadav Horesh <nadavh.horesh at gmail.com>

> I compiled after setting the flags for a core2 linux machine.  A quick and
> dirty benchmark showed a x2 improvement over scipy.signal.sepfir2d.
> I think that are some declaration errors in the python code (for instance
> I think that the convolution __init__.py should be
>
> from ext import pyconvolve
>
> instead of
>
> from ext import convolve
>
>  I'll take a closer look later.
>
> Thank you,
>
>    Nadav.
>
>
>
> 2011/12/28 Tony Yu <tsyu80 at gmail.com>
>
>>
>>
>> On Tue, Dec 27, 2011 at 8:24 PM, Tony Yu <tsyu80 at gmail.com> wrote:
>>
>>>
>>>
>>> On Tue, Dec 27, 2011 at 8:29 AM, Nadav Horesh <nadavh.horesh at gmail.com>wrote:
>>>
>>>> How can I get it?
>>>>
>>>>   Nadav
>>>>
>>>
>>> The code Stefan mentioned is in an old pull request (PR #16<https://github.com/scikits-image/scikits-image/pull/16>).
>>> That PR is from before the switch from scikits.image to skimage. I've made
>>> a new branch<https://github.com/tonysyu/scikits-image/commits/skimage-convolution>in my git repo with the convolution code in the new namespace.
>>>
>>> If you're already running skimage from git, then you can use git to
>>> clone this branch:
>>>
>>> git remote -f add tonysyu git at github.com:tonysyu/scikits-image.git
>>> git checkout -b convolution tonysyu/skimage-convolution
>>>
>>>
>>> In case this isn't familiar: The first line adds my git repo to your
>>> list of remotes, and the "-f" flag fetches the tags from my repo (this
>>> ensures that you have the info about my branches). My repo is now added to
>>> your repo as a remote with the name "tonysyu" (you can change this). The
>>> second line creates a new branch "convolution", clones my
>>> "skimage-convolution" branch into it, and checks it out.
>>>
>>> Hope that helps,
>>> -Tony
>>>
>>
>> Oops, I forgot to mention: I added a compile flag that is specific to my
>> system (In convolution/setup.py there's an include flag '-I/usr/...') that
>> should probably be removed. Also, I should mention that I haven't gotten
>> this branch to compile on my system (OSX). I believe it should compile OK
>> on Linux (after removing the '-I/usr/...' compile flag).
>>
>> Good luck,
>> -Tony
>>
>>>
>>> 2011/12/23 St?fan van der Walt <stefan at sun.ac.za>
>>>
>>>> On Thu, Dec 22, 2011 at 10:44 PM, Nadav Horesh <nadavh.horesh at gmail.com>
>>>> wrote:
>>>> > The application is not too sophisticated, and I do use numpy, scipy
>>>> and
>>>> > skimage for all I need. The only problem is speed, I need the
>>>> processing to
>>>> > be at l5-10 time faster. Convolutions take most of the processing
>>>> time. I
>>>> > prefer a flexible solution that would speed up also common nonlinear
>>>> filters
>>>> > (i.e. a median filter).
>>>>
>>>> We have a PR in the pipeline for doing really, really fast
>>>> convolutions... but it needs a bit of work.  Would you like to have a
>>>> look at it?
>>>>
>>>> St?fan
>>>>
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111230/219ccd35/attachment.html>

From ralf.gommers at googlemail.com  Fri Dec 30 13:19:03 2011
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Fri, 30 Dec 2011 19:19:03 +0100
Subject: Need an advice
In-Reply-To: <CAEym_HoaxTgzUBCYMtjNtyeqc=dnDvyb0i+mFUPtbVznGVWRnQ@mail.gmail.com>
References: <CA+oBP_tF5YvsH9Nws1ha1BzVa_CXr=BhXZmW7PnhL=ah8O4J=w@mail.gmail.com>
	<CAB=suEnTxQ+ibJ+58dL4XmvqwY+zVP3pRmvDis15b6Th3z3dQQ@mail.gmail.com>
	<CA+oBP_tRVj29jgmyije3uEjg9tHMAqtB1e_y0XKgzaCBuL=pZQ@mail.gmail.com>
	<CABDkGQmU4-OtonbngS6wEzqE85M++Tz0Lr9VRO_B4HySS2HT+g@mail.gmail.com>
	<CA+oBP_vMAar=0Rd3xHtJff_y8V=+o_Sa47MvJ4OU5dsqN-oN2w@mail.gmail.com>
	<CAEym_Ho86DawGzVq9LRLFm-eOugjKo0neVRa3MbFPtyR34k9Dw@mail.gmail.com>
	<CAEym_HqMM8h_eTm9vCDvJC1Xj1dg79Es22r_gZ6zm30TWnU2MQ@mail.gmail.com>
	<CA+oBP_u0D+0NKp=Wsdsvr9iJAY7Kv+6wZBQ17=SCUu=78MM_hw@mail.gmail.com>
	<CA+oBP_uLt-2WWh65CCt1Q7LsipamDvE65=9-uZWMRUtgA8xoAQ@mail.gmail.com>
	<CAEym_HoaxTgzUBCYMtjNtyeqc=dnDvyb0i+mFUPtbVznGVWRnQ@mail.gmail.com>
Message-ID: <CABL7CQjhRbe=yXHed5C-WQYgrfKvEpj1t_YeihGUMxigEaf2Zg@mail.gmail.com>

On Fri, Dec 30, 2011 at 5:46 PM, Tony Yu <tsyu80 at gmail.com> wrote:

>
>
> On Fri, Dec 30, 2011 at 8:20 AM, Nadav Horesh <nadavh.horesh at gmail.com>wrote:
>
>> Remarks for the convolution subpackage:
>> 1. The __init__.py should be probably changed to
>>
>> from ext import pyconvolve as convolve
>>
>
> Agreed. Alternatively, the c-method could be renamed so that the python
> method in ext can be named convolve.
>
>>
>> 2. The test_convolution.py file is very instructive. It should be
>> polished a bit. I think it would be worthwhile to add also
>> scipy.signal.sepfir2d and cv2.sepFilter2D to the test.
>>
>
>> 3. I found the convolve speed in par with cv.convolve2d (it can be slower
>> or faster depending on the kernel)
>>
>>    Nadav
>>
>
> Thanks for testing the code.
>
> I've got the code compiling on my system now, so I was able to clean up a
> few things. Could you update to what's currently on my skimage-convolution
> branch to check that it builds on your system? If not, what flags do you
> have to change/add to get it to compile?
>
> -Tony
>
> P.S. If any one else is building this on OS X: ppc compatible builds is
> turned on by default (at least on my system). This should be turned off
> before building. Add the following line to ~/.profile, or just run it right
> before building:
>
> export ARCH_FLAGS="-arch i386 -arch x86_64"
>

Can you explain why is this necessary?

In convolution/setup.py I also see you add "-ffast-math", which is a
GCC-specific flag. It's better to remove it I think, it may give problems
with other compilers.

Ralf


>
>
>
>>
>> 2011/12/28 Nadav Horesh <nadavh.horesh at gmail.com>
>>
>>> I compiled after setting the flags for a core2 linux machine.  A quick
>>> and dirty benchmark showed a x2 improvement over scipy.signal.sepfir2d.
>>> I think that are some declaration errors in the python code (for
>>> instance I think that the convolution __init__.py should be
>>>
>>> from ext import pyconvolve
>>>
>>> instead of
>>>
>>> from ext import convolve
>>>
>>>  I'll take a closer look later.
>>>
>>> Thank you,
>>>
>>>    Nadav.
>>>
>>>
>>>
>>> 2011/12/28 Tony Yu <tsyu80 at gmail.com>
>>>
>>>>
>>>>
>>>> On Tue, Dec 27, 2011 at 8:24 PM, Tony Yu <tsyu80 at gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Dec 27, 2011 at 8:29 AM, Nadav Horesh <nadavh.horesh at gmail.com
>>>>> > wrote:
>>>>>
>>>>>> How can I get it?
>>>>>>
>>>>>>   Nadav
>>>>>>
>>>>>
>>>>> The code Stefan mentioned is in an old pull request (PR #16<https://github.com/scikits-image/scikits-image/pull/16>).
>>>>> That PR is from before the switch from scikits.image to skimage. I've made
>>>>> a new branch<https://github.com/tonysyu/scikits-image/commits/skimage-convolution>in my git repo with the convolution code in the new namespace.
>>>>>
>>>>> If you're already running skimage from git, then you can use git to
>>>>> clone this branch:
>>>>>
>>>>> git remote -f add tonysyu git at github.com:tonysyu/scikits-image.git
>>>>> git checkout -b convolution tonysyu/skimage-convolution
>>>>>
>>>>>
>>>>> In case this isn't familiar: The first line adds my git repo to your
>>>>> list of remotes, and the "-f" flag fetches the tags from my repo (this
>>>>> ensures that you have the info about my branches). My repo is now added to
>>>>> your repo as a remote with the name "tonysyu" (you can change this). The
>>>>> second line creates a new branch "convolution", clones my
>>>>> "skimage-convolution" branch into it, and checks it out.
>>>>>
>>>>> Hope that helps,
>>>>> -Tony
>>>>>
>>>>
>>>> Oops, I forgot to mention: I added a compile flag that is specific to
>>>> my system (In convolution/setup.py there's an include flag '-I/usr/...')
>>>> that should probably be removed. Also, I should mention that I haven't
>>>> gotten this branch to compile on my system (OSX). I believe it should
>>>> compile OK on Linux (after removing the '-I/usr/...' compile flag).
>>>>
>>>> Good luck,
>>>> -Tony
>>>>
>>>>>
>>>>> 2011/12/23 St?fan van der Walt <stefan at sun.ac.za>
>>>>>
>>>>>> On Thu, Dec 22, 2011 at 10:44 PM, Nadav Horesh <
>>>>>> nadavh.horesh at gmail.com> wrote:
>>>>>> > The application is not too sophisticated, and I do use numpy, scipy
>>>>>> and
>>>>>> > skimage for all I need. The only problem is speed, I need the
>>>>>> processing to
>>>>>> > be at l5-10 time faster. Convolutions take most of the processing
>>>>>> time. I
>>>>>> > prefer a flexible solution that would speed up also common
>>>>>> nonlinear filters
>>>>>> > (i.e. a median filter).
>>>>>>
>>>>>> We have a PR in the pipeline for doing really, really fast
>>>>>> convolutions... but it needs a bit of work.  Would you like to have a
>>>>>> look at it?
>>>>>>
>>>>>> St?fan
>>>>>>
>>>>>
>>>>
>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111230/bde59a45/attachment.html>

From ralf.gommers at googlemail.com  Fri Dec 30 17:48:20 2011
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Fri, 30 Dec 2011 23:48:20 +0100
Subject: Need an advice
In-Reply-To: <CAEym_Hqzj1wX9i27Y64Wr135h_kehNVh=rm70rv2y1jKf2rqPA@mail.gmail.com>
References: <CA+oBP_tF5YvsH9Nws1ha1BzVa_CXr=BhXZmW7PnhL=ah8O4J=w@mail.gmail.com>
	<CAB=suEnTxQ+ibJ+58dL4XmvqwY+zVP3pRmvDis15b6Th3z3dQQ@mail.gmail.com>
	<CA+oBP_tRVj29jgmyije3uEjg9tHMAqtB1e_y0XKgzaCBuL=pZQ@mail.gmail.com>
	<CABDkGQmU4-OtonbngS6wEzqE85M++Tz0Lr9VRO_B4HySS2HT+g@mail.gmail.com>
	<CA+oBP_vMAar=0Rd3xHtJff_y8V=+o_Sa47MvJ4OU5dsqN-oN2w@mail.gmail.com>
	<CAEym_Ho86DawGzVq9LRLFm-eOugjKo0neVRa3MbFPtyR34k9Dw@mail.gmail.com>
	<CAEym_HqMM8h_eTm9vCDvJC1Xj1dg79Es22r_gZ6zm30TWnU2MQ@mail.gmail.com>
	<CA+oBP_u0D+0NKp=Wsdsvr9iJAY7Kv+6wZBQ17=SCUu=78MM_hw@mail.gmail.com>
	<CA+oBP_uLt-2WWh65CCt1Q7LsipamDvE65=9-uZWMRUtgA8xoAQ@mail.gmail.com>
	<CAEym_HoaxTgzUBCYMtjNtyeqc=dnDvyb0i+mFUPtbVznGVWRnQ@mail.gmail.com>
	<CABL7CQjhRbe=yXHed5C-WQYgrfKvEpj1t_YeihGUMxigEaf2Zg@mail.gmail.com>
	<CAEym_Hqzj1wX9i27Y64Wr135h_kehNVh=rm70rv2y1jKf2rqPA@mail.gmail.com>
Message-ID: <CABL7CQgUiVECRqYffy5RAikE2mPx22JzOxXZwDZ6GVnH+E=KoA@mail.gmail.com>

On Fri, Dec 30, 2011 at 8:05 PM, Tony Yu <tsyu80 at gmail.com> wrote:

>
>
> On Fri, Dec 30, 2011 at 1:19 PM, Ralf Gommers <ralf.gommers at googlemail.com
> > wrote:
>
>>
>>
>> On Fri, Dec 30, 2011 at 5:46 PM, Tony Yu <tsyu80 at gmail.com> wrote:
>>
>>>
>>>
>>> On Fri, Dec 30, 2011 at 8:20 AM, Nadav Horesh <nadavh.horesh at gmail.com>wrote:
>>>
>>>> Remarks for the convolution subpackage:
>>>> 1. The __init__.py should be probably changed to
>>>>
>>>> from ext import pyconvolve as convolve
>>>>
>>>
>>> Agreed. Alternatively, the c-method could be renamed so that the python
>>> method in ext can be named convolve.
>>>
>>>>
>>>> 2. The test_convolution.py file is very instructive. It should be
>>>> polished a bit. I think it would be worthwhile to add also
>>>> scipy.signal.sepfir2d and cv2.sepFilter2D to the test.
>>>>
>>>
>>>> 3. I found the convolve speed in par with cv.convolve2d (it can be
>>>> slower or faster depending on the kernel)
>>>>
>>>>    Nadav
>>>>
>>>
>>> Thanks for testing the code.
>>>
>>> I've got the code compiling on my system now, so I was able to clean up
>>> a few things. Could you update to what's currently on my
>>> skimage-convolution branch to check that it builds on your system? If not,
>>> what flags do you have to change/add to get it to compile?
>>>
>>> -Tony
>>>
>>> P.S. If any one else is building this on OS X: ppc compatible builds is
>>> turned on by default (at least on my system). This should be turned off
>>> before building. Add the following line to ~/.profile, or just run it right
>>> before building:
>>>
>>> export ARCH_FLAGS="-arch i386 -arch x86_64"
>>>
>>
>> Can you explain why is this necessary?
>>
>> In convolution/setup.py I also see you add "-ffast-math", which is a
>> GCC-specific flag. It's better to remove it I think, it may give problems
>> with other compilers.
>>
>> Ralf
>>
>
> On my system at least, running gcc will, by default, add "-arch ppc" along
> with i386 and x86_64. As far as I can tell, PPC doesn't support SSE, which
> is used by this implementation.
>

That's true. I can't tell for sure, but it seems that this code is not
optional. Meaning PPC is unsupported, and the ARCH_FLAGS need to be defined
on OS X. I'm only a very occasional user now so it doesn't bother me too
much, but isn't this a large penalty for the benefit you get?


>
> The flag is left over from the original implementation. Removing
> "-ffast-math" works fine on my system. To be honest, I don't do much
> non-Python coding so I don't know the implications of adding/removing the
> flag.
>

It's very likely to give problems with unusual (or even Intel) compilers I
think.

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

From tsyu80 at gmail.com  Sat Dec 31 00:51:46 2011
From: tsyu80 at gmail.com (Tony Yu)
Date: Sat, 31 Dec 2011 00:51:46 -0500
Subject: Need an advice
In-Reply-To: <CABL7CQgUiVECRqYffy5RAikE2mPx22JzOxXZwDZ6GVnH+E=KoA@mail.gmail.com>
References: <CA+oBP_tF5YvsH9Nws1ha1BzVa_CXr=BhXZmW7PnhL=ah8O4J=w@mail.gmail.com>
	<CAB=suEnTxQ+ibJ+58dL4XmvqwY+zVP3pRmvDis15b6Th3z3dQQ@mail.gmail.com>
	<CA+oBP_tRVj29jgmyije3uEjg9tHMAqtB1e_y0XKgzaCBuL=pZQ@mail.gmail.com>
	<CABDkGQmU4-OtonbngS6wEzqE85M++Tz0Lr9VRO_B4HySS2HT+g@mail.gmail.com>
	<CA+oBP_vMAar=0Rd3xHtJff_y8V=+o_Sa47MvJ4OU5dsqN-oN2w@mail.gmail.com>
	<CAEym_Ho86DawGzVq9LRLFm-eOugjKo0neVRa3MbFPtyR34k9Dw@mail.gmail.com>
	<CAEym_HqMM8h_eTm9vCDvJC1Xj1dg79Es22r_gZ6zm30TWnU2MQ@mail.gmail.com>
	<CA+oBP_u0D+0NKp=Wsdsvr9iJAY7Kv+6wZBQ17=SCUu=78MM_hw@mail.gmail.com>
	<CA+oBP_uLt-2WWh65CCt1Q7LsipamDvE65=9-uZWMRUtgA8xoAQ@mail.gmail.com>
	<CAEym_HoaxTgzUBCYMtjNtyeqc=dnDvyb0i+mFUPtbVznGVWRnQ@mail.gmail.com>
	<CABL7CQjhRbe=yXHed5C-WQYgrfKvEpj1t_YeihGUMxigEaf2Zg@mail.gmail.com>
	<CAEym_Hqzj1wX9i27Y64Wr135h_kehNVh=rm70rv2y1jKf2rqPA@mail.gmail.com>
	<CABL7CQgUiVECRqYffy5RAikE2mPx22JzOxXZwDZ6GVnH+E=KoA@mail.gmail.com>
Message-ID: <CAEym_HrBT+o_dZLCpGpinNETQrV_wi-ZcpBJSanAxTXOH4NnHQ@mail.gmail.com>

On Fri, Dec 30, 2011 at 5:48 PM, Ralf Gommers
<ralf.gommers at googlemail.com>wrote:

>
>
> On Fri, Dec 30, 2011 at 8:05 PM, Tony Yu <tsyu80 at gmail.com> wrote:
>
>>
>>
>> On Fri, Dec 30, 2011 at 1:19 PM, Ralf Gommers <
>> ralf.gommers at googlemail.com> wrote:
>>
>>>
>>>
>>> On Fri, Dec 30, 2011 at 5:46 PM, Tony Yu <tsyu80 at gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Dec 30, 2011 at 8:20 AM, Nadav Horesh <nadavh.horesh at gmail.com>wrote:
>>>>
>>>>> Remarks for the convolution subpackage:
>>>>> 1. The __init__.py should be probably changed to
>>>>>
>>>>> from ext import pyconvolve as convolve
>>>>>
>>>>
>>>> Agreed. Alternatively, the c-method could be renamed so that the python
>>>> method in ext can be named convolve.
>>>>
>>>>>
>>>>> 2. The test_convolution.py file is very instructive. It should be
>>>>> polished a bit. I think it would be worthwhile to add also
>>>>> scipy.signal.sepfir2d and cv2.sepFilter2D to the test.
>>>>>
>>>>
>>>>> 3. I found the convolve speed in par with cv.convolve2d (it can be
>>>>> slower or faster depending on the kernel)
>>>>>
>>>>>    Nadav
>>>>>
>>>>
>>>> Thanks for testing the code.
>>>>
>>>> I've got the code compiling on my system now, so I was able to clean up
>>>> a few things. Could you update to what's currently on my
>>>> skimage-convolution branch to check that it builds on your system? If not,
>>>> what flags do you have to change/add to get it to compile?
>>>>
>>>> -Tony
>>>>
>>>> P.S. If any one else is building this on OS X: ppc compatible builds is
>>>> turned on by default (at least on my system). This should be turned off
>>>> before building. Add the following line to ~/.profile, or just run it right
>>>> before building:
>>>>
>>>> export ARCH_FLAGS="-arch i386 -arch x86_64"
>>>>
>>>
>>> Can you explain why is this necessary?
>>>
>>> In convolution/setup.py I also see you add "-ffast-math", which is a
>>> GCC-specific flag. It's better to remove it I think, it may give problems
>>> with other compilers.
>>>
>>> Ralf
>>>
>>
>> On my system at least, running gcc will, by default, add "-arch ppc"
>> along with i386 and x86_64. As far as I can tell, PPC doesn't support SSE,
>> which is used by this implementation.
>>
>
> That's true. I can't tell for sure, but it seems that this code is not
> optional. Meaning PPC is unsupported, and the ARCH_FLAGS need to be defined
> on OS X. I'm only a very occasional user now so it doesn't bother me too
> much, but isn't this a large penalty for the benefit you get?
>

Well, I assume that we would be able to add a check to disable the build on
unsupported architectures. As far as, whether it's worth it: I don't know.
Is PPC very common? I'm only familiar with it in the context of old Apple
computers. From the Wikipedia page <http://en.wikipedia.org/wiki/PowerPC>,
it seems like PPC is mainly used in servers now.

As for the benefit: I think getting close to the performance of OpenCV is
pretty significant. (On my system, however, I don't quite see the
performance boost that Nadav sees: skimage: 0.034 secs, ndimage: 0.089
secs, opencv: 0.018 secs, for the output of
'test_convolution.py'---nevertheless, it's a significant improvement over
ndimage). And, in comparison, OpenCV can be incredibly difficult to build.

There are probably other ways to get similar performance, but like I said,
I don't do any serious non-Python coding, so I have no idea what those
alternatives may be. Stefan and Pieter (the original author of this code)
have probably thought this through a bit more.

-Tony


>> The flag is left over from the original implementation. Removing
>> "-ffast-math" works fine on my system. To be honest, I don't do much
>> non-Python coding so I don't know the implications of adding/removing the
>> flag.
>>
>
> It's very likely to give problems with unusual (or even Intel) compilers I
> think.
>
> Ralf
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20111231/ebdbab0e/attachment.html>

From jeanpatrick.pommier at gmail.com  Sat Dec 31 05:32:55 2011
From: jeanpatrick.pommier at gmail.com (jip)
Date: Sat, 31 Dec 2011 02:32:55 -0800 (PST)
Subject: watershed issue
In-Reply-To: <CAEym_HpN-h_sP9SgL=1OHTapcGAqKe2s9NX3-tbseayuC4TsbQ@mail.gmail.com>
References: <7455907.1194.1325099150777.JavaMail.geo-discussion-forums@vbad17>
 <20111228200044.GA31953@phare.normalesup.org> <31888480.2012.1325252365968.JavaMail.geo-discussion-forums@vbgw2>
 <CAEym_HpG25PrtCHtQbg41iMvyKei5his6seZpqJbOzEiqzq3FA@mail.gmail.com> <CAEym_HpN-h_sP9SgL=1OHTapcGAqKe2s9NX3-tbseayuC4TsbQ@mail.gmail.com>
Message-ID: <5a00960a-9632-41c3-9757-46966ed9a3a0@dp8g2000vbb.googlegroups.com>

Thank you Tony,
Modifying the threshold value from 30 to a lower value, gives a
consistent result.

Jean-Patrick
sk.morphology.watershed(bassin_hi,markers,mask=top>30)

On 30 d?c, 17:22, Tony Yu <tsy... at gmail.com> wrote:
> On Fri, Dec 30, 2011 at 8:01 AM, Tony Yu <tsy... at gmail.com> wrote:
>
> > On Fri, Dec 30, 2011 at 5:39 AM, jip <jeanpatrick.pomm... at gmail.com>wrote:
>
> >> Dear Emmanuelle,
>
> >> Sorry for the delay.
> >> I have rewritten a clearer script
> >> <https://docs.google.com/open?id=0B-YDFMbEy1grODU1Y2U0OTgtMzk1MS00Mzkx...>I
> >> hope.
> >> First, it takes a 12bits image<https://docs.google.com/open?id=0B-YDFMbEy1grNWJlYTkwYzYtMjk0ZS00NGVl...>(cy3 in the archive), isolates a region andremoves the background<https://docs.google.com/open?id=0B-YDFMbEy1grNDZjOWZjZjAtMGVmMS00ZTM2...>
> >> .
> >> Regional maxima are found to get markers for watershed.
> >> Three kind of maps are also prepared.
> >> Each map, with the markers image, is submitted to the watershed
> >> algorithm.Segmentation is performed with watershed as indicated here<http://scikits-image.org/docs/dev/auto_examples/plot_watershed.html#e...>,
> >> as follow:
> >> segmentation=watershed(map,markers,mask)
> >> map:grayscale image
> >> markers:label image
> >> mask:binary image
>
> > There's a small typo here: watershed should be called as:
>
> > ? ? ?watershed(map, makers, mask=mask)
>
> > More specifically, in your code, you have:
>
> > ? ? sk.morphology.watershed(bassin_hi,markers,top>30)
>
> > but it should be called as:
>
> > ? ? sk.morphology.watershed(bassin_hi,markers,mask=top>30)
>
> > Without specifying `mask=`, you're setting the connectivity parameter in
> > watershed. Even with this correction, something seems to be off since
> > watershed seems to return blank images. Without the masks, it gives what I
> > would expect. I'm not sure what's going on the masked output.
>
> > -Tony
>
> Actually, I think this masked output is correct: All the markers seem to
> land in the masked-out regions.
>
> >>> mask = top > 30
> >>> print np.any(marker * mask)
>
> False
>
> -Tony