Comments 34
Не думали склеенные файлы сохранять в каком-то своём формате? Это избавило бы от удвоения количества картинок и склеивания налету. Нужно только написать просмотрщик для нового типа файлов в вашем приложении.
Лучше тогда уже действительно в exif писать, чтобы не плодить форматов. Там, правда, ограничение на 64кб на поле, но это не смертельно.
А уж если совсем на свой формат переходить, так правильнее уже и JPEG2000 использовать.
Но и тогда о простоте подхода забыть придется.
Одним из вариантов решения проблемы с увеличившимся вдвое количеством ресурсов может быть настройка пост-билд экшена, которые копирует в бандл прозрачные маски с теми же именами, что и у jpg-файлов.
А не думали использовать что-то аналогичное хромакей? Реализация: При отображении вычислять маску автоматом исходя из того, что некоторый цвет (с небольшим оговоренным допуском) считаем прозрачным. Делаете подложку из зеленого цвета. Все пикселы, в которых уровень зеленого преобладает над уровнем красного и синего считаем прозрачными.
Косяки: Нельзя использовать зеленый. Решение: В случае если картинка уже имеет зеленый цвет — можно оговаривать цвет заранее (например синий или красный). Также можно и с другими цветами но с другим алгоритмом проверки…
Плюсы: нет удвоенного количества файлов. Стандартный формат. Адекватный размер. Простота создания файлов с картинками.
Минусы: возможны появления артефактов в маске, как результат — шум возле картинки…
Вариант достойный обсуждения. К сожалению, JPEG хранит не RGB картинку, а YCbCr (как и MPEG, DXT1-DXT5 и др.), потому «зеленый» сильно смешается с другими цветами и артефакты перечеркнут всю идею… Ну и восстановление цветового баланса будет потом непростой задачей.
Ну просто исходя из увиденных скриншотов, я решил что маски нужны не с градациями, а в духе есть/нет. Такой вариант пробовал на веб сайтах — работало вполне кошерно. Про RGB говорил т.к. обрабатывал уже распакованную картинку (а она там была именно rgb)
А баланс зачем восстанавливать? или это было сказано по поводу полупрозрачных картинок?
Как раз маски нужны были с градациями. Баланс восстанавливать надо будет, если мы целиком избавимся от одного цвета и заменим его альфа-каналом.
Покажете свой вариант с веб сайтами?
ну на счет сайтов — это я приувеличил: просто попробовал реализовать эффект хромакей наткнувшись на описание работы с canvas — на том все и заглохло… Но в планах есть… Честно :-) вот на чем остановился
вполне неплохо! для GUI без теней и особого сглаживания вполне может подойти
UFO landed and left these words here
Конечно пробовал. Размер 1.8Мб был получен при оптимальном соотношении цвета/качества. Без этого тестовый пример 2.5Мб занимал. Более того, есть методы, которые автоматическим утилитам и не снились, например, разбить изображение на блоки, квантовать каждый из них до 256 цветов и собрать все вместе.
Но все-равно ~400кб размера для такой текстуры и без визуальных потерь только JPEG даст.
UFO landed and left these words here
Круто
А как выглядит джпег, полученный из png с помощью imagemagic?

Для меня, непрограммиста, например загадка, как Флеш жмёт png: они сохраняют прозрачность, но при этом уменьшаются в размере и при диком сжатии покрываются характерными артефактами
Ага, спасибо. Ничего не зная про порты, я такие штуки разделял в ФШ с помощью экшена, который делал кучу клонов прозрачного слоя (чтобы все полупрозрачные пиксели стали 100% непрозрачности), а оказывается вот оно как можно.
Добавлю маленькую деталь о сжатии JPEG.
ImageMagick позволяет указывать не только quality но еще и chroma subsampling. При его отключении (точнее, установке параметра -sampling-factor 4:4:4 ) смешение цветов при сжатии уменьшается, и параметр quality можно установить меньшим, сохранив менее размытые цвета при большем сжатии.
нельзя туда TIFF пихать? Каналов — сколько угодно. Подержка как jpg, так и всяких zip копрессий
В фотошопе если для TIFF ставить галочку «Save Transparency», то JPEG сжатие становится неактивным. Может можно как-то это обойти со слоями и спец. утилитами, но надо еще изучать.

Прямым конвертированием — нельзя, при "-compress JPEG" ImageMagick ругается (точнее, libjpeg) на непригодные данные на входе, если скармливать ему png с прозрачностью. Однако при использовании сжатия JPEG2000, все конвертируется, с сохранением прозрачности. Аналогично, если использовать ZIP.
Я имел ввиду использовать TIFF/LZW-ZIP + Alpha напрямую в софте. В OS X поддержка TIFF есть изначально, как наследие NeXT. А вот есть ли она iOS?
Использовать можно, хотя и были некоторые репорты о проблемах. Но TIFF/LWZ и TIFF/ZIP менее выгодны, чем PNG, потому интересно только колдовать с TIFF/JPEG и слоями
В геймдеве подобная техника применяется уже давно.
Только файл создается один, где последовательно записаны данные обоих файлов и в начале заголовок о смещениях данных и их размере. Кроме того серую маску можно делать также в jpeg с очень сильным сжатием (20-40%), результат не хуже.
мне казалось, в геймдеве как раз лидирует DXT5 с explicit alpha и другие GPU-поддерживаемые форматы, не требующие перекодировки текстуры и пересоздания mipmaps. Хотя если Вы о мобильных играх, то действительно тут и текстур поменьше, и альтернативы своим решениям почти нет.
А вообще, смещение в заголовке сразу рубит на корню простоту и редактируемость, получается собственный формат без возможности просмотра, требующий отдельных утилит и пр. В таком случае можно действительно и JPEG2000 уже использовать.
В таком случае рекомендую для iOS формат PVRTC или просто PVR. Это своего рода аналог DDS/DXT но для чипов PowerVR, которые повсеместно стоят в яблочных девайсах.
Я потому и писал, что на мобильных альтернативы собственным решениям почти нет — PVRTC уж очень lossy, как и ETC. Чистый PVR с GZ сжатием хоть как-то еще дают приемлемые размеры, но все-равно для 2D игр, где не нужны mipmaps лучше таки потратить секунду-другую на загрузку PNG или реконструкцию текстуры из JPEG+маска, это будет в разы оптимальнее по качеству/размеру.
Полностью с вами согласен, если важен размер на диске. Если важна скорость загрузки, то у PVR нет конкурентов. Даже загрузка PVR из ZIP происходит быстрее загрузки из PNG.
Первый вопрос, как сторонника стандартов: почему шаманство с JPEG, а не JNG?
1. Разве iOS и другие моб. платформы нативно поддерживают JNG? С разумным временем загрузки, подхватыванием Retina тегов @2x и пр.? Я находил стороннюю библиотеку по работе с JNG на github, но не стал бы рисковать встраивать ее в рабочий и отлаженный проект, в то время как с CGImageRef::initWithMask изменение кода минимально и работает идеально.

2. Удобство использования. Можно просматривать видим в любом просмотрщике маску и RGB данные, ретушировать при необходимости, исправлять баги, менять степень сжатия.

3. Оптимизации. Утилит, аналогичных jpegrescan для JNG еще просто не существует, надо писать свои.

В целом, подход точно такой же, как в JNG формате — различные потоки для альфа и RGB канала, но без соединения в один контейнер. Если Apple/Google/MS/etc. начнут использовать JNG — можно перейти даже без особой переконверсии, склеиванием с формированием заголовка.
Ну, 1 пункт весомый. Хотя, libmng сложно портировать?
2. Не критично, всю разработку можно вести в PNG, а в JNG только финальный этап.
3. jpegrescan сделает поток JPEG его и надо будет «поместить» в JNG. Или просто подбор параметров.
Впрочем, п.1 достаточно.
Портировать наврядли очень сложно… В конце концов, можно и вариант с github вычистить, отладить до блеска и использовать в продакшене. Но все-таки это время и усилия, а отдача не очень большая по сравнению с велосипедами вроде JPEG+PNG.
В целом, хотелось бы нативной поддержки JNG или чего-то вроде от самой ОС. Я бы, как и наверняка многие разработчики, с удовольствием перевел все проекты на него с заметным уменьшением размеров картинок.
libmng написанно на c, собирается в gcc нормально, из зависимостей тянет за собой zlib, jpeglib
После статьи по jng на хабре — немного поигрался с этим делом.
Я так понял, что сложности потом это скормить UIImage. Хотя CGImage под OSX создавал из буфера, а UIImage по идее потом на основе CGImage создать не проблема. Но, в любом случае, не 5 строчек кода уже получается. Хотя я бы предпочёл именно JNG.
Тут конечно не совсем то, про что автор пишет, но может кому сгодится. Работает и в ИЕ6.
Only those users with full accounts are able to leave comments. Log in, please.