GIMP метод составления / смешивания слоев

Question

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

Мой оригинальный подход состоял в том, чтобы просто использовать композицию Src-Over для "нормального" режима наложения и композицию Src-Atop для других режимов. По сравнению с выходом из GIMP, это дало аналогичные, но отличающиеся результаты. Выходной альфа-канал совпадает, но данные RGB отличаются.

В частности, влияние цвета переднего плана на фон равно нулю, когда фоновая альфа равна нулю. Потратив несколько часов наивного просмотра источника GIMP 2.8.10, я заметил несколько вещей, которые меня смущают.

За исключением определенных режимов и нескольких вспомогательных вещей, которые происходят во время экспорта, которые я еще не нашел в коде, подход примерно такой:

if ~normalmode
    FGalpha = min(FGalpha, BGalpha);  % << why this?
end

    FGalpha = FGalpha * mask * opacity;
    OUTalpha = BGalpha + (1 - BGalpha) * FGalpha;
    ratio = FGalpha / (OUTalpha + eps);
    OUT = OUT * ratio + BG * (1 - ratio);

if normalmode
    OUT = cat(3, OUT, OUTalpha);
else
    OUT = cat(3, OUT, BGalpha);
end

Точки любопытства заключаются в том, что я концептуально не понимаю, почему для композиции нужно брать минимум альфа слоев. Конечно, этот подход дает результаты, соответствующие GIMP, но мне неудобно устанавливать это как поведение по умолчанию, если я не понимаю причины.

---

Лучше всего об этом спросить где-нибудь на форуме GIMP, но я подумал, что было бы более плодотворно обратиться к широкой аудитории. Чтобы уточнить и подвести итог:

• Имеет ли смысл, что на цвета в прозрачной области BG не влияет умножение с непрозрачным цветом переднего плана? Не приведет ли это к риску кровотечения неизмененных данных вблизи краев жесткой маски при какой-либо будущей операции?
• Хотя я ничего не нашел, есть ли другие приложения, которые используют этот подход?
• Я неправ, чтобы использовать поведение GIMP в качестве ссылки? У меня нет PS для сравнения, и ImageMagick настолько гибок, что на самом деле не предлагает конкретного ожидаемого поведения. Конечно, у GIMP есть некоторые вещи, которые он делает неправильно; может быть, это что-то еще, что может измениться.

РЕДАКТИРОВАТЬ: я могу по крайней мере ответить на последний вопрос, отказавшись от него. Я решил добавить поддержку как SVG 1.2, так и устаревших методов GIMP. Методы GEGL, которые будут использоваться GIMP в будущем, следуют методам SVG, поэтому я полагаю, что это говорит о правильности унаследованных методов.

Что бы это ни стоило, все методы SVG основаны на композиции Porter-Duff Src-Over. Если обратиться к документации, то факт, что смешанная математика - то же самое, становится запутанным, потому что смесь и композиция алгебраически объединяются с использованием предварительно умноженного альфа, чтобы уменьшить общую вычислительную стоимость. За исключением SoftLight, математика сочетания ядер такая же, как и в GIMP и в других местах.

Любую другую операцию смешивания (например, PinLight, Hue) можно сделать совместимой, просто выполнив:

As = Sa * (1 - Da);
Ad = Da * (1 - Sa);
Ab = Sa * Da;
Ra = As + Ad + Ab;   % output alpha
Rc = ( f(Sc,Dc)*Ab + Sc*As + Dc*Ad ) / Ra;

а затем делать некоторую алгебру, если вы хотите упростить это.