Mailman 3 February 2012 - scikit-image

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

10 Feb '12

On Thu, Feb 9, 2012 at 12:26 AM, Thouis Jones <thouis.jones(a)curie.fr> wrote: > Or take a look at ilastik (ilastik.org). We've been using this in a What a neat project! I've added a link to our front page. Stéfan

1 0

Re: 0.5 release soon?
by Stéfan van der Walt 10 Feb '12

10 Feb '12

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

1 0

Error when building from git
by Guillaume 10 Feb '12

10 Feb '12

Hey list, First thanks for the great work. I am planning to use skimage for some fluorescence microscopy analysis. Today I installed from the git repository and an error occurred when compiling: File "/home/guillaume/Python/lib/scikits-image/skimage/util/ dtype.py", line 20, in <module> in <module> np.float16, np.float32, np.float64) AttributeError: 'module' object has no attribute 'float16' taking out 'float16' in the _supported_types tuple solves the issue (at least it compiles), but I don't know whether it could have consequences later on. _supported_types = (np.uint8, np.uint16, np.uint32, np.int8, np.int16, np.int32, #np.float16, ### Commented this out... np.float32, np.float64) I am running Python 2.7.2+ with numpy 1.5.1 (that is what you get with apt-get install python-numpy) Thanks...

2 1

Re: 0.5 release soon?
by Nelle Varoquaux 10 Feb '12

10 Feb '12

On 10 February 2012 06:07, 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. > Are there any major todos before that? > > * Maybe doc additions if they're close. > > * Of the current pull requests, only SSIM and template-matching are close, > but I don't think I'll have much time to sort out the issues with > template-matching for awhile. > > * I was really excited about the image stitching example using HoGs, > suggested by Nelle. If it's not close, though, no pressure. > I'm a bit swamped with work right now, so I'll think we'll have to delay that if you want to do a release before end of February Cheers, Nelle > > Anything else? > > Cheers! > -Tony >

1 0

0.5 release soon?
by Tony Yu 10 Feb '12

10 Feb '12

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

1 0

image conversions
by Michael Aye 09 Feb '12

09 Feb '12

I am working through the docs of skimage and tried out the image conversions. The docs say that these functions *properly rescale* the values, but I'm not sure what is meant with *properly? * *IF *rescaling is meant to exploit the defined range between 0 and 1 for floats, that does not seem to happen: In [13]: data=np.uint(data) In [14]: data.max() Out[14]: 27 In [15]: data.min() Out[15]: 17 In [16]: fimg = skimage.img_as skimage.img_as_float skimage.img_as_int skimage.img_as_ubyte skimage.img_as_uint In [16]: fimg = skimage.img_as_float(data) In [17]: fimg.max() Out[17]: 6.2864273801181529e-09 In [18]: fimg.min() Out[18]: 3.9581209430373555e-09 In [19]: imshow(fimg) Out[19]: <matplotlib.image.AxesImage at 0xe38b1f0> In [20]: data.dtype Out[20]: dtype('uint32') Or do I misunderstand something? Best regards, Michael

3 3

Re: Fixing image loading in Python: imread
by Luis Pedro Coelho 09 Feb '12

09 Feb '12

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

1 0

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

09 Feb '12

Hi Thouis, ilastik does not seem to have a programmatic interface, is that right? I can't do it via GUI's, my end goal is to find features programmatically in possibly thousands of images...

2 1

Understanding HoG output
by bricklemacho 09 Feb '12

09 Feb '12

Hi, new to group, new to image processing starting to explore HoG. Looking for a python implementation and discovered skimage.feature.hog(). My plan to run skimage.features.hog over some positive/negative images and use this to train a svm classifier from scikits-learn. I am trying to understand the output hog before I proceed further. When I run skimag.feature.hog() it over a region of interest it appears to returns an array. How do I interpret this array? Is there a way to reshape the array to see what it was like before it was flattened or that doesn't make any sense? Can I plot the descriptor returned in any meaningful way? Also when I choose to visualise the HoG often where I expected to see vertical line dominate, say on the edge of builds, the line drawn often appears to be more dominant at the 45 deg. Is this expected as the line drawn is really just the sum of all surrounding orientations for the "cell"? Thanks in advance, Michael. --

1 0

Re: Documentation sprint over the weekend
by Ralf Gommers 09 Feb '12

09 Feb '12

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

1 0

Re: Documentation sprint over the weekend
by Tony Yu 09 Feb '12

09 Feb '12

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

1 0

Re: Documentation sprint over the weekend
by Stéfan van der Walt 08 Feb '12

08 Feb '12

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

1 0

Re: FreeImage binaries
by Zachary Pincus 08 Feb '12

08 Feb '12

> On Tue, Feb 7, 2012 at 3:10 PM, Zachary Pincus <zachary.pincus(a)yale.edu> wrote: >> FreeImage library downloading from github, alpha version: >> https://github.com/zachrahan/scikits-image/blob/freeimage-install-libs/skim… >> >> No idea how best to bake this in to bdist or install distutils commands. > > That'll do the trick! Then we just need to do a check for whether the > file has already been downloaded, and to timeout after a while. Then > we can include it safely in the setup.py command. OK, timeouts and checks added to the above. It's not an optional flag whether to raise an error if no file for the host platform is found... I thought that might be useful? Anyway, now to figure out how to add it to setup.py install and setup.py bdist -- any ideas? Zach

1 0

Re: Documentation sprint over the weekend
by Ralf Gommers 08 Feb '12

08 Feb '12

On Wed, Feb 8, 2012 at 8:47 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > > > On Wed, Feb 8, 2012 at 2:27 PM, Ralf Gommers <ralf.gommers(a)googlemail.com>wrote: > >> >> >> 2012/2/8 Stéfan van der Walt <stefan(a)sun.ac.za> >> >>> On Tue, Feb 7, 2012 at 6:55 PM, Tony Yu <tsyu80(a)gmail.com> wrote: >>> > >>> > I just added the side bar in PR 128. >>> >>> Nice! >>> >>> http://scikits-image.org/docs/dev/ >>> >> >> Looks great. I just noticed that the logo on that page (and other pages) >> always links to the currently open page, instead of always to >> http://scikits-image.org. Is that intended? >> >> Ralf >> >> > For me, the logo links to the index page of the docs. Is this what you > meant by "currently open page" or is it actually behaving differently? > On http://scikits-image.org/docs/dev/ it points to http://scikits-image.org/docs/dev/. On http://scikits-image.org/ it points to http://scikits-image.org/. On http://scikits-image.org/docs/ it points to http://scikits-image.org/docs/. On http://scikits-image.org/docs/0.3/ it points to http://scikits-image.org/docs/0.3/. This is unusual, and because there are no links to go higher up the tree (say from docs/0.3/ to docs/, or from docs/ to the homepage) it makes the site hard to navigate. > > I guess it is more common---design-wise---for the logo to link to the home > page, but I think going to the main page of the docs is a more common > operation (for me, at least). This is also what the numpy documentation > does. BUT, the numpy docs also has a link history at the very top, which > you can follow to get back to scipy.org. Maybe we should add a homepage > link in the sidebar? > That would be useful. Ralf

1 0

Re: Documentation sprint over the weekend
by Tony Yu 08 Feb '12

08 Feb '12

On Wed, Feb 8, 2012 at 2:27 PM, Ralf Gommers <ralf.gommers(a)googlemail.com>wrote: > > > 2012/2/8 Stéfan van der Walt <stefan(a)sun.ac.za> > >> On Tue, Feb 7, 2012 at 6:55 PM, Tony Yu <tsyu80(a)gmail.com> wrote: >> > >> > I just added the side bar in PR 128. >> >> Nice! >> >> http://scikits-image.org/docs/dev/ >> > > Looks great. I just noticed that the logo on that page (and other pages) > always links to the currently open page, instead of always to > http://scikits-image.org. Is that intended? > > Ralf > > For me, the logo links to the index page of the docs. Is this what you meant by "currently open page" or is it actually behaving differently? I guess it is more common---design-wise---for the logo to link to the home page, but I think going to the main page of the docs is a more common operation (for me, at least). This is also what the numpy documentation does. BUT, the numpy docs also has a link history at the very top, which you can follow to get back to scipy.org. Maybe we should add a homepage link in the sidebar? -Tony

1 0

Re: Documentation sprint over the weekend
by Ralf Gommers 08 Feb '12

08 Feb '12

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

1 0

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

08 Feb '12

2012/2/8 Stéfan van der Walt <stefan(a)sun.ac.za> > On Tue, Feb 7, 2012 at 6:30 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > > OK, maybe I'll do the main package docstring :) (PR #127) > > :) Thanks, Tony. I made a few small tweaks and merged--please have a > look and see if you're happy. > > Cheers > Stéfan > Looks good to me. Thanks, -Tony

1 0

Re: Documentation sprint over the weekend
by Stéfan van der Walt 08 Feb '12

08 Feb '12

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

1 0

Re: skimage module not found by iPython's completion?
by Stéfan van der Walt 08 Feb '12

08 Feb '12

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

1 0

Re: Documentation sprint over the weekend
by Tony Yu 08 Feb '12

08 Feb '12

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

1 0

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

08 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

StackOverflow fun
by Stéfan van der Walt 07 Feb '12

07 Feb '12

Hi all, https://plus.google.com/104831275312843762750/posts/Ai9Bd5DQfAv What can I say...you guys collectively kick ass :) Cheers Stéfan

1 0

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

06 Feb '12

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

1 0

Re: skimage module not found by iPython's completion?
by Stéfan van der Walt 06 Feb '12

06 Feb '12

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

1 0

Re: Documentation sprint over the weekend
by Stéfan van der Walt 06 Feb '12

06 Feb '12

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

1 0

Re: skimage module not found by iPython's completion?
by Michael Aye 06 Feb '12

06 Feb '12

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

1 0

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

06 Feb '12

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

1 0

skimage module not found by iPython's completion?
by Michael Aye 06 Feb '12

06 Feb '12

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

1 0

Re: Documentation sprint over the weekend
by Tony Yu 06 Feb '12

06 Feb '12

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

1 0

Re: Documentation sprint over the weekend
by Michael Aye 06 Feb '12

06 Feb '12

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

1 0

Re: Documentation sprint over the weekend
by Emmanuelle Gouillart 04 Feb '12

04 Feb '12

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

2 1

Re: Documentation sprint over the weekend
by Stéfan van der Walt 04 Feb '12

04 Feb '12

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

1 0

Re: Dependency versions
by Stéfan van der Walt 04 Feb '12

04 Feb '12

Hi Tony On Fri, Feb 3, 2012 at 7:40 AM, Tony Yu <tsyu80(a)gmail.com> wrote: > I'd like to start a discussion on how to handle versions of dependencies. > The current docs suggest that we require Numpy 1.4, but at some point we'd > probably want to increment this. In fact, I forgot that the dtype._convert > pull request (PR #99) uses the function `promote_types` from numpy 1.6. (We > need to either bump up the numpy version now or add a compatibility > function.) I think it is reasonable if the latest release of skimage relies on the latest stable release of numpy and matplotlib. > In addition, we should add a minimum (optional) version of Matplotlib for > use in examples (this has come up in a few PRs already). I recommend that we bump NumPy to 1.6 and Matplotlib to 1.0 (release 2011-01-03). The "subplots" functionality in 1.0 is really, really handy. > I run most of my scientific software from github, so I have no problem with > running the bleeding edge, but this is certainly more difficult for others. > How do other packages increment versions of dependencies? True; but I think that, if you're running old versions of numpy and scipy, running an older version of skimage should be fine. If you need the latest, then it is reasonable to upgrade those packages as well. Backward compatibility comes at a cost, unfortunately! Regards Stéfan

1 0

Fixing image loading in Python: imread
by Luis Pedro Coelho 03 Feb '12

03 Feb '12

Hi, I finally got a bit fed up with the state of reading & writing images in Python/numpy and started a new project: imread https://github.com/luispedro/imread I want it to be simple: No image processing at all, just getting the bytes out of image files and into image files. This way it has a better chance of being very stable and getting into linux distros and stuff like that. Once it matures a bit, I will use it in mahotas and I will submit a patch to scikits.learn. It currently has two functions imread : filename -> numpy array : reads a file imsave: filename & numpy array : writes a file I can imaging adding another pair to read&write to an in-memory buffer and perhaps a way to guess fileformats and retrieve metadata. But, again, there will be exactly zero image processing functions. That's for other packages to worry about. It only supports PNG at the moment (using libpng) and JPEG (through libjpeg). It needs better error checking, of course. It should be boring and solid. With TIFF, I will call it "1.0" as it will cover most use cases. What do you guys think? -- Luis Pedro Coelho | University of Lisbon | http://luispedro.org Q29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9wZ3Atc2lnbmF0dXJlOyBuYW1lPSJzaWduYXR1cmUu YXNjIg0KQ29udGVudC1EZXNjcmlwdGlvbjogVGhpcyBpcyBhIGRpZ2l0YWxseSBzaWduZWQgbWVz c2FnZSBwYXJ0Lg0KDQotLS0tLUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLQpWZXJzaW9uOiBHbnVQ RyB2MS40LjExIChHTlUvTGludXgpCgppRVlFQUJFQ0FBWUZBazhzRkcwQUNna1FFUTFzbU9kZ3Z2 STZQUUNlUFR6Mnd5Zk5UeGo4RnhSUHAzQUJJOTVUCnJIOEFuMm5ubGJkcDFZK3ArUXhuVVVxL205 MGF0aXhOCj1kSlF5Ci0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo=

2 1

Dependency versions
by Tony Yu 03 Feb '12

03 Feb '12

Hi everyone, I'd like to start a discussion on how to handle versions of dependencies. The current docs suggest that we require Numpy 1.4<http://scikits-image.org/docs/dev/install.html>, but at some point we'd probably want to increment this. In fact, I forgot that the dtype._convert pull request (PR #99) uses the function `promote_types` from numpy 1.6. (We need to either bump up the numpy version now or add a compatibility function.) In addition, we should add a minimum (optional) version of Matplotlib for use in examples (this has come up in a few PRs already). I run most of my scientific software from github, so I have no problem with running the bleeding edge, but this is certainly more difficult for others. How do other packages increment versions of dependencies? Best, -Tony

1 0

Re: Getting Mahotas on Windows to run
by Stéfan van der Walt 02 Feb '12

02 Feb '12

Hi Thomas Welcome to the scikits-image mailing list. On Thu, Feb 2, 2012 at 12:54 PM, thomash <thomas.haslwanter(a)gmail.com> wrote: > I am fairly new to image processing in Python, and have a bugger of a > time getting Mahotas to run on my Windows machine. (Win7, 32bit, > Python 2.7). The best place to ask Mahotas questions would be on the PythonVision mailing list, where Luis is active: http://groups.google.com/group/pythonvision > My main problem seems to be related to freeimage, and I am wondering > if any of you got it running under Windows? You can also use FreeImage via scikits-image, so please try that as well and let us know: http://www.lfd.uci.edu/~gohlke/pythonlibs/#scikits.image The code snippet you need is: import skimage.io as sio sio.use('freeimage') img = sio.imread('/path/to/image.jpg') sio.imshow(img) Regards Stéfan

1 0

Getting Mahotas on Windows to run
by thomash 02 Feb '12

02 Feb '12

Hi, I am fairly new to image processing in Python, and have a bugger of a time getting Mahotas to run on my Windows machine. (Win7, 32bit, Python 2.7). In addition to installing Mahotas, I copied the "FreeImage.dll" to "C: \Python27\DLLs", the "FreeImage.h" to "C:\Python27\include", and "FreeImage.lib" to "C:\Python27\libs". My main problem seems to be related to freeimage, and I am wondering if any of you got it running under Windows? My error message: In [5]: from mahotas import freeimage ------------------------------------------------------------ Traceback (most recent call last): File "<ipython console>", line 1, in <module> File "C:\Python27\lib\site-packages\mahotas-0.7.1-py2.7-win32.egg \mahotas\__init__.py", line 77, in <module> from .freeimage import imread, imsave File "C:\Python27\lib\site-packages\mahotas-0.7.1-py2.7-win32.egg \mahotas\freeimage.py", line 148, in <module> _FI = _register_api(_FI, _API) File "C:\Python27\lib\site-packages\mahotas-0.7.1-py2.7-win32.egg \mahotas\freeimage.py", line 102, in _register_api func = getattr(lib, f) File "C:\Python27\lib\ctypes\__init__.py", line 366, in __getattr__ func = self.__getitem__(name) File "C:\Python27\lib\ctypes\__init__.py", line 371, in __getitem__ func = self._FuncPtr((name_or_ordinal, self)) AttributeError: function 'FreeImage_CloseMultiBitmap' not found Any hints? Thanks, Thomas

1 0

Re: Documentation sprint over the weekend
by Tony Yu 02 Feb '12

02 Feb '12

2012/2/2 Stéfan van der Walt <stefan(a)sun.ac.za> > Hi all, > > For release 0.5 I'd like to have a good User Guide available for skimage. > I'm going to start writing it this weekend, so if you have some spare > cycles to contribute, that'd be much appreciated! > > Also, have a look at the updated web front page <http://skimage.org>(thanks, Tony!). > > Regards > Stéfan > Hmm, I'm not sure I really deserve the credit for the front page, but thanks! I should have a little bit of free time to work on the docs this weekend. Any specific goals? One thing I'd like to see is a package docstring listing all subpackages (+ 1-sentence descriptions of those subpackages; e.g. type `np?` in ipython); and then each subpackage would have it's own docstring listing of functions (e.g. type `numpy.linalg?` in ipython). I guess this is separate from the user guide, but it's still really valuable for learning the package. While we're talking about release 0.5, I think we should try to clean out a number of pull requests. Some of them should be quick: PR 99 <https://github.com/scikits-image/scikits-image/pull/99>: Rewrite dtype._convert function There is a comment at the end of this PR suggesting we clip when converting int to uint, but maybe we should just merge this PR and add the clipping change as a new PR. In fact, if there are no objections by tomorrow, I'm just going to merge the PR as is. (No promises that I'll submit a PR for the clipping change.) PR 105 <https://github.com/scikits-image/scikits-image/pull/105>: ENH: Allow choice between 4 and 8 neighbor mode. I was waiting for a response to a few suggested changes, but they are relatively minor, so this could be merged as is. PR 95 <https://github.com/scikits-image/scikits-image/pull/95>: debian/control updates to reflect name space transition This seems like a really simple change, but since I don't really use/know-anything-about Debian, I'm hesitant to be the one to merge. PR 107 <https://github.com/scikits-image/scikits-image/pull/107>: Add rescale_intensity function with test and example. Stefan: you mentioned you wanted to send a PR to this branch. If it was an involved change, we should hold off until a later date. I'm not so certain about the others. Cheers, -Tony

1 0

Documentation sprint over the weekend
by Stéfan van der Walt 02 Feb '12

02 Feb '12

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

1 0

Feature Extraction
by Jérôme Kieffer 01 Feb '12

01 Feb '12

Hi, I wonder if you know "IPOL": http://www.ipol.im They publish articles on image processing, featuring implementations (in C/C++). I made bindings for their SIFT and SURF feature extractions & image alignment (only 2 img for now). My cython code could be released under BSD if you wish ... but beside this I don't know the license of (all) the original C++ code: "The implementation of IPOL algorithms is distributed under a free software license, usually GPL, AGPL, LGPL or BSD." It also includes Eigen: Eigen is Free Software. It is licensed under the LGPL3+. As an alternative license choice, Eigen is also licensed under the GPL2+. So LGPL3 seems to be the most permissive license achievable :-/ If it does not make sense for skimage ... I will release it elsewhere but it can interest some of yours. Cheers, -- Jérôme Kieffer <google(a)terre-adelie.org> the code is here: https://github.com/kif/surf/tree/master/features

2 1

FreeImage manitenance
by Zachary Pincus 01 Feb '12

01 Feb '12

Hi all, Apropos of the recent discussion about and troubles with diagnosing FreeImage library loading problems on 64-bit windows, I have tried to enhance the library-loading code: https://github.com/scikits-image/scikits-image/pull/117 And speaking of FreeImage and 64-bit-ness, https://github.com/scikits-image/scikits-image/pull/112 fixes some problems in 64-bit image loading, and also clarifies how to deal with 64-bit pointers and the ctypes interface. Finally, https://github.com/scikits-image/scikits-image/pull/113 builds on the changes in PR 112 to expose basic image metadata reading in a 64-bit-safe manner. Comments welcome. Zach

2 1