Matt Gruenke wrote:
Joel de Guzman wrote:
Matt Gruenke wrote:
Joel de Guzman wrote:
I think inventing new terminology is better than overloading or hijacking existing terminology. Furthermore, I believe good names accurately describe the concepts to which they refer. Finally, as a user, seeing an unfamiliar term will either prompt me to investigate it - or at least to treat it as an unknown, and therefore with appropriate caution.
I see no overloading or hijacking.
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".
Data format and pixel semantics are orthogonal concepts. A primary goal of GIL is to separate these concepts. IMO, the names used in GIL should reflect this.
I agree. That is why I support the idea that color spaces as tuples where the algorithms are separated from the containers. IOTW, color spaces are separate from color-space algorithms.
That's not my point. Take a look at all the existing libraries that use concepts. Pick one; Vigra seems popular.
As far as I can tell, GIL does not seek to be only as good as other libraries, in what it does - nor should it. In fact, its main objective seems to be to take a principled approach to the problem of image representation, access, and conversion and, in so doing, to provide a better foundation for imaging libraries and applications than existing solutions. Otherwise, why bother?
Years of programming experience have taught me that semantics matter. Clouded semantics limit extensibility and cause confusion, bugs, and redundancy. (Ambiguity should be deliberate, and carefully bounded.)
Years of experience has taught me that gratuitous invention of new terms is not a good thing.
"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. ( Clearly, this is getting to be a bicycle-shed, so I'll just let it be and let the authors do what they think is best. of all things I do not like are naming games. ) Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net