Mailman 3 April 2013 - scikit-image

Re: Mean of Least Variance filter
by Stéfan van der Walt 24 Apr '13

24 Apr '13

On Wed, Apr 24, 2013 at 3:02 PM, Chintak Sheth <chintaksheth(a)gmail.com> wrote: > Yeah I already have a copy of the paper and read it as well. Although I wont > be able to download the paper you've provided. I am not a member of ACM, not > yet. Petkov has a copy on his website: http://www.cs.rug.nl/~petkov/publications/2011ivc-contour_survey.pdf Stéfan

1 0

Re: Describing superpixels
by Juan Nunez-Iglesias 24 Apr '13

24 Apr '13

On Wed, Apr 24, 2013 at 1:01 AM, Stéfan van der Walt <stefan(a)sun.ac.za>wrote: > You don't even need to. Have a look at section 3.1 of > > https://scholar.sun.ac.za/handle/10019.1/4883 Very clear! =) But yes, my brain hurts thinking about it in nD. The memory_efficient flag sounds like a good, generalisable compromise. It's probably best to get flood fill working before we get too far ahead of ourselves though. =)

1 0

Re: Mean of Least Variance filter
by Chintak Sheth 24 Apr '13

24 Apr '13

Hi Stefan, Yeah I already have a copy of the paper and read it as well. Although I wont be able to download the paper you've provided. I am not a member of ACM, not yet. Chintak On Apr 24, 2013 6:13 PM, "Stéfan van der Walt" <stefan(a)sun.ac.za> wrote: > Hi Chintak > > On Wed, Apr 24, 2013 at 2:34 PM, Chintak Sheth <chintaksheth(a)gmail.com> > wrote: > > So I was reading a paper on implementation of MLV filters which belongs > to a > > broder class of value-and-criterion filters. I read this paper "A > > morphology-based filter structure for edge-enhancing smoothing" > > This looks like an interesting approach (paper available for download > at: http://www.markschulze.net/docs/pdf/icip94.pdf), but I can't find > much more written on it, or a citation count--so it's hard to see what > its effect has been in practice. It'd be good to also look at > > http://dl.acm.org/citation.cfm?id=1897509 > > and compare with other algorithms. > > Stéfan > > -- > You received this message because you are subscribed to the Google Groups > "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to scikit-image+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > >

1 0

Re: Mean of Least Variance filter
by Stéfan van der Walt 24 Apr '13

24 Apr '13

Hi Chintak On Wed, Apr 24, 2013 at 2:34 PM, Chintak Sheth <chintaksheth(a)gmail.com> wrote: > So I was reading a paper on implementation of MLV filters which belongs to a > broder class of value-and-criterion filters. I read this paper "A > morphology-based filter structure for edge-enhancing smoothing" This looks like an interesting approach (paper available for download at: http://www.markschulze.net/docs/pdf/icip94.pdf), but I can't find much more written on it, or a citation count--so it's hard to see what its effect has been in practice. It'd be good to also look at http://dl.acm.org/citation.cfm?id=1897509 and compare with other algorithms. Stéfan

1 0

Mean of Least Variance filter
by Chintak Sheth 24 Apr '13

24 Apr '13

Hi, So I was reading a paper on implementation of MLV filters which belongs to a broder class of value-and-criterion filters. I read this paper "A morphology-based filter structure for edge-enhancing smoothing<http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=4136…> " It elaborates on the advantages over the median filter or morphological opening. It essentially exhibits edge-enhancing noise smoothing behaviour. Best of all it can be extended to 3D easily. I think it would be a good addition to the already present filter implementations on skimage. What do you guys think about this ? Chintak

1 0

Re: functions of ndimage
by Stéfan van der Walt 24 Apr '13

24 Apr '13

On Wed, Apr 24, 2013 at 8:54 AM, Nelle Varoquaux <nelle.varoquaux(a)gmail.com> wrote: > I don't agree with this point: if you take the case of scikit-learn, there > are some methods from scipy wrapped in scikit-learn, where the API changed > to match the scikits (all classifiers are classes, with a fit method, a > predict method, etc). The API of methods in skimage should match skimage's > API, not scipy's. I concur. If scipy has a slightly clunky API (which, for legacy and backward API compatibility reason, might be possible) we shouldn't be tied to it. Whenever you have a chance to put a new API in place instead of adopting an old one, you should make use of it to review that API. As such, I am not against adopting the existing API, but I want it to be reviewed carefully at hand of examples. Stéfan

1 0

GSoC applications are open
by Stéfan van der Walt 24 Apr '13

24 Apr '13

Hi prospective GSoC participants Please see the message by Vlad to the scikit-learn list below. Everything there pertains to scikit-image as well. Regards Stéfan ---------- Forwarded message ---------- From: Vlad Niculae Date: Wed, Apr 24, 2013 at 3:57 AM Dear students interested in applying for this year's GSoC with scikit-learn: As of a couple of days, applications are open. Scikit-learn is a suborganization of the PSF this year, like in previous years, so you will apply with PSF as an organzation, specifying that you will work on scikit-learn. The PSF were kind enough to provide instructions and a template for the proposals, so you are invited to peruse them. I am forwarding the specific e-mail here. I would like to stress that there is a strict requirement for having contributed some code to scikit-learn, and to blog weekly about your project. But most importantly, please discuss your proposal on the mailing list, the sooner the better. There have been discussions until now, maybe less active than they should have been, but I hope ideas and directions have crystallised a bit and we will soon see good discussion and competitive proposals. Yours, Vlad ---------- Forwarded message ---------- From: Terri Oda Date: Mon, Apr 22, 2013 at 7:22 AM Subject: [Soc2013-general] Student Application Template (Applications start April 22!) To: soc2013-general(a)python.org As hopefully all of you are aware, student applications to GSoC will be opening April 22 19:00 UTC (tomorrow to me) and closing May 3rd. I highly recommend that you all submit applications early -- you can modify them up until the final deadline. Google will not extend the deadline for any reason, including technical problems with the melange system (which have been known to happen at the last minute in the past), so the sooner you can get an application in the better! We have a template to help you prepare your application with the PSF: http://wiki.python.org/moin/SummerOfCode/ApplicationTemplate2013 Your sub-organizations may have additional requirements; ask them if there's any extra information they need from you. Please note a few things we ask for that are not always required by other orgs: * We do require students to blog about their projects, so you will need to set up a GSoC blog for weekly status updates and any other thoughts you wish to record about your project. * We do require students to submit a link to some sort of code sample, preferably a patch to the sub-org to which you are applying. Talk to your mentors if you're uncertain what would be appropriate. * Don't forget to put the name of your sub-organization (e.g. OpenHatch, MNE-Python) into the title of your application. If you're not sure about how to write a good proposal, ask your prospective mentors: they're the ones who will be deciding if they hire you or not, so they get the final word as to what a good proposal looks like for them. Terri

1 0

Re: functions of ndimage
by Juan Nunez-Iglesias 24 Apr '13

24 Apr '13

On Wed, Apr 24, 2013 at 4:54 PM, Nelle Varoquaux <nelle.varoquaux(a)gmail.com>wrote: > I don't agree with this point: if you take the case of scikit-learn, there > are some methods from scipy wrapped in scikit-learn, where the API changed > to match the scikits (all classifiers are classes, with a fit method, a > predict method, etc). The API of methods in skimage should match skimage's > API, not scipy's. > Hi Nelle! =) This is a fair point, but scikit-learn has a very stable, very well-defined interface for its estimators. There are two differences in the case of scikit-image: 1) most of the API is similar to the scipy ndimage API in the first place, implemented as functions that take an image and return an image of the same shape. 2) it's not as consistent overall (e.g. graph.MCP is an object, graph.shortest_path is a function). So, I would recommend aiming for new interfaces in scikit-image to be as close as possible to the scipy.ndimage interface. If a few kwargs are lost in translation, well, that's not a big deal. =)

1 0

Re: functions of ndimage
by Nelle Varoquaux 24 Apr '13

24 Apr '13

> > I'm in the middle on this: I would suggest importing the relevant ndimage > functions into the skimage namespace, but not touching the API, except > perhaps in extremely egregious cases. Just as the lack of a Gaussian filter > might confuse beginners, two divergent APIs will confuse advanced users. > I don't agree with this point: if you take the case of scikit-learn, there are some methods from scipy wrapped in scikit-learn, where the API changed to match the scikits (all classifiers are classes, with a fit method, a predict method, etc). The API of methods in skimage should match skimage's API, not scipy's. > > On Wed, Apr 24, 2013 at 11:41 AM, abid rahman <abidrahman2(a)gmail.com>wrote: > >> Hi, >> >> Isn't it a bad idea that for some functions we should go for scipy, for >> some other functions we go for skimage. Actually what I felt from >> user-point-of-view is to decrease maximum dependency in the project. So it >> is always better to bring all image processing stuffs in python under one >> library. Installation of one library should serve all our purpose. >> >> Abid K. >> opencvpython.blogspot.com >> >> >> On Wed, Apr 24, 2013 at 3:49 AM, Stéfan van der Walt <stefan(a)sun.ac.za>wrote: >> >>> On Tue, Apr 23, 2013 at 11:49 PM, Emmanuelle Gouillart >>> <emmanuelle.gouillart(a)nsup.org> wrote: >>> > I can see only a small number of scipy.ndimage functions that >>> are >>> > concerned, like gaussian_filter, distance_transform_edt, >>> > binary_fill_holes, but I now think that it'd be worth having a wrapper >>> > for these functions in skimage, for the sake of users not well aware of >>> > scipy.ndimage. We already depend on scipy anyway. >>> >>> I'd be happy to put wrappers to those functions in skimage, as long as >>> we do a thorough review of the API of each. That turns out to be one >>> of skimage's strongest benefits, and we shouldn't rely on ndimage to >>> have considered it very carefully. I think it would help if we had >>> some practical use cases of each of these, to guide us in the right >>> direction. >>> >>> But yes, I can see how this would confuse beginners... >>> >>> Stéfan >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "scikit-image" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to scikit-image+unsubscribe(a)googlegroups.com. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "scikit-image" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to scikit-image+unsubscribe(a)googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- > You received this message because you are subscribed to the Google Groups > "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to scikit-image+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > >

1 0

Re: functions of ndimage
by Chintak Sheth 24 Apr '13

24 Apr '13

Yeah, I think lets provide a unified experience to our users. You need scikit-image and this alone. On Wed, Apr 24, 2013 at 12:03 PM, Juan Nunez-Iglesias <jni.soma(a)gmail.com>wrote: > On Wed, Apr 24, 2013 at 4:16 PM, Josh Warner <silvertrumpet999(a)gmail.com>wrote: > >> (like the change of `scipy.ndimage.label` coming in 0.13) > > If this were to be implemented, would our policy then be to use relative >> imports for the wrapped versions of these functions internally, rather than >> importing from SciPy? >> > > I hadn't considered this but it makes a lot of sense, as it potentially > slowly decouples scikit-image from its scipy dependency. > > That would make it easier for future maintenance as well, I guess, change the one wrapper and rest all follows. Chintak

1 0