"can't tell apart" isn't a transitive relation. That is, just because I can't tell A from B and I can't tell B from C doesn't mean I can't tell A from C.
“Has the same name as”, however, is a transitive relation.
So, if no two indistinguishable colors have distinct names, and for every pair of colors have a path between them of colors such that adjacent colors in the path are indistinguishable, then all colors would have the same name.
Even if you associate each color with a set of names, if the graph where vertices are colors and edges are “these colors are indistinguishable” is connected, and any two indistinguishable colors have the same set of names, then all colors would have the same set of names.
The solution of “assign a degree of applicability if each name to each color” and allow a color name to have different levels of applicability for a pair of indistinguishable colors, sorta solves the problem?
But, in a sense, isn’t “to what degree do each of these names apply to this color” just a kind of identifier like a name is? (Though it has the advantage that we can talk about the identifiers being very close to each other )
We can’t have identifiers for colors always be the same iff the colors are indistinguishable, because “is the same” is transitive while “is visually indistinguishable” is not.
Therefore, in order to be able to describe a large variety of colors (with say, rgb), we choose to use an identifying scheme (such as rgb) which has different identifiers for colors which are visually indistinguishable.
Your suggestion was that if two colors are indistinguishable, they should have that name.
But given any two colors A and B you can construct a sequence C1 = A, C2, C3, ..., Cn = B where adjacent colors Ci and Ci+1 are indistinguishable from each other, and so need the same name, for 1 <= i < n. Hence, A and B have to have the same name.
The problem with your argument is that indistinguishable doesn't mean the equal. I'm not saying there is no difference between adjacent colors. I'm saying that the difference is indistinguishable. A lot of indistinguishable differences add to a distinguishable difference.
Think about it with numbers: if your sequence A, B, C... are each zero units apart, then yes, A = B = C = ...
In actuality, though, they are not zero units apart. They are a small, but positive distance apart. Those tiny differences add up so the distance from A to C is twice as far as the distance from A to B.
Let's do an example, using just colors with no red or green in their RGB representation so we just have to give the B component, which is a decimal from from 0 to 255. Let's call 0 "black".
Your suggestion was that if a color is close enough to another to be indistinguishable it the two should have the same name.
1 is close enough to 0, so gets the name "black" too.
How about 2? That's farther from 0 "black". Is it distinguishable? If not, it too is "black", and we can go on to compare 3 and 0, and beyond.
At some point we get our lowest blue-only RGB color that is distinguishable from 0 "black". Suppose that is 4. So we have 0, 1, 2, and 3 are all called "black", and since 4 is distinguishable from 0 it needs a new name, say "very light blue".
But now we have 3 "black" only 1 away from 4 "very light blue". Those are probably indistinguishable, so are supposed to have the same name. Oops.
Having more than one name doesn’t change the story, and neither does some colors having no name at all. For each pair of adjacent colors which is indistinguishable to most people, and the two colors must either have the same name (the two sets of names are equal) or different names (the two sets of names have no intersection).
Hah, I love it! There's a lot to dislike about HN and the culture here, but questions like these that sort of make me go "Well obviously not, because ... erm" are quite common and always interesting.
What does 'telling a color apart' even mean? I did a mini project some time ago, where I basically did some custom color quantization (it was to reduce an image into a configurable amount of discrete colors, to make a pixel quilt with a manageable amount of distinct fabric colors). So I used CieLAB colors to calculate the 'visual distance' between the available colors and then recursively merged colors until I got to the desired amount. But even a simple algorithm like that, it turned out, could be implemented in several way; each of which gave different, yet equally 'valid' results.
My point being - it's very hard to give a simple, unambiguous meaning to seemingly simple concepts like 'what is a color', 'when are colors the same' and 'are these two colors more similar than those other two'. There is a lot of abstraction between the physics of light and representations of color e.g. on a screen, or in fabric, or when printing.
I think in the case of telling two colors apart, it's can be as simple as presenting them side by side, and seeing if someone can distinguish a difference.
First, because if I recursively apply your argument, then no color would have a name. Starting from the very 1st lowest color frequency and the 2nd right next to it, no-one could differentiate them. Apply the same logic between the 2nd and the 3rd, the 3rd and the 4th, etc.
So you cannot apply this argument to "any" color pair. You would have to define a set of starting colors, and always do the comparison against them. Now you enter the problem of which starting colors to starts, and the fact that using any pre-existing color names would most likely not be evenly distributed on the color spectrum.
Second, it wouldn't work because color recognition is not a transitive process.
- If you show me two very close red variations side by side, I may not be able to tell the difference.
- If you space the variation, I may be able to tell that there are 2 different reds, but wouldn't be able to tell which one is darker/lighter accurately.
- If instead of showing me the two close reds side by side, you show them to me paired with an other color, I may be able to tell the difference. For instance, show me a board with half red1 + yellow, and an other board with red2 + yellow. I may spot than 1 of the red + yellow is matching that good compared to the other one.
That's interesting. So what you have is some sort of similarity metric that is colour based. You could define it as being 1 for an exact match, and 0 for not matching, so cyan, etc. would be 0 red, while orange may be slightly red (e.g. 0.1), and pink may be slightly more red (e.g. 0.25). This would be a 3D function/surface.
This would allow you to model classes of colours, like purples. Shades of a colour could then be any similar colour in the range 0 to 0.5 (or 0.25).
Yes, this is what Delta E in the CIELAB color space is meant for. But in RGB color space this concept doesn't make sense; well, only if you would accept a non linear similarity metric - but then what is the metric for, if you need to apply a curve to it to normalize it? But still, this is different from modeling 'shades' of a color (if we say 'shades' are varying brightness in RGB space using the 0.21/0.72/0.7 brightness conversion - but again, I argue that 'shades' is an ambiguous concept).
My point is, again, that colors are a much more difficult concept than some in this discussion are making it out to be, and 'distance between colors' is more complex still.
Yep, in fact, that’s exactly what those hex codes are: a specification for how much red, how much green, and how much blue is in the color (though our vision and color perception may not map linearly to that specification).
That restricts you to 8 bits per color channel, and more importantly, to the RGB color space which is non linear. Comparing colors in RGB color space is nonsense in the first place ('comparing' here is 'judge by human perception'). 'Comparing' colors is just not that easy; in fact, I'd argue that without (much) more definition and clarification, it's impossible to do, because it can mean different things depending on the purpose.
