Есть картинка, на ней есть область, залитая красно-бордовым градиентом.
Беру цвет нескольких красных пикселей:
0x942518 0x924D46 0x942518 0x824D46.
Числа естественно получаются разные, но все эти точки красного оттенка. Глазами я это конечно вижу. Но нужно это как-то запрограммировать. Грубо говоря, нужно написать метод
boolean isRed(int color)
или даже по другому
byte compareColor(int currentColor, int pattern1, int pattern2) 
сравнить цвет, и определит, к каком образцу он ближе. Т.е. сравниваем пурпурный с красным и зеленым, и получаем 1, т.к. пурпурынй ближе к красному, чем к зеленому.
Или сравнить цвет с образцом с каким-то коэффициентом "похожести":
boolean isColorsSimilar(int currentColor, int baseColor, int accuracy), где accuracy - необходимая точность сравнения.
Как сравнивать цвета? 
Интересует не какое-то готовое решение, а именно сам принцип сравнения.






Это сообщение отредактировал(а) Temdegon - 19.2.2011, 21:02

Кажется, можно отдельно посчитать разницу каждого спектра. Если эта разница выше установленного лимита хотя бы в одном спектре - вернуть false.

Например:
красный эталон - FF 00 00
на входе для сравнения: EF 00 00
лимит "похожести": A0

Вот и делаем:

придумал только что, если неправильно - пожалуйста, сильно не пинайте

Мне тоже очень интересно. Но при чем здесь Java? Вопрос явно просится в Алгоритмы

Temdegon, если нужен сам принцип сравнения - то почему не взять обычное расстояние между векторами из трех компонент (R,G,B-компоненты)? Позволит как напрямую сравнивать близость цветов между собой, так и ввести порог по похожести.

Если задача на самом деле стоит не так, как она описана - то опишите задачу нормально. Ибо и для задачи квантования палитры (чтобы картинку представить меньшим числом цветов), и для задачи сегментации изображения, и для других задач, основанных на объединении цветов или пикселов в наборы, хороших (точных, быстрых и т.д.) методов разработано много. Тогда, действительно, тема плачет по разделу "алгоритмы".