Hi Stefan.
I see that you've worked on vlfeat wrappers. I've been thinking of the best way to provide a scikits.image.feature module, with things like star features, FAST corner detection (wrappers already written), etc. If you have any ideas, I'd love to hear them. I'm only roughly familiar with keypoint detection. But I thought about integrating SIFT code from vlfeat. I love vlfeat but it's to much matlab... And I'm pretty sure it's hard to beat the vlfeat SSE2 code.
I guess similar things apply to corner detection. vlfeat is gpl. Is it possible to include gpl code int scikits.image and still release it under BSD license (which is the current scikits.image license, right?) ? I saw there was also a discussion about making opencv an dependency. Wouldn't it be possible to just include some of the optimized code without actually using the whole library? Or is there to much infrastructure in opencv that gets used? I'm not a big fan of opencv but I guess there is some fairly optimized code there that scikits.images might want to use. Cheers, Andy
Hi Andy On Wed, Sep 21, 2011 at 9:35 AM, Andreas Mueller <amueller@ais.uni-bonn.de> wrote:
vlfeat is gpl. Is it possible to include gpl code int scikits.image and still release it under BSD license (which is the current scikits.image license, right?) ?
Unfortunately not. Almost the entire scientific software stack (python, numpy, scipy, ipython, matplotlib, scikit-learn, etc.) are all BSD; we have great interaction with people from industry (who shy away from the GPL due to its viral nature), and we do not want to risk those collaborations. I also don't like that GPL projects can take from BSD projects, but that any improvements they make then cannot be contributed back. That said, many open source projects are simply unaware of these issues, and gladly re-license certain portions of their code upon request. Some good examples are the CellProfiler team's great morphology code (currently a pull request, being merged), or Nocedal's BFGS code that he relicensed BSD for inclusion in SciPy.
I saw there was also a discussion about making opencv an dependency. Wouldn't it be possible to just include some of the optimized code without actually using the whole library? Or is there to much infrastructure in opencv that gets used?
After conversing with several people at the EuroSciPy conference, I realised that this would be a bad idea. People simply don't want such a heavy dependency. But your suggestion is the right one: we'll borrow code where needed (e.g. star features), and send improvements back to the opencv team as they come up.
I'm not a big fan of opencv but I guess there is some fairly optimized code there that scikits.images might want to use.
OpenCV is crazy fast. Pieter Holtzhausen, as part of his google summer of code, implemented an SSE2 convolution, which almost gets to the OpenCV speed; point is--it takes a lot of manual effort to beat their code speedwise. Of course, with all the Python scientific tools at our disposal, we gain plenty of other benefits that C cannot provide. Regards Stéfan
participants (2)
-
Andreas Mueller -
Stéfan van der Walt