Mailman 3 December 2011 - scikit-image

31 Dec '11

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

1 0

Re: Need an advice
by Tony Yu 30 Dec '11

30 Dec '11

On Fri, Dec 30, 2011 at 5:48 PM, Ralf Gommers <ralf.gommers(a)googlemail.com>wrote: > > > On Fri, Dec 30, 2011 at 8:05 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > >> >> >> On Fri, Dec 30, 2011 at 1:19 PM, Ralf Gommers < >> ralf.gommers(a)googlemail.com> wrote: >> >>> >>> >>> On Fri, Dec 30, 2011 at 5:46 PM, Tony Yu <tsyu80(a)gmail.com> wrote: >>> >>>> >>>> >>>> On Fri, Dec 30, 2011 at 8:20 AM, Nadav Horesh <nadavh.horesh(a)gmail.com>wrote: >>>> >>>>> Remarks for the convolution subpackage: >>>>> 1. The __init__.py should be probably changed to >>>>> >>>>> from ext import pyconvolve as convolve >>>>> >>>> >>>> Agreed. Alternatively, the c-method could be renamed so that the python >>>> method in ext can be named convolve. >>>> >>>>> >>>>> 2. The test_convolution.py file is very instructive. It should be >>>>> polished a bit. I think it would be worthwhile to add also >>>>> scipy.signal.sepfir2d and cv2.sepFilter2D to the test. >>>>> >>>> >>>>> 3. I found the convolve speed in par with cv.convolve2d (it can be >>>>> slower or faster depending on the kernel) >>>>> >>>>> Nadav >>>>> >>>> >>>> Thanks for testing the code. >>>> >>>> I've got the code compiling on my system now, so I was able to clean up >>>> a few things. Could you update to what's currently on my >>>> skimage-convolution branch to check that it builds on your system? If not, >>>> what flags do you have to change/add to get it to compile? >>>> >>>> -Tony >>>> >>>> P.S. If any one else is building this on OS X: ppc compatible builds is >>>> turned on by default (at least on my system). This should be turned off >>>> before building. Add the following line to ~/.profile, or just run it right >>>> before building: >>>> >>>> export ARCH_FLAGS="-arch i386 -arch x86_64" >>>> >>> >>> Can you explain why is this necessary? >>> >>> In convolution/setup.py I also see you add "-ffast-math", which is a >>> GCC-specific flag. It's better to remove it I think, it may give problems >>> with other compilers. >>> >>> Ralf >>> >> >> On my system at least, running gcc will, by default, add "-arch ppc" >> along with i386 and x86_64. As far as I can tell, PPC doesn't support SSE, >> which is used by this implementation. >> > > That's true. I can't tell for sure, but it seems that this code is not > optional. Meaning PPC is unsupported, and the ARCH_FLAGS need to be defined > on OS X. I'm only a very occasional user now so it doesn't bother me too > much, but isn't this a large penalty for the benefit you get? > Well, I assume that we would be able to add a check to disable the build on unsupported architectures. As far as, whether it's worth it: I don't know. Is PPC very common? I'm only familiar with it in the context of old Apple computers. From the Wikipedia page <http://en.wikipedia.org/wiki/PowerPC>, it seems like PPC is mainly used in servers now. As for the benefit: I think getting close to the performance of OpenCV is pretty significant. (On my system, however, I don't quite see the performance boost that Nadav sees: skimage: 0.034 secs, ndimage: 0.089 secs, opencv: 0.018 secs, for the output of 'test_convolution.py'---nevertheless, it's a significant improvement over ndimage). And, in comparison, OpenCV can be incredibly difficult to build. There are probably other ways to get similar performance, but like I said, I don't do any serious non-Python coding, so I have no idea what those alternatives may be. Stefan and Pieter (the original author of this code) have probably thought this through a bit more. -Tony >> The flag is left over from the original implementation. Removing >> "-ffast-math" works fine on my system. To be honest, I don't do much >> non-Python coding so I don't know the implications of adding/removing the >> flag. >> > > It's very likely to give problems with unusual (or even Intel) compilers I > think. > > Ralf > >

1 0

Re: Need an advice
by Ralf Gommers 30 Dec '11

30 Dec '11

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

1 0

Re: Need an advice
by Tony Yu 30 Dec '11

30 Dec '11

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

1 0

Re: Need an advice
by Ralf Gommers 30 Dec '11

30 Dec '11

On Fri, Dec 30, 2011 at 5:46 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > > > On Fri, Dec 30, 2011 at 8:20 AM, Nadav Horesh <nadavh.horesh(a)gmail.com>wrote: > >> Remarks for the convolution subpackage: >> 1. The __init__.py should be probably changed to >> >> from ext import pyconvolve as convolve >> > > Agreed. Alternatively, the c-method could be renamed so that the python > method in ext can be named convolve. > >> >> 2. The test_convolution.py file is very instructive. It should be >> polished a bit. I think it would be worthwhile to add also >> scipy.signal.sepfir2d and cv2.sepFilter2D to the test. >> > >> 3. I found the convolve speed in par with cv.convolve2d (it can be slower >> or faster depending on the kernel) >> >> Nadav >> > > Thanks for testing the code. > > I've got the code compiling on my system now, so I was able to clean up a > few things. Could you update to what's currently on my skimage-convolution > branch to check that it builds on your system? If not, what flags do you > have to change/add to get it to compile? > > -Tony > > P.S. If any one else is building this on OS X: ppc compatible builds is > turned on by default (at least on my system). This should be turned off > before building. Add the following line to ~/.profile, or just run it right > before building: > > export ARCH_FLAGS="-arch i386 -arch x86_64" > Can you explain why is this necessary? In convolution/setup.py I also see you add "-ffast-math", which is a GCC-specific flag. It's better to remove it I think, it may give problems with other compilers. Ralf > > > >> >> 2011/12/28 Nadav Horesh <nadavh.horesh(a)gmail.com> >> >>> I compiled after setting the flags for a core2 linux machine. A quick >>> and dirty benchmark showed a x2 improvement over scipy.signal.sepfir2d. >>> I think that are some declaration errors in the python code (for >>> instance I think that the convolution __init__.py should be >>> >>> from ext import pyconvolve >>> >>> instead of >>> >>> from ext import convolve >>> >>> I'll take a closer look later. >>> >>> Thank you, >>> >>> Nadav. >>> >>> >>> >>> 2011/12/28 Tony Yu <tsyu80(a)gmail.com> >>> >>>> >>>> >>>> On Tue, Dec 27, 2011 at 8:24 PM, Tony Yu <tsyu80(a)gmail.com> wrote: >>>> >>>>> >>>>> >>>>> On Tue, Dec 27, 2011 at 8:29 AM, Nadav Horesh <nadavh.horesh(a)gmail.com >>>>> > wrote: >>>>> >>>>>> How can I get it? >>>>>> >>>>>> Nadav >>>>>> >>>>> >>>>> The code Stefan mentioned is in an old pull request (PR #16<https://github.com/scikits-image/scikits-image/pull/16>). >>>>> That PR is from before the switch from scikits.image to skimage. I've made >>>>> a new branch<https://github.com/tonysyu/scikits-image/commits/skimage-convolution>in my git repo with the convolution code in the new namespace. >>>>> >>>>> If you're already running skimage from git, then you can use git to >>>>> clone this branch: >>>>> >>>>> git remote -f add tonysyu git@github.com:tonysyu/scikits-image.git >>>>> git checkout -b convolution tonysyu/skimage-convolution >>>>> >>>>> >>>>> In case this isn't familiar: The first line adds my git repo to your >>>>> list of remotes, and the "-f" flag fetches the tags from my repo (this >>>>> ensures that you have the info about my branches). My repo is now added to >>>>> your repo as a remote with the name "tonysyu" (you can change this). The >>>>> second line creates a new branch "convolution", clones my >>>>> "skimage-convolution" branch into it, and checks it out. >>>>> >>>>> Hope that helps, >>>>> -Tony >>>>> >>>> >>>> Oops, I forgot to mention: I added a compile flag that is specific to >>>> my system (In convolution/setup.py there's an include flag '-I/usr/...') >>>> that should probably be removed. Also, I should mention that I haven't >>>> gotten this branch to compile on my system (OSX). I believe it should >>>> compile OK on Linux (after removing the '-I/usr/...' compile flag). >>>> >>>> Good luck, >>>> -Tony >>>> >>>>> >>>>> 2011/12/23 Stéfan van der Walt <stefan(a)sun.ac.za> >>>>> >>>>>> On Thu, Dec 22, 2011 at 10:44 PM, Nadav Horesh < >>>>>> nadavh.horesh(a)gmail.com> wrote: >>>>>> > The application is not too sophisticated, and I do use numpy, scipy >>>>>> and >>>>>> > skimage for all I need. The only problem is speed, I need the >>>>>> processing to >>>>>> > be at l5-10 time faster. Convolutions take most of the processing >>>>>> time. I >>>>>> > prefer a flexible solution that would speed up also common >>>>>> nonlinear filters >>>>>> > (i.e. a median filter). >>>>>> >>>>>> We have a PR in the pipeline for doing really, really fast >>>>>> convolutions... but it needs a bit of work. Would you like to have a >>>>>> look at it? >>>>>> >>>>>> Stéfan >>>>>> >>>>> >>>> >>>> >

1 0

Re: Need an advice
by Stéfan van der Walt 30 Dec '11

30 Dec '11

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

1 0

Re: Need an advice
by Tony Yu 30 Dec '11

30 Dec '11

On Fri, Dec 30, 2011 at 8:20 AM, Nadav Horesh <nadavh.horesh(a)gmail.com>wrote: > Remarks for the convolution subpackage: > 1. The __init__.py should be probably changed to > > from ext import pyconvolve as convolve > Agreed. Alternatively, the c-method could be renamed so that the python method in ext can be named convolve. > > 2. The test_convolution.py file is very instructive. It should be polished > a bit. I think it would be worthwhile to add also scipy.signal.sepfir2d > and cv2.sepFilter2D to the test. > > 3. I found the convolve speed in par with cv.convolve2d (it can be slower > or faster depending on the kernel) > > Nadav > Thanks for testing the code. I've got the code compiling on my system now, so I was able to clean up a few things. Could you update to what's currently on my skimage-convolution branch to check that it builds on your system? If not, what flags do you have to change/add to get it to compile? -Tony P.S. If any one else is building this on OS X: ppc compatible builds is turned on by default (at least on my system). This should be turned off before building. Add the following line to ~/.profile, or just run it right before building: export ARCH_FLAGS="-arch i386 -arch x86_64" > > 2011/12/28 Nadav Horesh <nadavh.horesh(a)gmail.com> > >> I compiled after setting the flags for a core2 linux machine. A quick >> and dirty benchmark showed a x2 improvement over scipy.signal.sepfir2d. >> I think that are some declaration errors in the python code (for instance >> I think that the convolution __init__.py should be >> >> from ext import pyconvolve >> >> instead of >> >> from ext import convolve >> >> I'll take a closer look later. >> >> Thank you, >> >> Nadav. >> >> >> >> 2011/12/28 Tony Yu <tsyu80(a)gmail.com> >> >>> >>> >>> On Tue, Dec 27, 2011 at 8:24 PM, Tony Yu <tsyu80(a)gmail.com> wrote: >>> >>>> >>>> >>>> On Tue, Dec 27, 2011 at 8:29 AM, Nadav Horesh <nadavh.horesh(a)gmail.com>wrote: >>>> >>>>> How can I get it? >>>>> >>>>> Nadav >>>>> >>>> >>>> The code Stefan mentioned is in an old pull request (PR #16<https://github.com/scikits-image/scikits-image/pull/16>). >>>> That PR is from before the switch from scikits.image to skimage. I've made >>>> a new branch<https://github.com/tonysyu/scikits-image/commits/skimage-convolution>in my git repo with the convolution code in the new namespace. >>>> >>>> If you're already running skimage from git, then you can use git to >>>> clone this branch: >>>> >>>> git remote -f add tonysyu git@github.com:tonysyu/scikits-image.git >>>> git checkout -b convolution tonysyu/skimage-convolution >>>> >>>> >>>> In case this isn't familiar: The first line adds my git repo to your >>>> list of remotes, and the "-f" flag fetches the tags from my repo (this >>>> ensures that you have the info about my branches). My repo is now added to >>>> your repo as a remote with the name "tonysyu" (you can change this). The >>>> second line creates a new branch "convolution", clones my >>>> "skimage-convolution" branch into it, and checks it out. >>>> >>>> Hope that helps, >>>> -Tony >>>> >>> >>> Oops, I forgot to mention: I added a compile flag that is specific to my >>> system (In convolution/setup.py there's an include flag '-I/usr/...') that >>> should probably be removed. Also, I should mention that I haven't gotten >>> this branch to compile on my system (OSX). I believe it should compile OK >>> on Linux (after removing the '-I/usr/...' compile flag). >>> >>> Good luck, >>> -Tony >>> >>>> >>>> 2011/12/23 Stéfan van der Walt <stefan(a)sun.ac.za> >>>> >>>>> On Thu, Dec 22, 2011 at 10:44 PM, Nadav Horesh < >>>>> nadavh.horesh(a)gmail.com> wrote: >>>>> > The application is not too sophisticated, and I do use numpy, scipy >>>>> and >>>>> > skimage for all I need. The only problem is speed, I need the >>>>> processing to >>>>> > be at l5-10 time faster. Convolutions take most of the processing >>>>> time. I >>>>> > prefer a flexible solution that would speed up also common nonlinear >>>>> filters >>>>> > (i.e. a median filter). >>>>> >>>>> We have a PR in the pipeline for doing really, really fast >>>>> convolutions... but it needs a bit of work. Would you like to have a >>>>> look at it? >>>>> >>>>> Stéfan >>>>> >>>> >>> >>>

1 0

Re: watershed issue
by Tony Yu 30 Dec '11

30 Dec '11

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

1 0

Re: Need an advice
by Nadav Horesh 30 Dec '11

30 Dec '11

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

1 0

watershed issue
by jip 30 Dec '11

30 Dec '11

Dear all, I try to use watershed implemenation in skimage, compared with scipy as follow: # -*- coding: utf-8 -*- """ Created on Thu Dec 22 13:45:46 2011 @author: Jean-Patrick Pommier Telomeres quantification at low resolution with skimage """ import scipy.ndimage as nd import pylab as plb import numpy as np import skimage as sk import skimage.morphology as mo import skimage.io as io import skimage.filter.edges as edges #import mahotas as mh #import pymorph def gray12_to_8(im): '''Converts a 12 bits image to 8 bits ''' i=0.062271062*im return np.uint8(i) def Hipass(im,size=9): '''returns a hipass filtered image with background >=0 with a gaussian filter of size size=9 by default''' blur=blur=nd.gaussian_filter(im,size) hi=im-1.0*blur-5 mask=np.copy(hi) hi[mask<0]=0 return hi def gray_dist(im): '''Build a pseudo distance map from a high pass filtered image suitable for watershed''' f=Hipass(im,9) dist=f.max()-f dist -= dist.min() dist = dist/float(dist.ptp()) * 255 dist = dist.astype(np.uint8) return dist #============================================================================== # images #============================================================================== path="/home/claire/Applications/ImagesTest/JPP50/16/" CC="DAPI/" PR="CY3/" im="1.TIF" #sk.io.use_plugin('gdal', 'imread') sk.io.use_plugin('freeimage', 'imread') sk.io.use_plugin('matplotlib', 'imshow') dapi=io.imread(path+CC+im) cy3=io.imread(path+PR+im) #============================================================================= # Extracting known nuclei #============================================================================== nuc=dapi[215:264,1151:1198] telo=cy3[215:264,1151:1198] telo=np.uint16(telo) #============================================================================== # Telomeres Segmentation with skimage & ndimage print telo.dtype se=mo.disk(7) top=mo.greyscale_white_top_hat(gray12_to_8(telo),se) #print top.min(),top.max(),top.dtype hi=np.uint8(Hipass(top,size=9)) #print hi.min(), hi.max(),hi.dtype dist=nd.distance_transform_bf(top>10) bassin_dist=np.uint16(dist.max()-dist) bassin_hi=hi.max()-hi remax=mo.is_local_maximum(bassin_hi,hi>6) markers,n=nd.label(remax) print n, 'spots detected' edgesmap=edges.sobel(hi) seg=sk.morphology.watershed(edgesmap,markers,top>30) segn=nd.watershed_ift(bassin_hi,markers) segn_mark_dist=nd.watershed_ift(bassin_dist,markers) #============================================================================== # Quantification #============================================================================== print top.shape,top.dtype #print np.shape(seg),np.dtype(seg) #spots_I=nd.measurements.sum(top,seg) #print spots_I #============================================================================== # #============================================================================== plb.figure(1) plb.subplot(341,frameon=False, xticks=[], yticks=[]) plb.title('raw 12bits') plb.imshow(telo) plb.subplot(342,frameon=False, xticks=[], yticks=[]) plb.title('top Hat') plb.imshow(top) plb.subplot(343,frameon=False, xticks=[], yticks=[]) plb.title('hiP') plb.imshow(hi) plb.subplot(344,frameon=False, xticks=[], yticks=[]) plb.title('regional max') plb.imshow(remax,interpolation=None) plb.subplot(345,frameon=False, xticks=[], yticks=[]) plb.title('markers') plb.imshow(markers,interpolation=None) plb.subplot(346,frameon=False, xticks=[], yticks=[]) plb.title('bassin=hi') plb.imshow(bassin_hi,interpolation=None) plb.subplot(347,frameon=False, xticks=[], yticks=[]) plb.title('bassin dist') plb.imshow(bassin_dist,interpolation=None) plb.subplot(348,frameon=False, xticks=[], yticks=[]) plb.title('hi+mark (nd)') plb.imshow(segn,interpolation=None) plb.subplot(349,frameon=False, xticks=[], yticks=[]) plb.title('sobel (sk)') plb.imshow(edgesmap,interpolation=None) plb.subplot(3,4,10,frameon=False, xticks=[], yticks=[]) plb.title('sob+mark (sk)') plb.imshow(seg,interpolation=None) plb.subplot(3,4,12,frameon=False, xticks=[], yticks=[]) plb.title('dist+mark (nd)') plb.imshow(segn_mark_dist,interpolation=None) plb.show() <https://lh5.googleusercontent.com/-OBPfUOGJNok/TvtKO_6q20I/AAAAAAAAAqw/6VX7…> I get a strange result, see the "sob+mark (sk)" image, compared to the segmentations obtained with the scipy implementation. Is it a skimage bug ? Best regards. Jean-Patrick

3 3

Rescale intensity function [was: Asymmetric behavior in dtype conversion]
by Tony Yu 29 Dec '11

29 Dec '11

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

1 0

Re: Need an advice
by Nadav Horesh 28 Dec '11

28 Dec '11

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

1 0

Re: Need an advice
by Tony Yu 27 Dec '11

27 Dec '11

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

1 0

Re: Need an advice
by Tony Yu 27 Dec '11

27 Dec '11

On Tue, Dec 27, 2011 at 8:29 AM, Nadav Horesh <nadavh.horesh(a)gmail.com>wrote: > How can I get it? > > Nadav > The code Stefan mentioned is in an old pull request (PR #16<https://github.com/scikits-image/scikits-image/pull/16>). That PR is from before the switch from scikits.image to skimage. I've made a new branch<https://github.com/tonysyu/scikits-image/commits/skimage-convolution>in my git repo with the convolution code in the new namespace. If you're already running skimage from git, then you can use git to clone this branch: git remote -f add tonysyu git@github.com:tonysyu/scikits-image.git git checkout -b convolution tonysyu/skimage-convolution In case this isn't familiar: The first line adds my git repo to your list of remotes, and the "-f" flag fetches the tags from my repo (this ensures that you have the info about my branches). My repo is now added to your repo as a remote with the name "tonysyu" (you can change this). The second line creates a new branch "convolution", clones my "skimage-convolution" branch into it, and checks it out. Hope that helps, -Tony > 2011/12/23 Stéfan van der Walt <stefan(a)sun.ac.za> > >> On Thu, Dec 22, 2011 at 10:44 PM, Nadav Horesh <nadavh.horesh(a)gmail.com> >> wrote: >> > The application is not too sophisticated, and I do use numpy, scipy and >> > skimage for all I need. The only problem is speed, I need the >> processing to >> > be at l5-10 time faster. Convolutions take most of the processing time. >> I >> > prefer a flexible solution that would speed up also common nonlinear >> filters >> > (i.e. a median filter). >> >> We have a PR in the pipeline for doing really, really fast >> convolutions... but it needs a bit of work. Would you like to have a >> look at it? >> >> Stéfan >> >

1 0

Re: Need an advice
by Nadav Horesh 27 Dec '11

27 Dec '11

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

1 0

Re: plugin freeimage vs gdal on 0.5dev
by jip 27 Dec '11

27 Dec '11

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

1 0

Pull request visualisation
by Stéfan van der Walt 26 Dec '11

26 Dec '11

Here's an illustration of our GitHub pull-request activity over the last while. It's modest, still, but those humps are good news! https://plus.google.com/u/0/104831275312843762750/posts/dHzc6cQfyhV

1 0

Re: PKG: Cant seem to build scikits debian package from source
by Jerome Kieffer 23 Dec '11

23 Dec '11

On Fri, 23 Dec 2011 12:28:33 +0530 harish badrinath <harishbadrinath(a)gmail.com> wrote: > Hello, > I cant seem to build scikits-image from source using debuild. > > Here are the steps i followed: > a)I checkout master and debian branches in seprate directories. > b) export master branch as a tar ball > c) run dh_make (a debian specific packaging helper script) > d) copy the contents of the debian directory to the directory in which > i ran dh_make > e) run debbuild I suggest you to install python-stdeb (on recent ubuntu/debian systems) then simply use the setup.py: python setup.py --command-packages=stdeb.command bdist_deb to create a debian package. Most of the case it works out of the box (I just tested on scikits-git and it is OK). Cheers -- Jerome Kieffer <google(a)terre-adelie.org>

1 0

Re: PKG: Cant seem to build scikits debian package from source
by Nadav Horesh 23 Dec '11

23 Dec '11

There is a new import statement syntax. I think you should upgrade your python. I have no experience with Debian, but on the seveal other linux distros I used this upgrade is easy and harmless. Nadav. 2011/12/23 harish badrinath <harishbadrinath(a)gmail.com> > Hello, > I cant seem to build scikits-image from source using debuild. > > Here are the steps i followed: > a)I checkout master and debian branches in seprate directories. > b) export master branch as a tar ball > c) run dh_make (a debian specific packaging helper script) > d) copy the contents of the debian directory to the directory in which > i ran dh_make > e) run debbuild > > The log of the build is > <snip> > dh clean --buildsystem python_distutils > dh_testdir -O--buildsystem=python_distutils > dh_auto_clean -O--buildsystem=python_distutils > Traceback (most recent call last): > File "setup.py", line 101, in <module> > cmdclass={'build_py': build_py}, > File "/usr/lib/pymodules/python2.5/numpy/distutils/core.py", line > 152, in setup > config = configuration() > File "setup.py", line 42, in configuration > config.add_subpackage('skimage') > File "/usr/lib/pymodules/python2.5/numpy/distutils/misc_util.py", > line 957, in add_subpackage > caller_level = 2) > File "/usr/lib/pymodules/python2.5/numpy/distutils/misc_util.py", > line 926, in get_subpackage > caller_level = caller_level + 1) > File "/usr/lib/pymodules/python2.5/numpy/distutils/misc_util.py", > line 863, in _get_configuration_from_setup_py > config = setup_module.configuration(*args) > File "skimage/setup.py", line 8, in configuration > config.add_subpackage('graph') > File "/usr/lib/pymodules/python2.5/numpy/distutils/misc_util.py", > line 957, in add_subpackage > caller_level = 2) > File "/usr/lib/pymodules/python2.5/numpy/distutils/misc_util.py", > line 926, in get_subpackage > caller_level = caller_level + 1) > File "/usr/lib/pymodules/python2.5/numpy/distutils/misc_util.py", > line 848, in _get_configuration_from_setup_py > ('.py', 'U', 1)) > File "skimage/graph/setup.py", line 3, in <module> > from skimage._build import cython > File > "/home/code/projs/scikits-image-master/scikits-image-0.4/skimage/__init__.py", > line 64 > from .util.dtype import * > SyntaxError: 'import *' not allowed with 'from .' > dh_auto_clean: python2.5 setup.py clean -a returned exit code 1 > make: *** [clean] Error 1 > dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit > status 2 > debuild: fatal error at line 1325: > dpkg-buildpackage -rfakeroot -D -us -uc failed > </snip> > Since i have very little experience with python, its build system, etc > any help would be appreciated. > > Regards, > Harish >

1 0

Re: Need an advice
by Nadav Horesh 23 Dec '11

23 Dec '11

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

1 0

Re: Need an advice
by Stéfan van der Walt 23 Dec '11

23 Dec '11

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

1 0

PKG: Cant seem to build scikits debian package from source
by harish badrinath 22 Dec '11

22 Dec '11

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

1 0

Re: Need an advice
by Nadav Horesh 22 Dec '11

22 Dec '11

The application is not too sophisticated, and I do use numpy, scipy and skimage for all I need. The only problem is speed, I need the processing to be at l5-10 time faster. Convolutions take most of the processing time. I prefer a flexible solution that would speed up also common nonlinear filters (i.e. a median filter). Nadav, 2011/12/22 Jaidev Deshpande <deshpande.jaidev(a)gmail.com> > On Fri, Dec 23, 2011 at 1:42 AM, Nadav Horesh <nadavh.horesh(a)gmail.com> > wrote: > > > >Currently in use are filters and array processing from numpy, > scipy.signal, scipy.ndimage and numexpr. I am looking for faster tools that > cold be used without any extensive learning period. > > Are filters all you're looking for? If yes, and if your application > isn't too sophisticated, you can simply use NumPy arrays as filters. > Or else try scikits-image. > > What kind of filtering is it, and what's the application? > > Best, > Jaidev >

1 0

Re: Need an advice
by Emmanuelle Gouillart 22 Dec '11

22 Dec '11

Hi Nadav, would you need everything to be faster, or do you have some identified bottlenecks that take most of the computing time? In the latter case, you may want to keep using the most standard tools for most image processing steps, and pick a specialized and fast module for the most critical steps, like OpenCV. Also, the algorithms in scikits-image shouldn't do too bad in terms of executing speed, since they rely either on numpy arrays or on Cython code: what speed factor would you expect to gain with another library such as OpenCV? As for alternative librairies, ITK is very powerful and fast and has Python bindings. The learning curve looks a bit steep, though. Cheers, Emmanuelle On Thu, Dec 22, 2011 at 10:12:59PM +0200, Nadav Horesh wrote: > I have several scripts dealing with image procession of digital cameras > raw data. Currently in use are filters and array processing from numpy, > scipy.signal, scipy.ndimage and numexpr. I am looking for faster tools > that cold be used without any extensive learning period. I came up of the > following options: > 1, Theano: Can be very fast, but missing some important features� like a > median filter > 2. OpenCV: Fast and features rich, but the interface is not easy to learn. > Any recommendation for alternative libraries or easy interfaces to opencv? > (I looked at pyopencv, but the project doen't seems to be alive these > days) > �� Nadav

1 0

Re: plugin freeimage vs gdal on 0.5dev
by jip 22 Dec '11

22 Dec '11

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

1 0

Re: Need an advice
by Jaidev Deshpande 22 Dec '11

22 Dec '11

On Fri, Dec 23, 2011 at 1:42 AM, Nadav Horesh <nadavh.horesh(a)gmail.com> wrote: > >Currently in use are filters and array processing from numpy, scipy.signal, scipy.ndimage and numexpr. I am looking for faster tools that cold be used without any extensive learning period. Are filters all you're looking for? If yes, and if your application isn't too sophisticated, you can simply use NumPy arrays as filters. Or else try scikits-image. What kind of filtering is it, and what's the application? Best, Jaidev

1 0

Need an advice
by Nadav Horesh 22 Dec '11

22 Dec '11

I have several scripts dealing with image procession of digital cameras raw data. Currently in use are filters and array processing from numpy, scipy.signal, scipy.ndimage and numexpr. I am looking for faster tools that cold be used without any extensive learning period. I came up of the following options: 1, Theano: Can be very fast, but missing some important features like a median filter 2. OpenCV: Fast and features rich, but the interface is not easy to learn. Any recommendation for alternative libraries or easy interfaces to opencv? (I looked at pyopencv, but the project doen't seems to be alive these days) Nadav

1 0

Re: plugin freeimage vs gdal on 0.5dev
by Nelle Varoquaux 22 Dec '11

22 Dec '11

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

1 0

Re: plugin freeimage vs gdal on 0.5dev
by jip 22 Dec '11

22 Dec '11

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

1 0

How to update skimage 0.5dev
by jip 22 Dec '11

22 Dec '11

Dear all, I'd like to update skimage 0.5dev. I read somewhere that I need not to download the whole archive from github and rebuild from scratch for every update. sudo easy_install -U skimage fails I there a command to do the work? Thank you. Jean-Patrick Pommier

2 1

plugin freeimage vs gdal on 0.5dev
by jip 22 Dec '11

22 Dec '11

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

2 1

Re: morphology.label() bug?
by Stéfan van der Walt 22 Dec '11

22 Dec '11

On Wed, Dec 21, 2011 at 10:39 PM, karoyakani <tj.takei(a)gmail.com> wrote: >> I don't like having background == 0, but I'll settle for background == >> -1 as a default. > > Thanks! Please review the PR at: https://github.com/scikits-image/scikits-image/pull/105 > Or, len(np.unique(labels)) - 1, if we do not count the background in. Or, as Tony mentioned: labels.max() Cheers Stéfan

1 0

Re: morphology.label() bug?
by Stéfan van der Walt 22 Dec '11

22 Dec '11

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

1 0

Re: Video io, 'get' not working with OpenCv
by Stéfan van der Walt 22 Dec '11

22 Dec '11

Hi Pieter On Thu, Dec 22, 2011 at 2:40 AM, Pieter Holtzhausen <holtzhau(a)gmail.com> wrote: > Seems like the python bindings disabled that functionality > https://code.ros.org/trac/opencv/changeset/6358 Could you perhaps put together a PR to address this issue? That'd be much appreciated. Stéfan

1 0

Re: Video io, 'get' not working with OpenCv
by Pieter Holtzhausen 22 Dec '11

22 Dec '11

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

1 0

Re: Video io, 'get' not working with OpenCv
by robbert 22 Dec '11

22 Dec '11

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

2 1

Re: morphology.label() bug?
by karoyakani 21 Dec '11

21 Dec '11

On Dec 21, 2:02 pm, Stéfan van der Walt <ste...(a)sun.ac.za> wrote: ... > I don't like having background == 0, but I'll settle for background == > -1 as a default. Thanks! > > Regarding connectedness, both matlab and ndimage have options of 8- > > connect and 4-connect. ... > > That's been added in the patch I proposed. Thanks!! > > Regarding number of labeled regions (not counting the background > > regions), again matlab and ndimage compute and return it. ... > > This is a one-liner: len(np.unique(labels)) Or, len(np.unique(labels)) - 1, if we do not count the background in. I tend to think that is a norm when we consider the background special. Yet who cares if the output does not include the number of regions. Regards, TJ

1 0

Re: Asymmetric behavior in dtype conversion
by Stéfan van der Walt 21 Dec '11

21 Dec '11

On Wed, Dec 21, 2011 at 11:16 AM, Tony Yu <tsyu80(a)gmail.com> wrote: > I've definitely been bit by example 1 many times. > > I think we should check that float images are between 0 and 1 in > ``util.dtype._convert`` (and either warn or raise an error), but we > shouldn't have to worry about it elsewhere. That doesn't really solve the > issue, so... This check is cheap enough that we should just add it (it may save more time than it costs in the end). The rest of the examples are fairly unusual, and since there's no way to automatically detect those situations, we'll just expect the users to correctly scale their data before using it (I am not opposed to adding utility functions for that purpose, though). Stéfan

1 0

Re: morphology.label() bug?
by Stéfan van der Walt 21 Dec '11

21 Dec '11

On Sat, Dec 17, 2011 at 7:36 PM, karoyakani <tj.takei(a)gmail.com> wrote: > It's very useful and common that we assume Background:="0"-value > pixels. > ndimage and matlab do so. > I don't know why skimage doesn't. I don't like having background == 0, but I'll settle for background == -1 as a default. > Regarding connectedness, both matlab and ndimage have options of 8- > connect and 4-connect. > Meantime skimage has only 8-connect. > Why don't we add 4-connect as an option? That's been added in the patch I proposed. > Regarding number of labeled regions (not counting the background > regions), again matlab and ndimage compute and return it. > Why don't we add it to the skimage, as it would be very useful to > users? This is a one-liner: len(np.unique(labels)) Cheers Stéfan

1 0

Re: morphology.label() bug?
by Tony Yu 21 Dec '11

21 Dec '11

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

1 0

Re: Asymmetric behavior in dtype conversion
by Christoph Gohlke 21 Dec '11

21 Dec '11

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

2 1

Re: Asymmetric behavior in dtype conversion
by Stéfan van der Walt 21 Dec '11

21 Dec '11

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

1 0

Re: Asymmetric behavior in dtype conversion
by Christoph Gohlke 21 Dec '11

21 Dec '11

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

1 0

Asymmetric behavior in dtype conversion
by Tony Yu 21 Dec '11

21 Dec '11

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

1 0

Re: A bug in skimage.io
by Nadav Horesh 20 Dec '11

20 Dec '11

That is it. Nadav 2011/12/20 Stéfan van der Walt <stefan(a)sun.ac.za> > On Mon, Dec 19, 2011 at 11:00 PM, Nadav Horesh <nadavh.horesh(a)gmail.com> > wrote: > > the for loop should be changed to > > > > for i in range(len(self.chunks)): > > Good catch, thanks Nadav. Please verify that I made the correct change: > > > https://github.com/scikits-image/scikits-image/commit/4df36631f64285b88bdfd… > > Cheers > Stéfan >

1 0

Re: New Doodle poll: "Scientific Python packages: Popularity check" (fwd)
by Stéfan van der Walt 20 Dec '11

20 Dec '11

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

1 0

New Doodle poll: "Scientific Python packages: Popularity check" (fwd)
by Stéfan van der Walt 20 Dec '11

20 Dec '11

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

1 0

[SciPy-User] New Doodle poll: "Scientific Python packages: Popularity check" (fwd)
by Emmanuelle Gouillart 20 Dec '11

20 Dec '11

----- Forwarded message from Pierre Raybaut <pierre.raybaut(a)gmail.com> ----- Date: Tue, 20 Dec 2011 11:17:50 +0100 From: Pierre Raybaut <pierre.raybaut(a)gmail.com> To: pythonxy(a)googlegroups.com, scipy-user <scipy-user(a)scipy.org> Subject: [SciPy-User] New Doodle poll: "Scientific Python packages: Popularity check" Reply-To: SciPy Users List <scipy-user(a)scipy.org> Hi all, Three years ago (day for day... that's weird!), I made a Doodle poll for estimating ~scientific Python packages popularity. Things have changed since then and I propose a new poll here: http://www.doodle.com/rzssq2dbnus4a34r This poll is intended to identify the most popular scientific Python packages to be included in the Python(x,y) distribution. However, even if the package list is *not* exhaustive, I'm sure that people who are not interested in Python(x,y) will find the poll results interesting anyway. Thank you for your participation, and please spread the word! -Pierre _______________________________________________ SciPy-User mailing list SciPy-User(a)scipy.org http://mail.scipy.org/mailman/listinfo/scipy-user ----- End forwarded message -----

1 0

Re: A bug in skimage.io
by Stéfan van der Walt 20 Dec '11

20 Dec '11

On Mon, Dec 19, 2011 at 11:00 PM, Nadav Horesh <nadavh.horesh(a)gmail.com> wrote: > the for loop should be changed to > > for i in range(len(self.chunks)): Good catch, thanks Nadav. Please verify that I made the correct change: https://github.com/scikits-image/scikits-image/commit/4df36631f64285b88bdfd… Cheers Stéfan

1 0

A bug in skimage.io
by Nadav Horesh 19 Dec '11

19 Dec '11

In the file skimage/io/_plugins/util.py line 215 the for loop should be changed to for i in range(len(self.chunks)): this change let it work on my PC (linux, 4 real core + 4 virtual (with hyperthreading)), since there there self.cores == 8 and len(self(chunks)) == 4 Nadav

1 0

Video io, 'get' not working with OpenCv
by robbert 17 Dec '11

17 Dec '11

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

3 3

Re: morphology.label() bug?
by karoyakani 17 Dec '11

17 Dec '11

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

1 0

Re: morphology.label() bug?
by Emmanuelle Gouillart 17 Dec '11

17 Dec '11

> > a = np.array([ > > Ã¯Â¿Â½ Ã¯Â¿Â½[0,1,1,0,0,0], > > Ã¯Â¿Â½ Ã¯Â¿Â½[0,1,1,0,1,0], > > Ã¯Â¿Â½ Ã¯Â¿Â½[0,0,0,1,1,1], > > Ã¯Â¿Â½ Ã¯Â¿Â½[0,0,0,0,1,0]]) > This is the correct output, since the zero is not connected to any > other region. In fact, ndimage labels it incorrectly as: > array([[0, 1, 1, 0, 0, 0], > [0, 1, 1, 0, 1, 0], > [0, 0, 0, 1, 1, 1], > [0, 0, 0, 0, 1, 0]]) Well, this is not incorrect, since ndimage.label only labels connected components of the foreground (True pixels). Emmanuelle

2 1

morphology.label() bug?
by karoyakani 16 Dec '11

16 Dec '11

Hi Group, lable() of my skimage 0.4.2 generates a wierd label value "2" at the bottom-right corner. a = np.array([ [0,1,1,0,0,0], [0,1,1,0,1,0], [0,0,0,1,1,1], [0,0,0,0,1,0]]) from skimage import morphology morphology.label(a) Out[]: array([ [0, 1, 1, 0, 0, 0], [0, 1, 1, 0, 1, 0], [0, 0, 0, 1, 1, 1], [0, 0, 0, 0, 1, 2]]) Is this a bug or a feature? Documentation virtually tells nothing and no example. In comparison, scipy.ndimage.label() looks behaving better in this testcase. It also allows an optional arg of 4-connected and 8-connected se and it outputs the number of labels. So I would say it appears more matured and useful to me. I may be too new and know too little about the current status and the roadmap in a big picture. Regards, TJ

2 1

Add exposure module
by Tony Yu 15 Dec '11

15 Dec '11

As suggested in the feature requests for 0.5<http://groups.google.com/group/scikits-image/msg/ddda01a609f41fd5>, I just added an exposure module<https://github.com/scikits-image/scikits-image/pull/103>with histogram equalization based on code by Jan Erik Solem<http://www.janeriksolem.net/2009/06/histogram-equalization-with-python-and.…>(with the author's permission). Anyway, please look over the pull request. It's probably a lot more complicated than it needs to (especially given the terse code that it was derived from). I took some pains to return an image of the same type as the input, and I added a histogram function which tries to figure out the correct binning for image intensities (there's probably an established way of doing this that I'm missing). Enjoy! Cheers! -Tony

1 0

Travel
by Stéfan van der Walt 13 Dec '11

13 Dec '11

Hi all, I'll be traveling to South Africa over the next few days, so until I arrive I won't have a good internet connection. If any issues arise, please ping Emmanuelle or Tony. I look forward to an inbox full of PRs upon arrival :) Cheers Stéfan

1 0

Re: skeletonize question
by Zachary Pincus 13 Dec '11

13 Dec '11

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

3 3

Re: skeletonize question
by Zachary Pincus 13 Dec '11

13 Dec '11

On Dec 13, 2011, at 5:23 AM, Thouis (Ray) Jones wrote: > 2011/12/13 Stéfan van der Walt <stefan(a)sun.ac.za>: >> I am glad you showed me this example, because it also pointed out a >> problem with paletted image reading in PIL. I'm seriously considering >> just making matplotlib our default backend (except that they also have >> a PNG reading bug in older versions where images are flipped upside >> down!). > > Having fought this fight far too many times, I'm beginning to think > there's a need for a simple, small, and fast python module wrapping > libtiff, libpng, and libjpeg and talking to numpy. This would handle > 90% or more of everyone's needs and would hopefully be simpler to > install and use than PIL (and would have a faster development cycle). > > Ray Jones That's why I wrote that FreeImage backend... But maybe asking people to get libfreeimage (lightweight and dependency-free as it may be) is harder than ensuring they have libs tiff, png, and jpeg? There are win32 DLLs available for FreeImage, but no pre-built binaries for OS X, and I don't know if many/any/all linux distros provide packages for FreeImage. Does anyone know this? Similarly, I'm not sure what the licensing issues would be for providing pre-built FreeImage libraries -- FreeImage is GPL (v2), not LGPL, and so I don't actually know whether that means pre-build FreeImage libs can be distributed with skimage or not. Zach

2 1

Re: skeletonize question
by Thouis (Ray) Jones 13 Dec '11

13 Dec '11

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

1 0

Re: skeletonize question
by Tony Yu 12 Dec '11

12 Dec '11

2011/12/12 Stéfan van der Walt <stefan(a)sun.ac.za> > On Mon, Dec 12, 2011 at 5:13 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > > > > Strange: when I open "circles.png" using the matplotlib backend, I get a > > float32 array (with the white pixels equal to 0.00392157). With the PIL > > backend, I get a bool array (before your recent bug fix) or uint8 (after > the > > fix). Are you not having the same issue with matplotlib? > > While the bool type is fine (it's a black and white image), the pixel > order was completely messed up; try to display it! > Wow, when you said the pixel order was messed up, I thought you meant that it was just transposed, but it *really* is screwed up. > > In mpl, I see the same thing you do. It is because matplotlib assumes > that all images with depth < 8 is 8-bit, and therefore returns 1/255 > instead of 1. Filed here: > > https://github.com/matplotlib/matplotlib/pull/623 > Good, I thought it was just me. > > Cheers > Stéfan >

1 0

Re: skeletonize question
by Stéfan van der Walt 12 Dec '11

12 Dec '11

On Mon, Dec 12, 2011 at 5:13 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > > Strange: when I open "circles.png" using the matplotlib backend, I get a > float32 array (with the white pixels equal to 0.00392157). With the PIL > backend, I get a bool array (before your recent bug fix) or uint8 (after the > fix). Are you not having the same issue with matplotlib? While the bool type is fine (it's a black and white image), the pixel order was completely messed up; try to display it! In mpl, I see the same thing you do. It is because matplotlib assumes that all images with depth < 8 is 8-bit, and therefore returns 1/255 instead of 1. Filed here: https://github.com/matplotlib/matplotlib/pull/623 Cheers Stéfan

1 0

Re: io plugin issue (8bits 16bits)
by jip 12 Dec '11

12 Dec '11

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

2 1

Re: skeletonize question
by Tony Yu 12 Dec '11

12 Dec '11

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

1 0

skeletonize question
by karoyakani 12 Dec '11

12 Dec '11

Hi, I'm new to this mailing list. skimage version 0.4.2 has morphology.skeletonize() that works almost as good as Matlab bwmorph('thin'). However the output seems transposed when I tested a Matlab's example image 'circles.png': http://www.mathworks.com/help/toolbox/images/ref/bwmorph.html Is this a bug? ######## import numpy as np from scipy import ndimage from scipy.io import loadmat from skimage.morphology import skeletonize import matplotlib.pyplot as plt # test image from Matlab bwmorph('skel') demo bw = loadmat('circles.mat')['BW'] sk = skeletonize(bw) plt.figure() plt.imshow(bw+sk.transpose(), cmap=plt.cm.gray, interpolation='nearest') plt.show() ######## Thanks, - TJ

2 1

Re: Measure and graph subpackages
by Stéfan van der Walt 11 Dec '11

11 Dec '11

On Dec 11, 2011 10:26 AM, "Tony Yu" <tsyu80(a)gmail.com> wrote: > > On Sun, Dec 11, 2011 at 12:46 PM, Zachary Pincus <zachary.pincus(a)yale.edu> wrote: >> >> Stéfan may be able to amplify, but IIRC he has some other code to put into measure that should more clearly differentiate the two sub-modules. Right now it's correct that both the content in 'measure' (marching-squares contour-finding) and in 'graph' (Dijkstra's algorithm on a lattice) are both about tracing paths through pixel arrays, albeit in very different contexts. So it might not be bad to re-organize. >> >> But contour-finding is not a graph operation, so such a re-org should be more than putting that code in the 'graph' package. > > Oh, I meant the other way around: getting the minimum-cost path seems like something you measure in an image. (Sort of.) That was under the assumption that nothing else was planned for the graph package. I was thinking of putting things like graph cuts in there, but placing an emphasis on the way a function is implemented rather than what it does may be the wrong approach. E.g., we don't put image filters in the Fourier submodule. What can go in there is maybe graph handling utilities for other functions. So, where would a good home for shortest path be? We'll keep a link to the original location for backward compatibility too. Cheers Stéfan

1 0

Re: Measure and graph subpackages
by Zachary Pincus 11 Dec '11

11 Dec '11

Stéfan may be able to amplify, but IIRC he has some other code to put into measure that should more clearly differentiate the two sub-modules. Right now it's correct that both the content in 'measure' (marching-squares contour-finding) and in 'graph' (Dijkstra's algorithm on a lattice) are both about tracing paths through pixel arrays, albeit in very different contexts. So it might not be bad to re-organize. But contour-finding is not a graph operation, so such a re-org should be more than putting that code in the 'graph' package. Zach On Dec 11, 2011, at 11:13 AM, Tony Yu wrote: > I don't know anything about graph theory, but from my (naive) perspective, it seems that the graph subpackage should be part of the measure subpackage. Is this correct? > > -Tony

2 1

Measure and graph subpackages
by Tony Yu 11 Dec '11

11 Dec '11

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

1 0

Re: Feature requests for 0.5
by Stéfan van der Walt 09 Dec '11

09 Dec '11

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

1 0

Re: New module for thresholding
by Stéfan van der Walt 09 Dec '11

09 Dec '11

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

1 0

Re: New module for thresholding
by Tony Yu 09 Dec '11

09 Dec '11

2011/12/9 Stéfan van der Walt <stefan(a)sun.ac.za> > On Fri, Dec 9, 2011 at 12:42 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > > It doesn't really make sense to add a separate thresholding module, so > where > > should I put this thresholding function? > > Another place it could fit is in the filter sub-module, since it is > just a per-pixel operation. > > You also mentioned histogram equalisation, but that we may want to put > in an "exposure" module, along with things like dynamic range imaging > etc. > > Stéfan > I like the idea of an "exposure" module, and it definitely has a clear meaning, unlike "levels". Putting thresholding in filter is a little strange to me (for some reason). But if there's no other suggestions, I'm fine with it. -Tony

1 0

12 bits tif image issue with skimage 0.5dev
by jip 09 Dec '11

09 Dec '11

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

2 2

Re: New module for thresholding
by Stéfan van der Walt 09 Dec '11

09 Dec '11

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

1 0

New module for thresholding
by Tony Yu 09 Dec '11

09 Dec '11

This came up in a pull request to add thresholding<https://github.com/scikits-image/scikits-image/pull/98>to skimage, but I thought it'd be good to move the discussion to the mailing list. It doesn't really make sense to add a separate thresholding module, so where should I put this thresholding function? My proposal is to add a "levels" module and put thresholding there. Then, for example, we could add some functions to adjust contrast/brightness/gamma. Someone suggested a histogram equalization function, which would also fit in a levels module. On the other hand, "levels" is often used by photo-editing programs to denote a specific tool for adjusting color/intensity levels. Thoughts/ideas? -Tony

1 0

Re: Feature requests for 0.5
by Thouis Jones 09 Dec '11

09 Dec '11

2011/12/9 Stéfan van der Walt <stefan(a)sun.ac.za>: > We'll probably borrow heavily from cpmath where we can. Since you > have a lot of experience with this stuff, your feedback is appreciated > (because, in the end, it would be great if you guys could actually use > these tools!). That's certainly our hope, as well. We'd like to be able to trim down CP as well as take advantage of a more widely deployed and therefore (hopefully) better-tested codebase. While we're on the subject of measuring objects... You might consider supporting overlapping segmentations, using an ijk (ij=position, k=label) scheme. This has started to become necessary for many of our experiments, and we're starting down the road of making all the feature measurements compatible with this labeling scheme. This is the sort of thing to add earlier rather than later, though I think Lee has some code to wrap a feature measurement function in the non-overlapping style to make it ijk-compatible (by looping over noninteracting sets of labels in the ijk matrix). Ray

1 0

Re: Feature requests for 0.5
by Stéfan van der Walt 08 Dec '11

08 Dec '11

On Thu, Dec 8, 2011 at 2:17 AM, Thouis Jones <thouis.jones(a)curie.fr> wrote: > From the bio corner of the world, I would suggest nearly everything here: > http://murphylab.cbi.cmu.edu/services/SLF/ Thanks, Ray. For my own future reference, here's the actual list: http://murphylab.web.cmu.edu/services/SLF/features.html Luckily, many of these are easy to compute once the object has been isolated (a one or two-liner) in NumPy. So we just have to define a standard API to calculate features, something like: feature(values, positions) Around that, we can then build an additional layer that handles them per labeled object, e.g. each(feature, labeled_image) We'll probably borrow heavily from cpmath where we can. Since you have a lot of experience with this stuff, your feedback is appreciated (because, in the end, it would be great if you guys could actually use these tools!). Cheers Stéfan

1 0

Re: Feature requests for 0.5
by Emmanuelle Gouillart 08 Dec '11

08 Dec '11

On Thu, Dec 08, 2011 at 01:31:46AM -0800, StÃ¯Â¿Â½fan van der Walt wrote: > On Wed, Dec 7, 2011 at 9:10 PM, Emmanuelle Gouillart > <emmanuelle.gouillart(a)nsup.org> wrote: > > Regarding graph-cut segmentation, it's not exactly graph-cut, but I have > > some code (purely Python) implementing the random walker segmentation > > algorithm > > (http://cns.bu.edu/~lgrady/Random_Walker_Image_Segmentation.html). It's a > > very nice algorithm that overcomes some of the limitations of the > > watershed, and it can label more than two phases. So I could clean up > > this code a bit for skimage, I guess this could be my contribution to 0.5 > Thanks for the link; I haven't seen this method before. Does it > vectorize fairly well? The implementation that I use is based on solving a large sparse linear system, so there is no for loop or anything like this. Does this answer your question? > I wonder, if we start doing seeded segmentation, whether it might be > worth building a Qt or Matplotlib GUI along with it. I have other uses > for a "Paint" component too, such as modifying the FFT spectrum and > watching the changes in place (wouldn't FFT painting be fun? :). I've got mixed feelings about this. Having some interactive GUIs for adjusting parameters like for thresholding, or Canny filtering, would be great and save a lot of time. Sometimes I get quite frustrated when typing several commands in Ipython to test different parameters, whereas the algorithm is actually fast enough so that I could just move a handle and see the result. I asked Eric Jones during Scipy India if he could make a small example using traitsUI for interactive thresholding. The question is: should these interfaces go in skimage or elsewhere? If yes, we would have to make sure that this does not introduce additional dependencies (only optional ones). I think it's very important that skimage stays a toolkit, and a package that it is easy to depend on for other projects. Cheers, Emmanuelle

2 1

Re: scikits-image 0.4 release
by Stéfan van der Walt 08 Dec '11

08 Dec '11

On Thu, Dec 8, 2011 at 5:43 AM, Michael Aye <kmichael.aye(a)gmail.com> wrote: >> >> Please visit our examples gallery to see what we've been up to: >> >> http://scikits-image.org/docs/0.3/auto_examples/ >> > This should be http://scikits-image.org/docs/0.4/auto_examples/ > ,right? Ouch, well, that's embarrassing! I've sent updates to the scipy list. Thanks! Stéfan

1 0

Re: scikits-image 0.4 release
by Michael Aye 08 Dec '11

08 Dec '11

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

1 0

Re: Feature requests for 0.5
by Thouis Jones 08 Dec '11

08 Dec '11

2011/12/8 Stéfan van der Walt <stefan(a)sun.ac.za>: > As for the different measures, I think we could benefit from having > some of those grouped together. Things like getting the area (after > labelling is trivial), but computing circularity etc. can get more > interesting. Do you know of a good list of such desired measurements? > Maybe also have a look at the MATLAB docs online to see what they > provide as a point of reference. >From the bio corner of the world, I would suggest nearly everything here: http://murphylab.cbi.cmu.edu/services/SLF/ Specific papers: http://murphylab.web.cmu.edu/publications/81-boland2001.pdf http://murphylab.web.cmu.edu/publications/87-murphy2002.pdf http://murphylab.cbi.cmu.edu/services/SLF/ Also see the table at the end of: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.33.9697 These are all for cells, but many of the features are generally useful, I think. Ray

1 0

Re: Feature requests for 0.5
by Emmanuelle Gouillart 08 Dec '11

08 Dec '11

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

2 1

Re: Feature requests for 0.5
by Anders Klint 08 Dec '11

08 Dec '11

Hi, More of a question than a request: Rather long ago I used an image analysis tool called Image Pro which had a rather large set of measurements that could be applied to identified objects. So a possible scenario there could be something like: * Grab image * Segment objects from background * Measure objects * Filter out only objects with a size between 1.5 and 3.3 mm^2 (or relevant pixel measurement) and a roundness (defined in terms of length of object's periphery vs periphery of a circle with same area) over 0.85 * ...and further processing on matching objects Other measurements included for example major and minor axis direction and length, average greyscale value etc etc Could something like this, ie a more comprehensive set of measurements be valuable for skimage users? Regards /Anders On 6 dec 2011, at 01:51, Stéfan van der Walt wrote: > Hi all, > > With 0.4 (and 0.4.1, 0.4.2) out the door, we can start setting > priorities for 0.5. > > Personally, I'd like to see > > - An expansion of the user guide > - Completion of the Debian packaging > - Object convex hulls and > - Graph cut segmentation and/or tri-mapping > > Feel free to weigh in with your own suggestions, then we'll come to an > agreement on the best way forward. > > Regards > Stéfan

2 1

Re: Feature requests for 0.5
by Stéfan van der Walt 08 Dec '11

08 Dec '11

Hi Tony On Wed, Dec 7, 2011 at 8:52 AM, Tony Yu <tsyu80(a)gmail.com> wrote: > * A while back, I mentioned the possibility of automatically importing some > submodules (but leaving them in their own namespace). For example, I'd vote > for automatic import of the io module. If we can agree on which submodules > (if any), I could throw together a pull request. This was the original model for NumPy and SciPy, but whenever redesign comes up this is mentioned, and I think those projects would eventually like to step away from it. The important thing to improve may be the root docstring for skimage, so that you can inspect that to know what is available below. > * Automatic threshold algorithms. I started to integrate some code from > CellProfiler, but I got bogged down with some of the details. I can give it > another go, unless someone else wants to do it. We could maybe start with an implementation of Otsu's method, which is really simple: http://en.wikipedia.org/wiki/Otsu's_method Regards Stéfan

1 0

Re: Feature requests for 0.5
by Neil Yager 07 Dec '11

07 Dec '11

> * Automatic threshold algorithms. I started to integrate some code from > CellProfiler, but I got bogged down with some of the details. I can give it > another go, unless someone else wants to do it. I agree that thresholding should be a priority, as it is widely used. I also started to look at the CellProfiler. It has a lot of functionality, but even a subset of this would be a good start. Unfortunately I don't think I'll have much time for this in the next few weeks. Another useful method would be histogram equalization. Here's a nice implementation: http://www.janeriksolem.net/2009/06/histogram-equalization-with-python-and.… but we'd have to contact the author about using it. Neil

1 0

Re: Feature requests for 0.5
by Tony Yu 07 Dec '11

07 Dec '11

2011/12/6 Stéfan van der Walt <stefan(a)sun.ac.za> > Hi Nelle > > On Mon, Dec 5, 2011 at 10:23 PM, Nelle Varoquaux > <nelle.varoquaux(a)gmail.com> wrote: > > I have a Harris affine region detector I'd like to integrate, and > > Great, that would be a very useful addition! > > > potentially a panorama stitching example using hogs and harris I'd > > like to integrate (might be slightly to complicated for the user guide > > ?). It's work in progress, but I should have time to work on that > > during the christmas holidays. > > We could make this an example chapter in the user guide, since it > would illustrate a number of things. For that, we may want to modify > the auto example generator to allow text snippets to appear between > code. I did quite a bit of work on stitching during my phd, so I'd be > interested to help out with this, if you want. > > Regards > Stéfan > A stitching/image-registration example would be great. Other wish-list items: * A while back, I mentioned the possibility of automatically importing some submodules (but leaving them in their own namespace). For example, I'd vote for automatic import of the io module. If we can agree on which submodules (if any), I could throw together a pull request. * Automatic threshold algorithms. I started to integrate some code from CellProfiler, but I got bogged down with some of the details. I can give it another go, unless someone else wants to do it. Best, -Tony

1 0

The asymmetry of licensing
by Stéfan van der Walt 06 Dec '11

06 Dec '11

Hi all, Here's a link to a (potentially controversial) post I made on Google Plus: https://plus.google.com/104831275312843762750/posts/fcdAoLarutu Basically, it briefly touches on why we are using BSD and not GPL. Your comments are welcome. Regards Stéfan

1 0

Re: io plugin issue (8bits 16bits)
by Neil Yager 06 Dec '11

06 Dec '11

> I'll commit that as soon as it has been reviewed by at least one other person. I just pulled 88, 90 and 91, and everything works for me. Neli

1 0

Re: installation -- error on the download webpage
by Emmanuelle Gouillart 06 Dec '11

06 Dec '11

> For future reference: > To start, clone git@github.com:scikits-image/scikits-image-web.git > 1. Make the changes necessary. > 2. "make html" and check that the build/html output looks ok. > 3. "make gh-pages" > 4. If all looks ok, "cd gh-pages ; git commit" Thanks, this will be useful! Emmanuelle

1 0

installation -- error on the download webpage
by Emmanuelle Gouillart 06 Dec '11

06 Dec '11

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

2 2

Re: io plugin issue (8bits 16bits)
by Neil Yager 06 Dec '11

06 Dec '11

Coincidentally, I also noticed the 16-bit tiff issue the other day, and started working on a fix. I was using an approach based on this: http://stackoverflow.com/questions/7684695/numpy-array-of-an-i16-image-file Changing the last line of imread in pil_plugin to: return np.array(im.getdata()).reshape(im.size[::-1]) fixes that specific problems, but causes others (e.g. can't load colour images). At that point I got side-tracked by something else, so I'm not sure if it's a good fix. Neil On Dec 6, 12:32 am, Stéfan van der Walt <ste...(a)sun.ac.za> wrote: > On Mon, Dec 5, 2011 at 2:40 PM, Christoph Gohlke <cjgoh...(a)gmail.com> wrote: > > skimage.io.use_plugin is somewhat broken (I think). It replaces all > > previously defined default imread, imwrite, and imshow functions, regardless > > whether a `kind` argument is provided. For example: > > Between Chris and myself, we should have this fixed tonight. Follow along here: > > https://github.com/scikits-image/scikits-image/pull/88https://github.com/sc… > > PR90 provides a new function called "plugin_order", which allows the > user to see under the hood which function skimage will try to use. > > Cheers > Stéfan

3 2

Re: Feature requests for 0.5
by Stéfan van der Walt 05 Dec '11

05 Dec '11

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

1 0

Re: Feature requests for 0.5
by Nelle Varoquaux 05 Dec '11

05 Dec '11

Hi Stéfan, I have a Harris affine region detector I'd like to integrate, and potentially a panorama stitching example using hogs and harris I'd like to integrate (might be slightly to complicated for the user guide ?). It's work in progress, but I should have time to work on that during the christmas holidays. Cheers, Nelle 2011/12/6 Stéfan van der Walt <stefan(a)sun.ac.za>: > Hi all, > > With 0.4 (and 0.4.1, 0.4.2) out the door, we can start setting > priorities for 0.5. > > Personally, I'd like to see > > - An expansion of the user guide > - Completion of the Debian packaging > - Object convex hulls and > - Graph cut segmentation and/or tri-mapping > > Feel free to weigh in with your own suggestions, then we'll come to an > agreement on the best way forward. > > Regards > Stéfan

1 0

Feature requests for 0.5
by Stéfan van der Walt 05 Dec '11

05 Dec '11

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

1 0

Re: io plugin issue (8bits 16bits)
by Christoph Gohlke 05 Dec '11

05 Dec '11

On 12/5/2011 1:52 PM, StÃ¯Â¿Â½fan van der Walt wrote: > On Mon, Dec 5, 2011 at 1:20 PM, jip<jeanpatrick.pommier(a)gmail.com> wrote: >> I joined an image with that message. > Thanks, JP. This allowed me to narrow down the problem. We currently > do not have logic to support PIL Tiff objects, so they end up embedded > in an object array. > > In the meantime, the matplotlib plugin does work for me: > > import skimage.io as sio > sio.use_plugin('matplotlib') > img = sio.imread('1.tiff') > > Cheers > StÃ¯Â¿Â½fan > Hello, Matplotlib's imread uses PIL and also does not read 16 bit TIFFs correctly. The FreeImage, Qt, and GDAL plugins do. With scikits-image 0.4.2, the following works correctly for me on Windows: import skimage.io skimage.io.use_plugin('freeimage') skimage.io.use_plugin('matplotlib') image = skimage.io.imread('1.tif', plugin='freeimage') skimage.io.imshow(image, cmap='gray') skimage.io.show() skimage.io.use_plugin is somewhat broken (I think). It replaces all previously defined default imread, imwrite, and imshow functions, regardless whether a `kind` argument is provided. For example: skimage.io.use_plugin('freeimage', 'imread') skimage.io.use_plugin('matplotlib', 'imshow') the second call replaces freeimage.imread as the default imread function with matplotlib.imread. Christoph

2 1

Re: io plugin issue (8bits 16bits)
by jip 05 Dec '11

05 Dec '11

dear Stéfan, I joined an image with that message. <https://docs.google.com/open?id=0B-YDFMbEy1grYTMzMGRiZDUtNzk2OC00YTAwLTk5NT…> Le lundi 5 décembre 2011 20:08:36 UTC+1, Stefan van der Walt a écrit : > > Hi JP > > Thanks for finding this issue. Would you mind placing a small 12-bit tiff > online somewhere so that I can use it in the test suite? > > It's strange that the matplotlib plugin is not available, since you > mention that you have pylab. Can you import matplotlib without problems? > I can use pylab if the image is loaded with readmagick. I can check skimage.io on an other configuration. Best regards Jean-Patrick > >> >>

2 1

Nowozin
by Andreas Müller 05 Dec '11

05 Dec '11

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

2 1

Re: io plugin issue (8bits 16bits)
by Stéfan van der Walt 05 Dec '11

05 Dec '11

Hi JP Thanks for finding this issue. Would you mind placing a small 12-bit tiff online somewhere so that I can use it in the test suite? It's strange that the matplotlib plugin is not available, since you mention that you have pylab. Can you import matplotlib without problems? Regards Stéfan On Dec 5, 2011 5:30 AM, "jip" <jeanpatrick.pommier(a)gmail.com> wrote: > Dear all, > > I meet some problem to open/display 12bits tif (16 bits) gray images. > I can open an image but I fail to display it: > import skimage > path='/media/Elements__/Science/Biologie/QTeloFISH/myoblastes > HPS/JPP55_nFF/16/DAPI' > image='/1.tif' > from skimage import io as io > > print skimage.io.plugin_info('matplotlib') > #skimage.io.use_plugin('matplotlib', 'read') > > #dapi=io.imread(path+image,plugin='matplotlib') > dapi=io.imread(path+image) > > print type(dapi) > print type(dapi) > print 'dapi.dtype',dapi.dtype > > io.imshow(dapi) > #import pylab > #pylab.imshow(dapi) > #pylab.show() > Then I get the following error: > *<type 'numpy.ndarray'> > <type 'numpy.ndarray'> > dapi.dtype object > Traceback (most recent call last): > File "/home/claire/.spyder2/.temp.py", line 28, in <module> > io.imshow(dapi) > File > "/usr/local/lib/python2.6/dist-packages/skimage-0.4-py2.6-linux-i686.egg/skimage/io/_io.py", > line 149, in imshow > return call_plugin('imshow', arr, plugin=plugin, **plugin_args) > File > "/usr/local/lib/python2.6/dist-packages/skimage-0.4-py2.6-linux-i686.egg/skimage/io/_plugins/plugin.py", > line 88, in call > return func(*args, **kwargs) > File > "/usr/local/lib/python2.6/dist-packages/skimage-0.4-py2.6-linux-i686.egg/skimage/io/_plugins/pil_plugin.py", > line 108, in imshow > Image.fromarray(arr).show() > File "/usr/lib/python2.6/dist-packages/PIL/Image.py", line 1886, in > fromarray > raise TypeError("Cannot handle this data type") > TypeError: Cannot handle this data type > * > The default plugin is PIL.If I try to switch to matplotlib (or freeimage), > the plugin doesn't seem available: > *Traceback (most recent call last): > File "/home/claire/.spyder2/.temp.py", line 16, in <module> > dapi=io.imread(path+image,plugin='matplotlib') > File > "/usr/local/lib/python2.6/dist-packages/skimage-0.4-py2.6-linux-i686.egg/skimage/io/_io.py", > line 72, in imread > img = call_plugin('imread', fname, plugin=plugin, **plugin_args) > File > "/usr/local/lib/python2.6/dist-packages/skimage-0.4-py2.6-linux-i686.egg/skimage/io/_plugins/plugin.py", > line 86, in call > (plugin, kind)) > RuntimeError: Could not find the plugin "matplotlib" for imread.* > I can open the same image with plugin='pil' but I fail to display it: > *uint16 > (1024, 1536) > Traceback (most recent call last): > File "/home/claire/.spyder2/.temp.py", line 28, in <module> > io.imshow(dapi0) > File > "/usr/local/lib/python2.6/dist-packages/skimage-0.4-py2.6-linux-i686.egg/skimage/io/_io.py", > line 149, in imshow > return call_plugin('imshow', arr, plugin=plugin, **plugin_args) > File > "/usr/local/lib/python2.6/dist-packages/skimage-0.4-py2.6-linux-i686.egg/skimage/io/_plugins/plugin.py", > line 88, in call > return func(*args, **kwargs) > File > "/usr/local/lib/python2.6/dist-packages/skimage-0.4-py2.6-linux-i686.egg/skimage/io/_plugins/pil_plugin.py", > line 108, in imshow > Image.fromarray(arr).show() > File "/usr/lib/python2.6/dist-packages/PIL/Image.py", line 1886, in > fromarray > raise TypeError("Cannot handle this data type") > TypeError: Cannot handle this data type* > > Does io.imshow() support only 8bits image? > > I can open and display the image with readmagick/pylab. > > Best regards > Jean-Patrick > > >

1 0

io plugin issue (8bits 16bits)
by jip 05 Dec '11

05 Dec '11

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

1 0

Re: scikits-image 0.4 release
by Emmanuelle Gouillart 05 Dec '11

05 Dec '11

Very cool :-). I was very excited to talk about the new release during my talk at Scipy India (a few hours ago), thanks for the opportunity to advertise the release! During questions, I was asked if during the sprint, it would be possible to contribute to the Debian/Ubuntu packaging. I don't know the status of the packaging, and if something could be done to help with the packaging. What should I answer to the person who asked about packaging? Cheers, Emmanuelle On Sat, Dec 03, 2011 at 02:42:41PM -0800, StÃ¯Â¿Â½fan van der Walt wrote: > Announcement: scikits-image 0.4 > =============================== > We're happy to announce the 0.4 release of scikits-image, an image processing > toolbox for SciPy. > Please visit our examples gallery to see what we've been up to: > http://scikits-image.org/docs/0.3/auto_examples/ > Note that, in this release, we renamed the module from ``scikits.image`` to > ``skimage``, to work around name space conflicts with other scikits (similarly, > the machine learning scikit is now imported as ``sklearn``). > A big shout-out also to everyone currently at SciPy India; have fun, and > remember to join the scikits-image sprint! > This release runs under all major operating systems where Python (>=2.6 or > 3.x), NumPy and SciPy can be installed. > For more information, visit our website > http://scikits-image.org > New Features > ------------ > - Module rename from ``scikits.image`` to ``skimage`` > - Contour finding > - Grey-level co-occurrence matrices > - Skeletonization and medial axis transform > - Convex hull images > - New test data sets > - GDAL I/O plugin > ... as well as some bug fixes. > Contributors to this release > ---------------------------- > * Andreas Mueller > * Christopher Gohlke > * Emmanuelle Gouillart > * Neil Yager > * Nelle Varoquaux > * Riaan van den Dool > * Stefan van der Walt > * Thouis (Ray) Jones > * Tony S Yu > * Zachary Pincus

2 1

Re: scikits-image 0.4 release
by jip 04 Dec '11

04 Dec '11

Thank you, I just upgrade Jean-Patrick Pommier

1 0

sprint @Scipy India on Thursday 8th
by Emmanuelle Gouillart 03 Dec '11

03 Dec '11

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

2 1

scikits-image 0.4 release
by Stéfan van der Walt 03 Dec '11

03 Dec '11

Announcement: scikits-image 0.4 =============================== We're happy to announce the 0.4 release of scikits-image, an image processing toolbox for SciPy. Please visit our examples gallery to see what we've been up to: http://scikits-image.org/docs/0.3/auto_examples/ Note that, in this release, we renamed the module from ``scikits.image`` to ``skimage``, to work around name space conflicts with other scikits (similarly, the machine learning scikit is now imported as ``sklearn``). A big shout-out also to everyone currently at SciPy India; have fun, and remember to join the scikits-image sprint! This release runs under all major operating systems where Python (>=2.6 or 3.x), NumPy and SciPy can be installed. For more information, visit our website http://scikits-image.org New Features ------------ - Module rename from ``scikits.image`` to ``skimage`` - Contour finding - Grey-level co-occurrence matrices - Skeletonization and medial axis transform - Convex hull images - New test data sets - GDAL I/O plugin ... as well as some bug fixes. Contributors to this release ---------------------------- * Andreas Mueller * Christopher Gohlke * Emmanuelle Gouillart * Neil Yager * Nelle Varoquaux * Riaan van den Dool * Stefan van der Walt * Thouis (Ray) Jones * Tony S Yu * Zachary Pincus

1 0

Re: Preparing for 0.4 and updated gallery
by Emmanuelle Gouillart 02 Dec '11

02 Dec '11

Great! These will be very exciting news to disclose in my talk @ Scipy India on this Sunday! Cheers, Emmanuelle On Thu, Dec 01, 2011 at 01:14:10PM -0800, StÃ¯Â¿Â½fan van der Walt wrote: > Hi all, > I think we are basically ready to tag 0.4! If you know of any issue > that needs to be addressed urgently, let me know. > The gallery is also filling up very nicely! > http://scikits-image.org/docs/dev/auto_examples/index.html > E.g, you'll see the contour finding by Zach Pincus that was merged > today, and the grey-level co-occurrence matrix work by Neil Yager. > According to Ohloh, we now have about 10,000 lines of Python code, vs, > e.g., scikit-learn's 30,000. Keep it coming! > Cheers > StÃ¯Â¿Â½fan

1 0

Re: Preparing for 0.4 and updated gallery
by Dan Farmer 01 Dec '11

01 Dec '11

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

1 0

Preparing for 0.4 and updated gallery
by Stéfan van der Walt 01 Dec '11

01 Dec '11

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

1 0