[GIL] integration between boost libraries (gil / multiarray)
Hi, I'm a big fan of gil. It's one of the best library I know. It has really improved my work, which consists of writing image processing algorithms. Thanks to the authors. 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, ... 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. 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 ? Best regards, Fabien
At Mon, 21 Jun 2010 17:40:31 +0200 (CEST), fabien.castan@free.fr wrote:
I'm a big fan of gil. It's one of the best library I know. It has really improved my work, which consists of writing image processing algorithms. Thanks to the authors.
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, ...
If GIL is truly a generic library (I am not familiar with it), it should be possible to make your own types (and MultiArrays) model its concepts, and use all these kinds of algorithms. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Hi there,
If GIL is truly a generic library (I am not familiar with it), it should be possible to make your own types (and MultiArrays) model its concepts, and use all these kinds of algorithms.
Gil is concept based. Christian
At Mon, 21 Jun 2010 10:37:59 -1000, Christian Henning wrote:
Hi there,
If GIL is truly a generic library (I am not familiar with it), it should be possible to make your own types (and MultiArrays) model its concepts, and use all these kinds of algorithms.
Gil is concept based.
That doesn't necessarily make it generic :-0 In C++ sans-concept-support, it's easy to define concepts that aren't amenable to post-hoc mapping (definition:http://cpp-next.com/archive/2009/11/three-kinds-of-concept-maps/). -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Hi there,
Gil is concept based.
That doesn't necessarily make it generic :-0
Do you mean that tools like concepts in the wrong hands can cause confusion or just plain gibberish? If so, I'm pretty sure the people at adobe who handcrafted gil knew what they were doing. Also gil survived the boost review and is now part of boost for a couple of years, or so. I don't really wanna blow up this issue. For now view concepts from gil and multi_array are not compatible I would say. Hopefully in the future we can agree on 2D and 3D container and container view concepts that should be implemented by all libs who need such functionality. In the same we way boost needs a common point2D structure. ;-)
In C++ sans-concept-support, it's easy to define concepts that aren't amenable to post-hoc mapping
(definition:http://cpp-next.com/archive/2009/11/three-kinds-of-concept-maps/).
Thanks for the link! Christian
At Mon, 21 Jun 2010 20:43:03 -1000, Christian Henning wrote:
Hi there,
Gil is concept based.
That doesn't necessarily make it generic :-0
Do you mean that tools like concepts in the wrong hands can cause confusion or just plain gibberish? If so, I'm pretty sure the people at adobe who handcrafted gil knew what they were doing. Also gil survived the boost review and is now part of boost for a couple of years, or so.
I'm not trying to imply anything, one way or another, about the people who built GIL. I am only saying that you can invent concepts all day long but you'll end up with a non-generic library if you haven't accounted for the need to non-intrusively adapt types to model them.
I don't really wanna blow up this issue.
Then I suggest cooling your jets a wee bit :-)
For now view concepts from gil and multi_array are not compatible I would say. Hopefully in the future we can agree on 2D and 3D container and container view concepts that should be implemented by all libs who need such functionality. In the same we way boost needs a common point2D structure. ;-)
I'm not sure why it should be true that we need a common point2D. But then, maybe I'm missing something. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
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
participants (3)
-
Christian Henning -
David Abrahams -
fabien.castan＠free.fr