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@namail1.corp.adobe.com
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