homm 10 июл 2010 в 20:42

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

3 мин

31K

Python*

+16

Комментарии 37

НЛО прилетело и опубликовало эту надпись здесь

homm 10 июл 2010 в 22:10

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

НЛО прилетело и опубликовало эту надпись здесь

homm 10 июл 2010 в 22:17

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

Veterinar 10 июл 2010 в 22:22

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

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

VolCh 10 июл 2010 в 22:20

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

homm 10 июл 2010 в 22:25

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

VolCh 10 июл 2010 в 23:11

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

sunnybear 10 июл 2010 в 22:07

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

-4

homm 10 июл 2010 в 22:14

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

sunnybear 10 июл 2010 в 22:16

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

homm 10 июл 2010 в 22:20

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

azproduction 10 июл 2010 в 22:15

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

tzlom 10 июл 2010 в 22:26

вообще говоря для компонентов картинок 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 10 июл 2010 в 22:54

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

-2

НЛО прилетело и опубликовало эту надпись здесь

tzlom 10 июл 2010 в 23:19

a = (a1 + a2) / 2;

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

НЛО прилетело и опубликовало эту надпись здесь

gene4000 11 июл 2010 в 09:18

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

homm 11 июл 2010 в 10:13

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

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

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

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

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

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

gene4000 11 июл 2010 в 10:53

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

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

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

homm 11 июл 2010 в 11:22

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

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

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

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

gene4000 11 июл 2010 в 11:28

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

homm 11 июл 2010 в 11:37

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

gene4000 11 июл 2010 в 11:45

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

homm 11 июл 2010 в 11:49

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

gene4000 11 июл 2010 в 11:51

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

homm 11 июл 2010 в 11:51

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

homm 11 июл 2010 в 12:02

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

gene4000 11 июл 2010 в 11:49

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

homm 11 июл 2010 в 11:51

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