From stefan at sun.ac.za  Wed Feb  1 04:56:00 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 1 Feb 2012 01:56:00 -0800
Subject: FreeImage manitenance
In-Reply-To: <E1930E30-260B-4A85-AFEB-BE9A28B6CA5A@yale.edu>
References: <E1930E30-260B-4A85-AFEB-BE9A28B6CA5A@yale.edu>
Message-ID: <CABDkGQ=is7qhW2XYttJHqTZu1y=CDUkGm9ko-jErF5D31nrViw@mail.gmail.com>

Hi Zach

On Tue, Jan 31, 2012 at 12:17 PM, Zachary Pincus
<zachary.pincus at yale.edu> wrote:
> Apropos of the recent discussion about and troubles with diagnosing FreeImage library loading problems on 64-bit windows, I have tried to enhance the library-loading code:
> https://github.com/scikits-image/scikits-image/pull/117

There's a small spacing typo in this changeset, but apart from that
looks ready to be merged.

> And speaking of FreeImage and 64-bit-ness,
> https://github.com/scikits-image/scikits-image/pull/112
> fixes some problems in 64-bit image loading, and also clarifies how to deal with 64-bit pointers and the ctypes interface.

I've merged 112.

> Finally,
> https://github.com/scikits-image/scikits-image/pull/113
> builds on the changes in PR 112 to expose basic image metadata reading in a 64-bit-safe manner.

That looks good.  Let's document the tags keyword and merge.

Thanks for all the fixes!

St?fan


From stefan at sun.ac.za  Wed Feb  1 18:19:24 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 1 Feb 2012 15:19:24 -0800
Subject: Feature Extraction
In-Reply-To: <20120201224738.d38b973c.google@terre-adelie.org>
References: <20120201224738.d38b973c.google@terre-adelie.org>
Message-ID: <CABDkGQm8QFT6W7P5-wvFkQLRUTFEC-Bw78OzvQfUM3f2U35UdA@mail.gmail.com>

Hi J?r?me

2012/2/1 J?r?me Kieffer <google at terre-adelie.org>:
> I wonder if you know "IPOL": http://www.ipol.im
> They publish articles on image processing, featuring implementations (in C/C++).

Thanks, interesting site.

> I made bindings for their SIFT and SURF feature extractions & image alignment (only 2 img for now). My cython code could be released under BSD if you wish ... but beside this I don't know the license of (all) the original C++ code:
> "The implementation of IPOL algorithms is distributed under a free software license, usually GPL, AGPL, LGPL or BSD."
> It also includes Eigen:
> Eigen is Free Software. It is licensed under the LGPL3+. As an alternative license choice, Eigen is also licensed under the GPL2+.
>
> So LGPL3 seems to be the most permissive license achievable :-/
> If it does not make sense for skimage ... I will release it elsewhere but it can interest some of yours.

As far as I'm aware, the LGPL does not have the same viral properties,
but I don't know what the implications are of linking to such code in
a BSD project and I'd rather steer clear for safety.

I'd like to incorporating this code into skimage:

http://pr.willowgarage.com/wiki/Star_Detector

Regards
St?fan


From google at terre-adelie.org  Wed Feb  1 16:47:38 2012
From: google at terre-adelie.org (=?ISO-8859-1?Q?J=E9r=F4me?= Kieffer)
Date: Wed, 1 Feb 2012 22:47:38 +0100
Subject: Feature Extraction
Message-ID: <20120201224738.d38b973c.google@terre-adelie.org>

Hi,

I wonder if you know "IPOL": http://www.ipol.im
They publish articles on image processing, featuring implementations (in C/C++).

I made bindings for their SIFT and SURF feature extractions & image alignment (only 2 img for now). My cython code could be released under BSD if you wish ... but beside this I don't know the license of (all) the original C++ code:
"The implementation of IPOL algorithms is distributed under a free software license, usually GPL, AGPL, LGPL or BSD."
It also includes Eigen:
Eigen is Free Software. It is licensed under the LGPL3+. As an alternative license choice, Eigen is also licensed under the GPL2+. 

So LGPL3 seems to be the most permissive license achievable :-/
If it does not make sense for skimage ... I will release it elsewhere but it can interest some of yours.

Cheers,
-- 
J?r?me Kieffer <google at terre-adelie.org>

the code is here:
https://github.com/kif/surf/tree/master/features


From stefan at sun.ac.za  Thu Feb  2 06:58:43 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 2 Feb 2012 03:58:43 -0800
Subject: Documentation sprint over the weekend
Message-ID: <CABDkGQ=8xdHN-3Y7WmJuGKCjLwnQdubHmi1Wd-E29R60jPqkjA@mail.gmail.com>

Hi all,

For release 0.5 I'd like to have a good User Guide available for skimage.
 I'm going to start writing it this weekend, so if you have some spare
cycles to contribute, that'd be much appreciated!

Also, have a look at the updated web front page
<http://skimage.org>(thanks, Tony!).

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

From tsyu80 at gmail.com  Thu Feb  2 10:07:33 2012
From: tsyu80 at gmail.com (Tony Yu)
Date: Thu, 2 Feb 2012 10:07:33 -0500
Subject: Documentation sprint over the weekend
In-Reply-To: <CABDkGQ=8xdHN-3Y7WmJuGKCjLwnQdubHmi1Wd-E29R60jPqkjA@mail.gmail.com>
References: <CABDkGQ=8xdHN-3Y7WmJuGKCjLwnQdubHmi1Wd-E29R60jPqkjA@mail.gmail.com>
Message-ID: <CAEym_HpyBn+9JbabmBA+eycsVVg51xKeNNqV=7h8_-5_P7QQFA@mail.gmail.com>

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

> Hi all,
>
> For release 0.5 I'd like to have a good User Guide available for skimage.
>  I'm going to start writing it this weekend, so if you have some spare
> cycles to contribute, that'd be much appreciated!
>
> Also, have a look at the updated web front page <http://skimage.org>(thanks, Tony!).
>
> Regards
> St?fan
>


Hmm, I'm not sure I really deserve the credit for the front page, but
thanks!

I should have a little bit of free time to work on the docs this weekend.
Any specific goals?

One thing I'd like to see is a package docstring listing all subpackages (+
1-sentence descriptions of those subpackages; e.g. type `np?` in ipython);
and then each subpackage would have it's own docstring listing of functions
(e.g. type `numpy.linalg?` in ipython). I guess this is separate from the
user guide, but it's still really valuable for learning the package.

While we're talking about release 0.5, I think we should try to clean out a
number of pull requests. Some of them should be quick:

PR 99 <https://github.com/scikits-image/scikits-image/pull/99>: Rewrite
dtype._convert function
    There is a comment at the end of this PR suggesting we clip when
converting int to uint, but maybe we should just merge this PR and add the
clipping change as a new PR. In fact, if there are no objections by
tomorrow, I'm just going to merge the PR as is. (No promises that I'll
submit a PR for the clipping change.)

PR 105 <https://github.com/scikits-image/scikits-image/pull/105>: ENH:
Allow choice between 4 and 8 neighbor mode.
    I was waiting for a response to a few suggested changes, but they are
relatively minor, so this could be merged as is.

PR 95 <https://github.com/scikits-image/scikits-image/pull/95>:
debian/control updates to reflect name space transition
   This seems like a really simple change, but since I don't really
use/know-anything-about Debian, I'm hesitant to be the one to merge.

PR 107 <https://github.com/scikits-image/scikits-image/pull/107>: Add
rescale_intensity function with test and example.
   Stefan: you mentioned you wanted to send a PR to this branch. If it was
an involved change, we should hold off until a later date.


I'm not so certain about the others.

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

From thomas.haslwanter at gmail.com  Thu Feb  2 15:54:40 2012
From: thomas.haslwanter at gmail.com (thomash)
Date: Thu, 2 Feb 2012 12:54:40 -0800 (PST)
Subject: Getting Mahotas on Windows to run
Message-ID: <b4cddbe8-5a3c-448b-988a-08c7b76bda6d@o14g2000vbo.googlegroups.com>

Hi,
I am fairly new to image processing in Python, and have a bugger of a
time getting Mahotas to run on my Windows machine. (Win7, 32bit,
Python 2.7).
In addition to installing Mahotas, I copied the "FreeImage.dll" to "C:
\Python27\DLLs", the "FreeImage.h" to "C:\Python27\include", and
"FreeImage.lib" to "C:\Python27\libs".

My main problem seems to be related to freeimage, and I am wondering
if any of you got it running under Windows?

My error message:
In [5]: from mahotas import freeimage
------------------------------------------------------------
Traceback (most recent call last):
  File "<ipython console>", line 1, in <module>
  File "C:\Python27\lib\site-packages\mahotas-0.7.1-py2.7-win32.egg
\mahotas\__init__.py", line 77, in <module>
    from .freeimage import imread, imsave
  File "C:\Python27\lib\site-packages\mahotas-0.7.1-py2.7-win32.egg
\mahotas\freeimage.py", line 148, in <module>
    _FI = _register_api(_FI, _API)
  File "C:\Python27\lib\site-packages\mahotas-0.7.1-py2.7-win32.egg
\mahotas\freeimage.py", line 102, in _register_api
    func = getattr(lib, f)
  File "C:\Python27\lib\ctypes\__init__.py", line 366, in __getattr__
    func = self.__getitem__(name)
  File "C:\Python27\lib\ctypes\__init__.py", line 371, in __getitem__
    func = self._FuncPtr((name_or_ordinal, self))
AttributeError: function 'FreeImage_CloseMultiBitmap' not found

Any hints?
Thanks, Thomas


From stefan at sun.ac.za  Thu Feb  2 17:19:54 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 2 Feb 2012 14:19:54 -0800
Subject: Getting Mahotas on Windows to run
In-Reply-To: <b4cddbe8-5a3c-448b-988a-08c7b76bda6d@o14g2000vbo.googlegroups.com>
References: <b4cddbe8-5a3c-448b-988a-08c7b76bda6d@o14g2000vbo.googlegroups.com>
Message-ID: <CABDkGQkMzJhw3f-NB-b4ezHtEEf0BGHCBpEpPRa4J15bgNuk5A@mail.gmail.com>

Hi Thomas

Welcome to the scikits-image mailing list.

On Thu, Feb 2, 2012 at 12:54 PM, thomash <thomas.haslwanter at gmail.com> wrote:
> I am fairly new to image processing in Python, and have a bugger of a
> time getting Mahotas to run on my Windows machine. (Win7, 32bit,
> Python 2.7).

The best place to ask Mahotas questions would be on the PythonVision
mailing list, where Luis is active:

http://groups.google.com/group/pythonvision

> My main problem seems to be related to freeimage, and I am wondering
> if any of you got it running under Windows?

You can also use FreeImage via scikits-image, so please try that as
well and let us know:

http://www.lfd.uci.edu/~gohlke/pythonlibs/#scikits.image

The code snippet you need is:

import skimage.io as sio
sio.use('freeimage')

img = sio.imread('/path/to/image.jpg')
sio.imshow(img)

Regards
St?fan


From tsyu80 at gmail.com  Fri Feb  3 10:40:49 2012
From: tsyu80 at gmail.com (Tony Yu)
Date: Fri, 3 Feb 2012 10:40:49 -0500
Subject: Dependency versions
Message-ID: <CAEym_HpKWrqa_hsgsCHQKSNKNVgUxm8BanP_5QUtfzzzX9_j7A@mail.gmail.com>

Hi everyone,

I'd like to start a discussion on how to handle versions of dependencies.
The current docs suggest that we require Numpy
1.4<http://scikits-image.org/docs/dev/install.html>,
but at some point we'd probably want to increment this. In fact, I forgot
that the dtype._convert pull request (PR #99) uses the function
`promote_types` from numpy 1.6. (We need to either bump up the numpy
version now or add a compatibility function.)

In addition, we should add a minimum (optional) version of Matplotlib for
use in examples (this has come up in a few PRs already).

I run most of my scientific software from github, so I have no problem with
running the bleeding edge, but this is certainly more difficult for others.
How do other packages increment versions of dependencies?

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

From stefan at sun.ac.za  Fri Feb  3 18:55:46 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 3 Feb 2012 15:55:46 -0800
Subject: Fixing image loading in Python: imread
In-Reply-To: <4357987.if5pQMgS3P@rabbit>
References: <4357987.if5pQMgS3P@rabbit>
Message-ID: <CABDkGQkNWvEP9AwXxMfp0PzsOFsG8MjggRX74-HKCxF-JE-n+g@mail.gmail.com>

Hey Luis

On Fri, Feb 3, 2012 at 9:07 AM, Luis Pedro Coelho <luis at luispedro.org> wrote:
> imread
> https://github.com/luispedro/imread
>
> I want it to be simple: No image processing at all, just getting the bytes out
> of image files and into image files.

A simple image reader would certainly be useful.  There's been some
hope that someone would do this in pure Python (and I think Zach may
even have started on that), but so far that's not panned out.
Wrapping libjpeg and libpng seems very similar to what matplotlib
does, so you may also want to look at their code (we currently provide
those functions as an skimage.io plugin).

Regards
St?fan


From stefan at sun.ac.za  Fri Feb  3 19:05:13 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 3 Feb 2012 16:05:13 -0800
Subject: Dependency versions
In-Reply-To: <CAEym_HpKWrqa_hsgsCHQKSNKNVgUxm8BanP_5QUtfzzzX9_j7A@mail.gmail.com>
References: <CAEym_HpKWrqa_hsgsCHQKSNKNVgUxm8BanP_5QUtfzzzX9_j7A@mail.gmail.com>
Message-ID: <CABDkGQ=V--H6AB8pw_+wrRY87y7Z4fa35sntuKbWTht9qVv5Uw@mail.gmail.com>

Hi Tony

On Fri, Feb 3, 2012 at 7:40 AM, Tony Yu <tsyu80 at gmail.com> wrote:
> I'd like to start a discussion on how to handle versions of dependencies.
> The current docs suggest that we require Numpy 1.4, but at some point we'd
> probably want to increment this. In fact, I forgot that the dtype._convert
> pull request (PR #99) uses the function `promote_types` from numpy 1.6. (We
> need to either bump up the numpy version now or add a compatibility
> function.)

I think it is reasonable if the latest release of skimage relies on
the latest stable release of numpy and matplotlib.

> In addition, we should add a minimum (optional) version of Matplotlib for
> use in examples (this has come up in a few PRs already).

I recommend that we bump NumPy to 1.6 and Matplotlib to 1.0 (release
2011-01-03).  The "subplots" functionality in 1.0 is really, really
handy.

> I run most of my scientific software from github, so I have no problem with
> running the bleeding edge, but this is certainly more difficult for others.
> How do other packages increment versions of dependencies?

True; but I think that, if you're running old versions of numpy and
scipy, running an older version of skimage should be fine.  If you
need the latest, then it is reasonable to upgrade those packages as
well.  Backward compatibility comes at a cost, unfortunately!

Regards
St?fan


From luis at luispedro.org  Fri Feb  3 12:07:57 2012
From: luis at luispedro.org (Luis Pedro Coelho)
Date: Fri, 03 Feb 2012 17:07:57 +0000
Subject: Fixing image loading in Python: imread
Message-ID: <4357987.if5pQMgS3P@rabbit>

Hi,

I finally got a bit fed up with the state of reading & writing images in 
Python/numpy and started a new project:

imread
https://github.com/luispedro/imread

I want it to be simple: No image processing at all, just getting the bytes out 
of image files and into image files.

This way it has a better chance of being very stable and getting 
into linux distros and stuff like that. Once it matures a bit, I will use it in 
mahotas and I will submit a patch to scikits.learn.

It currently has two functions

imread : filename -> numpy array
    : reads a file
imsave: filename & numpy array
    : writes a file

I can imaging adding another pair to read&write to an in-memory buffer and 
perhaps a way to guess fileformats and retrieve metadata. But, again, there 
will be exactly zero image processing functions. That's for other packages to 
worry about.

It only supports PNG at the moment (using libpng) and JPEG (through libjpeg).  
It needs better error checking, of course. It should be boring and solid. With 
TIFF, I will call it "1.0" as it will cover most use cases.

What do you guys think?
-- 
Luis Pedro Coelho | University of Lisbon | http://luispedro.org
-------------- next part --------------
Q29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9wZ3Atc2lnbmF0dXJlOyBuYW1lPSJzaWduYXR1cmUu
YXNjIg0KQ29udGVudC1EZXNjcmlwdGlvbjogVGhpcyBpcyBhIGRpZ2l0YWxseSBzaWduZWQgbWVz
c2FnZSBwYXJ0Lg0KDQotLS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLQpWZXJzaW9uOiBHbnVQ
RyB2MS40LjExIChHTlUvTGludXgpCgppRVlFQUJFQ0FBWUZBazhzRkcwQUNna1FFUTFzbU9kZ3Z2
STZQUUNlUFR6Mnd5Zk5UeGo4RnhSUHAzQUJJOTVUCnJIOEFuMm5ubGJkcDFZK3ArUXhuVVVxL205
MGF0aXhOCj1kSlF5Ci0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo=

From stefan at sun.ac.za  Sat Feb  4 00:29:52 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 3 Feb 2012 21:29:52 -0800
Subject: Documentation sprint over the weekend
In-Reply-To: <CAEym_HpyBn+9JbabmBA+eycsVVg51xKeNNqV=7h8_-5_P7QQFA@mail.gmail.com>
References: <CABDkGQ=8xdHN-3Y7WmJuGKCjLwnQdubHmi1Wd-E29R60jPqkjA@mail.gmail.com>
 <CAEym_HpyBn+9JbabmBA+eycsVVg51xKeNNqV=7h8_-5_P7QQFA@mail.gmail.com>
Message-ID: <CABDkGQkdaaX6WSdfJ+68wTb__RO8wFiPaZ0BJYPKnRtQTS1DTg@mail.gmail.com>

On Thu, Feb 2, 2012 at 7:07 AM, Tony Yu <tsyu80 at gmail.com> wrote:
> I should have a little bit of free time to work on the docs this weekend.
> Any specific goals?

I think we should try and complete the following sections:

- Introduction
   (installation -- link to existing docs, overview and how we fit in
on top of scipy, our goals, what we provide)
- Reading and displaying images
   (io module, display, fancy=True, using matplotlib, etc.)
- Data-types and the pipeline
   (dtype conversion, how to ensure your output is in the right
format, all functions accept any input but returns preferred dtype
output--user should call img_as_*)
- Getting help
   (reference guide, examples gallery, maybe image processing specific
websites similar to metaoptimize.com/qa )

And some tutorials are always welcome--although I think the gallery
now largely fulfills that role.

Did I miss anything important?

We also need a man-page for skivi (the image viewer).  I've uploaded a template:

https://github.com/scikits-image/scikits-image/blob/debian/debian/skivi.1

> One thing I'd like to see is a package docstring listing all subpackages (+
> 1-sentence descriptions of those subpackages; e.g. type `np?` in ipython);
> and then each subpackage would have it's own docstring listing of functions
> (e.g. type `numpy.linalg?` in ipython). I guess this is separate from the
> user guide, but it's still really valuable for learning the package.

Yes, good point!

> While we're talking about release 0.5, I think we should try to clean out a
> number of pull requests. Some of them should be quick:
>
> PR 99: Rewrite dtype._convert function

Merged (by me).

> PR 105: ENH: Allow choice between 4 and 8 neighbor mode.

Merged (by Tony).

> PR 95: debian/control updates to reflect name space transition

Rejected (mainly adding the author's name, but very few changes).  I
updated the control file to be up to date in the meantime.

> PR 107: Add rescale_intensity function with test and example.

I'm keen to merge this; we're just waiting for the rest of the list to
comment on the matplotlib 1.0 dependency.

Cheers
St?fan


From emmanuelle.gouillart at nsup.org  Sat Feb  4 07:28:39 2012
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Sat, 4 Feb 2012 13:28:39 +0100
Subject: Documentation sprint over the weekend
In-Reply-To: <CABDkGQkdaaX6WSdfJ+68wTb__RO8wFiPaZ0BJYPKnRtQTS1DTg@mail.gmail.com>
References: <CABDkGQ=8xdHN-3Y7WmJuGKCjLwnQdubHmi1Wd-E29R60jPqkjA@mail.gmail.com>
 <CAEym_HpyBn+9JbabmBA+eycsVVg51xKeNNqV=7h8_-5_P7QQFA@mail.gmail.com>
 <CABDkGQkdaaX6WSdfJ+68wTb__RO8wFiPaZ0BJYPKnRtQTS1DTg@mail.gmail.com>
Message-ID: <20120204122839.GA31382@phare.normalesup.org>

Hi,

I'll try to work on the "getting help" part of the user guide, then.

Cheers,
Emmanuelle

> - Introduction
>    (installation -- link to existing docs, overview and how we fit in
> on top of scipy, our goals, what we provide)
> - Reading and displaying image
>    (io module, display, fancy=True, using matplotlib, etc.)
> - Data-types and the pipeline
>    (dtype conversion, how to ensure your output is in the right
> format, all functions accept any input but returns preferred dtype
> output--user should call img_as_*)
> - Getting help
>    (reference guide, examples gallery, maybe image processing specific
> websites similar to metaoptimize.com/qa )

> And some tutorials are always welcome--although I think the gallery
> now largely fulfills that role.

> Did I miss anything important?

> We also need a man-page for skivi (the image viewer).  I've uploaded a template:

> https://github.com/scikits-image/scikits-image/blob/debian/debian/skivi.1

> > One thing I'd like to see is a package docstring listing all subpackages (+
> > 1-sentence descriptions of those subpackages; e.g. type `np?` in ipython);
> > and then each subpackage would have it's own docstring listing of functions
> > (e.g. type `numpy.linalg?` in ipython). I guess this is separate from the
> > user guide, but it's still really valuable for learning the package.

> Yes, good point!

> > While we're talking about release 0.5, I think we should try to clean out a
> > number of pull requests. Some of them should be quick:

> > PR 99: Rewrite dtype._convert function

> Merged (by me).

> > PR 105: ENH: Allow choice between 4 and 8 neighbor mode.

> Merged (by Tony).

> > PR 95: debian/control updates to reflect name space transition

> Rejected (mainly adding the author's name, but very few changes).  I
> updated the control file to be up to date in the meantime.

> > PR 107: Add rescale_intensity function with test and example.

> I'm keen to merge this; we're just waiting for the rest of the list to
> comment on the matplotlib 1.0 dependency.

> Cheers
> St??????fan


From tsyu80 at gmail.com  Sat Feb  4 14:47:14 2012
From: tsyu80 at gmail.com (Tony Yu)
Date: Sat, 4 Feb 2012 14:47:14 -0500
Subject: Documentation sprint over the weekend
In-Reply-To: <20120204122839.GA31382@phare.normalesup.org>
References: <CABDkGQ=8xdHN-3Y7WmJuGKCjLwnQdubHmi1Wd-E29R60jPqkjA@mail.gmail.com>
	<CAEym_HpyBn+9JbabmBA+eycsVVg51xKeNNqV=7h8_-5_P7QQFA@mail.gmail.com>
	<CABDkGQkdaaX6WSdfJ+68wTb__RO8wFiPaZ0BJYPKnRtQTS1DTg@mail.gmail.com>
	<20120204122839.GA31382@phare.normalesup.org>
Message-ID: <CAEym_Hp-Qke-Ko8iUbo7Qy7cSg_GL2B-h7nTjPcPtejJvn=eBg@mail.gmail.com>

On Sat, Feb 4, 2012 at 7:28 AM, Emmanuelle Gouillart <
emmanuelle.gouillart at nsup.org> wrote:

> Hi,
>
> I'll try to work on the "getting help" part of the user guide, then.
>
> Cheers,
> Emmanuelle
>

I'll get to work on the data-types and processing pipeline. I may not have
as much time as expected, though, since I got sidetracked by other PRs.

Cheers,
-Tony

>
> > - Introduction
> >    (installation -- link to existing docs, overview and how we fit in
> > on top of scipy, our goals, what we provide)
> > - Reading and displaying image
> >    (io module, display, fancy=True, using matplotlib, etc.)
> > - Data-types and the pipeline
> >    (dtype conversion, how to ensure your output is in the right
> > format, all functions accept any input but returns preferred dtype
> > output--user should call img_as_*)
> > - Getting help
> >    (reference guide, examples gallery, maybe image processing specific
> > websites similar to metaoptimize.com/qa )
>
> > And some tutorials are always welcome--although I think the gallery
> > now largely fulfills that role.
>
> > Did I miss anything important?
>
> > We also need a man-page for skivi (the image viewer).  I've uploaded a
> template:
>
> >
> https://github.com/scikits-image/scikits-image/blob/debian/debian/skivi.1
>
> > > One thing I'd like to see is a package docstring listing all
> subpackages (+
> > > 1-sentence descriptions of those subpackages; e.g. type `np?` in
> ipython);
> > > and then each subpackage would have it's own docstring listing of
> functions
> > > (e.g. type `numpy.linalg?` in ipython). I guess this is separate from
> the
> > > user guide, but it's still really valuable for learning the package.
>
> > Yes, good point!
>
> > > While we're talking about release 0.5, I think we should try to clean
> out a
> > > number of pull requests. Some of them should be quick:
>
> > > PR 99: Rewrite dtype._convert function
>
> > Merged (by me).
>
> > > PR 105: ENH: Allow choice between 4 and 8 neighbor mode.
>
> > Merged (by Tony).
>
> > > PR 95: debian/control updates to reflect name space transition
>
> > Rejected (mainly adding the author's name, but very few changes).  I
> > updated the control file to be up to date in the meantime.
>
> > > PR 107: Add rescale_intensity function with test and example.
>
> > I'm keen to merge this; we're just waiting for the rest of the list to
> > comment on the matplotlib 1.0 dependency.
>
> > Cheers
> > St?fan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120204/2c7979db/attachment.html>

From kmichael.aye at gmail.com  Mon Feb  6 06:28:05 2012
From: kmichael.aye at gmail.com (Michael Aye)
Date: Mon, 6 Feb 2012 03:28:05 -0800 (PST)
Subject: Documentation sprint over the weekend
In-Reply-To: <CAEym_Hp-Qke-Ko8iUbo7Qy7cSg_GL2B-h7nTjPcPtejJvn=eBg@mail.gmail.com>
References: <CABDkGQ=8xdHN-3Y7WmJuGKCjLwnQdubHmi1Wd-E29R60jPqkjA@mail.gmail.com>
 <CAEym_HpyBn+9JbabmBA+eycsVVg51xKeNNqV=7h8_-5_P7QQFA@mail.gmail.com>
 <CABDkGQkdaaX6WSdfJ+68wTb__RO8wFiPaZ0BJYPKnRtQTS1DTg@mail.gmail.com>
 <20120204122839.GA31382@phare.normalesup.org> <CAEym_Hp-Qke-Ko8iUbo7Qy7cSg_GL2B-h7nTjPcPtejJvn=eBg@mail.gmail.com>
Message-ID: <d87a9c23-3798-428b-84c4-e47d97eb13a1@g27g2000yqa.googlegroups.com>

I think it would be helpful, if the gallery would mention from which
version on a feature/method is available. Currently, for example, it
seems not clear from the website that exposure and harris are only
available from github only, or did I miss something?

Best regards,
Michael

On Feb 4, 8:47?pm, Tony Yu <tsy... at gmail.com> wrote:
> On Sat, Feb 4, 2012 at 7:28 AM, Emmanuelle Gouillart <
>
> emmanuelle.gouill... at nsup.org> wrote:
> > Hi,
>
> > I'll try to work on the "getting help" part of the user guide, then.
>
> > Cheers,
> > Emmanuelle
>
> I'll get to work on the data-types and processing pipeline. I may not have
> as much time as expected, though, since I got sidetracked by other PRs.
>
> Cheers,
> -Tony
>
>
>
>
>
>
>
>
>
> > > - Introduction
> > > ? ?(installation -- link to existing docs, overview and how we fit in
> > > on top of scipy, our goals, what we provide)
> > > - Reading and displaying image
> > > ? ?(io module, display, fancy=True, using matplotlib, etc.)
> > > - Data-types and the pipeline
> > > ? ?(dtype conversion, how to ensure your output is in the right
> > > format, all functions accept any input but returns preferred dtype
> > > output--user should call img_as_*)
> > > - Getting help
> > > ? ?(reference guide, examples gallery, maybe image processing specific
> > > websites similar to metaoptimize.com/qa )
>
> > > And some tutorials are always welcome--although I think the gallery
> > > now largely fulfills that role.
>
> > > Did I miss anything important?
>
> > > We also need a man-page for skivi (the image viewer). ?I've uploaded a
> > template:
>
> >https://github.com/scikits-image/scikits-image/blob/debian/debian/ski...
>
> > > > One thing I'd like to see is a package docstring listing all
> > subpackages (+
> > > > 1-sentence descriptions of those subpackages; e.g. type `np?` in
> > ipython);
> > > > and then each subpackage would have it's own docstring listing of
> > functions
> > > > (e.g. type `numpy.linalg?` in ipython). I guess this is separate from
> > the
> > > > user guide, but it's still really valuable for learning the package.
>
> > > Yes, good point!
>
> > > > While we're talking about release 0.5, I think we should try to clean
> > out a
> > > > number of pull requests. Some of them should be quick:
>
> > > > PR 99: Rewrite dtype._convert function
>
> > > Merged (by me).
>
> > > > PR 105: ENH: Allow choice between 4 and 8 neighbor mode.
>
> > > Merged (by Tony).
>
> > > > PR 95: debian/control updates to reflect name space transition
>
> > > Rejected (mainly adding the author's name, but very few changes). ?I
> > > updated the control file to be up to date in the meantime.
>
> > > > PR 107: Add rescale_intensity function with test and example.
>
> > > I'm keen to merge this; we're just waiting for the rest of the list to
> > > comment on the matplotlib 1.0 dependency.
>
> > > Cheers
> > > St?fan


From kmichael.aye at gmail.com  Mon Feb  6 12:43:07 2012
From: kmichael.aye at gmail.com (Michael Aye)
Date: Mon, 6 Feb 2012 09:43:07 -0800 (PST)
Subject: skimage module not found by iPython's completion?
Message-ID: <d128f1ad-f97b-4a79-873b-af8e74fe34dc@w19g2000vbe.googlegroups.com>

Hi all,

I noticed some weirds things with iPython's completion regarding
skimage v0.12.
When typing 'import sk' and then pressing <tab> to complete the import
line, iPython cannot find skimage.
But if I type 'import skimage' on my own, it works.
Then, I type 'skimage.' and press <tab> to inspect the module, and I
get:

skimage.data_dir      skimage.img_as_int    skimage.pkg_dir
skimage.util
skimage.get_log       skimage.img_as_ubyte  skimage.test
skimage.version
skimage.img_as_float  skimage.img_as_uint   skimage.test_verbose

(= half missing).

Anybody knows what's going on here? I'm puzzled...

Best regards,
Michael


From tsyu80 at gmail.com  Mon Feb  6 10:33:16 2012
From: tsyu80 at gmail.com (Tony Yu)
Date: Mon, 6 Feb 2012 10:33:16 -0500
Subject: Documentation sprint over the weekend
In-Reply-To: <d87a9c23-3798-428b-84c4-e47d97eb13a1@g27g2000yqa.googlegroups.com>
References: <CABDkGQ=8xdHN-3Y7WmJuGKCjLwnQdubHmi1Wd-E29R60jPqkjA@mail.gmail.com>
	<CAEym_HpyBn+9JbabmBA+eycsVVg51xKeNNqV=7h8_-5_P7QQFA@mail.gmail.com>
	<CABDkGQkdaaX6WSdfJ+68wTb__RO8wFiPaZ0BJYPKnRtQTS1DTg@mail.gmail.com>
	<20120204122839.GA31382@phare.normalesup.org>
	<CAEym_Hp-Qke-Ko8iUbo7Qy7cSg_GL2B-h7nTjPcPtejJvn=eBg@mail.gmail.com>
	<d87a9c23-3798-428b-84c4-e47d97eb13a1@g27g2000yqa.googlegroups.com>
Message-ID: <CAEym_Hr0NnQhkE=6fgjHvvivC2Eu6p1ySB8iS9_TC5-FHaa2hQ@mail.gmail.com>

On Mon, Feb 6, 2012 at 6:28 AM, Michael Aye <kmichael.aye at gmail.com> wrote:

> I think it would be helpful, if the gallery would mention from which
> version on a feature/method is available. Currently, for example, it
> seems not clear from the website that exposure and harris are only
> available from github only, or did I miss something?
>
> Best regards,
> Michael
>

Hi Michael,

You're correct: exposure and harris are only available in the development
version of scikits-image. Currently we just have different versions of the
docs for each release (and for the dev version). For example, there's are a
separate gallery for skimage
v0.4<http://scikits-image.org/docs/0.4/auto_examples/index.html>
.

It might be a bit much to add labels to each example in the gallery, but I
do think it should be clearer that you're looking at the development
version of the documentation. (I think the only indication is on the
homepage and the url.) Maybe we should specify the version in the sidebar
and add links to older versions. We could also add version notes (e.g. "New
in skimage v0.5") in the examples themselves and/or in the function
docstrings---could this be automated some how?

-Tony


>
> On Feb 4, 8:47 pm, Tony Yu <tsy... at gmail.com> wrote:
> > On Sat, Feb 4, 2012 at 7:28 AM, Emmanuelle Gouillart <
> >
> > emmanuelle.gouill... at nsup.org> wrote:
> > > Hi,
> >
> > > I'll try to work on the "getting help" part of the user guide, then.
> >
> > > Cheers,
> > > Emmanuelle
> >
> > I'll get to work on the data-types and processing pipeline. I may not
> have
> > as much time as expected, though, since I got sidetracked by other PRs.
> >
> > Cheers,
> > -Tony
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > > - Introduction
> > > >    (installation -- link to existing docs, overview and how we fit in
> > > > on top of scipy, our goals, what we provide)
> > > > - Reading and displaying image
> > > >    (io module, display, fancy=True, using matplotlib, etc.)
> > > > - Data-types and the pipeline
> > > >    (dtype conversion, how to ensure your output is in the right
> > > > format, all functions accept any input but returns preferred dtype
> > > > output--user should call img_as_*)
> > > > - Getting help
> > > >    (reference guide, examples gallery, maybe image processing
> specific
> > > > websites similar to metaoptimize.com/qa )
> >
> > > > And some tutorials are always welcome--although I think the gallery
> > > > now largely fulfills that role.
> >
> > > > Did I miss anything important?
> >
> > > > We also need a man-page for skivi (the image viewer).  I've uploaded
> a
> > > template:
> >
> > >https://github.com/scikits-image/scikits-image/blob/debian/debian/ski.
> ..
> >
> > > > > One thing I'd like to see is a package docstring listing all
> > > subpackages (+
> > > > > 1-sentence descriptions of those subpackages; e.g. type `np?` in
> > > ipython);
> > > > > and then each subpackage would have it's own docstring listing of
> > > functions
> > > > > (e.g. type `numpy.linalg?` in ipython). I guess this is separate
> from
> > > the
> > > > > user guide, but it's still really valuable for learning the
> package.
> >
> > > > Yes, good point!
> >
> > > > > While we're talking about release 0.5, I think we should try to
> clean
> > > out a
> > > > > number of pull requests. Some of them should be quick:
> >
> > > > > PR 99: Rewrite dtype._convert function
> >
> > > > Merged (by me).
> >
> > > > > PR 105: ENH: Allow choice between 4 and 8 neighbor mode.
> >
> > > > Merged (by Tony).
> >
> > > > > PR 95: debian/control updates to reflect name space transition
> >
> > > > Rejected (mainly adding the author's name, but very few changes).  I
> > > > updated the control file to be up to date in the meantime.
> >
> > > > > PR 107: Add rescale_intensity function with test and example.
> >
> > > > I'm keen to merge this; we're just waiting for the rest of the list
> to
> > > > comment on the matplotlib 1.0 dependency.
> >
> > > > Cheers
> > > > St?fan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120206/525884d0/attachment.html>

From kmichael.aye at gmail.com  Mon Feb  6 14:32:32 2012
From: kmichael.aye at gmail.com (Michael Aye)
Date: Mon, 6 Feb 2012 11:32:32 -0800 (PST)
Subject: skimage module not found by iPython's completion?
In-Reply-To: <CAEym_HqcWArjPQcyK2d4BBVv6srwOSYN81zH4pViheMd4aVzDQ@mail.gmail.com>
References: <d128f1ad-f97b-4a79-873b-af8e74fe34dc@w19g2000vbe.googlegroups.com>
 <CAEym_HqcWArjPQcyK2d4BBVv6srwOSYN81zH4pViheMd4aVzDQ@mail.gmail.com>
Message-ID: <2b9a4fba-145b-471a-b86f-ed3f430cd53e@dn8g2000vbb.googlegroups.com>

Thanks, works fine!

Michael

On Feb 6, 8:12?pm, Tony Yu <tsy... at gmail.com> wrote:
> On Mon, Feb 6, 2012 at 12:43 PM, Michael Aye <kmichael.... at gmail.com> wrote:
> > Hi all,
>
> > I noticed some weirds things with iPython's completion regarding
> > skimage v0.12.
> > When typing 'import sk' and then pressing <tab> to complete the import
> > line, iPython cannot find skimage.
> > But if I type 'import skimage' on my own, it works.
> > Then, I type 'skimage.' and press <tab> to inspect the module, and I
> > get:
>
> > skimage.data_dir ? ? ?skimage.img_as_int ? ?skimage.pkg_dir
> > skimage.util
> > skimage.get_log ? ? ? skimage.img_as_ubyte ?skimage.test
> > skimage.version
> > skimage.img_as_float ?skimage.img_as_uint ? skimage.test_verbose
>
> > (= half missing).
>
> > Anybody knows what's going on here? I'm puzzled...
>
> > Best regards,
> > Michael
>
> Huh, I guess I didn't notice this first issue until you mentioned it. Turns
> out<http://stackoverflow.com/questions/1552961/ipython-tab-completes-only...>there's
> an easy fix: Run `%rehashx` in ipython to rebuild the database of
> known modules.
>
> As for the second issue: We don't automatically import any subpackages
> (other than `util`). This was a design decision since automatic imports of
> all subpackages would increase load times (there may be other reasons too).
> On the other hand, if you just want to see which submodules are available
> for import, you can write `import skimage.<tab>` (note the dot before
> <tab>) or `from skimage import<tab>` in ipython.
>
> Hope that helps,
> -Tony


From stefan at sun.ac.za  Mon Feb  6 15:01:11 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 6 Feb 2012 12:01:11 -0800
Subject: Documentation sprint over the weekend
In-Reply-To: <d87a9c23-3798-428b-84c4-e47d97eb13a1@g27g2000yqa.googlegroups.com>
References: <CABDkGQ=8xdHN-3Y7WmJuGKCjLwnQdubHmi1Wd-E29R60jPqkjA@mail.gmail.com>
 <CAEym_HpyBn+9JbabmBA+eycsVVg51xKeNNqV=7h8_-5_P7QQFA@mail.gmail.com>
 <CABDkGQkdaaX6WSdfJ+68wTb__RO8wFiPaZ0BJYPKnRtQTS1DTg@mail.gmail.com>
 <20120204122839.GA31382@phare.normalesup.org> <CAEym_Hp-Qke-Ko8iUbo7Qy7cSg_GL2B-h7nTjPcPtejJvn=eBg@mail.gmail.com>
 <d87a9c23-3798-428b-84c4-e47d97eb13a1@g27g2000yqa.googlegroups.com>
Message-ID: <CABDkGQnTaNJD3cEngoG38e8k4oP9i0GcGc0dL2pyUoxQTyRLbA@mail.gmail.com>

On Mon, Feb 6, 2012 at 3:28 AM, Michael Aye <kmichael.aye at gmail.com> wrote:
> I think it would be helpful, if the gallery would mention from which
> version on a feature/method is available. Currently, for example, it
> seems not clear from the website that exposure and harris are only
> available from github only, or did I miss something?

Thanks, Michael, that's a good point.  Tony's suggestions sound like
the way to go; in the mean time, here's a PR to add the version number
to each example:

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

St?fan


From stefan at sun.ac.za  Mon Feb  6 15:14:19 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 6 Feb 2012 12:14:19 -0800
Subject: skimage module not found by iPython's completion?
In-Reply-To: <CAEym_HqcWArjPQcyK2d4BBVv6srwOSYN81zH4pViheMd4aVzDQ@mail.gmail.com>
References: <d128f1ad-f97b-4a79-873b-af8e74fe34dc@w19g2000vbe.googlegroups.com>
 <CAEym_HqcWArjPQcyK2d4BBVv6srwOSYN81zH4pViheMd4aVzDQ@mail.gmail.com>
Message-ID: <CABDkGQnZXD26iWOV4FSWQEPNsjkrE8_de8XfnugKQrkCEwRFyg@mail.gmail.com>

On Mon, Feb 6, 2012 at 11:12 AM, Tony Yu <tsyu80 at gmail.com> wrote:
> As for the second issue: We don't automatically import any subpackages
> (other than `util`). This was a design decision since automatic imports of
> all subpackages would increase load times (there may be other reasons too).
> On the other hand, if you just want to see which submodules are available
> for import, you can write `import skimage.<tab>` (note the dot before <tab>)
> or `from skimage import<tab>` in ipython.

Besides, Tony is busy updating all the module level docstrings, so
that "skimage?" should soon deliver useful results :)

Cheers
St?fan


From tsyu80 at gmail.com  Mon Feb  6 14:12:56 2012
From: tsyu80 at gmail.com (Tony Yu)
Date: Mon, 6 Feb 2012 14:12:56 -0500
Subject: skimage module not found by iPython's completion?
In-Reply-To: <d128f1ad-f97b-4a79-873b-af8e74fe34dc@w19g2000vbe.googlegroups.com>
References: <d128f1ad-f97b-4a79-873b-af8e74fe34dc@w19g2000vbe.googlegroups.com>
Message-ID: <CAEym_HqcWArjPQcyK2d4BBVv6srwOSYN81zH4pViheMd4aVzDQ@mail.gmail.com>

On Mon, Feb 6, 2012 at 12:43 PM, Michael Aye <kmichael.aye at gmail.com> wrote:

> Hi all,
>
> I noticed some weirds things with iPython's completion regarding
> skimage v0.12.
> When typing 'import sk' and then pressing <tab> to complete the import
> line, iPython cannot find skimage.
> But if I type 'import skimage' on my own, it works.
> Then, I type 'skimage.' and press <tab> to inspect the module, and I
> get:
>
> skimage.data_dir      skimage.img_as_int    skimage.pkg_dir
> skimage.util
> skimage.get_log       skimage.img_as_ubyte  skimage.test
> skimage.version
> skimage.img_as_float  skimage.img_as_uint   skimage.test_verbose
>
> (= half missing).
>
> Anybody knows what's going on here? I'm puzzled...
>
> Best regards,
> Michael


Huh, I guess I didn't notice this first issue until you mentioned it. Turns
out<http://stackoverflow.com/questions/1552961/ipython-tab-completes-only-some-modules>there's
an easy fix: Run `%rehashx` in ipython to rebuild the database of
known modules.

As for the second issue: We don't automatically import any subpackages
(other than `util`). This was a design decision since automatic imports of
all subpackages would increase load times (there may be other reasons too).
On the other hand, if you just want to see which submodules are available
for import, you can write `import skimage.<tab>` (note the dot before
<tab>) or `from skimage import<tab>` in ipython.

Hope that helps,
-Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120206/b8a7f351/attachment.html>

From tsyu80 at gmail.com  Mon Feb  6 15:45:10 2012
From: tsyu80 at gmail.com (Tony Yu)
Date: Mon, 6 Feb 2012 15:45:10 -0500
Subject: skimage module not found by iPython's completion?
In-Reply-To: <CABDkGQnZXD26iWOV4FSWQEPNsjkrE8_de8XfnugKQrkCEwRFyg@mail.gmail.com>
References: <d128f1ad-f97b-4a79-873b-af8e74fe34dc@w19g2000vbe.googlegroups.com>
	<CAEym_HqcWArjPQcyK2d4BBVv6srwOSYN81zH4pViheMd4aVzDQ@mail.gmail.com>
	<CABDkGQnZXD26iWOV4FSWQEPNsjkrE8_de8XfnugKQrkCEwRFyg@mail.gmail.com>
Message-ID: <CAEym_HoLmRxopWYbEgug7F-_w7ytsX4GVYZ34gD7RTm4MqNTVQ@mail.gmail.com>

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

> On Mon, Feb 6, 2012 at 11:12 AM, Tony Yu <tsyu80 at gmail.com> wrote:
> > As for the second issue: We don't automatically import any subpackages
> > (other than `util`). This was a design decision since automatic imports
> of
> > all subpackages would increase load times (there may be other reasons
> too).
> > On the other hand, if you just want to see which submodules are available
> > for import, you can write `import skimage.<tab>` (note the dot before
> <tab>)
> > or `from skimage import<tab>` in ipython.
>
> Besides, Tony is busy updating all the module level docstrings, so
> that "skimage?" should soon deliver useful results :)
>
> Cheers
> St?fan
>

Wait a minute... Let me quote what I wrote in the original email: "One
thing I'd like to see is a package docstring listing all subpackages..."

Note: I didn't say that I would implement it ;)

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

From stefan at sun.ac.za  Tue Feb  7 04:02:50 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 7 Feb 2012 01:02:50 -0800
Subject: StackOverflow fun
Message-ID: <CABDkGQ=8ev4SeN9vG+y-vNp-Sk4DWhJ7w7MWNqO-yyORkyuG2g@mail.gmail.com>

Hi all,

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

What can I say...you guys collectively kick ass :)

Cheers
St?fan


From kmichael.aye at gmail.com  Tue Feb  7 07:47:51 2012
From: kmichael.aye at gmail.com (Michael Aye)
Date: Tue, 7 Feb 2012 04:47:51 -0800 (PST)
Subject: random walker segmentation / blob detection
Message-ID: <27207519.2086.1328618871447.JavaMail.geo-discussion-forums@yqcz12>

Hi folks,

I am searching for the best way of doing blob detection in my noisy 
planetary image data but I just can't find the egg-laying woolen 
milk-giving pig (german proverb) that would solve all my problems, but then 
again it wouldn't be called research, if there's nothing to research, 
right? ;)

In this case, I don't understand the working principle of the 
random_walker_segmentation example for one simple reason (i.e. 2 simple 
lines ;) ):

markers[data < -0.3] = 1
> markers[data > 1.3] = 2


Where do I get these thresholds from? In fact, finding reasonable 
thresholds that for sure contain the objects I am interested in is the 
whole problem, isn't it?
If I have to read out 'reasonable' values from the histogram first, how 
would I do that?

I played with 'significance' thresholding, something like dark pixels have 
to be x*sigma away from a median image pixel value, but then 
randomly-shaped shadows in noisy data that has no blobs are also being 
identified as blobs, which I need to avoid (see attached images with and 
without blobs).
I also tried already to get rid of identified shadows using morphology 
operators (something like a proper blob has to survive 2 or 3 erosion 
operators) but this is not clean enough either.

Can you maybe recommend a chain of image operations that would find me 
blobs in noisy data while having a low rate of false positives?

Best regards,
Michael

PS.: I can't exclude that my brain is using a shape-related expectation 
about how the blobs have to look like, so maybe I have to put that into the 
game as well?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120207/1bdeff39/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blobs.png
Type: image/png
Size: 323581 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120207/1bdeff39/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: no_blobs.png
Type: image/png
Size: 337395 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120207/1bdeff39/attachment-0001.png>

From kmichael.aye at gmail.com  Tue Feb  7 13:38:59 2012
From: kmichael.aye at gmail.com (Michael Aye)
Date: Tue, 7 Feb 2012 10:38:59 -0800 (PST)
Subject: random walker segmentation / blob detection
In-Reply-To: <27207519.2086.1328618871447.JavaMail.geo-discussion-forums@yqcz12>
References: <27207519.2086.1328618871447.JavaMail.geo-discussion-forums@yqcz12>
Message-ID: <15809851.4267.1328639939474.JavaMail.geo-discussion-forums@vbtq34>

I have played with this and the size of the resulting segmentation is 
extremely sensitive to the marker thresholds, something that I can't allow, 
as I want to calculate the blob-covered area as well.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120207/acdd2cde/attachment.html>

From stefan at sun.ac.za  Tue Feb  7 14:30:29 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 7 Feb 2012 11:30:29 -0800
Subject: FreeImage binaries
In-Reply-To: <F61A02CB-649C-41C0-893A-8C30055A2B2B@yale.edu>
References: <F61A02CB-649C-41C0-893A-8C30055A2B2B@yale.edu>
Message-ID: <CABDkGQkJwb6fbH6n-yrmZp-7fwWmqt_0MwzpB_C9B2NR1y708w@mail.gmail.com>

Hi Zach

On Tue, Feb 7, 2012 at 8:44 AM, Zachary Pincus <zachary.pincus at yale.edu> wrote:
> For this we'd want an OS X dylib that's at least 32/64-bit, if not a four-way (intel/ppc 32/64). This should be pretty easy for me to make. We'd also want standalone 32- and 64-bit windows DLLs. And should we have anything for linux, or do we assume that those people can get FreeImage compiled manually or via a package manager easily enough?
>
> I could just package these up as "data" in a python module, and then point ctypes at the right lib based on run-time checks. Maybe silly to distribute extra binaries, but that might be the user-friendliest solution? Other feedback welcome of course.

I think distributing these is a good idea; but I'm a bit hesitant to
include the binaries in the source repo.  How about we modify the
bdist command to fetch these binaries from GitHub, and then store them
in their own repo?

St?fan


From zachary.pincus at yale.edu  Tue Feb  7 11:44:42 2012
From: zachary.pincus at yale.edu (Zachary Pincus)
Date: Tue, 7 Feb 2012 11:44:42 -0500
Subject: FreeImage binaries
Message-ID: <F61A02CB-649C-41C0-893A-8C30055A2B2B@yale.edu>

Hey all,

Some conversation on the pythonvision list (about a "simple python image IO library") has suggested to me that perhaps we should consider distributing FreeImage binaries either with skimage, or as a simple add-on package.

For this we'd want an OS X dylib that's at least 32/64-bit, if not a four-way (intel/ppc 32/64). This should be pretty easy for me to make. We'd also want standalone 32- and 64-bit windows DLLs. And should we have anything for linux, or do we assume that those people can get FreeImage compiled manually or via a package manager easily enough?

I could just package these up as "data" in a python module, and then point ctypes at the right lib based on run-time checks. Maybe silly to distribute extra binaries, but that might be the user-friendliest solution? Other feedback welcome of course.

Zach


From stefan at sun.ac.za  Tue Feb  7 14:54:01 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 7 Feb 2012 11:54:01 -0800
Subject: random walker segmentation / blob detection
In-Reply-To: <27207519.2086.1328618871447.JavaMail.geo-discussion-forums@yqcz12>
References: <27207519.2086.1328618871447.JavaMail.geo-discussion-forums@yqcz12>
Message-ID: <CABDkGQnLd+sibOQt6JGkL=vWQ++ymXUyX+BaF5q_+w=zhgRj4A@mail.gmail.com>

Hey Michael

On Tue, Feb 7, 2012 at 4:47 AM, Michael Aye <kmichael.aye at gmail.com> wrote:
> I am searching for the best way of doing blob detection in my noisy
> planetary image data but I just can't find the egg-laying woolen milk-giving
> pig (german proverb) that would solve all my problems, but then again it
> wouldn't be called research, if there's nothing to research, right? ;)

I played around with your images in

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

just to get a feel for what we're dealing with here.  A first result:

http://mentat.za.net/refer/aye_planet0.png
http://mentat.za.net/refer/aye_planet1.png

This technique, specifically, is a non-linear filter, but I think you
should be able to achieve the same with a simpler pipeline:

1) Filter out the image noise
2) Find structures of the appropriate range of sizes in the image
(maybe using difference of Gaussians or other blob detection)
3) Threshold

If you have enough examples of the kind of blobs you're trying to
find, you can train a classifier to set thresholds.  Otherwise, try to
incorporate any knowledge you have from beforehand (i.e., the blobs
are roughly X in size, roughly Y in colour, roughly Z in shape).

Keep us up to date with your progress, and thanks for the interesting
discussion.

Cheers
St?fan


From stefan at sun.ac.za  Tue Feb  7 14:56:13 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 7 Feb 2012 11:56:13 -0800
Subject: FreeImage binaries
In-Reply-To: <CC370626-3242-4133-B367-9D8BA5D011D4@yale.edu>
References: <F61A02CB-649C-41C0-893A-8C30055A2B2B@yale.edu>
 <CABDkGQkJwb6fbH6n-yrmZp-7fwWmqt_0MwzpB_C9B2NR1y708w@mail.gmail.com> <CC370626-3242-4133-B367-9D8BA5D011D4@yale.edu>
Message-ID: <CABDkGQnKsz=yV1G2owDf5P29GiTF_veMA-ZL3HS+wX_mEXFvpg@mail.gmail.com>

On Tue, Feb 7, 2012 at 11:38 AM, Zachary Pincus <zachary.pincus at yale.edu> wrote:
> That's a decent idea -- and that way, we could only fetch the appropriate binary for each bdist, instead of shipping all of them.
>
> Any way to make the install command do this as well, for those who install from source?
>
> In either case, though, I'm a bit out of my element in the distutils hackery to make this sort of thing happen...

As a start, how about just getting a Python script going for doing the
fetching + moving?  Once that is done, I think it won't be too hard to
get distutils to play along.  At worst, we can tell all Windows/Mac
users to do

from skimage import install_libs
install_libs()

after installation.

Cheers
St?fan


From stefan at sun.ac.za  Tue Feb  7 16:10:13 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 7 Feb 2012 13:10:13 -0800
Subject: FreeImage binaries
In-Reply-To: <1F493141-EFAF-42D3-B709-7F7AC101F76F@yale.edu>
References: <F61A02CB-649C-41C0-893A-8C30055A2B2B@yale.edu>
 <CABDkGQkJwb6fbH6n-yrmZp-7fwWmqt_0MwzpB_C9B2NR1y708w@mail.gmail.com>
 <CC370626-3242-4133-B367-9D8BA5D011D4@yale.edu> <CABDkGQnKsz=yV1G2owDf5P29GiTF_veMA-ZL3HS+wX_mEXFvpg@mail.gmail.com>
 <9E376917-3E60-42B9-8379-9F10920CD088@yale.edu> <1F493141-EFAF-42D3-B709-7F7AC101F76F@yale.edu>
Message-ID: <CABDkGQn9SaZ22gv=Z-GR2nSsTPCzMCKhp2ri31CZ+yDbADC18Q@mail.gmail.com>

On Tue, Feb 7, 2012 at 12:13 PM, Zachary Pincus <zachary.pincus at yale.edu> wrote:
> Also, is anyone a license-maven? Is this sort of thing (distributing binaries, then downloading and run-time loading them in a BSD-licensced project) OK under the GPL (v2) or the FreeImage license?
> http://freeimage.sourceforge.net/license.html

Meh, licensing :)

My take (and these issues are tricky, so IANAL and all that):

The combined work (skimage + freeimage) must be distributed under the
terms of the GPL.  Our license (the Modified BSD) is more permissive
than the GPL, so the GPL simply imposes some additional restrictions.

As far as I understand, you are within your rights to distribute
patches to GPL code under any license you wish (which is, in a tenuous
sense, what we're doing).

When we distribute skimage + the freeimage plugin (but no freeimage
binary), our distribution is only governed by the permissive BSD.
E.g., a company may use our code with the Matlotlib backend, mix it in
with their own (proprietary) code, and not have to worry about
anything.  If we write the "install_libs" command, we may want to
clearly state what the implications are.

Also, an interesting perspective on incorporating BSD code into GPL projects:

http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html

St?fan


From stefan at sun.ac.za  Tue Feb  7 16:34:39 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 7 Feb 2012 13:34:39 -0800
Subject: FreeImage binaries
In-Reply-To: <9A2AC320-EC62-49F9-946A-CF4AEB9620EF@yale.edu>
References: <F61A02CB-649C-41C0-893A-8C30055A2B2B@yale.edu>
 <CABDkGQkJwb6fbH6n-yrmZp-7fwWmqt_0MwzpB_C9B2NR1y708w@mail.gmail.com>
 <CC370626-3242-4133-B367-9D8BA5D011D4@yale.edu> <CABDkGQnKsz=yV1G2owDf5P29GiTF_veMA-ZL3HS+wX_mEXFvpg@mail.gmail.com>
 <9E376917-3E60-42B9-8379-9F10920CD088@yale.edu> <1F493141-EFAF-42D3-B709-7F7AC101F76F@yale.edu>
 <CABDkGQn9SaZ22gv=Z-GR2nSsTPCzMCKhp2ri31CZ+yDbADC18Q@mail.gmail.com> <9A2AC320-EC62-49F9-946A-CF4AEB9620EF@yale.edu>
Message-ID: <CABDkGQ=CiicQnw27zbTkYJahZu8RyB8JDvS5gib0AhY7RvTa8Q@mail.gmail.com>

On Tue, Feb 7, 2012 at 1:18 PM, Zachary Pincus <zachary.pincus at yale.edu> wrote:
> And as you can see, I've put up the binaries I have so far here:
> https://github.com/zachrahan/freeimage-sharedlib
>
> I still need a win64 DLL. And I also have no idea what the story is with linux shared libs -- is it easy to distribute such for a given architecture, or do these get so fragmented that it makes more sense to just have the user make their package manager install FreeImage?

Thanks.  I think under Linux we're OK.  We just need to modify the
plugin to at least pick up on the default naming conventions (Debian,
e.g., names it libfreeimage.so.3, which we don't find).

St?fan


From stefan at sun.ac.za  Tue Feb  7 16:39:55 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 7 Feb 2012 13:39:55 -0800
Subject: FreeImage binaries
In-Reply-To: <9A2AC320-EC62-49F9-946A-CF4AEB9620EF@yale.edu>
References: <F61A02CB-649C-41C0-893A-8C30055A2B2B@yale.edu>
 <CABDkGQkJwb6fbH6n-yrmZp-7fwWmqt_0MwzpB_C9B2NR1y708w@mail.gmail.com>
 <CC370626-3242-4133-B367-9D8BA5D011D4@yale.edu> <CABDkGQnKsz=yV1G2owDf5P29GiTF_veMA-ZL3HS+wX_mEXFvpg@mail.gmail.com>
 <9E376917-3E60-42B9-8379-9F10920CD088@yale.edu> <1F493141-EFAF-42D3-B709-7F7AC101F76F@yale.edu>
 <CABDkGQn9SaZ22gv=Z-GR2nSsTPCzMCKhp2ri31CZ+yDbADC18Q@mail.gmail.com> <9A2AC320-EC62-49F9-946A-CF4AEB9620EF@yale.edu>
Message-ID: <CABDkGQmtctDO8qNVOvS3+Lqi5W6iQ2rESAXUXhwcuw7UrCE5SQ@mail.gmail.com>

On Tue, Feb 7, 2012 at 1:18 PM, Zachary Pincus <zachary.pincus at yale.edu> wrote:
relevant readme when we cause the binaries to be downloaded. But
another opinion might be useful, if you want to look at that license:
> https://github.com/zachrahan/freeimage-sharedlib/blob/master/license-fi.txt

This license is very clear on the relevant points:

"You may distribute the Executable version of Covered Code under a
license of Your choice, which may contain terms different from this
License,
provided that You are in compliance with the terms of this License and
that the license for the Executable version does not attempt to limit
or alter the recipient's rights in the Source Code version from the
rights set forth in this License. If You distribute the Executable
version under a different license You must make it absolutely clear
that any terms which differ from this License are offered by You
alone, not by the Initial Developer or any Contributor. You hereby
agree to indemnify the Initial Developer and every Contributor for any
liability incurred by the Initial Developer or such Contributor as a
result of any such terms You offer.

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

I think we're perfectly safe, as long as we then provide the license
file as well.  In this case, we can even distribute skimage+freeimage
package binaries without concern.

St?fan


From stefan at sun.ac.za  Tue Feb  7 16:57:00 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 7 Feb 2012 13:57:00 -0800
Subject: FreeImage binaries
In-Reply-To: <DF0F7EA0-27F5-454D-BF73-721756AE0E56@yale.edu>
References: <F61A02CB-649C-41C0-893A-8C30055A2B2B@yale.edu>
 <CABDkGQkJwb6fbH6n-yrmZp-7fwWmqt_0MwzpB_C9B2NR1y708w@mail.gmail.com>
 <CC370626-3242-4133-B367-9D8BA5D011D4@yale.edu> <CABDkGQnKsz=yV1G2owDf5P29GiTF_veMA-ZL3HS+wX_mEXFvpg@mail.gmail.com>
 <9E376917-3E60-42B9-8379-9F10920CD088@yale.edu> <1F493141-EFAF-42D3-B709-7F7AC101F76F@yale.edu>
 <CABDkGQn9SaZ22gv=Z-GR2nSsTPCzMCKhp2ri31CZ+yDbADC18Q@mail.gmail.com>
 <9A2AC320-EC62-49F9-946A-CF4AEB9620EF@yale.edu> <CABDkGQ=CiicQnw27zbTkYJahZu8RyB8JDvS5gib0AhY7RvTa8Q@mail.gmail.com>
 <DF0F7EA0-27F5-454D-BF73-721756AE0E56@yale.edu>
Message-ID: <CABDkGQmytMDBiFYZUzA+rfB6QmeOYVgEeE7cCEZO_xvpX+MFmg@mail.gmail.com>

On Tue, Feb 7, 2012 at 1:41 PM, Zachary Pincus <zachary.pincus at yale.edu> wrote:
>> Thanks. ?I think under Linux we're OK. ?We just need to modify the
>> plugin to at least pick up on the default naming conventions (Debian,
>> e.g., names it libfreeimage.so.3, which we don't find).
>
>
> Thanks! If anyone can give me any guidance on the matter of locating libraries on different linux flavors, I'd be grateful. I'm unfortunately basically linux-ignorant.

I think if we look for liblibrary.so.majorversion as well as
liblibrary.so in the standard locations (/lib, /usr/lib,
/usr/local/lib, /opt/lib) we should be ok.

Cheers
St?fan


From zachary.pincus at yale.edu  Tue Feb  7 14:38:02 2012
From: zachary.pincus at yale.edu (Zachary Pincus)
Date: Tue, 7 Feb 2012 14:38:02 -0500
Subject: FreeImage binaries
In-Reply-To: <CABDkGQkJwb6fbH6n-yrmZp-7fwWmqt_0MwzpB_C9B2NR1y708w@mail.gmail.com>
References: <F61A02CB-649C-41C0-893A-8C30055A2B2B@yale.edu> <CABDkGQkJwb6fbH6n-yrmZp-7fwWmqt_0MwzpB_C9B2NR1y708w@mail.gmail.com>
Message-ID: <CC370626-3242-4133-B367-9D8BA5D011D4@yale.edu>

>> For this we'd want an OS X dylib that's at least 32/64-bit, if not a four-way (intel/ppc 32/64). This should be pretty easy for me to make. We'd also want standalone 32- and 64-bit windows DLLs. And should we have anything for linux, or do we assume that those people can get FreeImage compiled manually or via a package manager easily enough?
>> 
>> I could just package these up as "data" in a python module, and then point ctypes at the right lib based on run-time checks. Maybe silly to distribute extra binaries, but that might be the user-friendliest solution? Other feedback welcome of course.
> 
> I think distributing these is a good idea; but I'm a bit hesitant to
> include the binaries in the source repo.  How about we modify the
> bdist command to fetch these binaries from GitHub, and then store them
> in their own repo?

That's a decent idea -- and that way, we could only fetch the appropriate binary for each bdist, instead of shipping all of them.

Any way to make the install command do this as well, for those who install from source?

In either case, though, I'm a bit out of my element in the distutils hackery to make this sort of thing happen...

Zach



From zachary.pincus at yale.edu  Tue Feb  7 15:04:32 2012
From: zachary.pincus at yale.edu (Zachary Pincus)
Date: Tue, 7 Feb 2012 15:04:32 -0500
Subject: FreeImage binaries
In-Reply-To: <CABDkGQnKsz=yV1G2owDf5P29GiTF_veMA-ZL3HS+wX_mEXFvpg@mail.gmail.com>
References: <F61A02CB-649C-41C0-893A-8C30055A2B2B@yale.edu> <CABDkGQkJwb6fbH6n-yrmZp-7fwWmqt_0MwzpB_C9B2NR1y708w@mail.gmail.com> <CC370626-3242-4133-B367-9D8BA5D011D4@yale.edu> <CABDkGQnKsz=yV1G2owDf5P29GiTF_veMA-ZL3HS+wX_mEXFvpg@mail.gmail.com>
Message-ID: <9E376917-3E60-42B9-8379-9F10920CD088@yale.edu>

On Feb 7, 2012, at 2:56 PM, St?fan van der Walt wrote:

> On Tue, Feb 7, 2012 at 11:38 AM, Zachary Pincus <zachary.pincus at yale.edu> wrote:
>> That's a decent idea -- and that way, we could only fetch the appropriate binary for each bdist, instead of shipping all of them.
>> 
>> Any way to make the install command do this as well, for those who install from source?
>> 
>> In either case, though, I'm a bit out of my element in the distutils hackery to make this sort of thing happen...
> 
> As a start, how about just getting a Python script going for doing the
> fetching + moving?  Once that is done, I think it won't be too hard to
> get distutils to play along.  At worst, we can tell all Windows/Mac
> users to do
> 
> from skimage import install_libs
> install_libs()
> 
> after installation.

OK, as soon as github is back working I'll make a repo to hold the binaries. Can anyone (Christoph?) send me a win64 FreeImage DLL that I can include?

Zach



From zachary.pincus at yale.edu  Tue Feb  7 15:13:05 2012
From: zachary.pincus at yale.edu (Zachary Pincus)
Date: Tue, 7 Feb 2012 15:13:05 -0500
Subject: FreeImage binaries
In-Reply-To: <9E376917-3E60-42B9-8379-9F10920CD088@yale.edu>
References: <F61A02CB-649C-41C0-893A-8C30055A2B2B@yale.edu> <CABDkGQkJwb6fbH6n-yrmZp-7fwWmqt_0MwzpB_C9B2NR1y708w@mail.gmail.com> <CC370626-3242-4133-B367-9D8BA5D011D4@yale.edu> <CABDkGQnKsz=yV1G2owDf5P29GiTF_veMA-ZL3HS+wX_mEXFvpg@mail.gmail.com> <9E376917-3E60-42B9-8379-9F10920CD088@yale.edu>
Message-ID: <1F493141-EFAF-42D3-B709-7F7AC101F76F@yale.edu>

>> As a start, how about just getting a Python script going for doing the
>> fetching + moving?  Once that is done, I think it won't be too hard to
>> get distutils to play along.  At worst, we can tell all Windows/Mac
>> users to do
>> 
>> from skimage import install_libs
>> install_libs()
>> 
>> after installation.
> 
> OK, as soon as github is back working I'll make a repo to hold the binaries. Can anyone (Christoph?) send me a win64 FreeImage DLL that I can include?
> 

Also, is anyone a license-maven? Is this sort of thing (distributing binaries, then downloading and run-time loading them in a BSD-licensced project) OK under the GPL (v2) or the FreeImage license? 
http://freeimage.sourceforge.net/license.html





From stefan at sun.ac.za  Tue Feb  7 18:59:32 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 7 Feb 2012 15:59:32 -0800
Subject: FreeImage binaries
In-Reply-To: <679C3617-3B15-427A-81F5-8F0473048F0A@yale.edu>
References: <F61A02CB-649C-41C0-893A-8C30055A2B2B@yale.edu>
 <CABDkGQkJwb6fbH6n-yrmZp-7fwWmqt_0MwzpB_C9B2NR1y708w@mail.gmail.com>
 <CC370626-3242-4133-B367-9D8BA5D011D4@yale.edu> <CABDkGQnKsz=yV1G2owDf5P29GiTF_veMA-ZL3HS+wX_mEXFvpg@mail.gmail.com>
 <9E376917-3E60-42B9-8379-9F10920CD088@yale.edu> <1F493141-EFAF-42D3-B709-7F7AC101F76F@yale.edu>
 <CABDkGQn9SaZ22gv=Z-GR2nSsTPCzMCKhp2ri31CZ+yDbADC18Q@mail.gmail.com>
 <9A2AC320-EC62-49F9-946A-CF4AEB9620EF@yale.edu> <CABDkGQ=CiicQnw27zbTkYJahZu8RyB8JDvS5gib0AhY7RvTa8Q@mail.gmail.com>
 <DF0F7EA0-27F5-454D-BF73-721756AE0E56@yale.edu> <CABDkGQmytMDBiFYZUzA+rfB6QmeOYVgEeE7cCEZO_xvpX+MFmg@mail.gmail.com>
 <9169C243-2769-4DA6-99F6-43070D7F7663@yale.edu> <679C3617-3B15-427A-81F5-8F0473048F0A@yale.edu>
Message-ID: <CABDkGQnPfiCO1s5e3Pwivw-=x4HwErx+QuooDF-mw0LFuWesoQ@mail.gmail.com>

On Tue, Feb 7, 2012 at 3:10 PM, Zachary Pincus <zachary.pincus at yale.edu> wrote:
> FreeImage library downloading from github, alpha version:
> https://github.com/zachrahan/scikits-image/blob/freeimage-install-libs/skimage/io/_plugins/freeimage_install.py
>
> No idea how best to bake this in to bdist or install distutils commands.

That'll do the trick!  Then we just need to do a check for whether the
file has already been downloaded, and to timeout after a while.  Then
we can include it safely in the setup.py command.

Thanks, Zach!
St?fan


From zachary.pincus at yale.edu  Tue Feb  7 16:18:59 2012
From: zachary.pincus at yale.edu (Zachary Pincus)
Date: Tue, 7 Feb 2012 16:18:59 -0500
Subject: FreeImage binaries
In-Reply-To: <CABDkGQn9SaZ22gv=Z-GR2nSsTPCzMCKhp2ri31CZ+yDbADC18Q@mail.gmail.com>
References: <F61A02CB-649C-41C0-893A-8C30055A2B2B@yale.edu> <CABDkGQkJwb6fbH6n-yrmZp-7fwWmqt_0MwzpB_C9B2NR1y708w@mail.gmail.com> <CC370626-3242-4133-B367-9D8BA5D011D4@yale.edu> <CABDkGQnKsz=yV1G2owDf5P29GiTF_veMA-ZL3HS+wX_mEXFvpg@mail.gmail.com> <9E376917-3E60-42B9-8379-9F10920CD088@yale.edu> <1F493141-EFAF-42D3-B709-7F7AC101F76F@yale.edu> <CABDkGQn9SaZ22gv=Z-GR2nSsTPCzMCKhp2ri31CZ+yDbADC18Q@mail.gmail.com>
Message-ID: <9A2AC320-EC62-49F9-946A-CF4AEB9620EF@yale.edu>

> On Tue, Feb 7, 2012 at 12:13 PM, Zachary Pincus <zachary.pincus at yale.edu> wrote:
>> Also, is anyone a license-maven? Is this sort of thing (distributing binaries, then downloading and run-time loading them in a BSD-licensced project) OK under the GPL (v2) or the FreeImage license?
>> http://freeimage.sourceforge.net/license.html
> 
> Meh, licensing :)
> 
> My take (and these issues are tricky, so IANAL and all that):
> 
> The combined work (skimage + freeimage) must be distributed under the
> terms of the GPL.  Our license (the Modified BSD) is more permissive
> than the GPL, so the GPL simply imposes some additional restrictions.
> 
> As far as I understand, you are within your rights to distribute
> patches to GPL code under any license you wish (which is, in a tenuous
> sense, what we're doing).
> 
> When we distribute skimage + the freeimage plugin (but no freeimage
> binary), our distribution is only governed by the permissive BSD.
> E.g., a company may use our code with the Matlotlib backend, mix it in
> with their own (proprietary) code, and not have to worry about
> anything.  If we write the "install_libs" command, we may want to
> clearly state what the implications are.
> 
> Also, an interesting perspective on incorporating BSD code into GPL projects:
> 
> http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html

Yeah, I think we'd be on thin ice for GPL -- at a minimum we'd need to have a copy of the FreeImage sources available somewhere, just to distribute the binaries. Then the "install_libs()" thing seems very close to cheating the spirit if not the practice of the license. (LGPL would be a different matter.)

So I read further about the FreeImage license and it looks sufficiently permissive for this case. I *think* we just need to make sure to also copy over the FreeImage license file and a relevant readme when we cause the binaries to be downloaded. But another opinion might be useful, if you want to look at that license:
https://github.com/zachrahan/freeimage-sharedlib/blob/master/license-fi.txt

And as you can see, I've put up the binaries I have so far here:
https://github.com/zachrahan/freeimage-sharedlib

I still need a win64 DLL. And I also have no idea what the story is with linux shared libs -- is it easy to distribute such for a given architecture, or do these get so fragmented that it makes more sense to just have the user make their package manager install FreeImage?

Zach





From zachary.pincus at yale.edu  Tue Feb  7 16:41:00 2012
From: zachary.pincus at yale.edu (Zachary Pincus)
Date: Tue, 7 Feb 2012 16:41:00 -0500
Subject: FreeImage binaries
In-Reply-To: <CABDkGQ=CiicQnw27zbTkYJahZu8RyB8JDvS5gib0AhY7RvTa8Q@mail.gmail.com>
References: <F61A02CB-649C-41C0-893A-8C30055A2B2B@yale.edu> <CABDkGQkJwb6fbH6n-yrmZp-7fwWmqt_0MwzpB_C9B2NR1y708w@mail.gmail.com> <CC370626-3242-4133-B367-9D8BA5D011D4@yale.edu> <CABDkGQnKsz=yV1G2owDf5P29GiTF_veMA-ZL3HS+wX_mEXFvpg@mail.gmail.com> <9E376917-3E60-42B9-8379-9F10920CD088@yale.edu> <1F493141-EFAF-42D3-B709-7F7AC101F76F@yale.edu> <CABDkGQn9SaZ22gv=Z-GR2nSsTPCzMCKhp2ri31CZ+yDbADC18Q@mail.gmail.com> <9A2AC320-EC62-49F9-946A-CF4AEB9620EF@yale.edu> <CABDkGQ=CiicQnw27zbTkYJahZu8RyB8JDvS5gib0AhY7RvTa8Q@mail.gmail.com>
Message-ID: <DF0F7EA0-27F5-454D-BF73-721756AE0E56@yale.edu>

> Thanks.  I think under Linux we're OK.  We just need to modify the
> plugin to at least pick up on the default naming conventions (Debian,
> e.g., names it libfreeimage.so.3, which we don't find).


Thanks! If anyone can give me any guidance on the matter of locating libraries on different linux flavors, I'd be grateful. I'm unfortunately basically linux-ignorant.

Zach


From zachary.pincus at yale.edu  Tue Feb  7 17:10:23 2012
From: zachary.pincus at yale.edu (Zachary Pincus)
Date: Tue, 7 Feb 2012 17:10:23 -0500
Subject: FreeImage binaries
In-Reply-To: <CABDkGQmytMDBiFYZUzA+rfB6QmeOYVgEeE7cCEZO_xvpX+MFmg@mail.gmail.com>
References: <F61A02CB-649C-41C0-893A-8C30055A2B2B@yale.edu> <CABDkGQkJwb6fbH6n-yrmZp-7fwWmqt_0MwzpB_C9B2NR1y708w@mail.gmail.com> <CC370626-3242-4133-B367-9D8BA5D011D4@yale.edu> <CABDkGQnKsz=yV1G2owDf5P29GiTF_veMA-ZL3HS+wX_mEXFvpg@mail.gmail.com> <9E376917-3E60-42B9-8379-9F10920CD088@yale.edu> <1F493141-EFAF-42D3-B709-7F7AC101F76F@yale.edu> <CABDkGQn9SaZ22gv=Z-GR2nSsTPCzMCKhp2ri31CZ+yDbADC18Q@mail.gmail.com> <9A2AC320-EC62-49F9-946A-CF4AEB9620EF@yale.edu> <CABDkGQ=CiicQnw27zbTkYJahZu8RyB8JDvS5gib0AhY7RvTa8Q@mail.gmail.com> <DF0F7EA0-27F5-454D-BF73-721756AE0E56@yale.edu> <CABDkGQmytMDBiFYZUzA+rfB6QmeOYVgEeE7cCEZO_xvpX+MFmg@mail.gmail.com>
Message-ID: <9169C243-2769-4DA6-99F6-43070D7F7663@yale.edu>

>> Thanks! If anyone can give me any guidance on the matter of locating libraries on different linux flavors, I'd be grateful. I'm unfortunately basically linux-ignorant.
> 
> I think if we look for liblibrary.so.majorversion as well as
> liblibrary.so in the standard locations (/lib, /usr/lib,
> /usr/local/lib, /opt/lib) we should be ok.

New idea -- it may be better to just try to load anything that starts with "FreeImage" or "libfreeimage" (non case-sensitive). This because I notice that the default OS X makefile produces "libfreeimage.3.15.1.dylib"...

This way the code will just try to load any matching file it finds, and if the loader complains then it'll move on to the next.

Zach


From zachary.pincus at yale.edu  Tue Feb  7 18:10:06 2012
From: zachary.pincus at yale.edu (Zachary Pincus)
Date: Tue, 7 Feb 2012 18:10:06 -0500
Subject: FreeImage binaries
In-Reply-To: <9169C243-2769-4DA6-99F6-43070D7F7663@yale.edu>
References: <F61A02CB-649C-41C0-893A-8C30055A2B2B@yale.edu> <CABDkGQkJwb6fbH6n-yrmZp-7fwWmqt_0MwzpB_C9B2NR1y708w@mail.gmail.com> <CC370626-3242-4133-B367-9D8BA5D011D4@yale.edu> <CABDkGQnKsz=yV1G2owDf5P29GiTF_veMA-ZL3HS+wX_mEXFvpg@mail.gmail.com> <9E376917-3E60-42B9-8379-9F10920CD088@yale.edu> <1F493141-EFAF-42D3-B709-7F7AC101F76F@yale.edu> <CABDkGQn9SaZ22gv=Z-GR2nSsTPCzMCKhp2ri31CZ+yDbADC18Q@mail.gmail.com> <9A2AC320-EC62-49F9-946A-CF4AEB9620EF@yale.edu> <CABDkGQ=CiicQnw27zbTkYJahZu8RyB8JDvS5gib0AhY7RvTa8Q@mail.gmail.com> <DF0F7EA0-27F5-454D-BF73-721756AE0E56@yale.edu> <CABDkGQmytMDBiFYZUzA+rfB6QmeOYVgEeE7cCEZO_xvpX+MFmg@mail.gmail.com> <9169C243-2769-4DA6-99F6-43070D7F7663@yale.edu>
Message-ID: <679C3617-3B15-427A-81F5-8F0473048F0A@yale.edu>

FreeImage library downloading from github, alpha version:
https://github.com/zachrahan/scikits-image/blob/freeimage-install-libs/skimage/io/_plugins/freeimage_install.py

No idea how best to bake this in to bdist or install distutils commands.

Zach


From zachary.pincus at yale.edu  Tue Feb  7 18:11:55 2012
From: zachary.pincus at yale.edu (Zachary Pincus)
Date: Tue, 7 Feb 2012 18:11:55 -0500
Subject: FreeImage binaries
In-Reply-To: <9169C243-2769-4DA6-99F6-43070D7F7663@yale.edu>
References: <F61A02CB-649C-41C0-893A-8C30055A2B2B@yale.edu> <CABDkGQkJwb6fbH6n-yrmZp-7fwWmqt_0MwzpB_C9B2NR1y708w@mail.gmail.com> <CC370626-3242-4133-B367-9D8BA5D011D4@yale.edu> <CABDkGQnKsz=yV1G2owDf5P29GiTF_veMA-ZL3HS+wX_mEXFvpg@mail.gmail.com> <9E376917-3E60-42B9-8379-9F10920CD088@yale.edu> <1F493141-EFAF-42D3-B709-7F7AC101F76F@yale.edu> <CABDkGQn9SaZ22gv=Z-GR2nSsTPCzMCKhp2ri31CZ+yDbADC18Q@mail.gmail.com> <9A2AC320-EC62-49F9-946A-CF4AEB9620EF@yale.edu> <CABDkGQ=CiicQnw27zbTkYJahZu8RyB8JDvS5gib0AhY7RvTa8Q@mail.gmail.com> <DF0F7EA0-27F5-454D-BF73-721756AE0E56@yale.edu> <CABDkGQmytMDBiFYZUzA+rfB6QmeOYVgEeE7cCEZO_xvpX+MFmg@mail.gmail.com> <9169C243-2769-4DA6-99F6-43070D7F7663@yale.edu>
Message-ID: <E0CBA287-923B-45D5-BA80-3E98E6430FC3@yale.edu>

> New idea -- it may be better to just try to load anything that starts with "FreeImage" or "libfreeimage" (non case-sensitive). This because I notice that the default OS X makefile produces "libfreeimage.3.15.1.dylib"...
> 
> This way the code will just try to load any matching file it finds, and if the loader complains then it'll move on to the next.

https://github.com/zachrahan/scikits-image/commit/77d2ae88b5519c3b521241ad5d081d86066bc034

This seems slightly more likely to work in more situations. I still need to test it rather more carefully though. But comments as to the general idea would be welcome.

Zach


From tsyu80 at gmail.com  Tue Feb  7 21:30:52 2012
From: tsyu80 at gmail.com (Tony Yu)
Date: Tue, 7 Feb 2012 21:30:52 -0500
Subject: skimage module not found by iPython's completion?
In-Reply-To: <CAEym_HoLmRxopWYbEgug7F-_w7ytsX4GVYZ34gD7RTm4MqNTVQ@mail.gmail.com>
References: <d128f1ad-f97b-4a79-873b-af8e74fe34dc@w19g2000vbe.googlegroups.com>
	<CAEym_HqcWArjPQcyK2d4BBVv6srwOSYN81zH4pViheMd4aVzDQ@mail.gmail.com>
	<CABDkGQnZXD26iWOV4FSWQEPNsjkrE8_de8XfnugKQrkCEwRFyg@mail.gmail.com>
	<CAEym_HoLmRxopWYbEgug7F-_w7ytsX4GVYZ34gD7RTm4MqNTVQ@mail.gmail.com>
Message-ID: <CAEym_HrKdzN1=dRvfjZ0=ZEv-+J_E_Su7SrB7SQ4sRJ=wDR6BQ@mail.gmail.com>

On Mon, Feb 6, 2012 at 3:45 PM, Tony Yu <tsyu80 at gmail.com> wrote:

>
>
> 2012/2/6 St?fan van der Walt <stefan at sun.ac.za>
>
>> On Mon, Feb 6, 2012 at 11:12 AM, Tony Yu <tsyu80 at gmail.com> wrote:
>> > As for the second issue: We don't automatically import any subpackages
>> > (other than `util`). This was a design decision since automatic imports
>> of
>> > all subpackages would increase load times (there may be other reasons
>> too).
>> > On the other hand, if you just want to see which submodules are
>> available
>> > for import, you can write `import skimage.<tab>` (note the dot before
>> <tab>)
>> > or `from skimage import<tab>` in ipython.
>>
>> Besides, Tony is busy updating all the module level docstrings, so
>> that "skimage?" should soon deliver useful results :)
>>
>> Cheers
>> St?fan
>>
>
> Wait a minute... Let me quote what I wrote in the original email: "One
> thing I'd like to see is a package docstring listing all subpackages..."
>
> Note: I didn't say that I would implement it ;)
>
> -Tony
>

OK, maybe I'll do the main package docstring :) (PR
#127<https://github.com/scikits-image/scikits-image/pull/127>
)

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

From tsyu80 at gmail.com  Tue Feb  7 21:55:41 2012
From: tsyu80 at gmail.com (Tony Yu)
Date: Tue, 7 Feb 2012 21:55:41 -0500
Subject: Documentation sprint over the weekend
In-Reply-To: <CABDkGQnTaNJD3cEngoG38e8k4oP9i0GcGc0dL2pyUoxQTyRLbA@mail.gmail.com>
References: <CABDkGQ=8xdHN-3Y7WmJuGKCjLwnQdubHmi1Wd-E29R60jPqkjA@mail.gmail.com>
	<CAEym_HpyBn+9JbabmBA+eycsVVg51xKeNNqV=7h8_-5_P7QQFA@mail.gmail.com>
	<CABDkGQkdaaX6WSdfJ+68wTb__RO8wFiPaZ0BJYPKnRtQTS1DTg@mail.gmail.com>
	<20120204122839.GA31382@phare.normalesup.org>
	<CAEym_Hp-Qke-Ko8iUbo7Qy7cSg_GL2B-h7nTjPcPtejJvn=eBg@mail.gmail.com>
	<d87a9c23-3798-428b-84c4-e47d97eb13a1@g27g2000yqa.googlegroups.com>
	<CABDkGQnTaNJD3cEngoG38e8k4oP9i0GcGc0dL2pyUoxQTyRLbA@mail.gmail.com>
Message-ID: <CAEym_Hqr1Q3L9pbgXsvwNVH__MySetHdDtuoYx=VVKLjE3GR7A@mail.gmail.com>

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

> On Mon, Feb 6, 2012 at 3:28 AM, Michael Aye <kmichael.aye at gmail.com>
> wrote:
> > I think it would be helpful, if the gallery would mention from which
> > version on a feature/method is available. Currently, for example, it
> > seems not clear from the website that exposure and harris are only
> > available from github only, or did I miss something?
>
> Thanks, Michael, that's a good point.  Tony's suggestions sound like
> the way to go; in the mean time, here's a PR to add the version number
> to each example:
>
> https://github.com/scikits-image/scikits-image/pull/124
>
> St?fan
>

I just added the side bar in PR
128<https://github.com/scikits-image/scikits-image/pull/128>
.
-Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120207/97be68d2/attachment.html>

From stefan at sun.ac.za  Wed Feb  8 04:25:57 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 8 Feb 2012 01:25:57 -0800
Subject: skimage module not found by iPython's completion?
In-Reply-To: <CAEym_HrKdzN1=dRvfjZ0=ZEv-+J_E_Su7SrB7SQ4sRJ=wDR6BQ@mail.gmail.com>
References: <d128f1ad-f97b-4a79-873b-af8e74fe34dc@w19g2000vbe.googlegroups.com>
 <CAEym_HqcWArjPQcyK2d4BBVv6srwOSYN81zH4pViheMd4aVzDQ@mail.gmail.com>
 <CABDkGQnZXD26iWOV4FSWQEPNsjkrE8_de8XfnugKQrkCEwRFyg@mail.gmail.com>
 <CAEym_HoLmRxopWYbEgug7F-_w7ytsX4GVYZ34gD7RTm4MqNTVQ@mail.gmail.com> <CAEym_HrKdzN1=dRvfjZ0=ZEv-+J_E_Su7SrB7SQ4sRJ=wDR6BQ@mail.gmail.com>
Message-ID: <CABDkGQ=biDQijk6X++SkKiTijyM0hXA61EzAyrfw9OC2PbYrjA@mail.gmail.com>

On Tue, Feb 7, 2012 at 6:30 PM, Tony Yu <tsyu80 at gmail.com> wrote:
> OK, maybe I'll do the main package docstring :) (PR #127)

:)  Thanks, Tony.  I made a few small tweaks and merged--please have a
look and see if you're happy.

Cheers
St?fan


From kmichael.aye at gmail.com  Wed Feb  8 04:52:35 2012
From: kmichael.aye at gmail.com (Michael Aye)
Date: Wed, 8 Feb 2012 01:52:35 -0800 (PST)
Subject: random walker segmentation / blob detection
In-Reply-To: <CABDkGQnLd+sibOQt6JGkL=vWQ++ymXUyX+BaF5q_+w=zhgRj4A@mail.gmail.com>
References: <27207519.2086.1328618871447.JavaMail.geo-discussion-forums@yqcz12>
 <CABDkGQnLd+sibOQt6JGkL=vWQ++ymXUyX+BaF5q_+w=zhgRj4A@mail.gmail.com>
Message-ID: <26400884.2838.1328694755524.JavaMail.geo-discussion-forums@vbtr6>

Hi St?fan,

thanks for playing with it, looks good.
Do you have any comment on the question I had with the random_walker 
concerning the marker thresholds?

Best regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120208/a20c183f/attachment.html>

From stefan at sun.ac.za  Wed Feb  8 05:00:39 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 8 Feb 2012 02:00:39 -0800
Subject: Documentation sprint over the weekend
In-Reply-To: <CAEym_Hqr1Q3L9pbgXsvwNVH__MySetHdDtuoYx=VVKLjE3GR7A@mail.gmail.com>
References: <CABDkGQ=8xdHN-3Y7WmJuGKCjLwnQdubHmi1Wd-E29R60jPqkjA@mail.gmail.com>
 <CAEym_HpyBn+9JbabmBA+eycsVVg51xKeNNqV=7h8_-5_P7QQFA@mail.gmail.com>
 <CABDkGQkdaaX6WSdfJ+68wTb__RO8wFiPaZ0BJYPKnRtQTS1DTg@mail.gmail.com>
 <20120204122839.GA31382@phare.normalesup.org> <CAEym_Hp-Qke-Ko8iUbo7Qy7cSg_GL2B-h7nTjPcPtejJvn=eBg@mail.gmail.com>
 <d87a9c23-3798-428b-84c4-e47d97eb13a1@g27g2000yqa.googlegroups.com>
 <CABDkGQnTaNJD3cEngoG38e8k4oP9i0GcGc0dL2pyUoxQTyRLbA@mail.gmail.com> <CAEym_Hqr1Q3L9pbgXsvwNVH__MySetHdDtuoYx=VVKLjE3GR7A@mail.gmail.com>
Message-ID: <CABDkGQmtvEPPWkQW2YwuF8yY-JkDMyV5iJ_0Q1tdTdGjo3CkJg@mail.gmail.com>

On Tue, Feb 7, 2012 at 6:55 PM, Tony Yu <tsyu80 at gmail.com> wrote:
>
> I just added the side bar in PR 128.

Nice!

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


From stefan at sun.ac.za  Wed Feb  8 05:23:46 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 8 Feb 2012 02:23:46 -0800
Subject: random walker segmentation / blob detection
In-Reply-To: <26400884.2838.1328694755524.JavaMail.geo-discussion-forums@vbtr6>
References: <27207519.2086.1328618871447.JavaMail.geo-discussion-forums@yqcz12>
 <CABDkGQnLd+sibOQt6JGkL=vWQ++ymXUyX+BaF5q_+w=zhgRj4A@mail.gmail.com> <26400884.2838.1328694755524.JavaMail.geo-discussion-forums@vbtr6>
Message-ID: <CABDkGQmOihqufQZ0C_5x688uqZFsxasj6ga8aSOqAGQgTQ6yzw@mail.gmail.com>

On Wed, Feb 8, 2012 at 1:52 AM, Michael Aye <kmichael.aye at gmail.com> wrote:
> Do you have any comment on the question I had with the random_walker
> concerning the marker thresholds?

I think we should ping Emmanuelle on that one; she wrote the code, and
is intimately familiar with the segmentation algorithms in skimage.

Regards
St?fan


From tsyu80 at gmail.com  Wed Feb  8 10:10:22 2012
From: tsyu80 at gmail.com (Tony Yu)
Date: Wed, 8 Feb 2012 10:10:22 -0500
Subject: skimage module not found by iPython's completion?
In-Reply-To: <CABDkGQ=biDQijk6X++SkKiTijyM0hXA61EzAyrfw9OC2PbYrjA@mail.gmail.com>
References: <d128f1ad-f97b-4a79-873b-af8e74fe34dc@w19g2000vbe.googlegroups.com>
	<CAEym_HqcWArjPQcyK2d4BBVv6srwOSYN81zH4pViheMd4aVzDQ@mail.gmail.com>
	<CABDkGQnZXD26iWOV4FSWQEPNsjkrE8_de8XfnugKQrkCEwRFyg@mail.gmail.com>
	<CAEym_HoLmRxopWYbEgug7F-_w7ytsX4GVYZ34gD7RTm4MqNTVQ@mail.gmail.com>
	<CAEym_HrKdzN1=dRvfjZ0=ZEv-+J_E_Su7SrB7SQ4sRJ=wDR6BQ@mail.gmail.com>
	<CABDkGQ=biDQijk6X++SkKiTijyM0hXA61EzAyrfw9OC2PbYrjA@mail.gmail.com>
Message-ID: <CAEym_Hoj0kvinttwADt35_TA+Ao7H8hpZ+szmu7noHwUcDWHZA@mail.gmail.com>

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

> On Tue, Feb 7, 2012 at 6:30 PM, Tony Yu <tsyu80 at gmail.com> wrote:
> > OK, maybe I'll do the main package docstring :) (PR #127)
>
> :)  Thanks, Tony.  I made a few small tweaks and merged--please have a
> look and see if you're happy.
>
> Cheers
> St?fan
>

Looks good to me.

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

From stefan at sun.ac.za  Wed Feb  8 16:09:21 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 8 Feb 2012 13:09:21 -0800
Subject: Documentation sprint over the weekend
In-Reply-To: <CABL7CQh52Q2YYAkfV1q-ms7=+pfxCYbp8ZQxPg_-caoHT-cm4Q@mail.gmail.com>
References: <CABDkGQ=8xdHN-3Y7WmJuGKCjLwnQdubHmi1Wd-E29R60jPqkjA@mail.gmail.com>
 <CAEym_HpyBn+9JbabmBA+eycsVVg51xKeNNqV=7h8_-5_P7QQFA@mail.gmail.com>
 <CABDkGQkdaaX6WSdfJ+68wTb__RO8wFiPaZ0BJYPKnRtQTS1DTg@mail.gmail.com>
 <20120204122839.GA31382@phare.normalesup.org> <CAEym_Hp-Qke-Ko8iUbo7Qy7cSg_GL2B-h7nTjPcPtejJvn=eBg@mail.gmail.com>
 <d87a9c23-3798-428b-84c4-e47d97eb13a1@g27g2000yqa.googlegroups.com>
 <CABDkGQnTaNJD3cEngoG38e8k4oP9i0GcGc0dL2pyUoxQTyRLbA@mail.gmail.com>
 <CAEym_Hqr1Q3L9pbgXsvwNVH__MySetHdDtuoYx=VVKLjE3GR7A@mail.gmail.com>
 <CABDkGQmtvEPPWkQW2YwuF8yY-JkDMyV5iJ_0Q1tdTdGjo3CkJg@mail.gmail.com>
 <CABL7CQjXE0s0DV-q4R21sgqyM4OK3hhrfTq7u9Jugo-bMtS5Pw@mail.gmail.com>
 <CAEym_Ho2O_5dMrO+SgdKg=mb8mY1JM13PQ-wcc-if_QHSiTwag@mail.gmail.com> <CABL7CQh52Q2YYAkfV1q-ms7=+pfxCYbp8ZQxPg_-caoHT-cm4Q@mail.gmail.com>
Message-ID: <CABDkGQkqdQBM984wGDivAp0DADLAYyhfZ3GTj-qjkMS6VDy-MA@mail.gmail.com>

On Wed, Feb 8, 2012 at 12:12 PM, Ralf Gommers
<ralf.gommers at googlemail.com> wrote:
> On http://scikits-image.org/docs/dev/ it points to
> http://scikits-image.org/docs/dev/.
> On http://scikits-image.org/ it points to http://scikits-image.org/.
> On http://scikits-image.org/docs/ it points to
> http://scikits-image.org/docs/.
> On http://scikits-image.org/docs/0.3/ it points to
> http://scikits-image.org/docs/0.3/.

I rebuilt the docs.  The logo now links to the webpage, and there is
an additional navigation item in the sidebar to take you to the
documentation root.

Regards
St?fan


From emmanuelle.gouillart at nsup.org  Wed Feb  8 07:58:35 2012
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Wed, 8 Feb 2012 13:58:35 +0100
Subject: random walker segmentation / blob detection
In-Reply-To: <26400884.2838.1328694755524.JavaMail.geo-discussion-forums@vbtr6>
References: <27207519.2086.1328618871447.JavaMail.geo-discussion-forums@yqcz12>
 <CABDkGQnLd+sibOQt6JGkL=vWQ++ymXUyX+BaF5q_+w=zhgRj4A@mail.gmail.com>
 <26400884.2838.1328694755524.JavaMail.geo-discussion-forums@vbtr6>
Message-ID: <20120208125835.GB4628@phare.normalesup.org>

Hi Michael,

sorry for not being very reactive! For the random walker algorithm,
markers basically have to be pixels 

On Wed, Feb 08, 2012 at 01:52:35AM -0800, Michael Aye wrote:
>    Hi St??????fan,
>    thanks for playing with it, looks good.
>    Do you have any comment on the question I had with the random_walker
>    concerning the marker thresholds?
>    Best regards,
>    Michael


From emmanuelle.gouillart at nsup.org  Wed Feb  8 07:59:22 2012
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Wed, 8 Feb 2012 13:59:22 +0100
Subject: random walker segmentation / blob detection
In-Reply-To: <20120208125835.GB4628@phare.normalesup.org>
References: <27207519.2086.1328618871447.JavaMail.geo-discussion-forums@yqcz12>
 <CABDkGQnLd+sibOQt6JGkL=vWQ++ymXUyX+BaF5q_+w=zhgRj4A@mail.gmail.com>
 <26400884.2838.1328694755524.JavaMail.geo-discussion-forums@vbtr6>
 <20120208125835.GB4628@phare.normalesup.org>
Message-ID: <20120208125922.GC4628@phare.normalesup.org>

Sorry for the unfinished mail, I'm working on it and will send a more
complete answer in a few minutes!

On Wed, Feb 08, 2012 at 01:58:35PM +0100, Emmanuelle Gouillart wrote:
> Hi Michael,

> sorry for not being very reactive! For the random walker algorithm,
> markers basically have to be pixels 

> On Wed, Feb 08, 2012 at 01:52:35AM -0800, Michael Aye wrote:
> >    Hi St??????fan,
> >    thanks for playing with it, looks good.
> >    Do you have any comment on the question I had with the random_walker
> >    concerning the marker thresholds?
> >    Best regards,
> >    Michael


From emmanuelle.gouillart at nsup.org  Wed Feb  8 08:46:53 2012
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Wed, 8 Feb 2012 14:46:53 +0100
Subject: random walker segmentation / blob detection
In-Reply-To: <26400884.2838.1328694755524.JavaMail.geo-discussion-forums@vbtr6>
References: <27207519.2086.1328618871447.JavaMail.geo-discussion-forums@yqcz12>
 <CABDkGQnLd+sibOQt6JGkL=vWQ++ymXUyX+BaF5q_+w=zhgRj4A@mail.gmail.com>
 <26400884.2838.1328694755524.JavaMail.geo-discussion-forums@vbtr6>
Message-ID: <20120208134653.GD4628@phare.normalesup.org>

Hi Michael,                                                                     
                                                                                
sorry for not being very reactive! For the random walker algorithm,
markers basically have to be pixels for which you are sure that they
belong to one phase (say, the phase blobs or the phase "normal
ground"). Most of the time markers are determined from the histogram
(e.g., taking the 10% darker and lighter pixels), but other features than
gray values can be use to determine whether you can label your markers or
not (such as local variance, Haralick features -- this is in fact a
classification task).

Of course, this implies that you know the number of phases beforehand,
that is, if you know that you have blobs, then you can start thinking of
determining markers and using the random walker. But this won't tell you
whether you have blobs or not.

For your blobs image, when I plot the histogram I can see that it is
bimodal, with two peaks. The first peak corresponds mostly to the blobs
pixels, while the second one corresponds to the normal ground. What I
would do would be to detect a local minimum of the histogram (or another
fancier classification technique -- I tried Gaussian mixture models from
scikit-learn but the peaks are definitely not Gaussian so it didn't work
at all). Then you can take a threshold value that correspond to say 80%
of pixels that have a value smaller than the local minimum (using
scipy.stats.scoreatpecentile). And do the same for the other peak. This
insures that you have only a small number of unlabeled pixels having grey
values around the local minimum, and the random walker should do well in
this case (at least, it does on this image, as I checked!). Another rule of
thumb with the random walker is that markers should be distributed in
space as homogeneously as possible (I guess I should add that in the
docstring!).

What I also found with your image was that I had to change the beta
parameter of the random walker so that it works on this image, because
you have a lot of texture, therefore diffusion is very difficult and you
can end up with an ill-conditioned system if beta is too large. beta=10
was working fine for me. This texture is also the reason why I had to
take a large fraction of the two peaks as markers (80%, as I suggested
above) to get a good result, since diffusion is too difficult when there
are not enough markers.   

Of course, all this doesn't tell you whether you have blobs at all or
not, and this is -- as I understand it -- one of the primary information
that you want to obtain. When you have only one small blob it is unlikely
that the histogram has two peaks and you won't be able to use the above
method. Are your images always taken with the same exposure settings?
What I mean is, can you know in advance what are the grey values of the
blob?

What I understand from your two images is that you know that there are
blobs not only from the grey values but also because these regions have a
certain size and have less texture (a smaller local variance) than
elsewhere, so you might want to incorporate this criteria as well in
the choice of markers. If you can have hard thresholds for these criteria
(that are the same for all images), then it is much easier, but if you
can't, it's really a question of determining whether you have one or two
clusters in your features space (features being grey values, local
variance etc.) and I don't know a proper method to do that.

You may want to ask this last question on the scikit-learn mailing-list as
well, because it is really a classification problem.

Hope this helps a little, and thanks for the interesting usecase! Keep us
informed about your progress.

Cheers,
Emmanuelle

On Wed, Feb 08, 2012 at 01:52:35AM -0800, Michael Aye wrote:
>    Hi St??????fan,
>    thanks for playing with it, looks good.
>    Do you have any comment on the question I had with the random_walker
>    concerning the marker thresholds?
>    Best regards,
>    Michael


From tsyu80 at gmail.com  Wed Feb  8 14:47:16 2012
From: tsyu80 at gmail.com (Tony Yu)
Date: Wed, 8 Feb 2012 14:47:16 -0500
Subject: Documentation sprint over the weekend
In-Reply-To: <CABL7CQjXE0s0DV-q4R21sgqyM4OK3hhrfTq7u9Jugo-bMtS5Pw@mail.gmail.com>
References: <CABDkGQ=8xdHN-3Y7WmJuGKCjLwnQdubHmi1Wd-E29R60jPqkjA@mail.gmail.com>
	<CAEym_HpyBn+9JbabmBA+eycsVVg51xKeNNqV=7h8_-5_P7QQFA@mail.gmail.com>
	<CABDkGQkdaaX6WSdfJ+68wTb__RO8wFiPaZ0BJYPKnRtQTS1DTg@mail.gmail.com>
	<20120204122839.GA31382@phare.normalesup.org>
	<CAEym_Hp-Qke-Ko8iUbo7Qy7cSg_GL2B-h7nTjPcPtejJvn=eBg@mail.gmail.com>
	<d87a9c23-3798-428b-84c4-e47d97eb13a1@g27g2000yqa.googlegroups.com>
	<CABDkGQnTaNJD3cEngoG38e8k4oP9i0GcGc0dL2pyUoxQTyRLbA@mail.gmail.com>
	<CAEym_Hqr1Q3L9pbgXsvwNVH__MySetHdDtuoYx=VVKLjE3GR7A@mail.gmail.com>
	<CABDkGQmtvEPPWkQW2YwuF8yY-JkDMyV5iJ_0Q1tdTdGjo3CkJg@mail.gmail.com>
	<CABL7CQjXE0s0DV-q4R21sgqyM4OK3hhrfTq7u9Jugo-bMtS5Pw@mail.gmail.com>
Message-ID: <CAEym_Ho2O_5dMrO+SgdKg=mb8mY1JM13PQ-wcc-if_QHSiTwag@mail.gmail.com>

On Wed, Feb 8, 2012 at 2:27 PM, Ralf Gommers <ralf.gommers at googlemail.com>wrote:

>
>
> 2012/2/8 St?fan van der Walt <stefan at sun.ac.za>
>
>> On Tue, Feb 7, 2012 at 6:55 PM, Tony Yu <tsyu80 at gmail.com> wrote:
>> >
>> > I just added the side bar in PR 128.
>>
>> Nice!
>>
>> http://scikits-image.org/docs/dev/
>>
>
> Looks great. I just noticed that the logo on that page (and other pages)
> always links to the currently open page, instead of always to
> http://scikits-image.org. Is that intended?
>
> Ralf
>
>
For me, the logo links to the index page of the docs. Is this what you
meant by "currently open page" or is it actually behaving differently?

I guess it is more common---design-wise---for the logo to link to the home
page, but I think going to the main page of the docs is a more common
operation (for me, at least). This is also what the numpy documentation
does. BUT, the numpy docs also has a link history at the very top, which
you can follow to get back to scipy.org. Maybe we should add a homepage
link in the sidebar?

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

From zachary.pincus at yale.edu  Wed Feb  8 15:42:10 2012
From: zachary.pincus at yale.edu (Zachary Pincus)
Date: Wed, 8 Feb 2012 15:42:10 -0500
Subject: FreeImage binaries
In-Reply-To: <CABDkGQnPfiCO1s5e3Pwivw-=x4HwErx+QuooDF-mw0LFuWesoQ@mail.gmail.com>
References: <F61A02CB-649C-41C0-893A-8C30055A2B2B@yale.edu> <CABDkGQkJwb6fbH6n-yrmZp-7fwWmqt_0MwzpB_C9B2NR1y708w@mail.gmail.com> <CC370626-3242-4133-B367-9D8BA5D011D4@yale.edu> <CABDkGQnKsz=yV1G2owDf5P29GiTF_veMA-ZL3HS+wX_mEXFvpg@mail.gmail.com> <9E376917-3E60-42B9-8379-9F10920CD088@yale.edu> <1F493141-EFAF-42D3-B709-7F7AC101F76F@yale.edu> <CABDkGQn9SaZ22gv=Z-GR2nSsTPCzMCKhp2ri31CZ+yDbADC18Q@mail.gmail.com> <9A2AC320-EC62-49F9-946A-CF4AEB9620EF@yale.edu> <CABDkGQ=CiicQnw27zbTkYJahZu8RyB8JDvS5gib0AhY7RvTa8Q@mail.gmail.com> <DF0F7EA0-27F5-454D-BF73-721756AE0E56@yale.edu> <CABDkGQmytMDBiFYZUzA+rfB6QmeOYVgEeE7cCEZO_xvpX+MFmg@mail.gmail.com> <9169C243-2769-4DA6-99F6-43070D7F7663@yale.edu> <679C3617-3B15-427A-81F5-8F0473048F0A@yale.edu> <CABDkGQnPfiCO1s5e3Pwivw-=x4HwErx+QuooDF-mw0LFuWesoQ@mail.gmail.com>
Message-ID: <83014E90-1CBF-441E-916F-23D08DACAF90@yale.edu>

> On Tue, Feb 7, 2012 at 3:10 PM, Zachary Pincus <zachary.pincus at yale.edu> wrote:
>> FreeImage library downloading from github, alpha version:
>> https://github.com/zachrahan/scikits-image/blob/freeimage-install-libs/skimage/io/_plugins/freeimage_install.py
>> 
>> No idea how best to bake this in to bdist or install distutils commands.
> 
> That'll do the trick!  Then we just need to do a check for whether the
> file has already been downloaded, and to timeout after a while.  Then
> we can include it safely in the setup.py command.

OK, timeouts and checks added to the above. It's not an optional flag whether to raise an error if no file for the host platform is found... I thought that might be useful? Anyway, now to figure out how to add it to setup.py install and setup.py bdist -- any ideas?

Zach 


From ralf.gommers at googlemail.com  Wed Feb  8 14:27:57 2012
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Wed, 8 Feb 2012 20:27:57 +0100
Subject: Documentation sprint over the weekend
In-Reply-To: <CABDkGQmtvEPPWkQW2YwuF8yY-JkDMyV5iJ_0Q1tdTdGjo3CkJg@mail.gmail.com>
References: <CABDkGQ=8xdHN-3Y7WmJuGKCjLwnQdubHmi1Wd-E29R60jPqkjA@mail.gmail.com>
	<CAEym_HpyBn+9JbabmBA+eycsVVg51xKeNNqV=7h8_-5_P7QQFA@mail.gmail.com>
	<CABDkGQkdaaX6WSdfJ+68wTb__RO8wFiPaZ0BJYPKnRtQTS1DTg@mail.gmail.com>
	<20120204122839.GA31382@phare.normalesup.org>
	<CAEym_Hp-Qke-Ko8iUbo7Qy7cSg_GL2B-h7nTjPcPtejJvn=eBg@mail.gmail.com>
	<d87a9c23-3798-428b-84c4-e47d97eb13a1@g27g2000yqa.googlegroups.com>
	<CABDkGQnTaNJD3cEngoG38e8k4oP9i0GcGc0dL2pyUoxQTyRLbA@mail.gmail.com>
	<CAEym_Hqr1Q3L9pbgXsvwNVH__MySetHdDtuoYx=VVKLjE3GR7A@mail.gmail.com>
	<CABDkGQmtvEPPWkQW2YwuF8yY-JkDMyV5iJ_0Q1tdTdGjo3CkJg@mail.gmail.com>
Message-ID: <CABL7CQjXE0s0DV-q4R21sgqyM4OK3hhrfTq7u9Jugo-bMtS5Pw@mail.gmail.com>

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

> On Tue, Feb 7, 2012 at 6:55 PM, Tony Yu <tsyu80 at gmail.com> wrote:
> >
> > I just added the side bar in PR 128.
>
> Nice!
>
> http://scikits-image.org/docs/dev/
>

Looks great. I just noticed that the logo on that page (and other pages)
always links to the currently open page, instead of always to
http://scikits-image.org. Is that intended?

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

From ralf.gommers at googlemail.com  Wed Feb  8 15:12:52 2012
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Wed, 8 Feb 2012 21:12:52 +0100
Subject: Documentation sprint over the weekend
In-Reply-To: <CAEym_Ho2O_5dMrO+SgdKg=mb8mY1JM13PQ-wcc-if_QHSiTwag@mail.gmail.com>
References: <CABDkGQ=8xdHN-3Y7WmJuGKCjLwnQdubHmi1Wd-E29R60jPqkjA@mail.gmail.com>
	<CAEym_HpyBn+9JbabmBA+eycsVVg51xKeNNqV=7h8_-5_P7QQFA@mail.gmail.com>
	<CABDkGQkdaaX6WSdfJ+68wTb__RO8wFiPaZ0BJYPKnRtQTS1DTg@mail.gmail.com>
	<20120204122839.GA31382@phare.normalesup.org>
	<CAEym_Hp-Qke-Ko8iUbo7Qy7cSg_GL2B-h7nTjPcPtejJvn=eBg@mail.gmail.com>
	<d87a9c23-3798-428b-84c4-e47d97eb13a1@g27g2000yqa.googlegroups.com>
	<CABDkGQnTaNJD3cEngoG38e8k4oP9i0GcGc0dL2pyUoxQTyRLbA@mail.gmail.com>
	<CAEym_Hqr1Q3L9pbgXsvwNVH__MySetHdDtuoYx=VVKLjE3GR7A@mail.gmail.com>
	<CABDkGQmtvEPPWkQW2YwuF8yY-JkDMyV5iJ_0Q1tdTdGjo3CkJg@mail.gmail.com>
	<CABL7CQjXE0s0DV-q4R21sgqyM4OK3hhrfTq7u9Jugo-bMtS5Pw@mail.gmail.com>
	<CAEym_Ho2O_5dMrO+SgdKg=mb8mY1JM13PQ-wcc-if_QHSiTwag@mail.gmail.com>
Message-ID: <CABL7CQh52Q2YYAkfV1q-ms7=+pfxCYbp8ZQxPg_-caoHT-cm4Q@mail.gmail.com>

On Wed, Feb 8, 2012 at 8:47 PM, Tony Yu <tsyu80 at gmail.com> wrote:

>
>
> On Wed, Feb 8, 2012 at 2:27 PM, Ralf Gommers <ralf.gommers at googlemail.com>wrote:
>
>>
>>
>> 2012/2/8 St?fan van der Walt <stefan at sun.ac.za>
>>
>>> On Tue, Feb 7, 2012 at 6:55 PM, Tony Yu <tsyu80 at gmail.com> wrote:
>>> >
>>> > I just added the side bar in PR 128.
>>>
>>> Nice!
>>>
>>> http://scikits-image.org/docs/dev/
>>>
>>
>> Looks great. I just noticed that the logo on that page (and other pages)
>> always links to the currently open page, instead of always to
>> http://scikits-image.org. Is that intended?
>>
>> Ralf
>>
>>
> For me, the logo links to the index page of the docs. Is this what you
> meant by "currently open page" or is it actually behaving differently?
>

On http://scikits-image.org/docs/dev/ it points to
http://scikits-image.org/docs/dev/.
On http://scikits-image.org/ it points to http://scikits-image.org/.
On http://scikits-image.org/docs/ it points to
http://scikits-image.org/docs/.
On http://scikits-image.org/docs/0.3/ it points to
http://scikits-image.org/docs/0.3/.

This is unusual, and because there are no links to go higher up the tree
(say from docs/0.3/ to docs/, or from docs/ to the homepage) it makes the
site hard to navigate.

>
> I guess it is more common---design-wise---for the logo to link to the home
> page, but I think going to the main page of the docs is a more common
> operation (for me, at least). This is also what the numpy documentation
> does. BUT, the numpy docs also has a link history at the very top, which
> you can follow to get back to scipy.org. Maybe we should add a homepage
> link in the sidebar?
>

That would be useful.

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

From bricklemacho at gmail.com  Thu Feb  9 01:37:26 2012
From: bricklemacho at gmail.com (bricklemacho)
Date: Wed, 8 Feb 2012 22:37:26 -0800 (PST)
Subject: Understanding HoG output
Message-ID: <a9ae03e4-f629-48f0-905e-8e623ffae190@qt7g2000pbc.googlegroups.com>

Hi, new to group, new to image processing starting to explore HoG.
Looking for a python implementation and discovered
skimage.feature.hog().

My plan to run skimage.features.hog over some positive/negative images
and use this to train a svm classifier from scikits-learn.   I am
trying to understand the output hog before I proceed further.    When
I run skimag.feature.hog() it over a region of interest  it appears to
returns an array.  How do I interpret this array?  Is there a way to
reshape the array to see what it was like before it was flattened or
that doesn't make any sense?  Can I plot the descriptor returned in
any meaningful way?

Also when I choose to visualise the HoG often where I expected to see
vertical line dominate, say on the edge of builds, the line drawn
often appears to be more dominant at the 45 deg.  Is this expected as
the line drawn is really just the sum of all surrounding orientations
for the "cell"?

Thanks in advance,

Michael.
--


From tsyu80 at gmail.com  Wed Feb  8 22:56:47 2012
From: tsyu80 at gmail.com (Tony Yu)
Date: Wed, 8 Feb 2012 22:56:47 -0500
Subject: Documentation sprint over the weekend
In-Reply-To: <CABDkGQkqdQBM984wGDivAp0DADLAYyhfZ3GTj-qjkMS6VDy-MA@mail.gmail.com>
References: <CABDkGQ=8xdHN-3Y7WmJuGKCjLwnQdubHmi1Wd-E29R60jPqkjA@mail.gmail.com>
	<CAEym_HpyBn+9JbabmBA+eycsVVg51xKeNNqV=7h8_-5_P7QQFA@mail.gmail.com>
	<CABDkGQkdaaX6WSdfJ+68wTb__RO8wFiPaZ0BJYPKnRtQTS1DTg@mail.gmail.com>
	<20120204122839.GA31382@phare.normalesup.org>
	<CAEym_Hp-Qke-Ko8iUbo7Qy7cSg_GL2B-h7nTjPcPtejJvn=eBg@mail.gmail.com>
	<d87a9c23-3798-428b-84c4-e47d97eb13a1@g27g2000yqa.googlegroups.com>
	<CABDkGQnTaNJD3cEngoG38e8k4oP9i0GcGc0dL2pyUoxQTyRLbA@mail.gmail.com>
	<CAEym_Hqr1Q3L9pbgXsvwNVH__MySetHdDtuoYx=VVKLjE3GR7A@mail.gmail.com>
	<CABDkGQmtvEPPWkQW2YwuF8yY-JkDMyV5iJ_0Q1tdTdGjo3CkJg@mail.gmail.com>
	<CABL7CQjXE0s0DV-q4R21sgqyM4OK3hhrfTq7u9Jugo-bMtS5Pw@mail.gmail.com>
	<CAEym_Ho2O_5dMrO+SgdKg=mb8mY1JM13PQ-wcc-if_QHSiTwag@mail.gmail.com>
	<CABL7CQh52Q2YYAkfV1q-ms7=+pfxCYbp8ZQxPg_-caoHT-cm4Q@mail.gmail.com>
	<CABDkGQkqdQBM984wGDivAp0DADLAYyhfZ3GTj-qjkMS6VDy-MA@mail.gmail.com>
Message-ID: <CAEym_HoSMJRCsWQ8x+sGKJFGWjAMzYks46FD=Jm-QYfxS86iQQ@mail.gmail.com>

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

> On Wed, Feb 8, 2012 at 12:12 PM, Ralf Gommers
> <ralf.gommers at googlemail.com> wrote:
> > On http://scikits-image.org/docs/dev/ it points to
> > http://scikits-image.org/docs/dev/.
> > On http://scikits-image.org/ it points to http://scikits-image.org/.
> > On http://scikits-image.org/docs/ it points to
> > http://scikits-image.org/docs/.
> > On http://scikits-image.org/docs/0.3/ it points to
> > http://scikits-image.org/docs/0.3/.
>
> I rebuilt the docs.  The logo now links to the webpage, and there is
> an additional navigation item in the sidebar to take you to the
> documentation root.
>
> Regards
> St?fan
>

Nice! Not only did you add the navigation link, but the sidebar looks much
cleaner now, also.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120208/01b813c0/attachment.html>

From kmichael.aye at gmail.com  Thu Feb  9 05:44:09 2012
From: kmichael.aye at gmail.com (Michael Aye)
Date: Thu, 9 Feb 2012 02:44:09 -0800 (PST)
Subject: random walker segmentation / blob detection
In-Reply-To: <CAHGWWxFKunAkJUVkrokxipqczSN5Sbg8LhDRoenRFHpQP55S5g@mail.gmail.com>
References: <27207519.2086.1328618871447.JavaMail.geo-discussion-forums@yqcz12>
 <CABDkGQnLd+sibOQt6JGkL=vWQ++ymXUyX+BaF5q_+w=zhgRj4A@mail.gmail.com>
 <26400884.2838.1328694755524.JavaMail.geo-discussion-forums@vbtr6> <20120208134653.GD4628@phare.normalesup.org>
 <CAHGWWxFKunAkJUVkrokxipqczSN5Sbg8LhDRoenRFHpQP55S5g@mail.gmail.com>
Message-ID: <11829122.221.1328784249183.JavaMail.geo-discussion-forums@vbev17>

Hi Thouis,

ilastik does not seem to have a programmatic interface, is that right?
I can't do it via GUI's, my end goal is to find features programmatically 
in possibly thousands of images...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120209/93beb500/attachment.html>

From kmichael.aye at gmail.com  Thu Feb  9 09:07:19 2012
From: kmichael.aye at gmail.com (Michael Aye)
Date: Thu, 9 Feb 2012 06:07:19 -0800 (PST)
Subject: image conversions
Message-ID: <28713919.277.1328796439191.JavaMail.geo-discussion-forums@vbeu3>

I am working through the docs of skimage and tried out the image 
conversions.
The docs say that these functions *properly rescale* the values, but I'm 
not sure what is meant with *properly? *
*IF *rescaling is meant to exploit the defined range between 0 and 1 for 
floats, that does not seem to happen:

In [13]: data=np.uint(data)

In [14]: data.max()
Out[14]: 27

In [15]: data.min()
Out[15]: 17

In [16]: fimg = skimage.img_as
skimage.img_as_float  skimage.img_as_int    skimage.img_as_ubyte 
 skimage.img_as_uint

In [16]: fimg = skimage.img_as_float(data)

In [17]: fimg.max()
Out[17]: 6.2864273801181529e-09

In [18]: fimg.min()
Out[18]: 3.9581209430373555e-09

In [19]: imshow(fimg)
Out[19]: <matplotlib.image.AxesImage at 0xe38b1f0>

In [20]: data.dtype
Out[20]: dtype('uint32')


Or do I misunderstand something?

Best regards,
Michael
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120209/d8dd736a/attachment.html>

From kmichael.aye at gmail.com  Thu Feb  9 09:20:29 2012
From: kmichael.aye at gmail.com (Michael Aye)
Date: Thu, 9 Feb 2012 06:20:29 -0800 (PST)
Subject: image conversions
In-Reply-To: <28713919.277.1328796439191.JavaMail.geo-discussion-forums@vbeu3>
References: <28713919.277.1328796439191.JavaMail.geo-discussion-forums@vbeu3>
Message-ID: <29519118.381.1328797229306.JavaMail.geo-discussion-forums@vbtx11>

I think I understand now. Because the uint32 range was only used up to 
value of 27, the float value became so small, right?:

In [23]: 27.0/(2**32)
Out[23]: 6.28642737865448e-09


Ok, good that we talked about it... ;) (and sorry for the noise..) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120209/742c7db4/attachment.html>

From ralf.gommers at googlemail.com  Thu Feb  9 01:25:30 2012
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Thu, 9 Feb 2012 07:25:30 +0100
Subject: Documentation sprint over the weekend
In-Reply-To: <CAEym_HoSMJRCsWQ8x+sGKJFGWjAMzYks46FD=Jm-QYfxS86iQQ@mail.gmail.com>
References: <CABDkGQ=8xdHN-3Y7WmJuGKCjLwnQdubHmi1Wd-E29R60jPqkjA@mail.gmail.com>
	<CAEym_HpyBn+9JbabmBA+eycsVVg51xKeNNqV=7h8_-5_P7QQFA@mail.gmail.com>
	<CABDkGQkdaaX6WSdfJ+68wTb__RO8wFiPaZ0BJYPKnRtQTS1DTg@mail.gmail.com>
	<20120204122839.GA31382@phare.normalesup.org>
	<CAEym_Hp-Qke-Ko8iUbo7Qy7cSg_GL2B-h7nTjPcPtejJvn=eBg@mail.gmail.com>
	<d87a9c23-3798-428b-84c4-e47d97eb13a1@g27g2000yqa.googlegroups.com>
	<CABDkGQnTaNJD3cEngoG38e8k4oP9i0GcGc0dL2pyUoxQTyRLbA@mail.gmail.com>
	<CAEym_Hqr1Q3L9pbgXsvwNVH__MySetHdDtuoYx=VVKLjE3GR7A@mail.gmail.com>
	<CABDkGQmtvEPPWkQW2YwuF8yY-JkDMyV5iJ_0Q1tdTdGjo3CkJg@mail.gmail.com>
	<CABL7CQjXE0s0DV-q4R21sgqyM4OK3hhrfTq7u9Jugo-bMtS5Pw@mail.gmail.com>
	<CAEym_Ho2O_5dMrO+SgdKg=mb8mY1JM13PQ-wcc-if_QHSiTwag@mail.gmail.com>
	<CABL7CQh52Q2YYAkfV1q-ms7=+pfxCYbp8ZQxPg_-caoHT-cm4Q@mail.gmail.com>
	<CABDkGQkqdQBM984wGDivAp0DADLAYyhfZ3GTj-qjkMS6VDy-MA@mail.gmail.com>
	<CAEym_HoSMJRCsWQ8x+sGKJFGWjAMzYks46FD=Jm-QYfxS86iQQ@mail.gmail.com>
Message-ID: <CABL7CQg8ZM6ctr=QtfDnfSvvfJSAF-KotAsroJyQPAm-MWoO4g@mail.gmail.com>

On Thu, Feb 9, 2012 at 4:56 AM, Tony Yu <tsyu80 at gmail.com> wrote:

>
>
> 2012/2/8 St?fan van der Walt <stefan at sun.ac.za>
>
>> On Wed, Feb 8, 2012 at 12:12 PM, Ralf Gommers
>> <ralf.gommers at googlemail.com> wrote:
>> > On http://scikits-image.org/docs/dev/ it points to
>> > http://scikits-image.org/docs/dev/.
>> > On http://scikits-image.org/ it points to http://scikits-image.org/.
>> > On http://scikits-image.org/docs/ it points to
>> > http://scikits-image.org/docs/.
>> > On http://scikits-image.org/docs/0.3/ it points to
>> > http://scikits-image.org/docs/0.3/.
>>
>> I rebuilt the docs.  The logo now links to the webpage, and there is
>> an additional navigation item in the sidebar to take you to the
>> documentation root.
>>
>> Regards
>> St?fan
>>
>
> Nice! Not only did you add the navigation link, but the sidebar looks much
> cleaner now, also.
>
> Indeed, looks great.

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

From kmichael.aye at gmail.com  Thu Feb  9 12:06:34 2012
From: kmichael.aye at gmail.com (Michael Aye)
Date: Thu, 9 Feb 2012 09:06:34 -0800 (PST)
Subject: random walker segmentation / blob detection
In-Reply-To: <20120208134653.GD4628@phare.normalesup.org>
References: <27207519.2086.1328618871447.JavaMail.geo-discussion-forums@yqcz12>
 <CABDkGQnLd+sibOQt6JGkL=vWQ++ymXUyX+BaF5q_+w=zhgRj4A@mail.gmail.com>
 <26400884.2838.1328694755524.JavaMail.geo-discussion-forums@vbtr6>
 <20120208134653.GD4628@phare.normalesup.org>
Message-ID: <18847975.422.1328807194237.JavaMail.geo-discussion-forums@vbjk3>

Hi Emmanuelle,

thanks for chiming in!

On Wednesday, February 8, 2012 2:46:53 PM UTC+1, Emmanuelle Gouillart wrote:
>
> Hi Michael,                                                               
>       
>                                                                           
>       
> sorry for not being very reactive! For the random walker algorithm,
> markers basically have to be pixels for which you are sure that they
> belong to one phase (say, the phase blobs or the phase "normal
> ground"). Most of the time markers are determined from the histogram
> (e.g., taking the 10% darker and lighter pixels), but other features than
> gray values can be use to determine whether you can label your markers or
> not (such as local variance, Haralick features -- this is in fact a
> classification task).
>
> What does 'this' refer to? Using Haralick features, or my general problem?
 

> Of course, this implies that you know the number of phases beforehand,
> that is, if you know that you have blobs, then you can start thinking of
> determining markers and using the random walker. But this won't tell you
> whether you have blobs or not.
>
Yes, and that is one of my problems. I have more difficulties in NOT 
finding blobs in data that does not have them, than identifying blobs in 
images when they are there (false positives I need to suppress somehow).
 

> For your blobs image, when I plot the histogram I can see that it is
> bimodal, with two peaks. 
>
I played a lot with the bimodal thresholding idea, but unfortunately I have 
also a lot of not-bimodal data, when the signal-to-noise ratio is very weak.
   

> Of course, all this doesn't tell you whether you have blobs at all or
> not, and this is -- as I understand it -- one of the primary information
> that you want to obtain. 
>
When you have only one small blob it is unlikely
> that the histogram has two peaks and you won't be able to use the above
> method. Are your images always taken with the same exposure settings?
> What I mean is, can you know in advance what are the grey values of the
> blob?
>
> No, not at all unfortunately. My data consists of time series under 
varying lighting conditions due to the different incidence angles of the 
sun. Therefore the SNR also changes.
 

> What I understand from your two images is that you know that there are
> blobs not only from the grey values but also because these regions have a
> certain size and have less texture (a smaller local variance) than
> elsewhere, so you might want to incorporate this criteria as well in
> the choice of markers. 
>
Unfortunately I don't know the size. These blobs can be big or small. The 
only thing I could fix size-wise is, that I don't want to count blobs that 
are the same size as the background-noise dips. But I would not know how to 
'measure' that.

 

> If you can have hard thresholds for these criteria
> (that are the same for all images), then it is much easier, but if you
> can't, it's really a question of determining whether you have one or two
> clusters in your features space (features being grey values, local
> variance etc.) and I don't know a proper method to do that.
>
> Can k-means clustering maybe indicate to me how well a clustering worked, 
something like a score? I basically have 3 phases in the images: dark 
blobs, grayish background, and bright ice patches. Maybe clustering could 
indicate by scores if a 2 or 3 phase clustering represents the image better?
 

> You may want to ask this last question on the scikit-learn mailing-list as
> well, because it is really a classification problem.
>
> Will do, thanks!

Michael

 

> Hope this helps a little, and thanks for the interesting usecase! Keep us
> informed about your progress.
>
> Cheers,
> Emmanuelle
>
> On Wed, Feb 08, 2012 at 01:52:35AM -0800, Michael Aye wrote:
> >    Hi St???fan,
> >    thanks for playing with it, looks good.
> >    Do you have any comment on the question I had with the random_walker
> >    concerning the marker thresholds?
> >    Best regards,
> >    Michael
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120209/c97167c9/attachment.html>

From thouis.jones at curie.fr  Thu Feb  9 03:26:51 2012
From: thouis.jones at curie.fr (Thouis Jones)
Date: Thu, 9 Feb 2012 09:26:51 +0100
Subject: random walker segmentation / blob detection
In-Reply-To: <20120208134653.GD4628@phare.normalesup.org>
References: <27207519.2086.1328618871447.JavaMail.geo-discussion-forums@yqcz12>
 <CABDkGQnLd+sibOQt6JGkL=vWQ++ymXUyX+BaF5q_+w=zhgRj4A@mail.gmail.com>
 <26400884.2838.1328694755524.JavaMail.geo-discussion-forums@vbtr6> <20120208134653.GD4628@phare.normalesup.org>
Message-ID: <CAHGWWxFKunAkJUVkrokxipqczSN5Sbg8LhDRoenRFHpQP55S5g@mail.gmail.com>

On Wed, Feb 8, 2012 at 14:46, Emmanuelle Gouillart
<emmanuelle.gouillart at nsup.org> wrote:
> You may want to ask this last question on the scikit-learn mailing-list as
> well, because it is really a classification problem.

Or take a look at ilastik (ilastik.org).  We've been using this in a
lot of cases with biological images and are pretty happy with it.  (I
assume there are other tools like this, but ilastik is the one I know
offhand).

Thouis Jones


From tsyu80 at gmail.com  Thu Feb  9 09:47:54 2012
From: tsyu80 at gmail.com (Tony Yu)
Date: Thu, 9 Feb 2012 09:47:54 -0500
Subject: image conversions
In-Reply-To: <29519118.381.1328797229306.JavaMail.geo-discussion-forums@vbtx11>
References: <28713919.277.1328796439191.JavaMail.geo-discussion-forums@vbeu3>
	<29519118.381.1328797229306.JavaMail.geo-discussion-forums@vbtx11>
Message-ID: <CAEym_Hq9K+mnA6u_E6PvCCM61r_Rt_3Y=e_HfaVbjmDBWUUOpQ@mail.gmail.com>

On Thu, Feb 9, 2012 at 9:20 AM, Michael Aye <kmichael.aye at gmail.com> wrote:

> I think I understand now. Because the uint32 range was only used up to
> value of 27, the float value became so small, right?:
>
> In [23]: 27.0/(2**32)
> Out[23]: 6.28642737865448e-09
>
>
> Ok, good that we talked about it... ;) (and sorry for the noise..)
>

Glad you figured it out on your own, but that's actually a good point: we
don't have uint32 ranges listed in the docs.

Based on your recent emails, I think you may be a good resource. Please
continue to point out any spots in the code or the docs where things aren't
clear. It's easy for us to overlook the unintuitive parts of the package
after using it for awhile.

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

From luis at luispedro.org  Thu Feb  9 13:33:43 2012
From: luis at luispedro.org (Luis Pedro Coelho)
Date: Thu, 9 Feb 2012 10:33:43 -0800 (PST)
Subject: Fixing image loading in Python: imread
In-Reply-To: <CABDkGQkNWvEP9AwXxMfp0PzsOFsG8MjggRX74-HKCxF-JE-n+g@mail.gmail.com>
References: <4357987.if5pQMgS3P@rabbit>
 <CABDkGQkNWvEP9AwXxMfp0PzsOFsG8MjggRX74-HKCxF-JE-n+g@mail.gmail.com>
Message-ID: <11854282.550.1328812423756.JavaMail.geo-discussion-forums@vbbfs26>

 I had a look at matplotlib. It is very similar to what I did (I mean, it's 
just a call to libpng, there is just a few variations on the same theme), 
but not as flexible as they are not using anything but libpng.

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

From stefan at sun.ac.za  Thu Feb  9 13:54:13 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 9 Feb 2012 10:54:13 -0800
Subject: image conversions
In-Reply-To: <29519118.381.1328797229306.JavaMail.geo-discussion-forums@vbtx11>
References: <28713919.277.1328796439191.JavaMail.geo-discussion-forums@vbeu3>
	<29519118.381.1328797229306.JavaMail.geo-discussion-forums@vbtx11>
Message-ID: <CABDkGQm=8ebsFvKrVG3fdrS5s0GQ55WHmBCvwWHz6hZ=jFtsEA@mail.gmail.com>

On Feb 9, 2012 6:32 AM, "Michael Aye" <kmichael.aye at gmail.com> wrote:
>
> I think I understand now. Because the uint32 range was only used up to
value of 27, the float value became so small, right?:
>
>> In [23]: 27.0/(2**32)
>> Out[23]: 6.28642737865448e-09
>
That's right!

Tony also wrote a function called "rescale_intensity" for modifying the
extents of an image.

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

From thouis.jones at curie.fr  Thu Feb  9 07:06:57 2012
From: thouis.jones at curie.fr (Thouis Jones)
Date: Thu, 9 Feb 2012 13:06:57 +0100
Subject: random walker segmentation / blob detection
In-Reply-To: <11829122.221.1328784249183.JavaMail.geo-discussion-forums@vbev17>
References: <27207519.2086.1328618871447.JavaMail.geo-discussion-forums@yqcz12>
 <CABDkGQnLd+sibOQt6JGkL=vWQ++ymXUyX+BaF5q_+w=zhgRj4A@mail.gmail.com>
 <26400884.2838.1328694755524.JavaMail.geo-discussion-forums@vbtr6>
 <20120208134653.GD4628@phare.normalesup.org> <CAHGWWxFKunAkJUVkrokxipqczSN5Sbg8LhDRoenRFHpQP55S5g@mail.gmail.com>
 <11829122.221.1328784249183.JavaMail.geo-discussion-forums@vbev17>
Message-ID: <CAHGWWxH8B_H6BgjpnFufUnnaPRZHdjDtfe7_5fYjRA7JT43JCg@mail.gmail.com>

On Thu, Feb 9, 2012 at 11:44, Michael Aye <kmichael.aye at gmail.com> wrote:
> ilastik does not seem to have a programmatic interface, is that right?
> I can't do it via GUI's, my end goal is to find features programmatically in
> possibly thousands of images...

It has a scripting interface (command line) for batch processing.  I
have talked to them about adding a client/server mode using zmq, but
it's not yet started.

Ray


From tsyu80 at gmail.com  Fri Feb 10 00:07:44 2012
From: tsyu80 at gmail.com (Tony Yu)
Date: Fri, 10 Feb 2012 00:07:44 -0500
Subject: 0.5 release soon?
Message-ID: <CAEym_HqzDEzDuz3aiVpAs+OGuSoTtiKuYAa_if8Q_FmPiiKY-g@mail.gmail.com>

There has been a surprising amount of new features, fixes, and doc
improvements since 0.4, so I'm wondering if it's time for a new release.
Are there any major todos before that?

* Maybe doc additions if they're close.

* Of the current pull requests, only SSIM and template-matching are close,
but I don't think I'll have much time to sort out the issues with
template-matching for awhile.

* I was really excited about the image stitching example using HoGs,
suggested by Nelle. If it's not close, though, no pressure.

Anything else?

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

From guillaume at mitotic-machine.org  Fri Feb 10 04:55:57 2012
From: guillaume at mitotic-machine.org (Guillaume)
Date: Fri, 10 Feb 2012 01:55:57 -0800 (PST)
Subject: Error when building from git
Message-ID: <e36f20f0-9e2c-445d-8f7c-4ba9fc1fa3ae@t5g2000yqk.googlegroups.com>

Hey list,

First thanks for the great work. I am planning to use skimage for some
fluorescence microscopy analysis.

Today I installed from the git repository and an error occurred when
compiling:

 File "/home/guillaume/Python/lib/scikits-image/skimage/util/
dtype.py", line 20, in <module>
 in <module>
    np.float16, np.float32, np.float64)
AttributeError: 'module' object has no attribute 'float16'

taking out 'float16' in the _supported_types tuple solves the issue
(at least it compiles), but I don't know whether it  could have
consequences later on.

_supported_types = (np.uint8, np.uint16, np.uint32,
                    np.int8, np.int16, np.int32,
                    #np.float16, ### Commented this out...
                    np.float32, np.float64)


I am running Python  2.7.2+ with numpy 1.5.1 (that is what you get
with apt-get install python-numpy)

Thanks...


From stefan at sun.ac.za  Fri Feb 10 05:34:34 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 10 Feb 2012 02:34:34 -0800
Subject: Error when building from git
In-Reply-To: <e36f20f0-9e2c-445d-8f7c-4ba9fc1fa3ae@t5g2000yqk.googlegroups.com>
References: <e36f20f0-9e2c-445d-8f7c-4ba9fc1fa3ae@t5g2000yqk.googlegroups.com>
Message-ID: <CABDkGQkAo91Ve5gc7UA8tezE4jnm0q7eBuUbp9GZABvTt2Y9MQ@mail.gmail.com>

Hi Guillaume

On Fri, Feb 10, 2012 at 1:55 AM, Guillaume
<guillaume at mitotic-machine.org> wrote:
> First thanks for the great work. I am planning to use skimage for some
> fluorescence microscopy analysis.

That's great!  We'd love to see what you do once you've got some
working examples.

> Today I installed from the git repository and an error occurred when
> compiling:
>
> ?File "/home/guillaume/Python/lib/scikits-image/skimage/util/
> dtype.py", line 20, in <module>
> ?in <module>
> ? ?np.float16, np.float32, np.float64)
> AttributeError: 'module' object has no attribute 'float16'

The float16 data-type was introduced in NumPy 1.6, and while we
currently list NumPy 1.4 as a dependency, but we're going to have to
up that to 1.6 (I think some of it is being used in the data type
conversion code now, e.g.).  I hope this isn't too much of an
inconvenience!

Regards
St?fan


From guillaume at mitotic-machine.org  Fri Feb 10 06:01:11 2012
From: guillaume at mitotic-machine.org (Guillaume)
Date: Fri, 10 Feb 2012 03:01:11 -0800 (PST)
Subject: Error when building from git
In-Reply-To: <CABDkGQkAo91Ve5gc7UA8tezE4jnm0q7eBuUbp9GZABvTt2Y9MQ@mail.gmail.com>
References: <e36f20f0-9e2c-445d-8f7c-4ba9fc1fa3ae@t5g2000yqk.googlegroups.com> <CABDkGQkAo91Ve5gc7UA8tezE4jnm0q7eBuUbp9GZABvTt2Y9MQ@mail.gmail.com>
Message-ID: <7812d347-4dfe-45fa-b253-0da6d510d557@w1g2000vbg.googlegroups.com>

Ok thanks,

Also, I just ran into another problem with freeimage...
First, when I first tried to open a file with the freeimage plugin, it
was not found (I assumed it was bundled with skimage).
So I apt-get installed libfreeimage3.
but the error persisted (i.e. RuntimeError: Could not find the plugin
"freeimage" for imread.)

After some investigation, I found that I had to link  /usr/lib/
libfreeimage.so.3 with /usr/lib/libfreeimage.so to pass the plugin
test:

sudo ln -s /usr/lib/libfreeimage.so.3 /usr/lib/libfreeimage.so

Then the test is ok. Maybe there should be some more flexibility in
the search for the shared object, in the  _load_library(libname,
libdir) function? Putting a regexp somewhere?

Bye

Guillaume
On 10 f?v, 11:34, St?fan van der Walt <ste... at sun.ac.za> wrote:
> Hi Guillaume
>
> On Fri, Feb 10, 2012 at 1:55 AM, Guillaume
>
> <guilla... at mitotic-machine.org> wrote:
> > First thanks for the great work. I am planning to use skimage for some
> > fluorescence microscopy analysis.
>
> That's great! ?We'd love to see what you do once you've got some
> working examples.
>
> > Today I installed from the git repository and an error occurred when
> > compiling:
>
> > ?File "/home/guillaume/Python/lib/scikits-image/skimage/util/
> > dtype.py", line 20, in <module>
> > ?in <module>
> > ? ?np.float16, np.float32, np.float64)
> > AttributeError: 'module' object has no attribute 'float16'
>
> The float16 data-type was introduced in NumPy 1.6, and while we
> currently list NumPy 1.4 as a dependency, but we're going to have to
> up that to 1.6 (I think some of it is being used in the data type
> conversion code now, e.g.). ?I hope this isn't too much of an
> inconvenience!
>
> Regards
> St?fan


From stefan at sun.ac.za  Fri Feb 10 06:11:08 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 10 Feb 2012 03:11:08 -0800
Subject: 0.5 release soon?
In-Reply-To: <CAEym_HqzDEzDuz3aiVpAs+OGuSoTtiKuYAa_if8Q_FmPiiKY-g@mail.gmail.com>
References: <CAEym_HqzDEzDuz3aiVpAs+OGuSoTtiKuYAa_if8Q_FmPiiKY-g@mail.gmail.com>
Message-ID: <CABDkGQ=nggoaX8_hQX+WNMkrdu-LNPcuzSeUzgC=kqxWE8+Y6g@mail.gmail.com>

On Thu, Feb 9, 2012 at 9:07 PM, Tony Yu <tsyu80 at gmail.com> wrote:
> There has been a surprising amount of new features, fixes, and doc
> improvements since 0.4, so I'm wondering if it's time for a new release.

You're right, it's about time!

> Are there any major todos before that?

- Finish the Debian packaging.  Really, this is so close, we should just do it:

  1. Edit the skivi.1 man-page template (anyone with Troff skills here?)
  2. Update the copyright file.
  3. Ping Yaroslav to check and upload.

If possible, we should get permission from everyone with per-file
copyright messages and move their names to the CONTRIBUTORS.txt file,
so that we have a single license covering all our code.

> * Maybe doc additions if they're close.

I've got some unpushed user guide changes that I'll be done with soon.

> * Of the current pull requests, only SSIM and template-matching are close,
> but I don't think I'll have much time to sort out the issues with
> template-matching for awhile.

For now, I'm pretty much done with SSIM, so if you think it looks OK
please merge.

> * I was really excited about the image stitching example using HoGs,
> suggested by Nelle. If it's not close, though, no pressure.

Since Nelle's indicated that she's very busy at the moment, we can
push that back to 0.6 (and yes, it would make a great feature!).

The end of February gets crazy for me time-wise, so shall we aim for
the 19th of February?  That gives us two more weekends.

St?fan


From stefan at sun.ac.za  Fri Feb 10 06:35:01 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 10 Feb 2012 03:35:01 -0800
Subject: random walker segmentation / blob detection
In-Reply-To: <CAHGWWxFKunAkJUVkrokxipqczSN5Sbg8LhDRoenRFHpQP55S5g@mail.gmail.com>
References: <27207519.2086.1328618871447.JavaMail.geo-discussion-forums@yqcz12>
 <CABDkGQnLd+sibOQt6JGkL=vWQ++ymXUyX+BaF5q_+w=zhgRj4A@mail.gmail.com>
 <26400884.2838.1328694755524.JavaMail.geo-discussion-forums@vbtr6>
 <20120208134653.GD4628@phare.normalesup.org> <CAHGWWxFKunAkJUVkrokxipqczSN5Sbg8LhDRoenRFHpQP55S5g@mail.gmail.com>
Message-ID: <CABDkGQm80gqp5Y0sj5XZBXYg8A87vyHx2=nSPrrREYp_ZAiRYg@mail.gmail.com>

On Thu, Feb 9, 2012 at 12:26 AM, Thouis Jones <thouis.jones at curie.fr> wrote:
> Or take a look at ilastik (ilastik.org). ?We've been using this in a

What a neat project!  I've added a link to our front page.

St?fan


From stefan at sun.ac.za  Fri Feb 10 06:39:15 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 10 Feb 2012 03:39:15 -0800
Subject: random walker segmentation / blob detection
In-Reply-To: <18847975.422.1328807194237.JavaMail.geo-discussion-forums@vbjk3>
References: <27207519.2086.1328618871447.JavaMail.geo-discussion-forums@yqcz12>
 <CABDkGQnLd+sibOQt6JGkL=vWQ++ymXUyX+BaF5q_+w=zhgRj4A@mail.gmail.com>
 <26400884.2838.1328694755524.JavaMail.geo-discussion-forums@vbtr6>
 <20120208134653.GD4628@phare.normalesup.org> <18847975.422.1328807194237.JavaMail.geo-discussion-forums@vbjk3>
Message-ID: <CABDkGQm1t68ssXkZRVBCM47=zc-hUbyqz_Zzp9Xk-bD8Pf5m2w@mail.gmail.com>

On Thu, Feb 9, 2012 at 9:06 AM, Michael Aye <kmichael.aye at gmail.com> wrote:
> Can k-means clustering maybe indicate to me how well a clustering worked,
> something like a score? I basically have 3 phases in the images: dark blobs,
> grayish background, and bright ice patches. Maybe clustering could indicate
> by scores if a 2 or 3 phase clustering represents the image better?

Here's an implementation of ICM-based clustering:

http://stackoverflow.com/a/9174197/214686

I wonder if we should include this in the scikit--Emmanuelle, do
people actually still use ICM segmentation?

St?fan


From stefan at sun.ac.za  Fri Feb 10 07:26:48 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 10 Feb 2012 04:26:48 -0800
Subject: Error when building from git
In-Reply-To: <7812d347-4dfe-45fa-b253-0da6d510d557@w1g2000vbg.googlegroups.com>
References: <e36f20f0-9e2c-445d-8f7c-4ba9fc1fa3ae@t5g2000yqk.googlegroups.com>
 <CABDkGQkAo91Ve5gc7UA8tezE4jnm0q7eBuUbp9GZABvTt2Y9MQ@mail.gmail.com> <7812d347-4dfe-45fa-b253-0da6d510d557@w1g2000vbg.googlegroups.com>
Message-ID: <CABDkGQkx0HGgYJXo9Vs28b_gUdxPWFNrjDSS0ffvAf5sjSeR6Q@mail.gmail.com>

On Fri, Feb 10, 2012 at 3:01 AM, Guillaume
<guillaume at mitotic-machine.org> wrote:
> Also, I just ran into another problem with freeimage...
[...]
>
> After some investigation, I found that I had to link ?/usr/lib/
> libfreeimage.so.3 with /usr/lib/libfreeimage.so to pass the plugin
> test:

I just discovered this myself earlier this week.  Zachary Pincus has
been working on better library location (on Windows mainly), so we should have
that sorted out soon.  Would you mind creating an issue on GitHub in
the mean time, so that we don't lose track of it?

Thanks!
St?fan


From nelle.varoquaux at gmail.com  Fri Feb 10 02:55:50 2012
From: nelle.varoquaux at gmail.com (Nelle Varoquaux)
Date: Fri, 10 Feb 2012 08:55:50 +0100
Subject: 0.5 release soon?
In-Reply-To: <CAEym_HqzDEzDuz3aiVpAs+OGuSoTtiKuYAa_if8Q_FmPiiKY-g@mail.gmail.com>
References: <CAEym_HqzDEzDuz3aiVpAs+OGuSoTtiKuYAa_if8Q_FmPiiKY-g@mail.gmail.com>
Message-ID: <CAE-UAvQVggs--UaupPao9s-WWpo23kZENvy8JgLNfR9dCJ9avw@mail.gmail.com>

On 10 February 2012 06:07, Tony Yu <tsyu80 at gmail.com> wrote:

> There has been a surprising amount of new features, fixes, and doc
> improvements since 0.4, so I'm wondering if it's time for a new release.
> Are there any major todos before that?
>
> * Maybe doc additions if they're close.
>
> * Of the current pull requests, only SSIM and template-matching are close,
> but I don't think I'll have much time to sort out the issues with
> template-matching for awhile.
>
> * I was really excited about the image stitching example using HoGs,
> suggested by Nelle. If it's not close, though, no pressure.
>

I'm a bit swamped with work right now, so I'll think we'll have to delay
that if you want to do a release before end of February

Cheers,
Nelle


>
> Anything else?
>
> Cheers!
> -Tony
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120210/bd27a3e5/attachment.html>

From zachary.pincus at yale.edu  Fri Feb 10 09:21:21 2012
From: zachary.pincus at yale.edu (Zachary Pincus)
Date: Fri, 10 Feb 2012 09:21:21 -0500
Subject: Error when building from git
In-Reply-To: <CABDkGQkx0HGgYJXo9Vs28b_gUdxPWFNrjDSS0ffvAf5sjSeR6Q@mail.gmail.com>
References: <e36f20f0-9e2c-445d-8f7c-4ba9fc1fa3ae@t5g2000yqk.googlegroups.com> <CABDkGQkAo91Ve5gc7UA8tezE4jnm0q7eBuUbp9GZABvTt2Y9MQ@mail.gmail.com> <7812d347-4dfe-45fa-b253-0da6d510d557@w1g2000vbg.googlegroups.com> <CABDkGQkx0HGgYJXo9Vs28b_gUdxPWFNrjDSS0ffvAf5sjSeR6Q@mail.gmail.com>
Message-ID: <6A03E059-3B64-4614-83D0-B790B1E8650D@yale.edu>

Hi Guillaume,

Sorry for the trouble with the FreeImage loading -- I'm glad you got it straightened out. As St?fan mentioned, we're trying to get this a lot smoother, and it should be soon! Please let me know if you have any other problems with FreeImage.

I should also mention (as you're doing microscopy and may need to get at image metadata from time to time, as I do) that I recently added that capability to the freeimage wrappers. See e.g.: https://github.com/scikits-image/scikits-image/blob/master/skimage/io/_plugins/test_freeimage.py

>> Also, I just ran into another problem with freeimage...
> [...]
>> 
>> After some investigation, I found that I had to link  /usr/lib/
>> libfreeimage.so.3 with /usr/lib/libfreeimage.so to pass the plugin
>> test:
> 
> I just discovered this myself earlier this week.  Zachary Pincus has
> been working on better library location (on Windows mainly), so we should have
> that sorted out soon.  Would you mind creating an issue on GitHub in
> the mean time, so that we don't lose track of it?
> 

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

This should fix the above problem and a host of others. 

A mechanism for auto-downloading a freeimage library on Win/Mac is still in progress... I'm not sure how to best integrate that with the distutils, but here's what I have for a start:
https://github.com/zachrahan/scikits-image/tree/freeimage-install-libs
https://github.com/zachrahan/freeimage-sharedlib

Zach



From tsyu80 at gmail.com  Fri Feb 10 09:58:46 2012
From: tsyu80 at gmail.com (Tony Yu)
Date: Fri, 10 Feb 2012 09:58:46 -0500
Subject: 0.5 release soon?
In-Reply-To: <CABDkGQ=nggoaX8_hQX+WNMkrdu-LNPcuzSeUzgC=kqxWE8+Y6g@mail.gmail.com>
References: <CAEym_HqzDEzDuz3aiVpAs+OGuSoTtiKuYAa_if8Q_FmPiiKY-g@mail.gmail.com>
	<CABDkGQ=nggoaX8_hQX+WNMkrdu-LNPcuzSeUzgC=kqxWE8+Y6g@mail.gmail.com>
Message-ID: <CAEym_HoU-FWvkyyH4CkzwLuhcDL4aoC7ooxRBaVFiMwGjy45og@mail.gmail.com>

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

> On Thu, Feb 9, 2012 at 9:07 PM, Tony Yu <tsyu80 at gmail.com> wrote:
> > There has been a surprising amount of new features, fixes, and doc
> > improvements since 0.4, so I'm wondering if it's time for a new release.
>
> You're right, it's about time!
>
> > Are there any major todos before that?
>
> - Finish the Debian packaging.  Really, this is so close, we should just
> do it:
>
>  1. Edit the skivi.1 man-page template (anyone with Troff skills here?)
>  2. Update the copyright file.
>  3. Ping Yaroslav to check and upload.
>
> If possible, we should get permission from everyone with per-file
> copyright messages and move their names to the CONTRIBUTORS.txt file,
> so that we have a single license covering all our code.
>
> > * Maybe doc additions if they're close.
>
> I've got some unpushed user guide changes that I'll be done with soon.
>
> > * Of the current pull requests, only SSIM and template-matching are
> close,
> > but I don't think I'll have much time to sort out the issues with
> > template-matching for awhile.
>
> For now, I'm pretty much done with SSIM, so if you think it looks OK
> please merge.
>


Actually, I haven't really look over SSIM; I was just basing its readiness
on Nicolas's comments. ;) I'll read through the code this weekend.



>
> > * I was really excited about the image stitching example using HoGs,
> > suggested by Nelle. If it's not close, though, no pressure.
>
> Since Nelle's indicated that she's very busy at the moment, we can
> push that back to 0.6 (and yes, it would make a great feature!).
>
> The end of February gets crazy for me time-wise, so shall we aim for
> the 19th of February?  That gives us two more weekends.
>
> St?fan
>

The 19th sounds like a good target. I guess I forgot about the FreeImage
issues, but it sounds like Zach is working pretty hard to make the build as
care-free as possible.

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

From zachary.pincus at yale.edu  Fri Feb 10 10:46:21 2012
From: zachary.pincus at yale.edu (Zachary Pincus)
Date: Fri, 10 Feb 2012 10:46:21 -0500
Subject: Error when building from git
In-Reply-To: <4F353293.4080808@mitotic-machine.org>
References: <e36f20f0-9e2c-445d-8f7c-4ba9fc1fa3ae@t5g2000yqk.googlegroups.com> <CABDkGQkAo91Ve5gc7UA8tezE4jnm0q7eBuUbp9GZABvTt2Y9MQ@mail.gmail.com> <7812d347-4dfe-45fa-b253-0da6d510d557@w1g2000vbg.googlegroups.com> <CABDkGQkx0HGgYJXo9Vs28b_gUdxPWFNrjDSS0ffvAf5sjSeR6Q@mail.gmail.com> <6A03E059-3B64-4614-83D0-B790B1E8650D@yale.edu> <4F353293.4080808@mitotic-machine.org>
Message-ID: <7CFEF0AD-F1D6-4277-8975-36867D8B8D1C@yale.edu>

> Indeed metadata are important, thanks for pointing this out, I'll have a look at it (though I find metamorph is not so good at recording good metadata).
> 
> By the way, I have both .stk and .tif images, so I use Christoph Gohlke tifffile.py for the .stk files. Is ther any chance this will be integrated to skimage?


Wow! Somehow I was not familiar with Christoph's tifffile.py... that'll be very handy for these cursed LSM files I have laying around. (No help for the ZVIs, but I already have a silly zvi->ome-tiff workflow for them.)

Perhaps Christoph, who frequents this list, can weight in on whether it would be a good idea to wrap this in as a skimage IO plugin, or if it's best as a separate project...

Zach


From cjgohlke at gmail.com  Fri Feb 10 16:20:21 2012
From: cjgohlke at gmail.com (Christoph Gohlke)
Date: Fri, 10 Feb 2012 13:20:21 -0800
Subject: Error when building from git
In-Reply-To: <7CFEF0AD-F1D6-4277-8975-36867D8B8D1C@yale.edu>
References: <e36f20f0-9e2c-445d-8f7c-4ba9fc1fa3ae@t5g2000yqk.googlegroups.com> <CABDkGQkAo91Ve5gc7UA8tezE4jnm0q7eBuUbp9GZABvTt2Y9MQ@mail.gmail.com> <7812d347-4dfe-45fa-b253-0da6d510d557@w1g2000vbg.googlegroups.com> <CABDkGQkx0HGgYJXo9Vs28b_gUdxPWFNrjDSS0ffvAf5sjSeR6Q@mail.gmail.com> <6A03E059-3B64-4614-83D0-B790B1E8650D@yale.edu> <4F353293.4080808@mitotic-machine.org> <7CFEF0AD-F1D6-4277-8975-36867D8B8D1C@yale.edu>
Message-ID: <4F358A15.4080606@gmail.com>

On 2/10/2012 7:46 AM, Zachary Pincus wrote:
>> Indeed metadata are important, thanks for pointing this out, I'll have a look at it (though I find metamorph is not so good at recording good metadata).
>>
>> By the way, I have both .stk and .tif images, so I use Christoph Gohlke tifffile.py for the .stk files. Is ther any chance this will be integrated to skimage?
>
> Wow! Somehow I was not familiar with Christoph's tifffile.py... that'll be very handy for these cursed LSM files I have laying around. (No help for the ZVIs, but I already have a silly zvi->ome-tiff workflow for them.)
>
> Perhaps Christoph, who frequents this list, can weight in on whether it would be a good idea to wrap this in as a skimage IO plugin, or if it's best as a separate project...
>
> Zach

A skimage io plugin for tifffile.py is straightforward (attached). The 
module already implements imread, imsave, and imshow functions. Those 
functions return/save/show n-dimensional numpy arrays (n>=2). I'm not 
sure skimage can handle n>3?

Tifffile.py and tifffile.c are BSD licensed, so it is no problem to 
include them with skimage. I don't think the module itself should be 
maintained or supported as part of skimage.


Regarding those cursed, broken, undocumented or NDAed, microscopy file 
formats:

I'm aware of two other projects that strive to read LSM files: pylibtiff 
<http://code.google.com/p/pylibtiff/> and pylsm 
<http://www.freesbi.ch/pylsm>.

How about a plugin for BioFormats 
<http://loci.wisc.edu/software/bio-formats>, which supports many more 
formats? The Cellprofiler project contains GPLed bindings 
<https://svn.broadinstitute.org/CellProfiler/trunk/CellProfiler/bioformats/>.

Christoph



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: tifffile_plugin.ini
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120210/a7f17f09/attachment.ksh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tifffile_plugin.py
Type: text/x-python
Size: 313 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120210/a7f17f09/attachment.py>

From bdholt1 at gmail.com  Fri Feb 10 08:45:12 2012
From: bdholt1 at gmail.com (Brian Holt)
Date: Fri, 10 Feb 2012 13:45:12 +0000
Subject: Understanding HoG output
In-Reply-To: <a9ae03e4-f629-48f0-905e-8e623ffae190@qt7g2000pbc.googlegroups.com>
References: <a9ae03e4-f629-48f0-905e-8e623ffae190@qt7g2000pbc.googlegroups.com>
Message-ID: <CAFkP-qy-TzHD4RsOM1rZVnpB=Gpj=kzCg+0q0JvxjvHvFhuggg@mail.gmail.com>

Hi Michael,

Hi, new to group, new to image processing starting to explore HoG.
Looking for a python implementation and discovered
skimage.feature.hog().


Glad to hear someone's using HoGs!

My plan to run skimage.features.hog over some positive/negative images
and use this to train a svm classifier from scikits-learn.   I am
trying to understand the output hog before I proceed further.    When
I run skimag.feature.hog() it over a region of interest  it appears to
returns an array.  How do I interpret this array?

My best suggestion would be that you take a look at the comments written in
`hog.py`.  Each part quotes the relevant section from the Dalal Triggs
paper and then under that implements the code required to do the job.
 Others on this list may have different views, but I'd be reluctant to try
to 'interpret' the flattened descriptor.


 Is there a way to reshape the array to see what it was like before it was
flattened or that doesn't make any sense?  Can I plot the descriptor
returned in
any meaningful way?


Yes, you can reshape the array (but that can be a bit tricky), or you could
modify the hog function to return the unraveled descriptor and ravel it
yourself later if you need it.

Also when I choose to visualise the HoG often where I expected to see
vertical line dominate, say on the edge of builds, the line drawn
often appears to be more dominant at the 45 deg.  Is this expected as
the line drawn is really just the sum of all surrounding orientations
for the "cell"?


A line is drawn for each gradient bin with an intensity proportional to the
magnitude of that gradient.  So, the 'star' shape you see for each cell is
just the superimposition of all of these lines. You should expect to see
dominant lines perpendicular to lines in the image (parallel to the
gradient). Also remember that the default is to use 9 bins, so it may be
that the 45degree dominant line you see is the closest approximation to
horizontal.  You can test this out by trying 8 bins instead of 9.

I hope it helps, feel free to ask any more questions.

Regards
Brian

On 9 February 2012 06:37, bricklemacho <bricklemacho at gmail.com> wrote:

>
>
>
>
>
>
> Thanks in advance,
>
> Michael.
> --




-- 
He is no fool who gives what he cannot keep to gain what he cannot lose.
 - Jim Elliot.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120210/eac2c9d5/attachment.html>

From guillaume at mitotic-machine.org  Fri Feb 10 10:06:59 2012
From: guillaume at mitotic-machine.org (Guillaume Gay)
Date: Fri, 10 Feb 2012 16:06:59 +0100
Subject: Error when building from git
In-Reply-To: <6A03E059-3B64-4614-83D0-B790B1E8650D@yale.edu>
References: <e36f20f0-9e2c-445d-8f7c-4ba9fc1fa3ae@t5g2000yqk.googlegroups.com> <CABDkGQkAo91Ve5gc7UA8tezE4jnm0q7eBuUbp9GZABvTt2Y9MQ@mail.gmail.com> <7812d347-4dfe-45fa-b253-0da6d510d557@w1g2000vbg.googlegroups.com> <CABDkGQkx0HGgYJXo9Vs28b_gUdxPWFNrjDSS0ffvAf5sjSeR6Q@mail.gmail.com> <6A03E059-3B64-4614-83D0-B790B1E8650D@yale.edu>
Message-ID: <4F353293.4080808@mitotic-machine.org>

Hi Zachary

Indeed metadata are important, thanks for pointing this out, I'll have a 
look at it (though I find metamorph is not so good at recording good 
metadata).

By the way, I have both .stk and .tif images, so I use Christoph Gohlke 
tifffile.py for the .stk files. Is ther any chance this will be 
integrated to skimage?


Guillaume

Le 10/02/2012 15:21, Zachary Pincus a ?crit :
> Hi Guillaume,
>
> Sorry for the trouble with the FreeImage loading -- I'm glad you got it straightened out. As St?fan mentioned, we're trying to get this a lot smoother, and it should be soon! Please let me know if you have any other problems with FreeImage.
>
> I should also mention (as you're doing microscopy and may need to get at image metadata from time to time, as I do) that I recently added that capability to the freeimage wrappers. See e.g.: https://github.com/scikits-image/scikits-image/blob/master/skimage/io/_plugins/test_freeimage.py
>
>>> Also, I just ran into another problem with freeimage...
>> [...]
>>> After some investigation, I found that I had to link  /usr/lib/
>>> libfreeimage.so.3 with /usr/lib/libfreeimage.so to pass the plugin
>>> test:
>> I just discovered this myself earlier this week.  Zachary Pincus has
>> been working on better library location (on Windows mainly), so we should have
>> that sorted out soon.  Would you mind creating an issue on GitHub in
>> the mean time, so that we don't lose track of it?
>>
> https://github.com/scikits-image/scikits-image/pull/134
>
> This should fix the above problem and a host of others.
>
> A mechanism for auto-downloading a freeimage library on Win/Mac is still in progress... I'm not sure how to best integrate that with the distutils, but here's what I have for a start:
> https://github.com/zachrahan/scikits-image/tree/freeimage-install-libs
> https://github.com/zachrahan/freeimage-sharedlib
>
> Zach
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: guillaume.vcf
Type: text/x-vcard
Size: 282 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120210/84805257/attachment.vcf>

From stefan at sun.ac.za  Fri Feb 10 19:14:11 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 10 Feb 2012 16:14:11 -0800
Subject: Understanding HoG output
In-Reply-To: <20120210171742.GB2759@phare.normalesup.org>
References: <a9ae03e4-f629-48f0-905e-8e623ffae190@qt7g2000pbc.googlegroups.com>
 <CAFkP-qy-TzHD4RsOM1rZVnpB=Gpj=kzCg+0q0JvxjvHvFhuggg@mail.gmail.com> <20120210171742.GB2759@phare.normalesup.org>
Message-ID: <CABDkGQmaDq-UBjN=Lgs6mxYmGYd=xFkTPA-amLP4xJyeSjPHJg@mail.gmail.com>

On Fri, Feb 10, 2012 at 9:17 AM, Emmanuelle Gouillart
<emmanuelle.gouillart at nsup.org> wrote:
> understanding how this function was working. Your explanations do help;
> do you think it would be possible to write a meaningful example using

And Brian obliged...

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

St?fan


From emmanuelle.gouillart at nsup.org  Fri Feb 10 12:17:42 2012
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Fri, 10 Feb 2012 18:17:42 +0100
Subject: Understanding HoG output
In-Reply-To: <CAFkP-qy-TzHD4RsOM1rZVnpB=Gpj=kzCg+0q0JvxjvHvFhuggg@mail.gmail.com>
References: <a9ae03e4-f629-48f0-905e-8e623ffae190@qt7g2000pbc.googlegroups.com>
 <CAFkP-qy-TzHD4RsOM1rZVnpB=Gpj=kzCg+0q0JvxjvHvFhuggg@mail.gmail.com>
Message-ID: <20120210171742.GB2759@phare.normalesup.org>

Hi Brian,

thanks a lot for the explanations! I must say that when I had a look at
the HoG function following Michael's post, I had quite a hard time
understanding how this function was working. Your explanations do help;
do you think it would be possible to write a meaningful example using
HoGs for the example gallery? That might give a good starting point in
order to use this function. If you don't have the time to write the
example yourself, any hints on the possible contents would also help.

Cheers,
Emmanuelle

On Fri, Feb 10, 2012 at 01:45:12PM +0000, Brian Holt wrote:
>    Hi Michael,??????

>      Hi, new to group, new to image processing starting to explore HoG.
>      Looking for a python implementation and discovered
>      skimage.feature.hog().

>    Glad to hear someone's using HoGs!

>      My plan to run skimage.features.hog over some positive/negative images
>      and use this to train a svm classifier from scikits-learn. ?????? I am
>      trying to understand the output hog before I proceed further. ?????? ??????When
>      I run skimag.feature.hog() it over a region of interest ??????it appears to
>      returns an array. ??????How do I interpret this array???????

>    My best suggestion would be that you take a look at the comments written
>    in `hog.py`. ??????Each part quotes the relevant section from the Dalal Triggs
>    paper and then under that implements the code required to do the job.
>    ??????Others on this list may have different views, but I'd be reluctant to try
>    to 'interpret' the flattened descriptor. ??????

>      ??????Is there a way to??????reshape the array to see what it was like before it
>      was flattened or??????that doesn't make any sense? ??????Can I plot the descriptor
>      returned in
>      any meaningful way?

>    Yes, you can reshape the array (but that can be a bit tricky), or you
>    could modify the hog function to return the unraveled descriptor and ravel
>    it yourself later if you need it.

>      Also when I choose to visualise the HoG often where I expected to see
>      vertical line dominate, say on the edge of builds, the line drawn
>      often appears to be more dominant at the 45 deg. ??????Is this expected as
>      the line drawn is really just the sum of all surrounding orientations
>      for the "cell"?

>    A line is drawn for each gradient bin with an intensity proportional to
>    the magnitude of that gradient. ??????So, the 'star' shape you see for each
>    cell is just the superimposition of all of these lines. You should expect
>    to see dominant lines perpendicular to lines in the image (parallel to the
>    gradient). Also remember that the default is to use 9 bins, so it may be
>    that the 45degree dominant line you see is the closest approximation to
>    horizontal. ??????You can test this out by trying 8 bins instead of 9.??????

>    I hope it helps, feel free to ask any more questions.
>    Regards
>    Brian

>    On 9 February 2012 06:37, bricklemacho <[1]bricklemacho at gmail.com> wrote:

>      Thanks in advance,

>      Michael.


From emmanuelle.gouillart at nsup.org  Fri Feb 10 13:33:26 2012
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Fri, 10 Feb 2012 19:33:26 +0100
Subject: Understanding HoG output
In-Reply-To: <20120210171742.GB2759@phare.normalesup.org>
References: <a9ae03e4-f629-48f0-905e-8e623ffae190@qt7g2000pbc.googlegroups.com>
 <CAFkP-qy-TzHD4RsOM1rZVnpB=Gpj=kzCg+0q0JvxjvHvFhuggg@mail.gmail.com>
 <20120210171742.GB2759@phare.normalesup.org>
Message-ID: <20120210183326.GA3444@phare.normalesup.org>

Wow, that was quick ;-) ! Thanks for the pull request, will have a look
at it right now.

Emmanuelle

On Fri, Feb 10, 2012 at 06:17:42PM +0100, Emmanuelle Gouillart wrote:
> Hi Brian,

> thanks a lot for the explanations! I must say that when I had a look at
> the HoG function following Michael's post, I had quite a hard time
> understanding how this function was working. Your explanations do help;
> do you think it would be possible to write a meaningful example using
> HoGs for the example gallery? That might give a good starting point in
> order to use this function. If you don't have the time to write the
> example yourself, any hints on the possible contents would also help.

> Cheers,
> Emmanuelle

> On Fri, Feb 10, 2012 at 01:45:12PM +0000, Brian Holt wrote:
> >    Hi Michael,??????

> >      Hi, new to group, new to image processing starting to explore HoG.
> >      Looking for a python implementation and discovered
> >      skimage.feature.hog().

> >    Glad to hear someone's using HoGs!

> >      My plan to run skimage.features.hog over some positive/negative images
> >      and use this to train a svm classifier from scikits-learn. ?????? I am
> >      trying to understand the output hog before I proceed further. ?????? ??????When
> >      I run skimag.feature.hog() it over a region of interest ??????it appears to
> >      returns an array. ??????How do I interpret this array???????

> >    My best suggestion would be that you take a look at the comments written
> >    in `hog.py`. ??????Each part quotes the relevant section from the Dalal Triggs
> >    paper and then under that implements the code required to do the job.
> >    ??????Others on this list may have different views, but I'd be reluctant to try
> >    to 'interpret' the flattened descriptor. ??????

> >      ??????Is there a way to??????reshape the array to see what it was like before it
> >      was flattened or??????that doesn't make any sense? ??????Can I plot the descriptor
> >      returned in
> >      any meaningful way?

> >    Yes, you can reshape the array (but that can be a bit tricky), or you
> >    could modify the hog function to return the unraveled descriptor and ravel
> >    it yourself later if you need it.

> >      Also when I choose to visualise the HoG often where I expected to see
> >      vertical line dominate, say on the edge of builds, the line drawn
> >      often appears to be more dominant at the 45 deg. ??????Is this expected as
> >      the line drawn is really just the sum of all surrounding orientations
> >      for the "cell"?

> >    A line is drawn for each gradient bin with an intensity proportional to
> >    the magnitude of that gradient. ??????So, the 'star' shape you see for each
> >    cell is just the superimposition of all of these lines. You should expect
> >    to see dominant lines perpendicular to lines in the image (parallel to the
> >    gradient). Also remember that the default is to use 9 bins, so it may be
> >    that the 45degree dominant line you see is the closest approximation to
> >    horizontal. ??????You can test this out by trying 8 bins instead of 9.??????

> >    I hope it helps, feel free to ask any more questions.
> >    Regards
> >    Brian

> >    On 9 February 2012 06:37, bricklemacho <[1]bricklemacho at gmail.com> wrote:

> >      Thanks in advance,

> >      Michael.


From emmanuelle.gouillart at nsup.org  Fri Feb 10 13:58:57 2012
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Fri, 10 Feb 2012 19:58:57 +0100
Subject: Error when building from git
In-Reply-To: <CABDkGQkAo91Ve5gc7UA8tezE4jnm0q7eBuUbp9GZABvTt2Y9MQ@mail.gmail.com>
References: <e36f20f0-9e2c-445d-8f7c-4ba9fc1fa3ae@t5g2000yqk.googlegroups.com>
 <CABDkGQkAo91Ve5gc7UA8tezE4jnm0q7eBuUbp9GZABvTt2Y9MQ@mail.gmail.com>
Message-ID: <20120210185857.GB3444@phare.normalesup.org>

Hi,

> The float16 data-type was introduced in NumPy 1.6, and while we
> currently list NumPy 1.4 as a dependency, but we're going to have to
> up that to 1.6 (I think some of it is being used in the data type
> conversion code now, e.g.).  I hope this isn't too much of an
> inconvenience!

isn't it possible to test which version of numpy is used, and remove
float16 from the list if numpy.__version__ < 1.6? It looks like a small
cost in order to be be able to support numpy 1.5. I can do the change if
there is no opposition to this.

The same thing that happened to Guillaume also happened to me as I was
rebuilding skimage 10 minutes ago, since I'm using the version of numpy
packaged by the most recent Ubuntu which is 1.5.

As I see things, it would be great if people could use skimage with the
dependencies provided by a recent version of Ubuntu, say the most recent
LTS, or the latest release of Ubuntu. We will lose many users if they
have to install a new numpy (which also means that they will have to
install non-packaged matplolib, and scipy). If you disagree with this
philosophy, please tell me :-).

My 2 cents,
Emmanuelle


From stefan at sun.ac.za  Sat Feb 11 04:39:22 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sat, 11 Feb 2012 01:39:22 -0800
Subject: Error when building from git
In-Reply-To: <20120210185857.GB3444@phare.normalesup.org>
References: <e36f20f0-9e2c-445d-8f7c-4ba9fc1fa3ae@t5g2000yqk.googlegroups.com>
 <CABDkGQkAo91Ve5gc7UA8tezE4jnm0q7eBuUbp9GZABvTt2Y9MQ@mail.gmail.com> <20120210185857.GB3444@phare.normalesup.org>
Message-ID: <CABDkGQkqERmOWudUTkL9-oZB6f+8dHdH=7WL7mGjyFwGyb99Ww@mail.gmail.com>

Hi Emmanuelle

On Fri, Feb 10, 2012 at 10:58 AM, Emmanuelle Gouillart
<emmanuelle.gouillart at nsup.org> wrote:
> isn't it possible to test which version of numpy is used, and remove
> float16 from the list if numpy.__version__ < 1.6? It looks like a small
> cost in order to be be able to support numpy 1.5. I can do the change if
> there is no opposition to this.

If we can stay compatible with 1.5 with minor changes, that's probably
worth it.  Can you also check the dtype conversion code to make sure
it all works? (Running the unit tests should be enough of an
indication)

> As I see things, it would be great if people could use skimage with the
> dependencies provided by a recent version of Ubuntu, say the most recent
> LTS, or the latest release of Ubuntu. We will lose many users if they
> have to install a new numpy (which also means that they will have to
> install non-packaged matplolib, and scipy). If you disagree with this
> philosophy, please tell me :-).

I understand the challenges of running on an older platform, but I
also wonder: if a user can recompile scikits-image, what's stopping
them from also building the latest (stable) numpy?  I certainly have
the expectation that software should run with the available stable
versions of dependencies on the date of release.  That said, any
benefit we can get with little effort is worth it, and there's no
reason to purposefully make it harder for users than need be.  So
please, keep the PRs coming for backwards compatibility, as long as
they are not too disruptive.

Regards
St?fan


From bricklemacho at gmail.com  Sat Feb 11 05:07:11 2012
From: bricklemacho at gmail.com (bricklemacho)
Date: Sat, 11 Feb 2012 02:07:11 -0800 (PST)
Subject: Understanding HoG output
In-Reply-To: <CAFkP-qy-TzHD4RsOM1rZVnpB=Gpj=kzCg+0q0JvxjvHvFhuggg@mail.gmail.com>
References: <a9ae03e4-f629-48f0-905e-8e623ffae190@qt7g2000pbc.googlegroups.com>
 <CAFkP-qy-TzHD4RsOM1rZVnpB=Gpj=kzCg+0q0JvxjvHvFhuggg@mail.gmail.com>
Message-ID: <efa12f74-b93c-4514-a24d-b0ae43c8561b@tj4g2000pbc.googlegroups.com>

> My best suggestion would be that you take a look at the comments written in
> `hog.py`. ?Each part quotes the relevant section from the Dalal Triggs
> paper and then under that implements the code required to do the job.
> ?Others on this list may have different views, but I'd be reluctant to try
> to 'interpret' the flattened descriptor.

Doh! didn't think to look at the code.  Based on this suggestion I
have had a look at the code, good level of commenting in the code.


> Yes, you can reshape the array (but that can be a bit tricky), or you could
> modify the hog function to return the unraveled descriptor and ravel it
> yourself later if you need it.

Thanks for the idea.



> A line is drawn for each gradient bin with an intensity proportional to the
> magnitude of that gradient. ?So, the 'star' shape you see for each cell is
> just the superimposition of all of these lines. You should expect to see
> dominant lines perpendicular to lines in the image (parallel to the
> gradient). Also remember that the default is to use 9 bins, so it may be
> that the 45degree dominant line you see is the closest approximation to
> horizontal. ?You can test this out by trying 8 bins instead of 9.

Ahh.. I guess I was expecting some sort of "edge" like in the edge
detector.  Makes more sense now.


Also, thanks for the simple example.


From nelle.varoquaux at gmail.com  Sat Feb 11 02:58:58 2012
From: nelle.varoquaux at gmail.com (Nelle Varoquaux)
Date: Sat, 11 Feb 2012 08:58:58 +0100
Subject: Error when building from git
In-Reply-To: <20120210185857.GB3444@phare.normalesup.org>
References: <e36f20f0-9e2c-445d-8f7c-4ba9fc1fa3ae@t5g2000yqk.googlegroups.com>
	<CABDkGQkAo91Ve5gc7UA8tezE4jnm0q7eBuUbp9GZABvTt2Y9MQ@mail.gmail.com>
	<20120210185857.GB3444@phare.normalesup.org>
Message-ID: <CAE-UAvSaF2UUuNRMRx_6dCSj4Om+PiC9JhxwbqL8o3M3hdjBjQ@mail.gmail.com>

Hi,

As I see things, it would be great if people could use skimage with the
> dependencies provided by a recent version of Ubuntu, say the most recent
> LTS, or the latest release of Ubuntu. We will lose many users if they
> have to install a new numpy (which also means that they will have to
> install non-packaged matplolib, and scipy). If you disagree with this
> philosophy, please tell me :-).
>

My ubuntu version is old (11.04, and I don't want to risk breaking my OS
updating it), so I am more in favor of keeping at least the version in the
most recent LTS. I also think ubuntu is one of the distro moving fast. I'm
not sure what versions of numpy is packaged for debian and OpenSuse, but it
might be worth checking that too.

Cheers,
N
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120211/1e4d5a3f/attachment.html>

From google at terre-adelie.org  Sat Feb 11 05:31:19 2012
From: google at terre-adelie.org (=?ISO-8859-1?Q?J=E9r=F4me?= Kieffer)
Date: Sat, 11 Feb 2012 11:31:19 +0100
Subject: Error when building from git
In-Reply-To: <20120210185857.GB3444@phare.normalesup.org>
References: <e36f20f0-9e2c-445d-8f7c-4ba9fc1fa3ae@t5g2000yqk.googlegroups.com>
	<CABDkGQkAo91Ve5gc7UA8tezE4jnm0q7eBuUbp9GZABvTt2Y9MQ@mail.gmail.com>
	<20120210185857.GB3444@phare.normalesup.org>
Message-ID: <20120211113119.445a7227.google@terre-adelie.org>


Hi Emmanuelle,

The latest Ubuntu LTS is 10.04 where numpy is v1.3
(http://packages.ubuntu.com/lucid/python-numpy) 
The latest stable debian is squeeze where numpy is v1.4.1
(http://packages.debian.org/squeeze/python-numpy)

If you intent to package skimage for debian you should have a look at
what are the current versions in unstable (aka sid) and testing
(currently wheezy). If you keep compatibility with stable one could
even backport skimage to stable and make it available for current
distribution at virtually no-cost.

-- 
J?r?me Kieffer <jerome.kieffer at terre-adelie.org>

PS: We are currently deploying debian6 (squeeze) at work which should
be the reference until end 2013 (at least!) so putting dependency on a
too-recent numpy will prevent skimage to be deployed on the beamline.



From stefan at sun.ac.za  Sat Feb 11 17:26:10 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sat, 11 Feb 2012 14:26:10 -0800
Subject: Error when building from git
In-Reply-To: <20120211113119.445a7227.google@terre-adelie.org>
References: <e36f20f0-9e2c-445d-8f7c-4ba9fc1fa3ae@t5g2000yqk.googlegroups.com>
 <CABDkGQkAo91Ve5gc7UA8tezE4jnm0q7eBuUbp9GZABvTt2Y9MQ@mail.gmail.com>
 <20120210185857.GB3444@phare.normalesup.org> <20120211113119.445a7227.google@terre-adelie.org>
Message-ID: <CABDkGQ=XWF4Gbc7DNpOonmuVoHH9Sc=Eq4mdyUGm-qo0FDQ0sQ@mail.gmail.com>

2012/2/11 J?r?me Kieffer <google at terre-adelie.org>:
> PS: We are currently deploying debian6 (squeeze) at work which should
> be the reference until end 2013 (at least!) so putting dependency on a
> too-recent numpy will prevent skimage to be deployed on the beamline.

I guess the point I was trying to make is that nobody expects SciPy 12
to work with NumPy 1.5, since they are released at different times.
If you install scikits-image 0.4, released when NumPy 1.5 was stable,
you'll get 1.5 compatibility.  The problem only comes in when you
require the latest functionality--in which case upgrading the package
+ dependencies seems completely reasonable.

If we focus on getting scikits-image packaged in the different
distros, these problems should more-or-less go away, since people will
do "apt-get install python-skimage" and be happy with whichever
version is provided.

St?fan


From tsyu80 at gmail.com  Sat Feb 11 17:07:21 2012
From: tsyu80 at gmail.com (Tony Yu)
Date: Sat, 11 Feb 2012 17:07:21 -0500
Subject: Error when building from git
In-Reply-To: <CABDkGQkqERmOWudUTkL9-oZB6f+8dHdH=7WL7mGjyFwGyb99Ww@mail.gmail.com>
References: <e36f20f0-9e2c-445d-8f7c-4ba9fc1fa3ae@t5g2000yqk.googlegroups.com>
	<CABDkGQkAo91Ve5gc7UA8tezE4jnm0q7eBuUbp9GZABvTt2Y9MQ@mail.gmail.com>
	<20120210185857.GB3444@phare.normalesup.org>
	<CABDkGQkqERmOWudUTkL9-oZB6f+8dHdH=7WL7mGjyFwGyb99Ww@mail.gmail.com>
Message-ID: <CAEym_HoqEZTgDZ23Rf7gknZnunCvRjoqqY0oAVRK6UUV837xDw@mail.gmail.com>

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

> Hi Emmanuelle
>
> On Fri, Feb 10, 2012 at 10:58 AM, Emmanuelle Gouillart
> <emmanuelle.gouillart at nsup.org> wrote:
> > isn't it possible to test which version of numpy is used, and remove
> > float16 from the list if numpy.__version__ < 1.6? It looks like a small
> > cost in order to be be able to support numpy 1.5. I can do the change if
> > there is no opposition to this.
>
> If we can stay compatible with 1.5 with minor changes, that's probably
> worth it.  Can you also check the dtype conversion code to make sure
> it all works? (Running the unit tests should be enough of an
> indication)
>

I'd be in favor of supporting numpy 1.5. Just note that the `convert`
function uses `np.promote_types`, which is also new to numpy 1.6.

-Tony

> As I see things, it would be great if people could use skimage with the
> > dependencies provided by a recent version of Ubuntu, say the most recent
> > LTS, or the latest release of Ubuntu. We will lose many users if they
> > have to install a new numpy (which also means that they will have to
> > install non-packaged matplolib, and scipy). If you disagree with this
> > philosophy, please tell me :-).
>
> I understand the challenges of running on an older platform, but I
> also wonder: if a user can recompile scikits-image, what's stopping
> them from also building the latest (stable) numpy?  I certainly have
> the expectation that software should run with the available stable
> versions of dependencies on the date of release.  That said, any
> benefit we can get with little effort is worth it, and there's no
> reason to purposefully make it harder for users than need be.  So
> please, keep the PRs coming for backwards compatibility, as long as
> they are not too disruptive.
>
> Regards
> St?fan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120211/6bc4e531/attachment.html>

From cjgohlke at gmail.com  Sun Feb 12 11:57:26 2012
From: cjgohlke at gmail.com (Christoph Gohlke)
Date: Sun, 12 Feb 2012 08:57:26 -0800
Subject: Error when building from git
In-Reply-To: <20120212103643.GD5452@phare.normalesup.org>
References: <e36f20f0-9e2c-445d-8f7c-4ba9fc1fa3ae@t5g2000yqk.googlegroups.com> <CABDkGQkAo91Ve5gc7UA8tezE4jnm0q7eBuUbp9GZABvTt2Y9MQ@mail.gmail.com> <20120210185857.GB3444@phare.normalesup.org> <CABDkGQkqERmOWudUTkL9-oZB6f+8dHdH=7WL7mGjyFwGyb99Ww@mail.gmail.com> <CAEym_HoqEZTgDZ23Rf7gknZnunCvRjoqqY0oAVRK6UUV837xDw@mail.gmail.com> <20120212103643.GD5452@phare.normalesup.org>
Message-ID: <4F37EF76.4010606@gmail.com>

On 2/12/2012 2:36 AM, Emmanuelle Gouillart wrote:
> On Sat, Feb 11, 2012 at 05:07:21PM -0500, Tony Yu wrote:
>>     I'd be in favor of supporting numpy 1.5. Just note that the `convert`
>>     function uses `np.promote_types`, which is also new to numpy 1.6.
>>     -Tony
> Thanks Tony, I figured this out when running the tests :-). So if we want
> to support numpy 1.5, we'll have to write a conversion table to emulate
> what np.promote_types does, is that correct?
>
> Emmanuelle
>

Note that the original rewrite of the dtype._convert function had it's 
own inline implementation of dtype promotion, e.g. 
<https://github.com/cgohlke/scikits-image/commit/038db9d1abb684e22656af4a954c94109ac0f94f#L0R74>. 


Christoph


From emmanuelle.gouillart at nsup.org  Sun Feb 12 05:36:43 2012
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Sun, 12 Feb 2012 11:36:43 +0100
Subject: Error when building from git
In-Reply-To: <CAEym_HoqEZTgDZ23Rf7gknZnunCvRjoqqY0oAVRK6UUV837xDw@mail.gmail.com>
References: <e36f20f0-9e2c-445d-8f7c-4ba9fc1fa3ae@t5g2000yqk.googlegroups.com>
 <CABDkGQkAo91Ve5gc7UA8tezE4jnm0q7eBuUbp9GZABvTt2Y9MQ@mail.gmail.com>
 <20120210185857.GB3444@phare.normalesup.org>
 <CABDkGQkqERmOWudUTkL9-oZB6f+8dHdH=7WL7mGjyFwGyb99Ww@mail.gmail.com>
 <CAEym_HoqEZTgDZ23Rf7gknZnunCvRjoqqY0oAVRK6UUV837xDw@mail.gmail.com>
Message-ID: <20120212103643.GD5452@phare.normalesup.org>

On Sat, Feb 11, 2012 at 05:07:21PM -0500, Tony Yu wrote:
>    I'd be in favor of supporting numpy 1.5. Just note that the `convert`
>    function uses `np.promote_types`, which is also new to numpy 1.6.
>    -Tony

Thanks Tony, I figured this out when running the tests :-). So if we want
to support numpy 1.5, we'll have to write a conversion table to emulate
what np.promote_types does, is that correct?

Emmanuelle


From emmanuelle.gouillart at nsup.org  Sun Feb 12 05:59:42 2012
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Sun, 12 Feb 2012 11:59:42 +0100
Subject: Error when building from git
In-Reply-To: <CABDkGQkqERmOWudUTkL9-oZB6f+8dHdH=7WL7mGjyFwGyb99Ww@mail.gmail.com>
References: <e36f20f0-9e2c-445d-8f7c-4ba9fc1fa3ae@t5g2000yqk.googlegroups.com>
 <CABDkGQkAo91Ve5gc7UA8tezE4jnm0q7eBuUbp9GZABvTt2Y9MQ@mail.gmail.com>
 <20120210185857.GB3444@phare.normalesup.org>
 <CABDkGQkqERmOWudUTkL9-oZB6f+8dHdH=7WL7mGjyFwGyb99Ww@mail.gmail.com>
Message-ID: <20120212105942.GE5452@phare.normalesup.org>


Hi St??????fan,

> I understand the challenges of running on an older platform, but I
> also wonder: if a user can recompile scikits-image, what's stopping
> them from also building the latest (stable) numpy?  

Well, it's just one more pain in the neck to build another package. And
if you have to build numpy, (I think) you also have to build your own
matplotlib, scipy, etc. Which is even a greater pain.

What's more, a large fraction of users want to use the packages installed
by their IT managers, who like to have one standard version of all
packages. People using Python(x,y) on Windows, for example, would have a
hard time building all the packages. I think the example given by
J??????r??????me is a good one: he works in a big institute where people might be
interested in using skimage, but users typically don't install their own
packages. 

That said, we can of course tell people to install an older version
skimage. However, I have the impression that an important part of the
added value of new releases are in the algorithms/functions that the
release provides, rather than in using newer numpy functionalities.
This is by all means a biased point of view, since I've been more busy
with the former point.

> I certainly have
> the expectation that software should run with the available stable
> versions of dependencies on the date of release.  That said, any
> benefit we can get with little effort is worth it, and there's no
> reason to purposefully make it harder for users than need be.  So
> please, keep the PRs coming for backwards compatibility, as long as
> they are not too disruptive.

OK, I'll try to :-D.

Cheers,
Emmanuelle


From emmanuelle.gouillart at nsup.org  Sun Feb 12 10:16:56 2012
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Sun, 12 Feb 2012 16:16:56 +0100
Subject: random walker segmentation / blob detection
In-Reply-To: <CABDkGQm1t68ssXkZRVBCM47=zc-hUbyqz_Zzp9Xk-bD8Pf5m2w@mail.gmail.com>
References: <27207519.2086.1328618871447.JavaMail.geo-discussion-forums@yqcz12>
 <CABDkGQnLd+sibOQt6JGkL=vWQ++ymXUyX+BaF5q_+w=zhgRj4A@mail.gmail.com>
 <26400884.2838.1328694755524.JavaMail.geo-discussion-forums@vbtr6>
 <20120208134653.GD4628@phare.normalesup.org>
 <18847975.422.1328807194237.JavaMail.geo-discussion-forums@vbjk3>
 <CABDkGQm1t68ssXkZRVBCM47=zc-hUbyqz_Zzp9Xk-bD8Pf5m2w@mail.gmail.com>
Message-ID: <20120212151656.GB28929@phare.normalesup.org>

On Fri, Feb 10, 2012 at 03:39:15AM -0800, St??????fan van der Walt wrote:
> On Thu, Feb 9, 2012 at 9:06 AM, Michael Aye <kmichael.aye at gmail.com> wrote:
> > Can k-means clustering maybe indicate to me how well a clustering worked,
> > something like a score? I basically have 3 phases in the images: dark blobs,
> > grayish background, and bright ice patches. Maybe clustering could indicate
> > by scores if a 2 or 3 phase clustering represents the image better?

> Here's an implementation of ICM-based clustering:

> http://stackoverflow.com/a/9174197/214686

> I wonder if we should include this in the scikit--Emmanuelle, do
> people actually still use ICM segmentation?

I have to say that I don't know ICM segmentation. It looks very
interesting (your code is impressively short!), would you have any
reference to suggest for me to read about this algorithm?

Thx,
Emmanuelle


From stefan at sun.ac.za  Sun Feb 12 19:21:55 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 12 Feb 2012 16:21:55 -0800
Subject: random walker segmentation / blob detection
In-Reply-To: <20120212151656.GB28929@phare.normalesup.org>
References: <27207519.2086.1328618871447.JavaMail.geo-discussion-forums@yqcz12>
 <CABDkGQnLd+sibOQt6JGkL=vWQ++ymXUyX+BaF5q_+w=zhgRj4A@mail.gmail.com>
 <26400884.2838.1328694755524.JavaMail.geo-discussion-forums@vbtr6>
 <20120208134653.GD4628@phare.normalesup.org> <18847975.422.1328807194237.JavaMail.geo-discussion-forums@vbjk3>
 <CABDkGQm1t68ssXkZRVBCM47=zc-hUbyqz_Zzp9Xk-bD8Pf5m2w@mail.gmail.com> <20120212151656.GB28929@phare.normalesup.org>
Message-ID: <CABDkGQkEQkMjBgmPN8h=jSC4QWSKrm5DSNtGSWhARr=YF9b39Q@mail.gmail.com>

On Sun, Feb 12, 2012 at 7:16 AM, Emmanuelle Gouillart
<emmanuelle.gouillart at nsup.org> wrote:
> I have to say that I don't know ICM segmentation. It looks very
> interesting (your code is impressively short!), would you have any
> reference to suggest for me to read about this algorithm?

It is called Iterated Conditional Modes, but I have to admit that my
implementation is based on a tea-time conversation, and not on any
specific paper.  The reference I have is:

On the Statistical Analysis of Dirty Pictures
Julian Besag
Journal of the Royal Statistical Society. Series B (Methodological)
Vol. 48, No. 3 (1986), pp. 259-302

Regards
St?fan


From emmanuelle.gouillart at nsup.org  Sun Feb 12 11:31:45 2012
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Sun, 12 Feb 2012 17:31:45 +0100
Subject: random walker segmentation / blob detection
In-Reply-To: <CAHGWWxH8B_H6BgjpnFufUnnaPRZHdjDtfe7_5fYjRA7JT43JCg@mail.gmail.com>
References: <27207519.2086.1328618871447.JavaMail.geo-discussion-forums@yqcz12>
 <CABDkGQnLd+sibOQt6JGkL=vWQ++ymXUyX+BaF5q_+w=zhgRj4A@mail.gmail.com>
 <26400884.2838.1328694755524.JavaMail.geo-discussion-forums@vbtr6>
 <20120208134653.GD4628@phare.normalesup.org>
 <CAHGWWxFKunAkJUVkrokxipqczSN5Sbg8LhDRoenRFHpQP55S5g@mail.gmail.com>
 <11829122.221.1328784249183.JavaMail.geo-discussion-forums@vbev17>
 <CAHGWWxH8B_H6BgjpnFufUnnaPRZHdjDtfe7_5fYjRA7JT43JCg@mail.gmail.com>
Message-ID: <20120212163145.GD28929@phare.normalesup.org>

Hi Ray,

this segmentation algorithm with supervised learning really seems great!
I wonder whether we could have a similar algorithm in skimage.
ilastik.org is down at the moment, so I can't check their license. But
there is a random forest classifier in scikit-learn that we could re-use.
A difficult point is the in-painting of pixels on the image; could anyone
give hints about technical solutions to do this?

Cheers,
Emmanuelle

On Thu, Feb 09, 2012 at 01:06:57PM +0100, Thouis Jones wrote:
> On Thu, Feb 9, 2012 at 11:44, Michael Aye <kmichael.aye at gmail.com> wrote:
> > ilastik does not seem to have a programmatic interface, is that right?
> > I can't do it via GUI's, my end goal is to find features programmatically in
> > possibly thousands of images...

> It has a scripting interface (command line) for batch processing.  I
> have talked to them about adding a client/server mode using zmq, but
> it's not yet started.

> Ray 


From emmanuelle.gouillart at nsup.org  Sun Feb 12 14:30:32 2012
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Sun, 12 Feb 2012 20:30:32 +0100
Subject: random walker segmentation / blob detection
In-Reply-To: <18847975.422.1328807194237.JavaMail.geo-discussion-forums@vbjk3>
References: <27207519.2086.1328618871447.JavaMail.geo-discussion-forums@yqcz12>
 <CABDkGQnLd+sibOQt6JGkL=vWQ++ymXUyX+BaF5q_+w=zhgRj4A@mail.gmail.com>
 <26400884.2838.1328694755524.JavaMail.geo-discussion-forums@vbtr6>
 <20120208134653.GD4628@phare.normalesup.org>
 <18847975.422.1328807194237.JavaMail.geo-discussion-forums@vbjk3>
Message-ID: <20120212193032.GE28929@phare.normalesup.org>

Hello Michael,

>      (e.g., taking the 10% darker and lighter pixels), but other
>      features than gray values can be use to determine whether you can
>      label your markers or not (such as local variance, Haralick
>      features -- this is in fact a classification task).

>    What does 'this' refer to? Using Haralick features, or my general problem?
>    ??????

I was thinking of the general problem of assigning labels to objects.

>      Are your images always taken with the same exposure settings?
>      What I mean is, can you know in advance what are the grey values of the
>      blob?

>    No, not at all unfortunately. My data consists of time series under
>    varying lighting conditions due to the different incidence angles of the
>    sun. Therefore the SNR also changes.
>    ??????

Any way that you could rescale all your images in a meaningful way? If
the grayish background always occupies a large fraction of the image (say
more than 50%?), then you could try to rescale the grey values so that
the central part of the histogram (say from quantile 25% to 75%) is the
same for all your images. If this is possible, it would make your life
much easier, since you could determine markers in the same way for all
images after this rescaling step.

>      What I understand from your two images is that you know that there are
>      blobs not only from the grey values but also because these regions have
>      a
>      certain size and have less texture (a smaller local variance) than
>      elsewhere, so you might want to incorporate this criteria as well in
>      the choice of markers.

>    Unfortunately I don't know the size. These blobs can be big or small. The
>    only thing I could fix size-wise is, that I don't want to count blobs that
>    are the same size as the background-noise dips. But I would not know how
>    to 'measure' that.
>    ??????
The background definitely has some texture. Have you tried checking the
Fourier transform or the wavelet transform to see whether you can extract
this typical length? Or you could binarize the image (using
threshold_otsu for example) and estimate the size of shadow patches by
mathematical morphology operations (how many erosions are needed to get
rid of a large fraction of the dark patches?). 

Once again, this supposes that the background is the majority phase, I
don't know whether it's always the case or not.

>      If you can have hard thresholds for these criteria
>      (that are the same for all images), then it is much easier, but if you
>      can't, it's really a question of determining whether you have one or two
>      clusters in your features space (features being grey values, local
>      variance etc.) and I don't know a proper method to do that.

>    Can k-means clustering maybe indicate to me how well a clustering worked,
>    something like a score? I basically have 3 phases in the images: dark
>    blobs, grayish background, and bright ice patches. Maybe clustering could
>    indicate by scores if a 2 or 3 phase clustering represents the image
>    better?
>    ??????

Well, this is not an easy problem, see for example
http://en.wikipedia.org/wiki/Determining_the_number_of_clusters_in_a_data_set
The score of the k-means algorithm is given by the sum of the squared
distances of points to the cluster center (see
http://en.wikipedia.org/wiki/K-means_clustering). (This is not really a
score, since you want to minimize this quantity, it's the inverse of a
score) The more clusters you have, the smaller will be this quantity:
you'll have to decide how much you want it to decrease when you increase
the number of clusters. Don't know whether that would work or not...  

Cheers,
Emmanuelle


From stefan at sun.ac.za  Mon Feb 13 05:48:22 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 13 Feb 2012 02:48:22 -0800
Subject: Error when building from git
In-Reply-To: <20120212105942.GE5452@phare.normalesup.org>
References: <e36f20f0-9e2c-445d-8f7c-4ba9fc1fa3ae@t5g2000yqk.googlegroups.com>
 <CABDkGQkAo91Ve5gc7UA8tezE4jnm0q7eBuUbp9GZABvTt2Y9MQ@mail.gmail.com>
 <20120210185857.GB3444@phare.normalesup.org> <CABDkGQkqERmOWudUTkL9-oZB6f+8dHdH=7WL7mGjyFwGyb99Ww@mail.gmail.com>
 <20120212105942.GE5452@phare.normalesup.org>
Message-ID: <CABDkGQnxwX+NtDUDyXBMZbmmADWe2e6c6_PfcZ5Y+00uFOncsA@mail.gmail.com>

On Sun, Feb 12, 2012 at 2:59 AM, Emmanuelle Gouillart
<emmanuelle.gouillart at nsup.org> wrote:
> What's more, a large fraction of users want to use the packages installed
> by their IT managers, who like to have one standard version of all
> packages. People using Python(x,y) on Windows, for example, would have a
> hard time building all the packages. I think the example given by
> J?r?me is a good one: he works in a big institute where people might be
> interested in using skimage, but users typically don't install their own
> packages.

We are included in Python(x,y), for the record.  The issue here is
only with people who want to use the latest (Git) version of skimage.

> That said, we can of course tell people to install an older version
> skimage. However, I have the impression that an important part of the
> added value of new releases are in the algorithms/functions that the
> release provides, rather than in using newer numpy functionalities.
> This is by all means a biased point of view, since I've been more busy
> with the former point.

That's a very valid point.  And since it's so little effort to remain
1.5 compatible, there seems little reason not to.

I'm the guilty party that suggested the use of a numpy 1.6 call in the
converter functions--sorry about that!  Chris has kindly made a PR to
address the issue.

So, let's talk about Matplotlib--can we use version 1 yet?  If not, I
suggest that we at least copy over 'subplots', because this function
makes it so much easier to build clean examples.

St?fan


From zachary.pincus at yale.edu  Mon Feb 13 08:44:20 2012
From: zachary.pincus at yale.edu (Zachary Pincus)
Date: Mon, 13 Feb 2012 08:44:20 -0500
Subject: Tifffile.py as a plugin vs BioFormats
In-Reply-To: <4F38DB21.1000702@mitotic-machine.org>
References: <e36f20f0-9e2c-445d-8f7c-4ba9fc1fa3ae@t5g2000yqk.googlegroups.com> <CABDkGQkAo91Ve5gc7UA8tezE4jnm0q7eBuUbp9GZABvTt2Y9MQ@mail.gmail.com> <7812d347-4dfe-45fa-b253-0da6d510d557@w1g2000vbg.googlegroups.com> <CABDkGQkx0HGgYJXo9Vs28b_gUdxPWFNrjDSS0ffvAf5sjSeR6Q@mail.gmail.com> <6A03E059-3B64-4614-83D0-B790B1E8650D@yale.edu> <4F353293.4080808@mitotic-machine.org> <7CFEF0AD-F1D6-4277-8975-36867D8B8D1C@yale.edu> <4F358A15.4080606@gmail.com> <4F38DB21.1000702@mitotic-machine.org>
Message-ID: <395D2F78-5F54-4B05-B516-C1BD0D6C5F81@yale.edu>

> Thank you Christoph for the suggestion, I think I will use your solution, which works fine for me.
> 
> 
> Of course BioFormats is kind of the golden standard for those microscopy formats but I don't feel very comfortable with the java/python bindings (isn't it adding a java dependency, and making platform changes more complex?

I'll make a PR for the tifffile / scikits-plugin integration shortly.

As far as BioFormats and python/java, I think Ray has had the most experience working with this, if he wants to weigh in on that.

Zach




> 
> 
> Guillaume
> 
> 
> 
> Le 10/02/2012 22:20, Christoph Gohlke a ?crit :
>> On 2/10/2012 7:46 AM, Zachary Pincus wrote:
>>>> Indeed metadata are important, thanks for pointing this out, I'll have a look at it (though I find metamorph is not so good at recording good metadata).
>>>> 
>>>> By the way, I have both .stk and .tif images, so I use Christoph Gohlke tifffile.py for the .stk files. Is ther any chance this will be integrated to skimage?
>>> 
>>> Wow! Somehow I was not familiar with Christoph's tifffile.py... that'll be very handy for these cursed LSM files I have laying around. (No help for the ZVIs, but I already have a silly zvi->ome-tiff workflow for them.)
>>> 
>>> Perhaps Christoph, who frequents this list, can weight in on whether it would be a good idea to wrap this in as a skimage IO plugin, or if it's best as a separate project...
>>> 
>>> Zach
>> 
>> A skimage io plugin for tifffile.py is straightforward (attached). The module already implements imread, imsave, and imshow functions. Those functions return/save/show n-dimensional numpy arrays (n>=2). I'm not sure skimage can handle n>3?
>> 
>> Tifffile.py and tifffile.c are BSD licensed, so it is no problem to include them with skimage. I don't think the module itself should be maintained or supported as part of skimage.
>> 
>> 
>> Regarding those cursed, broken, undocumented or NDAed, microscopy file formats:
>> 
>> I'm aware of two other projects that strive to read LSM files: pylibtiff <http://code.google.com/p/pylibtiff/> and pylsm <http://www.freesbi.ch/pylsm>.
>> 
>> How about a plugin for BioFormats <http://loci.wisc.edu/software/bio-formats>, which supports many more formats? The Cellprofiler project contains GPLed bindings <https://svn.broadinstitute.org/CellProfiler/trunk/CellProfiler/bioformats/>.
>> 
>> Christoph
>> 
>> 
>> 
> 
> <guillaume.vcf>



From guillaume at mitotic-machine.org  Mon Feb 13 04:42:57 2012
From: guillaume at mitotic-machine.org (Guillaume Gay)
Date: Mon, 13 Feb 2012 10:42:57 +0100
Subject: Tifffile.py as a plugin vs BioFormats
In-Reply-To: <4F358A15.4080606@gmail.com>
References: <e36f20f0-9e2c-445d-8f7c-4ba9fc1fa3ae@t5g2000yqk.googlegroups.com> <CABDkGQkAo91Ve5gc7UA8tezE4jnm0q7eBuUbp9GZABvTt2Y9MQ@mail.gmail.com> <7812d347-4dfe-45fa-b253-0da6d510d557@w1g2000vbg.googlegroups.com> <CABDkGQkx0HGgYJXo9Vs28b_gUdxPWFNrjDSS0ffvAf5sjSeR6Q@mail.gmail.com> <6A03E059-3B64-4614-83D0-B790B1E8650D@yale.edu> <4F353293.4080808@mitotic-machine.org> <7CFEF0AD-F1D6-4277-8975-36867D8B8D1C@yale.edu> <4F358A15.4080606@gmail.com>
Message-ID: <4F38DB21.1000702@mitotic-machine.org>

Hi,

Thank you Christoph for the suggestion, I think I will use your 
solution, which works fine for me.


Of course BioFormats is kind of the golden standard for those microscopy 
formats but I don't feel very comfortable with the java/python bindings 
(isn't it adding a java dependency, and making platform changes more 
complex?).



Guillaume



Le 10/02/2012 22:20, Christoph Gohlke a ?crit :
> On 2/10/2012 7:46 AM, Zachary Pincus wrote:
>>> Indeed metadata are important, thanks for pointing this out, I'll 
>>> have a look at it (though I find metamorph is not so good at 
>>> recording good metadata).
>>>
>>> By the way, I have both .stk and .tif images, so I use Christoph 
>>> Gohlke tifffile.py for the .stk files. Is ther any chance this will 
>>> be integrated to skimage?
>>
>> Wow! Somehow I was not familiar with Christoph's tifffile.py... 
>> that'll be very handy for these cursed LSM files I have laying 
>> around. (No help for the ZVIs, but I already have a silly 
>> zvi->ome-tiff workflow for them.)
>>
>> Perhaps Christoph, who frequents this list, can weight in on whether 
>> it would be a good idea to wrap this in as a skimage IO plugin, or if 
>> it's best as a separate project...
>>
>> Zach
>
> A skimage io plugin for tifffile.py is straightforward (attached). The 
> module already implements imread, imsave, and imshow functions. Those 
> functions return/save/show n-dimensional numpy arrays (n>=2). I'm not 
> sure skimage can handle n>3?
>
> Tifffile.py and tifffile.c are BSD licensed, so it is no problem to 
> include them with skimage. I don't think the module itself should be 
> maintained or supported as part of skimage.
>
>
> Regarding those cursed, broken, undocumented or NDAed, microscopy file 
> formats:
>
> I'm aware of two other projects that strive to read LSM files: 
> pylibtiff <http://code.google.com/p/pylibtiff/> and pylsm 
> <http://www.freesbi.ch/pylsm>.
>
> How about a plugin for BioFormats 
> <http://loci.wisc.edu/software/bio-formats>, which supports many more 
> formats? The Cellprofiler project contains GPLed bindings 
> <https://svn.broadinstitute.org/CellProfiler/trunk/CellProfiler/bioformats/>.
>
> Christoph
>
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: guillaume.vcf
Type: text/x-vcard
Size: 282 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120213/ccbf6aea/attachment.vcf>

From guillaume at mitotic-machine.org  Mon Feb 13 05:01:42 2012
From: guillaume at mitotic-machine.org (Guillaume Gay)
Date: Mon, 13 Feb 2012 11:01:42 +0100
Subject: Error when building from git
In-Reply-To: <CABDkGQ=XWF4Gbc7DNpOonmuVoHH9Sc=Eq4mdyUGm-qo0FDQ0sQ@mail.gmail.com>
References: <e36f20f0-9e2c-445d-8f7c-4ba9fc1fa3ae@t5g2000yqk.googlegroups.com> <CABDkGQkAo91Ve5gc7UA8tezE4jnm0q7eBuUbp9GZABvTt2Y9MQ@mail.gmail.com> <20120210185857.GB3444@phare.normalesup.org> <20120211113119.445a7227.google@terre-adelie.org> <CABDkGQ=XWF4Gbc7DNpOonmuVoHH9Sc=Eq4mdyUGm-qo0FDQ0sQ@mail.gmail.com>
Message-ID: <4F38DF86.7020106@mitotic-machine.org>

Giving a humble user side perspective here...

I think St?fan is right: if I use the git repository for skimage, I 
shall expect that it depends on the latest versions of the dependencies, 
and not complain about lack of compatibility with the packaged version 
of numpy, for example.

Yet ... somehow I felt I could use the latest version of skimage 
(because there would be for example the latest algorithms implemented) 
without  having to reconsider my whole python environment, notably 
because I am not 100% sure the rest of my code won't suffer. Said 
otherwise numpy is at the root of lots of stuff I'm doing, and skimage 
is closer to the tip. Pushing this a lot, you could say: the user shall 
be ready to compile the latest linux kernel, as they are cloning skimage 
from git....

I guess the equilibrium here is hard to catch.

Guillaume


Le 11/02/2012 23:26, St?fan van der Walt a ?crit :
> 2012/2/11 J?r?me Kieffer<google at terre-adelie.org>:
>> PS: We are currently deploying debian6 (squeeze) at work which should
>> be the reference until end 2013 (at least!) so putting dependency on a
>> too-recent numpy will prevent skimage to be deployed on the beamline.
> I guess the point I was trying to make is that nobody expects SciPy 12
> to work with NumPy 1.5, since they are released at different times.
> If you install scikits-image 0.4, released when NumPy 1.5 was stable,
> you'll get 1.5 compatibility.  The problem only comes in when you
> require the latest functionality--in which case upgrading the package
> + dependencies seems completely reasonable.
>
> If we focus on getting scikits-image packaged in the different
> distros, these problems should more-or-less go away, since people will
> do "apt-get install python-skimage" and be happy with whichever
> version is provided.
>
> St?fan
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: guillaume.vcf
Type: text/x-vcard
Size: 282 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120213/e796b536/attachment.vcf>

From emmanuelle.gouillart at nsup.org  Mon Feb 13 13:47:51 2012
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Mon, 13 Feb 2012 19:47:51 +0100
Subject: dependencies: numpy, matplotlib
In-Reply-To: <CABDkGQnxwX+NtDUDyXBMZbmmADWe2e6c6_PfcZ5Y+00uFOncsA@mail.gmail.com>
References: <e36f20f0-9e2c-445d-8f7c-4ba9fc1fa3ae@t5g2000yqk.googlegroups.com>
 <CABDkGQkAo91Ve5gc7UA8tezE4jnm0q7eBuUbp9GZABvTt2Y9MQ@mail.gmail.com>
 <20120210185857.GB3444@phare.normalesup.org>
 <CABDkGQkqERmOWudUTkL9-oZB6f+8dHdH=7WL7mGjyFwGyb99Ww@mail.gmail.com>
 <20120212105942.GE5452@phare.normalesup.org>
 <CABDkGQnxwX+NtDUDyXBMZbmmADWe2e6c6_PfcZ5Y+00uFOncsA@mail.gmail.com>
Message-ID: <20120213184751.GB9541@phare.normalesup.org>

> That's a very valid point.  And since it's so little effort to remain
> 1.5 compatible, there seems little reason not to.

> I'm the guilty party that suggested the use of a numpy 1.6 call in the
> converter functions--sorry about that!  Chris has kindly made a PR to
> address the issue.

And it works like a charm, as I just tested with my "old" ;-) set-up
(numpy 1.5). Build and tests work fine, the doc builds well, just
perfect! I saw that you've already merged the PR, but I wanted to confirm
that it works fine for me. Thanks Chris, you rock!

> So, let's talk about Matplotlib--can we use version 1 yet?  If not, I
> suggest that we at least copy over 'subplots', because this function
> makes it so much easier to build clean examples.

I think Matplotlib is a smaller issue, since it's only used to build the
doc (am I wrong?), that is, more a developer's than a user's job. And
Matplotlib 1.0.1 is packaged for the latest ubuntu. There is always the
risk that people download an example, try to execute it and are annoyed
by the error they get if they have an older version of matplotlib. If
people start complaining, then we might copy over matplotlib's subplots
and call skimage.subplots. But I think that this wouldn't discourage new
users, contrary to installation problems. Maybe a sentence in the user
guide on how to adapt examples for matplotlib < 1.0 could help, too. So
my opinion is, yes, we could use version 1 now.

Cheers,
Emmanuelle


From yager.neil at gmail.com  Mon Feb 13 23:44:52 2012
From: yager.neil at gmail.com (Neil Yager)
Date: Mon, 13 Feb 2012 20:44:52 -0800 (PST)
Subject: GUI tools and upsizing
Message-ID: <0a962708-d617-45d0-b343-b7e774f23965@b23g2000yqn.googlegroups.com>

Hi everyone,

Two questions:

1. One thing that I think would be very useful is some simple
interactive tools for examining with images. For example, 2 simple
additions to the basic matplotlib's imshow would be to show the pixel
intensity of the current mouse location (it already shows the x, y
coordinates). Also, it would be nice to be able to click at 2 points
and display the profile of intensities between them. Would adding
functionality like this cause too many compatibility issues, or be
moving too far away from skimage's core strength?

2. I'm currently working with large images and it often useful to work
with down-sampled versions. A quick way to do this is using views:

im_small = im[::4, ::4]

Is there a quick way to do the inverse? i.e. something like:

im_big = im[::0.25, ::0.25]

At the moment I'm just resizing the image, which has more overhead.
Anything I'm missing?

Cheers,
Neil


From thouis.jones at curie.fr  Mon Feb 13 16:33:05 2012
From: thouis.jones at curie.fr (Thouis Jones)
Date: Mon, 13 Feb 2012 22:33:05 +0100
Subject: random walker segmentation / blob detection
In-Reply-To: <20120212163145.GD28929@phare.normalesup.org>
References: <27207519.2086.1328618871447.JavaMail.geo-discussion-forums@yqcz12>
 <CABDkGQnLd+sibOQt6JGkL=vWQ++ymXUyX+BaF5q_+w=zhgRj4A@mail.gmail.com>
 <26400884.2838.1328694755524.JavaMail.geo-discussion-forums@vbtr6>
 <20120208134653.GD4628@phare.normalesup.org> <CAHGWWxFKunAkJUVkrokxipqczSN5Sbg8LhDRoenRFHpQP55S5g@mail.gmail.com>
 <11829122.221.1328784249183.JavaMail.geo-discussion-forums@vbev17>
 <CAHGWWxH8B_H6BgjpnFufUnnaPRZHdjDtfe7_5fYjRA7JT43JCg@mail.gmail.com> <20120212163145.GD28929@phare.normalesup.org>
Message-ID: <CAHGWWxH2nMZQk7oEOW_or9xuaLQVgv+Gb__Ke3PZ8TJL1txAFg@mail.gmail.com>

On Sun, Feb 12, 2012 at 17:31, Emmanuelle Gouillart
<emmanuelle.gouillart at nsup.org> wrote:
> Hi Ray,
>
> this segmentation algorithm with supervised learning really seems great!
> I wonder whether we could have a similar algorithm in skimage.
> ilastik.org is down at the moment, so I can't check their license. But
> there is a random forest classifier in scikit-learn that we could re-use.
> A difficult point is the in-painting of pixels on the image; could anyone
> give hints about technical solutions to do this?

It's BSD.  It makes heavy use of Vigra
(http://hci.iwr.uni-heidelberg.de/vigra/doc/vigra/index.html) via
vigranumpy, which can be a bit difficult to build (using CMAKE) in
some cases (like Mac fat binary in a virtualenv).

I doubt it's worth trying to reimplement a painting/labeling UI.  It's
not that hard to get a demonstration version working, but for anything
more serious than toy problems, it will take a fair amount of time, I
think.  Time would be better spent working with the ilastik project on
interoperability, such as scripting its pipeline (already possible, to
some extent) or making it easier to call into their filtering and
classification code as a python module.   CellProfiler already does
this in the ClassifyPixels module:
https://github.com/CellProfiler/CellProfiler/blob/master/cellprofiler/modules/classifypixels.py

Best,
Ray


From stefan at sun.ac.za  Tue Feb 14 03:22:07 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 14 Feb 2012 00:22:07 -0800
Subject: GUI tools and upsizing
In-Reply-To: <0a962708-d617-45d0-b343-b7e774f23965@b23g2000yqn.googlegroups.com>
References: <0a962708-d617-45d0-b343-b7e774f23965@b23g2000yqn.googlegroups.com>
Message-ID: <CABDkGQ=+Ufw8_T95YJdot6oL2yD3r+=0qcO55VZnNR59cnC-zQ@mail.gmail.com>

Hey Neil

On Mon, Feb 13, 2012 at 8:44 PM, Neil Yager <yager.neil at gmail.com> wrote:
> 1. One thing that I think would be very useful is some simple
> interactive tools for examining with images. For example, 2 simple
> additions to the basic matplotlib's imshow would be to show the pixel
> intensity of the current mouse location (it already shows the x, y
> coordinates). Also, it would be nice to be able to click at 2 points
> and display the profile of intensities between them. Would adding
> functionality like this cause too many compatibility issues, or be
> moving too far away from skimage's core strength?

Not at all!  Would you like to update the fancy viewer?  It already
does most of what you want:

from skimage import io, data
io.use_plugin('qt')
io.imshow(data.camera(), fancy=True)

> 2. I'm currently working with large images and it often useful to work
> with down-sampled versions. A quick way to do this is using views:
>
> im_small = im[::4, ::4]
>
> Is there a quick way to do the inverse? i.e. something like:
>
> im_big = im[::0.25, ::0.25]

Emmanuelle's suggestion (to use ndimage.zoom) is the right one.  We
should probably write a wrapper around our fast_homography code,
though, because it yields better results (fewer boundary effects, it's
a bit faster).  Here's a start:

import numpy as np
from skimage import transform, img_as_float

def zoom(image, s):
    H = np.array([[s, 0, 0],
                  [0, s, 0],
                  [0, 0, 1]])
    output_shape = np.ceil(np.array(image.shape) * s)
    image = img_as_float(image)
    return transform.fast_homography(image, H,
                                     output_shape=output_shape)


St?fan


From emmanuelle.gouillart at nsup.org  Tue Feb 14 02:40:24 2012
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Tue, 14 Feb 2012 08:40:24 +0100
Subject: GUI tools and upsizing
In-Reply-To: <0a962708-d617-45d0-b343-b7e774f23965@b23g2000yqn.googlegroups.com>
References: <0a962708-d617-45d0-b343-b7e774f23965@b23g2000yqn.googlegroups.com>
Message-ID: <20120214074024.GA8921@phare.normalesup.org>

Hi Neil,

just answering quickly to your second question (someone will still have
to answer the first one!).

> 2. I'm currently working with large images and it often useful to work
> with down-sampled versions. A quick way to do this is using views:

> im_small = im[::4, ::4]

> Is there a quick way to do the inverse? i.e. something like:

> im_big = im[::0.25, ::0.25]

> At the moment I'm just resizing the image, which has more overhead.
> Anything I'm missing?

I use scipy.ndimage.zoom for this purpose.

Cheers,
Emmanuelle


From yager.neil at gmail.com  Wed Feb 15 00:13:18 2012
From: yager.neil at gmail.com (Neil Yager)
Date: Tue, 14 Feb 2012 21:13:18 -0800 (PST)
Subject: GUI tools and upsizing
In-Reply-To: <CABDkGQ=+Ufw8_T95YJdot6oL2yD3r+=0qcO55VZnNR59cnC-zQ@mail.gmail.com>
References: <0a962708-d617-45d0-b343-b7e774f23965@b23g2000yqn.googlegroups.com>
 <CABDkGQ=+Ufw8_T95YJdot6oL2yD3r+=0qcO55VZnNR59cnC-zQ@mail.gmail.com>
Message-ID: <d1dbbb0f-6ffd-4893-a8e1-97cd41b8a17f@t30g2000vbx.googlegroups.com>

Great - thanks guys. That fancy viewer is much better than what I've
been using. I'll look into extending its functionality even further.

Neil


From tsyu80 at gmail.com  Wed Feb 15 01:01:56 2012
From: tsyu80 at gmail.com (Tony Yu)
Date: Wed, 15 Feb 2012 01:01:56 -0500
Subject: GUI tools and upsizing
In-Reply-To: <CABDkGQ=+Ufw8_T95YJdot6oL2yD3r+=0qcO55VZnNR59cnC-zQ@mail.gmail.com>
References: <0a962708-d617-45d0-b343-b7e774f23965@b23g2000yqn.googlegroups.com>
	<CABDkGQ=+Ufw8_T95YJdot6oL2yD3r+=0qcO55VZnNR59cnC-zQ@mail.gmail.com>
Message-ID: <CAEym_HpksFkS+v9BwAKf+odJT2aQtxjd8cvbZ0yexcR8j9j8fQ@mail.gmail.com>

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

> Hey Neil
>
> On Mon, Feb 13, 2012 at 8:44 PM, Neil Yager <yager.neil at gmail.com> wrote:
> > 1. One thing that I think would be very useful is some simple
> > interactive tools for examining with images. For example, 2 simple
> > additions to the basic matplotlib's imshow would be to show the pixel
> > intensity of the current mouse location (it already shows the x, y
> > coordinates). Also, it would be nice to be able to click at 2 points
> > and display the profile of intensities between them. Would adding
> > functionality like this cause too many compatibility issues, or be
> > moving too far away from skimage's core strength?
>
> Not at all!  Would you like to update the fancy viewer?  It already
> does most of what you want:
>
> from skimage import io, data
> io.use_plugin('qt')
> io.imshow(data.camera(), fancy=True)
>

This is strange: imshow (with or without "fancy") isn't working for me with
the qt backend. Or actually, imread_qt isn't working for me (see traceback
below; also imshow works if I force skimage to use a different imread,
although the window disappears immediately). I'm not really sure how to
debug a MemoryError.

What's weird is that I'm certain I've used the fancy viewer since the
addition of imread_qt (July 2011). I updated (Py)Qt but that didn't help.

-Tony

python(34737,0x7fff70b93cc0) malloc: *** mmap(size=140734799798272) failed
(error co
de=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
Traceback (most recent call last):
  File "qtshow.py", line 9, in <module>
    io.imshow(data.camera(), fancy=True)
  File "/Users/Tony/python/devel/skimage/skimage/data/__init__.py", line
34, in came
ra
    return load("camera.png")
  File "/Users/Tony/python/devel/skimage/skimage/data/__init__.py", line
27, in load

    return imread(_os.path.join(data_dir, f))
  File "/Users/Tony/python/devel/skimage/skimage/io/_io.py", line 72, in
imread
    img = call_plugin('imread', fname, plugin=plugin, **plugin_args)
  File "/Users/Tony/python/devel/skimage/skimage/io/_plugins/plugin.py",
line 88, in
 call
    return func(*args, **kwargs)
  File "/Users/Tony/python/devel/skimage/skimage/io/_plugins/qt_plugin.py",
line 102
, in imread_qt
    img = np.array(arrayptr)
MemoryError
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120215/7e6a10d2/attachment.html>

From bricklemacho at gmail.com  Thu Feb 16 06:32:45 2012
From: bricklemacho at gmail.com (bricklemacho)
Date: Thu, 16 Feb 2012 03:32:45 -0800 (PST)
Subject: Understanding HoG output
In-Reply-To: <CAFkP-qy-TzHD4RsOM1rZVnpB=Gpj=kzCg+0q0JvxjvHvFhuggg@mail.gmail.com>
References: <a9ae03e4-f629-48f0-905e-8e623ffae190@qt7g2000pbc.googlegroups.com>
 <CAFkP-qy-TzHD4RsOM1rZVnpB=Gpj=kzCg+0q0JvxjvHvFhuggg@mail.gmail.com>
Message-ID: <7b53b53d-ff5d-4f38-9ab7-2343c6477cfc@o4g2000pbc.googlegroups.com>



On Feb 10, 9:45?pm, Brian Holt <bdho... at gmail.com> wrote:
<snip>
> A line is drawn for each gradient bin with an intensity proportional to the
> magnitude of that gradient. ?So, the 'star' shape you see for each cell is
> just the superimposition of all of these lines. You should expect to see
> dominant lines perpendicular to lines in the image (parallel to the
> gradient). Also remember that the default is to use 9 bins, so it may be
> that the 45degree dominant line you see is the closest approximation to
> horizontal. ?You can test this out by trying 8 bins instead of 9.

Okay, I am still having problems understanding visualisation of the
HoG.  When I plot the visualisation it seem to make sense.  It is
still not clear why I don't see vertical/perpendicular lines.   If you
look at http://tinypic.com/r/dy0fud/5  I would expect to see the pole
of the street light to show dominant perpendicular lines, but they
appear to be more horizontal than vertical.  Similar stuff happens if
I use buildings, the "edge" of the building, clearly visable in the
gradient images, ends up as either tending towards the  45deg  (or
135deg).   The parameters used for the picture were: Orientations 9,
Pixesl Per Cell16x16, Cells per Block 3x3.

I will trace the code to try to get a better understanding of the
visualisation output, but  would appreciate if anyone has any advice
or explanation of my misunderstanding of the visualisation.

Also what is the best why to link to images in a post?

Thanks,

Michael.
--


From bricklemacho at gmail.com  Thu Feb 16 12:25:02 2012
From: bricklemacho at gmail.com (bricklemacho)
Date: Thu, 16 Feb 2012 09:25:02 -0800 (PST)
Subject: Understanding HoG output
In-Reply-To: <CAFkP-qzb0kRF_mNWLv5rLGGKVVROpVTyWQTuzWp0jBPcEFrZ9Q@mail.gmail.com>
References: <a9ae03e4-f629-48f0-905e-8e623ffae190@qt7g2000pbc.googlegroups.com>
 <CAFkP-qy-TzHD4RsOM1rZVnpB=Gpj=kzCg+0q0JvxjvHvFhuggg@mail.gmail.com>
 <7b53b53d-ff5d-4f38-9ab7-2343c6477cfc@o4g2000pbc.googlegroups.com>
 <CAEym_Hr5umzG55-TRUaAV9piKA5k2RVgsLfYjZysxFvOc3BCCg@mail.gmail.com> <CAFkP-qzb0kRF_mNWLv5rLGGKVVROpVTyWQTuzWp0jBPcEFrZ9Q@mail.gmail.com>
Message-ID: <c4163edc-e0ba-4df5-9b21-d5bcfdef53e4@v6g2000pba.googlegroups.com>

Hi Brian, and Tony.

Thanks both for your response.  I hope my newbie terminology is not
making this more confusing.

> Tony's answer is spot on here. ?Perhaps you expect that the HoG image
> should look like the gradient image? Instead, what the descriptor is
> really aiming to capture is the direction (that's the 'oriented'
> part), that the gradients go. So assuming an image where the left half
> is black and the right half white, there would be a vertical of
> horizontal (or as close as possible, depending on the number of bins)
> lines in the HoG image.

Okay, makes sense, the direction of the change would be horizontal
direction if the line in the orignal image was vertical.   This is how
I originally interpreted the visualisation provide by the skimage-hog
algorithm.

The problem was when I comparing this to the visualisation from the
Dalal & Triggs paper.   In the paper the R-HOG descriptor seems to
show a different relationship, when visualised the dominant
orientations appear to be parallel to lines in the original image.  If
you have access to the Dalal & Triggs paper,  I am basing my
expectations on Figure 6(e), top of page 8.    I don't have access to
the original Dalal & Triggs visualisation code so I will reread the
paper to make sure I am comparing like with like.


> This is what I was referring to when I talked about the number of
> bins. ?If you look carefully at the HoG image, you'll notice that
> there are vertical lines in some places (like at the black billboard),
> but there are no perfectly horizontal lines. ?The closest
> approximation to horizontal is maybe a 20deg line. ?That's because
> there are 9 bins. ?If you tried this with 8 bins, you should see some
> horizontal lines.

If I change play with the bins I do end up with horizontal lines.  I
suspect what is being visualised is different, or being interpreted
differently,  to what the Dala & Triggs paper is visualisation.   I
just have to understand the different visualisations.

Thanks again for your help.

Michael.
--


From tsyu80 at gmail.com  Thu Feb 16 09:53:08 2012
From: tsyu80 at gmail.com (Tony Yu)
Date: Thu, 16 Feb 2012 09:53:08 -0500
Subject: Understanding HoG output
In-Reply-To: <7b53b53d-ff5d-4f38-9ab7-2343c6477cfc@o4g2000pbc.googlegroups.com>
References: <a9ae03e4-f629-48f0-905e-8e623ffae190@qt7g2000pbc.googlegroups.com>
	<CAFkP-qy-TzHD4RsOM1rZVnpB=Gpj=kzCg+0q0JvxjvHvFhuggg@mail.gmail.com>
	<7b53b53d-ff5d-4f38-9ab7-2343c6477cfc@o4g2000pbc.googlegroups.com>
Message-ID: <CAEym_Hr5umzG55-TRUaAV9piKA5k2RVgsLfYjZysxFvOc3BCCg@mail.gmail.com>

On Thu, Feb 16, 2012 at 6:32 AM, bricklemacho <bricklemacho at gmail.com>wrote:

>
>
> On Feb 10, 9:45 pm, Brian Holt <bdho... at gmail.com> wrote:
> <snip>
> > A line is drawn for each gradient bin with an intensity proportional to
> the
> > magnitude of that gradient.  So, the 'star' shape you see for each cell
> is
> > just the superimposition of all of these lines. You should expect to see
> > dominant lines perpendicular to lines in the image (parallel to the
> > gradient). Also remember that the default is to use 9 bins, so it may be
> > that the 45degree dominant line you see is the closest approximation to
> > horizontal.  You can test this out by trying 8 bins instead of 9.
>
> Okay, I am still having problems understanding visualisation of the
> HoG.  When I plot the visualisation it seem to make sense.  It is
> still not clear why I don't see vertical/perpendicular lines.   If you
> look at http://tinypic.com/r/dy0fud/5  I would expect to see the pole
> of the street light to show dominant perpendicular lines, but they
> appear to be more horizontal than vertical.  Similar stuff happens if
> I use buildings, the "edge" of the building, clearly visable in the
> gradient images, ends up as either tending towards the  45deg  (or
> 135deg).   The parameters used for the picture were: Orientations 9,
> Pixesl Per Cell16x16, Cells per Block 3x3.
>


I don't actually understand HoG that well, but this result, I believe, is
expect. Assuming HoG does what the name suggests, you should expect the
lines to align with the direction with the largest gradient. So, if the
pole of the street light is a dark gray, and the background is white, then
the lines should be perpendicular to the pole since this is the direction
of the highest gradient.


>
> I will trace the code to try to get a better understanding of the
> visualisation output, but  would appreciate if anyone has any advice
> or explanation of my misunderstanding of the visualisation.
>
> Also what is the best why to link to images in a post?
>
> Thanks,
>
> Michael.
> --
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120216/240587fb/attachment.html>

From bdholt1 at gmail.com  Thu Feb 16 10:46:10 2012
From: bdholt1 at gmail.com (Brian Holt)
Date: Thu, 16 Feb 2012 15:46:10 +0000
Subject: Understanding HoG output
In-Reply-To: <CAEym_Hr5umzG55-TRUaAV9piKA5k2RVgsLfYjZysxFvOc3BCCg@mail.gmail.com>
References: <a9ae03e4-f629-48f0-905e-8e623ffae190@qt7g2000pbc.googlegroups.com>
	<CAFkP-qy-TzHD4RsOM1rZVnpB=Gpj=kzCg+0q0JvxjvHvFhuggg@mail.gmail.com>
	<7b53b53d-ff5d-4f38-9ab7-2343c6477cfc@o4g2000pbc.googlegroups.com>
	<CAEym_Hr5umzG55-TRUaAV9piKA5k2RVgsLfYjZysxFvOc3BCCg@mail.gmail.com>
Message-ID: <CAFkP-qzb0kRF_mNWLv5rLGGKVVROpVTyWQTuzWp0jBPcEFrZ9Q@mail.gmail.com>

Hi Michael,

>
> I don't actually understand HoG that well, but this result, I believe, is expect. Assuming HoG does what the name suggests, you should expect the lines to align with the direction with the largest gradient. So, if the pole of the street light is a dark gray, and the background is white, then the lines should be perpendicular to the pole since this is the direction of the highest gradient.
>


Tony's answer is spot on here. ?Perhaps you expect that the HoG image
should look like the gradient image? Instead, what the descriptor is
really aiming to capture is the direction (that's the 'oriented'
part), that the gradients go. So assuming an image where the left half
is black and the right half white, there would be a vertical of
horizontal (or as close as possible, depending on the number of bins)
lines in the HoG image.

> I would expect to see the pole?of the street light to show dominant perpendicular lines, but they?appear to be more horizontal than vertical.

This is what I was referring to when I talked about the number of
bins.  If you look carefully at the HoG image, you'll notice that
there are vertical lines in some places (like at the black billboard),
but there are no perfectly horizontal lines.  The closest
approximation to horizontal is maybe a 20deg line.  That's because
there are 9 bins.  If you tried this with 8 bins, you should see some
horizontal lines.

Hope it helps
Brian


From bricklemacho at gmail.com  Fri Feb 17 06:19:20 2012
From: bricklemacho at gmail.com (bricklemacho)
Date: Fri, 17 Feb 2012 03:19:20 -0800 (PST)
Subject: Understanding HoG output
In-Reply-To: <c4163edc-e0ba-4df5-9b21-d5bcfdef53e4@v6g2000pba.googlegroups.com>
References: <a9ae03e4-f629-48f0-905e-8e623ffae190@qt7g2000pbc.googlegroups.com>
 <CAFkP-qy-TzHD4RsOM1rZVnpB=Gpj=kzCg+0q0JvxjvHvFhuggg@mail.gmail.com>
 <7b53b53d-ff5d-4f38-9ab7-2343c6477cfc@o4g2000pbc.googlegroups.com>
 <CAEym_Hr5umzG55-TRUaAV9piKA5k2RVgsLfYjZysxFvOc3BCCg@mail.gmail.com>
 <CAFkP-qzb0kRF_mNWLv5rLGGKVVROpVTyWQTuzWp0jBPcEFrZ9Q@mail.gmail.com> <c4163edc-e0ba-4df5-9b21-d5bcfdef53e4@v6g2000pba.googlegroups.com>
Message-ID: <4b545925-a428-46ab-812f-5c26a199b4d8@n8g2000pbc.googlegroups.com>

Thought I would follow up.  I have sorted out the visualisation
expectations.  I have been able to modify the visualisation output/
plot of the D&T paper. SOme simple maths can make the orientations
"parallel" if I so desire.    It also appears that the D&T paper plot
the orientations after block normalisation which also accounts for why
I was seeing different in gradients.  Anyway, I have a better
understanding now, so thanks everyone for your help.

Now to work out how to calculate HoG descriptor for a region rather
than a whole image.

Michael.
--


From bdholt1 at gmail.com  Fri Feb 17 06:27:11 2012
From: bdholt1 at gmail.com (Brian Holt)
Date: Fri, 17 Feb 2012 11:27:11 +0000
Subject: Understanding HoG output
In-Reply-To: <4b545925-a428-46ab-812f-5c26a199b4d8@n8g2000pbc.googlegroups.com>
References: <a9ae03e4-f629-48f0-905e-8e623ffae190@qt7g2000pbc.googlegroups.com>
  <CAFkP-qy-TzHD4RsOM1rZVnpB=Gpj=kzCg+0q0JvxjvHvFhuggg@mail.gmail.com>
  <7b53b53d-ff5d-4f38-9ab7-2343c6477cfc@o4g2000pbc.googlegroups.com>
  <CAEym_Hr5umzG55-TRUaAV9piKA5k2RVgsLfYjZysxFvOc3BCCg@mail.gmail.com>
  <CAFkP-qzb0kRF_mNWLv5rLGGKVVROpVTyWQTuzWp0jBPcEFrZ9Q@mail.gmail.com>
  <c4163edc-e0ba-4df5-9b21-d5bcfdef53e4@v6g2000pba.googlegroups.com>
  <4b545925-a428-46ab-812f-5c26a199b4d8@n8g2000pbc.googlegroups.com>
Message-ID: <284925131-1329478032-cardhu_decombobulator_blackberry.rim.net-1033964168-@b11.c4.bise7.blackberry>

Hi Michael,

I'm glad you've got it all sorted out. 

An issue report has been raised regarding the HoG around a point (actually a list of points). It seems to me that there are 2 options. 

1 we could compute the HoG over the whole image and then copy the descriptor values around a given point and return. This requires very little change to the existing code, but will be inefficient for those only requiring sparse keypoints.

2 move the heavy lifting into another function and call it on small image patches. Good for sparse keypoints, bad for dense.  

So it depends on what you want really. Quick win is number 1.

Cheers
Brian

-----Original Message-----
From: bricklemacho <bricklemacho at gmail.com>
Sender: scikits-image at googlegroups.com
Date: Fri, 17 Feb 2012 03:19:20 
To: scikits-image<scikits-image at googlegroups.com>
Reply-To: scikits-image at googlegroups.com
Subject: Re: Understanding HoG output

Thought I would follow up.  I have sorted out the visualisation
expectations.  I have been able to modify the visualisation output/
plot of the D&T paper. SOme simple maths can make the orientations
"parallel" if I so desire.    It also appears that the D&T paper plot
the orientations after block normalisation which also accounts for why
I was seeing different in gradients.  Anyway, I have a better
understanding now, so thanks everyone for your help.

Now to work out how to calculate HoG descriptor for a region rather
than a whole image.

Michael.
--

From guillaume at mitotic-machine.org  Fri Feb 17 09:53:01 2012
From: guillaume at mitotic-machine.org (Guillaume Gay)
Date: Fri, 17 Feb 2012 15:53:01 +0100
Subject: GUI tools and upsizing
In-Reply-To: <0a962708-d617-45d0-b343-b7e774f23965@b23g2000yqn.googlegroups.com>
References: <0a962708-d617-45d0-b343-b7e774f23965@b23g2000yqn.googlegroups.com>
Message-ID: <4F3E69CD.3010204@mitotic-machine.org>

Le 14/02/2012 05:44, Neil Yager a ?crit :
> Hi everyone,
>
> Two questions:
>
> 1. One thing that I think would be very useful is some simple
> interactive tools for examining with images. For example, 2 simple
> additions to the basic matplotlib's imshow would be to show the pixel
> intensity of the current mouse location (it already shows the x, y
> coordinates). Also, it would be nice to be able to click at 2 points
> and display the profile of intensities between them. Would adding
> functionality like this cause too many compatibility issues, or be
> moving too far away from skimage's core strength?
Hello,

I just happen to code a simple linescan function, if that helps...

Guillaume


>
> 2. I'm currently working with large images and it often useful to work
> with down-sampled versions. A quick way to do this is using views:
>
> im_small = im[::4, ::4]
>
> Is there a quick way to do the inverse? i.e. something like:
>
> im_big = im[::0.25, ::0.25]
>
> At the moment I'm just resizing the image, which has more overhead.
> Anything I'm missing?
>
> Cheers,
> Neil
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: linescan.py
Type: text/x-python
Size: 2003 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120217/425ad1e7/attachment.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: guillaume.vcf
Type: text/x-vcard
Size: 282 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120217/425ad1e7/attachment.vcf>

From stefan at sun.ac.za  Mon Feb 20 02:03:11 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 19 Feb 2012 23:03:11 -0800
Subject: GUI tools and upsizing
In-Reply-To: <CAEym_HpksFkS+v9BwAKf+odJT2aQtxjd8cvbZ0yexcR8j9j8fQ@mail.gmail.com>
References: <0a962708-d617-45d0-b343-b7e774f23965@b23g2000yqn.googlegroups.com>
 <CABDkGQ=+Ufw8_T95YJdot6oL2yD3r+=0qcO55VZnNR59cnC-zQ@mail.gmail.com> <CAEym_HpksFkS+v9BwAKf+odJT2aQtxjd8cvbZ0yexcR8j9j8fQ@mail.gmail.com>
Message-ID: <CABDkGQm1wT9dHVfuR6YejQak-FrexZByDQtxD8OmCH2i3yXTWw@mail.gmail.com>

Hey, Tony

On Tue, Feb 14, 2012 at 10:01 PM, Tony Yu <tsyu80 at gmail.com> wrote:
> What's weird is that I'm certain?I've used the fancy viewer since the
> addition of imread_qt (July 2011). I updated (Py)Qt but that didn't help.

What version of Qt are you running?

St?fan


From stefan at sun.ac.za  Mon Feb 20 02:04:51 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 19 Feb 2012 23:04:51 -0800
Subject: GUI tools and upsizing
In-Reply-To: <4F3E69CD.3010204@mitotic-machine.org>
References: <0a962708-d617-45d0-b343-b7e774f23965@b23g2000yqn.googlegroups.com>
 <4F3E69CD.3010204@mitotic-machine.org>
Message-ID: <CABDkGQ=wtY52bPL5+mpuN6t79uG5YKvie2sCD1z54gN+wNm1TA@mail.gmail.com>

On Fri, Feb 17, 2012 at 6:53 AM, Guillaume Gay
<guillaume at mitotic-machine.org> wrote:
> I just happen to code a simple linescan function, if that helps...

Thanks, Guillaume!  If you could integrate this with the fancy Qt
imshow to display the line, that would be wonderful, but otherwise I'm
sure we'll still be able to use this code.

St?fan


From tsyu80 at gmail.com  Mon Feb 20 10:53:54 2012
From: tsyu80 at gmail.com (Tony Yu)
Date: Mon, 20 Feb 2012 10:53:54 -0500
Subject: GUI tools and upsizing
In-Reply-To: <CABDkGQm1wT9dHVfuR6YejQak-FrexZByDQtxD8OmCH2i3yXTWw@mail.gmail.com>
References: <0a962708-d617-45d0-b343-b7e774f23965@b23g2000yqn.googlegroups.com>
	<CABDkGQ=+Ufw8_T95YJdot6oL2yD3r+=0qcO55VZnNR59cnC-zQ@mail.gmail.com>
	<CAEym_HpksFkS+v9BwAKf+odJT2aQtxjd8cvbZ0yexcR8j9j8fQ@mail.gmail.com>
	<CABDkGQm1wT9dHVfuR6YejQak-FrexZByDQtxD8OmCH2i3yXTWw@mail.gmail.com>
Message-ID: <CAEym_Hpw+zfyDwCTNXTeNRekJJxXB7Raq3MOjyB3M+6foEchUQ@mail.gmail.com>

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

> Hey, Tony
>
> On Tue, Feb 14, 2012 at 10:01 PM, Tony Yu <tsyu80 at gmail.com> wrote:
> > What's weird is that I'm certain I've used the fancy viewer since the
> > addition of imread_qt (July 2011). I updated (Py)Qt but that didn't help.
>
> What version of Qt are you running?
>
> I'm running Qt 4.8.0 and PyQt 4.9.1. Before upgrading, I was running Qt
4.7.3 and PyQt 4.8.4. Both setups failed.

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

From guillaume at mitotic-machine.org  Mon Feb 20 06:11:16 2012
From: guillaume at mitotic-machine.org (Guillaume Gay)
Date: Mon, 20 Feb 2012 12:11:16 +0100
Subject: GUI tools and upsizing
In-Reply-To: <CABDkGQ=wtY52bPL5+mpuN6t79uG5YKvie2sCD1z54gN+wNm1TA@mail.gmail.com>
References: <0a962708-d617-45d0-b343-b7e774f23965@b23g2000yqn.googlegroups.com> <4F3E69CD.3010204@mitotic-machine.org> <CABDkGQ=wtY52bPL5+mpuN6t79uG5YKvie2sCD1z54gN+wNm1TA@mail.gmail.com>
Message-ID: <4F422A54.9000902@mitotic-machine.org>

Ok, I can give it a try...

Some questions then:

- skivi is pure Qt, so must I keep it that way (no matplotlib dependency)?
- skivi is good for RGB images, but not so much for greyscale... Also 
data conversion from uint16 to uint8 turns everything black (it set 
anything > 256 to 0), shall this be corrected?
-Christoph Gohlke tifffile.imshow() is somehow closer to what us 
microscopy guys are expecting (more suitable for those greyscale 
multipage tiffs), though some features of the fancy viewer such as the 
contrast settings, are great. Also it is a pure matplotlib 
implementation and the intensity value reading is already there. So my 
question is:
Are those tools needed by the general image analysis skimage community 
are more by scientific tiff users? If the latest, my guess is that 
building on top of matplotlib and Christoph's implementation of imshow 
is a better tactic (plus it would be more cross platform, as this can be 
a widget irrespective of the backend).

Cheers,

Guillaume




Le 20/02/2012 08:04, St?fan van der Walt a ?crit :
> On Fri, Feb 17, 2012 at 6:53 AM, Guillaume Gay
> <guillaume at mitotic-machine.org>  wrote:
>> I just happen to code a simple linescan function, if that helps...
> Thanks, Guillaume!  If you could integrate this with the fancy Qt
> imshow to display the line, that would be wonderful, but otherwise I'm
> sure we'll still be able to use this code.
>
> St?fan
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: guillaume.vcf
Type: text/x-vcard
Size: 282 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120220/73195a84/attachment.vcf>

From yager.neil at gmail.com  Tue Feb 21 02:04:33 2012
From: yager.neil at gmail.com (Neil Yager)
Date: Mon, 20 Feb 2012 23:04:33 -0800 (PST)
Subject: GUI tools and upsizing
In-Reply-To: <4F422A54.9000902@mitotic-machine.org>
References: <0a962708-d617-45d0-b343-b7e774f23965@b23g2000yqn.googlegroups.com>
 <4F3E69CD.3010204@mitotic-machine.org> <CABDkGQ=wtY52bPL5+mpuN6t79uG5YKvie2sCD1z54gN+wNm1TA@mail.gmail.com>
 <4F422A54.9000902@mitotic-machine.org>
Message-ID: <2ba68dd0-e4bc-443f-af29-1587f06d5ef4@o6g2000vbz.googlegroups.com>

I agree that there are some benefits of both viewers. However, I work
a lot with 16-bit greyscale, and I like the pan & zoom of the
matplotlib-based viewer. Therefore, I've found myself using the
TIFFFile one more lately. Adding the line profile & some contrast
adjustment to this viewer would be great.

Neil

On Feb 20, 11:11?am, Guillaume Gay <guilla... at mitotic-machine.org>
wrote:
> Ok, I can give it a try...
>
> Some questions then:
>
> - skivi is pure Qt, so must I keep it that way (no matplotlib dependency)?
> - skivi is good for RGB images, but not so much for greyscale... Also
> data conversion from uint16 to uint8 turns everything black (it set
> anything > 256 to 0), shall this be corrected?
> -Christoph Gohlke tifffile.imshow() is somehow closer to what us
> microscopy guys are expecting (more suitable for those greyscale
> multipage tiffs), though some features of the fancy viewer such as the
> contrast settings, are great. Also it is a pure matplotlib
> implementation and the intensity value reading is already there. So my
> question is:
> Are those tools needed by the general image analysis skimage community
> are more by scientific tiff users? If the latest, my guess is that
> building on top of matplotlib and Christoph's implementation of imshow
> is a better tactic (plus it would be more cross platform, as this can be
> a widget irrespective of the backend).
>
> Cheers,
>
> Guillaume
>
> Le 20/02/2012 08:04, St?fan van der Walt a ?crit :
>
>
>
>
>
>
>
> > On Fri, Feb 17, 2012 at 6:53 AM, Guillaume Gay
> > <guilla... at mitotic-machine.org> ?wrote:
> >> I just happen to code a simple linescan function, if that helps...
> > Thanks, Guillaume! ?If you could integrate this with the fancy Qt
> > imshow to display the line, that would be wonderful, but otherwise I'm
> > sure we'll still be able to use this code.
>
> > St?fan
>
>
>
> ?guillaume.vcf
> < 1KViewDownload


From guillaume at mitotic-machine.org  Tue Feb 21 03:05:09 2012
From: guillaume at mitotic-machine.org (Guillaume Gay)
Date: Tue, 21 Feb 2012 09:05:09 +0100
Subject: GUI tools and upsizing
In-Reply-To: <2ba68dd0-e4bc-443f-af29-1587f06d5ef4@o6g2000vbz.googlegroups.com>
References: <0a962708-d617-45d0-b343-b7e774f23965@b23g2000yqn.googlegroups.com> <4F3E69CD.3010204@mitotic-machine.org> <CABDkGQ=wtY52bPL5+mpuN6t79uG5YKvie2sCD1z54gN+wNm1TA@mail.gmail.com> <4F422A54.9000902@mitotic-machine.org> <2ba68dd0-e4bc-443f-af29-1587f06d5ef4@o6g2000vbz.googlegroups.com>
Message-ID: <4F435035.9010006@mitotic-machine.org>

Ok, sounds good to me too, if nobody objects...


Guillaume

Le 21/02/2012 08:04, Neil Yager a ?crit :
> I agree that there are some benefits of both viewers. However, I work
> a lot with 16-bit greyscale, and I like the pan&  zoom of the
> matplotlib-based viewer. Therefore, I've found myself using the
> TIFFFile one more lately. Adding the line profile&  some contrast
> adjustment to this viewer would be great.
>
> Neil
>
> On Feb 20, 11:11 am, Guillaume Gay<guilla... at mitotic-machine.org>
> wrote:
>> Ok, I can give it a try...
>>
>> Some questions then:
>>
>> - skivi is pure Qt, so must I keep it that way (no matplotlib dependency)?
>> - skivi is good for RGB images, but not so much for greyscale... Also
>> data conversion from uint16 to uint8 turns everything black (it set
>> anything>  256 to 0), shall this be corrected?
>> -Christoph Gohlke tifffile.imshow() is somehow closer to what us
>> microscopy guys are expecting (more suitable for those greyscale
>> multipage tiffs), though some features of the fancy viewer such as the
>> contrast settings, are great. Also it is a pure matplotlib
>> implementation and the intensity value reading is already there. So my
>> question is:
>> Are those tools needed by the general image analysis skimage community
>> are more by scientific tiff users? If the latest, my guess is that
>> building on top of matplotlib and Christoph's implementation of imshow
>> is a better tactic (plus it would be more cross platform, as this can be
>> a widget irrespective of the backend).
>>
>> Cheers,
>>
>> Guillaume
>>
>> Le 20/02/2012 08:04, St?fan van der Walt a ?crit :
>>
>>
>>
>>
>>
>>
>>
>>> On Fri, Feb 17, 2012 at 6:53 AM, Guillaume Gay
>>> <guilla... at mitotic-machine.org>    wrote:
>>>> I just happen to code a simple linescan function, if that helps...
>>> Thanks, Guillaume!  If you could integrate this with the fancy Qt
>>> imshow to display the line, that would be wonderful, but otherwise I'm
>>> sure we'll still be able to use this code.
>>> St?fan
>>
>>
>>   guillaume.vcf
>> <  1KViewDownload

-------------- next part --------------
A non-text attachment was scrubbed...
Name: guillaume.vcf
Type: text/x-vcard
Size: 282 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120221/f8cbf99c/attachment.vcf>

From stefan at sun.ac.za  Tue Feb 21 16:17:14 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 21 Feb 2012 13:17:14 -0800
Subject: GUI tools and upsizing
In-Reply-To: <2ba68dd0-e4bc-443f-af29-1587f06d5ef4@o6g2000vbz.googlegroups.com>
References: <0a962708-d617-45d0-b343-b7e774f23965@b23g2000yqn.googlegroups.com>
 <4F3E69CD.3010204@mitotic-machine.org> <CABDkGQ=wtY52bPL5+mpuN6t79uG5YKvie2sCD1z54gN+wNm1TA@mail.gmail.com>
 <4F422A54.9000902@mitotic-machine.org> <2ba68dd0-e4bc-443f-af29-1587f06d5ef4@o6g2000vbz.googlegroups.com>
Message-ID: <CABDkGQkdXcYiYkkMpDFXt5RfAe_PcvNUKZm4t1cYcW3zWWfnQQ@mail.gmail.com>

On Mon, Feb 20, 2012 at 11:04 PM, Neil Yager <yager.neil at gmail.com> wrote:
> I agree that there are some benefits of both viewers. However, I work
> a lot with 16-bit greyscale, and I like the pan & zoom of the
> matplotlib-based viewer. Therefore, I've found myself using the
> TIFFFile one more lately. Adding the line profile & some contrast
> adjustment to this viewer would be great.

If you can improve the matplotlib version of imshow, that would be
much appreciated.  Let me know if you need a hand with anything.  The
source is in:

skimage/io/_plugins/matplotlib_plugin.py

Currently it just sets interpolation to 'nearest' and 'cmap' to gray
by default (behaviour that is important to keep).

St?fan


From stefan at sun.ac.za  Tue Feb 21 17:38:28 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 21 Feb 2012 14:38:28 -0800
Subject: GUI tools and upsizing
In-Reply-To: <CAEym_HoZjz-C4F_vrTF0-L5eop2Kuj=1Ubd9+ndHqiO5VUGbvA@mail.gmail.com>
References: <0a962708-d617-45d0-b343-b7e774f23965@b23g2000yqn.googlegroups.com>
 <4F3E69CD.3010204@mitotic-machine.org> <CABDkGQ=wtY52bPL5+mpuN6t79uG5YKvie2sCD1z54gN+wNm1TA@mail.gmail.com>
 <4F422A54.9000902@mitotic-machine.org> <2ba68dd0-e4bc-443f-af29-1587f06d5ef4@o6g2000vbz.googlegroups.com>
 <CABDkGQkdXcYiYkkMpDFXt5RfAe_PcvNUKZm4t1cYcW3zWWfnQQ@mail.gmail.com>
 <11BC8A63-181F-4668-89D6-11D0445EA1AB@yale.edu> <CAEym_HoZjz-C4F_vrTF0-L5eop2Kuj=1Ubd9+ndHqiO5VUGbvA@mail.gmail.com>
Message-ID: <CABDkGQn6Aq7cEkSJ_QHVWjJbDpfuKhioYABJ-xkFJMGArTCrDg@mail.gmail.com>

On Tue, Feb 21, 2012 at 2:23 PM, Tony Yu <tsyu80 at gmail.com> wrote:
> I haven't really been following this discussion closely, but the TIFFFile
> viewer isn't actually TIFF-specific, is it? If not, it should probably be
> either integrated with the matplotlib plugin or set as an optional interface
> to matplotlib plugin using a "fancy" parameter (like the one for the qt
> plugin).

Yes, I think doing it as part of the Matplotlib plugin makes most sense.

St?fan


From zachary.pincus at yale.edu  Tue Feb 21 16:22:14 2012
From: zachary.pincus at yale.edu (Zachary Pincus)
Date: Tue, 21 Feb 2012 16:22:14 -0500
Subject: GUI tools and upsizing
In-Reply-To: <CABDkGQkdXcYiYkkMpDFXt5RfAe_PcvNUKZm4t1cYcW3zWWfnQQ@mail.gmail.com>
References: <0a962708-d617-45d0-b343-b7e774f23965@b23g2000yqn.googlegroups.com> <4F3E69CD.3010204@mitotic-machine.org> <CABDkGQ=wtY52bPL5+mpuN6t79uG5YKvie2sCD1z54gN+wNm1TA@mail.gmail.com> <4F422A54.9000902@mitotic-machine.org> <2ba68dd0-e4bc-443f-af29-1587f06d5ef4@o6g2000vbz.googlegroups.com> <CABDkGQkdXcYiYkkMpDFXt5RfAe_PcvNUKZm4t1cYcW3zWWfnQQ@mail.gmail.com>
Message-ID: <11BC8A63-181F-4668-89D6-11D0445EA1AB@yale.edu>

On Feb 21, 2012, at 4:17 PM, St?fan van der Walt wrote:

> On Mon, Feb 20, 2012 at 11:04 PM, Neil Yager <yager.neil at gmail.com> wrote:
>> I agree that there are some benefits of both viewers. However, I work
>> a lot with 16-bit greyscale, and I like the pan & zoom of the
>> matplotlib-based viewer. Therefore, I've found myself using the
>> TIFFFile one more lately. Adding the line profile & some contrast
>> adjustment to this viewer would be great.
> 
> If you can improve the matplotlib version of imshow, that would be
> much appreciated.  Let me know if you need a hand with anything.  The
> source is in:
> 
> skimage/io/_plugins/matplotlib_plugin.py
> 
> Currently it just sets interpolation to 'nearest' and 'cmap' to gray
> by default (behaviour that is important to keep).

The tifffile one actually seems pretty feature-rich. I'm not sure best how to incproprate it into the tifffile skimage plugin, or if maybe it should just live side-by-side as another matplotlib plugin.

The problem with having it as a part of the tifffile IO plugin is that the plugin.ini file would have to state that it provides an imshow(), but the plugin itself would then either have to stub out imshow() if matplotlib (required for the tifffile imshow) is not present, or not provide imshow() in the first place in this case. Any thoughts? 

Zach



From tsyu80 at gmail.com  Tue Feb 21 17:23:10 2012
From: tsyu80 at gmail.com (Tony Yu)
Date: Tue, 21 Feb 2012 17:23:10 -0500
Subject: GUI tools and upsizing
In-Reply-To: <11BC8A63-181F-4668-89D6-11D0445EA1AB@yale.edu>
References: <0a962708-d617-45d0-b343-b7e774f23965@b23g2000yqn.googlegroups.com>
	<4F3E69CD.3010204@mitotic-machine.org>
	<CABDkGQ=wtY52bPL5+mpuN6t79uG5YKvie2sCD1z54gN+wNm1TA@mail.gmail.com>
	<4F422A54.9000902@mitotic-machine.org>
	<2ba68dd0-e4bc-443f-af29-1587f06d5ef4@o6g2000vbz.googlegroups.com>
	<CABDkGQkdXcYiYkkMpDFXt5RfAe_PcvNUKZm4t1cYcW3zWWfnQQ@mail.gmail.com>
	<11BC8A63-181F-4668-89D6-11D0445EA1AB@yale.edu>
Message-ID: <CAEym_HoZjz-C4F_vrTF0-L5eop2Kuj=1Ubd9+ndHqiO5VUGbvA@mail.gmail.com>

On Tue, Feb 21, 2012 at 4:22 PM, Zachary Pincus <zachary.pincus at yale.edu>wrote:

> On Feb 21, 2012, at 4:17 PM, St?fan van der Walt wrote:
>
> > On Mon, Feb 20, 2012 at 11:04 PM, Neil Yager <yager.neil at gmail.com>
> wrote:
> >> I agree that there are some benefits of both viewers. However, I work
> >> a lot with 16-bit greyscale, and I like the pan & zoom of the
> >> matplotlib-based viewer. Therefore, I've found myself using the
> >> TIFFFile one more lately. Adding the line profile & some contrast
> >> adjustment to this viewer would be great.
> >
> > If you can improve the matplotlib version of imshow, that would be
> > much appreciated.  Let me know if you need a hand with anything.  The
> > source is in:
> >
> > skimage/io/_plugins/matplotlib_plugin.py
> >
> > Currently it just sets interpolation to 'nearest' and 'cmap' to gray
> > by default (behaviour that is important to keep).
>
> The tifffile one actually seems pretty feature-rich. I'm not sure best how
> to incproprate it into the tifffile skimage plugin, or if maybe it should
> just live side-by-side as another matplotlib plugin.
>
> The problem with having it as a part of the tifffile IO plugin is that the
> plugin.ini file would have to state that it provides an imshow(), but the
> plugin itself would then either have to stub out imshow() if matplotlib
> (required for the tifffile imshow) is not present, or not provide imshow()
> in the first place in this case. Any thoughts?
>
> Zach
>
>
I haven't really been following this discussion closely, but the TIFFFile
viewer isn't actually TIFF-specific, is it? If not, it should probably be
either integrated with the matplotlib plugin or set as an optional
interface to matplotlib plugin using a "fancy" parameter (like the one for
the qt plugin).

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

From siggin at gmail.com  Wed Feb 22 09:37:42 2012
From: siggin at gmail.com (Sigmund)
Date: Wed, 22 Feb 2012 06:37:42 -0800 (PST)
Subject: Object detection
Message-ID: <7611871.8019.1329921462637.JavaMail.geo-discussion-forums@ynbo36>

Dear Group,

I'm trying to do object detecting on images as shown on the end of the post.
I tried to adapt the coin example in the gallery but the results are not 
good.
My problem is that both the background (bg) and the objects have large 
variations in there gray value.
By the way, these are tiny little ice spheres (30-100 microns)
A second approach was to do a laplace filter and threshold the result but 
even there, the variability is to big (see below).

Well, before I change the measurement technique (change bg) or start 
working on sorting out which group of segments form a sphere,
I thought, I better ask some adepts in image processing if there is an 
easier way. 

Thanks in advance!
Siggi

<https://lh3.googleusercontent.com/-PeS-7pVfM6Y/T0T09jyQD5I/AAAAAAAAADs/s3N1rF32bv8/s1600/005_crop.jpg>
<https://lh4.googleusercontent.com/-xhi_BdlNmS0/T0T5Mc56y8I/AAAAAAAAAD4/XRALl1uBnHA/s1600/random.png>

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

From zachary.pincus at yale.edu  Wed Feb 22 08:45:52 2012
From: zachary.pincus at yale.edu (Zachary Pincus)
Date: Wed, 22 Feb 2012 08:45:52 -0500
Subject: GUI tools and upsizing
In-Reply-To: <CABDkGQn6Aq7cEkSJ_QHVWjJbDpfuKhioYABJ-xkFJMGArTCrDg@mail.gmail.com>
References: <0a962708-d617-45d0-b343-b7e774f23965@b23g2000yqn.googlegroups.com> <4F3E69CD.3010204@mitotic-machine.org> <CABDkGQ=wtY52bPL5+mpuN6t79uG5YKvie2sCD1z54gN+wNm1TA@mail.gmail.com> <4F422A54.9000902@mitotic-machine.org> <2ba68dd0-e4bc-443f-af29-1587f06d5ef4@o6g2000vbz.googlegroups.com> <CABDkGQkdXcYiYkkMpDFXt5RfAe_PcvNUKZm4t1cYcW3zWWfnQQ@mail.gmail.com> <11BC8A63-181F-4668-89D6-11D0445EA1AB@yale.edu> <CAEym_HoZjz-C4F_vrTF0-L5eop2Kuj=1Ubd9+ndHqiO5VUGbvA@mail.gmail.com> <CABDkGQn6Aq7cEkSJ_QHVWjJbDpfuKhioYABJ-xkFJMGArTCrDg@mail.gmail.com>
Message-ID: <AFB8533F-4767-42E8-BF7F-3117F9FC1256@yale.edu>

> On Tue, Feb 21, 2012 at 2:23 PM, Tony Yu <tsyu80 at gmail.com> wrote:
>> I haven't really been following this discussion closely, but the TIFFFile
>> viewer isn't actually TIFF-specific, is it? If not, it should probably be
>> either integrated with the matplotlib plugin or set as an optional interface
>> to matplotlib plugin using a "fancy" parameter (like the one for the qt
>> plugin).
> 
> Yes, I think doing it as part of the Matplotlib plugin makes most sense.

OK, I've merged the tifffile IO plugin; as I'm no expert on the GUI display side, I'll leave it to someone else to port over the improved imshow that tifffile provides...

Zach



From stefan at sun.ac.za  Wed Feb 22 15:08:41 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 22 Feb 2012 12:08:41 -0800
Subject: Object detection
In-Reply-To: <7611871.8019.1329921462637.JavaMail.geo-discussion-forums@ynbo36>
References: <7611871.8019.1329921462637.JavaMail.geo-discussion-forums@ynbo36>
Message-ID: <CABDkGQmKdPxV2BM-6dcSOBOJ9JOYwofmEMriK=tdYDosJ5pn7Q@mail.gmail.com>

Hi Siggi

On Wed, Feb 22, 2012 at 6:37 AM, Sigmund <siggin at gmail.com> wrote:
> I'm trying to do object detecting on images as shown on the end of the post.
> I tried to adapt the coin example in the gallery but the results are not good.
> My problem is that both the background (bg) and the objects have large variations in there gray value.
> By the way, these are tiny little ice spheres (30-100 microns)
> A second approach was to do a laplace filter and threshold the result but even there, the variability is to big (see below).

Could you describe what kind of information you'd like to extract from
the image?  A simple thresholding (foreground vs background),
identification of individual objects, etc.?

St?fan


From amueller at ais.uni-bonn.de  Wed Feb 22 15:47:27 2012
From: amueller at ais.uni-bonn.de (Andreas)
Date: Wed, 22 Feb 2012 21:47:27 +0100
Subject: Object detection
In-Reply-To: <7611871.8019.1329921462637.JavaMail.geo-discussion-forums@ynbo36>
References: <7611871.8019.1329921462637.JavaMail.geo-discussion-forums@ynbo36>
Message-ID: <4F45545F.3060803@ais.uni-bonn.de>

Hi Siggi.
As I understand your task, you are trying to get bounding boxes for each 
ball.
Is that correct?
I am not so familiar with this kind of task but it seems to me a 
template matching approach
could be good.
If a gray-scale template doesn't work, maybe on the laplacian or the 
gradient?

Cheers,
Andy


From siggin at gmail.com  Thu Feb 23 09:30:47 2012
From: siggin at gmail.com (Sigmund)
Date: Thu, 23 Feb 2012 06:30:47 -0800 (PST)
Subject: Object detection
In-Reply-To: <7611871.8019.1329921462637.JavaMail.geo-discussion-forums@ynbo36>
References: <7611871.8019.1329921462637.JavaMail.geo-discussion-forums@ynbo36>
Message-ID: <3024433.1547.1330007447131.JavaMail.geo-discussion-forums@vbfm8>

Hi,

like Andy suggested, I need the bonding box for each shear. This should 
represent the diameter in 
good approximation what leads to the grain size distribution.

Thanks for your help! 
Siggi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120223/65b9149b/attachment.html>

From zachary.pincus at yale.edu  Thu Feb 23 10:02:55 2012
From: zachary.pincus at yale.edu (Zachary Pincus)
Date: Thu, 23 Feb 2012 10:02:55 -0500
Subject: Object detection
In-Reply-To: <3024433.1547.1330007447131.JavaMail.geo-discussion-forums@vbfm8>
References: <7611871.8019.1329921462637.JavaMail.geo-discussion-forums@ynbo36> <3024433.1547.1330007447131.JavaMail.geo-discussion-forums@vbfm8>
Message-ID: <3289EF3F-05E8-4C8B-A15C-41B2B9FE1EBD@yale.edu>

Hi Siggi,

> like Andy suggested, I need the bonding box for each shear. This should represent the diameter in 
> good approximation what leads to the grain size distribution.

In this case I'd also agree with Andy that a template-matching approach might be best, with a library of templates of different sizes. Then for each template-match peak, determine which size template gives the best match, and read out the size distribution from that?

Alternately, you could look at a Hough-circles sort of approach, and again could read off the size distribution straight from the Hough-transformed image. 

Zach


From tsyu80 at gmail.com  Thu Feb 23 10:57:20 2012
From: tsyu80 at gmail.com (Tony Yu)
Date: Thu, 23 Feb 2012 10:57:20 -0500
Subject: Object detection
In-Reply-To: <3289EF3F-05E8-4C8B-A15C-41B2B9FE1EBD@yale.edu>
References: <7611871.8019.1329921462637.JavaMail.geo-discussion-forums@ynbo36>
	<3024433.1547.1330007447131.JavaMail.geo-discussion-forums@vbfm8>
	<3289EF3F-05E8-4C8B-A15C-41B2B9FE1EBD@yale.edu>
Message-ID: <CAEym_HoXJKCHP7a=T1OsdBsr9uo_VgdxXXbnd5ew=Ro1nu6F2A@mail.gmail.com>

On Thu, Feb 23, 2012 at 10:02 AM, Zachary Pincus <zachary.pincus at yale.edu>wrote:

> Hi Siggi,
>
> > like Andy suggested, I need the bonding box for each shear. This should
> represent the diameter in
> > good approximation what leads to the grain size distribution.
>
> In this case I'd also agree with Andy that a template-matching approach
> might be best, with a library of templates of different sizes. Then for
> each template-match peak, determine which size template gives the best
> match, and read out the size distribution from that?
>
> Alternately, you could look at a Hough-circles sort of approach, and again
> could read off the size distribution straight from the Hough-transformed
> image.
>
> Zach


I have a hough-circles implementation (which I've been meaning to
contribute). Unfortunately, my implementation does a pretty poor job when
there's a large range of circle size and when the circles are
close/overlapping. As a result, the output I get for the example image is
not very good. A better implementation may be able to deal with these
issues, though.

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

From tsyu80 at gmail.com  Thu Feb 23 11:47:53 2012
From: tsyu80 at gmail.com (Tony Yu)
Date: Thu, 23 Feb 2012 11:47:53 -0500
Subject: Object detection
In-Reply-To: <4F466886.2030003@mitotic-machine.org>
References: <7611871.8019.1329921462637.JavaMail.geo-discussion-forums@ynbo36>
	<3024433.1547.1330007447131.JavaMail.geo-discussion-forums@vbfm8>
	<3289EF3F-05E8-4C8B-A15C-41B2B9FE1EBD@yale.edu>
	<CAEym_HoXJKCHP7a=T1OsdBsr9uo_VgdxXXbnd5ew=Ro1nu6F2A@mail.gmail.com>
	<4F466886.2030003@mitotic-machine.org>
Message-ID: <CAEym_HoB1UuJVCan2qHeT+98VEc+WifS4h_9WomG6PGTfpTN2Q@mail.gmail.com>

On Thu, Feb 23, 2012 at 11:25 AM, Guillaume Gay <
guillaume at mitotic-machine.org> wrote:

>  Le 23/02/2012 16:57, Tony Yu a ?crit :
>
>
>
> On Thu, Feb 23, 2012 at 10:02 AM, Zachary Pincus <zachary.pincus at yale.edu>wrote:
>
>> Hi Siggi,
>>
>> > like Andy suggested, I need the bonding box for each shear. This should
>> represent the diameter in
>> > good approximation what leads to the grain size distribution.
>>
>>  In this case I'd also agree with Andy that a template-matching approach
>> might be best, with a library of templates of different sizes. Then for
>> each template-match peak, determine which size template gives the best
>> match, and read out the size distribution from that?
>>
>> Alternately, you could look at a Hough-circles sort of approach, and
>> again could read off the size distribution straight from the
>> Hough-transformed image.
>>
>> Zach
>
>
>  I have a hough-circles implementation (which I've been meaning to
> contribute). Unfortunately, my implementation does a pretty poor job when
> there's a large range of circle size and when the circles are
> close/overlapping. As a result, the output I get for the example image is
> not very good. A better implementation may be able to deal with these
> issues, though.
>
>  -Tony
>
>  Have you tried opencv's? Also their fitEllipse might be of help...
>

I'll have to look into that. I've used the opencv implementation of hough
circles, but it didn't give me very good results---that could easily have
been a problem on my end, though.

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

From guillaume at mitotic-machine.org  Thu Feb 23 06:22:24 2012
From: guillaume at mitotic-machine.org (Guillaume Gay)
Date: Thu, 23 Feb 2012 12:22:24 +0100
Subject: Imshow and Linescan - first version
In-Reply-To: <4F422A54.9000902@mitotic-machine.org>
References: <0a962708-d617-45d0-b343-b7e774f23965@b23g2000yqn.googlegroups.com> <4F3E69CD.3010204@mitotic-machine.org> <CABDkGQ=wtY52bPL5+mpuN6t79uG5YKvie2sCD1z54gN+wNm1TA@mail.gmail.com> <4F422A54.9000902@mitotic-machine.org>
Message-ID: <4F462170.4010206@mitotic-machine.org>

Hi all,

Here is a first version of the linescan implementation. It sort of 
works, but I have some issues:

-the major one is that when I instantiate the LineScanInteractor within 
the imshow() function definition, I don't catch the events any more. So 
this is not usable in an interactive session.

-I can't get the ticks on the linescan plot to update properly...

-also there should be some kind of a reset mechanism, because if the 
image is zoomed in, you can lost the handles of the line

So if any one have a hint on how to do this...

Meanwhile I can try to have this work in conjunction tifffile's imshow 
(which should not be so complicated).

With all that maybe it would be better to implement a subclass of 
FigureCanvas, so that linescan appears only when a button (at the bottom 
of the window) is pressed, and it is easy to add e.g. a histogram plot 
or a contrast setter... what do you think?


Bye

Guillaume





Le 20/02/2012 12:11, Guillaume Gay a ?crit :
> Ok, I can give it a try...
>
> Some questions then:
>
> - skivi is pure Qt, so must I keep it that way (no matplotlib 
> dependency)?
> - skivi is good for RGB images, but not so much for greyscale... Also 
> data conversion from uint16 to uint8 turns everything black (it set 
> anything > 256 to 0), shall this be corrected?
> -Christoph Gohlke tifffile.imshow() is somehow closer to what us 
> microscopy guys are expecting (more suitable for those greyscale 
> multipage tiffs), though some features of the fancy viewer such as the 
> contrast settings, are great. Also it is a pure matplotlib 
> implementation and the intensity value reading is already there. So my 
> question is:
> Are those tools needed by the general image analysis skimage community 
> are more by scientific tiff users? If the latest, my guess is that 
> building on top of matplotlib and Christoph's implementation of imshow 
> is a better tactic (plus it would be more cross platform, as this can 
> be a widget irrespective of the backend).
>
> Cheers,
>
> Guillaume
>
>
>
>
> Le 20/02/2012 08:04, St?fan van der Walt a ?crit :
>> On Fri, Feb 17, 2012 at 6:53 AM, Guillaume Gay
>> <guillaume at mitotic-machine.org>  wrote:
>>> I just happen to code a simple linescan function, if that helps...
>> Thanks, Guillaume!  If you could integrate this with the fancy Qt
>> imshow to display the line, that would be wonderful, but otherwise I'm
>> sure we'll still be able to use this code.
>>
>> St?fan
>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: guillaume.vcf
Type: text/x-vcard
Size: 295 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120223/881cb26d/attachment.vcf>

From tsyu80 at gmail.com  Thu Feb 23 13:29:54 2012
From: tsyu80 at gmail.com (Tony Yu)
Date: Thu, 23 Feb 2012 13:29:54 -0500
Subject: Imshow and Linescan - first version
In-Reply-To: <4F462170.4010206@mitotic-machine.org>
References: <0a962708-d617-45d0-b343-b7e774f23965@b23g2000yqn.googlegroups.com>
	<4F3E69CD.3010204@mitotic-machine.org>
	<CABDkGQ=wtY52bPL5+mpuN6t79uG5YKvie2sCD1z54gN+wNm1TA@mail.gmail.com>
	<4F422A54.9000902@mitotic-machine.org>
	<4F462170.4010206@mitotic-machine.org>
Message-ID: <CAEym_HoaTkBxB59OH_uzH2sS04CcPuQ-0TUcdszpg47bbtP9+w@mail.gmail.com>

On Thu, Feb 23, 2012 at 6:22 AM, Guillaume Gay <
guillaume at mitotic-machine.org> wrote:

> Hi all,
>
> Here is a first version of the linescan implementation. It sort of works,
> but I have some issues:
>
> -the major one is that when I instantiate the LineScanInteractor within
> the imshow() function definition, I don't catch the events any more. So
> this is not usable in an interactive session.
>
> -I can't get the ticks on the linescan plot to update properly...
>
> -also there should be some kind of a reset mechanism, because if the image
> is zoomed in, you can lost the handles of the line
>
> So if any one have a hint on how to do this...
>
> Meanwhile I can try to have this work in conjunction tifffile's imshow
> (which should not be so complicated).
>
> With all that maybe it would be better to implement a subclass of
> FigureCanvas, so that linescan appears only when a button (at the bottom of
> the window) is pressed, and it is easy to add e.g. a histogram plot or a
> contrast setter... what do you think?
>
>
> Bye
>
> Guillaume
>

HI Guillaume,

I don't actually see a link or attachment in this email. Could you point me
to the code you mention above?

Thanks,
-Tony


>
> Le 20/02/2012 12:11, Guillaume Gay a ?crit :
>
>> Ok, I can give it a try...
>>
>> Some questions then:
>>
>> - skivi is pure Qt, so must I keep it that way (no matplotlib dependency)?
>> - skivi is good for RGB images, but not so much for greyscale... Also
>> data conversion from uint16 to uint8 turns everything black (it set
>> anything > 256 to 0), shall this be corrected?
>> -Christoph Gohlke tifffile.imshow() is somehow closer to what us
>> microscopy guys are expecting (more suitable for those greyscale multipage
>> tiffs), though some features of the fancy viewer such as the contrast
>> settings, are great. Also it is a pure matplotlib implementation and the
>> intensity value reading is already there. So my question is:
>> Are those tools needed by the general image analysis skimage community
>> are more by scientific tiff users? If the latest, my guess is that building
>> on top of matplotlib and Christoph's implementation of imshow is a better
>> tactic (plus it would be more cross platform, as this can be a widget
>> irrespective of the backend).
>>
>> Cheers,
>>
>> Guillaume
>>
>>
>>
>>
>> Le 20/02/2012 08:04, St?fan van der Walt a ?crit :
>>
>>> On Fri, Feb 17, 2012 at 6:53 AM, Guillaume Gay
>>> <guillaume at mitotic-machine.org**>  wrote:
>>>
>>>> I just happen to code a simple linescan function, if that helps...
>>>>
>>> Thanks, Guillaume!  If you could integrate this with the fancy Qt
>>> imshow to display the line, that would be wonderful, but otherwise I'm
>>> sure we'll still be able to use this code.
>>>
>>> St?fan
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120223/8753a85d/attachment.html>

From guillaume at mitotic-machine.org  Thu Feb 23 11:25:42 2012
From: guillaume at mitotic-machine.org (Guillaume Gay)
Date: Thu, 23 Feb 2012 17:25:42 +0100
Subject: Object detection
In-Reply-To: <CAEym_HoXJKCHP7a=T1OsdBsr9uo_VgdxXXbnd5ew=Ro1nu6F2A@mail.gmail.com>
References: <7611871.8019.1329921462637.JavaMail.geo-discussion-forums@ynbo36> <3024433.1547.1330007447131.JavaMail.geo-discussion-forums@vbfm8> <3289EF3F-05E8-4C8B-A15C-41B2B9FE1EBD@yale.edu> <CAEym_HoXJKCHP7a=T1OsdBsr9uo_VgdxXXbnd5ew=Ro1nu6F2A@mail.gmail.com>
Message-ID: <4F466886.2030003@mitotic-machine.org>

Le 23/02/2012 16:57, Tony Yu a ?crit :
>
>
> On Thu, Feb 23, 2012 at 10:02 AM, Zachary Pincus 
> <zachary.pincus at yale.edu <mailto:zachary.pincus at yale.edu>> wrote:
>
>     Hi Siggi,
>
>     > like Andy suggested, I need the bonding box for each shear. This
>     should represent the diameter in
>     > good approximation what leads to the grain size distribution.
>
>     In this case I'd also agree with Andy that a template-matching
>     approach might be best, with a library of templates of different
>     sizes. Then for each template-match peak, determine which size
>     template gives the best match, and read out the size distribution
>     from that?
>
>     Alternately, you could look at a Hough-circles sort of approach,
>     and again could read off the size distribution straight from the
>     Hough-transformed image.
>
>     Zach
>
>
> I have a hough-circles implementation (which I've been meaning to 
> contribute). Unfortunately, my implementation does a pretty poor job 
> when there's a large range of circle size and when the circles are 
> close/overlapping. As a result, the output I get for the example image 
> is not very good. A better implementation may be able to deal with 
> these issues, though.
>
> -Tony
>
Have you tried opencv's? Also their fitEllipse might be of help...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120223/9ca4f76e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: guillaume.vcf
Type: text/x-vcard
Size: 282 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120223/9ca4f76e/attachment.vcf>

From stefan at sun.ac.za  Fri Feb 24 03:41:26 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Fri, 24 Feb 2012 00:41:26 -0800
Subject: Imshow and Linescan - first version
In-Reply-To: <4F4743FD.20304@mitotic-machine.org>
References: <0a962708-d617-45d0-b343-b7e774f23965@b23g2000yqn.googlegroups.com>
 <4F3E69CD.3010204@mitotic-machine.org> <CABDkGQ=wtY52bPL5+mpuN6t79uG5YKvie2sCD1z54gN+wNm1TA@mail.gmail.com>
 <4F422A54.9000902@mitotic-machine.org> <4F462170.4010206@mitotic-machine.org>
 <CAEym_HoaTkBxB59OH_uzH2sS04CcPuQ-0TUcdszpg47bbtP9+w@mail.gmail.com> <4F4743FD.20304@mitotic-machine.org>
Message-ID: <CABDkGQ=4twsN65EKpD_+e=RhBFmSQK-kZFzZpnuxWUg9nuVOsw@mail.gmail.com>

On Fri, Feb 24, 2012 at 12:02 AM, Guillaume Gay
<guillaume at mitotic-machine.org> wrote:
> I forked sckimage on github and pushed the plugin there:
>
> https://github.com/glyg/scikits-image/blob/master/skimage/io/_plugins/matplotlib_plugin.py

Cute!  I like it.

St?fan


From guillaume at mitotic-machine.org  Fri Feb 24 03:02:05 2012
From: guillaume at mitotic-machine.org (Guillaume Gay)
Date: Fri, 24 Feb 2012 09:02:05 +0100
Subject: Imshow and Linescan - first version
In-Reply-To: <CAEym_HoaTkBxB59OH_uzH2sS04CcPuQ-0TUcdszpg47bbtP9+w@mail.gmail.com>
References: <0a962708-d617-45d0-b343-b7e774f23965@b23g2000yqn.googlegroups.com> <4F3E69CD.3010204@mitotic-machine.org> <CABDkGQ=wtY52bPL5+mpuN6t79uG5YKvie2sCD1z54gN+wNm1TA@mail.gmail.com> <4F422A54.9000902@mitotic-machine.org> <4F462170.4010206@mitotic-machine.org> <CAEym_HoaTkBxB59OH_uzH2sS04CcPuQ-0TUcdszpg47bbtP9+w@mail.gmail.com>
Message-ID: <4F4743FD.20304@mitotic-machine.org>

Hi Tony,

Mea culpa, I forgot to attach the code:

I forked sckimage on github and pushed the plugin there:

https://github.com/glyg/scikits-image/blob/master/skimage/io/_plugins/matplotlib_plugin.py

Guillaume

Le 23/02/2012 19:29, Tony Yu a ?crit :
>
>
> On Thu, Feb 23, 2012 at 6:22 AM, Guillaume Gay 
> <guillaume at mitotic-machine.org <mailto:guillaume at mitotic-machine.org>> 
> wrote:
>
>     Hi all,
>
>     Here is a first version of the linescan implementation. It sort of
>     works, but I have some issues:
>
>     -the major one is that when I instantiate the LineScanInteractor
>     within the imshow() function definition, I don't catch the events
>     any more. So this is not usable in an interactive session.
>
>     -I can't get the ticks on the linescan plot to update properly...
>
>     -also there should be some kind of a reset mechanism, because if
>     the image is zoomed in, you can lost the handles of the line
>
>     So if any one have a hint on how to do this...
>
>     Meanwhile I can try to have this work in conjunction tifffile's
>     imshow (which should not be so complicated).
>
>     With all that maybe it would be better to implement a subclass of
>     FigureCanvas, so that linescan appears only when a button (at the
>     bottom of the window) is pressed, and it is easy to add e.g. a
>     histogram plot or a contrast setter... what do you think?
>
>
>     Bye
>
>     Guillaume
>
>
> HI Guillaume,
>
> I don't actually see a link or attachment in this email. Could you 
> point me to the code you mention above?
>
> Thanks,
> -Tony
>
>
>     Le 20/02/2012 12:11, Guillaume Gay a ?crit :
>
>         Ok, I can give it a try...
>
>         Some questions then:
>
>         - skivi is pure Qt, so must I keep it that way (no matplotlib
>         dependency)?
>         - skivi is good for RGB images, but not so much for
>         greyscale... Also data conversion from uint16 to uint8 turns
>         everything black (it set anything > 256 to 0), shall this be
>         corrected?
>         -Christoph Gohlke tifffile.imshow() is somehow closer to what
>         us microscopy guys are expecting (more suitable for those
>         greyscale multipage tiffs), though some features of the fancy
>         viewer such as the contrast settings, are great. Also it is a
>         pure matplotlib implementation and the intensity value reading
>         is already there. So my question is:
>         Are those tools needed by the general image analysis skimage
>         community are more by scientific tiff users? If the latest, my
>         guess is that building on top of matplotlib and Christoph's
>         implementation of imshow is a better tactic (plus it would be
>         more cross platform, as this can be a widget irrespective of
>         the backend).
>
>         Cheers,
>
>         Guillaume
>
>
>
>
>         Le 20/02/2012 08:04, St?fan van der Walt a ?crit :
>
>             On Fri, Feb 17, 2012 at 6:53 AM, Guillaume Gay
>             <guillaume at mitotic-machine.org
>             <mailto:guillaume at mitotic-machine.org>>  wrote:
>
>                 I just happen to code a simple linescan function, if
>                 that helps...
>
>             Thanks, Guillaume!  If you could integrate this with the
>             fancy Qt
>             imshow to display the line, that would be wonderful, but
>             otherwise I'm
>             sure we'll still be able to use this code.
>
>             St?fan
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120224/30323eaf/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: guillaume.vcf
Type: text/x-vcard
Size: 282 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120224/30323eaf/attachment.vcf>

From siggin at gmail.com  Sat Feb 25 08:50:05 2012
From: siggin at gmail.com (Sigmund)
Date: Sat, 25 Feb 2012 05:50:05 -0800 (PST)
Subject: Object detection
In-Reply-To: <7611871.8019.1329921462637.JavaMail.geo-discussion-forums@ynbo36>
References: <7611871.8019.1329921462637.JavaMail.geo-discussion-forums@ynbo36>
Message-ID: <31201667.20.1330177805581.JavaMail.geo-discussion-forums@ynjm17>

Hallo,

sorry for being so slow with my answers! I have urgent other tasks right 
now. I will pick up your hints when I have some time.
Thanks for your help.

Siggi

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

From siggin at gmail.com  Sat Feb 25 11:15:47 2012
From: siggin at gmail.com (Sigmund)
Date: Sat, 25 Feb 2012 08:15:47 -0800 (PST)
Subject: downscaling float32 image to uint12 via scikits.img_as_uint()
Message-ID: <2448250.748.1330186547745.JavaMail.geo-discussion-forums@vbae11>

Hi!
its me again... 
I'm using the scikits.img_as_uint() function for downscaling a float32 gray 
scale image. The downscaling is needed to use the 
mahotas.thresholding.otsu() function.
I noticed that the img_as_uint() function is not scaling the intensity.  It 
looks like that in areas where the intensity is exceeding the uint16 space, 
it shows wrong values. Does it show 0+the exceeding part?
Is the behavior volitional ?

Siggi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120225/27ec9845/attachment.html>

From stefan at sun.ac.za  Sat Feb 25 14:33:46 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sat, 25 Feb 2012 11:33:46 -0800
Subject: Object detection
In-Reply-To: <CAEym_HoXJKCHP7a=T1OsdBsr9uo_VgdxXXbnd5ew=Ro1nu6F2A@mail.gmail.com>
References: <7611871.8019.1329921462637.JavaMail.geo-discussion-forums@ynbo36>
 <3024433.1547.1330007447131.JavaMail.geo-discussion-forums@vbfm8>
 <3289EF3F-05E8-4C8B-A15C-41B2B9FE1EBD@yale.edu> <CAEym_HoXJKCHP7a=T1OsdBsr9uo_VgdxXXbnd5ew=Ro1nu6F2A@mail.gmail.com>
Message-ID: <CABDkGQnMGvsmzLHzOrGrCfdvfP5EPV=NXOsLpH37Q0v7x6znMg@mail.gmail.com>

Hi Tony

On Thu, Feb 23, 2012 at 7:57 AM, Tony Yu <tsyu80 at gmail.com> wrote:
> I have a hough-circles implementation (which I've been meaning to
> contribute). Unfortunately, my implementation does a pretty poor job when
> there's a large range of circle size and when the circles are
> close/overlapping.

I'm not sure this is your implementation's fault--aren't the
parameters just overly sensitive in general?

I searched for a different parametrization, and found this paper on the arxiv:

http://arxiv.org/abs/cs/0301001v1

Have you ever seen the Hough transform implemented using this
formulation?  (A(x^2 + y^2) + B(x) + C(y) + D).  Maybe we're on to
something :)

I'd love to be able to solve Siggi's problem--this is exactly the
kinds of things our toolbox should be able to address.

St?fan


From tsyu80 at gmail.com  Sat Feb 25 11:46:33 2012
From: tsyu80 at gmail.com (Tony Yu)
Date: Sat, 25 Feb 2012 11:46:33 -0500
Subject: downscaling float32 image to uint12 via scikits.img_as_uint()
In-Reply-To: <2448250.748.1330186547745.JavaMail.geo-discussion-forums@vbae11>
References: <2448250.748.1330186547745.JavaMail.geo-discussion-forums@vbae11>
Message-ID: <CAEym_HrZ7UyEikhSs4mBYDxbZ1NV4HxvNKOTx7AQXFLgGADfYg@mail.gmail.com>

Hi Siggi,

It sounds like you may have a float32 image with values outside of the
assumed range of 0--1 (see user
guide<http://scikits-image.org/docs/dev/user_guide/data_types.html>
).

A couple of solutions; unfortunately, both require you to run skimage from
github (there's been a lot of activity since the last release):
* Assuming you have float values outside the range, use
`rescale_intensity`<http://scikits-image.org/docs/dev/api/skimage.exposure.html#rescale-intensity>
to
rescale your image to the correct range. (You can also do this manually
too, of course).
* Use `threshold_otsu`<http://scikits-image.org/docs/dev/api/skimage.filter.html#threshold-otsu>
from
skimage instead of mahotas.

Also, all conversion functions should now (i.e. github master) raise an
error when given a float image outside of the 0--1 range, so this shouldn't
happen in the future.

Best,
-Tony


On Sat, Feb 25, 2012 at 11:15 AM, Sigmund <siggin at gmail.com> wrote:

> Hi!
> its me again...
> I'm using the scikits.img_as_uint() function for downscaling a float32
> gray scale image. The downscaling is needed to use the
> mahotas.thresholding.otsu() function.
> I noticed that the img_as_uint() function is not scaling the intensity.
> It looks like that in areas where the intensity is exceeding the uint16
> space, it shows wrong values. Does it show 0+the exceeding part?
> Is the behavior volitional ?
>
> Siggi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120225/da50579d/attachment.html>

From siggin at gmail.com  Sat Feb 25 15:18:15 2012
From: siggin at gmail.com (Sigmund)
Date: Sat, 25 Feb 2012 12:18:15 -0800 (PST)
Subject: downscaling float32 image to uint12 via scikits.img_as_uint()
In-Reply-To: <CAEym_HrZ7UyEikhSs4mBYDxbZ1NV4HxvNKOTx7AQXFLgGADfYg@mail.gmail.com>
References: <2448250.748.1330186547745.JavaMail.geo-discussion-forums@vbae11>
 <CAEym_HrZ7UyEikhSs4mBYDxbZ1NV4HxvNKOTx7AQXFLgGADfYg@mail.gmail.com>
Message-ID: <12083721.362.1330201095901.JavaMail.geo-discussion-forums@vbas10>



Am Samstag, 25. Februar 2012 17:46:33 UTC+1 schrieb Tony S Yu:
>
> Hi Siggi,
>
> It sounds like you may have a float32 image with values outside of the 
> assumed range of 0--1 (see user guide<http://scikits-image.org/docs/dev/user_guide/data_types.html>). 
>
>

correct!
 

> A couple of solutions; unfortunately, both require you to run skimage from 
> github (there's been a lot of activity since the last release):
>

no issues with the 0.5dev installation and use so fare on Mac OSX 10.6.8
 

> * Assuming you have float values outside the range, use 
> `rescale_intensity`<http://scikits-image.org/docs/dev/api/skimage.exposure.html#rescale-intensity> to 
> rescale your image to the correct range. (You can also do this manually 
> too, of course).
>
 
kept the float values since conversion is not needed anymore
 

> * Use `threshold_otsu`<http://scikits-image.org/docs/dev/api/skimage.filter.html#threshold-otsu> from 
> skimage instead of mahotas.
>

works great!
 

> Also, all conversion functions should now (i.e. github master) raise an 
> error when given a float image outside of the 0--1 range, so this shouldn't 
> happen in the future.
>

in my case they  raise the error


> Best,
> -Tony
>
>
Thanks! Great job!

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

From cjgohlke at gmail.com  Sat Feb 25 15:19:47 2012
From: cjgohlke at gmail.com (Christoph Gohlke)
Date: Sat, 25 Feb 2012 12:19:47 -0800
Subject: Imshow and Linescan - first version
In-Reply-To: <CAEym_HpXCfScRe-Q5Q1sgqUKNP416M=vW1c7iw+RFWXinnz1UA@mail.gmail.com>
References: <0a962708-d617-45d0-b343-b7e774f23965@b23g2000yqn.googlegroups.com> <4F3E69CD.3010204@mitotic-machine.org> <CABDkGQ=wtY52bPL5+mpuN6t79uG5YKvie2sCD1z54gN+wNm1TA@mail.gmail.com> <4F422A54.9000902@mitotic-machine.org> <4F462170.4010206@mitotic-machine.org> <CAEym_HoaTkBxB59OH_uzH2sS04CcPuQ-0TUcdszpg47bbtP9+w@mail.gmail.com> <4F4743FD.20304@mitotic-machine.org> <CABDkGQ=4twsN65EKpD_+e=RhBFmSQK-kZFzZpnuxWUg9nuVOsw@mail.gmail.com> <CAEym_HpXCfScRe-Q5Q1sgqUKNP416M=vW1c7iw+RFWXinnz1UA@mail.gmail.com>
Message-ID: <4F494263.40207@gmail.com>

On 2/25/2012 11:10 AM, Tony Yu wrote:
>
> 2012/2/24 St??????fan van der Walt <stefan at sun.ac.za <mailto:stefan at sun.ac.za>>
>
>     On Fri, Feb 24, 2012 at 12:02 AM, Guillaume Gay
>     <guillaume at mitotic-machine.org
>     <mailto:guillaume at mitotic-machine.org>> wrote:
>     > I forked sckimage on github and pushed the plugin there:
>     >
>     > https://github.com/glyg/scikits-image/blob/master/skimage/io/_plugins/matplotlib_plugin.py
>
>     Cute!  I like it.
>
>     St??????fan
>
>
> Hi Guillaume,
>
> Hmm, this is much more interesting than what I expected when you 
> mentioned a line scan tool. :)
>
> I made a PR to your repo, which I guess you already noticed (and 
> merged) and I have some more specific comments I want to add to your 
> PR, but I had some more general thoughts (i.e. probably not stuff that 
> should be implemented in this PR) that I want to post here:
>
> Plugin system
> ------
> It might be nice to have some sort of plugin system for the image 
> viewer. That way, tools like this could be implemented a bit more 
> easily and, also, easily added to the viewer or ignored by the user. I 
> think someone mentioned on the list that scikits-image should be 
> careful not to stray too far into GUI tools (I could be completely 
> mis-representing the idea here), and I agree to an extent. 
> Nevertheless, I think providing a viewer that supplies *an 
> infrastructure* for creating GUI tools might be really valuable. I 
> haven't really thought through what this plugin system would look 
> like, so it may just be a pipe dream.
>
> TIFFFile Viewer
> ------
> There was talk of integrating the viewer from TIFFFile---was the idea 
> to write a wrapper around the viewer (like Zach did for 
> `imread`/`imsave`) or to copy it into skimage and modify it. If it's 
> the latter, we should make sure that Christophe Gohlke is OK with that 
> (Christophe mentioned that it wouldn't make sense to fork TIFFFile 
> into skimage, but presumably, this would be different for 
> `tifffile.imshow` since we would likely want to modify it).
>
> Best,
> -Tony

Hi Tony,

sure it's OK to take imview or parts of it out of tifffile.py. I'm not 
sure how much of its functionality applies to skimage, which seems to 
limit itself to well defined image formats. Tifffile has to deal with 
n-dimensional, planar, any bit depth per channel, two channel "RGB", and 
16 bit paletted images. The tifffile.imshow function is a hack to 
provide a preview of such (often ambiguous) data.

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

From tsyu80 at gmail.com  Sat Feb 25 14:10:21 2012
From: tsyu80 at gmail.com (Tony Yu)
Date: Sat, 25 Feb 2012 14:10:21 -0500
Subject: Imshow and Linescan - first version
In-Reply-To: <CABDkGQ=4twsN65EKpD_+e=RhBFmSQK-kZFzZpnuxWUg9nuVOsw@mail.gmail.com>
References: <0a962708-d617-45d0-b343-b7e774f23965@b23g2000yqn.googlegroups.com>
	<4F3E69CD.3010204@mitotic-machine.org>
	<CABDkGQ=wtY52bPL5+mpuN6t79uG5YKvie2sCD1z54gN+wNm1TA@mail.gmail.com>
	<4F422A54.9000902@mitotic-machine.org>
	<4F462170.4010206@mitotic-machine.org>
	<CAEym_HoaTkBxB59OH_uzH2sS04CcPuQ-0TUcdszpg47bbtP9+w@mail.gmail.com>
	<4F4743FD.20304@mitotic-machine.org>
	<CABDkGQ=4twsN65EKpD_+e=RhBFmSQK-kZFzZpnuxWUg9nuVOsw@mail.gmail.com>
Message-ID: <CAEym_HpXCfScRe-Q5Q1sgqUKNP416M=vW1c7iw+RFWXinnz1UA@mail.gmail.com>

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

> On Fri, Feb 24, 2012 at 12:02 AM, Guillaume Gay
> <guillaume at mitotic-machine.org> wrote:
> > I forked sckimage on github and pushed the plugin there:
> >
> >
> https://github.com/glyg/scikits-image/blob/master/skimage/io/_plugins/matplotlib_plugin.py
>
> Cute!  I like it.
>
> St?fan
>

Hi Guillaume,

Hmm, this is much more interesting than what I expected when you mentioned
a line scan tool. :)

I made a PR to your repo, which I guess you already noticed (and merged)
and I have some more specific comments I want to add to your PR, but I had
some more general thoughts (i.e. probably not stuff that should be
implemented in this PR) that I want to post here:

Plugin system
------
It might be nice to have some sort of plugin system for the image viewer.
That way, tools like this could be implemented a bit more easily and, also,
easily added to the viewer or ignored by the user. I think someone
mentioned on the list that scikits-image should be careful not to stray too
far into GUI tools (I could be completely mis-representing the idea here),
and I agree to an extent. Nevertheless, I think providing a viewer that
supplies *an infrastructure* for creating GUI tools might be really
valuable. I haven't really thought through what this plugin system would
look like, so it may just be a pipe dream.

TIFFFile Viewer
------
There was talk of integrating the viewer from TIFFFile---was the idea to
write a wrapper around the viewer (like Zach did for `imread`/`imsave`) or
to copy it into skimage and modify it. If it's the latter, we should make
sure that Christophe Gohlke is OK with that (Christophe mentioned that it
wouldn't make sense to fork TIFFFile into skimage, but presumably, this
would be different for `tifffile.imshow` since we would likely want to
modify it).

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

From stefan at sun.ac.za  Sat Feb 25 18:26:24 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sat, 25 Feb 2012 15:26:24 -0800
Subject: 0.5 Release
Message-ID: <CABDkGQkRCD=24FU-WmLj28+u2TWDYgY8tJbh-vdsFg8_hc-ztw@mail.gmail.com>

Hi all,

I'm slightly behind on the release, but I have to cut it before PyData
this upcoming week, so if there's anything urgent that you'd like to
go in still, please let me know by tomorrow.  I'll try to push out the
release Sunday evening, Pacific time.

Thanks!
St?fan


From stefan at sun.ac.za  Sat Feb 25 18:27:58 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sat, 25 Feb 2012 15:27:58 -0800
Subject: Object detection
In-Reply-To: <53AABE26-1EA6-4BAB-9316-0D98CE67639B@yale.edu>
References: <7611871.8019.1329921462637.JavaMail.geo-discussion-forums@ynbo36>
 <3024433.1547.1330007447131.JavaMail.geo-discussion-forums@vbfm8>
 <3289EF3F-05E8-4C8B-A15C-41B2B9FE1EBD@yale.edu> <CAEym_HoXJKCHP7a=T1OsdBsr9uo_VgdxXXbnd5ew=Ro1nu6F2A@mail.gmail.com>
 <CABDkGQnMGvsmzLHzOrGrCfdvfP5EPV=NXOsLpH37Q0v7x6znMg@mail.gmail.com> <53AABE26-1EA6-4BAB-9316-0D98CE67639B@yale.edu>
Message-ID: <CABDkGQkb9-fEQjwFcduWEUqZWdrAgMBvOk+-HtmuXx-aXeSekw@mail.gmail.com>

On Sat, Feb 25, 2012 at 12:47 PM, Zachary Pincus
<zachary.pincus at yale.edu> wrote:
>> I'd love to be able to solve Siggi's problem--this is exactly the
>> kinds of things our toolbox should be able to address.
>
> Is there a template matching module? That'd be a good wish-list item for a simple cython implementation. (Convolution is easy, but sum-of-[absolute|squared]-differences can't be done through convolution alone, right? Or am I being daft?)

There's a pull-request in the making:

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

Feel free to review and chip in!

St?fan


From zachary.pincus at yale.edu  Sat Feb 25 15:47:51 2012
From: zachary.pincus at yale.edu (Zachary Pincus)
Date: Sat, 25 Feb 2012 15:47:51 -0500
Subject: Object detection
In-Reply-To: <CABDkGQnMGvsmzLHzOrGrCfdvfP5EPV=NXOsLpH37Q0v7x6znMg@mail.gmail.com>
References: <7611871.8019.1329921462637.JavaMail.geo-discussion-forums@ynbo36> <3024433.1547.1330007447131.JavaMail.geo-discussion-forums@vbfm8> <3289EF3F-05E8-4C8B-A15C-41B2B9FE1EBD@yale.edu> <CAEym_HoXJKCHP7a=T1OsdBsr9uo_VgdxXXbnd5ew=Ro1nu6F2A@mail.gmail.com> <CABDkGQnMGvsmzLHzOrGrCfdvfP5EPV=NXOsLpH37Q0v7x6znMg@mail.gmail.com>
Message-ID: <53AABE26-1EA6-4BAB-9316-0D98CE67639B@yale.edu>

> I'd love to be able to solve Siggi's problem--this is exactly the
> kinds of things our toolbox should be able to address.

Is there a template matching module? That'd be a good wish-list item for a simple cython implementation. (Convolution is easy, but sum-of-[absolute|squared]-differences can't be done through convolution alone, right? Or am I being daft?)

Zach


From emmanuelle.gouillart at nsup.org  Sat Feb 25 11:55:59 2012
From: emmanuelle.gouillart at nsup.org (Emmanuelle Gouillart)
Date: Sat, 25 Feb 2012 17:55:59 +0100
Subject: Object detection
In-Reply-To: <31201667.20.1330177805581.JavaMail.geo-discussion-forums@ynjm17>
References: <7611871.8019.1329921462637.JavaMail.geo-discussion-forums@ynbo36>
 <31201667.20.1330177805581.JavaMail.geo-discussion-forums@ynjm17>
Message-ID: <20120225165559.GB21748@phare.normalesup.org>

Hallo Siggi,

two quick remarks. If you are the one taking the pictures, there is
probably room for improvement concerning the acquisition, and not only
the processing. If your image is taken with scanning electron microscopy,
as it seems to me (but I'm not sure), you might want to combine an
image from secondary electrons as the one you sent, and one image from
back-scattered electrons. These two images should have a different type
of contrast, that you might use for example to remove the background, and
the process only regions corresponding to the spheres.

About the Laplace transform for extracting the edges, you can get more
pixels from the edges by using the canny filter, instead of a simple
sobel filter. I had to use a larger value of sigma (the width of the
Gaussian blurring applied before computing the sobel filter in the
algorithm) than the default value

>>> from skimage import img_as_float
>>> from skimage.filter import canny
>>> edges = canny(img_as_float(data), sigma=3)

Cheers,
Emmanuelle

On Sat, Feb 25, 2012 at 05:50:05AM -0800, Sigmund wrote:
>    Hallo,

>    sorry for being so slow with my answers! I have urgent other tasks right
>    now. I will pick up your hints when I have some time.
>    Thanks for your help.

>    Siggi


From cjgohlke at gmail.com  Sun Feb 26 00:07:10 2012
From: cjgohlke at gmail.com (Christoph Gohlke)
Date: Sat, 25 Feb 2012 21:07:10 -0800
Subject: 0.5 Release
In-Reply-To: <CABDkGQkRCD=24FU-WmLj28+u2TWDYgY8tJbh-vdsFg8_hc-ztw@mail.gmail.com>
References: <CABDkGQkRCD=24FU-WmLj28+u2TWDYgY8tJbh-vdsFg8_hc-ztw@mail.gmail.com>
Message-ID: <4F49BDFE.1080308@gmail.com>

On 2/25/2012 3:26 PM, St??????fan van der Walt wrote:
> Hi all,
>
> I'm slightly behind on the release, but I have to cut it before PyData
> this upcoming week, so if there's anything urgent that you'd like to
> go in still, please let me know by tomorrow.  I'll try to push out the
> release Sunday evening, Pacific time.
>
> Thanks!
> St??????fan
>

Hi St??????fan,

I submitted a couple of pull requests, which fix all test errors and 
failures on win32 and win-amd64 platforms.

Ciao,

Christoph



From zachary.pincus at yale.edu  Sun Feb 26 11:08:13 2012
From: zachary.pincus at yale.edu (Zachary Pincus)
Date: Sun, 26 Feb 2012 11:08:13 -0500
Subject: [scikits-image] Restore previous io plugins (#152)
In-Reply-To: <scikits-image/scikits-image/pull/152@github.com>
References: <scikits-image/scikits-image/pull/152@github.com>
Message-ID: <70C87030-C54F-4868-B772-75FA82CA8227@yale.edu>

Hi all,

I see there's been a flurry of fixit and cleanup patches! Thanks all, especially Christoph, and especially as I see a lot of these oversights about python 3 syntax etc. came from my code. Sorry :)

Thanks also for noticing the following issue Christoph:

> This fixes an issue when running skimage.io.tests. When the tifffile plugin is left active two subsequent tests in skimage.morphology fail to read PNG files.

Should I add similar teardown() stanzas to all of the image IO plugin tests so that none are left present thereafter, to avoid other such errors? (Though the other plugins read PNGs, it might be a better habit to tear everything down anyway.)

Zach


From stefan at sun.ac.za  Sun Feb 26 15:05:05 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 26 Feb 2012 12:05:05 -0800
Subject: [scikits-image] Restore previous io plugins (#152)
In-Reply-To: <70C87030-C54F-4868-B772-75FA82CA8227@yale.edu>
References: <scikits-image/scikits-image/pull/152@github.com> <70C87030-C54F-4868-B772-75FA82CA8227@yale.edu>
Message-ID: <CABDkGQ=gb_Lb+39PxZjZGO7=hCA7vWLFdDAThVQq=anmQ5hq6Q@mail.gmail.com>

On Sun, Feb 26, 2012 at 8:08 AM, Zachary Pincus <zachary.pincus at yale.edu> wrote:
>> This fixes an issue when running skimage.io.tests. When the tifffile plugin is left active two subsequent tests in skimage.morphology fail to read PNG files.
>
> Should I add similar teardown() stanzas to all of the image IO plugin tests so that none are left present thereafter, to avoid other such errors? (Though the other plugins read PNGs, it might be a better habit to tear everything down anyway.)

Thanks, I also thought this would be a good idea, after seeing
Christoph's patch.

St?fan


From stefan at sun.ac.za  Sun Feb 26 15:09:55 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 26 Feb 2012 12:09:55 -0800
Subject: 0.5 Release
In-Reply-To: <4F49BDFE.1080308@gmail.com>
References: <CABDkGQkRCD=24FU-WmLj28+u2TWDYgY8tJbh-vdsFg8_hc-ztw@mail.gmail.com>
 <4F49BDFE.1080308@gmail.com>
Message-ID: <CABDkGQ=7OpVn7ySdHN3Wa_8CADO2Bz+iKMY9iyNncA2F=jBkmw@mail.gmail.com>

Hi Christoph

On Sat, Feb 25, 2012 at 9:07 PM, Christoph Gohlke <cjgohlke at gmail.com> wrote:
> I submitted a couple of pull requests, which fix all test errors and
> failures on win32 and win-amd64 platforms.

Thanks very much!  All the PRs have been merged.

St?fan


From stefan at sun.ac.za  Sun Feb 26 15:15:53 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 26 Feb 2012 12:15:53 -0800
Subject: Imshow and Linescan - first version
In-Reply-To: <CAEym_HpXCfScRe-Q5Q1sgqUKNP416M=vW1c7iw+RFWXinnz1UA@mail.gmail.com>
References: <0a962708-d617-45d0-b343-b7e774f23965@b23g2000yqn.googlegroups.com>
 <4F3E69CD.3010204@mitotic-machine.org> <CABDkGQ=wtY52bPL5+mpuN6t79uG5YKvie2sCD1z54gN+wNm1TA@mail.gmail.com>
 <4F422A54.9000902@mitotic-machine.org> <4F462170.4010206@mitotic-machine.org>
 <CAEym_HoaTkBxB59OH_uzH2sS04CcPuQ-0TUcdszpg47bbtP9+w@mail.gmail.com>
 <4F4743FD.20304@mitotic-machine.org> <CABDkGQ=4twsN65EKpD_+e=RhBFmSQK-kZFzZpnuxWUg9nuVOsw@mail.gmail.com>
 <CAEym_HpXCfScRe-Q5Q1sgqUKNP416M=vW1c7iw+RFWXinnz1UA@mail.gmail.com>
Message-ID: <CABDkGQ=Xa8mXoaFrMk+yQvGhqKa2fD4hHg0H6FccMQzt+kELfg@mail.gmail.com>

On Sat, Feb 25, 2012 at 11:10 AM, Tony Yu <tsyu80 at gmail.com> wrote:
> Plugin system
> ------
> It might be nice to have some sort of plugin system for the image viewer.
> That way, tools like this could be implemented a bit more easily and, also,
> easily added to the viewer or ignored by the user.

At the moment, we basically have a double-viewer implementation:
simply vs fancy.  So we separate out

imshow(x) and imshow(x, fancy=True)

> agree to an extent. Nevertheless, I think providing a viewer that supplies
> *an infrastructure* for creating GUI tools might be really valuable. I
> haven't really thought through what this plugin system would look like, so
> it may just be a pipe dream.

This is a tricky problem (which set of tools to use, etc.)--but in
principle, it would be nice to have a few standard viewers, e.g.,
image compare, image compare + parameter adjust, mask editor (to build
custom filters, e.g.) and image inspector (like the one you and
Guillaume are working on).

St?fan


From cjgohlke at gmail.com  Sun Feb 26 15:25:46 2012
From: cjgohlke at gmail.com (Christoph Gohlke)
Date: Sun, 26 Feb 2012 12:25:46 -0800
Subject: [scikits-image] Restore previous io plugins (#152)
In-Reply-To: <CABDkGQ=gb_Lb+39PxZjZGO7=hCA7vWLFdDAThVQq=anmQ5hq6Q@mail.gmail.com>
References: <scikits-image/scikits-image/pull/152@github.com> <70C87030-C54F-4868-B772-75FA82CA8227@yale.edu> <CABDkGQ=gb_Lb+39PxZjZGO7=hCA7vWLFdDAThVQq=anmQ5hq6Q@mail.gmail.com>
Message-ID: <4F4A954A.8070904@gmail.com>

On 2/26/2012 12:05 PM, St??????fan van der Walt wrote:
> On Sun, Feb 26, 2012 at 8:08 AM, Zachary Pincus<zachary.pincus at yale.edu>  wrote:
>>> This fixes an issue when running skimage.io.tests. When the tifffile plugin is left active two subsequent tests in skimage.morphology fail to read PNG files.
>> Should I add similar teardown() stanzas to all of the image IO plugin tests so that none are left present thereafter, to avoid other such errors? (Though the other plugins read PNGs, it might be a better habit to tear everything down anyway.)
> Thanks, I also thought this would be a good idea, after seeing
> Christoph's patch.
>
> St??????fan
>

Instead of restoring the default plugins after each test module, maybe 
it would be better/cleaner/safer for the tests to never change the 
default plugins but to just load the plugin and explicitly specify the 
plugin in each imread, imwrite, etc. function call? It seems there is 
currently no way to load a plugin without making it the default. This 
could be achieved by changing the use_plugin function to accept another 
option for the `kind` parameter, e.g. an empty string, signaling that 
the plugin should only be loaded. Probably too late for the 0.5 release.

Christoph


From stefan at sun.ac.za  Sun Feb 26 19:03:40 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 26 Feb 2012 16:03:40 -0800
Subject: [scikits-image] Restore previous io plugins (#152)
In-Reply-To: <4F4A954A.8070904@gmail.com>
References: <scikits-image/scikits-image/pull/152@github.com>
 <70C87030-C54F-4868-B772-75FA82CA8227@yale.edu> <CABDkGQ=gb_Lb+39PxZjZGO7=hCA7vWLFdDAThVQq=anmQ5hq6Q@mail.gmail.com>
 <4F4A954A.8070904@gmail.com>
Message-ID: <CABDkGQkG0ACanWK9qixEuzOmMCK+tYMSEGFKmpPNkTuWmB8hDQ@mail.gmail.com>

On Sun, Feb 26, 2012 at 12:25 PM, Christoph Gohlke <cjgohlke at gmail.com> wrote:
> Instead of restoring the default plugins after each test module, maybe it
> would be better/cleaner/safer for the tests to never change the default
> plugins but to just load the plugin and explicitly specify the plugin in
> each imread, imwrite, etc. function call? It seems there is currently no way
> to load a plugin without making it the default. This could be achieved by
> changing the use_plugin function to accept another option for the `kind`
> parameter, e.g. an empty string, signaling that the plugin should only be
> loaded. Probably too late for the 0.5 release.

Ideally, the ``imread(..., plugin='fits')`` functionality should
auto-load the FITS-plugin---I should see why this is not currently
working, because it seems like a bug.

St?fan


From stefan at sun.ac.za  Mon Feb 27 00:16:40 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 26 Feb 2012 21:16:40 -0800
Subject: ANN: scikits-image v0.5
Message-ID: <CABDkGQmYQnjC+JnAs5-2V0RHLMOrV3B02iW3gV9X5NTtxi2b=g@mail.gmail.com>

Announcement: scikits-image 0.5
===============================

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

For more information, please visit our website

  http://scikits-image.org

New Features
------------
- Consistent intensity rescaling and improved range conversion.
- Random walker segmentation.
- Harris corner detection.
- Otsu thresholding.
- Block views, window views and montage.
- Plugin for Christoph Golke's "tifffile".
- Peak detection.
- Improved FreeImage wrappers and meta-data reading.
- 8-neighbor and background labelling.

... along with updates to the documentation and website, and a number of bug
fixes.

Contributors to this release
----------------------------
* Andreas Mueller
* Brian Holt
* Christoph Gohlke
* Emmanuelle Gouillart
* Michael Aye
* Nelle Varoquaux
* Nicolas Pinto
* Nicolas Poilvert
* Pieter Holtzhausen
* Stefan van der Walt
* Tony S Yu
* Warren Weckesser
* Zachary Pincus


From stefan at sun.ac.za  Mon Feb 27 01:01:03 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Sun, 26 Feb 2012 22:01:03 -0800
Subject: Windows binaries and 0.5
Message-ID: <CABDkGQnA_hVnvQ49yXx33AuS2DTdR4JyGy1=UYLFBuB2LOBixQ@mail.gmail.com>

Hey all,

Christoph has already built scikits-image 0.5 packages for windows.
Thanks a bunch, Chris!

And thanks also to everyone who contributed to this release!

St?fan


From stefan at sun.ac.za  Mon Feb 27 04:33:21 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 27 Feb 2012 01:33:21 -0800
Subject: Imshow and Linescan - first version
In-Reply-To: <4F4B491D.5070902@mitotic-machine.org>
References: <0a962708-d617-45d0-b343-b7e774f23965@b23g2000yqn.googlegroups.com>
 <4F3E69CD.3010204@mitotic-machine.org> <CABDkGQ=wtY52bPL5+mpuN6t79uG5YKvie2sCD1z54gN+wNm1TA@mail.gmail.com>
 <4F422A54.9000902@mitotic-machine.org> <4F462170.4010206@mitotic-machine.org>
 <CAEym_HoaTkBxB59OH_uzH2sS04CcPuQ-0TUcdszpg47bbtP9+w@mail.gmail.com>
 <4F4743FD.20304@mitotic-machine.org> <CABDkGQ=4twsN65EKpD_+e=RhBFmSQK-kZFzZpnuxWUg9nuVOsw@mail.gmail.com>
 <CAEym_HpXCfScRe-Q5Q1sgqUKNP416M=vW1c7iw+RFWXinnz1UA@mail.gmail.com>
 <CABDkGQ=Xa8mXoaFrMk+yQvGhqKa2fD4hHg0H6FccMQzt+kELfg@mail.gmail.com> <4F4B491D.5070902@mitotic-machine.org>
Message-ID: <CABDkGQ=YuUboZixonDcQB-gtjE7iBUOOKqNp43KkPR2Zj99mTw@mail.gmail.com>

On Mon, Feb 27, 2012 at 1:13 AM, Guillaume Gay
<guillaume at mitotic-machine.org> wrote:
> What do you mean by mask editor? Something like a slider to adjust a
> threshold with a superimposed mask?

It's often handy to manually construct a mask.  E.g., sometimes you
can see spikes in the FFT very clearly, and it would be useful to mark
those for filtering.  Another example of a mask editor would be to
select certain areas of an image, and mark it with given colors for
colorization:

http://www.cs.huji.ac.il/~yweiss/Colorization/

St?fan


From guillaume at mitotic-machine.org  Mon Feb 27 04:13:01 2012
From: guillaume at mitotic-machine.org (Guillaume Gay)
Date: Mon, 27 Feb 2012 10:13:01 +0100
Subject: Imshow and Linescan - first version
In-Reply-To: <CABDkGQ=Xa8mXoaFrMk+yQvGhqKa2fD4hHg0H6FccMQzt+kELfg@mail.gmail.com>
References: <0a962708-d617-45d0-b343-b7e774f23965@b23g2000yqn.googlegroups.com> <4F3E69CD.3010204@mitotic-machine.org> <CABDkGQ=wtY52bPL5+mpuN6t79uG5YKvie2sCD1z54gN+wNm1TA@mail.gmail.com> <4F422A54.9000902@mitotic-machine.org> <4F462170.4010206@mitotic-machine.org> <CAEym_HoaTkBxB59OH_uzH2sS04CcPuQ-0TUcdszpg47bbtP9+w@mail.gmail.com> <4F4743FD.20304@mitotic-machine.org> <CABDkGQ=4twsN65EKpD_+e=RhBFmSQK-kZFzZpnuxWUg9nuVOsw@mail.gmail.com> <CAEym_HpXCfScRe-Q5Q1sgqUKNP416M=vW1c7iw+RFWXinnz1UA@mail.gmail.com> <CABDkGQ=Xa8mXoaFrMk+yQvGhqKa2fD4hHg0H6FccMQzt+kELfg@mail.gmail.com>
Message-ID: <4F4B491D.5070902@mitotic-machine.org>

Le 26/02/2012 21:15, St?fan van der Walt a ?crit :
> On Sat, Feb 25, 2012 at 11:10 AM, Tony Yu<tsyu80 at gmail.com>  wrote:
>> Plugin system
>> ------
>> It might be nice to have some sort of plugin system for the image viewer.
>> That way, tools like this could be implemented a bit more easily and, also,
>> easily added to the viewer or ignored by the user.
> At the moment, we basically have a double-viewer implementation:
> simply vs fancy.  So we separate out
>
> imshow(x) and imshow(x, fancy=True)
I thought one solution was to sub-class FigureCanvas, with extra 
buttons, but from what I understand, it is not that easy to do this at 
the platform independant level.

  But maybe adding arguments to the function call, for exemple imshow(x, 
set_contrast=True, linescan=True) plus keyboard toggles is enough?

>
>> agree to an extent. Nevertheless, I think providing a viewer that supplies
>> *an infrastructure* for creating GUI tools might be really valuable. I
>> haven't really thought through what this plugin system would look like, so
>> it may just be a pipe dream.
> This is a tricky problem (which set of tools to use, etc.)--but in
> principle, it would be nice to have a few standard viewers, e.g.,
> image compare, image compare + parameter adjust, mask editor (to build
> custom filters, e.g.) and image inspector (like the one you and
> Guillaume are working on).
>
> St?fan
>
What do you mean by mask editor? Something like a slider to adjust a 
threshold with a superimposed mask?

Guillaume
-------------- next part --------------
A non-text attachment was scrubbed...
Name: guillaume.vcf
Type: text/x-vcard
Size: 282 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20120227/edcd03f6/attachment.vcf>

From stefan at sun.ac.za  Mon Feb 27 13:55:58 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 27 Feb 2012 10:55:58 -0800
Subject: [scikits-image] Restore previous io plugins (#152)
In-Reply-To: <4F4BCE74.7040303@gemini.edu>
References: <scikits-image/scikits-image/pull/152@github.com>
 <70C87030-C54F-4868-B772-75FA82CA8227@yale.edu> <CABDkGQ=gb_Lb+39PxZjZGO7=hCA7vWLFdDAThVQq=anmQ5hq6Q@mail.gmail.com>
 <4F4A954A.8070904@gmail.com> <CABDkGQkG0ACanWK9qixEuzOmMCK+tYMSEGFKmpPNkTuWmB8hDQ@mail.gmail.com>
 <4F4BCE74.7040303@gemini.edu>
Message-ID: <CABDkGQk09Eie89pr2CjFSxPSf+2gsCt92y9GiFOhHkbOD1w=OQ@mail.gmail.com>

On Mon, Feb 27, 2012 at 10:41 AM, James Turner <jturner at gemini.edu> wrote:
> I can try to look at this but it might take a couple of days to get
> to. Please let me know if you have Qs in the meantime (I'm not sure
> about auto-loading off the top of my head).

Thanks, James--we await your PR with great anticipation :)  Don't
worry about the auto-loading mechanics--we'll take care of that.

St?fan


From jturner at gemini.edu  Mon Feb 27 13:41:56 2012
From: jturner at gemini.edu (James Turner)
Date: Mon, 27 Feb 2012 15:41:56 -0300
Subject: [scikits-image] Restore previous io plugins (#152)
In-Reply-To: <CABDkGQkG0ACanWK9qixEuzOmMCK+tYMSEGFKmpPNkTuWmB8hDQ@mail.gmail.com>
References: <scikits-image/scikits-image/pull/152@github.com> <70C87030-C54F-4868-B772-75FA82CA8227@yale.edu> <CABDkGQ=gb_Lb+39PxZjZGO7=hCA7vWLFdDAThVQq=anmQ5hq6Q@mail.gmail.com> <4F4A954A.8070904@gmail.com> <CABDkGQkG0ACanWK9qixEuzOmMCK+tYMSEGFKmpPNkTuWmB8hDQ@mail.gmail.com>
Message-ID: <4F4BCE74.7040303@gemini.edu>

> Ideally, the ``imread(..., plugin='fits')`` functionality should
> auto-load the FITS-plugin---I should see why this is not currently
> working, because it seems like a bug.

Oh, did someone say FITS plugin? I've been meaning to get back to
that (sorry, too busy trying to finish up our Python distribution
for astronomy). I believe I had some uncommitted changes after SciPy
that we were pending me figuring out how to deal with metadata.

I can try to look at this but it might take a couple of days to get
to. Please let me know if you have Qs in the meantime (I'm not sure
about auto-loading off the top of my head).

Cheers,

James.


From tsyu80 at gmail.com  Tue Feb 28 00:20:55 2012
From: tsyu80 at gmail.com (Tony Yu)
Date: Tue, 28 Feb 2012 00:20:55 -0500
Subject: [scikits-image] Restore previous io plugins (#152)
In-Reply-To: <CABDkGQkG0ACanWK9qixEuzOmMCK+tYMSEGFKmpPNkTuWmB8hDQ@mail.gmail.com>
References: <scikits-image/scikits-image/pull/152@github.com>
	<70C87030-C54F-4868-B772-75FA82CA8227@yale.edu>
	<CABDkGQ=gb_Lb+39PxZjZGO7=hCA7vWLFdDAThVQq=anmQ5hq6Q@mail.gmail.com>
	<4F4A954A.8070904@gmail.com>
	<CABDkGQkG0ACanWK9qixEuzOmMCK+tYMSEGFKmpPNkTuWmB8hDQ@mail.gmail.com>
Message-ID: <CAEym_HpgjNSbzRcpW1Hju2VzvdOLAf33pALWjBtLH_f2EqVbqA@mail.gmail.com>

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

> On Sun, Feb 26, 2012 at 12:25 PM, Christoph Gohlke <cjgohlke at gmail.com>
> wrote:
> > Instead of restoring the default plugins after each test module, maybe it
> > would be better/cleaner/safer for the tests to never change the default
> > plugins but to just load the plugin and explicitly specify the plugin in
> > each imread, imwrite, etc. function call? It seems there is currently no
> way
> > to load a plugin without making it the default. This could be achieved by
> > changing the use_plugin function to accept another option for the `kind`
> > parameter, e.g. an empty string, signaling that the plugin should only be
> > loaded. Probably too late for the 0.5 release.
>
> Ideally, the ``imread(..., plugin='fits')`` functionality should
> auto-load the FITS-plugin---I should see why this is not currently
> working, because it seems like a bug.
>
> St?fan
>

I just submitted PR
#157<https://github.com/scikits-image/scikits-image/pull/157> to
address an error raised with non-loaded plugins. I'm not sure if this
addresses the issue you mention above, but it's related, at least.

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

From stefan at sun.ac.za  Wed Feb 29 18:13:48 2012
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 29 Feb 2012 15:13:48 -0800
Subject: RFC: Multiple backends + speedy looping
Message-ID: <CABDkGQnZezoXBq3XAiSYXj5_iTjQ--w9wrrnw3TfRyXBRG3nKw@mail.gmail.com>

Hello everyone,

After the skimage 0.5 release, it's time to start planning the Next
Big Thing (TM).  I hoped there would be a better solution by now, but
it seems that one of our main weak points is still that we cannot do
fast looping over images (e.g., filtering).

We have multiple computing back-end support available as a pull
request from Pieter Holtzhausen's GSOC--the code is fairly simple to
understand, and doesn't complicate the framework more than necessary.
This will allow us to, when doing convolutions e.g., first try doing
it via OpenCL, and then to fall back to the CPU.  We also have a full
testing framework in place, so that the output from different
back-ends are compared.

Have a look at the code here:

https://github.com/scikits-image/scikits-image/pull/14/files

If you have a better solution or other alternatives in mind, please
let me know; I'm keen to explore this space further.

Regards
St?fan