Mailman 3 February 2012 - scikit-image

Re: Imshow and Linescan - first version
by Guillaume Gay 11 Mar '12

11 Mar '12

Le 26/02/2012 21:15, Stéfan van der Walt a écrit : > On Sat, Feb 25, 2012 at 11:10 AM, Tony Yu<tsyu80(a)gmail.com> wrote: >> Plugin system >> ------ >> It might be nice to have some sort of plugin system for the image viewer. >> That way, tools like this could be implemented a bit more easily and, also, >> easily added to the viewer or ignored by the user. > At the moment, we basically have a double-viewer implementation: > simply vs fancy. So we separate out > > imshow(x) and imshow(x, fancy=True) I thought one solution was to sub-class FigureCanvas, with extra buttons, but from what I understand, it is not that easy to do this at the platform independant level. But maybe adding arguments to the function call, for exemple imshow(x, set_contrast=True, linescan=True) plus keyboard toggles is enough? > >> agree to an extent. Nevertheless, I think providing a viewer that supplies >> *an infrastructure* for creating GUI tools might be really valuable. I >> haven't really thought through what this plugin system would look like, so >> it may just be a pipe dream. > This is a tricky problem (which set of tools to use, etc.)--but in > principle, it would be nice to have a few standard viewers, e.g., > image compare, image compare + parameter adjust, mask editor (to build > custom filters, e.g.) and image inspector (like the one you and > Guillaume are working on). > > Stéfan > What do you mean by mask editor? Something like a slider to adjust a threshold with a superimposed mask? Guillaume

5 4

RFC: Multiple backends + speedy looping
by Stéfan van der Walt 01 Mar '12

01 Mar '12

Hello everyone, After the skimage 0.5 release, it's time to start planning the Next Big Thing (TM). I hoped there would be a better solution by now, but it seems that one of our main weak points is still that we cannot do fast looping over images (e.g., filtering). We have multiple computing back-end support available as a pull request from Pieter Holtzhausen's GSOC--the code is fairly simple to understand, and doesn't complicate the framework more than necessary. This will allow us to, when doing convolutions e.g., first try doing it via OpenCL, and then to fall back to the CPU. We also have a full testing framework in place, so that the output from different back-ends are compared. Have a look at the code here: https://github.com/scikits-image/scikits-image/pull/14/files If you have a better solution or other alternatives in mind, please let me know; I'm keen to explore this space further. Regards Stéfan

1 0

Re: [scikits-image] Restore previous io plugins (#152)
by Tony Yu 28 Feb '12

28 Feb '12

2012/2/26 Stéfan van der Walt <stefan(a)sun.ac.za> > On Sun, Feb 26, 2012 at 12:25 PM, Christoph Gohlke <cjgohlke(a)gmail.com> > wrote: > > Instead of restoring the default plugins after each test module, maybe it > > would be better/cleaner/safer for the tests to never change the default > > plugins but to just load the plugin and explicitly specify the plugin in > > each imread, imwrite, etc. function call? It seems there is currently no > way > > to load a plugin without making it the default. This could be achieved by > > changing the use_plugin function to accept another option for the `kind` > > parameter, e.g. an empty string, signaling that the plugin should only be > > loaded. Probably too late for the 0.5 release. > > Ideally, the ``imread(..., plugin='fits')`` functionality should > auto-load the FITS-plugin---I should see why this is not currently > working, because it seems like a bug. > > Stéfan > I just submitted PR #157<https://github.com/scikits-image/scikits-image/pull/157> to address an error raised with non-loaded plugins. I'm not sure if this addresses the issue you mention above, but it's related, at least. -Tony

1 0

Re: [scikits-image] Restore previous io plugins (#152)
by James Turner 28 Feb '12

28 Feb '12

> Ideally, the ``imread(..., plugin='fits')`` functionality should > auto-load the FITS-plugin---I should see why this is not currently > working, because it seems like a bug. Oh, did someone say FITS plugin? I've been meaning to get back to that (sorry, too busy trying to finish up our Python distribution for astronomy). I believe I had some uncommitted changes after SciPy that we were pending me figuring out how to deal with metadata. I can try to look at this but it might take a couple of days to get to. Please let me know if you have Qs in the meantime (I'm not sure about auto-loading off the top of my head). Cheers, James.

2 1

Windows binaries and 0.5
by Stéfan van der Walt 27 Feb '12

27 Feb '12

Hey all, Christoph has already built scikits-image 0.5 packages for windows. Thanks a bunch, Chris! And thanks also to everyone who contributed to this release! Stéfan

1 0

ANN: scikits-image v0.5
by Stéfan van der Walt 27 Feb '12

27 Feb '12

Announcement: scikits-image 0.5 =============================== We're happy to announce the 0.5 release of scikits-image, our image processing toolbox for SciPy. For more information, please visit our website http://scikits-image.org New Features ------------ - Consistent intensity rescaling and improved range conversion. - Random walker segmentation. - Harris corner detection. - Otsu thresholding. - Block views, window views and montage. - Plugin for Christoph Golke's "tifffile". - Peak detection. - Improved FreeImage wrappers and meta-data reading. - 8-neighbor and background labelling. ... along with updates to the documentation and website, and a number of bug fixes. Contributors to this release ---------------------------- * Andreas Mueller * Brian Holt * Christoph Gohlke * Emmanuelle Gouillart * Michael Aye * Nelle Varoquaux * Nicolas Pinto * Nicolas Poilvert * Pieter Holtzhausen * Stefan van der Walt * Tony S Yu * Warren Weckesser * Zachary Pincus

1 0

Re: [scikits-image] Restore previous io plugins (#152)
by Christoph Gohlke 27 Feb '12

27 Feb '12

On 2/26/2012 12:05 PM, StÃ¯Â¿Â½fan van der Walt wrote: > On Sun, Feb 26, 2012 at 8:08 AM, Zachary Pincus<zachary.pincus(a)yale.edu> wrote: >>> This fixes an issue when running skimage.io.tests. When the tifffile plugin is left active two subsequent tests in skimage.morphology fail to read PNG files. >> Should I add similar teardown() stanzas to all of the image IO plugin tests so that none are left present thereafter, to avoid other such errors? (Though the other plugins read PNGs, it might be a better habit to tear everything down anyway.) > Thanks, I also thought this would be a good idea, after seeing > Christoph's patch. > > StÃ¯Â¿Â½fan > Instead of restoring the default plugins after each test module, maybe it would be better/cleaner/safer for the tests to never change the default plugins but to just load the plugin and explicitly specify the plugin in each imread, imwrite, etc. function call? It seems there is currently no way to load a plugin without making it the default. This could be achieved by changing the use_plugin function to accept another option for the `kind` parameter, e.g. an empty string, signaling that the plugin should only be loaded. Probably too late for the 0.5 release. Christoph

2 1

Re: Imshow and Linescan - first version
by Stéfan van der Walt 27 Feb '12

27 Feb '12

On Sat, Feb 25, 2012 at 11:10 AM, Tony Yu <tsyu80(a)gmail.com> wrote: > Plugin system > ------ > It might be nice to have some sort of plugin system for the image viewer. > That way, tools like this could be implemented a bit more easily and, also, > easily added to the viewer or ignored by the user. At the moment, we basically have a double-viewer implementation: simply vs fancy. So we separate out imshow(x) and imshow(x, fancy=True) > agree to an extent. Nevertheless, I think providing a viewer that supplies > *an infrastructure* for creating GUI tools might be really valuable. I > haven't really thought through what this plugin system would look like, so > it may just be a pipe dream. This is a tricky problem (which set of tools to use, etc.)--but in principle, it would be nice to have a few standard viewers, e.g., image compare, image compare + parameter adjust, mask editor (to build custom filters, e.g.) and image inspector (like the one you and Guillaume are working on). Stéfan

1 0

Re: 0.5 Release
by Christoph Gohlke 27 Feb '12

27 Feb '12

On 2/25/2012 3:26 PM, StÃ¯Â¿Â½fan van der Walt wrote: > Hi all, > > I'm slightly behind on the release, but I have to cut it before PyData > this upcoming week, so if there's anything urgent that you'd like to > go in still, please let me know by tomorrow. I'll try to push out the > release Sunday evening, Pacific time. > > Thanks! > StÃ¯Â¿Â½fan > Hi StÃ¯Â¿Â½fan, I submitted a couple of pull requests, which fix all test errors and failures on win32 and win-amd64 platforms. Ciao, Christoph

2 1

Re: [scikits-image] Restore previous io plugins (#152)
by Zachary Pincus 27 Feb '12

27 Feb '12

Hi all, I see there's been a flurry of fixit and cleanup patches! Thanks all, especially Christoph, and especially as I see a lot of these oversights about python 3 syntax etc. came from my code. Sorry :) Thanks also for noticing the following issue Christoph: > This fixes an issue when running skimage.io.tests. When the tifffile plugin is left active two subsequent tests in skimage.morphology fail to read PNG files. Should I add similar teardown() stanzas to all of the image IO plugin tests so that none are left present thereafter, to avoid other such errors? (Though the other plugins read PNGs, it might be a better habit to tear everything down anyway.) Zach

2 1

Re: Object detection
by Zachary Pincus 26 Feb '12

26 Feb '12

> I'd love to be able to solve Siggi's problem--this is exactly the > kinds of things our toolbox should be able to address. Is there a template matching module? That'd be a good wish-list item for a simple cython implementation. (Convolution is easy, but sum-of-[absolute|squared]-differences can't be done through convolution alone, right? Or am I being daft?) Zach

2 1

0.5 Release
by Stéfan van der Walt 26 Feb '12

26 Feb '12

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

1 0

Re: Imshow and Linescan - first version
by Christoph Gohlke 26 Feb '12

26 Feb '12

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

1 0

Re: downscaling float32 image to uint12 via scikits.img_as_uint()
by Sigmund 26 Feb '12

26 Feb '12

Am Samstag, 25. Februar 2012 17:46:33 UTC+1 schrieb Tony S Yu: > > Hi Siggi, > > It sounds like you may have a float32 image with values outside of the > assumed range of 0--1 (see user guide<http://scikits-image.org/docs/dev/user_guide/data_types.html>). > > correct! > A couple of solutions; unfortunately, both require you to run skimage from > github (there's been a lot of activity since the last release): > no issues with the 0.5dev installation and use so fare on Mac OSX 10.6.8 > * Assuming you have float values outside the range, use > `rescale_intensity`<http://scikits-image.org/docs/dev/api/skimage.exposure.html#rescale-intensi…> to > rescale your image to the correct range. (You can also do this manually > too, of course). > kept the float values since conversion is not needed anymore > * Use `threshold_otsu`<http://scikits-image.org/docs/dev/api/skimage.filter.html#threshold-otsu> from > skimage instead of mahotas. > works great! > Also, all conversion functions should now (i.e. github master) raise an > error when given a float image outside of the 0--1 range, so this shouldn't > happen in the future. > in my case they raise the error > Best, > -Tony > > Thanks! Great job! Siggi

1 0

Re: Object detection
by Stéfan van der Walt 26 Feb '12

26 Feb '12

Hi Tony On Thu, Feb 23, 2012 at 7:57 AM, Tony Yu <tsyu80(a)gmail.com> wrote: > I have a hough-circles implementation (which I've been meaning to > contribute). Unfortunately, my implementation does a pretty poor job when > there's a large range of circle size and when the circles are > close/overlapping. I'm not sure this is your implementation's fault--aren't the parameters just overly sensitive in general? I searched for a different parametrization, and found this paper on the arxiv: http://arxiv.org/abs/cs/0301001v1 Have you ever seen the Hough transform implemented using this formulation? (A(x^2 + y^2) + B(x) + C(y) + D). Maybe we're on to something :) I'd love to be able to solve Siggi's problem--this is exactly the kinds of things our toolbox should be able to address. Stéfan

1 0

Re: Imshow and Linescan - first version
by Tony Yu 26 Feb '12

26 Feb '12

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

1 0

Object detection
by Sigmund 26 Feb '12

26 Feb '12

Dear Group, I'm trying to do object detecting on images as shown on the end of the post. I tried to adapt the coin example in the gallery but the results are not good. My problem is that both the background (bg) and the objects have large variations in there gray value. By the way, these are tiny little ice spheres (30-100 microns) A second approach was to do a laplace filter and threshold the result but even there, the variability is to big (see below). Well, before I change the measurement technique (change bg) or start working on sorting out which group of segments form a sphere, I thought, I better ask some adepts in image processing if there is an easier way. Thanks in advance! Siggi <https://lh3.googleusercontent.com/-PeS-7pVfM6Y/T0T09jyQD5I/AAAAAAAAADs/s3N1…> <https://lh4.googleusercontent.com/-xhi_BdlNmS0/T0T5Mc56y8I/AAAAAAAAAD4/XRAL…>

6 7

downscaling float32 image to uint12 via scikits.img_as_uint()
by Sigmund 26 Feb '12

26 Feb '12

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

2 1

Re: Imshow and Linescan - first version
by Guillaume Gay 24 Feb '12

24 Feb '12

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

2 1

Re: GUI tools and upsizing
by Guillaume Gay 24 Feb '12

24 Feb '12

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

4 5

Re: Object detection
by Guillaume Gay 24 Feb '12

24 Feb '12

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

2 1

Re: GUI tools and upsizing
by Zachary Pincus 22 Feb '12

22 Feb '12

> On Tue, Feb 21, 2012 at 2:23 PM, Tony Yu <tsyu80(a)gmail.com> wrote: >> I haven't really been following this discussion closely, but the TIFFFile >> viewer isn't actually TIFF-specific, is it? If not, it should probably be >> either integrated with the matplotlib plugin or set as an optional interface >> to matplotlib plugin using a "fancy" parameter (like the one for the qt >> plugin). > > Yes, I think doing it as part of the Matplotlib plugin makes most sense. OK, I've merged the tifffile IO plugin; as I'm no expert on the GUI display side, I'll leave it to someone else to port over the improved imshow that tifffile provides... Zach

1 0

Re: GUI tools and upsizing
by Stéfan van der Walt 22 Feb '12

22 Feb '12

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

1 0

Re: GUI tools and upsizing
by Zachary Pincus 22 Feb '12

22 Feb '12

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

2 1

Re: GUI tools and upsizing
by Tony Yu 21 Feb '12

21 Feb '12

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

1 0

Re: GUI tools and upsizing
by Guillaume Gay 20 Feb '12

20 Feb '12

Le 14/02/2012 05:44, Neil Yager a écrit : > Hi everyone, > > Two questions: > > 1. One thing that I think would be very useful is some simple > interactive tools for examining with images. For example, 2 simple > additions to the basic matplotlib's imshow would be to show the pixel > intensity of the current mouse location (it already shows the x, y > coordinates). Also, it would be nice to be able to click at 2 points > and display the profile of intensities between them. Would adding > functionality like this cause too many compatibility issues, or be > moving too far away from skimage's core strength? Hello, I just happen to code a simple linescan function, if that helps... Guillaume > > 2. I'm currently working with large images and it often useful to work > with down-sampled versions. A quick way to do this is using views: > > im_small = im[::4, ::4] > > Is there a quick way to do the inverse? i.e. something like: > > im_big = im[::0.25, ::0.25] > > At the moment I'm just resizing the image, which has more overhead. > Anything I'm missing? > > Cheers, > Neil >

2 1

Re: GUI tools and upsizing
by Stéfan van der Walt 20 Feb '12

20 Feb '12

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

1 0

Re: Understanding HoG output
by bricklemacho 17 Feb '12

17 Feb '12

Hi Brian, and Tony. Thanks both for your response. I hope my newbie terminology is not making this more confusing. > Tony's answer is spot on here. Perhaps you expect that the HoG image > should look like the gradient image? Instead, what the descriptor is > really aiming to capture is the direction (that's the 'oriented' > part), that the gradients go. So assuming an image where the left half > is black and the right half white, there would be a vertical of > horizontal (or as close as possible, depending on the number of bins) > lines in the HoG image. Okay, makes sense, the direction of the change would be horizontal direction if the line in the orignal image was vertical. This is how I originally interpreted the visualisation provide by the skimage-hog algorithm. The problem was when I comparing this to the visualisation from the Dalal & Triggs paper. In the paper the R-HOG descriptor seems to show a different relationship, when visualised the dominant orientations appear to be parallel to lines in the original image. If you have access to the Dalal & Triggs paper, I am basing my expectations on Figure 6(e), top of page 8. I don't have access to the original Dalal & Triggs visualisation code so I will reread the paper to make sure I am comparing like with like. > This is what I was referring to when I talked about the number of > bins. If you look carefully at the HoG image, you'll notice that > there are vertical lines in some places (like at the black billboard), > but there are no perfectly horizontal lines. The closest > approximation to horizontal is maybe a 20deg line. That's because > there are 9 bins. If you tried this with 8 bins, you should see some > horizontal lines. If I change play with the bins I do end up with horizontal lines. I suspect what is being visualised is different, or being interpreted differently, to what the Dala & Triggs paper is visualisation. I just have to understand the different visualisations. Thanks again for your help. Michael. --

2 2

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

17 Feb '12

Hi Michael, > > I don't actually understand HoG that well, but this result, I believe, is expect. Assuming HoG does what the name suggests, you should expect the lines to align with the direction with the largest gradient. So, if the pole of the street light is a dark gray, and the background is white, then the lines should be perpendicular to the pole since this is the direction of the highest gradient. > Tony's answer is spot on here. Perhaps you expect that the HoG image should look like the gradient image? Instead, what the descriptor is really aiming to capture is the direction (that's the 'oriented' part), that the gradients go. So assuming an image where the left half is black and the right half white, there would be a vertical of horizontal (or as close as possible, depending on the number of bins) lines in the HoG image. > I would expect to see the pole of the street light to show dominant perpendicular lines, but they appear to be more horizontal than vertical. This is what I was referring to when I talked about the number of bins. If you look carefully at the HoG image, you'll notice that there are vertical lines in some places (like at the black billboard), but there are no perfectly horizontal lines. The closest approximation to horizontal is maybe a 20deg line. That's because there are 9 bins. If you tried this with 8 bins, you should see some horizontal lines. Hope it helps Brian

1 0

Re: Understanding HoG output
by bricklemacho 16 Feb '12

16 Feb '12

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

2 1

Re: GUI tools and upsizing
by Tony Yu 15 Feb '12

15 Feb '12

2012/2/14 Stéfan van der Walt <stefan(a)sun.ac.za> > Hey Neil > > On Mon, Feb 13, 2012 at 8:44 PM, Neil Yager <yager.neil(a)gmail.com> wrote: > > 1. One thing that I think would be very useful is some simple > > interactive tools for examining with images. For example, 2 simple > > additions to the basic matplotlib's imshow would be to show the pixel > > intensity of the current mouse location (it already shows the x, y > > coordinates). Also, it would be nice to be able to click at 2 points > > and display the profile of intensities between them. Would adding > > functionality like this cause too many compatibility issues, or be > > moving too far away from skimage's core strength? > > Not at all! Would you like to update the fancy viewer? It already > does most of what you want: > > from skimage import io, data > io.use_plugin('qt') > io.imshow(data.camera(), fancy=True) > This is strange: imshow (with or without "fancy") isn't working for me with the qt backend. Or actually, imread_qt isn't working for me (see traceback below; also imshow works if I force skimage to use a different imread, although the window disappears immediately). I'm not really sure how to debug a MemoryError. What's weird is that I'm certain I've used the fancy viewer since the addition of imread_qt (July 2011). I updated (Py)Qt but that didn't help. -Tony python(34737,0x7fff70b93cc0) malloc: *** mmap(size=140734799798272) failed (error co de=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug Traceback (most recent call last): File "qtshow.py", line 9, in <module> io.imshow(data.camera(), fancy=True) File "/Users/Tony/python/devel/skimage/skimage/data/__init__.py", line 34, in came ra return load("camera.png") File "/Users/Tony/python/devel/skimage/skimage/data/__init__.py", line 27, in load return imread(_os.path.join(data_dir, f)) File "/Users/Tony/python/devel/skimage/skimage/io/_io.py", line 72, in imread img = call_plugin('imread', fname, plugin=plugin, **plugin_args) File "/Users/Tony/python/devel/skimage/skimage/io/_plugins/plugin.py", line 88, in call return func(*args, **kwargs) File "/Users/Tony/python/devel/skimage/skimage/io/_plugins/qt_plugin.py", line 102 , in imread_qt img = np.array(arrayptr) MemoryError

1 0

Re: GUI tools and upsizing
by Neil Yager 15 Feb '12

15 Feb '12

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

1 0

Re: GUI tools and upsizing
by Stéfan van der Walt 14 Feb '12

14 Feb '12

Hey Neil On Mon, Feb 13, 2012 at 8:44 PM, Neil Yager <yager.neil(a)gmail.com> wrote: > 1. One thing that I think would be very useful is some simple > interactive tools for examining with images. For example, 2 simple > additions to the basic matplotlib's imshow would be to show the pixel > intensity of the current mouse location (it already shows the x, y > coordinates). Also, it would be nice to be able to click at 2 points > and display the profile of intensities between them. Would adding > functionality like this cause too many compatibility issues, or be > moving too far away from skimage's core strength? Not at all! Would you like to update the fancy viewer? It already does most of what you want: from skimage import io, data io.use_plugin('qt') io.imshow(data.camera(), fancy=True) > 2. I'm currently working with large images and it often useful to work > with down-sampled versions. A quick way to do this is using views: > > im_small = im[::4, ::4] > > Is there a quick way to do the inverse? i.e. something like: > > im_big = im[::0.25, ::0.25] Emmanuelle's suggestion (to use ndimage.zoom) is the right one. We should probably write a wrapper around our fast_homography code, though, because it yields better results (fewer boundary effects, it's a bit faster). Here's a start: import numpy as np from skimage import transform, img_as_float def zoom(image, s): H = np.array([[s, 0, 0], [0, s, 0], [0, 0, 1]]) output_shape = np.ceil(np.array(image.shape) * s) image = img_as_float(image) return transform.fast_homography(image, H, output_shape=output_shape) Stéfan

1 0

Re: GUI tools and upsizing
by Emmanuelle Gouillart 14 Feb '12

14 Feb '12

Hi Neil, just answering quickly to your second question (someone will still have to answer the first one!). > 2. I'm currently working with large images and it often useful to work > with down-sampled versions. A quick way to do this is using views: > im_small = im[::4, ::4] > Is there a quick way to do the inverse? i.e. something like: > im_big = im[::0.25, ::0.25] > At the moment I'm just resizing the image, which has more overhead. > Anything I'm missing? I use scipy.ndimage.zoom for this purpose. Cheers, Emmanuelle

1 0

GUI tools and upsizing
by Neil Yager 14 Feb '12

14 Feb '12

Hi everyone, Two questions: 1. One thing that I think would be very useful is some simple interactive tools for examining with images. For example, 2 simple additions to the basic matplotlib's imshow would be to show the pixel intensity of the current mouse location (it already shows the x, y coordinates). Also, it would be nice to be able to click at 2 points and display the profile of intensities between them. Would adding functionality like this cause too many compatibility issues, or be moving too far away from skimage's core strength? 2. I'm currently working with large images and it often useful to work with down-sampled versions. A quick way to do this is using views: im_small = im[::4, ::4] Is there a quick way to do the inverse? i.e. something like: im_big = im[::0.25, ::0.25] At the moment I'm just resizing the image, which has more overhead. Anything I'm missing? Cheers, Neil

1 0

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

14 Feb '12

Hi Ray, this segmentation algorithm with supervised learning really seems great! I wonder whether we could have a similar algorithm in skimage. ilastik.org is down at the moment, so I can't check their license. But there is a random forest classifier in scikit-learn that we could re-use. A difficult point is the in-painting of pixels on the image; could anyone give hints about technical solutions to do this? Cheers, Emmanuelle On Thu, Feb 09, 2012 at 01:06:57PM +0100, Thouis Jones wrote: > On Thu, Feb 9, 2012 at 11:44, Michael Aye <kmichael.aye(a)gmail.com> wrote: > > ilastik does not seem to have a programmatic interface, is that right? > > I can't do it via GUI's, my end goal is to find features programmatically in > > possibly thousands of images... > It has a scripting interface (command line) for batch processing. I > have talked to them about adding a client/server mode using zmq, but > it's not yet started. > Ray

2 1

dependencies: numpy, matplotlib
by Emmanuelle Gouillart 14 Feb '12

14 Feb '12

> That's a very valid point. And since it's so little effort to remain > 1.5 compatible, there seems little reason not to. > I'm the guilty party that suggested the use of a numpy 1.6 call in the > converter functions--sorry about that! Chris has kindly made a PR to > address the issue. And it works like a charm, as I just tested with my "old" ;-) set-up (numpy 1.5). Build and tests work fine, the doc builds well, just perfect! I saw that you've already merged the PR, but I wanted to confirm that it works fine for me. Thanks Chris, you rock! > So, let's talk about Matplotlib--can we use version 1 yet? If not, I > suggest that we at least copy over 'subplots', because this function > makes it so much easier to build clean examples. I think Matplotlib is a smaller issue, since it's only used to build the doc (am I wrong?), that is, more a developer's than a user's job. And Matplotlib 1.0.1 is packaged for the latest ubuntu. There is always the risk that people download an example, try to execute it and are annoyed by the error they get if they have an older version of matplotlib. If people start complaining, then we might copy over matplotlib's subplots and call skimage.subplots. But I think that this wouldn't discourage new users, contrary to installation problems. Maybe a sentence in the user guide on how to adapt examples for matplotlib < 1.0 could help, too. So my opinion is, yes, we could use version 1 now. Cheers, Emmanuelle

1 0

Re: Error when building from git
by Zachary Pincus 13 Feb '12

13 Feb '12

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

3 5

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

13 Feb '12

Hi StÃ¯Â¿Â½fan, > I understand the challenges of running on an older platform, but I > also wonder: if a user can recompile scikits-image, what's stopping > them from also building the latest (stable) numpy? Well, it's just one more pain in the neck to build another package. And if you have to build numpy, (I think) you also have to build your own matplotlib, scipy, etc. Which is even a greater pain. What's more, a large fraction of users want to use the packages installed by their IT managers, who like to have one standard version of all packages. People using Python(x,y) on Windows, for example, would have a hard time building all the packages. I think the example given by JÃ¯Â¿Â½rÃ¯Â¿Â½me is a good one: he works in a big institute where people might be interested in using skimage, but users typically don't install their own packages. That said, we can of course tell people to install an older version skimage. However, I have the impression that an important part of the added value of new releases are in the algorithms/functions that the release provides, rather than in using newer numpy functionalities. This is by all means a biased point of view, since I've been more busy with the former point. > I certainly have > the expectation that software should run with the available stable > versions of dependencies on the date of release. That said, any > benefit we can get with little effort is worth it, and there's no > reason to purposefully make it harder for users than need be. So > please, keep the PRs coming for backwards compatibility, as long as > they are not too disruptive. OK, I'll try to :-D. Cheers, Emmanuelle

2 1

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

13 Feb '12

Giving a humble user side perspective here... I think Stéfan is right: if I use the git repository for skimage, I shall expect that it depends on the latest versions of the dependencies, and not complain about lack of compatibility with the packaged version of numpy, for example. Yet ... somehow I felt I could use the latest version of skimage (because there would be for example the latest algorithms implemented) without having to reconsider my whole python environment, notably because I am not 100% sure the rest of my code won't suffer. Said otherwise numpy is at the root of lots of stuff I'm doing, and skimage is closer to the tip. Pushing this a lot, you could say: the user shall be ready to compile the latest linux kernel, as they are cloning skimage from git.... I guess the equilibrium here is hard to catch. Guillaume Le 11/02/2012 23:26, Stéfan van der Walt a écrit : > 2012/2/11 Jérôme Kieffer<google(a)terre-adelie.org>: >> PS: We are currently deploying debian6 (squeeze) at work which should >> be the reference until end 2013 (at least!) so putting dependency on a >> too-recent numpy will prevent skimage to be deployed on the beamline. > I guess the point I was trying to make is that nobody expects SciPy 12 > to work with NumPy 1.5, since they are released at different times. > If you install scikits-image 0.4, released when NumPy 1.5 was stable, > you'll get 1.5 compatibility. The problem only comes in when you > require the latest functionality--in which case upgrading the package > + dependencies seems completely reasonable. > > If we focus on getting scikits-image packaged in the different > distros, these problems should more-or-less go away, since people will > do "apt-get install python-skimage" and be happy with whichever > version is provided. > > Stéfan >

1 0

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 13 Feb '12

13 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 13 Feb '12

13 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 12 Feb '12

12 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 12 Feb '12

12 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