Mailman 3 March 2012 - scikit-image

Re: Normalised cross correlation
by Stéfan van der Walt 26 Mar '12

26 Mar '12

On Sat, Mar 24, 2012 at 5:09 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > Just to follow up: This would be my preferred way to pad the image. Here, > the maximum in the output corresponds to the center of the best > template-match. Just as a point of interest, there should soon be some padding capabilities in numpy: https://github.com/numpy/numpy/pull/198 Stéfan

1 0

Re: Normalised cross correlation
by Tony Yu 25 Mar '12

25 Mar '12

On Sat, Mar 24, 2012 at 8:29 PM, Mike Sarahan <msarahan(a)gmail.com> wrote: > Hi Tony, > > Glad you figured this out. > I'm also not a huge fan of the Matlab-style padding. I guess > theoretically, it gives your match greater range - beyond the bounds > of the image. In practice, I found that such behavior in the presence > of noise often gave me a peak outside the image, when I knew I wanted > my peak inside the image. > > I'm mixed on the input padding. Intuitively, I think the high value > at template center is easier to understand for a human looking at the > cross correlation result image. I know that this confused me a lot > when I first encountered cross correlation using OpenCV. However, any > subsequent analysis (peak finding, for example) would have to account > for the difference, and I think this would be more of a headache than > a benefit to people. I can imagine a lot of careless analyses with > offsets of exactly half the template dimensions. > > Your proposed method for the padding makes more sense to me than > Matlab's. I would recommend defaulting to no padding, and also > recommend a little documentation that warns the user about the offset > they will have to account for if using the pad option. > > I can't think of a use case for padding the output with zeros. If > anyone else knows one, I'll be happy to learn, though. > Hey Mike, I guess my rationale for padding with zeros was the following: I want the output hotspot to match the image coordinates, but I don't want to have matches where the template exceeds the image boundaries. With the match centered on the template-origin, this padding actually makes no difference since you're padding only the higher indices, but with the match centered on the template-center, there would be a difference. Also, there's a (usually-insignificant) computational improvement compared to padding the input. I'm just making this stuff up as I go along, so this might not actually be a desirable use case. -Tony > Best, > Mike

1 0

Re: Normalised cross correlation
by Mike Sarahan 25 Mar '12

25 Mar '12

Hi Tony, Glad you figured this out. I'm also not a huge fan of the Matlab-style padding. I guess theoretically, it gives your match greater range - beyond the bounds of the image. In practice, I found that such behavior in the presence of noise often gave me a peak outside the image, when I knew I wanted my peak inside the image. I'm mixed on the input padding. Intuitively, I think the high value at template center is easier to understand for a human looking at the cross correlation result image. I know that this confused me a lot when I first encountered cross correlation using OpenCV. However, any subsequent analysis (peak finding, for example) would have to account for the difference, and I think this would be more of a headache than a benefit to people. I can imagine a lot of careless analyses with offsets of exactly half the template dimensions. Your proposed method for the padding makes more sense to me than Matlab's. I would recommend defaulting to no padding, and also recommend a little documentation that warns the user about the offset they will have to account for if using the pad option. I can't think of a use case for padding the output with zeros. If anyone else knows one, I'll be happy to learn, though. Best, Mike On Sat, Mar 24, 2012 at 4:03 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > > > 2012/3/24 Stéfan van der Walt <stefan(a)sun.ac.za> >> >> Hi Mike >> >> On Sat, Mar 24, 2012 at 2:16 PM, Mike Sarahan <msarahan(a)gmail.com> wrote: >> > I'm out of time for now, but I hope this helps a little. I will >> > investigate further when time allows, provided you all don't beat me >> > to it. >> >> Thanks for looking into this, and for identifying the boundary issue. >> The fact that there are differences even with padding is >> disconcerting; I'll see if I can review this soon. >> >> Stéfan > > > Ok,... so it turns out I made a stupid with the convolution-to-correlation > translation. Fixing that gives comparable *looking* results to matlab (after > Mike's padding patch). BUT, I also get NaN values with the padded output. > These NaNs come from the sqrt of negative values (see code which solves the > denominator). I *think* the argument of the sqrt should (mathematically) be > zero, but round-off errors are causing it to go negative. If that's the > case, then it's an easy fix to check that the argument is positive, but > someone should check my math to make sure the the code matches the equation. > > As for the padding---that was a hack. I noticed the original implementation > clipped the image to (M-m+1, N-n+1) so I padded *the result* with zeros to > make the output (M, N). Also, the way I padded it (all padding on bottom and > right) meant that the output has a high value when "origin" (i.e. top-left > corner) of the template matches, as opposed to the center. This could be > done by padding the image with half the template width to the left and > right, and half the template height to the top and bottom. > > Padding *the input* sounds like a good idea, but I think it should be done > in such a way that the output is (M, N)---i.e. same size as the input image. > I'm not a huge fan of the Matlab output size (but maybe some people expect > this output?). > > Is there a "right" way to do the padding? Or maybe "pad_output" should be > changed to "mode" (to match scipy.signal.convolve) with values 'valid' (no > padding; output (M-m+1, N-n+1)), 'same' (pad input with image mean), and > 'zeros' (pad output with zeros)? > > -T

1 0

Re: Normalised cross correlation
by Tony Yu 25 Mar '12

25 Mar '12

On Sat, Mar 24, 2012 at 7:03 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > > > 2012/3/24 Stéfan van der Walt <stefan(a)sun.ac.za> > >> Hi Mike >> >> On Sat, Mar 24, 2012 at 2:16 PM, Mike Sarahan <msarahan(a)gmail.com> wrote: >> > I'm out of time for now, but I hope this helps a little. I will >> > investigate further when time allows, provided you all don't beat me >> > to it. >> >> Thanks for looking into this, and for identifying the boundary issue. >> The fact that there are differences even with padding is >> disconcerting; I'll see if I can review this soon. >> >> Stéfan >> > > Ok,... so it turns out I made a stupid with the convolution-to-correlation<https://github.com/tonysyu/scikits-image/commit/ff4d66305c35fc7c749ab0d3ff1…>translation. Fixing that gives comparable *looking* results to matlab > (after Mike's padding patch). BUT, I also get NaN values with the padded > output. These NaNs come from the sqrt of negative values (see code<https://github.com/tonysyu/scikits-image/blob/skimage-template/skimage/feat…> which > solves the denominator<https://github.com/tonysyu/scikits-image/blob/skimage-template/skimage/feat…>). > I *think* the argument of the sqrt should (mathematically) be zero, but > round-off errors are causing it to go negative. If that's the case, then > it's an easy fix to check that the argument is positive, but someone should > check my math to make sure the the code<https://github.com/tonysyu/scikits-image/blob/skimage-template/skimage/feat…>matches the > equation<https://github.com/tonysyu/scikits-image/blob/skimage-template/skimage/feat…> > . > > As for the padding---that was a hack. I noticed the original > implementation clipped the image to (M-m+1, N-n+1) so I padded *the result* > with zeros to make the output (M, N). Also, the way I padded it (all > padding on bottom and right) meant that the output has a high value when > "origin" (i.e. top-left corner) of the template matches, as opposed to the > center. This could be done by padding the image with half the template > width to the left and right, and half the template height to the top and > bottom. > > Padding *the input* sounds like a good idea, but I think it should be done > in such a way that the output is (M, N)---i.e. same size as the input > image. I'm not a huge fan of the Matlab output size (but maybe some people > expect this output?). > > Is there a "right" way to do the padding? Or maybe "pad_output" should be > changed to "mode" (to match scipy.signal.convolve) with values 'valid' (no > padding; output (M-m+1, N-n+1)), 'same' (pad input with image mean), and > 'zeros' (pad output with zeros)? > > -T > Just to follow up: This would be my preferred way to pad the image.<https://github.com/tonysyu/scikits-image/commit/d1b0cb40af5e757e786216ae453…> Here, the maximum in the output corresponds to the center of the best template-match. -T

1 0

Re: Normalised cross correlation
by Tony Yu 25 Mar '12

25 Mar '12

2012/3/24 Stéfan van der Walt <stefan(a)sun.ac.za> > Hi Mike > > On Sat, Mar 24, 2012 at 2:16 PM, Mike Sarahan <msarahan(a)gmail.com> wrote: > > I'm out of time for now, but I hope this helps a little. I will > > investigate further when time allows, provided you all don't beat me > > to it. > > Thanks for looking into this, and for identifying the boundary issue. > The fact that there are differences even with padding is > disconcerting; I'll see if I can review this soon. > > Stéfan > Ok,... so it turns out I made a stupid with the convolution-to-correlation<https://github.com/tonysyu/scikits-image/commit/ff4d66305c35fc7c749ab0d3ff1…>translation. Fixing that gives comparable *looking* results to matlab (after Mike's padding patch). BUT, I also get NaN values with the padded output. These NaNs come from the sqrt of negative values (see code<https://github.com/tonysyu/scikits-image/blob/skimage-template/skimage/feat…> which solves the denominator<https://github.com/tonysyu/scikits-image/blob/skimage-template/skimage/feat…>). I *think* the argument of the sqrt should (mathematically) be zero, but round-off errors are causing it to go negative. If that's the case, then it's an easy fix to check that the argument is positive, but someone should check my math to make sure the the code<https://github.com/tonysyu/scikits-image/blob/skimage-template/skimage/feat…>matches the equation<https://github.com/tonysyu/scikits-image/blob/skimage-template/skimage/feat…> . As for the padding---that was a hack. I noticed the original implementation clipped the image to (M-m+1, N-n+1) so I padded *the result* with zeros to make the output (M, N). Also, the way I padded it (all padding on bottom and right) meant that the output has a high value when "origin" (i.e. top-left corner) of the template matches, as opposed to the center. This could be done by padding the image with half the template width to the left and right, and half the template height to the top and bottom. Padding *the input* sounds like a good idea, but I think it should be done in such a way that the output is (M, N)---i.e. same size as the input image. I'm not a huge fan of the Matlab output size (but maybe some people expect this output?). Is there a "right" way to do the padding? Or maybe "pad_output" should be changed to "mode" (to match scipy.signal.convolve) with values 'valid' (no padding; output (M-m+1, N-n+1)), 'same' (pad input with image mean), and 'zeros' (pad output with zeros)? -T

1 0

Re: Normalised cross correlation
by Stéfan van der Walt 24 Mar '12

24 Mar '12

Hi Mike On Sat, Mar 24, 2012 at 2:16 PM, Mike Sarahan <msarahan(a)gmail.com> wrote: > I'm out of time for now, but I hope this helps a little. I will > investigate further when time allows, provided you all don't beat me > to it. Thanks for looking into this, and for identifying the boundary issue. The fact that there are differences even with padding is disconcerting; I'll see if I can review this soon. Stéfan

1 0

Re: Normalised cross correlation
by Mike Sarahan 24 Mar '12

24 Mar '12

Hi guys, I have used NCC a lot in my research, so I thought I'd take a look at this. How critical is it that skimage's result image is the same size as matlab's? The difference arises from the approach to the problem. Matlab is assuming that the template might match an area of the target image that isn't fully in frame. They probably pad the original image (preferably with the target image average), and then do the cross correlation on the padded image. This would explain the different result size - Matlab seems to be M+m-1 by N+n-1. That means they pad by the template width laterally, and the template height vertically. They then have an M+2m x N+2n image, which they then apply the template match to. I haven't figured out the problem with the results not matching, though. The "good" news is that the results with padding the matlab way (pre-match) are especially fishy (nans are cropping up). That's certainly an indicator of something rather fundamental being wrong. I'm out of time for now, but I hope this helps a little. I will investigate further when time allows, provided you all don't beat me to it. Best, Mike On Tue, Mar 20, 2012 at 9:31 AM, Tony Yu <tsyu80(a)gmail.com> wrote: > > > On Tue, Mar 20, 2012 at 12:12 PM, Malcolm Reynolds > <malcolm.reynolds(a)gmail.com> wrote: >>> >>> >>> Wow, those results are incredibly different. Yes, please put together a >>> small script to reproduce the different behaviors (ideally, with the matlab >>> result saved as .npy---or if it's easier .mat---file; also, if you can >>> reproduce with a smaller image, that would be great). >>> >>> It'll be easy to check for switched arguments, but the rest might >>> take some time for me to get to. In your original email, it sounded like you >>> have some expertise in template matching; feel free to dig into the code and >>> see if you can spot any errors in the code. >>> >>> Cheers, >>> -Tony >> >> >> I've quickly whipped up some scripts in both matlab (if you have access to >> that) and python and put them >> here: https://github.com/malcolmreynolds/NCC-test-program - if you don't >> have access to matlab, then the .mat file included should contain the inputs >> and outputs from matlab's normxcorr2. To run it you just need to put any >> image called 'lena.png' in the directory and then I ran 'ipython --pylab -i >> run_ncc.py' at the shell on OS X. You may have your plotting set up a >> different way, or not use pylab, but if all else fails the result images are >> written out as pngs (also included in the repository). With matlab just get >> to the matlab prompt and do "run_ncc". >> >> For reference, this is what I see when using a 256x256 downsampled version >> of the lena image: >> http://img843.imageshack.us/img843/2729/screenshot20120320at155.png (matlab >> on left, middle and right are python with and without the pad_output flag). >> >> I'm afraid I'm definitely not an expert on template matching, but I reckon >> it's pretty crucial to have a good free (&fast!) implementation available in >> numpy/scipy/skimage in order to compete.. I will take a dig through your >> code sometime but unfortunately deadlines are always looming for me.. I'll >> hopefully get a chance this coming weekend. >> >> Thanks for your quick response, let me know if you have any problems with >> the stuff on github. >> >> Malcolm > > > Great. Thanks for putting this together and for the original bug report. > I'll take a look at this soon.... I hope. :) > > -Tony

1 0

New `viewer` subpackage (was [Re: Imshow and Linescan - first version])
by Tony Yu 23 Mar '12

23 Mar '12

2012/3/18 Stéfan van der Walt <stefan(a)sun.ac.za> > Hey, Tony > > On Fri, Mar 16, 2012 at 6:49 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > > Possible Con > > ------------------------ > > Someone mentioned a while back that it would be a good idea to keep > skimage > > focused on the basic toolset, and then a separate package could build > off of > > it. > > > > Counter-argument: This infrastructure (so far, at least) is fairly > > lightweight, and I imagine the biggest area of growth would be the > > plugins---most of which would just provide an interactive interface to > > skimage functions. > > This is the way I see it too: one of skimage's most important > contributions is to provide an easily-accessible Python platform for > building image processing solutions. This exactly means having good > pipelines, good display, and all the tools needed to build a complete > solution. Some of the algorithms may be obtained from elsewhere > (e.g., opencv)--but even so, building a solution using those packages > is currently still a pain. So, I see the construction of these basic > tools and building blocks as a fundamental part of what we're trying > to do. > > > Counter-argument: skimage would provide the simplest possible interface > for > > adding interactivity (taking advantage of Matplotlib tools for plotting > > histograms, etc and its support for multiple gui toolkits). A separate > > project would be ideal for gui-toolkit--specific viewers (which could > > potentially be significantly fast) since it would likely take more code > to > > do some of these things (I could be wrong about this). Also, I assume > more > > people using skimage would know matplotlib over any specific backend. > > I think from the start we assumed that we'd be building tools on > Matplotlib and Qt. If something better comes along, we should > consider it--of course--but in the meantime it still seems like a > reasonable choice. If the plugin infrastructure can be improved to > make it easier to build external tools, I'm also all for that. > > > I'd like to come to some sort of consensus, if possible, so please---if > you > > *any* opinions on this---let your voice be heard. > > I guess my opinion is obvious, but for the record: I'd love to include > this work directly as part of skimage. But, if that's not to be, I > still encourage it whole-heartedly! > > Stéfan > Since there weren't any objections, I added a new `viewer` subpackage in PR 165 <https://github.com/scikits-image/scikits-image/pull/165>. Sorry for the big commit: the full commit history can be found in another repo <https://github.com/tonysyu/skloupe>. The main parts are the viewer base classes<https://github.com/tonysyu/scikits-image/blob/mpl-viewer/skimage/viewer/vie…> and the plugin base class<https://github.com/tonysyu/scikits-image/blob/mpl-viewer/skimage/viewer/plu…>. The rest of the code just demonstrates what this backbone allows. If nothing else, you can play around with the examples<https://github.com/tonysyu/scikits-image/tree/mpl-viewer/examples> . I plan on adding some sort of "How to write a custom Plugin" documentation, but Guillaume didn't seem to have much trouble writing a ContrastSetter plugin even without that :) Cheers, -Tony

1 0

Best multispectral to RGB conversion
by jip 23 Mar '12

23 Mar '12

Dear all, Some one asked me how I choose the matrix coef to convert a five multispectral image to a three (RGB) multispectral image<http://dip4fish.blogspot.fr/2011/05/making-mfish-image.html?showComment=133…>. I feel that there is a best way to do that by maximising some distance in a color space. How would you do that? Examples of multispectral images are available here<https://github.com/jeanpat/MFISH> Best Regard Jean-Patrick Pommier

3 7

Re: PyData scikits-image overview video
by Neil Yager 22 Mar '12

22 Mar '12

Great video! It's really about time I start using the ipython notebook. I've been spending quite a bit of time this week going through the PyCon 2012 videos - there's some great ones (e.g. http://pyvideo.org/video/614/high-performance-python-i). However, many are ~3 hours, so the YouTube tip is definitely going to save me some time. Neil On Mar 21, 8:35 pm, Stéfan van der Walt <ste...(a)sun.ac.za> wrote: > Hi all, > > Max Walker and co. from Marakana did a fantastic job with the videos > from PyData. The scikits-image lecture is now available online: > > http://marakana.com/s/image_processing_in_python_with_scikits-image_p... > > I find it pretty annoying listening to my own voice, so what I like to > do is to go to: > > http://youtube.com/html5 > > and enable the HTML5 trial. Then, if you watch on YouTube, there's an > icon at the bottom to adjust the playback speed to 1.5x (ah, the > relief!). > > Stéfan

1 0