Russian Qt Forum

Добрый день

Есть простая структура

C++ (Qt)
struct ARGB {
 ...
 float alpha, red, green, blue;
};
 

Как определить операторы для нее? Напр оператор +

C++ (Qt)
friend ARGB operator + ( const ARGB & c1, const ARGB & c2 )
{
 return ARGB(c1.alpha + c2.alpha, c1.red + c2.red, c1.green + c2.green, c1.blue + c2.blue);
}
 

Так вроде глупо, если с2.alpha = 0.0f, то с2.red никак влиять не должен. А тогда как?

Спасибо

Может быть подумать о том, что бы сделать из структуры класс?
для классов же вроде нормально проводится перегрузка операторов?

http://www.cyberforum.ru/cpp-beginners/thread59084.html
http://programmersclub.ru/24/

С синтаксисом проблем нет, я спрашиваю как сделать операторы чтобы они давали разумный/корректный результат. Пример:

C++ (Qt)
ARGB c1, c2;
...
// теперь мне надо получить среднее значение
// хорошо бы записать так
ARGB average = (c1 + c2) * 0.5f;
 

Но что должен делать + ?

Простите тогда меня, но что делает тема с вопросом о принципах работы с цветом в различных цветовых пространствах, в техническом подфоруме "Qt > Общие вопросы" ?!  

кроме того "разумный/корректный результат" - это как?
вы имитируете смешение цветов как будто у вас множество слоев пленочек-цветофильтров? а какая пленочка у вас "выше"/ближе к наблюдателю? свет у вас насквось идет или отраженное освещение?

или вы "проецируете" на белое несколько изображений от нескольких проекторов?
или вы смешиваете краски, разбавленные водой для прозрачности ?

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

 да?

собственно как только вы поймете какой процесс вы хотите имитировать и приведете мысли в порядок - вам будет понятно как поступать с цветами. Вариантов много, важен часто также порядок "сложения цветов". :)

Наверное можно и так сказать, но можно взять и пример поближе к Qt/UI: gradient control, у каждого ключа цвет (RGB) и альфа (A). Как рисовать градиент? В любом случае известны исходные данные (2 или более ARGB) и вес каждого из них. Задача - уметь удобно находить среднее ARGB. Возникает везде где есть альфа канал, поэтому нет смысла рассказывать для чего мне это нужно  :)

многослойные типографские пленочки. та пленочка которая выше, может полностью заместить нижеследующую.
как вариант например так: скажем, если одна красная пленочка red2 лежит поверх red1,  то цвет конечного фильтра из 2-х пленочек - типа "суммарный" цвет наверное будет таким:
red3 = ((1-alpfa2)*red1*alpfa1)+red2*аlpfa2

Суммарная прозрачность 2-х пленочек думаю будет выглядеть так (а-ля сложение верояностей):
alpfa3 = 1-(1-alpfa1)*(1-alpfa2);

аlpfa - коэфф интенсивности замещения предыдущего цвета. 0 - все прозрачно, 1 - цвет полностью замещает предыдущий.

естественно в операции надо добавить ограничения на значения, что бы прозрачность не выходилаза 1 и т.п.

или можно так
http://base.vingrad.ru/view/1512-Gradientnaya-zalivka-i-slozhenie-tsvetov

Давайте приводить мысли в порядок. Альфа - прозрачность - она не "существует сама по себе". она подразумевает цвет на который вы это все накладываете. Что бы по цвету фона, цвецу фильтра и прозрачности фильтра - рассчитать итоговый цвет. Заметьте - у фона - "нет прозрачности"...

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

имхо...


ещё раз давайте более конкретно - к какому процессу вы рисуете алгоритм и что хотите отрисовывать? ))) без понимания того что вы хотите сделать - вы ну никак не сможете понять как вам это сделать. увы)

Простейший случай: есть "ребро" (2 точки) в каждой  из них задан ARGB. Найти (интерполировать) ARGB посередине. Это не имеет никакого отношения к "пленкам" (т.е. комбинациям слоев) - т.к. там результат зависит от порядка следования слоев и поэтому нет смысла делать операторы.

Найти среднее ARGB  я могу так

C++ (Qt)
ARGB AverageARGB( const ARGB & c1, const ARGB & c2 )
{
  ARGB result;
 
// interpolate alpha
  result.a = (c1.a + c2.a) * 0.5f;
 
// interpolate premultiplied colours
  result.r = (c1,r * c1.a + c2.r * c2.a) * 0.5f;
  result.g = (c1,g * c1.a + c2.g * c2.a) * 0.5f;
  result.b = (c1,b * c1.a + c2.b * c2.a) * 0.5f;
 
// clip divider
  float divider = MAX(result.a, 1.0e-4f);
 
// unpremultiply RGB
  result.r /= divider;
  result.g /= divider;
  result.b /= divider;
 
  return result;
}
 

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

Я так понимаю стандартный набор знаний об альфа-канале закончился?  :)

общая формула для микса цветов:

C3 = C1*(1-alpha1) + C2*alpha2,

где С - это R, G или B, или Y, U или V (Y'CbCr, если быть точнее)

С этой формулой явно что-то не так: если alpha1 = 1.0f (максимальная) то выходит C1 никак не роялит?
Но это не имеет отношения к моему вопросу. Да, с помощью альфа мы можем видеть одно изображение "сквозь" другое, т.е. иметь "слои". Как их комбинировать я знаю, а спрашиваю о другом: как (удобно) интерполировать альфа и RGB для точек ОДНОГО слоя. Сожалею что натолкнулся на "барьер мЫшления"  :)

Гм... это как я понимаю вариант "смешения пленочек", когда мы через одну пленку смотри на другую.? хотя выглядит не совсем как мне это кажется верным...


И это не барьер мышления, это нежелание вами внятно и конкретнее на примерах описать конкретно операции которые вы хотите производить. Т.е. возвращаемся в описанному ещё несколько дней назад о необходимости описать процессы которые вы имитируемые.

Пока вы внятно описали только случай "точки на грани двух картинок".  я думал вы сами уже все решили?
что вам мешает брать среднее по каждому из каналов в этом случае?
?

Причем здесь картинки? Есть треугольник, в каждом угле задано ARGB (прочитал из файла). Теперь мне надо разбить треугольник на несколько. Появляются новые точки, для них надо посчитать (интерполировать) новые ARGB используя исходные. Так понятно?

Как сказано в первом посте темы, это очевидно неверно: с1.r никак не может внести 0.5f  в финальный result.r если c1.a = 0.0f

С чего бы ээто вдруг "очевидно"?! )))
совершенно не очевидно ;) особенно в общем случае.
Ещё раз: пока вы не оструктурируютесь и не сможете представить физические процессы, ну или хотя бы модели, которые моделируете - у вас ничего не выйдет. Как минимум потому что для разных процессов будут разные формулы.

Вообще, имхо, вы похоже "как-то не так" понимаете "RGB+прозрачность"...

Прозрачность не меняет цвет, она именно делает его "прозрачным", определяет как его смешивать с подложкой.... Вы же отчего-то предполагаете что альфа-канал может менять ваш цвет фильтра - (" с1.r никак не может внести 0.5f  в финальный result.r если c1.a = 0.0f")

Давайте на пальцах? подумаем так: с точки зрения "прозрачности" - отдельный цвет в сотаве RGB - сам по себе ничто, он кодируют только соотношения между друг другом и положение между черным и белым... с точки зрения Alpha - RGB - это единое целое, которое он делает прозрачным весь сразу, не меняя его цвета... и вот как и сколько там один цвет из смешиваемых вносит - 0.3 или 0.8 - это уже для альфа-канала не важно ...  

по поводу моделей обработки цвета:
Если вам не подходит моделирование "пленочек", то возможно другая модель будет ближе для вашего случая: смоделируйте смешение разбавляемых водой красок. Вода - это как эквивалент альфа-канала. Она (как и альфа-канал) не меняет цвет, она делает его прозрачным. Процент воды в растворе - это альфа-канал. А вот RGB - определяет соотношения в банке с краской, которая не разбавлена. Так для вас понятнее?

Вот представьте что вы смешиваете 2 раствора краски в равных пропорциях : один раствор, в котором 20 процентов воды, с другим раствором, в котором 50 процентов воды и разливаете его на подсвеченным снизу матовом стекле.

первый вопрос - сколько процентов воды будет в конечном растворе? праально - 35.
А сколько процентов краски будет в конечном растворе - праально. 65.
Надо расписывать, что количество краски в конечном растворе будет рассчитываться именно как  
  ?
 
_{PS: (если совсем придираться, оно конечно не совсем удачно - для красок надо применять цветовое простванство CMYK или аналогичное (предназначенное для красок на белом), а мы в RGB остались... но думаю пока это не сильно существенно, тем более что само по себе понятие "прозрачность" , имхо, плохо подходит к пространству RGB которое моделирует смешение света в черном пространстве).. имхо...}

Пардон, ошибся. Надо вот так:

C3 = C1*(1-Alpha) + C2*Alpha,

где
С - это R, G или B, или Y, U или V (Y'CbCr, если быть точнее)
Alpha - это прозрачность накладываемого цвета.

С1 - компоненты пикселя, на который накладывается пиксель с компонентами С2.

Давайте разберемся  :)

Давайте переведем "литры" в ARGB модель. Для красной краски имеем

1-литр  Red = 1.0f, Alpha = 0.8f
2-литр  Red = 1.0f, Alpha = 0.5f
--------------------------
смесь: Red = 1.0f, Alpha = 0.65f

Т.е. предложенная Вами модель никак не учитывает интенсивность самого R(G, B)

Я против этого ничего не имею, но это просто смешивание с весом. Так рисуется напр непрозрачная подложка С1 позади полупрозрачного C2. Но это не подходит для смешивания 2-х компонент у каждого из которых своя альфа

Если я правильно понял, то при сложении двух цветов c1 и c2 их альфа канал должен также складываться, но не выходить за пределы 1.0f

Например, можно так:

C++ (Qt)
    result.r = 0.5 * (c1.r + c2.r);
    result.g = 0.5 * (c1.g + c2.g);
    result.b = 0.5 * (c1.b + c2.b);
    result.alpha = (c1.alpha + c2.alpha > 1.0) ? 1.0f : c1.alpha + c2.alpha;
 

Но мне это не нравится)

Давай посмотрим так.
Есть две точки образующие ребро. Обе одного цвета, скажем красного. Цвет любой точки на этом ребре должен быть красным.
Или такой пример. Две точки, одна белая вторая черная. Для них установили альфу == 0, точки полностью прозрачны. Интерполировали точку по середине ребра. Должна получиться точка серого цвета. После этого устанавливаем альфу для всех трех точек == 1, точки полностью не прозрачны. Рисуем сцену и видим все как нужно, черную-серую-белую точки.
Если использовать твою функцию AverageARGB для точек с альфой == 0, то результирующая точка всегда будет черной. Какая-то это не правильная интерполяция.
IMHO, альфа задает только прозрачность при наложении этой точки на фон, т.е. только при рендеринге.

Да, все верно, если вы считали как
литр1= 800 мл краски  Red=1.0f + 200 мл воды
литр2= 500 мл краски  Red=1.0f + 500 мл воды
смесь: 2литра: 1300 мл краски  Red=1.0f + 700 мл воды
что в пересчете на 1 литр 650 мл краски  Red=1.0f + 350 мл воды

Ну это не моя модель не учитывает, а формула, которая (да, признаю ошибся) справедлива только когда R1=R2 )))).
И частный случай рассмотренный выше.

Для того что бы модель была понятнее, рассмотрим другие случаи:

Предположим, вы хотите получить краску соответсвующую не Red=1.0f , а скажем Red=0.3f,  что делать?
Будьте добры смешать 300 мл Красной краски + 700 мл Черной - тогда вы получите 1 литр темно-красной краски,
т.е. красный значением R=0.3f
Где прозрачность? её нет. Краска не прозрачная.
т.е. (300 мл Красной краски + 700 мл Черной)  = (R=0.3f, Alpha = 1.0f)

Для того что бы получить 1 литр полупрозрачной смесси, скажем ( R=0.3f, Alpha = 0.8f)
возьмите 800 мл не прозрачной смеси, и смешайте его с 200 мл. воды.
т.е. получим 240 мл красной ( 300*0.8 ), 560 черной ( 700*0.8 ), и 200 мл. воды. - это ( R=0.3f Alpha = 0.8f )



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

Там будет и зависимость от интенсивности которую вы так хотите видеть, и ( вроде как) красивая зависимость похожая на расчет вероятностей 2-х событий. А вот прозрачность по прежнему будет рассчитываться по среднему.

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

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

Это просто крайний/граничный случай. Типа "в 1 литре воды НОЛЬ красной краски" (?) Эта ситуация не определена, нельзя говорить что краска красная если нет самой краски. Результат "черный" для этой ситуации единственно возможный.

Альфа канал должен просто осредняться, а не складываться, с этой компонентой все ясно. Пример: есть 2 одинаковых ARGB, результат любой интерполяции должен быть тем же значением (мы не комбинируем слои а интерполируем точки 1-го слоя).

Ну вот, оказывается я дурно влияю на подрастающее поколение  :)  Давайте вместо того чтобы горячиться рассмотрим  простой пример (взвешиваем прямолинейно):

С1:  A = 1.0f,  R = 0.0f, G = 0.0f, B = 0.0f    (видимый RGB = 0.0f, 0.0f, 0.0f)
С2:  A = 0.01f, R = 0.0f, G = 0.0f, B = 1.0f   (видимый RGB = 0.0f, 0.0f, 0.01f)
------------------------
result A = 0.505f, R = 0.0f, G = 0.0f, B = 0.5f   (видимый RGB = 0.0f, 0.0f, 0.25f)

Почему же в результате интерполяции мы увидим куда больше синего чем было в обоих исходных точках? (как в том анекдоте где "ребенок накакал больше собственного веса"?  :) ) Разве это не есть очевидно?

Да я давно все посчитал и привел в своем посте #6 этой темы. Вопрос был по технике C++ (как сделать удобно)

а расскажите анекдот:)

В данной модели отсутствует дистрибутивность.
Та что бинарными операциями не получится объеднить цвета.

Это просто другая формулировка того что прямолинейное использование арифметики (+. * . / ) не проходит для ARGB (в отличие от напр RGB). Но можно действовать и по-другому, напр.

C++ (Qt)
// просто суммируем компоненты
inline ARGB operator + ( const ARGB & c1, const ARGB & c2 )
{
 return ARGB(c1.a + c2.a, c1.r + c2.r, c1.g + c2.g, c1.b + c2.b);
}
 
// умножаем альфу на t, RGB на t * alpha
inline ARGB operator * ( const ARGB & c, float t )
{
 float t2 = c.a * t;
 return ARGB(t2, c.r * t2, c.g * t2, c.b * t2);
}
 
// делим альфу на t, RGB на t * alpha
inline ARGB operator / ( const ARGB & c, float t )
{
 float t2 = MAX(c.a * t, 1.0e-4f);
 return ARGB(c.a / t, c.r / t2, c.g / t2, c.b / t2);
}
 

После этого

C++ (Qt)
ARGB result1 = (c1 + c2) / 2;  // так ничего хорошего не получится ;-)
ARGB result2 = (c1 * 0.5f + c2 * 0.5f) / 1.0f;  // a так ?
ARGB result3 = (c1 * 0.125f + c2 * 0.5f + с3 * 0.375f) / 1.0f;  // или так ?
 

Не уверен что это правильно/элегантно. Критикуем, улучшаем

Так дейсвительно ничего путного не получится.
Нужна либо
- тринарная операция f(C1, C2, IntermediateFactor)
либо
- использовать не ARGB, а свой промежуточный класс.

Это утверждение голословно до тех пор пока Вы не укажете ошибку (я ее пока не вижу).

Не знаю как остальные, но я уже совсем запутался)
Надо внести ясность..
Я мыслю так:
1) любой цвет в представлении ARGB - это точка в 4-пространстве (4-куб с ребром = 1)
2) Если определёна операция "+" для любых двух цветов, то очевидно
    c = a + b - результат тоже точка в этом же 4-кубе
3) Скорее наводящий вопрос:
    a + b = b + a ?
это важно, поскольку отражает суть процесса смешения двух цветов.

4) тож вопрос для уяснения:
Что по Вашей логике должно получиться при сложении следующих цветов:
a)
   с1=с1(1, 0, 0, 1) (A, R, G, B)
   c2 = c2(0.5, 0, 0, 1) (A, R, G, B)
   res1 = c1 + c2 ?
   res2 = c2 + c1 ?
---------------------------------------------
b)
   c1=c1(0.5, 0, 0, 1)
   c2=c2(0.5, 0, 0, 0.5)
   res1 = c1 + c2 ?
   res2 = c2 + c1 ?

 ???
 

Нет. эта аналогия неуместна, т.к. в n-мерном пространстве все измерения "равноправны". А здесь альфа канал специфичен

res1 = res2 = (0.75. 0, 0, 1) (A, R, G, B)

res1 = res2 = (0.5. 0, 0, 0.75) (A, R, G, B)
Ну и как обсуждалось выше, просто + не пройдет, предлагается

res1 = (c1 * 0.5f + c2 * 0.5f) / 1.0f;

И в чём же его специфичность, если операция сложения двух цветов у Вас - просто среднее?

Пройдёт, если определить оператор "+":

C++ (Qt)
inline const ARGB operator+(const ARGB &c1, const ARGB &c2)
{
    ARGB  res;
    res.alpha = 0.5f * (c1.alpha + c2.alpha);
    res.r = 0.5f * (c1.r + c2.r);
    res.g = 0.5f * (c1.g + c2.g);
    res.b = 0.5f * (c1.b + c2.b);
    return res;
}
 

Кстати, а зачем здесь:
нужно делить на единицу? Без деления получится другой результат? ???

Не просто как обсуждалось в посте #18. В частных случаях (как в Ваших примерах где A или RGB одинаковы) просто сложение дает правильный результат, но в общем случае нет

Да. другой, см. оператор деления предложенный в посте #21

Ладненько, тогда следуя Вашей логике, можно оставить только лишь один оператор "+" определённый след. образом:

C++ (Qt)
inline const ARGB operator+(const ARGB &c1, const ARGB &c2)
{
    ARGB  res;
    float x = 0.5f * (1.0 - c1.alpha + c2.alpha);
 
    res.alpha = 0.5f * (c1.alpha + c2.alpha);
    res.r = c1.r * (1.0f - x) + x * c2.r;
    res.g = c1.g * (1.0f - x) + x * c2.g;
    res.b = c1.b * (1.0f - x) + x * c2.b;
    return res;
}
 

Очевидно как получается эта формула?

Немного опечатался: нужно писать

C++ (Qt)
inline const ARGB operator+(const ARGB &c1, const ARGB &c2)
{
    ARGB  res;
    float x = 0.5f * (1.0 - c1.alpha + c2.alpha);
 
    res.alpha = c1.alpha * (1.0f - x) + x * c2.alpha; // <--- вот здесь))
    res.r = c1.r * (1.0f - x) + x * c2.r;
    res.g = c1.g * (1.0f - x) + x * c2.g;
    res.b = c1.b * (1.0f - x) + x * c2.b;
    return res;
}
 

Проверим

С1: (1, 0, 0, 0)   // видимый RGB (0, 0, 0)  
С2: (0.5, 1, 0, 0)  // видимый RGB (0.5, 0, 0)
------------ (x = 0.25)
result:  (0.75, 0.25, 0, 0)  // видимый RGB (0.1875, 0, 0)
Неверно, видимый RGB должен быть (0.25, 0, 0)  

Кроме того, такой оператор дает неверную альфу при сложении 3 или более ARGB, напр
c1 + c2 + c3 + ..

Проверяем

С1: (1, 0, 0, 0)   // видимый RGB (0, 0, 0) 
С2: (0.5, 1, 0, 0)  // видимый RGB (0.5, 0, 0)
------------
result:  (0.875, 0.25, 0, 0)  // видимый RGB (0.21875, 0, 0)
Увы  :'(

А какой результат вы ожидали? Вы смешиваете чёрный с полупрозрачным красным и получаете (видимый) затемнённый (тёмный) красный. Не логично?
 

Вполне, вот только числа неверны  :)
Аналогия с красками. Было 0.5 литра красной краски разведенной в  0.5 литре воды. Добавили 1 литр черной краски.  Общее кол-во краски 1.5/2 = 0.75 (альфа 75%). Цвет краски без воды RGB(0.333(3). 0, 0). Разведенная краска бледнее: 0.3333 * 0.75 = 0.25 (Red)

Объясните, какой смысл в использовании оператора +
Не вдаваясь в формулы сложения двух цветов. Единственно что может иметь смысл это получение некоторой усредненной точки. И это все! При этом стоит заметить, что имея 3 разных точки не лежащих на одной прямой(что является общим случаем) вы получите:
С123 = С1+С2+С3;
С231 = С2+С3+С1;
С132 = С1+С3+С2;

С123 != С231;
С123 != С132;
С231 != С132;

Отсутствует ассоциативность! Какой для вас в этом смысл?

Имеет смысл 3-нарная операция вернее метод F(C1, C2, Mid = 0.5)
Кстати, F(C1, C2, Mid) != F(C2, C1, Mid) в общем случае, но всегда F(C1, C2, 0.5) == F(C2, C1, 0.5)

Для 2-х я бы просто использовал ф-цию - и все дела. Но различные методы разбиения поверхности требуют различных взвешиваний, в общем виде

От 2 до 8 "k". А "value" могут быть (атрибуты точки)

- float числа
- тройки чисел (x, y, z)
- RGB
- ARGB

Я могу сделать напр такую ф-цию
Но пользоваться ей неудобно (надо все время заряжать 2 массива) и в template она не ложится

Неверны относительно модели с вёдрами?))
Замечу, что эта аналогия здесь в данном случае - некорректна. Если альфа - канал у вас нуль, но тем не менее отличны от нуля компоненты RGB то сразу получаем противоречие.

Вот мы и получаем некоторую среднюю точку.

И кстати
не совсем верно. В последнем варианте, что я привёл, аналог Вашего Mid - есть x. И он равен 0.5 только в случае одинаковых прозрачностей у складываемых цветов, тем не менее свойство ассоциативности всегда выполняется:
с1 + с2 = с2 + с1 
 

Я понимаю что не удобно. Но нельзя муху превратить в слона.
Пример я привел выше. Он математически обоснован.

С123 = С1+С2+С3;
С231 = С2+С3+С1;
С132 = С1+С3+С2;

С123 != С231;
С123 != С132;
С231 != С132;

Если они не лежат на оной прямой вы никак не заставите их быть равными, как ни старайтесь.

Но так иамем точку центра тяжести треугольника:
F(F(С1+С2)+С3, 3) == F(F(С2+С3)+С1, 3) == F(F(С1+С3)+С2, 3);

Это Коммутативность, а не Aссоциативность

Aссоциативность:
(x+y)+ z=x+(y+z)

Коммутативность это когда AB=BA
Коммутатор это: [A, B] = AB - BA. Говорят, если A и B коммутируют, то [A, B] = 0
А есть ещё антикоммутатор [A, B]₊=AB+BA. И говорят, если A и B антикоммутируют, то AB + BA = 0

А вот A+B = B+A - это как рас ассоциативность  8)

Не надо путать "Коммутатор операторов" и "коммутативность" !

http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BC%D0%BC%D1%83%D1%82%D0%B0%D1%82%D0%BE%D1%80_%D0%BE%D0%BF%D0%B5%D1%80%D0%B0%D1%82%D0%BE%D1%80%D0%BE%D0%B2

http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BC%D0%BC%D1%83%D1%82%D0%B0%D1%82%D0%B8%D0%B2%D0%BD%D0%B0%D1%8F_%D0%BE%D0%BF%D0%B5%D1%80%D0%B0%D1%86%D0%B8%D1%8F

http://ru.wikipedia.org/wiki/%D0%90%D1%81%D1%81%D0%BE%D1%86%D0%B8%D0%B0%D1%82%D0%B8%D0%B2%D0%BD%D0%B0%D1%8F_%D0%BE%D0%BF%D0%B5%D1%80%D0%B0%D1%86%D0%B8%D1%8F

В операторе предложенном m_ax - согласен, не равны. Но не вижу почему они не равны для операторов предложенных в посте #21. Заметим что каждое слагаемое должно сначала на что-то множиться (premultiply alpha)

А что такого плохого (непристойного  :)) в модели с ведрами? Противоречие уже обсуждалось в посте #18 и любой практический расчет такие противоречия имеет: напр как взвесить если оба веса = 0? Результат ноль независимо от исходных значений,  это нормально и не есть проблема

Согласен)) Извиняйте)

Почему эт не равны? Всегда с1+с2=с2+с1.

А, у вас тут три точки)) Ясненько)

Хорошо, давайте так: Первый вариант, который я привёл:

C++ (Qt)
inline const ARGB operator+(const ARGB &c1, const ARGB &c2)
{
    ARGB  res;
    float x = 0.5f * (1.0f - c1.alpha + c2.alpha);
 
    res.alpha = 0.5f * (c1.alpha + c2.alpha);
    res.r = c1.r * (1.0f - x) + x * c2.r;
    res.g = c1.g * (1.0f - x) + x * c2.g;
    res.b = c1.b * (1.0f - x) + x * c2.b;
    return res;
}
 

Даёт для компонент RGB правильные доли этих цветов, если A = 1. Более того, он даёт правильный ответ для A.
А теперь вопрос: что нужно там изменить, чтоб получилась модель с ведром?

ЗЫ
Я при получении этого соотношения исходил совсем из других соображений. К вёдрам оно отношения не имело)) 

Отсутствует Ассоциативность, а не Коммутативность
С1+С2+С3 != С2+С3+С1
Но поскольку имеем Ассоциативность, то
С1+С2 == C2+C1 =>                               
(С1+С2)+С3 == (C2+C1)+C3 равносильно такой записи С1+С2+С3 == C2+C1+C3

И в чём тогда проблема? Или я чего-то не вкуриваю.. 

К теме "удобства"?
Почему "для удобства" не использовать функцию интерполяции, с предопределенными в ноль значениями аргументов?
Наверняка - более 8 точек (или скажем 10) вы наврятли будете "интерполировать".

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

Вот это неравно!!! С1+С2+С3 != С2+С3+С1
Хотя это равно!!!  С1+С2+С3 == C2+C1+C3

Можно, но ведь коэффициенты тоже надо передать, итого получается 16  :'(
А главное - это не засунуть в template и мне придется городить такую монстр-функцию и для др. типов

Я полагаю (возможно ошибаюсь) что "видимые" цвета (т.е. цвет умноженный на альфа) можно "просто смешивать". Разумеется потом надо "вернуть цвет взад" поделив на альфу. Вопрос в том как технично это оформить

Вот именно что должны множиться. Поэтому операции + и * по отдельности не имеют смысла.
Что у вас и показано в том примере


Мало того это еще и менее эффективно с точки зрения кол-ва вызовов функций(операция это функция).

Вам нужна функция F(C1, C2, K)
Тогда:
сложение 2-х: F(C1, C2, K1)
сложение 3-х: F(F(C1, C2, K1)), C3, K2)
сложение 4-х: F(F(F(C1, C2, K1)), C3, K2), C4, K3)
Или записав подугому:
C12 = F(C1, C2, K1)
C123 = F(C12, C3, K2)
C1234 = F(C123, C4, K3)
сложение N: ...

====================
Как вариан использования для некоторого удобства именно операции +. Можно слегка извратиться и сделать промежуточный класс Pair - Объединяющий цвет и коэффициент

inline ARGB::ARGB operator +  (const Pair  &p) const;

Тогда это:
 F(F(F(C1, C2, K1)), C3, K2), C4, K3)
Будет выглядеть так:

C = С1 + Pair(C2, K1) + Pair(C3, K2) + Pair(C4, K3);

Определите для вашего argb функцию умножения. Подозреваю, будет достаточно умножить на коэффициент ваш альфа-канал.
Даже если нет - определите в своей argb поле вес, с которым будет работать функция умножения.

тогда вызов interpolate описанной как
будет достаточно прозрачен:

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

зачем вам вообще понадобилось использовать "template"?

Ну а C1 что - лучше всех?  :) Я прикидывал так

C++ (Qt)
result = (C1.Mul(k1) + C1.Mul(k2) + ..).Div(k1 + k2 + ..);
 

Но сопля все равно длинная  :)

Так и сделал (пост #21)

Перечислил в посте #34

Можно пойти несколько дальше

inline ARGB ARGB::operator +  (const Pair  &p) const;
inline ARGB ARGB::operator +  (const ARGB  &c) const; {return *this + Pair(c, 0.5);}
inline Pair  ARGB::operator *  (float  k) const; {return Pair(*this, k);}
Тогда будем иметь, например:

C = С0  + С1 + C2*K1 + C3*K2 + C4*K3;

С0  + С1 <==> С0  + С1*0.5

В предыдущем моем посте


Естественно, поскольку коэффициентов на 1 меньше чем цветов.

Я кажется понял что имелось ввиду.

k1, k2, ..., kn - это веса

Эту схему тоже можно привести к
result = C1*k1 + C2*k2 + ... + Cn*kn; :)
если где-то множитель k отсутствует, то считается равным 1.

Причем вычисление будет осуществлятся в последний момент!
Операциии "+" и "*" делают накопление данных - Цепочка вложенных Pair.
Это необходимо для вычисления (k1 + k2 + ... + kn).
А при присвоении уже делается расчет (преобразование накопленной цепочки - объекта Pair в ARGB).

и что? вы хотите произвольно указывать в вашей функции аргументы разных типов? вместо того, что бы описать нормальные 4 функции?
Определяйте наследника класса QVariant - что бы он умел поддерживать ещё и "тройки чисел", "RGB", "ARGB" - и определяйте для него ваши операции.
Тогда и в шаблон думаю засунете. (или идите программировать на бейсике - там нет строгой типизации).

Короче с классами что-то типа того:

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

В итоге - Половина топика  это, имхо, флейм и рассуждения на уровне математического доказательства "женщины=проблемы"
(http://photobucket.com/albums/s235/revmyspace2/graphics/other/funny/005funny0403.jpg)
(кто там анекдот хотел? получите рапишитесь))

Не согласен!
Собственно тема постепенно и ракрывала абстрактное "хочу примерно того" в "необходимо именно это".
Насколько я понял автора, приведенное мной выше решение, то что ему нужно. А как он конкретно будет делать интерполяцию - его личное дело.
О чем он и говорит здесь #2.
Задача была именно в удобстве использования:
C1 + C2*x + C3 + C4 + C5*y ...

Что ж то за "пространство" которого так не хватат? RGB и ARGB прекрасно определенные вещи, более того - это самая популярная цветовая модель.
Почему простое слово "интерполяция" или даже проще "вычислить среднее 2-х значений" недостаточно? Зачем загромождать форум техническими подробностями моей задачи которые не имеют к делу никакого отношения?

Хмм... ну а зачем мне заводить еще класс, конвертировать туда-сюда и.т.п.? Выглядит никак не проще. Чем плохи операторы предложенные в посте #21? Ну или ф-ции Mul и Div?
 

Да, именно это я и имел ввиду. Разумеется, цепочка должна давать корректный результат, иначе такое "удобство" не нужно  :)

Именно потому что иначе не получается. Необходимо превести ваше пространство элементами которого являются ARGB в пространство на котором будут адекватны операции "+" и "*".
Использование только ARGB не даст нужного результата, что обсуждалось выше и я приводил соответствующие примеры.
Надо уж определиться:
- либо простое использование => преобразование
- либо забыть про красивости и использовать функции с подобной сигнатурой F(C1, C1, K);

====
Конечно можно сделать все это и с одним классом ARGB, но придется тащить в нем поля
float k;
ARGB* next;
Что как понимаю будет накладно для случаев не относящихся к данным операциям. И к тому же это ничего не даст с точки зрения улучшения производительности и уменьшения кол-ва операций. Внешнее использование будет выглядеть так-же.
Ведь класс Pair итак не видем при использовании.

Согласен и по существу я так и делаю: оператор *  переводит в пр-во "умноженной альфы", оператор / переводит назад. Что не так?

Причем здесь оператор /. Что он конкретно делает?

Делит альфу на вес и RGB на (альфа * вес). Вес может быть = 1. Пост #21

Уже понял.
В моем последнем примере с классом Pair не нужна опреция "/".
Кроме того можно работать с нелинейными комбинациями (при необходимости).

Это вам так _кажется_, что технические подробности не важны.
Поверьте мне, как системному аналитику, - ваша убежденность в том, что это ваше представление о данных операциях, (тем более убежденность что оно верно) - не более чем бред сивой кобылы. по крайней мере до тех пор, пока вы не потрудитесь объяснить ваши представления подробнее. тогда, уже,  ваши предсталения (возможно) начнут обретать смысл. то как и для чего вы обрабатываете данные - очень важно.
 
вот именно в определении того, что есть "корректный результат" - и кроется суть, которую вы, затрудняетесь объснить с самого начала топика. я вас не с проста с самого начала пытался заставить писать физическую модель процесса - все только для того, что бы мы хоть могли понять - что для вас есть корректный результат. но... "из вас клещами приходится все вытаскивать".

сказали бы уже спасибо, что ли, за то что тут вашу кашу в голове пытаеются струкитурировать... и не берут за это денег.
фу, молодой человек...

зы: вы уж извините за грубости, но надо как-то более структурированнее учиться думать... :-\
имхо.

Denjs - вы не правы.

К творческим личностям такой подход не приемлем. Все мы имеем свои особенности.
Я достаточно долго общаюсь с Igors. Ну, есть у него такая особенность, расплывчатые формулировки. Приходится постепенно уточнять или вытягивать данные. И что!
Он решает серьезные задачи, держит в голове большой проект, в своей(специфичной) предметной области, не привык формулировать задачи абстрагировано.
Однако, его вопросы всегда интересны!

А по поводу того что данная тема затянулась, "вина" не столько только Igors, сколько остальных.
Практически всю тему он раскрыл за 4 первых своих поста (Ответ #6). Но мало кто вникает. Обычно отвечают, лишь бы ответить. Я тоже, этим грешу(очень надеюсь что не часто :( )

2 DenjsМне кажется что роль "великого учителя" (которую Вы пытаетесь играть) засоряет форум и тягостна для Вас же самого. Зачем переходить на личности и сивых кобыл вместо того указать/предложить по существу? Я ничего не имею против критики и если пойму что был неправ - признаю. Но с какой стати я или др. человек должен в точности повторять именно Ваш ход рассуждений, который Вы упорно навязываете, да еще со всеми лирическими отступлениями?  :) Моей целью было просто обсудить операторы класса, а не писать для Вас диссертацию.

Я не желаю с Вами больше разговаривать до тех пор пока Вы не поймете что здесь нет "сеньоров" и "юниоров"