It seems pretty much everyone tried their hands at designing a colorspace. One such example—essentially forgotten today—is Xerox’s YES colorspace. I am not sure what problem this colorspace tries to solve:
The first line, yielding Y, gives something close to the brightness, but it differs from most other colorspaces that will use 0.299, 0.587, and 0.114 to compute brightness. Are Xerox YES’ values gamma corrected? Or relative to some other space than RGB?
Can’t say. There are very few references to this colorspace, and all points to a 1989 memo I couldn’t find . The inverse
isn’t especially friendly to integer computation.
I think a colorspace must have at least one of these characteristics to be useful:
- match the human visual system’s sensibility to brightness, color, and saturation,
- be perfectly reversible for lossless compression,
- be smooth in its components.
Matching the human visual system’s sensibility is useful for quantization because you know we’re very sensitive to brightness, but much less to color (hue, tint) and saturation. JPEG and TV make very much use of that—more on this later.
Reversibility is of course useful for lossless compression because you want to retrieve the original image bit by bit. While lossless compression isn’t always useful, you may want it in special applications (medical imaging, for example) or for special types of images.
The last criterion is also important for compression. For compression, you want the components to be as correlated as possible because, pretty much for every encoding scheme, it also means fewer bits. If you use simple differential encoding, the differences are smaller and distributed around zero… and that’s good for compression. If you use something like the DCT or wavelets, what also means most coefficients are small, and that’s also good for compression.
If your colorspace doesn’t have any of these properties, then it may not be that good.
 Xerox Color Encoding Standard, (tech rep?) XNSS 289005 (1989?)