Fwd: OpenImageIO

[Damian Eads]

Ed Rosten meant to send this to everyone so I'm forwarding this.


---------- Forwarded message ----------
From: Edward Rosten <edward.rosten at gmail.com>
Date: Mon, Oct 5, 2009 at 10:33 AM
Subject: Re: OpenImageIO
To: Damian Eads <eads at soe.ucsc.edu>


On Sun, Oct 4, 2009 at 1:17 AM, Damian Eads <eads at soe.ucsc.edu> wrote:

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

There are some compiler specific issues. Quite a few from the gcc 3.x
series failed to compile the code at all (getting stuck in an infinite
loop or failing entirely with an internal error). GCC 4.0.x and 4.1.x
are pretty slow with this code. The more recent iterations of 4.x work
well.

By the way, the makefile supports parallel builds flawlessly, which
speeds things up a great deal. The entire thing compiles on 30 seconds
on a fast, single socket computer.

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

It is possible, not that hard even. Due to the amount of generic code
in libCVD, once you have the image IO and video loading (with the
requisite colourspace conversion code), you will have most of the
compilable source code. This step wouldn't save you very much over
all. Much of the remaining code is in templates, so it won't add
anything unless you try to instantiate specific algorithms.

If you are still concerned about the extras, then I could put an
option in configure to compile only the image IO part, or we could
figure some other way of making it work. Although the build system is
quite monolithic, the library itself is very modular. I think it would
be worth trying to prevent fragmentation if possible, since it makes
maintenance, feature enhancements etc easier.

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

I would like to add that libCVD will stay this way.

-Ed

--
(You can't go wrong with psycho-rats.)  (http://mi.eng.cam.ac.uk/~er258)

/d{def}def/f{/Times findfont s scalefont setfont}d/s{11}d/r{roll}d f 2/m
{moveto}d -1 r 230 350 m 0 1 179{1 index show 88 rotate 4 mul 0 rmoveto}
 for /s 12 d f pop 235 420 translate 0 0 moveto 1 2 scale show showpage



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