Hi Lubomir, I will have a look on what you said, but I have found a temporarly solution: I am using gray views to store each components of my exr image... I need to do so because in exr, you can have an arbitrary number of channels, each one having a different kind of pixel and / or dimension ! That is why I thought it is better to use views... Now it is working on my project, I will try to make a io extension for gil, but I am running out of time. I'll try because this is not so difficult (true only with exr, dpx is very difficult). Thank you for all and happy new year ! Eloi. 2009/12/28 Lubomir Bourdev

Hi Eloi,

Think of GIL as a collection of concepts and models. The most general concepts support heterogeneous planar pixels (which means that GIL algorithms should work with them), but there are no existing models that provide implementation.

Even though GIL has a model for pixel value whose channels are of different types, those types can only differ in bit depth. What you want is each channel to be completely different - float, uint8, etc. So we need a new model of pixel value, which shouldn't be too hard to do if you start with an existing model.

Once you implement the new pixel value, there are several ways to proceed further depending on what functionality you want. The simplest way, if performance is not critical and if you require read-only model, is to create a new virtual image view that returns the new pixel value upon dereferencing. See the Mandelbrot example in the tutorial. All you need for this to work is to provide a function object that given (x,y) image coordinates, creates and returns your pixel value.

If you want your heterogeneous planar view to be writable, you will also need to provide a model for a heterogeneous planar pixel reference that goes with the new pixel value model I mentioned above and return that from your virtual image pixel accessor. Again you can look at the several pixel reference proxy models that GIL comes with.

If recomputing memory coordinates from (x,y) on every pixel access is too slow, you will also have to provide a custom pixel iterator and pixel locator that support heterogeneous planar pixels. See the design of custom pixel iterators and locators that come with GIL and the code examples. This will allow for a "native" GIL implementation of heterogeneous planar pixels.

Lubomir

...

-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of Christian Henning Sent: Monday, December 21, 2009 9:23 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] [GIL] planar view with different bit depth

Hi Eloi,

I have never tried that and I'm not sure if gil is designed to support such a functionality. Would be cool if you could define such a pixels type with a tuple ( mpl::vector4< uint32_t,double32_t,double16_t,uint8_t> ).

But you might be able to create packed_channel_reference types for each channel. But first you need to provide a 90bits integer type.

packed_channel_reference< uint90_t, 0, 32, 1 > packed_channel_reference< uint90_t,32, 32, 1 > packed_channel_reference< uint90_t,64, 16, 1 > packed_channel_reference< uint90_t,80, 8, 1 >

Such channels you could combine into a pixel type.

Mhmm, the more I think about it the more I have doubts. Hopefully Lubomir has better ideas. Such funtionality should be part of gil 3.0?

BTW, would you be interested in creating a exr io extension for gil? I can help you out.

Regards, Christian

On Mon, Dec 21, 2009 at 11:55 AM, Eloi Du Bois wrote:

...

Hi all,

I have a question. I am using gil to read exr image files (movie standard) and I would like to know can I make a planar view with n channels of different pixel bit depth... That sound weird but the exr standard allow users to put channels of different types ! For example: R = unsigned int 32 G = half float B = float A = byte

Thank you, Eloi.

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

---

Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users