Ed Rosten meant to send this to everyone so I'm forwarding this. ---------- Forwarded message ---------- From: Edward Rosten <edward.rosten@gmail.com> Date: Mon, Oct 5, 2009 at 10:33 AM Subject: Re: OpenImageIO To: Damian Eads <eads@soe.ucsc.edu> On Sun, Oct 4, 2009 at 1:17 AM, Damian Eads <eads@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