Когда использовать PNG или JPG при разработке для iPhone?


98

У меня есть приложение, которое отображает кучу изображений в слайд-шоу. Эти изображения будут частью пакета и распространяться вместе с приложением.

Все изображения являются фотографиями или фотографическими и т. Д.

Я читал, что в качестве формата изображения предпочтительнее использовать PNG, но, поскольку версия JPG будет намного меньше, я бы предпочел использовать это.

Есть ли какие-либо рекомендации, какой формат использовать и в каком случае?


Я хотел добавить, что исходные изображения уже все в формате JPG, если это имеет значение.
Maverick,

Ответы:


140

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

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

Используйте JPG для фотографий и для чего-либо большого, а PNG для чего-либо небольшого и / или предназначенного для отображения «до пикселя» (например, маленькие значки) или как часть составного прозрачного наложения и т. Д.


1
Я еще не видел никаких данных о производительности декодирования JPEG, PNG и iPNG. Иногда более сжатый формат лучше из-за уменьшения требуемого количества операций ввода-вывода; Я не уверен, насколько быстра у iPhone флешка. И я бы определенно не сказал, что для декомпрессии PNG требуется «очень мало» энергии; файл Other.artwork выглядит как необработанные растровые данные, предположительно из-за того, что накладные расходы ЦП / памяти при декомпрессии PNG слишком велики для часто используемых компонентов пользовательского интерфейса.
тк.

2
В моем текущем проекте у нас есть очень большие файлы png из-за требования прозрачности. Дисковый ввод-вывод значительно превышает время, затрачиваемое на декодирование jpeg. Имейте в виду, что PNG сжимаются, просто с использованием другого алгоритма.
Джон

2
Подумал, что я бы добавил один дополнительный совет для тех, кто пытается максимизировать производительность изображения. ЕСЛИ у вас есть хорошо сжатые файлы JPG, вы можете заранее загрузить необработанные данные JPG в объекты NSData (возможно, в массив или словарь) и построить JPG, используя UIImage: imageFromData, когда вы хотите отобразить. Данные JPG могут быть в 10-100 раз меньше, чем данные растрового изображения, но это позволяет избавиться от (относительно медленной) части ввода-вывода раньше. Очевидно, будьте осторожны с тем, сколько данных вы кэшируете / предварительно загружаете таким образом.
Найджел Флэк

2
Я нашел некоторые данные о времени комперсии: cocoanetics.com/2012/09/… Кажется, что использование png не быстрее, чем jpg;)
Maciej Kozieł

20

Apple оптимизирует изображения PNG, которые входят в комплект вашего iPhone. Фактически, iPhone использует специальную кодировку, в которой байты цвета оптимизированы для оборудования. XCode обрабатывает эту специальную кодировку за вас, когда вы создаете свой проект. Таким образом, вы видите дополнительные преимущества использования PNG на iPhone, не считая их размера. По этой причине настоятельно рекомендуется использовать PNG для любых изображений, которые появляются как часть интерфейса (в виде таблицы, меток и т. Д.).

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

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


5
В моем тесте оптимизация Xcode фактически сделала файлы медленнее, вероятно, потому, что узким местом является дисковый ввод-вывод, а не процессор.
Kornel

1
«Apple оптимизирует изображения PNG, которые входят в комплект приложений для iPhone» - Означает ли это, что динамически загружаемые PNG не оптимизированы?
Роберт

1
Нет, динамически загружаемые PNG не оптимизированы. Оптимизация в основном заключается в замене порядка байтов с RGBA на BGRA, что и используется графическим чипом iPhone внутри. Дополнительная информация здесь: graphicsoptimization.com/blog/?p=259
Ник Локвуд,

11

Есть одна важная вещь, о которой нужно подумать с PNG. Если в вашу сборку Xcode включен PNG, он будет оптимизирован для iOS. Это называется сжатием PNG. Если ваш PNG загружен во время выполнения, он не будет разрушен. Раздавленные PNG работают примерно так же, как 100% JPG. JPG низкого качества работает лучше, чем JPG более высокого качества. Таким образом, с точки зрения производительности от самого быстрого к самому медленному, это будет JPG низкого качества, JPG высокого качества, PNG Crushed, PNG.

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

http://www.cocoanetics.com/2011/10/avoiding-image-decompression-sickness/


9

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

Из его заключения:

Если вам абсолютно необходим альфа-канал или вам нужно использовать PNG, рекомендуется установить инструмент pngcrush на свой веб-сервер и заставить его обрабатывать все ваши PNG. Почти во всех других случаях высококачественные файлы JPEG сочетают в себе файлы меньшего размера (т.е. более быструю передачу) с более быстрым сжатием и рендерингом.

Оказывается, PNG отлично подходят для небольших изображений, которые вы могли бы использовать для элементов пользовательского интерфейса, но их нецелесообразно использовать для любых полноэкранных приложений, таких как каталоги или журналы. Здесь вы можете выбрать качество сжатия от 60 до 80% в зависимости от исходного материала.

Что касается отображения всего этого, вы захотите повесить экземпляры UIImage, из которых вы однажды нарисовали, потому что в них есть кешированная несжатая версия файла. А если у вас нет визуальной паузы для появления на экране большого изображения, вам придется заранее принудительно выполнить декомпрессию для пары изображений. Но имейте в виду, что для этого потребуется большой объем оперативной памяти, и если вы переусердствуете, это может привести к завершению работы вашего приложения. NSCache - отличное место для размещения часто используемых образов, потому что он автоматически удаляет образы, когда становится мало оперативной памяти.

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


Совершенно верно, и JPEGMini и ImageOptim делают jpeg действительно маленькими!
electronicix384128

7

Просто подумал, что поделюсь немного данными о производительности декомпрессии ...

Я делаю прототип 360-градусного средства просмотра - карусели, где пользователь может прокручивать серию фотографий, сделанных под разными углами, чтобы создать впечатление, что он может плавно вращать объект.

Я загрузил данные изображения в массив NSData, чтобы исключить ввод-вывод файлов из уравнения, но создать NSImage на лету. Тестирование с почти максимальной частотой кадров (~ 25 кадров в секунду) и просмотр в инструментах, я вижу, что приложение явно связано с ЦП, и загрузка ЦП увеличивается примерно на 10%, показывая ~ 275 кб в формате png по сравнению с ~ 75 кб в формате jpg.

Я не могу сказать точно, но я предполагаю, что ограничение ЦП обусловлено общим выполнением программы и перемещением всех данных в памяти, но эта распаковка изображения выполняется на графическом процессоре. В любом случае аргумент производительности JPG и PNG выглядит в пользу JPG, особенно когда принимаются во внимание меньшие размеры файлов (и, следовательно, меньшие размеры объектов в памяти, по крайней мере, в некоторых частях цепочки).

Конечно, все ситуации индивидуальны, ничто не заменит тестирование ...


2
Графический процессор не может распаковывать PNG. Используемый формат deflate не подходит для того типа распараллеливания, который позволяет GPU. Я предполагаю, что декодирование JPG может быть частично ускорено с помощью графического процессора, поскольку здесь задействовано преобразование цветового пространства.
Kornel

5

Я обнаружил огромные различия в производительности анимации при использовании jpeg и png. Например, размещение трех изображений jpeg размером с экран рядом в UIScrollView и горизонтальная прокрутка на iPhone4 приводит к задержке и совершенно неприятной рывке. В непрозрачных png-файлах того же размера прокрутка выполняется плавно. Я никогда не использую jpeg, даже если изображение большое.


1

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


3
Это не касается каких-либо соображений производительности JPG по сравнению с PNG.
daveMac

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.