Простое наложение 2-х изображений

[@homm]

Это относится к алгоритмам так, что этот же алгоритм используется и в imagemagick и в gd2 и в фотошопе. И это не «проблема» библиотеки питона, просто в ней это не реализовано, что, конечно, досадно в некотором роде. Но из-за этой её особенности было удобно её использовать, чтобы объяснить алгоритм.

[@homm]

Это ошибка, исправил.

[@Veterinar]

> просто в ней это не реализовано

Почему не реализовано? Реализовано, но работает не так, как вам хотелось бы. Обычно это и называют проблемой.

[@VolCh]

нет возможности сейчас проверить, но Image.composite в PIL должен, наверное, делать тоже самое :-/

[@homm]

К сожалению, нет, аналогично варианту im1.paste(im2, (0,0), im2).

[@VolCh]

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

[@sunnybear]

разве альфа-канал до 255? вроде же до 128? Там самое интересное — как альфа-канал потом вычислять.

[@homm]

Альфаканал до скольки угодно, сколько реализуете, столько и будет. Если разговор про 32-х битные PNG, то на хранение альфаканала там 8 бит.

[@sunnybear]

что верно, то верно. Осталось вспомнить, почему GD выдает 7 бит для прозрачности.

[@homm]

У меня есть предположение, что это сделано, чтобы результат умножения и сложения двух пикселей альфаканала не превышал 16 бит. Это очень полезно при расчетах на MMX, в 2 раза больше операций за такт.

[@azproduction]

Зависит от формата изображения. Для PNG это 8-бит или 16-бит уровней. Gif имеет 1 уровень. ICO 8-бит уровней.

[@tzlom]

вообще говоря для компонентов картинок 1 и 2 — c1 и с2 и их альф a1 и a2 результат сложения это
c = (c1*a1*(1-a2) + c2*a1)*(1/(1-(1-a1)*(1-a2))
a = 1-(1-a1)*(1-a2)

где c это любое число, a — дробное от 0 до 1
и не забываем проверять что c и a не вылезли за диапазон (у вас этого не вижу)

[@Alexsib]

Полностью согласен с Вами. Жаль «нет заряда для голосования»

[@tzlom]

a = (a1 + a2) / 2;

это неправильно, по вашей логике если 2 50% прозрачные пластины стоят друг за другом то их итоговая прозрачность 50%, хотя на самом деле — 25%

[@gene4000]

А как учитывается фоновый цвет? Тот который прозрачный.
Он бывает либо белым, либо черным. Да, сама прозрачность не нужна, без разницы какой у нее цвет, но области, которые полупрозрачны имеют долю этого цвета (обычно по контуру). Чаще всего там белый, реже черный, в некоторых программах можно выбрать любой оттенок серого.
Я к формуле сильно не присматривался, может быть единицы, которые там встречаются играют роль белого фонового цвета?

[@homm]

А как учитывается фоновый цвет? Тот который прозрачный.

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

Он бывает либо белым, либо черным.

Если речь о 32-х битных изображениях, он может быть любым из 16 миллионов цветов.

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

Где именно имеют? Если это было в какой-то программе при наложении 2-х изображений, это однозначно баг.

[@gene4000]

Обычно фоновый цвет (в том же png) должен быть каким-то конкретным, не бывает «пустого цвета». Причем не тот цвет, который обозначен специальным разделом, а реальный, который содержится в битовом массиве. Обычно это белый цвет. Других не встречал.
Крайние точки изображения, которые частично прозрачны, содержат кроме прозрачности часть фонового цвета (в случае с белым, они просто становятся светлее). И если просто взять прозрачность без учета фонового цвета, то получаются неприятные контуры у изображения. Примерно так:

1. исходный рисунок
2. правильная обработка
3. неправильная — только два варианта прозрачности: есть или нет.
4. неправильная — прозрачность учтена, а фоновый цвет из оригинального изображения не убран.

Я хотел узнать, как решается проблема с исключением фонового цвета

[@homm]

Крайние точки изображения, которые частично прозрачны, содержат кроме прозрачности часть фонового цвета

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


Слева на право: Картинка, цветовая составляющая, альфаканал.

В месте, где альфаканал имеет промежуточные значения, как видите, цвет не смешивается ни с каким «фоновым» цветом.

[@gene4000]

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

[@homm]

Зачем ему «догадываться», что там квадрат, если там прозрачные пиксели и может быть какой угодно цвет. Кстати, вы не могли бы не сохранять изображения в формат, который не поддерживает альфаканал, когда разговариаете об альфаканале? Решительно не возможно понять, что же именно сохраняет ваш редактор и действительно ли он подмешивает цвета «фона», или вам так кажется.

[@gene4000]

Давайте вы мне скажите значения верхней левой точки.
Раз там «прозрачный цвет», то а = 0x00 (в некоторых реализациях 0xFF). А что у вас там с цветами? В моем случае: RGB=0xFFFFFF.
У вас просто пропускается несколько байт? Что типа «Пусто 30 байт»? Или как?

[@homm]

Я же написал, там «все что угодно».

[@gene4000]

Т.е. могут быть просто случайные значения?

[@homm]

Все что угодно.

[@homm]

Вот картинка для размышлений: img6.imageshack.us/img6/3831/63261526.png (смотреть RGB каналы)

[@gene4000]

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

[@homm]

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

[@kresh]

Че то я тут не увидел алгоритма. Скорее логично перенести в Python, хотя и смысловой нагрузки в статье маловато.

[@homm]

Это все равно что перенести статью о создании иконок в блог Adobe, потомучто иконки рисовали в Фотошопе.

[@Denai]

Расположите копию примера справа от каждого результата чтоб каждый раз наверх не скроллить, станет удобнее читать

[@GreyCat]

А в CMYK как раз надо делать так, как делает PIL, т.е. без 1-x везде…

[@remal]

А можно особенно для не знающих Питон, расписать все это в виде обычного текста/псевдокода?