Mailman 3 March 2012 - scikit-image

Re: Normalised cross correlation
by Malcolm Reynolds 20 Mar '12

20 Mar '12

On Tuesday, March 6, 2012 6:54:22 PM UTC, Tony S Yu wrote: > > > Hi Malcolm, > > I currently have a PR for a normalized cross-correlation function<https://github.com/scikits-image/scikits-image/pull/100>(which was originally implemented by Pieter Holtzhausen). > Comments/suggestions would definitely be appreciated. > > -Tony > Hi Tony I've just got round to trying this and I may be using it wrong, but currently I'm finding it doesn't match the result given by matlab's normxcorr2. For one thing I think it would make sense to raise an error when the user passes the template and image the wrong way round (matlab does this). Also, I've tested by having the template as the central part of some image, and using ncc to compare the template to the whole image. Ideally since there is one arrangement which makes each pixel match perfectly, there will be a very clear strong peak in the NCC image - which is indeed what I see in matlab (eg http://img840.imageshack.us/img840/8577/screenshot20120320at143.png ). With your match_template function however, I'm unable to get the same result, what I get instead is this: http://img844.imageshack.us/img844/8577/screenshot20120320at143.png - and if I put the template and image arguments in a different order I get an image that looks like it may have accessed invalid memory: http://img849.imageshack.us/img849/7696/screenshot20120320at144.png Additionally, calling template_match a second time with the arguments in this 'wrong' order produces a segmentation fault. Also note that the matlab, when given a 768x432 image and 384x216 template the size of the result from normxcorr2 is 647x1151. As far as I can see this size of result is not possible to create with your code, although please correct me if I'm wrong? I hope these bug reports are useful, if you need me to put together a reproduction script just let me know. Malcolm

2 1

Presentation
by Vincent Albufera 20 Mar '12

20 Mar '12

Hello, I'm Vincent Albufera and I work with Emmanuelle Gouillart as image processing engineer. I would like to contribute to the development of scikits-image. I would like to add and complement the documentation of scikits-image. Best regards, Vincent

4 3

Platform for filters development
by Nadav Horesh 20 Mar '12

20 Mar '12

Attached here a concept code showing my attempt to produce in improved (over ndimage.generic_filter) platform for filters development. The code is very preliminary and needs a lot of extension as well as rewrite. My main questions are: 1. Is there is already a mature package for this purpose? 2. Is there is need for such a module inside scikits? Any comment is welcome. Nadav

1 0

Re: [OT] pass a C callback function to a cythom module via python
by Nadav Horesh 20 Mar '12

20 Mar '12

Can you explain in more details how can I implement it? Any case I am attaching an scheme that may clarify my intend. Soon I'll post a code demonstrating the problem. Thank you, Nadav, בתאריך 17 במרץ 2012 21:44, מאת Chris Colbert <sccolbert(a)gmail.com>: > You can see how we did this before with the opencv wrappers starting at > line 117 of this file: > > > https://github.com/scikits-image/scikits-image/blob/0.3.1/scikits/image/ope… > > > On Sat, Mar 17, 2012 at 2:35 PM, Chris Colbert <sccolbert(a)gmail.com>wrote: > >> cytpes.addressof(...) >> On Mar 17, 2012 12:52 AM, "Nadav Horesh" <nadavh.horesh(a)gmail.com> wrote: >> >>> It is good to know that there is still a hope. In my case I could make >>> it if only a ctype object would expose the address of the underlying C >>> object. >>> >>> Thank you, >>> >>> Nadav. >>> >>> בתאריך 16 במרץ 2012 18:09, מאת Stéfan van der Walt <stefan(a)sun.ac.za>: >>> >>>> Hi Nadav >>>> >>>> On Mar 15, 2012 10:54 PM, "Nadav Horesh" <nadavh.horesh(a)gmail.com> >>>> wrote: >>>> > >>>> > I have the following: >>>> > A library of C function which is compiled into a dll >>>> > A cython module with a function that expects as a parameter a C >>>> callback function. >>>> > >>>> > My problem is how to make a python script to pass directly the >>>> address of a C function from the dll to the cython function. >>>> >>>> There's a Cython Enhancement Proposal for this, but it hasn't been >>>> implemented: >>>> >>>> http://wiki.cython.org/enhancements/nativecall >>>> >>>> So, I don't think there's a cleaner way, unfortunately. It's great that >>>> you found a workaround, though--many people have been struggling with this >>>> issue. >>>> >>>> Stéfan >>>> >>> >

1 0

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

19 Mar '12

Hi, No problem for the structure change. I think things are clearer that way - at least for all that is below the skloupe/ directory. As for the debate on whether skloupe (in French this sounds great btw) should be part of skimage, I think it should be the case, for the same arguments both of you used. I started looking at the code. Running edgedetector_demo.py, I have some issues with the slider window not updating the slider position. This also happens when I run example/widgets/slider_demo.py (I openned an issue on the github page). Stéfan you said I think from the start we assumed that we'd be building tools on Matplotlib and Qt. Is Qt the *required* backend, or do we stick to the matplotlib higher compatibility layer? Guillaume Le 18/03/2012 17:55, Stéfan van der Walt a écrit : > 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 >

2 1

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

18 Mar '12

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

1 0

Re: [OT] pass a C callback function to a cythom module via python
by Chris Colbert 18 Mar '12

18 Mar '12

You can see how we did this before with the opencv wrappers starting at line 117 of this file: https://github.com/scikits-image/scikits-image/blob/0.3.1/scikits/image/ope… On Sat, Mar 17, 2012 at 2:35 PM, Chris Colbert <sccolbert(a)gmail.com> wrote: > cytpes.addressof(...) > On Mar 17, 2012 12:52 AM, "Nadav Horesh" <nadavh.horesh(a)gmail.com> wrote: > >> It is good to know that there is still a hope. In my case I could make >> it if only a ctype object would expose the address of the underlying C >> object. >> >> Thank you, >> >> Nadav. >> >> בתאריך 16 במרץ 2012 18:09, מאת Stéfan van der Walt <stefan(a)sun.ac.za>: >> >>> Hi Nadav >>> >>> On Mar 15, 2012 10:54 PM, "Nadav Horesh" <nadavh.horesh(a)gmail.com> >>> wrote: >>> > >>> > I have the following: >>> > A library of C function which is compiled into a dll >>> > A cython module with a function that expects as a parameter a C >>> callback function. >>> > >>> > My problem is how to make a python script to pass directly the address >>> of a C function from the dll to the cython function. >>> >>> There's a Cython Enhancement Proposal for this, but it hasn't been >>> implemented: >>> >>> http://wiki.cython.org/enhancements/nativecall >>> >>> So, I don't think there's a cleaner way, unfortunately. It's great that >>> you found a workaround, though--many people have been struggling with this >>> issue. >>> >>> Stéfan >>> >>

1 0

Re: [OT] pass a C callback function to a cythom module via python
by Chris Colbert 18 Mar '12

18 Mar '12

cytpes.addressof(...) On Mar 17, 2012 12:52 AM, "Nadav Horesh" <nadavh.horesh(a)gmail.com> wrote: > It is good to know that there is still a hope. In my case I could make it > if only a ctype object would expose the address of the underlying C object. > > Thank you, > > Nadav. > > בתאריך 16 במרץ 2012 18:09, מאת Stéfan van der Walt <stefan(a)sun.ac.za>: > >> Hi Nadav >> >> On Mar 15, 2012 10:54 PM, "Nadav Horesh" <nadavh.horesh(a)gmail.com> wrote: >> > >> > I have the following: >> > A library of C function which is compiled into a dll >> > A cython module with a function that expects as a parameter a C >> callback function. >> > >> > My problem is how to make a python script to pass directly the address >> of a C function from the dll to the cython function. >> >> There's a Cython Enhancement Proposal for this, but it hasn't been >> implemented: >> >> http://wiki.cython.org/enhancements/nativecall >> >> So, I don't think there's a cleaner way, unfortunately. It's great that >> you found a workaround, though--many people have been struggling with this >> issue. >> >> Stéfan >> >

1 0

Re: [OT] pass a C callback function to a cythom module via python
by Nadav Horesh 17 Mar '12

17 Mar '12

It is good to know that there is still a hope. In my case I could make it if only a ctype object would expose the address of the underlying C object. Thank you, Nadav. בתאריך 16 במרץ 2012 18:09, מאת Stéfan van der Walt <stefan(a)sun.ac.za>: > Hi Nadav > > On Mar 15, 2012 10:54 PM, "Nadav Horesh" <nadavh.horesh(a)gmail.com> wrote: > > > > I have the following: > > A library of C function which is compiled into a dll > > A cython module with a function that expects as a parameter a C callback > function. > > > > My problem is how to make a python script to pass directly the address > of a C function from the dll to the cython function. > > There's a Cython Enhancement Proposal for this, but it hasn't been > implemented: > > http://wiki.cython.org/enhancements/nativecall > > So, I don't think there's a cleaner way, unfortunately. It's great that > you found a workaround, though--many people have been struggling with this > issue. > > Stéfan >

1 0

Re: Imshow and Linescan - first version
by Tony Yu 17 Mar '12

17 Mar '12

2012/3/16 Stéfan van der Walt <stefan(a)sun.ac.za> > On Fri, Mar 16, 2012 at 5:44 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > > And I'll move this into scikits-image org as soon as I know what name to > put > > it under. I'm not sure how I feel about `skloupe`---as always there's the > > pronunciation issue. `skoupe`... that's a stretch. `sciloupe`? Based on > > pypi, `loupe` is available (it turns out there's a django-loupe project), > > but then there's the branding issue. `loupepy` or `louppy` (pyloupe is > > taken)? Too cutesy, maybe. `pypeye` (python picture eyer---that's not a > > word). Some bikeshedding would actually be welcome here. > > Well, skimage.viewer is still available :) And there it will also get > installed everywhere skimage does; but you know all the pros and cons > of maintaining a separate package already. > > Stéfan > Oh, I guess I was artificially constraining myself to io.plugins. This sounds like a good idea to me. Are there any cons to this? 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. ------------------------ Possible Con ------------------------ Moving this to skimage.viewer kind of marginalizes the other plugins. 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'd like to come to some sort of consensus, if possible, so please---if you *any* opinions on this---let your voice be heard. -Tony

1 0