Re: [boost] Interest in color library.

From: Kevin Wheatley (hxpro_at_[hidden])
Date: 2005-09-19 04:10:19

Adam Badura wrote:
> 
> > like RGBA 8:8:8:8 or YUV 4:2:2, etc...
> 
>     What "etc.."? I need to know such things... :) Or do you have any
> sugestions for a "general foramt specification"?

you need to separate out the concepts:

numerical representation; integer, floating point, fixed point,
signed/unsigned variations
range of representation; 1/8/10/12/15/16 bit integer, 16/32/64 bit
floats
encoding/transfer characteristics; gamma corrected, log encoded,
linear, relative/absolute values
storage format; packed/unpacked, interleaved/planar, strided/unstrided
dimensionality; 1D, 2D, 3D, 6D (and other printer ink counts), 31 and
other spectral data

What is the meaning of the composition/separation of the separate data
channels

As indicated above, the sampling of the multiple channels can be
variable between channels, reconstructing regular spacing needs
filters these need to work across similar dimensions as the data,
probably have a functor syle interface. this then needs the spacial
arangement to be navigatable in a multi-dimensional manner (N-D
segmented iterators?)

Type conversion is an interesting property, what does it mean to do
add RGB(0.5, 0.5, 0.5) to YUV(0.5,0,0)

Are they different to each other? Is YUV == Y'CbCr, does RGB (sRGB) ==
RGB (Adobe RGB).

Pesonally I'd like strict typing so that if I assign Adobe RGB to sRGB
I get an error, also the equality test should also fail, to me they
are totally different, in particular Adobe RGB colour space is a
'larger type'.

You may find it difficult to separate the colour aspects from what it
is to be an image, especially in the video style representations.

Colour manipulations should not be constrained to 0.0-1.0 no matter
what the underlying representation. (see for instance www.openexr.org,
ITU-R BT.709, etc)

How do you handle conversion from one bit depth to another - you may
need a policy/trait to cover rounding, bit depth extension 

e.g.

valueIn12Bit = (valueIn8Bit * (pow(2, 12) -1)) / (pow(2, 8) -1)

valueIn12Bit = (valueIn8Bit / (pow(2, 8) -1)) * (pow(2, 12) -1)

valueIn12Bit = (valueIn8Bit << (12 - 8)) | (valueIn8Bit >> (12 - 8))

valueIn12Bit = (valueIn8Bit << (12 - 8))

But what about the intermediate values... should it really be

valueIn12Bit = static_cast<typeFor12Bit>(double(valueIn8Bit * (pow(2,
12) -1)) / (pow(2, 8) -1))

or 

valueIn12Bit = static_cast<typeFor12Bit>((double(valueIn8Bit * (pow(2,
12) -1)) / (pow(2, 8) -1)) + 0.5)

Quite common assumptions are to convert everything to float and work
like that until going to an external interface.

All of this is not trivial and this is before you consider ICC or
similar.

I suggest trying to constrain yourself to one or two uses first and
see what can be generalised/simplified, otherwise it may take some
time...

Kevin

-- 
| Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this      |
| Senior Technology                     | My employer for certain |
| And Network Systems Architect         | Not even myself         |