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
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:
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk