Boost logo

Boost :

From: Ullrich Koethe (koethe_at_[hidden])
Date: 2006-10-17 23:43:35

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(),

(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

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

|                                                                |
| 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_at_[hidden]               Germany             |
|        koethe_at_[hidden]                        |
| WWW:      |

Boost list run by bdawes at, gregod at, cpdaniel at, john at