Статьи Архив статей

Перевод: Мациевский Николай aka sunnybear
Опубликована: 9 декабря 2008

Оптимизация изображений, часть 4: последовательные JPEG — быть или не быть?

Примечание: ниже перевод заметки "Image Optimization, Part 4: Progressive JPEGHot or Not?" из блога YUI. В ней уже известный по прошлым статьям Stoyan Stefanov рассматривает использование последовательных (progressive) JPEG с точки зрения клиентской оптимизации. Мои комментарии далее курсивом.

В своей предыдущей статье «Оптимизация изображений, часть 3: 4 шага для уменьшения размера файлов» последовательные JPEG-файлы были вскользь упомянуты как одна из возможностей для оптимизации JPEG. Эта статья рассматривает данный вопрос более глубоко, включая результаты проведенного эксперимента над 10000 изображений.

Базовые (baseline) и последовательные JPEG

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

Загрузка базовых JPEG

Загрузка базового JPEG-файла в браузере. По нажатию откроется полная версия.

Последовательные JPEG являются другой разновидностью данного формата: они загружаются (как можно понять из названия) последовательно. Сначала вы увидите картинку низкого качества. Затем, по мере поступления графической информации, качество изображения будет постепенно улучшаться.

Загрузка последовательных JPEG

Загрузка последовательных JPEG. По нажатию откроется полная версия.

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

Одной из причин против использования последовательных JPEG, о которой я слышал, будет то, что данные изображения выглядят немного устаревшими, и пользователи могут быть разочарованы, если не раздражены, увидев последовательное отображение. Я не знаю никакого исследования, которое бы фокусировалось на данном аспекте, если вам таковое известно, пожалуйста, прокомментируйте. Мне кажется, что последовательное отображение JPEG воспринимается пользователями как определенное поведение конкретного сайта, как, например, быстрая загрузка содержимого страницы или продолжительная задержка при открытии какой-либо страницы. Сайты настолько различаются в своем поведении, что такое «отклонение» вызывает, скорее, интерес, чем раздражение.

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

Эксперимент

Среди многих бесплатных API, которые предлагает Yahoo! также находится API для поиска картинок. Я использовал его, чтобы найти изображения, которые соответствуют нескольким запросам, например, "kittens", "puppies", "monkeys", "baby", "flower", "sunset"... Всего 12 запросов (удивительно, почему среди этих запросов нет ни одного «взрослой» тематики :). Получив URL изображений, я загружал все файлы и отсекал 4xx и 5xx ошибки и не-JPEG изображения (выяснилось, что некоторые сайты возвращают PNG или даже BMP переименованные под .jpg). После всех чисток у меня оказалось 10360, с которыми я продолжил свою работу. Изображения эти были самых различных размеров и качества и, что более важно, это были реальные изображения, полученные с реальных сайтов.

Имея на руках исходные изображения, я пропускал их через jpegtran дважды, используя следующие команды:

> jpegtran -copy none -optimize source.jpg result.jpg

и

> jpegtran -copy none -progressive source.jpg result.jpg

Первая оптимизировала таблицы Хафмана (Huffman tables) в базовом JPEG (детали описаны в предыдущей статье). Вторая же переводила исходное JPEG-изображения в последовательные.

Давайте посмотрим, что у нас получилось с размерами файлов.

Результаты

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

Douglas Adams — "Всего хорошего, и спасибо за рыбу"

Средний JPEG-файл, полученный в результате этого эксперимента, был 52,07 Кб, что, по-видимому, не является объективным статистическим показателем. Более важным является то, что средний выигрыш при использовании jpegtran для оптимизации изображений без потерь как базовых JPEG был 9,04% по сравнению с изначальным размером (среднее изображение стало 47,36 Кб), а при использовании последовательных JPEG составил 11,45% (46,11 Кб — средний размер изображения).

По-видимому, последовательные JPEG, в среднем, меньше. Но это только в среднем, поэтому совсем не факт. На самом же деле в более 15% случаев (1611 из 10360 изображений) последовательные JPEG были больше, чем базовые. Довольно тяжело предсказать, будет ли изображение меньше в размере, если сделать его последовательным, просто взглянув на него (или каким-то образом автоматизировав этот процесс). В связи с этим, любая идея, как будет вести себя изображение в зависимости от пространственных размеров или размера файла, будет весьма ценной.

В поисках какой-либо связи я построил график для полученных результатов, где:

  • По оси Y отложена разность размеров оптимизированных изображений «базовое минус последовательное», отрицательные числа в этом случае означают, что новое изображение было меньше.
  • По оси X отложены размеры файлов исходных изображений.

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

Последовательные и базовые JPEG-файлы

Если рассмотреть более детально область небольших файлов, чтобы увидеть, где именно последовательные JPEG менее эффективны, то лучше ограничиться размером файлов в 30 Кб. Затем, используя линию тренда из Excel, можно увидеть, где она, собственно, проходит (график с линией тренда приведен под основным графиком).

Распределение последовательных и базовых изображений небольших размеров

Распределение последовательных и базовых изображений небольших размеров.

Распределение последовательных и базовых изображений небольших размеров

Линия тренда для распределения последовательных и базовых изображений небольших размеров.

Заключение

Давайте окончательно разберемся с тем, что изображено на верхних графиках:

  • если ваше JPEG-изображение меньше 10 Кб, то лучше его сохранять в базовом формате (вероятность примерно 75%, что оно будет при этом меньше),
  • для файлов более 10 Кб последовательный JPEG-формат будет давать лучшее сжатие (в 94% случаев).

Скорее всего, где-то в районе 12 Кб лежит более лучшее соотношение получаемых процентов, например, 85% и 90%).

Если вашей целью является «экономия на спичках» (и последовательность действий не так существенна), то лучше опробовать оба случая: базовый и последовательный — и выбрать самый лучший.

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

IE и последовательные JPEG

Этот раздел можно было бы озаглавить: «Microsoft и весь остальной мир,» — настолько IE не похож на все остальные браузеры.

«О, нет, только не IE!» — именно так вы, наверное, подумали. Но не все так плохо (все еще хуже :). Дело всего лишь в том, что IE не отображает последовательные JPEG последовательно. Он просто замечательно показывает само изображение, но только как оно полностью прибывает к нему. Поэтому в IE базовые JPEG-файлы отображаются быстрее (работает появление изображения сверху вниз), чем последовательные JPEG.

Слово об ImageMagick

ImageMagick является замечательным набором утилит командной строки, которые также можно использовать для оптимизации изображений. В отличие от большинства других приложений для обработки изображений, по умолчанию, ImageMagick записывает оптимизированные базовые JPEG (как если бы вы использовали параметр -optimize в jpegtran).

ImageMagick может также вырезать метаданные и записывать последовательные JPEG, поэтому я повторил проведенный выше эксперимент, но только используя ImageMagick вместо jpegtran. Были использованы следующие команды:

>convert -strip source.jpg result.jpg // базовый JPG>convert -strip -interlace Plane source.jpg result.jpg // последовательный JPEG

Выводы после эксперимента с ImageMagick:

  • Линия тренда для базовых и последовательных изображений точно такая же: изображения в 10 Кб или большие в размере лучше оптимизировать при помощи последовательного сжатия.
  • Общий выигрыш в размере больше: среднее уменьшение файла составило 10,85% для базовых JPEG (jpegtran выдал 9,04%) и 13,25% для последовательного случая (и 11,45% при использовании jpegtran).
  • Происходит потеря качества. ImageMagick не производит операций полностью без потери качества. Визуально никаких изменений в изображении заметить не удалось, однако, при помощи инструмента для сравнения изображений можно получить, что попиксельная информация изменилась.

И в качестве заключительного аккорда скажу пару слов о статистике для скорости создания JPEG-файлов при использовании описанных выше инструментов. Ниже приведены данные для создания 10К+ изображений при помощи jpegtran и ImageMagick на моем ноутбуке (Windows XP, 2GHz dual CPU, 500 Мб RAM). От самого быстрого до самого медленного результате:

  1. базовый jpegtran (11 изображений в секунду),
  2. последовательный jpegtran (9 изображений в секунду),
  3. базовый ImageMagick (7 изображений в секунду),
  4. последовательный ImageMagick (5,5 изображений в секунду).

Читать дальше

Все комментарии (habrahabr.ru)