Mailman 3 February 2012 - scikit-image

Re: Object detection
by Guillaume Gay Feb. 23, 2012

Feb. 23, 2012

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 Feb. 22, 2012

Feb. 22, 2012

> 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 Feb. 21, 2012

Feb. 21, 2012

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 Feb. 21, 2012

Feb. 21, 2012

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 Feb. 20, 2012

Feb. 20, 2012

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 Feb. 20, 2012

Feb. 20, 2012

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 Feb. 20, 2012

Feb. 20, 2012

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 Feb. 17, 2012

Feb. 17, 2012

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 Feb. 16, 2012

Feb. 16, 2012

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 Feb. 16, 2012

Feb. 16, 2012

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