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?
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/...
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
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? _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Thanks for the swift reply, Christian.
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. from the GIL design guide:
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 image dimensions, number of bytes per row, and a pointer to the first pixel: template <typename Iterator> image_view<...> interleaved_view(ptrdiff_t width, ptrdiff_t height, Iterator pixels, ptrdiff_t rowsize);
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.
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
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 ));
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
participants (2)
-
Christian Henning -
Tomas Van Verrewegen