Hi all, since VIGRA has been mentioned several times in the discussion of GIL, I (as the VIGRA maintainer) would like to add a few comments. Some people on the list perhaps remember that I offered VIGRA for inclusion into boost a few years ago (must have been around 2002). Back then, it didn't find much acceptance, so I didn't push very far. Due to the renewed interest in image libraries, I'd like to repeat my offer now -- I still think that boost would be a good home for VIGRA. I also consider some integration with GIL an option, although one has to check what is technically possible and can be done by volunteers. In any case, I like GIL's extensive use of the view concept. On Fri, Oct 13, 2006 at 01:43:50PM -0700, Lubomir Bourdev wrote:
A related question: Which one is easier - building new functionality on top of a solid design, or extending the design of a library with lots of existing algorithms that are built on top of the old design?
This implies that functionality (i.e. algorithms) should be build on top of a solid (i.e. more or less finalized) design. However, in my experience this is impossible: as one tries to implement new functionality, one constantly meets limitations of the original design. It is the hallmark of good design that it can be adapted to these evolving needs with minimal effort. VIGRA has proven to be very flexible in this respect: we added much new functionality to the VIGRA core with hardly ever breaking backwards compatibility in existing algorithms. A design can only be really judged by demonstrating that it can evolve according to the needs of new requirements. In the GIL design guide, VIGRA is explicitely criticised for lack of two features: 1. support for different channel orderings such as BGR and conversions between them. This feature has been added to VIGRA about a year ago. 2. support for images with separate channels: VIGRA handles them by means of 3-dimensional MultiArray and MultiArrayView templates. The only things missing are DataAccessors that interprete these as 2-dimenional structures with multiband pixels, and interfaces to the older BasicImage/BasicImageView group of 2D image classes and algorithms. Both can be added trivially when there is sufficient demand (which has been lacking so far). Someone else pointed out that VIGRA provides an interface to the FFTW library whose license is incompatible with the boost license. This is true, but the FFTW can be replaced with another FFT library without much work provided that the new library is not restricted to power-of-2 image sizes (and it should prefarably be based on std::complex). Regards Ulli Koethe (VIGRA maintainer)