Tomas Van Verrewegen
2009-02-21 19:54:54 UTC
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?
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?