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