Boost logo

Boost :

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2006-10-18 19:38:25

Lubomir Bourdev wrote:
> Tim Shead wrote:
>> Another question / observation on the GIL API. When
>> interfacing with external code, particularly "C" libraries,
>> it's often necessary to pass a pointer to the memory managed
>> by an image
>> (gdk_pixbuf_create_from_raw_data() in my case). So far, I've
>> been using
>> &image[0]
>> to get a pointer to memory, but that's pretty ugly, and I'm
>> thinking it might not work for all cases. Is there a better
>> way to do it? If not, I'd suggest adding an "image::data()"
>> method that would provide canonical access to memory. The
>> choice of name is for consistency with std::basic_string::data().
>> Cheers,
>> Tim
> The problem of course is that the image view may not at all be
> memory-based, like the Mandelbrot set.
> Even for memory-based image views, and for images, they may be planar,
> so in this case you really need to get pointers to each color plane.
> If the image is interleaved you can just do what you would do with
> std::vector:
> rgba8_image_t img(100, 100);
> void* data=&img[0];
> If the image is planar, you can get the pointers to each plane like
> this:
> rgb8_planar_image_t planar_img(100, 100);
> void* plane0=&planar_img[0]->channel<0>();
> void* plane1=&planar_img[0]->channel<1>();
> ...
> Useful MPL predicates:
> // plain memory-based views/images with no dereference adaptors
> view_is_basic<View>
> image_is_basic<Image>
> view_is_planar<View>
> image_is_planar<Image>
> I am open to adding an interface like data() but I am not sure how best
> to do this to accommodate these variations.

We use something similar in VSIPL++ (,
where we have e.g. Matrix<std::complex<float> > with interleaved and split storage.
There we have some 'direct data access' metafunctions which provide a 'data()'
accessor returning

a) std::complex<float> *, for interleaved storage
b) std::pair<float *,float *>, for split storage
c) nothing, if there is no direct data access possible.

We have been thinking about extending it to Image Processing, where the element-type
is Pixel (such as defined by GIL), and storage is interleaved or planar.


      ...ich hab' noch einen Koffer in Berlin...

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