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

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

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

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



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

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

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

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

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

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

Читать дальше на webo.in →
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 40

    0
    По моим ощущениям, при сжатии с одинаковыми параметрами качества в Photoshop:

    — Размер progressive 3-pass был на 2-3% меньше, чем обычного
    — Скорость отображения была где-то в полтора раза меньше (видимо, за счёт того, что макроблоки рендерятся при каждом проходе, а не один раз).

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

    Про ваши тесты на ноутбуке: как собран ImageMagick? По крайней мере, когда собираешь его в Linux, можно задействовать SIMD-расширения типа mmx, и это ощутимо его ускоряет.
      +1
      >IE и последовательные JPEG
      к сожелению это почти сводит на нет использование послед изображений =((
        +3
        Не сведёт и не сводит — они часто используются уже сегодня и использовались пять лет назад.
        Отображается? Отображается. Полностью? Полностью. Правильно? Правильно. Быстро? Без специальных измерений разницу между отображением не заметить, да и не факт, что она не окажется в пользу прогрессивных.
        Что ещё надо?

        Зато в других браузерах удобнее.
        0
        а на php можно как то создавать последовательные через GD?
          0
          На php можно использовать вышеупомянутый ImageMagick: www.magickwand.org/
            –1
            GD…
            0
            хм… уже нашел :)
            imageinterlace — Enable or disable interlace
              0
              на php можно использовать вышеупомянутый jpegtran :)
              shell_exec
              0
              ага давайте еще поминусуйте, просишь на GD, пишут что попало, а я еще и крайний, лол!
              +1
              Речь идет про все существующие IE, в том чилсе IE8?
                0
                мне помнится 11.5лет назад я видел последовательные в ie — наверное не ко всем ;)
                0
                По-моему для пользователя лучше:
                Для больших картинок — последовательные.
                Для маленьких — базовый.
                • НЛО прилетело и опубликовало эту надпись здесь
                  0
                  Неплохо было бы изображение с примером последовательного JPEG'а сделать действительно последовательным JPEG'ом, для большей наглядности, так сказать :-)
                    +1
                    Я бы отметил что последовательные изображения, особеенно при большой площади, требуют горадо больше времени на декодирование, так как их приходится рендирить по три-четыре раза, каждый раз всё с более лучшей детализацией.
                    Для картинок, расположенных просто на странице это не является большой проблемой, но в одном проекте мне пришлось отказаться от использования последовательных изображении из-за катастрафического подения скорости анимации во время не загоруженных картинок.
                      0
                      Спасибо, интересно и обстоятельно изложили.
                        +5
                        Вспоминается «движение» времен расцвета dial-up'а «За то, чтобы картинки грузились снизу!» :-)
                          0
                          Bmp грузятся :)
                          +11
                          Автором статьи (не перевода) проделан огромный, но по своей сути мартышкин труд.

                          Начиная с осознания того факта что разные JPEGи c одинаковой таблицей квантования жмут одинаково (если говорить точнее, то после квантования остается одинаковое число одинаковых DCT-гармоник), разница может заключатся только в другом расположении информации внутри файла, т.е. перестановке одних и тех же данных. (плюс в progressive имеются незначительные накладные расходы на каждую строку макроблоков)

                          Во-вторых, автором упомянута оптимизация «таблицы Хафмана». Но, почему то, только для baseline формата. Где же чистота эксперимента, почему нельзя улучшить энтропийную компрессию для progressive? Раз уж данные которые находятся в файле одни и те же (= частоты кодовых слов совпадают), то оптимальная таблица Хаффмана будет одинаковой для обоих форматов.

                          Плюс к тому в условиях «экспериментов» закралась досадная систематическая ошибка — он берет уже скомпрессированные JPEGи в качестве исходных данных. Что значит в исходных данных уже убиты многие DCT-гармоники, но данный господин упорно продолжает домучивать оставшиеся.
                          На мой взгляд, если хочешь сравнить два разных «чего-нибудь» — бери самые лучшие исходные материалы (в нашем случае некомпрессированные картинки, например BMP), применяй свои «что-то»
                          и проверяй какая получилась разница между исходным и выходным.

                          Короче, на мой сугубо непрофессиональный взгляд не самого последнего лоха в сигнал процессинге — данная статья абсолютно не научная. и Автор не раскрыл, с какой стати прогрессивный формат (который ошибочно обзывается последовательным) должен быть меньше baseline.
                            0
                            Слово «прогрессивный», вообще-то, в русском языке уже имеет значение и оно ни раком, ни боком не является даже близким переводом соответствующего слова в соответствующем словосочетании. Хотя и «последовательный формат» — тоже не лучший вариант, конечно.
                            В остальном — почти полностью согласен с вами. Почти — поскольку ваши замечания, являясь логически непротиворечивыми, не объясняют таки почему на больших файлах «последовательный» файл становится меньше, несмотря на отсутсвие опции оптимизации таблиц Хафмана и накладные расходы по разбрасыванию данных по файлу…
                              +1
                              первый ответ что приходит в голову (а их можно сочинить много) — поскольку после оптимизации кодов Хаффмана стандартная таблица уже не подходит, то прога включает в JPEG еще и саму таблицу, которая очень даже не маленькая.

                              Но, по всей видимости, все же размер уменьшается в связи с изменением таблицы квантования. В экспериментах не было элементраной проверки что картинки по-пиксельно совпадают. А раз так, кто его знает что там с ними произошло.
                                +1
                                какой тогда смысл в оптимизации таблицы, если размер возрастёт? Нет, там же указано, что размер после оптимизации уменьшался относительно исходного.
                                Далее, утилита jpegtran предназначена для (цитирую ман) — lossless transformation of JPEG files, поэтому о какой проверке идёт речь? (что так же делает несостоятельным вашу претензию о том, что автор берёт жипеги в качестве исходников — здесь-то как раз всё в порядке — что же ещё ему брать для оптимизации без потерь). В случае imagemajick'а автор делал проверки — изображения не совпадали попиксельно — в статье про это написано.
                                Ну, и напоследок, запуск jpegtran с опциями -progressive и -optimize в моих экспериментах показал, что разницы с просто -progressive нет — либо оптимизация при progressive происходит по умолчанию, либо её невозможно сделать в этом случае по каким-то причинам. Более того, если к progressive файлу применить optimize, то получится файл размером таким же, как если применить optimize к исходному. Забавный результат :) — видимо, вы правы насчёт таблицы (не помню уже спеки — можно ли добавлять там внешнюю таблицу). И, видимо, progressive файлы то ли несовместимы с такой оптимизацией, то ли просто в данной утилите не реализована такая возможность.
                                  0
                                  таблицы хаффмана (как и таблицы квантования) всегда находятся в JPEG
                                  и занимают 16 байт на таблицу (2 AC + 2 DC)
                                    0
                                    На сколько мне позволяет сказать моя эрудированность,
                                    таблица квантования (в большинстве случаев) не включается в файл, ибо есть набор стандартных таблиц, по которым обычно и определяется качество.
                                    Количество элементов в ней: 64, ибо столько коэффициентов в 8x8 DCT, так что я предположу она занимает 64 байта (точно не знаю, разбираться лень)

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

                                    disclaimer.

                                    Честно говоря, я не настолько глубоко знаю формат JPEG чтобы обсуждать каждый бит и каждый оффсет. Факт, который я пытался донести — что в данном конкретном исследовании теория расходится с практикой. Что есть очень подозрительно.
                                      0
                                      >> ибо есть набор стандартных таблиц, по которым обычно и определяется качество.
                                      Они находятся в компрессоре, в декомпрессоре таких таблиц нет.
                                      Таблицы хаффмана восстанавливается декомпрессором из файла, где лежит 16 байтовый массив (на каждую таблицу) в котором содержится количество кодов конкретной длины (1..16 бит)
                                      Таблиц обычно 4 — 2 на яркостную компоненту и 2 на цветовую.

                                  0
                                  по поводу терминов,
                                  по-мне, слово «последовательный» гораздо ближе по смыслу к baseline, чем к progressive
                                  Особенно, если учитывать то, что в baseline макро-блоки хранятся в файле один за другим, т.е. «последовательно» :)

                                  а «прогрессивный формат», в русском понимании этого термина очень даже не плохо звучит
                                    0
                                    Это слово имеет несколько значений. Вам знаком термин «прогрессивная развёртка»? Присоединяюсь к вышестоящему заявлению о некорректности перевода.
                                      0
                                      еще одна калька
                                        +1
                                        Почему калька? Это правильный русский перевод. Если кто подзабыл значение этого слова, загляните в словарь Ушакова:

                                        ПРОГРЕССИ'ВНЫЙ, ая, ое; -вен, вна, вно (книжн.).
                                        1.
                                        Постепенно возрастающий, усиливающийся.
                                        Прогрессивное обложение, п. налог (налоговая система, при к-рой процент обложения увеличивается по мере увеличения дохода; экон.). П. рост безработицы в Германии. Прогрессивное развитие болезней.
                                        2.
                                        Политически, общественно передовой, стремящийся к прогрессу.
                                        … Освобождение Испании от гнета фашистских реакционеров не есть частное дело испанцев, а — общее дело всего передового и прогрессивного человечества. Сталин. Прогрессивные настроения.


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

                                          0
                                          обычно в таких случаях употребляют «прогрессирующий». Но против Ушакова не попрешь… да…
                                            0
                                            прогрессирующая развёртка? =))))
                                        +1
                                        Это новояз, калька и ложный друг переводчика вместе взятые. Так же как «Силиконовая долина». То, что вы назвали «прогрессивной развёрткой» всегда называли построчной и этот термин вполне отражает суть процесса, в отличии от «прогрессивной».
                                        Постепенно возрастающая развёртка? Усиливающаяся развёртка? ;)
                                        Кстати, progressive жпег в терминах imagemagick'а называется interlaced, что в применении к телевидению и развёрткам суть термины ортогональные :).
                                          0
                                          Постепенно прорисовывающаяся :-)

                                          А если серьёзно, то развёртка и тв в данном случае ни при чём, это был просто пример использования слова. Его смысловое значение подразумевает динамический характер явления, когда некое свойство изменяется от минимального значения к максимальному.

                                          Таким образом, загрузка изображения сначала в низком разрешении, которое постепенно увеличивается по мере получения файла, вполне обоснованно называется «прогрессивной». Этимологически употребление этого термина вполне оправданно.
                                            +1
                                            Конечно, развёртка не при чём. И это был пример неправильного употребления дилетантами кальки вместо уже имеющегося устоявшегося профессионального термина. :)
                                            Формально, употребление слова «прогрессивный» в случае жипега оправдано. Формально. Фактически же, слово «прогрессивный», как правило, употребляется всё-таки в значениях «передовой, новаторский». Кроме упомянутого неправильного употребления по отношении к построчной развёртке я сходу и не припомню других случаев. И «прогрессивный паралич» (хотя, паралич, похоже, уже устаревающий, поскольку тут чаще говорят о прогрессирующем) и прогрессивный налог — всё-таки «постепенно увеличивающиеся», а не просто «постепенные» и, тем более, не «постепенно прорисовывающийся» :).
                                            Терминология неустоявшаяся даже в английском (применение по сути антонимов к одному и тому же явлению), что уж говорить о русском. «Последовательный» формат лично мне тоже не нравится, но «прогрессивный» на мой вкус — ещё хуже.
                                      0
                                      «прогрессивный» в русском языке имеет значение «передовой, новаторский». Этот формат, конечно, является передовым, но в статье подчеркивается другая его особенность «progressive load» — «последовательная загрузка» (а не прогрессивная). Именно поэтому выбран термин «последовательный»: чтобы отразить последовательное обновление изображения при поступлении бинарных данных (в отличие от базового — когда она загружается, по сути, один раз: сверху вниз).
                                      0
                                      А чем в среднем отличаются jpeg'и с отрицательной разностью от jpeg'ов с положительной разностью (те что на втором графике)?
                                        0
                                        Автор, вроде, написал, что на глаз не отличить, и он этого не понимает :)

                                        «Довольно тяжело предсказать, будет ли изображение меньше в размере, если сделать его последовательным, просто взглянув на него (или каким-то образом автоматизировав этот процесс). В связи с этим...»
                                        0
                                        jpeg с прогрессивным сжатием либо плохо либо вообще не воспринимается мобилками
                                          0
                                          Мобильные устройства, терминалы, использующие старинные ОС, а так же .swf при динамической подгрузке изображений (во всяком случае до 10-й версии), не понимают progressive jpeg. Но для веб-среды вероятность выигрыша в объеме файла с прогрессивным сжатием достаточно высока.

                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                        Самое читаемое