Hi all, I have delved somewhat into the source code of GIL and would like to make some comments: 1. I like the concept of views to adapt images to algorithms' needs. Users can understand this quite easily. But there is also a danger of overuse (this is pointed out in the tuorial): doing all transformations on the fly may be very inefficient. For example, conversion between RGB and CMYK in an adaptor is OK, but RGB to LAB is not. For the latter cases, the GIL authors propose an idiom copy_pixels(some_expensive_view(source), some_other_view(destination)); A traditional STL style solution would probably be easier: transform(source.begin(), source.end(), destination.begin(), SomeFunctor()); (since implementing a view is more involved than implementing a functor, at least in terms of reading documentation). On the other hand, a PixelDereferenceAdapter is semantically also a view, so the use of the view idea could be extended. The interpretation of pixel adaptors as views is more apparent when data accessors are used (they work essentially like the image views). The difference to the PixelDereferenceAdapter is mainly syntactic (using operator* rather than get/set functions), and it was already pointed out that this is not without problems (reference proxies are required for operator*, which are more difficult to implement than data accessors and may sometimes exhibit unexpected behavior). 2. I like the idea of handling unknown input formats by means of a variant pixel. However, it remains to be shown whether this solution is indeed practical for algorithm implementation. For example, when a binary operation is called for a variant with 4 possible types, the compiler is forced to generate 16 algorithm instantiations (for all pairs) for every result type. There are a number of design alternatives (for example coercion to a common type) which are probably better. 3. I don't like that the input/output image format (jpeg, png etc.) must be hardcoded in the program (by using jpeg_read_image() etc.). 4. GIL has no (public) test suite whatsoever. 5. A GIL image can only be used with POD pixel types, because the allocated memory is never initialized (by uninitialized_fill() or equivalent). Neither is the destructor for individual pixels called before deallocation. 6. GIL may have alignment problems. For example, the variant template allocates internal memory as "char[MAX_SIZE]" but then reinterpret_casts it to an image type. Casts from "signed short *" to "pixel<int16s, rgb_t> *" and similar (see the tutorial) are also problematic (is there a guarantee that "sizeof(pixel<int16s, rgb_t>) == 3*sizeof(int16s)", and that they have the same alignment ?) 7. Is transform_pixel_position() able to handle image borders properly and efficiently (page 7 of the tutorial)? Otherwise, it is wrongly used (may cause segfaults). 8. The cached_loaction_t is a nice, elegant optimization. 9. Generic algorithms that work efficiently for both planar and interleaved multi-channel images are not as easy as the authors imply. On page 5 of the tutorial, the authors recommend transform_channels() in order to unroll the inner loop over the channels. But this optimization is useless for planar images - in this case, one wants to work on one channel at a time, i.e. the channel loop must be the outer rather than the inner loop. So much for now. Best regards Ulli -- ________________________________________________________________ | | | Ullrich Koethe Universitaet Hamburg / University of Hamburg | | FB Informatik / Dept. of Informatics | | AB Kognitive Systeme / Cognitive Systems Group | | | | Phone: +49 (0)40 42883-2573 Vogt-Koelln-Str. 30 | | Fax: +49 (0)40 42883-2572 D - 22527 Hamburg | | Email: u.koethe@computer.org Germany | | koethe@informatik.uni-hamburg.de | | WWW: http://kogs-www.informatik.uni-hamburg.de/~koethe/ | |________________________________________________________________|