Android bitmap set alpha

Класс Bitmap

Вам часто придётся иметь дело с изображениями котов, которые хранятся в файлах JPG, PNG, GIF. По сути, любое изображение, которое мы загружаем из графического файла, является набором цветных точек (пикселей). А информацию о каждой точке можно сохранить в битах. Отсюда и название — карта битов или по-буржуйски — bitmap. У нас иногда используется термин растр или растровое изображение. В Android есть специальный класс android.graphics.Bitmap для работы с подобными картинками.

Существуют готовые растровые изображения в файлах, о которых поговорим ниже. А чтобы создать с нуля объект Bitmap программным способом, нужно вызвать метод createBitmap():

В результате получится прямоугольник с заданными размерами в пикселях (первые два параметра). Третий параметр отвечает за информацию о прозрачности и качестве цвета (в конце статьи есть примеры).

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

Bitmap.Config

Кроме размеров, желательно знать цветовую схему. У класса Bitmap есть метод getConfig(), который возвращает перечисление Bitmap.Config.

Всего существует несколько элементов перечисления.

• Bitmap.Config ALPHA_8 — каждый пиксель содержит в себе информацию только о прозрачности, о цвете здесь ничего нет. Каждый пиксель требует 8 бит (1 байт) памяти.
• Bitmap.Config ARGB_4444 — устаревшая конфигурация, начиная с API 13. Аналог ARGB_8888, только каждому ARGB-компоненту отведено не по 8, а по 4 бита. Соответственно пиксель весит 16 бит (2 байта). Рекомендуется использовать ARGB_8888
• Bitmap.Config ARGB_8888 — на каждый из 4-х ARGB-компонентов пикселя (альфа, красный, зеленый, голубой) выделяется по 8 бит (1 байт). Каждый пиксель занимает 4 байта. Обладает наивысшим качеством для картинки.
• Bitmap.Config RGB_565 — красному и и синему компоненту выделено по 5 бит (32 различных значений), а зелёному — шесть бит (64 возможных значений). Картинка с такой конфигурацией может иметь артефакты. Каждый пиксель будет занимать 16 бит или 2 байта. Конфигурация не хранит информацию о прозрачности. Можно использовать в тех случаях, когда рисунки не требуют прозрачности и высокого качества.

Конфигурация RGB_565 была очень популярна на старых устройствах. С увеличением памяти и мощности процессоров данная конфигурация теряет актуальность.

В большинстве случаев вы можете использовать ARGB_8888.

Получив объект в своё распоряжение, вы можете управлять каждой его точкой. Например, закрасить его синим цветом.

Чтобы закрасить отдельную точку, используйте метод setPixel() (парный ему метод getPixel позволит узнать информацию о точке). Закрасим красной точкой центр синего прямоугольника из предыдущего примера — имитация следа от лазерной указки. Котам понравится.

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

Созданный нами цветной прямоугольник и управление отдельными точками не позволят вам нарисовать фигуру, не говоря уже о полноценном рисунке. Класс Bitmap не имеет своих методов для рисования, для этого есть метод Canvas (Холст), на котором вы можете размещать объекты Bitmap.

Когда вы размещали в разметке активности компонент ImageView и присваивали атрибуту android:src ресурс из папок drawable-xxx, то система автоматически выводила изображение на экран.

Если нужно программно получить доступ к битовой карте (изображению) из ресурса, то используется такой код:

Обратный процес конвертации из Bitmap в Drawable:

Изображение можно сохранить, например, на SD-карту в виде файла (кусок кода):

Каждая точка изображения представлена в виде 4-байтного целого числа. Сначала идёт байт прозрачности — значение 0 соответствует полной прозрачности, а 255 говорит о полной непрозрачности. Промежуточные значения позволяют делать полупрозрачные изображения. Этим искусством в совершенстве владел чеширский кот, который умело управлял всеми точками своего тела и растворялся в пространстве, только улыбка кота долго ещё висела в воздухе (что-то я отвлёкся).

Следующие три байта отвечают за красный, зелёный и синий цвет, которые работают по такому же принципу. Т.е. значение 255 соответствует насыщенному красному цвету и т.д.

Так как любое изображение кота — это набор точек, то с помощью метода getPixels() мы можем получить массив этих точек, сделать с этой точкой что-нибудь нехорошее (поменять прозрачность или цвет), а потом с помощью родственного метода setPixels() записать новые данные обратно в изображение. Так можно перекрасить чёрного кота в белого и наоборот. Если вам нужна конкретная точка на изображении, то используйте методы getPixel()/setPixel(). Подобный подход используется во многих графических фильтрах. Учтите, что операция по замене каждой точки в большом изображении занимает много времени. Желательно проводить подобные операции в отдельном потоке.

На этом базовая часть знакомства с битовой картой закончена. Теперь подробнее.

Учитывая ограниченные возможности памяти у мобильных устройств, следует быть осторожным при использовании объекта Bitmap во избежание утечки памяти. Не забывайте освобождать ресурсы при помощи метода recycle(), если вы в них не нуждаетесь. Например:

Почему это важно? Если не задумываться о ресурсах памяти, то можете получить ошибку OutOfMemoryError. На каждое приложение выделяется ограниченное количество памяти (heap size), разное в зависимости от устройства. Например, 16мб, 24мб и выше. Современные устройства как правило имеют 24мб и выше, однако это не так много, если ваше приложение злоупотребляет графическими файлами.

Bitmap на каждый пиксель тратит в общем случае 2 или 4 байта (зависит от битности изображения – 16 бит RGB_555 или 32 бита ARGB_888). Можно посчитать, сколько тратится ресурсов на Bitmap, содержащий изображение, снятое на 5-мегапиксельную камеру.

При соотношении сторон 4:3 получится изображение со сторонами 2583 х 1936. В конфигурации RGB_555 объект Bitmap займёт 2592 * 1936 * 2 = около 10Мб, а в ARGB_888 (режим по умолчанию) в 2 раза больше – чуть более 19Мб.

Во избежание проблем с памятью прибегают к помощи методов decodeXXX() класса BitmapFactory.

Если установить атрибут largeHeap в манифесте, то приложению будет выделен дополнительный блок памяти.

Ещё одна потенциальная проблема. У вас есть Bitmap и присвоили данный объект кому-то. Затем объект был удалён из памяти, а ссылка на него осталась. Получите крах приложения с ошибкой типа «Exception on Bitmap, throwIfRecycled».

Возможно, лучше сделать копию.

Получить Bitmap из ImageView

Если в ImageView имеется изображение, то получить Bitmap можно следующим образом:

Но с этим способом нужно быть осторожным. Например, если в ImageView используются элементы LayerDrawable, то возникнет ошибка. Можно попробовать такой вариант.

Более сложный вариант, но и более надёжный.

Изменение размеров — метод createScaledBitmap()

С помощью метода createScaledBitmap() можно изменить размер изображения.

Будем тренироваться на кошках. Добавим картинку в ресурсы (res/drawable). В разметку добавим два элемента ImageView

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

Кадрирование — метод createBitmap()

Существует несколько перегруженных версий метода Bitmap.createBitmap(), с помощью которых можно скопировать участок изображения.

• сreateBitmap(Bitmap source, int x, int y, int width, int height, Matrix m, boolean filter) — Returns an immutable bitmap from subset of the source bitmap, transformed by the optional matrix.
• createBitmap(int width, int height, Bitmap.Config config) — Returns a mutable bitmap with the specified width and height.
• createBitmap(Bitmap source, int x, int y, int width, int height) — Returns an immutable bitmap from the specified subset of the source bitmap.
• createBitmap(int[] colors, int offset, int stride, int width, int height, Bitmap.Config config) — Returns a immutable bitmap with the specified width and height, with each pixel value set to the corresponding value in the colors array.
• createBitmap(Bitmap src) — Returns an immutable bitmap from the source bitmap.
• createBitmap(int[] colors, int width, int height, Bitmap.Config config) — Returns a immutable bitmap with the specified width and height, with each pixel value set to the corresponding value in the colors array.

Описываемый ниже код не является оптимальным и очень ресурсоёмкий. На больших изображениях код будет сильно тормозить. Приводится для ознакомления. Чтобы вывести часть картинки, можно сначала создать нужный Bitmap с заданными размерами, занести в массив каждый пиксель исходного изображения, а затем этот же массив вернуть обратно. Но, так как мы уже задали другие размеры, то часть пикселей не выведутся.

По аналогии мы можем вывести и нижнюю правую часть изображения:

Немного модифицировав код, мы можем кадрировать центр исходного изображения. Предварительно придётся проделать несколько несложных вычислений.

Скриншот приводить не буду, проверьте самостоятельно.

Меняем цвета каждого пикселя

Через метод getPixels() мы можем получить массив всех пикселей растра, а затем в цикле заменить определённым образом цвета в пикселе и получить перекрашенную картинку. Для примера возьмем стандартный значок приложения, поместим его в ImageView, извлечём информацию из значка при помощи метода decodeResource(), применим собственные методы замены цвета и полученный результат поместим в другие ImageView:

Код для класса активности:

На скриншоте представлен оригинальный значок и три варианта замены цветов.

Ещё один пример, где также в цикле меняем цвет каждого пикселя Green->Blue, Red->Green, Blue->Red (добавьте на экран два ImageView):

Конвертируем Bitmap в байтовый массив и обратно

Сжимаем картинку

В предыдущем примере вызывался метод compress(). Несколько слов о нём. В первом аргументе передаём формат изображения, поддерживаются форматы JPEG, PNG, WEBP. Во втором аргументе указываем степень сжатия от 0 до 100, 0 — для получения малого размера файла, 100 — максимальное качество. Формат PNG не поддерживает сжатие с потерей качества и будет игнорировать данное значение. В третьем аргументе указываем файловый поток.

Как раскодировать Bitmap из Base64

Если изображение передаётся в текстовом виде через Base64-строку, то воспользуйтесь методом, позволяющим получить картинку из этой строки:

Вычисляем средние значения цветов

Дополнительные материалы

На StackOverFlow есть интересный пример программной генерации цветных квадратов с первой буквой слова. В пример квадрат используется как значок к приложению. Также популярен этот приём в списках. Квадраты также заменять кружочками.

Источник

Masking Bitmaps на Android

При разработке под Android довольно часто возникает задача наложить маску на изображение. Чаще всего требуется закруглить углы у фотографий или сделать изображение полностью круглым. Но иногда применяются маски и более сложной формы.

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

Я предполагаю, что читатель имеет опыт в разработке под Android и знаком с классами Canvas, Drawable и Bitmap.

Код, используемый в статье, можно найти на GitHub.

Постановка задачи

Допустим, у нас есть две картинки, которые представлены объектами Bitmap. Одна из них содержит исходное изображение, а вторая — маску в своем альфа-канале. Требуется отобразить изображение с наложенной маской.

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

Обратите внимание на .extractAlpha() : этот вызов создает Bitmap с конфигурацией ALPHA_8, значит, на один пиксел расходуется один байт, который кодирует прозрачность этого пиксела. В таком формате очень выгодно хранить маски, так как цветовая информация в них не несет полезной нагрузки и ее можно выкинуть.

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

PorterDuff modes

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

Теория

Введем обозначения (как в стандарте):

• Da (destination alpha) —исходная прозрачность пиксела холста;
• Dc (destination color) — исходный цвет пиксела холста;
• Sa (source alpha) — прозрачность пиксела накладываемого изображения;
• Sc (source color) — цвет пиксела накладываемого изображения;
• Da’ — прозрачность пискела холста после наложения;
• Dc’ — цвет пискела холста после наложения.

Режим определяется правилом, по которому определяются Da’ и Dc’ в зависимости от Dc, Da,Sa, Sc.

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

[Da’, Dc’] = f(Dc, Da, Sa, Sc)

Например, для режима DST_IN справедливо

Da’ = Sa·Da
Dc’ = Sa·Dc

или в компактной записи [Da’, Dc’] = [Sa·Da, Sa·Dc]. В документации Android это выглядит как

Надеюсь, теперь можно давать ссылку на не в меру лаконичную документацию от Google. Без предварительного объяснения созерцание оной зачастую вводит разработчиков в ступор: developer.android.com/reference/android/graphics/PorterDuff.Mode.html.

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

Из этой шпаргалки сразу видно интересующие нас режимы SRC_IN и DST_IN. Они, по сути, являются пересечением непрозрачных областей холста и накладываемого изображения, при этом DST_IN оставляет цвет холста, а SRC_IN меняет цвет. Если на холсте изначально была отрисована картинка, то выбираем DST_IN. Если на холсте изначально была нарисована маска — выбираем SRC_IN.

Теперь, когда все стало понятно, можно писать код.

SRC_IN

Довольно часто на stackoverflow.com встречаются ответы, где при использовании PorterDuff рекомендуют выделять память под буфер. Иногда даже это предлагается делать при каждом вызове onDraw. Конечно, это крайне неэффективно. Нужно стараться избегать вообще любого выделения памяти на куче в onDraw. Тем более удивительно наблюдать там Bitmap.createBitmap, который запросто может потребовать несколько мегабайт памяти. Простой пример: картинка 640*640 в формате ARGB занимает в памяти более 1,5 Мб.

Чтобы этого избежать, буфер можно выделять заранее и переиспользовать его в вызовах onDraw.
Вот пример Drawable, в которой используется режим SRC_IN. Память под буфер выделяется при изменении размера Drawable.

В примере выше сначала на холст буфера рисуется маска, потом в режиме SRC_IN рисуется картинка.

Внимательный читатель заметит, что этот код неоптимален. Зачем перерисовывать холст буфера при каждом вызове draw? Ведь можно делать это только когда что-то изменилось.

DST_IN

В отличие от SRC_IN, при использовании DST_IN надо изменить порядок рисования: сначала на холст рисуется картинка, а сверху маска. Изменения по сравнению с предыдущим примером будут такие:

Что любопытно, этот код не дает ожидаемого результата, если маска представлена в формате ALPHA_8. Если же она представлена в неэффективном формате ARGB_8888, то все прекрасно. Вопрос на stackoverflow.com на данный момент висит без ответа. Если кто-то знает причину — просьба поделиться знанием в комментариях.

CLEAR + DST_OVER

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

Но если подумать, то в некоторых случаях можно обойтись вообще без выделения буфера и рисовать сразу на холст, который нам передали в draw. При этом нужно иметь в виду, что на нем уже что-то нарисовано.

Для этого в холсте мы как бы прорезаем дырку по форме маски с помощью режима CLEAR, а затем рисуем картинку в режиме DST_OVER — образно говоря, подкладываем картинку под холст. Через эту дырку видно картинку и эффект получается как раз такой, как нам нужно.

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

Код будет выглядеть так:

У этого решения есть проблемы с прозрачностью. Если мы захотим реализовать метод setAlpha, то через изображение будет просвечивать фон окна, а вовсе не то, что было нарисовано на холсте под нашим Drawable. Сравните изображения:

Слева — как должно быть, справа — как получается, если использовать CLEAR + DST_OVER в комбинации с полупрозрачностью.

Как видим, использование режимов PorterDuff на Android связано либо с выделением лишней памяти, либо с ограничением применения. К счастью, есть способ избежать всех этих проблем. Достаточно воспользоваться BitmapShader.

BitmapShader

Обычно, когда упоминаются шейдеры, вспоминают OpenGL. Но не стоит пугаться, использование BitmapShader на Android не требует от разработчика знаний в этой области. По сути, реализации android.graphics.Shader описывают алгоритм, который определяет цвет каждого пиксела, то есть являются пискельными шейдерами.

Как их использовать? Очень просто: если шейдер зарядить в Paint, то все, что рисуется с помощью этого Paint, будет брать цвет пикселов из шейдера. В пакете есть реализации шейдеров для рисования градиентов, комбинирования других шейдеров и (самый полезный в контексте нашей задачи) BitmapShader, который инициализируется с помощью Bitmap. Такой шейдер возвращает цвет соответствующих пикселов из Bitmap, которое было передано при инициализации.

В документации есть важное уточнение: рисовать шейдером можно все, кроме Bitmap. На самом деле, если Bitmap в формате ALPHA_8, то при отрисовке такого Bitmap с помощью шейдера все прекрасно работает. А наша маска как раз в таком формате, так давайте попробуем отобразить маску с помощью шейдера, который использует изображения цветка.

• создаем BitmapShader, в который загружаем изображение цветка;
• создаем Paint, в который заряжаем этот BitmapShader;
• рисуем маску с помощью этого Paint.

Все очень просто, не так ли? На самом деле, если размеры маски и изображения не совпадают, то мы увидим не совсем то, что ожидали. Маска будет замощена изображениями, что соответствует использованному режиму Shader.TileMode.REPEAT .

Чтобы привести размер картинки к размеру маски, можно воспользоваться методом android.graphics.Shader#setLocalMatrix, в который нужно передать матрицу преобразования. К счастью, вспоминать курс аналитической геометрии не придется: класс android.graphics.Matrix содержит удобные методы формирования матрицы. Будем сжимать шейдер так, чтобы изображение полностью поместилось в маску без искажений пропорций, и сдвинем его так, чтобы совместить центры изображения и маски:

Также использование шейдера дает нам возможность легко реализовать методы изменения прозрачности нашего Drawable и установки ColorFilter. Достаточно вызвать одноименные методы шейдера.

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

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

Поскольку шейдер можно использовать для рисования чего угодно, то можно попробовать нарисовать текст, например:

RoundedBitmapDrawable

Полезно знать о существовании в Support Library класса RoundedBitmapDrawable. Он может пригодиться, если нужно только скруглить края или сделать картинку полностью круглой. Внутри используется BitmapShader.

Производительность

Давайте посмотрим, как перечисленные выше решения влияют на производительность. Для этого я использовал RecyclerView с сотней элементов. Графики GPU monitor сняты при быстром скроллинге на достаточно производительном смартфоне (Moto X Style).

Напомню, что на графиках по оси абсцисс — время, по оси ординат — количество миллисекунд, затраченное на отрисовку каждого кадра. В идеале график должен помещаться ниже зеленой линии, что соответствует 60 FPS.

Plain BitmapDrawable (no masking)

Видно, что использование BitmapShader позволяет добиться такого же высокого фреймрейта, что и без накладывания маски вообще. В то время как SRC_IN решение уже нельзя признать достаточно производительным, интерфейс ощутимо «подтормаживает» при быстром скроллинге, что подтверждается графиком: многие кадры отрисовываются дольше 16 мс, а некоторые и больше 33 мс, то есть FPS падает ниже 30.

Выводы

На мой взгляд, преимущества подхода с использованием BitmapShader очевидны: не надо выделять память под буфер, отличная гибкость, поддержка полупрозрачности, высокая производительность.
Неудивительно, что именно этот подход используется в библиотечных реализациях.

Источник