Comments 34
браво! попробую применить на windows 8
Не думали склеенные файлы сохранять в каком-то своём формате? Это избавило бы от удвоения количества картинок и склеивания налету. Нужно только написать просмотрщик для нового типа файлов в вашем приложении.
Одним из вариантов решения проблемы с увеличившимся вдвое количеством ресурсов может быть настройка пост-билд экшена, которые копирует в бандл прозрачные маски с теми же именами, что и у jpg-файлов.
А не думали использовать что-то аналогичное хромакей? Реализация: При отображении вычислять маску автоматом исходя из того, что некоторый цвет (с небольшим оговоренным допуском) считаем прозрачным. Делаете подложку из зеленого цвета. Все пикселы, в которых уровень зеленого преобладает над уровнем красного и синего считаем прозрачными.
Косяки: Нельзя использовать зеленый. Решение: В случае если картинка уже имеет зеленый цвет — можно оговаривать цвет заранее (например синий или красный). Также можно и с другими цветами но с другим алгоритмом проверки…
Плюсы: нет удвоенного количества файлов. Стандартный формат. Адекватный размер. Простота создания файлов с картинками.
Минусы: возможны появления артефактов в маске, как результат — шум возле картинки…
Косяки: Нельзя использовать зеленый. Решение: В случае если картинка уже имеет зеленый цвет — можно оговаривать цвет заранее (например синий или красный). Также можно и с другими цветами но с другим алгоритмом проверки…
Плюсы: нет удвоенного количества файлов. Стандартный формат. Адекватный размер. Простота создания файлов с картинками.
Минусы: возможны появления артефактов в маске, как результат — шум возле картинки…
Вариант достойный обсуждения. К сожалению, JPEG хранит не RGB картинку, а YCbCr (как и MPEG, DXT1-DXT5 и др.), потому «зеленый» сильно смешается с другими цветами и артефакты перечеркнут всю идею… Ну и восстановление цветового баланса будет потом непростой задачей.
Ну просто исходя из увиденных скриншотов, я решил что маски нужны не с градациями, а в духе есть/нет. Такой вариант пробовал на веб сайтах — работало вполне кошерно. Про RGB говорил т.к. обрабатывал уже распакованную картинку (а она там была именно rgb)
А баланс зачем восстанавливать? или это было сказано по поводу полупрозрачных картинок?
А баланс зачем восстанавливать? или это было сказано по поводу полупрозрачных картинок?
Как раз маски нужны были с градациями. Баланс восстанавливать надо будет, если мы целиком избавимся от одного цвета и заменим его альфа-каналом.
Покажете свой вариант с веб сайтами?
Покажете свой вариант с веб сайтами?
ну на счет сайтов — это я приувеличил: просто попробовал реализовать эффект хромакей наткнувшись на описание работы с canvas — на том все и заглохло… Но в планах есть… Честно :-) вот на чем остановился
Конечно пробовал. Размер 1.8Мб был получен при оптимальном соотношении цвета/качества. Без этого тестовый пример 2.5Мб занимал. Более того, есть методы, которые автоматическим утилитам и не снились, например, разбить изображение на блоки, квантовать каждый из них до 256 цветов и собрать все вместе.
Но все-равно ~400кб размера для такой текстуры и без визуальных потерь только JPEG даст.
Но все-равно ~400кб размера для такой текстуры и без визуальных потерь только JPEG даст.
Круто
А как выглядит джпег, полученный из png с помощью imagemagic?
Для меня, непрограммиста, например загадка, как Флеш жмёт png: они сохраняют прозрачность, но при этом уменьшаются в размере и при диком сжатии покрываются характерными артефактами
А как выглядит джпег, полученный из png с помощью imagemagic?
Для меня, непрограммиста, например загадка, как Флеш жмёт png: они сохраняют прозрачность, но при этом уменьшаются в размере и при диком сжатии покрываются характерными артефактами
Выглядит как джипег со странными областями вокруг объектов, где раньше была прозрачность (остатки работы дизайнера):
JPEG:
runserver.net/temp/data_2.jpg
Маска:
runserver.net/temp/data_2.mask.png
Оригинал:
runserver.net/temp/data_2.png
JPEG:
runserver.net/temp/data_2.jpg
Маска:
runserver.net/temp/data_2.mask.png
Оригинал:
runserver.net/temp/data_2.png
Добавлю маленькую деталь о сжатии JPEG.
ImageMagick позволяет указывать не только quality но еще и chroma subsampling. При его отключении (точнее, установке параметра -sampling-factor 4:4:4 ) смешение цветов при сжатии уменьшается, и параметр quality можно установить меньшим, сохранив менее размытые цвета при большем сжатии.
ImageMagick позволяет указывать не только quality но еще и chroma subsampling. При его отключении (точнее, установке параметра -sampling-factor 4:4:4 ) смешение цветов при сжатии уменьшается, и параметр quality можно установить меньшим, сохранив менее размытые цвета при большем сжатии.
нельзя туда TIFF пихать? Каналов — сколько угодно. Подержка как jpg, так и всяких zip копрессий
В фотошопе если для TIFF ставить галочку «Save Transparency», то JPEG сжатие становится неактивным. Может можно как-то это обойти со слоями и спец. утилитами, но надо еще изучать.
Прямым конвертированием — нельзя, при "-compress JPEG" ImageMagick ругается (точнее, libjpeg) на непригодные данные на входе, если скармливать ему png с прозрачностью. Однако при использовании сжатия JPEG2000, все конвертируется, с сохранением прозрачности. Аналогично, если использовать ZIP.
В геймдеве подобная техника применяется уже давно.
Только файл создается один, где последовательно записаны данные обоих файлов и в начале заголовок о смещениях данных и их размере. Кроме того серую маску можно делать также в jpeg с очень сильным сжатием (20-40%), результат не хуже.
Только файл создается один, где последовательно записаны данные обоих файлов и в начале заголовок о смещениях данных и их размере. Кроме того серую маску можно делать также в jpeg с очень сильным сжатием (20-40%), результат не хуже.
мне казалось, в геймдеве как раз лидирует DXT5 с explicit alpha и другие GPU-поддерживаемые форматы, не требующие перекодировки текстуры и пересоздания mipmaps. Хотя если Вы о мобильных играх, то действительно тут и текстур поменьше, и альтернативы своим решениям почти нет.
А вообще, смещение в заголовке сразу рубит на корню простоту и редактируемость, получается собственный формат без возможности просмотра, требующий отдельных утилит и пр. В таком случае можно действительно и JPEG2000 уже использовать.
А вообще, смещение в заголовке сразу рубит на корню простоту и редактируемость, получается собственный формат без возможности просмотра, требующий отдельных утилит и пр. В таком случае можно действительно и JPEG2000 уже использовать.
В таком случае рекомендую для iOS формат PVRTC или просто PVR. Это своего рода аналог DDS/DXT но для чипов PowerVR, которые повсеместно стоят в яблочных девайсах.
Я потому и писал, что на мобильных альтернативы собственным решениям почти нет — PVRTC уж очень lossy, как и ETC. Чистый PVR с GZ сжатием хоть как-то еще дают приемлемые размеры, но все-равно для 2D игр, где не нужны mipmaps лучше таки потратить секунду-другую на загрузку PNG или реконструкцию текстуры из JPEG+маска, это будет в разы оптимальнее по качеству/размеру.
Первый вопрос, как сторонника стандартов: почему шаманство с JPEG, а не JNG?
1. Разве iOS и другие моб. платформы нативно поддерживают JNG? С разумным временем загрузки, подхватыванием Retina тегов @2x и пр.? Я находил стороннюю библиотеку по работе с JNG на github, но не стал бы рисковать встраивать ее в рабочий и отлаженный проект, в то время как с CGImageRef::initWithMask изменение кода минимально и работает идеально.
2. Удобство использования. Можно просматривать видим в любом просмотрщике маску и RGB данные, ретушировать при необходимости, исправлять баги, менять степень сжатия.
3. Оптимизации. Утилит, аналогичных jpegrescan для JNG еще просто не существует, надо писать свои.
В целом, подход точно такой же, как в JNG формате — различные потоки для альфа и RGB канала, но без соединения в один контейнер. Если Apple/Google/MS/etc. начнут использовать JNG — можно перейти даже без особой переконверсии, склеиванием с формированием заголовка.
2. Удобство использования. Можно просматривать видим в любом просмотрщике маску и RGB данные, ретушировать при необходимости, исправлять баги, менять степень сжатия.
3. Оптимизации. Утилит, аналогичных jpegrescan для JNG еще просто не существует, надо писать свои.
В целом, подход точно такой же, как в JNG формате — различные потоки для альфа и RGB канала, но без соединения в один контейнер. Если Apple/Google/MS/etc. начнут использовать JNG — можно перейти даже без особой переконверсии, склеиванием с формированием заголовка.
Ну, 1 пункт весомый. Хотя, libmng сложно портировать?
2. Не критично, всю разработку можно вести в PNG, а в JNG только финальный этап.
3. jpegrescan сделает поток JPEG его и надо будет «поместить» в JNG. Или просто подбор параметров.
Впрочем, п.1 достаточно.
2. Не критично, всю разработку можно вести в PNG, а в JNG только финальный этап.
3. jpegrescan сделает поток JPEG его и надо будет «поместить» в JNG. Или просто подбор параметров.
Впрочем, п.1 достаточно.
Портировать наврядли очень сложно… В конце концов, можно и вариант с github вычистить, отладить до блеска и использовать в продакшене. Но все-таки это время и усилия, а отдача не очень большая по сравнению с велосипедами вроде JPEG+PNG.
В целом, хотелось бы нативной поддержки JNG или чего-то вроде от самой ОС. Я бы, как и наверняка многие разработчики, с удовольствием перевел все проекты на него с заметным уменьшением размеров картинок.
В целом, хотелось бы нативной поддержки JNG или чего-то вроде от самой ОС. Я бы, как и наверняка многие разработчики, с удовольствием перевел все проекты на него с заметным уменьшением размеров картинок.
libmng написанно на c, собирается в gcc нормально, из зависимостей тянет за собой zlib, jpeglib
После статьи по jng на хабре — немного поигрался с этим делом.
После статьи по jng на хабре — немного поигрался с этим делом.
Sign up to leave a comment.
Используем JPEG с прозрачностью