Сложить 2 QColor

[Igors]

2m_ax Пусть напр с1.alpha != 0, с2.alpha == 0. Тогда результат должен быть равен с1 (полностью прозрачное изображение ничего не меняет). А у Вас x != 0, значит с2.red (green, blue) что-то вносят в результат. А альфу Вы чего-то вообще осреднили, это не есть аддитивный эффект/сложение.

- (bug) Вы подрезаете альфу ДО деления на нее, а надо после. Напр я складываю белый + черный. Если обе альфы = 255, должен получиться серый

Это спорно. Возможно это баг именно в вашей модели.

Не спорно, а я ошибся. Белый + черный = белый, ведь мы хотим сумму. У Вас правильно, беру свои слова взад 

Теперь немного о другом. Не кажется ли Вам, что что-то идет не так? Вроде и формулка простейшая, а реализация чего-то развесистая, да еще и скрытая подлянка с производительностью. Если рассматривать более сложные операции (где участвуют 3-4 цвета), то это станет невыносимо. В чем причина?

[Bepec]

Причина в том же, в чем причина работы с музыкой - специфика. И без опыта и использования выверенных формул и алгоритмов нужно доходить до желанного результата самому очень долго

[m_ax]

Теперь немного о другом. Не кажется ли Вам, что что-то идет не так? Вроде и формулка простейшая, а реализация чего-то развесистая, да еще и скрытая подлянка с производительностью. Если рассматривать более сложные операции (где участвуют 3-4 цвета), то это станет невыносимо. В чем причина?

Да причина проста, об этом уже тож много говорили.. Конечный результат (вернее его качество) будет напрямую зависеть от постановки задачи.. Если задача плохо поставлена, или вообще не поставлена (корректно) то львиная часть времени будет просто в пустую утекать на её доопределения и выяснения что же всё-таки хотел постановщик этой задачи) Что, кстатии, весьма часто и происходит... за примерами далеко ходить не надо)

Это во-первых..
А во-вторых есть ещё такой момент который, пожалуй, является следствием первого: решения, направленные (и сформулированные) на написание костылей, дабы залатать дыры изначально нелепой архитектуры, как правило, и вызывают ту невыносимость и отторжение)  


Есть такая шутка у теоретиков: если вы не можете объяснить вашу теорию доступно своей жене, то это теория скорее всего неправильная)

[Igors]

Конечный результат (вернее его качество) будет напрямую зависеть от постановки задачи..

Помилуйте, какая "задача/постановка"? Вам что, неизвестно что такое альфа-канал?

visible_red = color.red * color.alpha    // premultiply - видимый красный цвет
result.red = visible_red / result.alpha;  // un-premultiply - обратная операция, видимый в Red с учетом альфы

Вот и все   Но я хотел поговорить не об этом. Чисто с точки зрения техники программирования - удачна ли реализация оператора + для класса QColor? Да, она корректна в том смысле что дает нужный результат, но хорошее ли это "архитектурное" решение? Мне кажется что нет, а Вы как думаете?

[Old]

Чисто с точки зрения техники программирования - удачна ли реализация оператора + для класса QColor? Да, она корректна в том смысле что дает нужный результат, но хорошее ли это "архитектурное" решение? Мне кажется что нет, а Вы как думаете?

Еще раз, мы что обсуждаем "технику" или "архитектуру"?

Это как спросить: А как вам, с точки зрения архитектуры, шипы на балконных ограждениях? Издали смотрятся  очень эффектно, а вот перелазить - больно.

[Bepec]

Уже традиция Igors - задача без поставленной цели.

Сделайте мне ээ.. машину...

Сделали. А почему она трехколёсная, надо ж было на антигравитационной тяге.

Сделали. А почему у неё нет багажника на 15 тонн?

Сделали. А почему она не вписывается в дизайн и стилистику 90-х годов?

Сделали. А почему в ней используются новые НА-НА-технологии?

Сделали на дровах. Она же убивает окружающую среду - деревья рубим и дымим - а не пошёл бы ты, заказчик в баню

PS После этого тема хиреет и умирает

[Igors]

Еще раз, мы что обсуждаем "технику" или "архитектуру"?

Обсуждаем насколько хорош (или плох) оператор + для QColor. К чему это отнести - технике или архитектуре - на Ваш вкус.

Сделайте мне ээ.. машину...
Сделали. А почему она трехколёсная, надо ж было ..
...

Так ведь именно так все и происходит в реальной задаче

[Old]

Обсуждаем насколько хорош (или плох) оператор + для QColor. К чему это отнести - технике или архитектуре - на Ваш вкус.

Хорошо, намекну по другому. Скажите, а метод push_back в std::vector он плох или хорошо?

[Igors]

Хорошо, намекну по другому. Скажите, а метод push_back в std::vector он плох или хорошо?

"Мне сказали сложить 2 QColor по такой-то формуле - я сделал. (какие претензии?)". Конечно никаких, но помнится Вы можете быть куда более активны в плане постановки, напр

Да, но таково условие задачи

Это условие вытекает из плохого знания предмета топикстартером. В такой многозадачности просто нет смысла.

Поэтому я и ожидал Вашей уничтожающей критики 

[Old]

"Мне сказали сложить 2 QColor по такой-то формуле - я сделал. (какие претензии?)".

Намек понят не был, ну да ладно...

Все зависит от контекста его использования (оператора+): для эпизодического сложения двух цветов - он хорош, для складывания массива цветов на время - плох.
Как, в прочем, и все в программирование.

[Igors]

Все зависит от контекста его использования (оператора+): для эпизодического сложения двух цветов - он хорош, для складывания массива цветов на время - плох.
Как, в прочем, и все в программирование.

Такая "диалектика" вполне уместна, но что-то уж очень "вообще"   QColor - прекрасный класс для перегонки из одной модели в другую, но для арифметики цветов он совершенно непригоден. Углубимся в детали

Код

C++ (Qt)
qreal QColor::red( void ) const;
 

Все строго по книжке - полная инкапсуляция, пользователь не знает (и не должен знать) откуда берется red. Но всегда ли это "так уж хорошо"? Вовсе нет. Довольно редко нужна именно красная компонента, подавляющее большинство операций применяются однообразно ко всем 3 цветам. И аксессоры путаются под ногами, раздувая текст "зато" делая его менее понятным. Вторая проблема еще более неприятна. Сделав red виртуальным (по сути) мы теперь должны "хавать что дают" и не можем дать никаких гарантий производительности.

Если исходные данные хранятся в QColor, то лучшее что мы можем сделать - это вылить его в какую-то промежуточную структуру (на худой конец float[4]), там все посчитать и залить обратно. Поэтому если нужна арифметика цветов, то лучше использовать свой класс, напр такой

Код

C++ (Qt)
template <class T>
struct ARGB {
 T a, rgb[3];
};

Обычно увидев такое "знатоки" начинают воротить нос Однако попробуйте сделать тот же оператор + и, возможно, Вы будете удивлены как прекрасно все получается. И проблем с обрезкой никаких. Видимо сложность/трудность только в том что надо сделать что-то свое (пусть на копейку) - а вдруг это окажется  "позорным велосипедом"? 

При желании конечно можно сделать все private и "накрутить песики" get/set, потом "зафрендить" оператоы/ф-ции. Но я в упор не вижу зачем такой фигней заниматься. Да, я читал эти книги, и даже помню категорическое "никаких исключений!" в одной из них. Но я так не считаю 

[Bepec]

Эммм... Вам не кажется, что вы только что описали qRgb классик? И к чему эта тафтология, если всё равно ваш "оператор", который вы не привели будет рассчитан на узкий спектр задач?

[Old]

QColor - прекрасный класс для перегонки из одной модели в другую, но для арифметики цветов он совершенно непригоден.

Точно, именно на это я намекал. Ну и его никто не навязывает для этой арифметики, как и никто не заставляеттак хранить картинки - QVector<QColor>.

[m_ax]

Эммм... Вам не кажется, что вы только что описали qRgb классик? И к чему эта тафтология, если всё равно ваш "оператор", который вы не привели будет рассчитан на узкий спектр задач?

QRgb - это не классик.. это просто псевдоним на unsigned int

[Bepec]

та я знаю Там как раз и будет гениальная простота работы, как и хочет Igors - без интерфейсов и прочего.