Thanks Chris for your prompt response. I can certainly create the YUV color space first, basing myself on those examples from the toolbox. Once that it is done, we are ready to define the pixel formats afore mentioned... at least for the IMC4. If you want to take a look already, herehttp://www.fourcc.org/images/imc2.gifyou have an example of how an image with a sub-sampled pixel format would look like in memory. The core idea is that different channels have different resolution! he idea is that the value of the channel 'U' is the same for the pixels @(0, 0) , @(0, 1), @(1, 0), @(1, 1). Same applies to the value of the channel 'V', but for the channel 'Y', they can hold different values. So iterating through pixels, we have to iterate through channels at different 'speed' for they don't have the same resolution. Thanks a lot Chris for your valuable help! H4rg 2013/3/14 Christian Henning

Hi,

thanks for you interest in boost::gil!

On Thu, Mar 14, 2013 at 10:48 AM, Harg Tholan wrote:

...

Hey,

I've been trying to find a definition for the IMC4http://www.fourcc.org/yuv.php#IMC4pixel format for GIL with no success, not even anything similar (planar pixel formats in which some of the channels are sub-sampled).

There are some color spaces in the toolbox, like xyz, lab, hsl, hsv, etc. Not sure if any of those can help you out. The toolbox has been added to boost trunk and should be released either with the next release or the following one.

Could you give me some insight in how a yuv pixel could be defined? Like what are the bit sizes for each channel, for instance.

...

I've spent many hours already trying to figure out how could I create

such

...

pixel format, and I am totally lost...

I'm sorry to hear that. I'm here to help but I have to concede that I'm not an expert in your field. So it could mutually benefiting. ;-)

...

The question is how can I specify that a pixel format is planar, and

planes

...

have different sizes due to sub-sampling!....I guess I'll have to override some operator[] operator++, operator-- Or to make a specialization of some classes.

But how and where? planar_pixel_iterator? channel_iterator? I need some aid! please!

Let's start at the beginning, like defining the pixel time. I can help and spell your code into gil code if necessary.

Regards, Christian

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On Thu, Mar 14, 2013 at 11:43 AM, Harg Tholan wrote:

I can certainly create the YUV color space first, basing myself on those examples from the toolbox. Once that it is done, we are ready to define the pixel formats afore mentioned... at least for the IMC4.

If you need any help doing that let me know! It think such color space would be a great addition to the toolbox.

If you want to take a look already, herehttp://www.fourcc.org/images/imc2.gifyou have an example of how an image with a sub-sampled pixel format would look like in memory. The core idea is that different channels have different resolution! he idea is that the value of the channel 'U' is the same for the pixels @(0, 0) , @(0, 1), @(1, 0), @(1, 1). Same applies to the value of the channel 'V', but for the channel 'Y', they can hold different values.

So iterating through pixels, we have to iterate through channels at different 'speed' for they don't have the same resolution.

Ok, I think I'm getting it. It might be that we have to create a new image type for your use case. Such image type would have 3 different planes ( images ) with different resolutions. Then we create a dereference functor which would access the correct pixels. Once, I have created a new image type for palletted images. Here you have two images inside and the access method is obviously different than to normal image types. This is just the first idea I have and there might be a better way to accomplish your task. But at least, we have a starting point! Christian