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

From: Lubomir Bourdev (lbourdev_at_[hidden])
Date: 2006-10-15 15:16:15

Thorsten wrote:
>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?
>>
>What if you need to revert your design, because certain functionality is
>not (or not easily) implementable - and you only find out while doing
>that one, specific algorithm? So, seeing a lib with lots of
>(algorithmic) functionality kind of increases my confidence that the
>basic design is sound...

Your argument is generally true, but not in the case of GIL.
GIL's goal is simple - to provide consistent, fast and representation-independent access to the pixels of an image. I claim that navigating the image and being able to get/set the values of the pixels is sufficient interface to build any imaging algorithm. Can you provide a counterexample?

>> Merging between GIL/Vigra or especially GIL/AGG would be interesting.
>>
>To repeat: I'd at least like to have Vigra's concept of pixel accessors
>and promotion traits merged/applied in GIL.

Promotion traits, as I stated in another thread, are handy and there is definitely a value in providing them. But I think they are an integral part of the imaging algorithms and therefore belong in the numeric extension. So stay tuned!
 
As for Vigra's pixel accessors... I read the documentation and I am still struggling to understand the difference between using them and using a PixelDereferenceAdaptor. If they indeed serve the same purpose, that would be an argument against including them in GIL. Can you post a simple example that illustrates how pixel accessors in Vigra are used?
 
Thanks,
Lubomir