Re: [boost] VIGRA and GIL -- Review of Generic Image Library (GIL)

From: Lubomir Bourdev (lbourdev_at_[hidden])
Date: 2006-10-16 17:50:05

Jose wrote:
> It would be great news if the GIL authors and yourself can 
> manage to integrate both libraries.
> 
> I haven't sent my GIL review, but while GIL provides a sound 
> design it would benefit most by combining with the more 
> mature VIGRA library.

We would be happy to see GIL's image abstraction combined with VIGRA's
algorithms. That would be the best of both worlds!

However, what we don't want to see is the review of GIL postponed to the
indefinite future or the current GIL submission rejected because of the
lack of VIGRA's algorithms. 

GIL core is a library with a very specific goal - to provide efficient
and representation-independent access to the pixels of an image.
Providing an extensive set of image processing algorithms has never been
the design goal of GIL core. While no library can ever be complete, we
believe GIL provides a comprehensive solution to the stated goal. 

Here is why we believe GIL is ready for boost submission as-is:

1. The set of image algorithms is fundamentally open-ended. Vigra has a
good set of them, but so do other libraries, like Intel's IPP, and ITK.
Why stop with VIGRA, why not take advantage of all of them? And why stop
at imaging algorithms; why not include computer vision algorithms like
the ones in OpenCV? And why not add vector graphics algorithms, like the
ones in AGG and Cairo? And when would we be ever done?

2. A library with multiple goals that could logically and easily be
separated should be broken down into multiple libraries. Notably, image
processing algorithms (like the ones in VIGRA) constitute a separate
goal and deserve a separate library. Vector graphics (AGG) is another
separate goal and deserves a separate library. Of course, it makes sense
for both of them to make heavy use of a core library (like GIL) that
abstracts away the image representation.

3. As Matt Gruenke states, the goal that GIL addresses is sufficiently
important in itself to justify it constituting a separate submission.
There are many cases where you deal with images in which you don't need
to deal with image processing algorithms. By providing GIL in boost
today, we will address the needs of this set of people that would
otherwise have to wait for an unspecified amount of time for something
they don't need.

4. GIL is a large library. Adding an extensive set of algorithms to it
will make it really huge. This will put a big burden on the boost review
process and it will be hard to ensure high quality for a very large
library. We believe it is better for boost to consume large libraries as
a set of smaller, solid and self-contained component libraries.

5. One argument I heard mentioned is, before writing lots of algorithms,
how do you know that your core is solid? It seems more appropriate to
start with algorithms and derive the data structures from them. While we
think this is generally the right approach, we are confident that GIL
can handle any imaging algorithm. This is because all GIL does is
provide an efficient and representation-independent access to the pixels
of an image, and this is all you need to be able to write any imaging
algorithm. We have certainly provided a proof of concept by providing
fully generic algorithms for convolution, resampling and generating the
gradient.

We are not saying that the core is complete, in a sense that it provides
you with all the tools you need in designing image processing
algorithms. In writing GIL image processing algorithms you may discover
useful abstractions, like, for example, the need for promotion traits.
Some of these abstractions may logically remain in the numeric
extension, but the best place for others may be GIL core. So adding
imaging algorithms will likely be associated with updating the core with
some new functionality, and maybe some minimal interface changes, and
this is a natural evolution for any library. However, we don't believe
that big changes to the current interfaces and large redesign of GIL
core will be necessary.

Some people say that GIL is a new library, so its design is unproven in
the long run. While GIL has a shorter life compared to mature libraries
like Vigra, we have been working on GIL for more than three years,
designing, implementing, throwing away and redesigning it from scratch
many times until we reach a design that we are confident with. In
designing GIL we have examined and taken advantage of the ideas behind
many mature imaging libraries, including Vigra. We have also drawn from
the expertise of many people at Adobe, and imaging is one of Adobe's
core businesses. Finally, we are using GIL to solve real problems.

Lubomir & Hailin