Boost logo

Boost :

Subject: Re: [boost] [gil] IMC4 Pixel format
From: Christian Henning (chhenning_at_[hidden])
Date: 2013-03-14 11:59:28

On Thu, Mar 14, 2013 at 11:43 AM, Harg Tholan <hargtholan_at_[hidden]> 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,
> here<>you 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!


Boost list run by bdawes at, gregod at, cpdaniel at, john at