Re: [boost] GIL Review - PixelDereferenceAdaptors vs. DataAccessors

From: Thorsten Behrens (th.behrens_at_[hidden])
Date: 2006-10-20 20:11:33

On Wed, Oct 18, 2006 at 11:58:55AM -0700, Lubomir Bourdev wrote:
> [about iterator/accessor vs. iterator-only]
>
> Second, reuse. The promise of generic programming can best be realized
> by agreeing to build on the same concepts. PixelAccessors may be
> appealing (I think they are in many ways) but unfortunately people have
> invested already a lot of effort in writing algorithms that deal just
> with iterators. If I want to copy two images I could just use std::copy.
> If I want to rotate the pixels 180 degrees, I can use std::reverse. Of
> course, as Thorsten pointed out, GIL often provides performance
> overloads. But the important thing is, we don't have to ; the algorithms
> still work. Besides, in the cases where we do, like std::copy, we
> typically still delegate to STL and call their std::copy. We don't
> explicitly call memmove, we call std::copy with PODs and STL turns it
> into memmove. We want to delegate as much as we can to standard
> components because they could be better tested and optimized.
> And the story, of course, does not end with the STL. If I want to find
> the largest and smallest pixels in my image I can just use
> boost::minmax_element. You may say that each of these is a trivial
> algorithm and easy to just make a version that works with Vigra, but as
> a collection they become a lot, and it is an open-ended set of
> algorithms: By conforming to the standard GIL will automatically benefit
> from any new algorithms that people may provide in the future.
>
I agree - with STL-style iterators being a well-established concept,
using them provides many benefits. But since the separation into
DataAccessor/Iterator (or PropertyMap/Cursor, see
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1873.html) so
nicely separates concerns (I think this is *especially* apparent in the
image pixel domain - packed pixel, planar channels, tiled or synthetic
images), I'd still love to see this concept used in GIL.

>From a plain user's perspective, I find something like
http://opensource.adobe.com/gil/packed_pixel.hpp just a little bit too
involved - I'd expect the common set of pixel types to be supported
natively in GIL (I acknowledge you already offered to include packed 
pixel support).

Both items taken together, what do you think about the following idea:
model GIL's core functionality according to DataAccessor/Iterator, and
provide an STL-style RandomAccessTraversalIterator as a wrapper on top
of that? Wouldn't that make up for a truly generic framework, where I'd
only need to provide something along the lines of your
pack/unpack_channel_fn functions and a bit of glue to add my own, custom
packed pixel type? Towards the algorithms, you stay compatible, to the
inside you're extremely flexible.

Then, Vigra & AGG...

>From how it appears to me (and what you and others stated), GIL's
selling points are currently pixel and image view abstractions, not so
much the actual algorithms. As a user, I don't have too much use for
that, I'm more interested in turn-key solutions like a Canny edge
detector, or in filtered image transformations (likewise, I'm a user of
Spirit, not so much of MPL). Thus, I feel it's crucial that, supposed
GIL is accepted into boost, it gets a set of common algorithms soon.
Luckily, Vigra was also offered to boost, and you and Ulli have
proof-of-concept code how to integrate them. I'd therefore really like
to see Vigra's algorithmic half in boost, too. 

Ulli, do you think that's feasible?

Cheers,

-- Thorsten