Hi there,
I have only one criticism: the integration with other boost libraries and firstly with multiarray. Because manipulating an image consists of manipulating an array of pixels. Many gil's operations are not present in multiarray: flip_view, subsampled_view, subimage_view, n_channel_view, x_iterator, y_iterator, xy_locator, cache_locator, plannar or interleaved arrays, virtual views, static_for_each, ...
Multi_array is for N-dimensional arrays. GIL only makes sense for 2D right now. Now, gil is generic in the sense that it's concept-based. I don't know about multi_array but in theory their views should be compatible to gil's views. But that's theory, in practice I don't expect them too.
For example, inside an algorithm I need to maintain a data structure for each pixel. So I would like to create an array of MyCustomStruct. I can use gil to do that but I need to have a notion of colorspace and operators between pixels, which have no sense in this particular case. But subsampled_view, cache_locator, etc. have a sense.
In theory you're right. But both libraries were developed by different people at different times without having the need to have compatible concepts.
Another less important thing, I find unfortunate that a structure like "point" is inside gil. Many operators are not defined. Some parts of my code are becoming dependant to gil just for a "point" class, or I need to work with one structure and make a conversion... Is there really nothing in boost for such thing ? Maybe just a typedef on a bounded_vector<2> could be sufficient ?
I second that and hopefully one day we can accomplish a boost lib that would define a point type that works for multiple boost libraries. Regards, Christian