Mailman 3 February 2012 - scikit-image

Re: random walker segmentation / blob detection
by Emmanuelle Gouillart 13 Feb '12

13 Feb '12

On Fri, Feb 10, 2012 at 03:39:15AM -0800, StÃ¯Â¿Â½fan van der Walt wrote: > On Thu, Feb 9, 2012 at 9:06 AM, Michael Aye <kmichael.aye(a)gmail.com> wrote: > > Can k-means clustering maybe indicate to me how well a clustering worked, > > something like a score? I basically have 3 phases in the images: dark blobs, > > grayish background, and bright ice patches. Maybe clustering could indicate > > by scores if a 2 or 3 phase clustering represents the image better? > Here's an implementation of ICM-based clustering: > http://stackoverflow.com/a/9174197/214686 > I wonder if we should include this in the scikit--Emmanuelle, do > people actually still use ICM segmentation? I have to say that I don't know ICM segmentation. It looks very interesting (your code is impressively short!), would you have any reference to suggest for me to read about this algorithm? Thx, Emmanuelle

2 1

Re: random walker segmentation / blob detection
by Michael Aye 12 Feb '12

12 Feb '12

Hi Stéfan, thanks for playing with it, looks good. Do you have any comment on the question I had with the random_walker concerning the marker thresholds? Best regards, Michael

4 8

Re: Error when building from git
by Emmanuelle Gouillart 12 Feb '12

12 Feb '12

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

2 1

Re: Error when building from git
by Emmanuelle Gouillart 11 Feb '12

11 Feb '12

Hi, > The float16 data-type was introduced in NumPy 1.6, and while we > currently list NumPy 1.4 as a dependency, but we're going to have to > up that to 1.6 (I think some of it is being used in the data type > conversion code now, e.g.). I hope this isn't too much of an > inconvenience! isn't it possible to test which version of numpy is used, and remove float16 from the list if numpy.__version__ < 1.6? It looks like a small cost in order to be be able to support numpy 1.5. I can do the change if there is no opposition to this. The same thing that happened to Guillaume also happened to me as I was rebuilding skimage 10 minutes ago, since I'm using the version of numpy packaged by the most recent Ubuntu which is 1.5. As I see things, it would be great if people could use skimage with the dependencies provided by a recent version of Ubuntu, say the most recent LTS, or the latest release of Ubuntu. We will lose many users if they have to install a new numpy (which also means that they will have to install non-packaged matplolib, and scipy). If you disagree with this philosophy, please tell me :-). My 2 cents, Emmanuelle

4 4

Re: Error when building from git
by Tony Yu 11 Feb '12

11 Feb '12

2012/2/11 Stéfan van der Walt <stefan(a)sun.ac.za> > Hi Emmanuelle > > On Fri, Feb 10, 2012 at 10:58 AM, Emmanuelle Gouillart > <emmanuelle.gouillart(a)nsup.org> wrote: > > isn't it possible to test which version of numpy is used, and remove > > float16 from the list if numpy.__version__ < 1.6? It looks like a small > > cost in order to be be able to support numpy 1.5. I can do the change if > > there is no opposition to this. > > If we can stay compatible with 1.5 with minor changes, that's probably > worth it. Can you also check the dtype conversion code to make sure > it all works? (Running the unit tests should be enough of an > indication) > I'd be in favor of supporting numpy 1.5. Just note that the `convert` function uses `np.promote_types`, which is also new to numpy 1.6. -Tony > As I see things, it would be great if people could use skimage with the > > dependencies provided by a recent version of Ubuntu, say the most recent > > LTS, or the latest release of Ubuntu. We will lose many users if they > > have to install a new numpy (which also means that they will have to > > install non-packaged matplolib, and scipy). If you disagree with this > > philosophy, please tell me :-). > > I understand the challenges of running on an older platform, but I > also wonder: if a user can recompile scikits-image, what's stopping > them from also building the latest (stable) numpy? I certainly have > the expectation that software should run with the available stable > versions of dependencies on the date of release. That said, any > benefit we can get with little effort is worth it, and there's no > reason to purposefully make it harder for users than need be. So > please, keep the PRs coming for backwards compatibility, as long as > they are not too disruptive. > > Regards > Stéfan >

1 0

Re: Understanding HoG output
by bricklemacho 11 Feb '12

11 Feb '12

> My best suggestion would be that you take a look at the comments written in > `hog.py`. Each part quotes the relevant section from the Dalal Triggs > paper and then under that implements the code required to do the job. > Others on this list may have different views, but I'd be reluctant to try > to 'interpret' the flattened descriptor. Doh! didn't think to look at the code. Based on this suggestion I have had a look at the code, good level of commenting in the code. > Yes, you can reshape the array (but that can be a bit tricky), or you could > modify the hog function to return the unraveled descriptor and ravel it > yourself later if you need it. Thanks for the idea. > A line is drawn for each gradient bin with an intensity proportional to the > magnitude of that gradient. So, the 'star' shape you see for each cell is > just the superimposition of all of these lines. You should expect to see > dominant lines perpendicular to lines in the image (parallel to the > gradient). Also remember that the default is to use 9 bins, so it may be > that the 45degree dominant line you see is the closest approximation to > horizontal. You can test this out by trying 8 bins instead of 9. Ahh.. I guess I was expecting some sort of "edge" like in the edge detector. Makes more sense now. Also, thanks for the simple example.

1 0

Re: Understanding HoG output
by Emmanuelle Gouillart 11 Feb '12

11 Feb '12

Hi Brian, thanks a lot for the explanations! I must say that when I had a look at the HoG function following Michael's post, I had quite a hard time understanding how this function was working. Your explanations do help; do you think it would be possible to write a meaningful example using HoGs for the example gallery? That might give a good starting point in order to use this function. If you don't have the time to write the example yourself, any hints on the possible contents would also help. Cheers, Emmanuelle On Fri, Feb 10, 2012 at 01:45:12PM +0000, Brian Holt wrote: > Hi Michael,Ã¯Â¿Â½ > Hi, new to group, new to image processing starting to explore HoG. > Looking for a python implementation and discovered > skimage.feature.hog(). > Glad to hear someone's using HoGs! > My plan to run skimage.features.hog over some positive/negative images > and use this to train a svm classifier from scikits-learn. Ã¯Â¿Â½ I am > trying to understand the output hog before I proceed further. Ã¯Â¿Â½ Ã¯Â¿Â½When > I run skimag.feature.hog() it over a region of interest Ã¯Â¿Â½it appears to > returns an array. Ã¯Â¿Â½How do I interpret this array?Ã¯Â¿Â½ > My best suggestion would be that you take a look at the comments written > in `hog.py`. Ã¯Â¿Â½Each part quotes the relevant section from the Dalal Triggs > paper and then under that implements the code required to do the job. > Ã¯Â¿Â½Others on this list may have different views, but I'd be reluctant to try > to 'interpret' the flattened descriptor. Ã¯Â¿Â½ > Ã¯Â¿Â½Is there a way toÃ¯Â¿Â½reshape the array to see what it was like before it > was flattened orÃ¯Â¿Â½that doesn't make any sense? Ã¯Â¿Â½Can I plot the descriptor > returned in > any meaningful way? > Yes, you can reshape the array (but that can be a bit tricky), or you > could modify the hog function to return the unraveled descriptor and ravel > it yourself later if you need it. > Also when I choose to visualise the HoG often where I expected to see > vertical line dominate, say on the edge of builds, the line drawn > often appears to be more dominant at the 45 deg. Ã¯Â¿Â½Is this expected as > the line drawn is really just the sum of all surrounding orientations > for the "cell"? > A line is drawn for each gradient bin with an intensity proportional to > the magnitude of that gradient. Ã¯Â¿Â½So, the 'star' shape you see for each > cell is just the superimposition of all of these lines. You should expect > to see dominant lines perpendicular to lines in the image (parallel to the > gradient). Also remember that the default is to use 9 bins, so it may be > that the 45degree dominant line you see is the closest approximation to > horizontal. Ã¯Â¿Â½You can test this out by trying 8 bins instead of 9.Ã¯Â¿Â½ > I hope it helps, feel free to ask any more questions. > Regards > Brian > On 9 February 2012 06:37, bricklemacho <[1]bricklemacho(a)gmail.com> wrote: > Thanks in advance, > Michael.

2 2

Re: 0.5 release soon?
by Tony Yu 10 Feb '12

10 Feb '12

2012/2/10 Stéfan van der Walt <stefan(a)sun.ac.za> > On Thu, Feb 9, 2012 at 9:07 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > > There has been a surprising amount of new features, fixes, and doc > > improvements since 0.4, so I'm wondering if it's time for a new release. > > You're right, it's about time! > > > Are there any major todos before that? > > - Finish the Debian packaging. Really, this is so close, we should just > do it: > > 1. Edit the skivi.1 man-page template (anyone with Troff skills here?) > 2. Update the copyright file. > 3. Ping Yaroslav to check and upload. > > If possible, we should get permission from everyone with per-file > copyright messages and move their names to the CONTRIBUTORS.txt file, > so that we have a single license covering all our code. > > > * Maybe doc additions if they're close. > > I've got some unpushed user guide changes that I'll be done with soon. > > > * Of the current pull requests, only SSIM and template-matching are > close, > > but I don't think I'll have much time to sort out the issues with > > template-matching for awhile. > > For now, I'm pretty much done with SSIM, so if you think it looks OK > please merge. > Actually, I haven't really look over SSIM; I was just basing its readiness on Nicolas's comments. ;) I'll read through the code this weekend. > > > * I was really excited about the image stitching example using HoGs, > > suggested by Nelle. If it's not close, though, no pressure. > > Since Nelle's indicated that she's very busy at the moment, we can > push that back to 0.6 (and yes, it would make a great feature!). > > The end of February gets crazy for me time-wise, so shall we aim for > the 19th of February? That gives us two more weekends. > > Stéfan > The 19th sounds like a good target. I guess I forgot about the FreeImage issues, but it sounds like Zach is working pretty hard to make the build as care-free as possible. -Tony

1 0

Re: Understanding HoG output
by Brian Holt 10 Feb '12

10 Feb '12

Hi Michael, Hi, new to group, new to image processing starting to explore HoG. Looking for a python implementation and discovered skimage.feature.hog(). Glad to hear someone's using HoGs! My plan to run skimage.features.hog over some positive/negative images and use this to train a svm classifier from scikits-learn. I am trying to understand the output hog before I proceed further. When I run skimag.feature.hog() it over a region of interest it appears to returns an array. How do I interpret this array? My best suggestion would be that you take a look at the comments written in `hog.py`. Each part quotes the relevant section from the Dalal Triggs paper and then under that implements the code required to do the job. Others on this list may have different views, but I'd be reluctant to try to 'interpret' the flattened descriptor. Is there a way to reshape the array to see what it was like before it was flattened or that doesn't make any sense? Can I plot the descriptor returned in any meaningful way? Yes, you can reshape the array (but that can be a bit tricky), or you could modify the hog function to return the unraveled descriptor and ravel it yourself later if you need it. Also when I choose to visualise the HoG often where I expected to see vertical line dominate, say on the edge of builds, the line drawn often appears to be more dominant at the 45 deg. Is this expected as the line drawn is really just the sum of all surrounding orientations for the "cell"? A line is drawn for each gradient bin with an intensity proportional to the magnitude of that gradient. So, the 'star' shape you see for each cell is just the superimposition of all of these lines. You should expect to see dominant lines perpendicular to lines in the image (parallel to the gradient). Also remember that the default is to use 9 bins, so it may be that the 45degree dominant line you see is the closest approximation to horizontal. You can test this out by trying 8 bins instead of 9. I hope it helps, feel free to ask any more questions. Regards Brian On 9 February 2012 06:37, bricklemacho <bricklemacho(a)gmail.com> wrote: > > > > > > > Thanks in advance, > > Michael. > -- -- He is no fool who gives what he cannot keep to gain what he cannot lose. - Jim Elliot.

1 0

Re: Error when building from git
by Guillaume 10 Feb '12

10 Feb '12

Ok thanks, Also, I just ran into another problem with freeimage... First, when I first tried to open a file with the freeimage plugin, it was not found (I assumed it was bundled with skimage). So I apt-get installed libfreeimage3. but the error persisted (i.e. RuntimeError: Could not find the plugin "freeimage" for imread.) After some investigation, I found that I had to link /usr/lib/ libfreeimage.so.3 with /usr/lib/libfreeimage.so to pass the plugin test: sudo ln -s /usr/lib/libfreeimage.so.3 /usr/lib/libfreeimage.so Then the test is ok. Maybe there should be some more flexibility in the search for the shared object, in the _load_library(libname, libdir) function? Putting a regexp somewhere? Bye Guillaume On 10 fév, 11:34, Stéfan van der Walt <ste...(a)sun.ac.za> wrote: > Hi Guillaume > > On Fri, Feb 10, 2012 at 1:55 AM, Guillaume > > <guilla...(a)mitotic-machine.org> wrote: > > First thanks for the great work. I am planning to use skimage for some > > fluorescence microscopy analysis. > > That's great! We'd love to see what you do once you've got some > working examples. > > > Today I installed from the git repository and an error occurred when > > compiling: > > > File "/home/guillaume/Python/lib/scikits-image/skimage/util/ > > dtype.py", line 20, in <module> > > in <module> > > np.float16, np.float32, np.float64) > > AttributeError: 'module' object has no attribute 'float16' > > The float16 data-type was introduced in NumPy 1.6, and while we > currently list NumPy 1.4 as a dependency, but we're going to have to > up that to 1.6 (I think some of it is being used in the data type > conversion code now, e.g.). I hope this isn't too much of an > inconvenience! > > Regards > Stéfan

2 1