Примечание: ниже перевод заметки "Image Optimization, Part 4: Progressive JPEGHot or Not?" из блога YUI. В ней уже известный по прошлым статьям Stoyan Stefanov рассматривает использование последовательных (progressive) JPEG с точки зрения клиентской оптимизации. Мои комментарии далее курсивом.
В своей предыдущей статье «Оптимизация изображений, часть 3: 4 шага для уменьшения размера файлов» последовательные JPEG-файлы были вскользь упомянуты как одна из возможностей для оптимизации JPEG. Эта статья рассматривает данный вопрос более глубоко, включая результаты проведенного эксперимента над 10000 изображений.
Базовые 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 были больше, чем базовые. Довольно тяжело предсказать, будет ли изображение меньше в размере, если сделать его последовательным, просто взглянув на него (или каким-то образом автоматизировав этот процесс). В связи с этим, любая идея, как будет вести себя изображение в зависимости от пространственных размеров или размера файла, будет весьма ценной.
В поисках какой-либо связи я построил график для полученных результатов, где:
График показывает общее распределение наших результатов, но здесь явно заметен следующий тренд: чем больше JPEG-изображение по размеру, тем выгоднее его сохранять как последовательное.
Если рассмотреть более детально область небольших файлов, чтобы увидеть, где именно последовательные JPEG менее эффективны, то лучше ограничиться размером файлов в 30 Кб. Затем, используя линию тренда из Excel, можно увидеть, где она, собственно, проходит (график с линией тренда приведен под основным графиком).
Распределение последовательных и базовых изображений небольших размеров.
Линия тренда для распределения последовательных и базовых изображений небольших размеров.
Давайте окончательно разберемся с тем, что изображено на верхних графиках:
Скорее всего, где-то в районе 12 Кб лежит более лучшее соотношение получаемых процентов, например, 85% и 90%).
Если вашей целью является «экономия на спичках» (и последовательность действий не так существенна), то лучше опробовать оба случая: базовый и последовательный — и выбрать самый лучший.
Также можно попробовать переводить все изображения, меньшие 10 Кб, в базовый формат, а все остальные в последовательный. Или, что проще, хранить все уменьшенные изображения в базовом формате, а последовательный использовать для всего остального.
Этот раздел можно было бы озаглавить: «Microsoft и весь остальной мир,» — настолько IE не похож на все остальные браузеры.
«О, нет, только не IE!» — именно так вы, наверное, подумали. Но не все так плохо (все еще хуже :). Дело всего лишь в том, что IE не отображает последовательные JPEG последовательно. Он просто замечательно показывает само изображение, но только как оно полностью прибывает к нему. Поэтому в IE базовые JPEG-файлы отображаются быстрее (работает появление изображения сверху вниз), чем последовательные JPEG.
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:
jpegtran выдал 9,04%) и 13,25% для последовательного случая (и 11,45% при использовании jpegtran).И в качестве заключительного аккорда скажу пару слов о статистике для скорости создания JPEG-файлов при использовании описанных выше инструментов. Ниже приведены данные для создания 10К+ изображений при помощи jpegtran и ImageMagick на моем ноутбуке (Windows XP, 2GHz dual CPU, 500 Мб RAM). От самого быстрого до самого медленного результате:
jpegtran (11 изображений в секунду),jpegtran (9 изображений в секунду),favicon.ico — это как?canvas и PNG-картинокcanvas и PNG-картинок
© 2016 ООО ВЕБО