You probably want something like CIELAB which is (quoting from Wikipedia) "designed so that the same amount of numerical change... corresponds to roughly the same amount of visually perceived change."
0: https://godsnotwheregodsnot.blogspot.com/2011/09/weighted-eu...
The conversion between RGB and CIELAB is almost meaningless (according to wikipedia) or perhaps there is a still a way to do that and helpful?
1. https://en.wikipedia.org/wiki/Color_space#Absolute_color_spa... : However, in general, converting between two non-absolute color spaces (for example, RGB to CMYK) or between absolute and non-absolute color spaces (for example, RGB to Lab*) is almost a meaningless concept.
As I understand it, that line is really talking about coming up with formal conversions. That is, some color spaces are effectively not well-enough defined (neither in relation to reality nor to each other) to be scientifically useful.
It's like how you might say converting from length in pixels to centimeters is "meaningless" because there isn't truly a consistent physical relationship between them, but people still get plenty of use out of making such a conversion every day.
> Interesting. Perhaps this information is not available with the images? or are they.
It's rare for images to use these colorspaces or gamuts. They are complex and cumbersome, and RGB makes for a damn good "pipe wrench" of bluntness and utility. Plus very few developers are aware of how deep color science is, and assume RGB is (pretty close to) the ground truth.
Regarding being reductive though, I think you have to be in this situation. It's a part of a product (not the whole thing) and seems like manual curation could fill in the gaps.
That wouldn't work for products that have poorly chosen color (which aren't rare) but have the right non-dominant color of customer's brand.
it also works both ways, so white elements having a color accent and a dark contrast element still have them recognized for what they are
If you used HSL, you possibly could match on the hue while being more lax on the brightness and saturation—so a pastel-pink color could still match to a red image. Not sure if the database can use different weights for positions in a vector (though with pre-processing S and L could be collapsed to narrower ranges, so they match more freely afterwards). Just need to make sure that white and black aren't matched to random hue values.
Though, I guess if you use only the distance to fixed chosen high-saturation values then it's about the same thing.
Except it seems that with just RGB distance, a semi-saturated cyan or yellow color might be counted as closer to ‘pure green’ than dark-green. Something like (0,255,180) vs (0,70,0).
Also:
> values('(${ color })'
2020 and still no placeholders.
> Just need to make sure that white and black aren't matched to random hue values.
Colors with too small saturation can just be excluded from the search, since gray/white/black go with anything.
Also as others have mentioned RGB space and human perceptible color space is different enough that distance in RGB doesn't equate to difference/similarity between colors
I can't see any client data in the query, so how would anything be injected?
I literally skimmed the article while drinking a coffee.
Nitpick. What's the point of writing a good guide with rich text and images, but showing end result only in video? I have embedded YouTube videos disabled by default, so it's a little embarrassing.
And seeing as you've gone to all the trouble of figuring out how to grab dominant colours from images, why not allow users to upload an image of their logo and grab the dominant colour from that? This could help avoid the problem of having noticably different shades, without making the user do anything technical like searching with an RGB value and a threshold.
CIE76 is not ideal but would let you continue to use CUBE.
You could consider doing a first pass with CIE76 and then sort by something more accurate in a second pass.
https://medium.com/@adamgross_6978/getting-started-with-json...
Another item to consider is also taking into account how the user might search - "red shoes", then classify the query as "color: red" & "shoes".
The next fun challenge is determining which image to display if you have a variant product (color/size combination for clothing for example). Figuring out which product image to show in the result set requires identifying the primary color in the search.
It is nice to look into the source code to see how it is done.
But in my experience it works around 80% of the time because there are so many exceptions.
And there are also other tricks of the trade. But for starters this simple solution might be enough.
This solution also assumes the colors in the images are 'calibrated' and are consistent. This is almost never the case, but may be overlooked in for the given use case.
I am sure it has some drawbacks, like distance on the rgb space may not be the best option, or that it does not ignore background color of it is not transparent, still, I like the way of thinking
Nice to see people still remember problems can be solved with anything else than, ehm, "AI".
It's population specific to the type of people who read xkcd but it's an interesting starting point if you want higher resolution info on, eg: exactly where people draw the line between "green" and "blue".
Raw data is here: http://xkcd.com/color/colorsurvey.tar.gz
