Comments 13
А можно посмотреть. как эти форматы сжимают градиенты?
В отличие от ETC и S3TC, алгоритм PVRTC не работает с фиксированными блоками пикселей.
Не совсем.
Для PVRTC4bpp — размер блока 4х4, для PVRTC2bpp — 8x4.
Мы на работе использовали данное свойство чтобы править «мух» на границах полу-прозрачных областей в уже сжатых файлах.
Это, кстати, самый огромный минус PVRTC. С удовольствием бы использовали тот же DXT5 (который сейчас принято называть BC3), но, к сожалению, на iOS-устройствах он не поддерживается.
А что скажете о *.tga?
А что можно сказать о Targa?
Формат очень простой, вот нереально простой, чем завоевал популярность у программистов.
Поддерживает черно-белые (1bpp), grayscale (как по русски правильно?), палитризированные (paletted), RGB и RGBA изображения.
Все это счастье еще и может быть пожато обычным RLE (в классическом варианте — строка RLE не должна пересекать ширину изображения)
Жмет, как вы уже поняли, плохо, зато быстро.
Т.к. писать-читать его легко и без всяких библиотек — широко используется как рабочий формат.
Если нет аллергии на сторонние библиотеки — лучше использовать PNG.
/Added:
Наши художники предпочитают, в качестве промежуточного формата, использовать TGA т.к. в фотошопе очень легко работать с его альфа-каналом. С PNG там позамороченнее.
Формат очень простой, вот нереально простой, чем завоевал популярность у программистов.
Поддерживает черно-белые (1bpp), grayscale (как по русски правильно?), палитризированные (paletted), RGB и RGBA изображения.
Все это счастье еще и может быть пожато обычным RLE (в классическом варианте — строка RLE не должна пересекать ширину изображения)
Жмет, как вы уже поняли, плохо, зато быстро.
Т.к. писать-читать его легко и без всяких библиотек — широко используется как рабочий формат.
Если нет аллергии на сторонние библиотеки — лучше использовать PNG.
/Added:
Наши художники предпочитают, в качестве промежуточного формата, использовать TGA т.к. в фотошопе очень легко работать с его альфа-каналом. С PNG там позамороченнее.
Спасибо. Спросил Ваше мнение, потому что уж очень много в опыте реверс-инжиниринга встречал текстуры именно этого формата, а популярность объяснить не мог. Мол, неужто действительно такой хороший формат?
Но, благодаря опыту и Вашей статье, все же сделал вывод, что оптимальнее использовать PNG, его недостатки не столь велики по сравнению с другими знакомыми форматами (для текстур).
Но, благодаря опыту и Вашей статье, все же сделал вывод, что оптимальнее использовать PNG, его недостатки не столь велики по сравнению с другими знакомыми форматами (для текстур).
Не за что ;) Правда я не автор статьи.
Для текстур, все же, я бы советовал использовать hardware-compressed форматы, они и грузятся быстрее, и памяти меньше занимают.
PNG текстуры все равно распакуются и будут использовать памяти столько же, сколько и BMP, к примеру.
PNG /TGA / TIFF и иже с ними в геймдеве чаще всего используются как промежуточные, т.н. uncooked данные.
Для текстур, все же, я бы советовал использовать hardware-compressed форматы, они и грузятся быстрее, и памяти меньше занимают.
PNG текстуры все равно распакуются и будут использовать памяти столько же, сколько и BMP, к примеру.
PNG /TGA / TIFF и иже с ними в геймдеве чаще всего используются как промежуточные, т.н. uncooked данные.
UFO just landed and posted this here
Никогда нельзя сравнивать размер PNG и GPU текстур! PNG это LZW архивный контейнер для формата RAW. К примеру, для несжатой текстуры 2048x2048x32 размер будет составлять 16777216 байт, на диске же она будет занимать столько, насколько сожмет компрессор или PNG конвертер, но в видеопамяти все те же 16 мегабайт. В то же время можно без особых проблем сжать каким-нибудь GZIP текстуру PVRTC 2048x2048x4bpp и получить на диске 300 килобайт вместо фиксированных 2097152 байт, которые все-равно она будет занимать в видеопамяти.
Затем, если уж вы рассматриваете текстуры «на все случаи жизни» (т.е. OpenGL ES 1.1-2.0), то обязательно надо учесть ATITC и 3DC.
Вообще, статья ну уж очень «для маленьких». Сравнение качества без метрик PSNR и SSIM не очень полезно, сравнение размера не актуально без таблиц. Подводные камни для больших файлов в assets вообще не упомянуты. Общий вывод-то для текстур на Android такой: для сжатых текстур без прозрачности можно использовать ETC1, для прозрачных — набор из PVRTC/S3TC/ATITC/3DC в зависимости от поддержки железом (можно разные билды выкладывать и параметрами Manifest ставить). Еще можно заморочиться с поддержкой raw 8-bit paletted, для некоторых игр подходит и занимает 8bpp, довольно удобно. Ну и если качество критично, то используем RGBA8888, в контейнере PNG, PVR, KTX и пр., или без оного вообще.
Ну и если у вас уже OpenGL ES 3.0, то тут надо смотреть на новые технологии — ETC2/EAC, ASTC и пр.
В конце-концов для самых-самых хитрых есть такие странности, как декодирование PVRTC или других текстур на ARM-Neon на лету, чтобы читать их на любом железе, собственные методы сжатия (н-р, храним текстуру 1024x1024 и таблицу, по которой достраивается до 2048x2048, если нужно такое разрешение) и т.д. По этим темам я давно хотел написать статьи и заполнить github различным кодом, но как-то руки не дошли.
Затем, если уж вы рассматриваете текстуры «на все случаи жизни» (т.е. OpenGL ES 1.1-2.0), то обязательно надо учесть ATITC и 3DC.
Вообще, статья ну уж очень «для маленьких». Сравнение качества без метрик PSNR и SSIM не очень полезно, сравнение размера не актуально без таблиц. Подводные камни для больших файлов в assets вообще не упомянуты. Общий вывод-то для текстур на Android такой: для сжатых текстур без прозрачности можно использовать ETC1, для прозрачных — набор из PVRTC/S3TC/ATITC/3DC в зависимости от поддержки железом (можно разные билды выкладывать и параметрами Manifest ставить). Еще можно заморочиться с поддержкой raw 8-bit paletted, для некоторых игр подходит и занимает 8bpp, довольно удобно. Ну и если качество критично, то используем RGBA8888, в контейнере PNG, PVR, KTX и пр., или без оного вообще.
Ну и если у вас уже OpenGL ES 3.0, то тут надо смотреть на новые технологии — ETC2/EAC, ASTC и пр.
В конце-концов для самых-самых хитрых есть такие странности, как декодирование PVRTC или других текстур на ARM-Neon на лету, чтобы читать их на любом железе, собственные методы сжатия (н-р, храним текстуру 1024x1024 и таблицу, по которой достраивается до 2048x2048, если нужно такое разрешение) и т.д. По этим темам я давно хотел написать статьи и заполнить github различным кодом, но как-то руки не дошли.
Добрый день коллега.
Подозреваю что статья действительно писалась «для самых маленьких» — для тех кто далек от темы или только-только постигает азы.
То что не было метрик действительно странно (в статье про сжатие изображений то!).
Немного поправить вас хочу — в PNG используется Deflate алгоритм (не LZW), и поток т.н. raw-deflate — т.е. без zlib-маркеров.
Как я уже писал выше — тут так же упущены такие важные моменты как проблемы полупрозрачных текстур при сжатии в PVRTC (например для UI приходится хранить 2 текстуры — PVRTC4bpp для RGB и PVRTC2bpp для A), и делать 2 выборки в шейдере.
3DC это уже специфика — он больше для специфичных текстур (типа нормалмапов) подходит, и, по сути, является тем же DXT5 (BC3), только сбоку.
PS. А можно спросить у вас про raw 8-bit paletted — в железе поддержки нет, значит приходится эмулировать. Вы палитру передаете юниформом в шейдер (а хватит регистров?), или отдельной текстурой.
Никогда не заморачивался, но вот вы написали — и стало жутко интересно.
Подозреваю что статья действительно писалась «для самых маленьких» — для тех кто далек от темы или только-только постигает азы.
То что не было метрик действительно странно (в статье про сжатие изображений то!).
Немного поправить вас хочу — в PNG используется Deflate алгоритм (не LZW), и поток т.н. raw-deflate — т.е. без zlib-маркеров.
Как я уже писал выше — тут так же упущены такие важные моменты как проблемы полупрозрачных текстур при сжатии в PVRTC (например для UI приходится хранить 2 текстуры — PVRTC4bpp для RGB и PVRTC2bpp для A), и делать 2 выборки в шейдере.
3DC это уже специфика — он больше для специфичных текстур (типа нормалмапов) подходит, и, по сути, является тем же DXT5 (BC3), только сбоку.
PS. А можно спросить у вас про raw 8-bit paletted — в железе поддержки нет, значит приходится эмулировать. Вы палитру передаете юниформом в шейдер (а хватит регистров?), или отдельной текстурой.
Никогда не заморачивался, но вот вы написали — и стало жутко интересно.
На счет LZW я действительно приврал уже, ну то такое дело.
Для UI я бы вообще PVRTC не использовал, но это тоже уже по желанию. Кстати, в актуальных версиях PVRTexTool есть регрессия, из-за которой альфа канал жмется хуже, чем 2-3 года назад. Можно даже сравнить и ужаснуться — раньше еще хоть как-то для UI подходило.
Про 8-bit paletted все проще — он обязателен для стандарта OpenGL ES 1.0 — GL_OES_compressed_paletted_texture, а значит и может быть использован где-угодно. Технически, в железе его зачастую реализуют как эмуляцию, но довольно быструю, потому открытие такой текстуры занимает разумное время.
Для работы надо, чтобы первые 1024 байта занимала палитра из 256 элементов, затем изображение с 8bpp. Грузим как обычно через glCompressedTexImage2D (GL.GL_TEXTURE_2D, 0, GL.GL_PALETTE8_RGBA8_OES, width, height, 0, width*height + 1024, data);
Для UI я бы вообще PVRTC не использовал, но это тоже уже по желанию. Кстати, в актуальных версиях PVRTexTool есть регрессия, из-за которой альфа канал жмется хуже, чем 2-3 года назад. Можно даже сравнить и ужаснуться — раньше еще хоть как-то для UI подходило.
Про 8-bit paletted все проще — он обязателен для стандарта OpenGL ES 1.0 — GL_OES_compressed_paletted_texture, а значит и может быть использован где-угодно. Технически, в железе его зачастую реализуют как эмуляцию, но довольно быструю, потому открытие такой текстуры занимает разумное время.
Для работы надо, чтобы первые 1024 байта занимала палитра из 256 элементов, затем изображение с 8bpp. Грузим как обычно через glCompressedTexImage2D (GL.GL_TEXTURE_2D, 0, GL.GL_PALETTE8_RGBA8_OES, width, height, 0, width*height + 1024, data);
Для UI я бы вообще PVRTC не использовал
К сожалению на iOS-девайсах это единственное что нам доступно, а учитывая разрешения последних iPad'ов — не жать огромные UI-атласы — просто непозволительно.
PS. Про paletted texture — спасибо, как-то упустил это расширение, правда с ходу не могу придумать куда нам это приспособить, но в багаже знаний пригодится ;)
Почему PNG даёт большой размер файлов? Да потому что используется не там где надо. Танчик со второй картинки в PNG как раз будет самым маленьким, нет?
Sign up to leave a comment.
Сжатие текстур в Android: сравнение форматов и примеры кода