Открыть список
Как стать автором
Обновить

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

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

Почему не реализовано? Реализовано, но работает не так, как вам хотелось бы. Обычно это и называют проблемой.
нет возможности сейчас проверить, но Image.composite в PIL должен, наверное, делать тоже самое :-/
К сожалению, нет, аналогично варианту im1.paste(im2, (0,0), im2).
:( жаль, а вообще спасибо за статью, впервые задумался об альфа-канале как о имеющем физическое воплощение в реальном мире, грубо говоря, в виде «цветных стеклышек» :) Пока таких задач (наложение двух полупрозрачных изображений) на практике не встречалось, но будет от чего плясать
разве альфа-канал до 255? вроде же до 128? Там самое интересное — как альфа-канал потом вычислять.
Альфаканал до скольки угодно, сколько реализуете, столько и будет. Если разговор про 32-х битные PNG, то на хранение альфаканала там 8 бит.
что верно, то верно. Осталось вспомнить, почему GD выдает 7 бит для прозрачности.
У меня есть предположение, что это сделано, чтобы результат умножения и сложения двух пикселей альфаканала не превышал 16 бит. Это очень полезно при расчетах на MMX, в 2 раза больше операций за такт.
Зависит от формата изображения. Для PNG это 8-бит или 16-бит уровней. Gif имеет 1 уровень. ICO 8-бит уровней.
вообще говоря для компонентов картинок 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 не вылезли за диапазон (у вас этого не вижу)
Полностью согласен с Вами. Жаль «нет заряда для голосования»
НЛО прилетело и опубликовало эту надпись здесь
a = (a1 + a2) / 2;

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

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

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

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

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

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

В месте, где альфаканал имеет промежуточные значения, как видите, цвет не смешивается ни с каким «фоновым» цветом.
Цвет изображения действительно не обязан содержать фоновый цвет, но дело в том, что сохранять изображение как-то нужно.
Как ваш графический редактор догадался, что сохранять нужно черный квадрат, а не белый? А что будет, если круг окажется красным? Квадрат зальет красным цветом? А если картинка будет многоцветной, то что случится с прозрачным фоном? Мой редактор делает так:
Зачем ему «догадываться», что там квадрат, если там прозрачные пиксели и может быть какой угодно цвет. Кстати, вы не могли бы не сохранять изображения в формат, который не поддерживает альфаканал, когда разговариаете об альфаканале? Решительно не возможно понять, что же именно сохраняет ваш редактор и действительно ли он подмешивает цвета «фона», или вам так кажется.
Давайте вы мне скажите значения верхней левой точки.
Раз там «прозрачный цвет», то а = 0x00 (в некоторых реализациях 0xFF). А что у вас там с цветами? В моем случае: RGB=0xFFFFFF.
У вас просто пропускается несколько байт? Что типа «Пусто 30 байт»? Или как?
Я же написал, там «все что угодно».
Т.е. могут быть просто случайные значения?
Все что угодно.
Еще по поводу форматов, которые не поддерживают альфа-канал. Удивительным образом любой формат можно заставить сохранить альфаканал в виде чб изображения, которое можно приложить к файлу с основным изображением. Например сделать два BMP файла, а потом собрать из них картинку с альфа-каналом (такие простые форматы часто использовали для загрузки текстур и карт прозрачности в 3d-ускорители, а сейчас можно использовать в небольших программах, где таскать с собой гиганский модуль для работы с графикой не очень удобно из-за одной-двух функций ).
Слушайте, я не понимаю, зачем вы это пишете. Вопрос простой — вы утверждаете, что в месте «полупрозрачности» должен подмешиваться какой-то фоновый цвет. Это не так.
Че то я тут не увидел алгоритма. Скорее логично перенести в Python, хотя и смысловой нагрузки в статье маловато.
Это все равно что перенести статью о создании иконок в блог Adobe, потомучто иконки рисовали в Фотошопе.
Расположите копию примера справа от каждого результата чтоб каждый раз наверх не скроллить, станет удобнее читать
А в CMYK как раз надо делать так, как делает PIL, т.е. без 1-x везде…
А можно особенно для не знающих Питон, расписать все это в виде обычного текста/псевдокода?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.