Discussion:
[GIL] wrapper for QImage
Tomas Van Verrewegen
2009-02-21 19:54:54 UTC
Permalink
Hi,

I'm planning to write an image manipulation application using Boost.GIL as a
backbone and Qt for the interface. Now I was thinking it might be a good idea
to write a wrapper around QImage to give GIL direct access to the pixels of a
QImage.

I've been looking at the code and as far as I can tell I have 2 options:
(1) create a new GIL image type that wraps the QImage
(2) create a "qimage_pixel_iterator" and use "... interleaved_view(...)"

Now my question(s):
- Would (2) be enough, or is it necessary to also create (1)?
- "QRgb" (Qt's pixel type) is a typedef for "unsigned int", so specialising
eg. "template<class Pixel> struct gil::channel_type" for "unsigned int" seems
somewhat suboptimal (is it an 8bit RGBA pixel or a 32bit Gray pixel?). Some
sort of proxy class might be appropriate? Maybe a gil::pixel<...> subclass?
Christian Henning
2009-02-21 21:01:16 UTC
Permalink
Hi Tomas, I once have created an ipl_image_wrapper for OpenCV. Have a look at

http://gil-contributions.googlecode.com/svn/trunk/gil_2/boost/gil/extension/opencv/ipl_image_wrapper.hpp

This wrapper made it possible to use the OpenCV algorithms. It's uses
shared_ptr to provide value semantics. I would think you can do
something similar with QImage. Unfortunately, I know nothing about
QImage. But I can offer more help with more informations.

Hope this helps. Are you planning on creating a gil extension?

Regards,
Christian



On Sat, Feb 21, 2009 at 2:54 PM, Tomas Van Verrewegen
Post by Tomas Van Verrewegen
Hi,
I'm planning to write an image manipulation application using Boost.GIL as a
backbone and Qt for the interface. Now I was thinking it might be a good idea
to write a wrapper around QImage to give GIL direct access to the pixels of a
QImage.
(1) create a new GIL image type that wraps the QImage
(2) create a "qimage_pixel_iterator" and use "... interleaved_view(...)"
- Would (2) be enough, or is it necessary to also create (1)?
- "QRgb" (Qt's pixel type) is a typedef for "unsigned int", so specialising
eg. "template<class Pixel> struct gil::channel_type" for "unsigned int" seems
somewhat suboptimal (is it an 8bit RGBA pixel or a 32bit Gray pixel?). Some
sort of proxy class might be appropriate? Maybe a gil::pixel<...> subclass?
_______________________________________________
Boost-users mailing list
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Tomas Van Verrewegen
2009-02-21 21:48:43 UTC
Permalink
Thanks for the swift reply, Christian.
Post by Christian Henning
This wrapper made it possible to use the OpenCV algorithms. It's uses
shared_ptr to provide value semantics. I would think you can do
something similar with QImage. Unfortunately, I know nothing about
QImage. But I can offer more help with more informations.
I quickly glanced your code. Unfortunately it seems to take the opposite
approach of what I had in mind:
You copy the GIL pixel data into an IPL image, then you do some cool stuff to
these pixels I suppose, and at the end you might copy everything back to a GIL
image to finish up...
What I want to do is provide GIL with a way of directly accessing the pixel
data owned by a QImage, so all GIL algorithms can work on this data, no
copying back and forth.
I haven't dug my way to the bottom of the GIL code yet, but it seems to me GIL
is designed not to care about the representation of a pixel/an image, so it
should be quite straightforward to provide some sort of qimage_iterator and
create a view on a qimage.
Post by Christian Henning
Standard image views can be constructed from raw data of any supported color
space, bit depth, channel ordering or planar vs. interleaved structure.
Interleaved views are constructed using interleaved_view, supplying the
template <typename Iterator>
image_view<...>
interleaved_view(ptrdiff_t width, ptrdiff_t height, Iterator pixels,
ptrdiff_t rowsize);
Christian Henning
2009-02-21 22:10:08 UTC
Permalink
Post by Tomas Van Verrewegen
I quickly glanced your code. Unfortunately it seems to take the opposite
You copy the GIL pixel data into an IPL image, then you do some cool stuff to
these pixels I suppose, and at the end you might copy everything back to a GIL
image to finish up...
What I want to do is provide GIL with a way of directly accessing the pixel
data owned by a QImage, so all GIL algorithms can work on this data, no
copying back and forth.
I haven't dug my way to the bottom of the GIL code yet, but it seems to me GIL
is designed not to care about the representation of a pixel/an image, so it
should be quite straightforward to provide some sort of qimage_iterator and
create a view on a qimage.
I don't think I'm copying back and forth. But nonetheless, depending
on the image type there are some pixel iterators. Please see here:

http://www.boost.org/doc/libs/1_36_0/libs/gil/doc/html/g_i_l_0188.html

Can you get access to the image buffer, scanline length, etc? If so,
you can create an iterator based on the image type.

Christian
Tomas Van Verrewegen
2009-02-22 11:35:46 UTC
Permalink
Post by Christian Henning
I don't think I'm copying back and forth.
Maybe I misinterpreted the call to
cvSetData( img
, &view.begin()[0]
, num_channels<View>::value * view.width() * sizeof( channel_t ));
Post by Christian Henning
Can you get access to the image buffer, scanline length, etc?
These should do the trick:
uchar * QImage::bits ()
const uchar * QImage::bits () const
int QImage::bytesPerLine () const
int QImage::depth () const
QImage::Format QImage::format () const
int QImage::height () const
int QImage::width () const

So I can get a pointer to the image buffer. In the case of an ARGB8 image this
pointer can be cast to QRgb* (which is a typedef for unsigned int).

A (class modelling) PixelIteratorConcept should return a (class modelling)
PixelConcept on dereference. unsigned int does not model PixelConcept, so I
suppose I need to create a proxy class that does model PixelConcept...


What I need to implement is this (please correct me if I'm mistaken):

// a pixel in a QImage
// models PixelConcept
template<QImage::Format Format> struct qimage_pixel {
// ...
}

// iterate over the pixels of a QImage
// models PixelIterator/MutablePixelIterator
template<QImage::Format Format> struct qimage_pixel_iterator;
template<QImage::Format Format> struct qimage_const_pixel_iterator;

// for every member of QImage::Format:
template<QImage::Format Format>
type_from_x_iterator<qimage_pixel_iterator<Format> >::view_t
qimage_view(const QImage& image) {
return interleaved_view(
image.width(),
image.height(),
qimage_iterator<Format>(image.bits()),
image.bytesPerLine()
);
}

// specialize some traits classes (const_iterator_type, channel_type,
// color_space_type, ...) for qimage_pixel and qimage_pixel_iterator
Loading...