Mailman 3 April 2013 - scikit-image

Re: Graph Cut
by Johannes Schönberger 28 Apr '13

28 Apr '13

Hi and welcome, Your profile seems perfect to me and your ideas meet our expectations; however I think only one of your proposed ideas is not considered sufficient. But Stefan van der Walt can give you more information regarding this. Nevertheless, please note that you have to submit at least one PR to scikit-image. Have a look at this page for more information and other ideas: https://github.com/scikit-image/scikit-image/wiki/GSoC-2013 Johannes Schönberger Am 26.04.2013 um 17:49 schrieb Beatka Wójciak <bettyrfly(a)gmail.com>: > Hello, > I am finishing my 3rd year of Computer Science studies at University of Wrocław (Poland). During my studies I've taken multiple courses about image processing and this (as well as machine learning) is my main field of interest. Most of the projects regarding image processing I've written are in C/C++ but I'm fluent in Python as well (I've written several servers in Python and now I'm using it in my text mining course). I've also taken course about numerical analysis so I'm not afraid of maths. > > I found graph cut algorithm particularly interesting. I've found this paper: http://research.microsoft.com/pubs/67890/siggraph04-grabcut.pdf which seems to give good results and I'd like to implement it. > Please let me know if you find my idea interesting. > > In case it didn't meet your expectations my other idea was to implement algorithm found here: http://people.csail.mit.edu/sparis/publi/2011/cvpr_radon/Cho_11_Blur_Kernel… (deblurring from the ideas page). > > I'd be grateful for your comments and suggestions. > Beata Wojciak > > -- > 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. > >

3 2

GSoC 2013 : Idea Discussion
by Ankit Agrawal 28 Apr '13

28 Apr '13

Hi everyone, I am Ankit Agrawal, a 3rd year student enrolled in a 5 year Dual Degree Program(B.Tech + Masters) in Electrical Engineering at IIT Bombay(where SciPy India meet was held in Dec 2012). My Masters specialization is in Communication and Signal Processing. The relevant courses that I have taken in the past are Linear Algebra, Image Processing, Computer Vision and Machine Learning. Previously, I have used MATLAB, OpenCV and PointCloud Library for Image Processing and Computer Vision projects. Some of my projects include : 1) Mini Project *1*<http://home.iitb.ac.in/~aaaagrawal/projects/ip_project1.pdf>and *2 <http://home.iitb.ac.in/~aaaagrawal/projects/ip_project2.pdf>* based on paper 'Undersampled Radial MRI with Multiple Coils. Iterative Image Reconstruction Using a Total Variation Constraint<http://www-mrsrl.stanford.edu/studygroup/2/Files/Block_2007_Undersampled.pdf> ' 2) Parallel Tracking and Mapping<https://github.com/ankit-maverick/ComputerVisionProject>in 3D using Kinect(WIP) based on paper 'Parallel Tracking and mapping for Small AR Workspaces<http://www.robots.ox.ac.uk/~lav/Papers/klein_murray_ismar2007/klein_murray_…> ' 3) Machine Learning competitions on Kaggle<https://www.kaggle.com/users/43981/ankit-agrawal#profile-results>(Yes, I have fallen victim to overfitting here.) I just got finished with my end-terms yesterday and hence was a bit under the hood during the last week and slow in pushing commits. I appreciate the patience of the community members who have been reviewing my Pull Requests. I have resumed working on them<https://github.com/scikit-image/scikit-image/pulls/ankit-maverick> . I want to discuss some of the ideas more extensively for building a strong GSoC proposal as the ideas page currently does not list much description of them. Idea # 1: In the feature detection idea, binary features like BRIEF<http://cvlabwww.epfl.ch/~lepetit/papers/calonder_eccv10.pdf>, FREAK <http://infoscience.epfl.ch/record/175537/files/2069.pdf> and BRISK<http://www.robots.ox.ac.uk/~vgg/rg/papers/brisk.pdf>; STAR corners, SURF<http://www.sciencedirect.com/science/article/pii/S1077314207001555>and SIFT <http://www.cs.ubc.ca/~lowe/papers/ijcv04.pdf> features need to be implemented(Currently, only feature readers are available for SIFT and SURF) . Over the span of 12 weeks, I think 4 of these can implemented giving 3 weeks of time to each. If this sounds a bit ambitious, 3 features can be completed with 4 for weeks for each one. I think a framework for handling features and descriptors like the opencv 2D features framework<http://docs.opencv.org/modules/features2d/doc/features2d.html>might be something that skimage should have in future considering the long-term. Idea # 2: I think that the Blind Deconvolution<http://people.csail.mit.edu/sparis/publi/2011/cvpr_radon/Cho_11_Blur_Kernel…>and Face Detection(@Stefan : Can you please confirm whether you meant Detection instead of Recognition in the idea listed on the idea's page<https://github.com/scikit-image/scikit-image/wiki/GSoC-2013>?) both can be completed comfortably in 12 weeks by me as I have worked on a project involving Radon transform(MiniProject 1<http://home.iitb.ac.in/~aaaagrawal/projects/ip_project1.pdf>and 2 <http://home.iitb.ac.in/~aaaagrawal/projects/ip_project2.pdf>) and have also done a course in Machine Learning. Currently, I don't know of any Non-patent-encumbered face detection algorithm in particular, but I am confident that there are effective methods other than Viola-Jones. A good introduction to Face detection and Recognition is in these slides<http://vision.stanford.edu/teaching/cs231a_autumn1112/lecture/lecture2_face…>by Stanford's Prof. Fei Fei Li. Beatka has shown interest in Graph-Cut as well as Blind Convolution, but I think it would be better if someone tackles all the segmentation algorithms together since the segmentation part of skimage needs many additions. There was a lot of interest for the segmentation idea in the beginning, but if no one is taking it, I would be happy to have that idea as my proposal. Idea # 3: What is needed to be implemented in Video Manipulation Framework idea? My guess is that interfacing the current Video streaming functionality(input either from webcam or files) with the currently implemented algorithms which would also lead to development of Computer Vision algorithms in the future in skimage. Can you please elaborate more on this idea, if possible in a modular way? I request all the community members to comment their views on these ideas soon as I plan to have my proposal ready by 30th. Thank you. Regards, Ankit Agrawal, Communication and Signal Processing, IIT Bombay.

2 1

segmentation fault when building doc
by Emmanuelle Gouillart 28 Apr '13

28 Apr '13

Hi all, when I try do build the doc with sphinx ("make html", on the master branch of scikit-image), I get a segmentation fault. Here is what gdb says: ************************** aleph ~/travail/projects/scikit-image/doc $ gdb python [master] [16:04] GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://bugs.launchpad.net/gdb-linaro/>... Reading symbols from /usr/bin/python...(no debugging symbols found)...done. (gdb) run /usr/bin/sphinx-build -b html -d build/doctrees source build/html Starting program: /usr/bin/python /usr/bin/sphinx-build -b html -d build/doctrees source build/html [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Running Sphinx v1.1.3 /usr/lib/pymodules/python2.7/matplotlib/__init__.py:923: UserWarning: This call to matplotlib.use() has no effect because the the backend has already been chosen; matplotlib.use() must be called *before* pylab, matplotlib.pyplot, or matplotlib.backends is imported for the first time. if warn: warnings.warn(_use_error_msg) loading pickled environment... not yet created loading intersphinx inventory from http://scikit-learn.org/stable/objects.inv... loading intersphinx inventory from http://docs.scipy.org/doc/scipy/reference/objects.inv... loading intersphinx inventory from http://docs.scipy.org/doc/numpy/objects.inv... loading intersphinx inventory from http://docs.python.org/2.7/objects.inv... Program received signal SIGSEGV, Segmentation fault. 0x00007fffdeac2643 in __pyx_pf_7skimage_9transform_16_hough_transform_hough_circle (__pyx_v_img=<optimized out>, __pyx_v_radius=0x48d6050, __pyx_v_normalize=1 '\001', __pyx_v_full_output=<optimized out>, __pyx_self=<optimized out>) at skimage/transform/_hough_transform.c:2240 warning: Source file is more recent than executable. 224 *__Pyx_BufPtrStrided3d(__pyx_t_5numpy_double_t *, __pyx_pybuffernd_acc.rcbuffer->pybuffer.buf, __pyx_t_26, __pyx_pybuffernd_acc.diminfo[0].strides, __pyx_t_27, __pyx_pybuffernd_acc.diminfo[1].strides, __pyx_t_28, __pyx_pybuffernd_acc.diminfo[2].strides) += __pyx_v_0 ***************************************** I checked that I obtain the same segfault on a fresh clone. Any idea of what's going on? Am I the only one having trouble building the doc? Cheers, Emmanuelle

3 3

Re: Making algorithms at least 3D, preferably nD
by Marianne Corvellec 28 Apr '13

28 Apr '13

Hello, A little off topic, sorry... On Friday, April 26, 2013 9:45:38 PM UTC+2, Stefan van der Walt wrote: > > > Should I go with British or US spelling for "neighbo(u)r"? =) > > I speak English, but I realise (with an S) that I am in the minority :) As > such, I think it is safer to use the US spelling. > I may agree with the fact that we should go with US spelling. Maybe just because it's shorter and you want short words in code. :) I'm not so sure you really are a minority spelling "realise". I am Canadian so I spell "realize" but "neighbour". Juan, you shouldn't say that spelling "neighbour" is British, it's just *non-US* ;) Alright, no troll intended. > Thanks for volunteering to work on this important part of the package. I > think once that is in place we'd have a very compelling story for a skimage > paper! > Exciting! :) Marianne

6 5

Re: imageio progress
by Almar Klein 27 Apr '13

27 Apr '13

> 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

GSoC 2013: Contour detection or feature detection ?
by Chintak Sheth 27 Apr '13

27 Apr '13

Hi, I am writing this mail since I am a little confused as to which project would be the most advantageous to our community. After talking to Tony, I have been able to short-list 2 projects, one regarding contour detection using snakes or feature detection using SIFT. Kindly take a look at the ideas described in detail below. *About me:* I am Chintak Sheth a 3rd year UG pursuing B.E. (Hons.) in Electrical and Electronics engineering at BITS Pilani Goa campus. I have been working in Image processing for about 8-9 months. I took it as an elective course just out of curiosity, and am now really passionate to work in it, I have recently got a paper published in IEEE Xplore DL. "Study of Dissociated Dipoles for Content Based Image Retrieval Using Stamp Recognition Systems<http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=6498274&cont…>" At the time we had worked on MATLAB, though I regret not having got exposed to skimage then. This is my first exposure with open source development. But in the last couple of weeks, I have contributed to the community by way of documentation for Morphological functions (with a lot of help from Tony: https://github.com/scikit-image/scikit-image/pull/528) which was recently merged and also by trying to implement a convex_hull_object function ( https://github.com/scikit-image/scikit-image/pull/522). *Idea 1:* I was fascinated about value-and-criterion class of nonlinear filters after reading "A morphology-based filter structure for edge-enhancing smoothing<http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=4136…>". It describes the implementation of Mean of Least Variance filters. What is interesting is the edge preserving smoothing behaviour and also the ease of extending it to 3D or n-D. Stefan further suggested going through this paper (Edge and Line Oriented Contour Detectors : State of the Art<http://www.cs.rug.nl/~petkov/publications/2011ivc-contour_survey.pdf>) which deals with a higher domain of contour detection and also presents on the various stages involved in this. As it turns out value-and-criterion filters fall into the preprocessing stage for contour detection and are mainly used for removing noise and textures while at the same time preserving edges. For the detection part, I think Active contours (or snakes) offers some pretty serious advantages as opposed to local detectors. Specifically, Snakes: Active contour models<http://morse.cs.byu.edu/750/papers/kass-witkin-terzopoulos-snakes.pdf> describes the basic algorithm and has been cited about 14660 times. I think snakes in combination with a preprocessing filter would be a pretty good addition to skimage. *Idea 2:* A feature detector like SIFT. A lot of literature is available online and also should be pretty good to have in skimage. I'd love to know what are your thoughts on what could be more advantageous to our community. Thanks, Chintak

1 0

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

26 Apr '13

On Apr 26, 2013 6:13 PM, "Juan Nunez-Iglesias" <jni.soma(a)gmail.com> wrote: > > On Fri, Apr 26, 2013 at 9:31 PM, Stéfan van der Walt <stefan(a)sun.ac.za> wrote: >> >> Perhaps we should implement >> such a spatial access library in _shared, and then write a short guide >> in the documentation on how to use it? > > > I like it! A very manageable first step. Busy this weekend but it's on my to-do for next week. > > Should I go with British or US spelling for "neighbo(u)r"? =) I speak English, but I realise (with an S) that I am in the minority :) As such, I think it is safer to use the US spelling. Thanks for volunteering to work on this important part of the package. I think once that is in place we'd have a very compelling story for a skimage paper! Stéfan

1 0

Re: Making algorithms at least 3D, preferably nD
by Juan Nunez-Iglesias 26 Apr '13

26 Apr '13

On Fri, Apr 26, 2013 at 9:31 PM, Stéfan van der Walt <stefan(a)sun.ac.za>wrote: > Perhaps we should implement > such a spatial access library in _shared, and then write a short guide > in the documentation on how to use it? > I like it! A very manageable first step. Busy this weekend but it's on my to-do for next week. Should I go with British or US spelling for "neighbo(u)r"? =)

1 0

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

26 Apr '13

On Fri, Apr 26, 2013 at 5:23 PM, Juan Nunez-Iglesias <jni.soma(a)gmail.com> wrote: > On Fri, Apr 26, 2013 at 2:36 PM, Stéfan van der Walt <stefan(a)sun.ac.za> > wrote: > At any rate, I've slightly softened my stance. The reason is that all these > neighbourhood models implicitly assume that the data are isotropic, ie same > resolution along each dimension. This is possible, even probable, until 3 > dimensions, and essentially impossible in 4D or higher. So while it's cute > and nice to make it nD, realistically, 3D is good enough for most purposes. > And you can't argue that it's much harder to do 3D than 2D. =) Sorry for throwing you under the bus, Juan :) But I think the tools you mention can be very useful, and tie in nicely also with the idea of graph-based operators for superpixels. Perhaps we should implement such a spatial access library in _shared, and then write a short guide in the documentation on how to use it? Stéfan

1 0

Re: Making algorithms at least 3D, preferably nD
by Juan Nunez-Iglesias 26 Apr '13

26 Apr '13

On Fri, Apr 26, 2013 at 2:36 PM, Stéfan van der Walt <stefan(a)sun.ac.za>wrote: > Juan's the right guy for the job! Oh *great*. #bus #thrownunder =P > I read his original email again, > and while I agree that supporting N-d is important, it still strikes > me as a lot harder to implement something in N-d vs 2-D (it's much > more than just grabbing the "juicy center", etc.). It depends a lot on the algorithm. For many (all the ones I've used, anyway), the algorithm works on voxels (is it hypervoxels in nD? =) and their neighbours, so you just need to abstract away the "neighbour" concept. See my (pure python, slow as molasses) watershed implementation here <https://github.com/janelia-flyem/gala/blob/master/gala/morpho.py#L168>, which depends on the function `get_neighbor_idxs` here<https://github.com/janelia-flyem/gala/blob/master/gala/morpho.py#L460>. (Full disclosure: it's so slow that when the parameters are right, it falls back on skimage. ;) I don't think any of these functions are in principle difficult to implement in Cython, so long as you pass the raveled array+shape, rather than the full n-dimensional array. It just wasn't a priority after you guys came out with 3D watershed. =) SLIC is another easy one to make nD: rather than 2D+RGB, it could be nD+arbitrary channels. The algorithm is exactly the same. (Sorry I've been slow on that one. Again: would have been easier to be nD from the start, rather than converting Andy's implementation which is a headache simply because it assumes 2D+3 channels in so many places.) At any rate, I've slightly softened my stance. The reason is that all these neighbourhood models implicitly assume that the data are isotropic, ie same resolution along each dimension. This is possible, even probable, until 3 dimensions, and essentially impossible in 4D or higher. So while it's cute and nice to make it nD, realistically, 3D is good enough for most purposes. And you can't argue that it's much harder to do 3D than 2D. =) Regarding tutorials, what exactly are people looking for? I incidentally have zero experience with: 1. writing tutorials, 2. mayavi, or 3. cross-correlation methods. However, I'm very much interested in learning about 1 and 2, so I'm happy to take this on with a bit of guidance! (But I have no helpful suggestions for Marianne's specific problem... Sorry!)

1 0