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 accessors? Lubomir
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: http://lists.boost.org/mailman/listinfo.cgi/boost