VIGRA ("Vision with Generic Algorithms") is a novel computer vision library that puts its main emphasize on flexible, reusable algorithms, because algorithms represent the principle know-how of this field. The library was consequently built using generic programming as introduced by Stepanov and Musser and exemplified in the C++ Standard Template Library. By writing a few adapters (image iterators and accessors) you can use VIGRA's algorithms on top of your data structures, within your environment. Alternatively, you can also use the data structures provided within VIGRA, which can be easily adapted to a wide range of applications. VIGRA's flexibility comes almost for free: Since the design uses compile-time polymorphism (templates), performance of the compiled program approaches that of a traditional, hand tuned, inflexible, solution.
VIGRA's design is documented in the chapter "Reusable Software in Computer Vision" by Ullrich Köthe, in: B. Jähne, H. Haußecker, P. Geißler: "Handbook on Computer Vision and Applications", volume 3, Acadamic Press, 1999. If you don't have the book, you may read a draft of this article. A shorter article "STL Style Generic Programming with Images" desrcibing some of the ideas has appeared in the January 2000 issue of C++ Report Magazine.
VIGRA is subject to this LICENSE. It can be downloaded at http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/vigra1.0.tar.gz. VIGRA should compile with any standard-conforming C++ compilers (including GNU g++, SGI C++ 7.3) and some non-conforming ones (SGI C++ 7.2, Microsoft Visual C++ 5.0, patchlevel 3). You can read the documentation online. Please report any bugs or other comments to koethe@informatik.uni-hamburg.de
Hi Ullrich -
My name is Will Schroeder, I'm working with a group of folks developing a segmentation and registration toolkit for the National Library of Medicine in the US. We are in the design stage, and have been struggling with architectural issues, mainly where to draw the line between run-time and compile-time binding.
My prior experience is with the open-source Visualization Toolkit (VTK www.kitware.c= om/vtk.html) which leans towards run-time binding and a very conservative C++ design (single inheritance, limited use of templates, etc.). Part of the reason for this is that we wrap the C++ library with interpreted languages like Tcl, Python, and Java. VTK is successful, it's a huge system and runs everywhere, and people seem to be able to learn and use it pretty well.
Some of the folks on the team have been encouraging us to go the generic programming route. We've been exploring and stumbled across the Vigra code. While I think this technology is promising, I'm concerned about the possible problems introduced such as code bloat, compiler difficulties, unreadable code, proliferation of classes, lack of run-time flexibility, etc. Part of my concern is that this toolkit has the potential to grow to 1000 classes and 250,000 lines of executable code. So it's code tha must be usable in production, not just in the academic sense.
Can you point me to any articles that discuss these issues, or do you have any experience that you can share along these lines? I'm interested in hearing both sides of the story. I have downloaded Reusable Software in Computer Vision and will look at it today.
Thank you,
Will
Sender: koethe@kogs.informatik.uni-hamburg.de--=====================_7714883==_.ALT-- From zhuge@mipg.upenn.edu Mon, 28 Feb 2000 17:30:25 -0600 Date: Mon, 28 Feb 2000 17:30:25 -0600 From: Ying zhuge@mipg.upenn.edu Subject: Fw: [Insight-developers] compliering error This is a multi-part message in MIME format. ------=_NextPart_000_002A_01BF8211.7F9E5100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It happened to me too. I try many times today. Ying ----- Original Message -----=20 From: Yinpeng Jin=20 To: insight-developers@public.kitware.com=20 Sent: Wednesday, February 28, 2001 3:07 PM Subject: [Insight-developers] compliering error It looks that ITK.dsw generated by CMake was changed, I got the below = message after a update: Is it relating to my MSVC++ setting or it is something due to CMake? It = only happened today, used to be fine all the time. =20 =20 --------------------Configuration: VXLNumerics - Win32 = Debug-------------------- Compiling... =20 ...... =20 \insightnew\InsightBuild\Code\Common\Debug\ITKCommon.lib=20 LINK : fatal error LNK1181: cannot open input file = "\insightnew\InsightBuild\Code\Common\Debug\ITKCommon.lib" Error executing link.exe. =20 VXLNumerics.lib - 1 error(s), 358 warning(s) --------------------Configuration: ITKCommon - Win32 = Debug-------------------- Compiling... =20 ...... =20 \insightnew\InsightBuild\Code\Numerics\vxl\Debug\VXLNumerics.lib=20 LINK : fatal error LNK1181: cannot open input file = "\insightnew\InsightBuild\Code\Numerics\vxl\Debug\VXLNumerics.lib" Error executing link.exe. =20 ITKCommon.lib - 1 error(s), 1 warning(s) --------------------Configuration: ITKBasicFilters - Win32 = Debug-------------------- Compiling... itkWriter.cxx Creating library... Microsoft (R) Library Manager Version 6.00.8447 Copyright (C) Microsoft Corp 1992-1998. All rights reserved. LINK : fatal error LNK1181: cannot open input file = "\insightnew\InsightBuild\Code\Common\Debug\ITKCommon.lib" Error executing link.exe. =20 ITKBasicFilters.lib - 1 error(s), 0 warning(s) =20 ------=_NextPart_000_002A_01BF8211.7F9E5100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Date: Fri, 25 Feb 2000 17:03:16 +0100
From: Ullrich Koethe <koethe@informatik.uni-hamburg.de>
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
To: Will Schroeder <will.schroeder@kitware.com>
Subject: Re: Could you share your experience...
X-MIME-Autoconverted: from 8bit to quoted-printable by kogs1.informatik.uni-hamburg.de id RAA02857
Hi Will,
this is a very interesting question indeed! As it happens I'm hoping to
get a PhD for my answer next Tuesday.
Basically, i think you need both: generic programming to get flexibility
at the low-level (functions and data structures), and
object-orientation for run-time flexibility.
In comparison to e.g. computer graphics, image analysis is a much less
mature field (inverse problems are always much harder). So, there is no
set of standard algorithms that work most of the time (some people claim
otherwise, but don't be fooled). Instead, we keep changing all kinds of
details as circumstances (i.e. the images to be processed) and
understanding evolve. These changes occur at a relatively=20 low-level:
exchange float for byte, replace a particular formula for second
derivatives by another one and the like.
Using virtual functions (and perhaps dynamic_cast) to cope with=20 this
kind of changes will result in a very inefficient system. You can't
simply do a dynamic cast for each pixel, i.e. 1 million times a second.
Compile-time techniques are much more appropriate here. In=20 addition,
generic programming gives you some techniques that are not present in
the OO part of C++:
- code generation upon necessity
- multiple polymorphism with powerful pattern matching (by partial
ordering
of overloaded functions and function templates)
- meta classes (traits)
So I use generic programming to write the real 'work horse
functionality'. (Some of the related ideas are described in my paper.)
Now, to get runtime flexibility, I build a larger pieces of
functionality from the generic building blocks and wrap them into
objects. These objects are then exported to Python. So I have both: I
can change alsogrithmis details in the generic layer and collaboration
of modules in the OO layer.
When implementing this in C++, some care is required to manage compile
dependencies. Since templates are usually kept in header files,
visibility of these headers must be controlled. (Otherwise, a=20 simple
implementation change could cause a huge recompile). This is part of the
benefit of wrapping genericity into objects. (Hopefully, this situation
will change when compilers start to support separate compilation=20 for
templates).
As to the choice of compiler: if your your goal is maximum portability,
you might be better of not using generic programming. However, since the
standard library depends on it, compilers are quickly catching up. Also,
one can use a subset of techniques that retains most of the benefits and
runs on most compilers. I've successfully used GNU g++, the SGI native
compiler and Microsoft Visual C++ (with some limitations).
Code bloat is a problem that I havn't gone into very much (which means
it wasn't so severe as to cause trouble). Often, the main reason=20 for
code bloat are long template names which can easily be stripped off the
final executable (on SGI, this sometimes reduces code size to 50%).
I hope this helps. Please ask again if any question remain
Regards
Ulli
--
________________________________________________________________
| &nb= sp; &= nbsp; = ; &nb= sp; |
| Ullrich Koethe Universit=E4t Hamburg / University of Hamburg |
| &nb= sp; FB Informatik / Dept. of Computer Science |
| &nb= sp; AB Kognitive Systeme / Cognitive Systems Group |
| &nb= sp; &= nbsp; = ; &nb= sp; |
| Phone: +49 (0)40 42883-2573 = Vogt-Koelln-Str. 30 |
| Fax: +49 (0)40 42883-2572 = D - 22527 Hamburg |
| Email: u.koethe@computer.org &= nbsp; Germany &nb= sp; |
| koethe@informatik.uni-hamburg.de &n= bsp; = |
| WWW: http://kogs-www.informatik.uni-hamburg.de/~koethe/ = ; |
|________________________________________________________________|