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 <tomasvanverrewegen@telenet.be> wrote:
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<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
participants (2)
-
Christian Henning -
Tomas Van Verrewegen