OpenImageIO

[Damian Eads]

2009/10/4 Stéfan van der Walt <stefan at sun.ac.za>:
>
> 2009/10/4 Damian Eads <eads at 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?).

It's not a template issue in this case. The FAST corner detector,
which compiles by default in LIBCVD, requires a lot of memory and
computation. To disable, try ./configure --disable-fast7
--disable-fast8, --disable-fast9. This should greatly speed up
compilation.

> We could
> look at extracting the IO part of CVD or ImageMagick to keep things
> light-weight.

Could do. LIBCVD is pretty lightweight and much smaller than OpenCV.
For example, there aren't high-level systems like face detectors in
LIBCVD nor will there ever be. LIBCVD just contains basic data
structures (an Image and ImageRef class), basic image/video loaders,
and easy-to-use, highly optimized image processing operators. Its
interface is designed to be functional rather than object-oriented.

> 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).

That could work too. :)

>>> 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.

Agreed, I don't think we want to replicate efforts to wrap existing
libraries. However, I think rewrapping is acceptable if we offer a
much simpler, functional interface than what has been done before. One
of the reasons why MATLAB is so popular is its functional style and
use of arrays to represent most data. If we can greatly reduce
boilerplating then duplicating efforts may be worthwhile.

>> 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.

Yes, I still need to integrate the morphology code into your branch,
once I get around figuring out how GIT works.

Damian

-----------------------------------------------------
Damian Eads                           Ph.D. Candidate
University of California             Computer Science
1156 High Street         Machine Learning Lab, E2-489
Santa Cruz, CA 95064    http://www.soe.ucsc.edu/~eads