Mailman 3 February 2012 - scikit-image

Re: skimage module not found by iPython's completion?
by Tony Yu 07 Feb '12

07 Feb '12

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

1 0

Re: FreeImage binaries
by Zachary Pincus 07 Feb '12

07 Feb '12

>> Thanks! If anyone can give me any guidance on the matter of locating libraries on different linux flavors, I'd be grateful. I'm unfortunately basically linux-ignorant. > > I think if we look for liblibrary.so.majorversion as well as > liblibrary.so in the standard locations (/lib, /usr/lib, > /usr/local/lib, /opt/lib) we should be ok. New idea -- it may be better to just try to load anything that starts with "FreeImage" or "libfreeimage" (non case-sensitive). This because I notice that the default OS X makefile produces "libfreeimage.3.15.1.dylib"... This way the code will just try to load any matching file it finds, and if the loader complains then it'll move on to the next. Zach

2 3

Re: FreeImage binaries
by Zachary Pincus 07 Feb '12

07 Feb '12

> Thanks. I think under Linux we're OK. We just need to modify the > plugin to at least pick up on the default naming conventions (Debian, > e.g., names it libfreeimage.so.3, which we don't find). Thanks! If anyone can give me any guidance on the matter of locating libraries on different linux flavors, I'd be grateful. I'm unfortunately basically linux-ignorant. Zach

2 1

Re: FreeImage binaries
by Zachary Pincus 07 Feb '12

07 Feb '12

> On Tue, Feb 7, 2012 at 12:13 PM, Zachary Pincus <zachary.pincus(a)yale.edu> wrote: >> Also, is anyone a license-maven? Is this sort of thing (distributing binaries, then downloading and run-time loading them in a BSD-licensced project) OK under the GPL (v2) or the FreeImage license? >> http://freeimage.sourceforge.net/license.html > > Meh, licensing :) > > My take (and these issues are tricky, so IANAL and all that): > > The combined work (skimage + freeimage) must be distributed under the > terms of the GPL. Our license (the Modified BSD) is more permissive > than the GPL, so the GPL simply imposes some additional restrictions. > > As far as I understand, you are within your rights to distribute > patches to GPL code under any license you wish (which is, in a tenuous > sense, what we're doing). > > When we distribute skimage + the freeimage plugin (but no freeimage > binary), our distribution is only governed by the permissive BSD. > E.g., a company may use our code with the Matlotlib backend, mix it in > with their own (proprietary) code, and not have to worry about > anything. If we write the "install_libs" command, we may want to > clearly state what the implications are. > > Also, an interesting perspective on incorporating BSD code into GPL projects: > > http://www.softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html Yeah, I think we'd be on thin ice for GPL -- at a minimum we'd need to have a copy of the FreeImage sources available somewhere, just to distribute the binaries. Then the "install_libs()" thing seems very close to cheating the spirit if not the practice of the license. (LGPL would be a different matter.) So I read further about the FreeImage license and it looks sufficiently permissive for this case. I *think* we just need to make sure to also copy over the FreeImage license file and a relevant readme when we cause the binaries to be downloaded. But another opinion might be useful, if you want to look at that license: https://github.com/zachrahan/freeimage-sharedlib/blob/master/license-fi.txt And as you can see, I've put up the binaries I have so far here: https://github.com/zachrahan/freeimage-sharedlib I still need a win64 DLL. And I also have no idea what the story is with linux shared libs -- is it easy to distribute such for a given architecture, or do these get so fragmented that it makes more sense to just have the user make their package manager install FreeImage? Zach

2 2

Re: FreeImage binaries
by Zachary Pincus 07 Feb '12

07 Feb '12

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

2 2

Re: FreeImage binaries
by Zachary Pincus 07 Feb '12

07 Feb '12

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

2 1

Re: random walker segmentation / blob detection
by Stéfan van der Walt 07 Feb '12

07 Feb '12

Hey Michael On Tue, Feb 7, 2012 at 4:47 AM, Michael Aye <kmichael.aye(a)gmail.com> wrote: > I am searching for the best way of doing blob detection in my noisy > planetary image data but I just can't find the egg-laying woolen milk-giving > pig (german proverb) that would solve all my problems, but then again it > wouldn't be called research, if there's nothing to research, right? ;) I played around with your images in http://dip.sun.ac.za/~stefan/dpt/ just to get a feel for what we're dealing with here. A first result: http://mentat.za.net/refer/aye_planet0.png http://mentat.za.net/refer/aye_planet1.png This technique, specifically, is a non-linear filter, but I think you should be able to achieve the same with a simpler pipeline: 1) Filter out the image noise 2) Find structures of the appropriate range of sizes in the image (maybe using difference of Gaussians or other blob detection) 3) Threshold If you have enough examples of the kind of blobs you're trying to find, you can train a classifier to set thresholds. Otherwise, try to incorporate any knowledge you have from beforehand (i.e., the blobs are roughly X in size, roughly Y in colour, roughly Z in shape). Keep us up to date with your progress, and thanks for the interesting discussion. Cheers Stéfan

1 0

FreeImage binaries
by Zachary Pincus 07 Feb '12

07 Feb '12

Hey all, Some conversation on the pythonvision list (about a "simple python image IO library") has suggested to me that perhaps we should consider distributing FreeImage binaries either with skimage, or as a simple add-on package. For this we'd want an OS X dylib that's at least 32/64-bit, if not a four-way (intel/ppc 32/64). This should be pretty easy for me to make. We'd also want standalone 32- and 64-bit windows DLLs. And should we have anything for linux, or do we assume that those people can get FreeImage compiled manually or via a package manager easily enough? I could just package these up as "data" in a python module, and then point ctypes at the right lib based on run-time checks. Maybe silly to distribute extra binaries, but that might be the user-friendliest solution? Other feedback welcome of course. Zach

2 1

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

07 Feb '12

I have played with this and the size of the resulting segmentation is extremely sensitive to the marker thresholds, something that I can't allow, as I want to calculate the blob-covered area as well.

1 0

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

07 Feb '12

Hi folks, I am searching for the best way of doing blob detection in my noisy planetary image data but I just can't find the egg-laying woolen milk-giving pig (german proverb) that would solve all my problems, but then again it wouldn't be called research, if there's nothing to research, right? ;) In this case, I don't understand the working principle of the random_walker_segmentation example for one simple reason (i.e. 2 simple lines ;) ): markers[data < -0.3] = 1 > markers[data > 1.3] = 2 Where do I get these thresholds from? In fact, finding reasonable thresholds that for sure contain the objects I am interested in is the whole problem, isn't it? If I have to read out 'reasonable' values from the histogram first, how would I do that? I played with 'significance' thresholding, something like dark pixels have to be x*sigma away from a median image pixel value, but then randomly-shaped shadows in noisy data that has no blobs are also being identified as blobs, which I need to avoid (see attached images with and without blobs). I also tried already to get rid of identified shadows using morphology operators (something like a proper blob has to survive 2 or 3 erosion operators) but this is not clean enough either. Can you maybe recommend a chain of image operations that would find me blobs in noisy data while having a low rate of false positives? Best regards, Michael PS.: I can't exclude that my brain is using a shape-related expectation about how the blobs have to look like, so maybe I have to put that into the game as well?

1 0