Re: [boost] GIL Review

From: Matt Gruenke (mgruenke_at_[hidden])
Date: 2006-11-01 02:02:25

Joel de Guzman wrote:

>Matt Gruenke wrote:
>  
>
>>The classical definition of color space is not concerned with data 
>>layout (i.e. channel ordering).  In many cases, the channel names in 
>>common use are heavily overloaded, and are therefore quite inadequate 
>>for specifying a color space.
>>    
>>
>
>I disagree. A color space is a tuple of numbers. It is concerned with
>data and layout as far as I can see. That is the very definition of
>"tuple".
>  
>

That's a color (or pixel value).

A color space provides the semantics of these numbers, possibly 
including how they are converted to other color spaces.  This may 
include its basis, CIE primaries, transfer function, gamut, etc.  (For 
more information, here's a good starting point: 
http://www.poynton.com/notes/colour_and_gamma/ColorFAQ.html )

A pixel format establishes the mapping between channels of an image 
(i.e. color, pixel value, etc.) and components of a color space.

>Years of experience has taught me that gratuitous invention of
>new terms is not a good thing.
>  
>

Yes, and I think the distinction between color space and pixel format 
not only isn't gratuitous - it's quite well justified.

>>>"Color Space" *IS* known terminology. That's my point.
>>> 
>>>      
>>>
>>"known" and "accurate" are distinct criteria.
>>    
>>
>
>I agree. And to me "pixel-format" is unknown, confusing and inaccurate.
>The worst of the worst. It's like calling a std::vector a data-container
>just because the std::vector does not quite follow the "classical" term
>of vector. Let's not be too pedantic.
>  
>

I'm not sure that's a good analogy.  In what ways are you suggesting 
vector an inaccurate description of that container?

Matt