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

From: Thorsten (th.behrens_at_[hidden])
Date: 2006-10-16 03:11:30

On Sun, Oct 15, 2006 at 12:16:15PM -0700, Lubomir Bourdev wrote:
> 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.
>
:-)

Well. You've asked a general question, I've responded generally.

> 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?
>  
accessor_t src_a, dst_a;
iterator_t src_i, dst_i;

// copy pixel from src_i to dst_i
dst_a.set(src_a(src_i),
          dst_i);

So, there's more to them than just a way to interpose a function object into 
setting/getting a pixel value (which is what a PixelDereferenceAdaptor does):

One can totally customize the interaction between accessor and iterator, thus
leaving considerably more leeway to both implementer and compiler, when 
applying Vigra algorithms (which all employ a stanza like above). 

Whereas GIL's 

iterator_t src_i, dst_i;

// copy pixel from src_i to dst_i
*dst_i = *src_i;

glues access and iteration together (N1550's new iterator concepts are there 
for a reason - STL iterators do mix several aspects). True, there's a way to
customize access, by wrapping a value type with e.g. planar_ptr. But that's
kind of involved, and buries things that could be right at ones fingertips
deep down in the innards of GIL.

And to ask the other way 'round: are there any reasons *not* to use the
accessor concept? It's for free in all cases you don't need it, makes clear
the dichotomy between access and traversal (which is especially apparent for
the domain of image pixel), and is used successfully in a state-of-the-art
image processing framework.

Cheers,

-- Thorsten