Boost logo

Boost :

From: Lubomir Bourdev (lbourdev_at_[hidden])
Date: 2006-10-15 22:09:44

> >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?

So, to summarize, GIL incorporates the pixel transformation function
into the iterator itself, whereas Vigra uses accessor objects
separately, and goes through their interface explicitly to get/set the
values of pixels, correct?

If so, I think accessors are a major limitation.

First of all, don't you need to write four versions of each generic
algorithm, based on whether the source and destination have accessors or
not? Or do you always provide accessors (the default ones doing a noop)
and use their set method? Both alternatives are problematic.

Second, isn't it cumbersome to provide an accessor separately from the
iterator and to have to pass it around everywhere you need it?

Third, perhaps the most severe limitation, expressions like
"dst_a.set(src_a(src_i),dst_i)" do not follow standard iterator
interfaces and cannot be used in any standard generic algorithms. For
example, how can you invoke any STL algorithm on images that have custom


> 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
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at