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

From: Thorsten Behrens (th.behrens_at_[hidden])
Date: 2006-10-16 12:59:40

Hi Lubomir,

on Sun, Oct 15, 2006 at 07:09:44PM -0700, you wrote:
> 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 by 'pixel transformation' you mean all the magic that's needed to
access the pixel's internal memory representation, then yes.

> 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.
> 
Not an issue (of course there are default noop accessors for STL-like
iterators). Why do you think this is 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?
> 
Iterators and accessors can be passed as tuples - typically a triple
<i_begin,i_end,acc> for the source and a pair <i_begin,acc> for the 
destination image. But that should be obvious from the Vigra docs...

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

Well, you wrote in 
B55F4112A7B48C44AF51E442990015C0016F3A56_at_[hidden]
> But GIL doesn't use any of these. It uses performance specializations
> as follows:
> 1. If both images are interleaved and have no padding at the end of
>    rows, invokes a single memmove
> 2. If both images are planar and have no padding at the end of rows,
>    invokes a memmove for each channel
> 3. If they are of the same type but have padding at the end of rows,
>    invokes memmove for each row (or K-memmoves per row in the case of
>    K-channel planar images)
>
Thus, you're specializing for certain iterator types anyway - no
difference compared to Vigra. In fact, you would probably specialize all 
those types that have non-trivial accessors in Vigra - simply because
there's so much room for optimization (take a fill on a 1bpp image, for
example - no need to execute that bit-by-bit, no? Or a paletted
destination image - you probably won't fill it by repeated palette
lookup for a constant color value and every single pixel).

Being able to employ stl algorithms for those types is a theoretical 
advantage at best. For all the other iterators types provided by Vigra,
stl algos work like a charm.

Lubomir, I really don't want to be a nag, and I'm getting the impression
that this discussion is leading nowhere. I just wanted to point out what
I perceived superior in Vigra - at the end of the day, it's prolly a
minor issue, at least if the set of pixel iterators is complete for
common formats (1-N packed pixel, palette lookup, 16bit floats).

Still, I'd love to see a best-of-both-worlds solution (a merge of Vigra
and GIL functionality - since Vigra was also offered to boost some time
ago...). But then again, that's probably off-topic and certainly none of
my business in this review thread.

Cheers,

-- Thorsten