Как стать автором
Обновить

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

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

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

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

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

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

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

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

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

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

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

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

disclaimer.

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

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

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

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


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

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

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

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

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