Mailman 3 April 2013 - scikit-image

Re: skimage and opencv
by Emmanuelle Gouillart 22 Sep '16

22 Sep '16

Hi FranÃ¯Â¿Â½ois, that's an excellent question, and not a troll :-). Opencv is a very powerful library, but it focuses primarily on computer vision (feature detection and extraction, classification, ...), as opposed to image processing in general (with other tasks such as denoising, segmentation, ...). The other big difference is that skimage builds on numpy ndarrays, and uses the full power of the numpy API (including of course the basic facilities for processing arrays as images that come with numpy), as well as some of scipy functions (you could have added scipy.ndimage to your list -- a few functions in skimage are wrappers around scipy.ndimage, that exist for the sake of completeneness). One important consequence is that algorithms working for 3-d or even n-d images can be easily implemented in 3-d/n-d in skimage, whereas opencv is restricted to 2-D images (as far as I know). Thanks to the use of numpy arrays, the API of skimage is also quite pleasant for a numpy user, more than the API of opencv. A related difference is that skimage is written in python and cython, whereas opencv is a C++ library. The two libraries attract a different crowd of developers, and a Python/Cython toolkit based on numpy arrays is easier to develop and maintain inside the Scientific Python ecosystem. I'm sure that other devs/users will have things to add to this discussion! Cheers, Emmanuelle On Thu, Dec 27, 2012 at 02:06:08PM -0800, FranÃ¯Â¿Â½ois wrote: > Hi users and devs, > It came to my knowledge that another python library (based on C++ and C > codes) for image processing exists too : opencv > I understand that numpy intregrates some basic features and we need some > advanced features but I have the feeling that skimages is redoundant with > opencv in some ways. > What's the position of skimage about that? (Don't read this question as a > troll but like a real question). > I mean that similar features exist in both. Would not be possible to > reuse/integrate opencv or merge? what's the reason for keeping them apart? > My observation is there is 4 libraries to manipulate images: > * PIL > * numpy > * skimages > * opencv > That's a lot. > Cheers,

3 2

Re: Contribution: circles and hough transform
by François 18 Jun '14

18 Jun '14

Hi, FYI, I plan to work on the detection of ellipses quite soon. Stefan indicated to me a reference which seems fairly simple to implement. Cheers, François.

3 3

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

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: Photomontage and Panoram Stitching
by Fedor Morozov 01 May '13

01 May '13

Hi. I have just made a pull request with wu's circle generation (one of the "Requested features"). It has nothing to do with the proposed project, but now I can build skimage and understand how to commit my changes. Circle images are attached to this post. вторник, 30 апреля 2013 г., 4:33:48 UTC+4 пользователь Stefan van der Walt написал: > > Hi Fedor > > On Tue, Apr 30, 2013 at 12:54 AM, Fedor Morozov <f-mo...(a)ya.ru<javascript:>> > wrote: > > My name is Fedor Morozov and I am a 2nd year computer science student in > > Moscow State University. > > Thanks for getting in touch! > > > What do you think about such project? I guess, it's rather ambitious, > yet it > > is diverse, interesting > > and will keep me from slacking. If some of the mentioned ideas get > separate > > projects, they can be > > adopted during summer. > > Nathan Faggian has done some work towards registration in pyimreg, and > what we discovered is that it is fairly hard to come up with a good > API. Perhaps you can have a look at that code and give us your > feedback? Registration would be a very useful feature to have in > skimage. > > Perhaps we could start with something simple: compare Harris features > with a robust matching algorithm such as RANSAC to find alignment with > a simple error measure (there is a PR for RANSAC by @ahojnnes). Once > aligned, perform Laplacian or other blending. If that works, one can > focus on adding other feature detectors, multi-resolution matching, > different error measures, optimization based approaches, etc. There > may be some code in https://github.com/stefanv/supreme that we can > re-use, or we can simply start from scratch. > > Eventually, I am also interested in non-rigid registration, > registration of voxel data, etc. > > Registration / blending is an immense topic that can very easily cover > an entire GSoC. > > Stéfan >

2 1

Re: GSoC: Photomontage and Panoram Stitching
by Fedor Morozov 30 Apr '13

30 Apr '13

Hi. Thank you for replying so soon. >> Perhaps we could start with something simple Sure, that is a good prototype, and, I think, it can be implemented in the following couple of days. Than I should choose some subset of possible improvements and turn it into a full-fledged project proposal with timeline and milestones to submit to Google. >> Eventually, I am also interested in non-rigid registration, registration of voxel data, etc. Judging by the adjastent thread, 3d algorithms are highly desirable for scikit-image, so they should be at least kept in mind when designing the project. As for the state of the art topics in general, it would be great to continue GSoC as a research project during the term. вторник, 30 апреля 2013 г., 4:33:48 UTC+4 пользователь Stefan van der Walt написал: > > Hi Fedor > > On Tue, Apr 30, 2013 at 12:54 AM, Fedor Morozov <f-mo...(a)ya.ru<javascript:>> > wrote: > > My name is Fedor Morozov and I am a 2nd year computer science student in > > Moscow State University. > > Thanks for getting in touch! > > > What do you think about such project? I guess, it's rather ambitious, > yet it > > is diverse, interesting > > and will keep me from slacking. If some of the mentioned ideas get > separate > > projects, they can be > > adopted during summer. > > Nathan Faggian has done some work towards registration in pyimreg, and > what we discovered is that it is fairly hard to come up with a good > API. Perhaps you can have a look at that code and give us your > feedback? Registration would be a very useful feature to have in > skimage. > > Perhaps we could start with something simple: compare Harris features > with a robust matching algorithm such as RANSAC to find alignment with > a simple error measure (there is a PR for RANSAC by @ahojnnes). Once > aligned, perform Laplacian or other blending. If that works, one can > focus on adding other feature detectors, multi-resolution matching, > different error measures, optimization based approaches, etc. There > may be some code in https://github.com/stefanv/supreme that we can > re-use, or we can simply start from scratch. > > Eventually, I am also interested in non-rigid registration, > registration of voxel data, etc. > > Registration / blending is an immense topic that can very easily cover > an entire GSoC. > > Stéfan >

1 0

Re: Making algorithms at least 3D, preferably nD
by Johannes Schönberger 30 Apr '13

30 Apr '13

> Volumetric image processing is definitely within scope of the scikit. > The reason that most of the implementations up to this point were 2-D > is simply a lack of time and hands. Luckily, that seems to be > changing, so we may very well have the luxury of tackling this problem > head-on. I also think that the majority of use cases is based on 2-D data (plus channel data) and volumentric data is a specific and rare use case. I'm also dealing with lots of nD data (3-D, 4-D,…), nevertheless they are mostly still 2-D data. E.g. - SAR stacks (NxMxD) - Covariance matrix images (NxMxDxD) - Hyperspectral remote sensing images (NxMxD) - Tomographic SAR (NxMxJxD) - etc. where D is often > 200.

2 2

Re: GSoC: Photomontage and Panoram Stitching
by Stéfan van der Walt 30 Apr '13

30 Apr '13

Hi Fedor On Tue, Apr 30, 2013 at 12:54 AM, Fedor Morozov <f-morozov(a)ya.ru> wrote: > My name is Fedor Morozov and I am a 2nd year computer science student in > Moscow State University. Thanks for getting in touch! > What do you think about such project? I guess, it's rather ambitious, yet it > is diverse, interesting > and will keep me from slacking. If some of the mentioned ideas get separate > projects, they can be > adopted during summer. Nathan Faggian has done some work towards registration in pyimreg, and what we discovered is that it is fairly hard to come up with a good API. Perhaps you can have a look at that code and give us your feedback? Registration would be a very useful feature to have in skimage. Perhaps we could start with something simple: compare Harris features with a robust matching algorithm such as RANSAC to find alignment with a simple error measure (there is a PR for RANSAC by @ahojnnes). Once aligned, perform Laplacian or other blending. If that works, one can focus on adding other feature detectors, multi-resolution matching, different error measures, optimization based approaches, etc. There may be some code in https://github.com/stefanv/supreme that we can re-use, or we can simply start from scratch. Eventually, I am also interested in non-rigid registration, registration of voxel data, etc. Registration / blending is an immense topic that can very easily cover an entire GSoC. Stéfan

1 0

Re: Making algorithms at least 3D, preferably nD
by Josh Warner 30 Apr '13

30 Apr '13

Sorry, it's been a busy couple of days! You are generally correct in your reservations of 2D+t vs. true 3D, and it comes back to the fact that we directly use naked NumPy arrays which carry no metadata. The discussion in PR #532 <https://github.com/scikit-image/scikit-image/pull/532> is relevant, for anyone that isn't seeing both. Handling these cases requires additional information, inferred from files or direct from the user in some fashion. As I noted in the PR discussion, this can be accomplished by wrapping the array into a container which also carries metadata, or via a kwarg indicating the behavior of the final channel. My vote is for the latter. On Sunday, April 28, 2013 10:05:40 PM UTC-5, Ankit Agrawal wrote: > > > > On Mon, Apr 29, 2013 at 7:49 AM, Juan Nunez-Iglesias <jni....(a)gmail.com<javascript:> > > wrote: > >> In Marianne's case, there is a 3D volumetric image *in addition to* a >> time axis. >> >> Furthermore, if the time resolution in t is sufficient, many nD >> algorithms can be used, along t as well (with suitable parameters e.g. >> sigma for gaussian gradient magnitude). For an example, see: >> >> Andres, B., Kroeger, T., Briggman, K. L., Denk, W., Korogod, N., Knott, >> G., Koethe, U., and Hamprecht, F. A. (2012). Globally optimal >> closed-surface segmentation for connectomics. ECCV, 778–791. >> >> where they use a 3D segmentation method to do tracking in 2D+t video. >> > > @Juan, this was an interesting read. I can feel why the 3D volumetric > algorithm fits 2D x t (video), because the task involved is segmentation > based tracking. However, I am still not fully convinced(would like to know > more such examples if any) and feel that most nD algorithms would work > differently on 2D x t and 3D. Thanks. > > Regards, > Ankit Agrawal, > Communication and Signal Processing, > IIT Bombay. >

1 0

Re: Making algorithms at least 3D, preferably nD
by Stéfan van der Walt 29 Apr '13

29 Apr '13

On Mon, Apr 29, 2013 at 7:04 AM, Juan Nunez-Iglesias <jni.soma(a)gmail.com> wrote: > But scikit-image is part of scikits, an "index of add-on toolkits that > complement SciPy, a library of scientific computing routines." (emphasis > mine). One of the goals is (/should be; @stefanv can weigh in) the analysis > of scientific images, many of which are 3D volumetric. And many such > algorithms can be applied as-is whether the data is 2D or 3D. This includes > filters, edge detectors, segmentation methods, convex hulls, and more. Volumetric image processing is definitely within scope of the scikit. The reason that most of the implementations up to this point were 2-D is simply a lack of time and hands. Luckily, that seems to be changing, so we may very well have the luxury of tackling this problem head-on. Stéfan

1 0