Здравствуйте, Reunion, Вы писали:

R>Здравствуйте, AcidTheProgrammer, Вы писали:

ATP>>Здравствуйте, Reunion, Вы писали:

R>>>Всем привет!

R>>>Есть картинка — из нее берется пиксель (x, y). Есть набор цветов. Надо для пикселя (x, y) найти наиболее похожий для глаза цвет из данного набора.
R>>>В интернете я нашел следующую функцию оценки похожести цветов: f = 30 * (rp — ri) * (rp — ri) + 59 * (gp — gi) * (gp — gi) * 11 * (bp — bi) * (bp — bi), где rp, gp и bp — цвет пикселя, ri, gi и bi — цвет из таблицы цветов. НО это бред! Мы ведь не интенсивность должны сравнивать. Точнее, наверное будет сказать, не только интенсивность!
R>>>Народ, подскажите как быть в данной ситуации.

R>>>Заранее спасибо.

ATP>>Конечно бред. Минимизируя данный функционал мы найдем наиболее подходяций по воспринимаемой яркости.
ATP>>Для цвета из табице будет иметь такой вид:

ATP>>f = sqrt ((rp — ri) * (rp — ri) + (gp — gi) * (gp — gi) + (bp — bi) * (bp — bi))

ATP>>Можно не брать корень.... если нужно быстро.

R>Можно так, но результат все равно тот же. Смотри мой ответ minorlogic'у

И что я там должен посмотреть...?

Бред он и есть бред.... С какой стати для нахождения ближайжего цвета, я должен пользоваться весами для яркочти.

Например если мы ищем для некого зеленого цвета, похожий:

Ясно, что если в палитре есть Красный по яркости не отличающийся от него и зеленый отличающийся на чудь-чудь, твой способ найдет именно красный — что является бредом. Попробуй со своим методом хороший дехеринг написать. Я например написал, и не один, и точно могу сказать, что метрика с весами по яркости хорошо будет работать только для полутоновых изображений.