Mailman 3 April 2013 - scikit-image

Re: Making algorithms at least 3D, preferably nD
by Ankit Agrawal April 29, 2013

April 29, 2013

Hi Juan, I think this is all a bit off-topic anyway. The whole idea of making the > algorithms nD is to apply them to 3D volumetric data, not 2D+t. That they > *sometimes* apply to 2D+t is merely a happy accident. > > Thanks again. I somehow thought that the nD algorithms that are going to be implemented in scikit should also generalize for 2D x t and hence my previous concern. Dealing just with volumetric data makes the whole picture clear. > 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. > Yes, all the functions in scipy.ndimage can be genralized for volumetric 3D.

1 0

Re: Making algorithms at least 3D, preferably nD
by Juan Nunez-Iglesias April 29, 2013

April 29, 2013

Hi again Ankit, I think this is all a bit off-topic anyway. The whole idea of making the algorithms nD is to apply them to 3D volumetric data, not 2D+t. That they * sometimes* apply to 2D+t is merely a happy accident. 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. On Mon, Apr 29, 2013 at 1:05 PM, Ankit Agrawal <aaaagrawal(a)gmail.com> wrote: > > > On Mon, Apr 29, 2013 at 7:49 AM, Juan Nunez-Iglesias <jni.soma(a)gmail.com>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. > > -- > 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: GSoC 2013 : Idea Discussion
by Ankit Agrawal April 29, 2013

April 29, 2013

Hi Stefan, > In the feature detection idea, binary features like BRIEF, FREAK and > BRISK; > > STAR corners, SURF and SIFT features need to be implemented(Currently, > only > > feature readers are available for SIFT and SURF) . > > We cannot have SIFT or SURF in skimage because of patent constraints, > but we are certainly interested in STAR (consensus). The binary > features would also be a very good contribution. > > I was unaware of that. Thanks for pointing out. OpenCV has a separate section for such patented/non-free algorithms<http://docs.opencv.org/modules/nonfree/doc/nonfree.html> . > > I think a framework for handling features and descriptors like the > opencv 2D > > features framework might be something that skimage should have in future > > considering the long-term. > > Could you describe what such a framework would look like and do? > I haven't looked at OpenCV's source code, but their features framework<http://docs.opencv.org/modules/features2d/doc/features2d.html>is organized into feature detectors, feature descriptor extractors, feature descriptor matchers, which to me seems very clean and elegant, atleast in terms of the API. > > I think that the Blind Deconvolution and Face Detection(@Stefan : Can > you > > please confirm whether you meant Detection instead of Recognition in the > > I meant detection, and specifically referred to an alternative way of > implemented Viola-Jones that would avoid patent restrictions. > Alternative algorithms would also work, but I am not very familiar > with the literature. > I will research more into these alternative methods. > > 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. > > All prospective candidates are more than welcome to share their > ideas/interests here, so that there is limited overlap. I agree that this would be better. > > 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. > > I think I mentioned this in another mail, but it would encompass > efficient reading, writing, seeking, and real-time display. Long, > long ago I wrote this for Octave: > > http://octave.sourceforge.net/video/overview.html > > I think we can definitely trump that by now in terms of functionality. Umm...I am not sure I got the exact meaning of what you meant here, can you please elaborate a bit? Thanks. Regards, Ankit Agrawal, Communication and Signal Processing, IIT Bombay.

2 1

Re: Making algorithms at least 3D, preferably nD
by Ankit Agrawal April 29, 2013

April 29, 2013

On Mon, Apr 29, 2013 at 7:49 AM, Juan Nunez-Iglesias <jni.soma(a)gmail.com>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 Juan Nunez-Iglesias April 29, 2013

April 29, 2013

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. On Mon, Apr 29, 2013 at 12:04 PM, Ankit Agrawal <aaaagrawal(a)gmail.com>wrote: > > > On Mon, Apr 29, 2013 at 7:13 AM, Juan Nunez-Iglesias <jni.soma(a)gmail.com>wrote: > >> On Mon, Apr 29, 2013 at 11:06 AM, Ankit Agrawal <aaaagrawal(a)gmail.com>wrote: >> >>> @Josh and Juan, >>> Thanks for your explanation. >>> >>> I may be wrong but I feel that there would be a limited number of >>> algorithms that are nD aware but will scale down nicely if provided with a >>> 2D image. For instance, if we have 3D data of the type (m x n x p), many >>> functions and algorithms involving spatial components for eg: gradient >>> based edge detectors won't be applicable since our 3rd dimension represents >>> a series of images, we can't have something like a gradient in that >>> dimension. >>> >> >> @Ankit, actually, edge detectors generalise quite nicely to nD, e.g.: >> >> http://docs.scipy.org/doc/scipy/reference/generated/scipy.ndimage.filters.g… >> > > Yes, edge detectors, filters and interpolating function generalize to nD > quite easily, but my point was something else which slipped through because > of my ambiguous explanation. The edge detectors will be good if the the > data is volumetric in nature. On the contrary, if the data is 3D(series of > images) where the dimension is not the z co-ordinate but a time instance, > like in Marianne's case, gradient along the first two dimensions would be > w.r.t space, while gradient along the third dimension would be w.r.t > time(like the Optical Flow algorithm<http://people.csail.mit.edu/bkph/papers/Optical_Flow_OPT.pdf>in Computer Vision), which according to me, are fundamentally different in > true sense. > > >> Many other examples of nD algorithms: >> http://docs.scipy.org/doc/scipy/reference/ndimage.html >> >> Instead, if our data is 3D volumetric image, a great percentage of >>> Computer Vision algorithms won't be of any use since they rely on making >>> sense 3D world from 2D data. I would love to hear any comments on this >>> point. Thanks. >>> >> >> Photographs are rarely 3D, but various kinds of microscopy produce truly >> 3D images, not a sequence of unrelated images. If you give specific >> algorithms, we might be better able to point out how to generalise to 3D, >> but the gist is that most algorithms *do* generalise. It is the >> implementations that are 2D, not the algorithms. >> >> > Regards, > Ankit Agrawal, > Communication and Signal Processing, > IIT Bombay. > > -- > 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: Making algorithms at least 3D, preferably nD
by Ankit Agrawal April 29, 2013

April 29, 2013

On Mon, Apr 29, 2013 at 7:13 AM, Juan Nunez-Iglesias <jni.soma(a)gmail.com>wrote: > On Mon, Apr 29, 2013 at 11:06 AM, Ankit Agrawal <aaaagrawal(a)gmail.com>wrote: > >> @Josh and Juan, >> Thanks for your explanation. >> >> I may be wrong but I feel that there would be a limited number of >> algorithms that are nD aware but will scale down nicely if provided with a >> 2D image. For instance, if we have 3D data of the type (m x n x p), many >> functions and algorithms involving spatial components for eg: gradient >> based edge detectors won't be applicable since our 3rd dimension represents >> a series of images, we can't have something like a gradient in that >> dimension. >> > > @Ankit, actually, edge detectors generalise quite nicely to nD, e.g.: > > http://docs.scipy.org/doc/scipy/reference/generated/scipy.ndimage.filters.g… > Yes, edge detectors, filters and interpolating function generalize to nD quite easily, but my point was something else which slipped through because of my ambiguous explanation. The edge detectors will be good if the the data is volumetric in nature. On the contrary, if the data is 3D(series of images) where the dimension is not the z co-ordinate but a time instance, like in Marianne's case, gradient along the first two dimensions would be w.r.t space, while gradient along the third dimension would be w.r.t time(like the Optical Flow algorithm<http://people.csail.mit.edu/bkph/papers/Optical_Flow_OPT.pdf>in Computer Vision), which according to me, are fundamentally different in true sense. > Many other examples of nD algorithms: > http://docs.scipy.org/doc/scipy/reference/ndimage.html > > Instead, if our data is 3D volumetric image, a great percentage of >> Computer Vision algorithms won't be of any use since they rely on making >> sense 3D world from 2D data. I would love to hear any comments on this >> point. Thanks. >> > > Photographs are rarely 3D, but various kinds of microscopy produce truly > 3D images, not a sequence of unrelated images. If you give specific > algorithms, we might be better able to point out how to generalise to 3D, > but the gist is that most algorithms *do* generalise. It is the > implementations that are 2D, not the algorithms. > > Regards, Ankit Agrawal, Communication and Signal Processing, IIT Bombay.

1 0

Re: Making algorithms at least 3D, preferably nD
by Juan Nunez-Iglesias April 29, 2013

April 29, 2013

On Mon, Apr 29, 2013 at 11:06 AM, Ankit Agrawal <aaaagrawal(a)gmail.com>wrote: > @Josh and Juan, > Thanks for your explanation. > > I may be wrong but I feel that there would be a limited number of > algorithms that are nD aware but will scale down nicely if provided with a > 2D image. For instance, if we have 3D data of the type (m x n x p), many > functions and algorithms involving spatial components for eg: gradient > based edge detectors won't be applicable since our 3rd dimension represents > a series of images, we can't have something like a gradient in that > dimension. > @Ankit, actually, edge detectors generalise quite nicely to nD, e.g.: http://docs.scipy.org/doc/scipy/reference/generated/scipy.ndimage.filters.g… Many other examples of nD algorithms: http://docs.scipy.org/doc/scipy/reference/ndimage.html Instead, if our data is 3D volumetric image, a great percentage of > Computer Vision algorithms won't be of any use since they rely on making > sense 3D world from 2D data. I would love to hear any comments on this > point. Thanks. > Photographs are rarely 3D, but various kinds of microscopy produce truly 3D images, not a sequence of unrelated images. If you give specific algorithms, we might be better able to point out how to generalise to 3D, but the gist is that most algorithms *do* generalise. It is the implementations that are 2D, not the algorithms.

1 0

Re: Making algorithms at least 3D, preferably nD
by Ankit Agrawal April 29, 2013

April 29, 2013

@Josh and Juan, Thanks for your explanation. On Sat, Apr 27, 2013 at 11:58 AM, Ankit Agrawal <aaaagrawal(a)gmail.com>wrote: > >> Hi all, >> >> I guess I need some clarification what nD images exactly mean. For >> 3D, these are the following ways I can think of it -- >> 1. RGB image (n x m x 3) : Total m*n pixels >> 2. Series of grey-scale images (m x n x p): Total p images each with m*n >> pixels >> 3. A grey-scale(m x n x 2) or an RGB image(m x n x 4) with depth value at >> each pixel like a Pointcloud(http://pointclouds.org/)? >> > > As others have pointed out, I think (1) and (3) are 2D+c, and (2) is 3D. > You can also have (m x n x p x 3), or even (t x m x n x p x c) for > arbitrary t and c. > > In general, when I said 3D I meant (m x n x p) and (m x n x p x 3), and > when I said nD I meant (t x m x n x p x c). But, importantly, what I'm > looking for is functions that are nD aware but will degrade nicely if > provided with e.g. a 2D image. > I may be wrong but I feel that there would be a limited number of algorithms that are nD aware but will scale down nicely if provided with a 2D image. For instance, if we have 3D data of the type (m x n x p), many functions and algorithms involving spatial components for eg: gradient based edge detectors won't be applicable since our 3rd dimension represents a series of images, we can't have something like a gradient in that dimension. Instead, if our data is 3D volumetric image, a great percentage of Computer Vision algorithms won't be of any use since they rely on making sense 3D world from 2D data. I would love to hear any comments on this point. Thanks. Regards, Ankit Agrawal, Communication and Signal Processing, IIT Bombay.

1 0

Re: Making algorithms at least 3D, preferably nD
by Marianne Corvellec April 29, 2013

April 29, 2013

@Ankit On Sunday, April 28, 2013 5:58:26 PM UTC+2, Juan Nunez-Iglesias wrote: > > On Sat, Apr 27, 2013 at 11:58 AM, Ankit Agrawal <aaaag...(a)gmail.com<javascript:> > > wrote: >> >> @Marianne >> Can you point out to the category that you meant with your images of the >> dimensions (512, 1536, 21)? >> > > I'm not Marianne but I would bet a nonzero sum that those are (m x n x p) > images. =) > Yes, exactly! Just confirming what Juan and others have made clear. It goes like: In [1]: import skimage.io as io In [2]: coll = io.ImageCollection('Movie2/movie2_t005_z*_c001.png') In [3]: len(coll) Out[3]: 21 In [4]: coll[0].shape Out[4]: (512, 1536) But this collection of image files is for one given time, there are many times (making a movie) so I guess I'm dealing with nD as well.

2 1

Re: GSoC 2013: Contour detection or feature detection ?
by Stéfan van der Walt April 28, 2013

April 28, 2013

Hi Chintak On Sat, Apr 27, 2013 at 8:13 AM, Chintak Sheth <chintaksheth(a)gmail.com> wrote: > opposed to local detectors. Specifically, Snakes: Active contour models > describes the basic algorithm and has been cited about 14660 times. I would consider (active) contour detection algorithms a relevant and very interesting topic for GSoC. > A feature detector like SIFT. A lot of literature is available online and > also should be pretty good to have in skimage. As mentioned on another thread, feature detection--as long as it is not patent encumbered--is on our radar. Specifically STAR (censure), and binary features. Also, perhaps, finding a way to do keyword matching based on our current dense implementation of daisy--any ideas? I haven't read the daisy paper yet. Stéfan

1 0