Какой формат изображения более эффективен с точки зрения памяти: PNG, JPEG или GIF?

Какой формат изображения более эффективен для экономии памяти? PNG, JPEG или GIF?

68 голосов | спросил Tredecies Nocturne 29 Jam1000000amTue, 29 Jan 2013 08:17:18 +040013 2013, 08:17:18

5 ответов


148

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

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

хранения

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

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

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

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

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

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

, если изображение имеет прозрачность, тогда
    попробуйте pngquant на изображении
    если результаты не являются удовлетворительными, тогда
        вернуться к неквантованному изображению
    конец
    хранить как PNG
еще
    попробуйте сохранить его как JPG с различными настройками качества
    если ни одна настройка не дает изображения приемлемого качества, тогда
        попробуйте pngquant на изображении
        если результаты не являются удовлетворительными, тогда
            вернуться к неквантованному изображению
        конец
        хранить как PNG
    еще
        хранить как JPG
    конец
конец

Совет: можно сохранить некоторые изображения в одном формате, а другие - в другом формате.

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

Память программ

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

Если ваша платформа не имеет выделенной видеопамяти, это не аппаратное ускорение или другие необычные случаи, то следующий раздел о VRAM будет полностью или частично реализован в ОЗУ, но основные принципы будут одинаковыми.

Видеопамять

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

Теперь VRAM, потребляемый вашими изображениями, будет примерно width * height * bitdepth для каждого изображения, загруженного в VRAM. Здесь можно заметить несколько вещей:

  1. Ширина и высота, в которой ваши изображения хранятся в VRAM, не обязательно совпадают с вашими исходными изображениями. Некоторые графические процессоры могут обрабатывать только текстуры с размерами 2, поэтому ваше изображение 320x240 может быть фактически сохранено в пространстве 512x256 в VRAM, при этом неиспользованная память эффективно теряется. Иногда вам даже не разрешается загружать текстуры с размерами, которые не обладают мощностью 2 (например, в GLES1.1).

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

  2. Битдэпт очень важен. Обычно текстуры загружаются в VRAM в 32-разрядный ARGB или 32-разрядный XRGB, но если ваше оборудование может поддерживать 16-битные глубины, и вы не против иметь более низкий бит-бит, вы можете уменьшить вдвое количество VRAM, потребляемого каждым изображением , что может быть интересно рассмотреть.

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

Скорость выполнения

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

  1. Размер изображения (на самом деле, это будет «размер выборки»): самая большая область изображения, которое вы собираетесь нарисовать, тем больше времени потребуется для ее рисования. Оказание огромного изображения в небольшом разделе экрана не очень эффективно, поэтому существует метод под названием mipmapping , который состоит из от торговли VRAM для скорости рендеринга, путем хранения изображений несколько раз с несколькими разрешениями и с использованием самого маленького, который может дать вам необходимое качество в любой момент времени. Mipmapping может выполняться при загрузке изображений, что скажется на скорости загрузки и использовании VRAM или при предварительной обработке (путем ручного хранения разных версий одного и того же изображения или с использованием формата, который поддерживает MIP-карту, например DDS), что будет влиять на хранение и VRAM, но мало повлияет на скорость загрузки.

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

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

ответил Panda Pajama 29 Jpm1000000pmTue, 29 Jan 2013 12:40:04 +040013 2013, 12:40:04
25

Как только изображение загрузится с диска и отформатировано для рендеринга, он будет использовать тот же объем памяти независимо от того, было ли это изображение сохранено на диске с использованием PNG, JPEG или GIF.

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

Это только для их представления на диске. В памяти они будут расширяться в один и тот же формат текстуры, используя тот же объем памяти, независимо от того, сохранили ли вы их на диск как PNG или JPEG или GIF.

ответил Trevor Powell 29 Jam1000000amTue, 29 Jan 2013 09:41:28 +040013 2013, 09:41:28
3

Это зависит.

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

PNG без потерь и наиболее эффективен для пиксельного искусства с четкими линиями и несколькими цветами. Он также поддерживает альфа-прозрачность.

GIF ничего не может сделать PNG не может сделать лучше, за исключением возможности хранить анимации. Но это актуально только в контексте веб-приложений. В разработке игр вы обычно создаете анимацию с помощью спрайта.

Обратите внимание, что при использовании графического движка, такого как Libgdx, он скорее всего распакует изображения сразу после их загрузки, а затем сохранит их в памяти как несжатые значения RGBA. Таким образом, формат изображения имеет значение только для скорости загрузки и имеет пространство на диске (или использование полосы пропускания, когда вы отправляете их по сети).

ответил Philipp 29 Jpm1000000pmTue, 29 Jan 2013 17:02:02 +040013 2013, 17:02:02
2

Я не знаю много о libgdx, но о форматах и ​​графике изображений:

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

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

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

PNG лучше GIF по размеру, скорости и функциям, но если вы хотите эффективно работать с растровыми изображениями, я бы предложил: .PNM.BZ2 ([edit] Из-за различного метода упаковки .PNM.BZ2 не всегда эффективнее, чем .PNG. [/edit])

PNM /PBM /PGM /PAM - это простые форматы растровых изображений с KISS-заголовками в текстовом виде , Использование gzip для них приведет к размеру файла, подобному PNG, поэтому bzip2 - лучшее решение для этого. Если вы собираетесь использовать растровые изображения внутри вашей программы, вы можете использовать сжатые битмапы bzip2 в контейнере .tar или .zip. Если у вас нет bzip2, использование PNM в zip-контейнере (zip с максимальным сжатием) может быть похоже на использование PNG. Таким образом, хранение PNG в ZIP-архиве может иметь только небольшую или не выгодную выгоду - скорее всего, просто увеличит время загрузки изображения.

Кроме того, это хороший выбор для хранения нескольких небольших спрайтов /изображений в одном растровом изображении, особенно когда вам нужно все вместе в одной и той же ситуации.

ответил comonad 29 Jpm1000000pmTue, 29 Jan 2013 18:17:11 +040013 2013, 18:17:11
1

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

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

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

Сжатые данные изображения имеют немного больший смысл, если возможно быстрое аппаратное декодирование. Для нормального отображения, по крайней мере, я помню этот http://en.wikipedia.org/wiki/3Dc. С этим вы можете сэкономить VRAM. Я еще не знаю других примеров аппаратного декодирования.

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

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

ответил Hatoru Hansou 30 Jam1000000amWed, 30 Jan 2013 01:53:37 +040013 2013, 01:53:37

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132