2009/10/4 Damian Eads <eads@soe.ucsc.edu>:
It is an important distinction. Along these lines, LIBCVD has no general dependencies other than a C++ compiler and compiles on both GCC and Visual Studio. If chosen as a specific dependency, it wouldn't increase the size of our dependency DAG by very much at all.
I downloaded both ImageMagick and CVD earlier this evening and started to compile both. ImageMagick completed fairly quickly, but CVD seems to take extremely long (could be a platform/compiler specific issue, I"m not sure. Are they making heavy use of templates?). We could look at extracting the IO part of CVD or ImageMagick to keep things light-weight. But like I mentioned earlier, we could just wrap existing solutions -- the user is bound to have PIL or matplotlib or imagemagick or ... installed (and we can encourage them to do so in the readme, for example).
My personal feeling is that we should stay away from general dependencies, if possible. I don't intend for scikits.image to become a wrapper around libcvd or opencv -- those wrappers already exist. Rather, I want to focus on implementing novel image processing techniques that are not easily available elsewhere. [Of course, if a function is easy enough to implement and useful for general purpose image processing (such as the color conversion routines), there's little reason to exclude it.]
Novel image processing algorithms not available elsewhere? Like what?
Sorry, I should have said "novel OR not easily available elsewhere". My main thought was that we should not try to replicate the wrappers for OpenCV, for example.
Image Processing. Most researchers use MATLAB, C++, or a combination of both. We should think of ways to broaden the appeal of Python to such researchers and the development of scikits.image should reflect it.
Absolutely, but since we can't be everything to all people, I'd rather make a difference where it is needed: adding algorithms not already easily accessible to Python users. Cheers Stéfan