[boost] GIL Image Processing Library - specific comments

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(),
             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: [phone]                Vogt-Koelln-Str. 30 |
| Fax:   [phone]                D - 22527 Hamburg   |
| Email: u.koethe_at_[hidden]               Germany             |
|        koethe_at_[hidden]                        |
| WWW:   http://kogs-www.informatik.uni-hamburg.de/~koethe/      |
|________________________________________________________________|