Mailman 3 May 2013 - scikit-image

Robert's Edge Detection. Part of [GsoC13]
by Umesh Sharma 06 May '13

06 May '13

Hi, It was suggested earlier that I submit a patch to get familiar with the codebase before applying for GsoC. So, I implemented Robert's Edge Detection algorithm (http://homepages.inf.ed.ac.uk/rbf/HIPR2/roberts.htm). I created an issue for this on github and I have the implementation in my git repo. Should I submit a pull request for this? Regards, Umesh

2 7

Re: imageio progress
by Stéfan van der Walt 05 May '13

05 May '13

On Sun, May 5, 2013 at 1:56 AM, Almar Klein <almar.klein(a)gmail.com> wrote: > I just moved imageio to github. Anyone who has an interest in collaborating > in this project, please let me know so I can give you write access. I can highly recommend working via pull requests. This has made such a big difference to the skimage development process, that I can't even imagine developing without it now. Stéfan

1 0

Re: imageio progress
by Almar Klein 04 May '13

04 May '13

I just moved imageio to github. Anyone who has an interest in collaborating in this project, please let me know so I can give you write access. - Almar On 27 April 2013 23:10, Almar Klein <almar.klein(a)gmail.com> wrote: > > Is there a way to add plugins by simply "dumping" plugin files into >> place? This was part of the thinking when we designed the skimage.io >> plugin infrastructure (so it would be easy for, e.g., Debian to add >> new formats by simply unpacking into the right location). >> >> I am not entirely happy with the complexity of the io module in >> skimage, and would love to hear ideas about how it can be simplified, >> perhaps integrating with imageio. >> > > The way in which this is currently implemented in imagio is that each > plugin module implements a Format class (with associated Reader and Writer > classes), and registers an instance of this Format class with the imagio > format manager: > > format = FormatDefinedInThisModule('dummy', 'An example format that > does nothing.') > imageio.formats.add_format(format) > > For a more complete example see plugins/example.py<https://bitbucket.org/almarklein/imageio/src/tip/imageio/plugins/example.py>. > In effect, plugins can be defines anywhere, also in 3d party packages. The > plugins/__init__.py simply imports has one line of code per plugin to > import it. > > You/we could extend it and make plugins/__init__.py search the whole > directory and import all found modules. I've done similar things in visvis, > but in retrospect I prefer explicitly importing the modules (also less > trouble with e.g. freezing). But perhaps the use case that you described > justifies such an approach. > > > Adding new formats is then a matter of dumping in a file containing read() >> and write() functions, and importing that in the __init__.py file. This >> results in very clean syntax: > > > Imagio currently does something similar. A plugin (or format as its called > in imageio) must implement three classes: Format to describe meta > information about the format (name, short description and docs), as well as > functionality to determine whether a given file(name) can be read/written > by the format or not. Reader and Writer are overloaded classes used to read > and write image data. They should implement a specific set of methods, but > may also implement additional methods in cases it makes sense to complement > the default interface. > > When the user tries to read an image (e.g. using imageio.imread()) the > format manager picks the first format that says it can read the data, and > uses an instance of its Reader class to do the reading. Alternatively > imagio.read() gives the user an instance of the Reader class for more > control. If the user wants to use a specific format he/she can use > imageio.imread(filename, format=X), where X can be the name of a format, > its extension, or a Format instance. > > > ... perhaps integrating with imageio. > > > I took imageio out of skimage because I think that reading/saving images > is useful to many people that do not necessarily need skimage. But I was > indeed hoping for some form of integration with skimage. > > Also, I'm hoping that imageio can be a place to place functionality for > reading specific formats (such as TIFF or .mhd (ITK)). An environment such > as github should make it fairly easy for multiple people to maintain their > own plugin in a collaborative repository. > > - Almar > > > > >

1 0

Re: GSoC 2013 Proposal : Implementation of STAR and Binary Feature Detectors and Descriptors
by Ankit Agrawal 02 May '13

02 May '13

Hi Stefan, On Thursday, May 2, 2013 2:15:11 PM UTC+5:30, Stefan van der Walt wrote: > > Looks like BRIEF, Star, ORB, FREAK then... > I will start making the corresponding changes in my proposal. Thank you. Regards, Ankit Agrawal, Communication and Signal Processing, IIT Bombay.

2 3

GSoC 2013 Final idea - Inpainting
by Chintak Sheth 02 May '13

02 May '13

Hi, After quite a bit of thought, I've decided to go ahead with Image inpainting (thanks Tony for suggesting this idea!) as my GSoC project. I'll keep Active contours for after GSoC if it yet remains undone. I've incorporated some changes as pointed out by Stefan and an additional reference by Tony (thanks both of you'll!). I've put up the proposal on google-melange site. Kindly let me know if there are any changes necessary or anything I'm missing out on. scikit-image: Image Inpainting for Restoration<http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/chintak/1> Thanks, Chintak

1 0

Gsoc 2013 Proposal
by Umesh Sharma 02 May '13

02 May '13

Name :- Umesh Kumar Sharma Email :- usharma01(a)gmail.com | umesh.sharma(a)cse.iitkgp.ernet.in Phone :- +91-8388055634 Location :- Kharagpur, India, GMT + 05:30 *Project Title* *:* Graph-cut/Normal-Cut Image Segmentation *Introduction :* Graph-Cut can be used to solve many problems of computer vision that can be formulated in terms of energy minimization. One very important problem of computer vision is object recognition, and it requires better image segementation techniques. There already exists implementation of Felzenswalb's fast graph based method, quickshift method and SLIC in scikit-image. The results of Felzenswalb's algorithm are quite well. If the image size becomes larger then many of the implemented graph algorithms become impractical. *Motivation :* Why python ? Python is my favourite programming language. I am working with python from my second year. So that is why i want to do something in python. Why scikit-image ? I am very interested in the field of image processing/Computer vision, and i wish to see a library equivalent to MATLAB fuctionality in python. I have gone through the source code of scikit-image. It is easy to understand and efficiently implemented. The library scikit-image is not complete yet so i can contribute more in this project and I have done some image processing projects in my past. I found the community of this project very helpful, during my PR submission. So that's why i am applying in scikit-image. *Project Goal:* During the Gsoc period, i was thinking of implementing "A Multilevel Banded Graph Cuts Method for Fast Image Segmentation" [Herve Lombaert, Yiyong Sun, Leo Grady, Chenyang Xu] as my Gsoc[2013] project. The results looks good as shown in paper. There is another paper "Star Shape Prior for Graph-Cut Image Segmentation", which if time permits, i would like to implement as well. *Implementation Details:* As described in paper this algorithm runs one multiple levels to decrease computation and memory requirement. First the graph cut is calcultate on an image of lower resolution and then solution is propagateed to next level only by computing the graph cut at that level in narrow band surrounding. The algorithm consist of three stages:- - Coarsening stage:- sequence of smaller images are constructed from the original image. - Initial Segmentation:- Min Cut is applied on the Coarsed images constructed in the stage first. - Uncoarsening stage :- A binary boundary image Jk is constructed to represent all the image point that are identified by the nodes in the cut Ck and project them onto a higher resolution boundary image Jk-1 at level k-1. also one more thing in this implementation we are using boykov and kolmogorov max-flow implementation because it is several time faster than slandered implementation. *Timeline:* Documentation and writing tests will be done along with the coding work so that it is not left for the last minute. Before June 17: To familiarize myself more with Scikit-image. Understand all smaller details of this algorithm. Discuss all my ideas with the mentor and community members. Discuss with my mentor for any changes in the plan. Phase 1: June 17 - July 19 (4 Weeks) : Implement Coarsening stage and start working on Initial Segmentation(boykov and kolmogorov max-flow)also do some documentation parallely. July 20 - August 2 (2 Week) : Testing and fixing bugs for Phase 1. Phase 2: August 3 - August 30 (4 Weeks) : Complete the segementation part and Implement final Uncoarsening stage of algorithm. August 31 - September 6 (2 Weeks) : Combine all parts of algorithm together and clean-up the code. September 6 - September 13 (1 Week) : Testing and fixing bugs for Phase 2. September 14 - September 27 (2 Week) : Finalizing all documentation and tests. Post Gsoc :- - Implement "Star Shape Prior for Graph-Cut Image Segmentation" paper for segmentation. - Implement remaining edge detector(mainly frei-chen). *About Me :-* I am currently 19 years old and i am pursuing my bachelors in computer science at Indian Institue of Technology Kharagpur(India). Apart from coding and Computer Science I like playing tennis, cricket. I love to spend some time with my friends. I am very enthusiastic in learning new things. My Prepration for this project - I am pretty clear about the implementation details of the paper. - I have quite understand the source code of scikit-image during my first PR, which is almost ready to merge. - I have good understanding of image processing. reference : https://github.com/umesh563/scikit-image/commits/master

1 1

Re: GSoC 2013 Proposal : Implementation of STAR and Binary Feature Detectors and Descriptors
by Ankit Agrawal 02 May '13

02 May '13

Hi Stefan and Tony, Thanks for your time and feedback. I have referred to the following links to compare feature detectors and descriptors. 1] Comparative Evaluation of Binary Features<http://www.cs.unc.edu/~jheinly/publications/eccv2012-heinly.pdf> 2] Comparison of Feature Detection Algorithms<http://computer-vision-talks.com/2011/01/comparison-of-the-opencvs-feature-…> 3] Feature Descriptor Comparison report<http://computer-vision-talks.com/2011/08/feature-descriptor-comparison-repo…> 4] Battle of Feature Descriptors<http://computer-vision-talks.com/2012/08/a-battle-of-three-descriptors-surf…> My conclusion about their comparative performance(time), quality(% of correct descriptor matches) and implementation time are as follows - Feature Detectors : (best)FAST > STAR :: Performance(time) (best)STAR > FAST :: Quality Implementation time :: 3 weeks each Binary Feature Descriptors : (best)BRIEF > ORB<http://www.vision.cs.chubu.ac.jp/CV-R/pdf/Rublee_iccv2011.pdf>> FREAK > BRISK :: Performance(time) (best)BRISK > FREAK >= ORB > BRIEF :: Quality(Averaging effects of Scaling, Rotation and Viewpoint change) BRIEF works best among the above four for Non-geometric transforms like change in brightness and exposure Implementation time :: Brisk - 5 weeks; FREAK and ORB - 2 weeks(provided BRIEF has been implemented, see NOTE), BRIEF - 2 weeks Note :: BRISK is dependent on FAST and ORB on BRIEF. Based on the above observations and implementation time details, please help me in choosing those that should be implemented during the course of summer. Thanks again for your time and please reply as soon it is possible for you because the gsoc-melange site is known to have gone down in the past on the last day. Thanks. Regards, Ankit Agrawal, Communication and Signal Processing, IIT Bombay.

2 1

Re: GSoC 2013 Proposal : Implementation of STAR and Binary Feature Detectors and Descriptors
by Tony Yu 02 May '13

02 May '13

On Wed, May 1, 2013 at 8:39 PM, Stéfan van der Walt <stefan(a)sun.ac.za>wrote: > Hi Ankit > > On Thu, May 2, 2013 at 3:16 AM, Ankit Agrawal <aaaagrawal(a)gmail.com> > wrote: > > @Stefan and Tony : Did you get a chance to go over my proposal, > especially > > the implementation timeline? I think that implementing FAST instead of > BRISK > > during the summer would make the timeline schedule better. I will > implement > > the BRISK after the Summer of Code. Your thoughts on this? > > The proposal looks good; I think we'll have a better idea of a > realistic timeline once we start coding, but that seems like a > reasonable estimate. > > I think it would be helpful if you could Google for some of the recent > papers that compared many of these binary features, to see which work > best, and then motivate which should be implemented first. > > Regards > Stéfan > > Hi Ankit, My free time has been pretty limited, so I can only give a quick response. The proposal looks good to me too. Here's a couple of feature detection comparisons that may be useful for choosing between implementations: http://computer-vision-talks.com/2011/01/comparison-of-the-opencvs-feature-… http://computer-vision-talks.com/2011/07/comparison-of-the-opencvs-feature-… Cheers, -Tony

1 0

Re: GSoC 2013 Proposal : Implementation of STAR and Binary Feature Detectors and Descriptors
by Ankit Agrawal 02 May '13

02 May '13

> It's also pretty easy to wrap his C code (as done here: > https://github.com/stefanv/supreme/tree/master/supreme/lib/fast) but > maybe implementing from scratch is best. > @Stefan and Tony : Did you get a chance to go over my proposal<https://github.com/scikit-image/scikit-image/wiki/GSoC-2013-Ankit-Agrawal-I…>, especially the implementation timeline? I think that implementing FAST instead of BRISK during the summer would make the timeline schedule better. I will implement the BRISK after the Summer of Code. Your thoughts on this? Regards, Ankit.

2 1

Re: GSoC 2013 Proposal : Implementation of STAR and Binary Feature Detectors and Descriptors
by Stéfan van der Walt 02 May '13

02 May '13

On Thu, May 2, 2013 at 3:04 AM, Tony Yu <tsyu80(a)gmail.com> wrote: > I'm not sure I'd call that NumPy code. I think the code is auto generated. > My guess is that it would be simpler to start fresh. It's also pretty easy to wrap his C code (as done here: https://github.com/stefanv/supreme/tree/master/supreme/lib/fast) but maybe implementing from scratch is best. Stéfan

1 0