Re: GSoC 2013 : Idea Discussion
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
Hi Stefan, 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.
On Mon, Apr 29, 2013 at 2:33 AM, Ankit Agrawal <aaaagrawal@gmail.com> wrote:
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.
I simply meant that we are now able to implement not only that functionality but quite a bit more. Stéfan
participants (2)
-
Ankit Agrawal
-
Stéfan van der Walt