Mailman 3 May 2015 - scikit-image

Re: Ridge filter
by Stefan van der Walt 31 May '15

31 May '15

Hi Juan On 2015-05-31 01:02:32, Juan Nunez-Iglesias <jni.soma(a)gmail.com> wrote: > I found this StackOverflow Q&A through Twitter, and found the > explanation thorough and the implementation spot-on for the > problem being discussed. > > https://dsp.stackexchange.com/questions/1714/best-way-of-segmenting-veins-i… This looks very interesting! I had a look at the Wikipedia page: http://en.wikipedia.org/wiki/Ridge_detection The section about variable scale detection caught my eye. Have a look at: Tony Lindeberg, "Edge detection and ridge detection with automatic scale selection" Stéfan

1 0

Ridge filter
by Juan Nunez-Iglesias 31 May '15

31 May '15

Hi all, I found this StackOverflow Q&A through Twitter, and found the explanation thorough and the implementation spot-on for the problem being discussed. https://dsp.stackexchange.com/questions/1714/best-way-of-segmenting-veins-i… However I don't recall seeing any ridge filters in skimage! Do we have any and if not, do we want to add one? Seems straightforward to implement... Juan.

1 0

GSoC meeting notes
by Stefan van der Walt 29 May '15

29 May '15

29/05/2015, VB, SW, DP Daniil has been working on an implementation of Multiblock LBP. The code is currently linked to his blog post: http://warmspringwinds.github.io/gsoc/2015/05/29/google-summer-of-code-mult… He will update the code with a gallery example and do a PR. So far, his MLBP implementation uses the same API as OpenCV so that it can be directly plugged in to their face recognition infrastructure for testing. We are not tied to their API, but it is convenient to use for now. DP will continue working on the rest of the object identification pipeline this week, but may return to MLBP later to convert it to Cython (if profiling shows that it is necessary). Next week's deliverables: - First step of the pre-trained OpenCV algorithm on DP’s Multiblock-LBP Start on training module in Python Deliverables: - Results of plugging MLBP into OpenCV - Pull request with MLBP + gallery example - Some updates to MLBP code requested by VB and SW Other notes: - DP will investigate whether he can get funding to attend EuroSciPy

1 0

skimage.feature
by Zsuzsanna Püspöki 29 May '15

29 May '15

I am trying to use the blob_dog, blob_log, blob_doh from skimage.feature on some synthetic data. 1. Why do you obtain such different results for the LoG and DoG on your sample data: http://scikit-image.org/docs/dev/auto_examples/plot_blob.html <https://ewa.epfl.ch/owa/redir.aspx?C=9lxjKPMqzkiQgZDrW5vS3JnRU_KdbNII73D0ph…> ? I would expect something very similar. 2. I am running the following line on the attached image: blobs_log = blob_log(image_gray, overlap = 0, min_sigma=3, max_sigma=25, num_sigma=100, threshold=.1) I cannot arrive to detect precisely the size of the bigger spots (though the range I put is enough, hence the huge spot). The increase in num_sigma does not solve the issue. I would expect perfect results here. 3. Is there an easy way to visualize the N best detections?

3 3

Re: Repository for GSoC project
by Ralf Gommers 28 May '15

28 May '15

On Tue, May 26, 2015 at 6:00 PM, Jaime Fernández del Río < jaime.frio(a)gmail.com> wrote: > > 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/d/optout. > Thanks everyone for the feedback. After some more thinking, I have asked > Aman to start sending PRs directly against the current master of scipy. > > To differentiate new from old implementations, we'll probably just prepend > all file names with "ndi_" instead of the current "ni_". We will eventually > start removing old functionality that has been replaced, but for quite > sometime they will both coexist. This means that at some point in time, > e.g. calling `ndimage.filters.uniform_filter1d` may use the new Cython code > paths, while `ndimage.filters.minimum_filter1d` may still be using the old > C code paths. > > We will not merge anything, answering Juan's question, until we have tests > that validate that functionality. That does not mean that the functionality > will be available to end users just yet, e.g. we may merge an iterator > before any top level function that uses it. But if it does not have tests, > it does not get merged. > > If anyone has a very strong opinion against this approach, please speak up > now! > I like this. If you can keep old and new implementations side by side, it could even be a good idea to have an easy mechanism (clearly marked as temporary and only for testing) for users to switch between the two so they can test their own code with the new routines before those become the default. Ralf

1 0

[ndimage-gsoc2015] Weekly Summary 2015/05/25
by Jaime Fernández del Río 27 May '15

27 May '15

Hi all, Aman and I had our first weekly sync meeting yesterday. After each of these weekly calls, I have asked Aman to publish a short summary, just like this one, on progress to date and plans for the week. If you would like to participate on one of these weekly meetings, just let us know. *Design Choices* 1. Use the NumPy iterator (numpy.flatiter in Python or PyArrayIterObject in C) for all basic array iteration, rather than a custom implementation as ndimage currently does. *Plan for the week* 1. Learn to use the NumPy iterator in Cython properly. 2. Send a first pull request against ndimage that: 1. Provides supporting Cython code for basic array iteration. 2. Translates an ndimage function that only requires basic iteration, to Cython. This will probably be find_objects from the measurements submodule. 3. Document the progress in a blog post. *Deliverables from last week* 1. None yet. Best, Jaime -- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.

1 0

Re: Repository for GSoC project
by Vighnesh Birodkar 26 May '15

26 May '15

Hello Correct me if I am wrong here, but I remember a discussion where someone said ndimage module is divided into ~6 files ? How about we rewrite one file at a time ? Also, I'd like Jaime to look at this : https://github.com/scikit-image/scikit-image/pull/1510 Does this partly overlap with Aman's project ? Thanks Vighnesh On Tuesday, May 26, 2015 at 1:07:31 AM UTC+5:30, Jaime Fernández del Río wrote: > > Hi all, > > This year I am mentoring Aman for one of the GSoC projects we have > underway, "Rewriting ndimage in Cython." By its very nature it doesn't > conform very well to the "many small pull requests" model: from the point > of view of scipy, things are going to be broken up until almost the very > last commit. I am not sure what the best way to set up a collaborative code > development environment would be, and so am asking for the collective > wisdom to help guide us. > > Aman could simply create one ginormous pull request that will grow, and > grow, and not be merged until everything was ready. I don't like this idea > too much, as it is going to eventually be a confusing mess, and I think it > would also make it difficult for others than Aman (that would mostly be me) > to contribute code. > > I think we could also use a branch, either on my fork of scipy or on > Aman's, as the repository on which development would happen, and against > which PRs would be created, and once completed send a single PR to the main > scipy repo. This may work, but I don't like it much either. > > What probably makes more sense is to create a new branch **in the main > scipy repository**, and have PRs sent and merged against that branch, which > would eventually be merged with master upon completion. NumPy seems to have > a couple such experimental branches ('with_maskna' and > 'enable_separate_by_default'), although there is none in SciPy that I see. > This would also allow us to keep the project in a controlled environment, > even if by the end of the summer not every single bit of ndimage has been > ported. > > If this third path is really the preferred way of doing things, I could > probably set things up myself (Ralf gave me commit rights when I became a > mentor for this project), but I'd like to hear what others think, before > abusing my powers. > > Thanks! > > Jaime > > -- > (\__/) > ( O.o) > ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes > de dominación mundial. >

2 1

Re: Repository for GSoC project
by Juan Nunez-Iglesias 26 May '15

26 May '15

Hey Jaime, (et al) This still leaves open the question of *how* you will merge things in this magical branch...? What will constitute a sufficiently-complete PR against this branch that would not be so in master? (I do 100% agree that a ginormous PR is not the way to go, though!) Juan. On Tue, May 26, 2015 at 5:37 AM, Jaime Fernández del Río <jaime.frio(a)gmail.com> wrote: > Hi all, > This year I am mentoring Aman for one of the GSoC projects we have > underway, "Rewriting ndimage in Cython." By its very nature it doesn't > conform very well to the "many small pull requests" model: from the point > of view of scipy, things are going to be broken up until almost the very > last commit. I am not sure what the best way to set up a collaborative code > development environment would be, and so am asking for the collective > wisdom to help guide us. > Aman could simply create one ginormous pull request that will grow, and > grow, and not be merged until everything was ready. I don't like this idea > too much, as it is going to eventually be a confusing mess, and I think it > would also make it difficult for others than Aman (that would mostly be me) > to contribute code. > I think we could also use a branch, either on my fork of scipy or on > Aman's, as the repository on which development would happen, and against > which PRs would be created, and once completed send a single PR to the main > scipy repo. This may work, but I don't like it much either. > What probably makes more sense is to create a new branch **in the main > scipy repository**, and have PRs sent and merged against that branch, which > would eventually be merged with master upon completion. NumPy seems to have > a couple such experimental branches ('with_maskna' and > 'enable_separate_by_default'), although there is none in SciPy that I see. > This would also allow us to keep the project in a controlled environment, > even if by the end of the summer not every single bit of ndimage has been > ported. > If this third path is really the preferred way of doing things, I could > probably set things up myself (Ralf gave me commit rights when I became a > mentor for this project), but I'd like to hear what others think, before > abusing my powers. > Thanks! > Jaime > -- > (\__/) > ( O.o) > ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes > de dominación mundial. > -- > 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/d/optout.

1 0

Repository for GSoC project
by Jaime Fernández del Río 26 May '15

26 May '15

Hi all, This year I am mentoring Aman for one of the GSoC projects we have underway, "Rewriting ndimage in Cython." By its very nature it doesn't conform very well to the "many small pull requests" model: from the point of view of scipy, things are going to be broken up until almost the very last commit. I am not sure what the best way to set up a collaborative code development environment would be, and so am asking for the collective wisdom to help guide us. Aman could simply create one ginormous pull request that will grow, and grow, and not be merged until everything was ready. I don't like this idea too much, as it is going to eventually be a confusing mess, and I think it would also make it difficult for others than Aman (that would mostly be me) to contribute code. I think we could also use a branch, either on my fork of scipy or on Aman's, as the repository on which development would happen, and against which PRs would be created, and once completed send a single PR to the main scipy repo. This may work, but I don't like it much either. What probably makes more sense is to create a new branch **in the main scipy repository**, and have PRs sent and merged against that branch, which would eventually be merged with master upon completion. NumPy seems to have a couple such experimental branches ('with_maskna' and 'enable_separate_by_default'), although there is none in SciPy that I see. This would also allow us to keep the project in a controlled environment, even if by the end of the summer not every single bit of ndimage has been ported. If this third path is really the preferred way of doing things, I could probably set things up myself (Ralf gave me commit rights when I became a mentor for this project), but I'd like to hear what others think, before abusing my powers. Thanks! Jaime -- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.

1 0

GSoC 2015 - Accepted Students
by Vighnesh Birodkar 23 May '15

23 May '15

Hello Everyone Please join in in congratulating Aman and Daniil for being a part of GSoC 2015 for scikit-image. We look forward to an awesome summer. I'd like to request Aman and Daniil to join the GSoC specific mailing list[1]. This will mainly hold project specific discussions and updates. Anyone interested in the projects can also join and share their thoughts. As part of PSF, GSoC students are required to write a blog post every 2 weeks. It would be nice if we could have an introductory blog post about each project during the community bonding period. About Daniil's project specifically, I'd like to see an overview of his face detection algorithm. Specifically, I'd like to see a pictorial representation of MB-LBP and what exactly the Viola-Jones method has patented. Please keep in mind, that these blog posts will not only be read by the mentors, but the general public as well, so they should be easily understandable and also include all the necessary details. A well documented face detection implementation would help gain a lot of traction for the project. Similarly (although I'm not clear about the specifics) if the design and strategy of the cython implementation of ndimage is well documented and explained, it will help the future maintainers enormously. For all your blog posts, keep this scenario in mind : A user googles "Face Detection / Python image filters ", and sequentially clicks each link till she/he finds what he wants. I'd also request Stefan and Ralf to chip in with their thoughts and share if they agree/disagree with my ideas about these blog posts (I'm trying to get a hang of this mentoring thing). Also, Juan can share his thoughts, for he use to always push me (and rightfully so) towards writing better last year. As a reference, see the blog feeds from last year written by Rishabh and me. You can also dig into previous years' GSoC archives to find more. Thanks Vighnesh [1] : https://groups.google.com/forum/#!forum/skimage-gsoc [2] : https://sharkysoc14.wordpress.com/ [3] : https://vcansimplify.wordpress.com/tag/gsoc/

5 6