Comments 40
По моим ощущениям, при сжатии с одинаковыми параметрами качества в Photoshop:
— Размер progressive 3-pass был на 2-3% меньше, чем обычного
— Скорость отображения была где-то в полтора раза меньше (видимо, за счёт того, что макроблоки рендерятся при каждом проходе, а не один раз).
Правда, второй минус нивелируюется скоростью загрузки файла по сети.
Про ваши тесты на ноутбуке: как собран ImageMagick? По крайней мере, когда собираешь его в Linux, можно задействовать SIMD-расширения типа mmx, и это ощутимо его ускоряет.
— Размер progressive 3-pass был на 2-3% меньше, чем обычного
— Скорость отображения была где-то в полтора раза меньше (видимо, за счёт того, что макроблоки рендерятся при каждом проходе, а не один раз).
Правда, второй минус нивелируюется скоростью загрузки файла по сети.
Про ваши тесты на ноутбуке: как собран ImageMagick? По крайней мере, когда собираешь его в Linux, можно задействовать SIMD-расширения типа mmx, и это ощутимо его ускоряет.
>IE и последовательные JPEG
к сожелению это почти сводит на нет использование послед изображений =((
к сожелению это почти сводит на нет использование послед изображений =((
Не сведёт и не сводит — они часто используются уже сегодня и использовались пять лет назад.
Отображается? Отображается. Полностью? Полностью. Правильно? Правильно. Быстро? Без специальных измерений разницу между отображением не заметить, да и не факт, что она не окажется в пользу прогрессивных.
Что ещё надо?
Зато в других браузерах удобнее.
Отображается? Отображается. Полностью? Полностью. Правильно? Правильно. Быстро? Без специальных измерений разницу между отображением не заметить, да и не факт, что она не окажется в пользу прогрессивных.
Что ещё надо?
Зато в других браузерах удобнее.
а на php можно как то создавать последовательные через GD?
На php можно использовать вышеупомянутый ImageMagick: www.magickwand.org/
хм… уже нашел :)
imageinterlace — Enable or disable interlace
imageinterlace — Enable or disable interlace
на php можно использовать вышеупомянутый jpegtran :)
shell_exec
shell_exec
ага давайте еще поминусуйте, просишь на GD, пишут что попало, а я еще и крайний, лол!
Речь идет про все существующие IE, в том чилсе IE8?
По-моему для пользователя лучше:
Для больших картинок — последовательные.
Для маленьких — базовый.
Для больших картинок — последовательные.
Для маленьких — базовый.
Неплохо было бы изображение с примером последовательного JPEG'а сделать действительно последовательным JPEG'ом, для большей наглядности, так сказать :-)
Я бы отметил что последовательные изображения, особеенно при большой площади, требуют горадо больше времени на декодирование, так как их приходится рендирить по три-четыре раза, каждый раз всё с более лучшей детализацией.
Для картинок, расположенных просто на странице это не является большой проблемой, но в одном проекте мне пришлось отказаться от использования последовательных изображении из-за катастрафического подения скорости анимации во время не загоруженных картинок.
Для картинок, расположенных просто на странице это не является большой проблемой, но в одном проекте мне пришлось отказаться от использования последовательных изображении из-за катастрафического подения скорости анимации во время не загоруженных картинок.
Спасибо, интересно и обстоятельно изложили.
Вспоминается «движение» времен расцвета dial-up'а «За то, чтобы картинки грузились снизу!» :-)
Автором статьи (не перевода) проделан огромный, но по своей сути мартышкин труд.
Начиная с осознания того факта что разные JPEGи c одинаковой таблицей квантования жмут одинаково (если говорить точнее, то после квантования остается одинаковое число одинаковых DCT-гармоник), разница может заключатся только в другом расположении информации внутри файла, т.е. перестановке одних и тех же данных. (плюс в progressive имеются незначительные накладные расходы на каждую строку макроблоков)
Во-вторых, автором упомянута оптимизация «таблицы Хафмана». Но, почему то, только для baseline формата. Где же чистота эксперимента, почему нельзя улучшить энтропийную компрессию для progressive? Раз уж данные которые находятся в файле одни и те же (= частоты кодовых слов совпадают), то оптимальная таблица Хаффмана будет одинаковой для обоих форматов.
Плюс к тому в условиях «экспериментов» закралась досадная систематическая ошибка — он берет уже скомпрессированные JPEGи в качестве исходных данных. Что значит в исходных данных уже убиты многие DCT-гармоники, но данный господин упорно продолжает домучивать оставшиеся.
На мой взгляд, если хочешь сравнить два разных «чего-нибудь» — бери самые лучшие исходные материалы (в нашем случае некомпрессированные картинки, например BMP), применяй свои «что-то»
и проверяй какая получилась разница между исходным и выходным.
Короче, на мой сугубо непрофессиональный взгляд не самого последнего лоха в сигнал процессинге — данная статья абсолютно не научная. и Автор не раскрыл, с какой стати прогрессивный формат (который ошибочно обзывается последовательным) должен быть меньше baseline.
Начиная с осознания того факта что разные 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 файлы то ли несовместимы с такой оптимизацией, то ли просто в данной утилите не реализована такая возможность.
Далее, утилита jpegtran предназначена для (цитирую ман) — lossless transformation of JPEG files, поэтому о какой проверке идёт речь? (что так же делает несостоятельным вашу претензию о том, что автор берёт жипеги в качестве исходников — здесь-то как раз всё в порядке — что же ещё ему брать для оптимизации без потерь). В случае imagemajick'а автор делал проверки — изображения не совпадали попиксельно — в статье про это написано.
Ну, и напоследок, запуск jpegtran с опциями -progressive и -optimize в моих экспериментах показал, что разницы с просто -progressive нет — либо оптимизация при progressive происходит по умолчанию, либо её невозможно сделать в этом случае по каким-то причинам. Более того, если к progressive файлу применить optimize, то получится файл размером таким же, как если применить optimize к исходному. Забавный результат :) — видимо, вы правы насчёт таблицы (не помню уже спеки — можно ли добавлять там внешнюю таблицу). И, видимо, progressive файлы то ли несовместимы с такой оптимизацией, то ли просто в данной утилите не реализована такая возможность.
таблицы хаффмана (как и таблицы квантования) всегда находятся в JPEG
и занимают 16 байт на таблицу (2 AC + 2 DC)
и занимают 16 байт на таблицу (2 AC + 2 DC)
На сколько мне позволяет сказать моя эрудированность,
таблица квантования (в большинстве случаев) не включается в файл, ибо есть набор стандартных таблиц, по которым обычно и определяется качество.
Количество элементов в ней: 64, ибо столько коэффициентов в 8x8 DCT, так что я предположу она занимает 64 байта (точно не знаю, разбираться лень)
Но мы поскольку изначально говорили про таблицу хаффмана,
то нужно сказать количество элементов в ней не 64, а столько, сколько может существовать различных кодовых слов при определенном квантовании. А их может быть довольно много.
disclaimer.
Честно говоря, я не настолько глубоко знаю формат JPEG чтобы обсуждать каждый бит и каждый оффсет. Факт, который я пытался донести — что в данном конкретном исследовании теория расходится с практикой. Что есть очень подозрительно.
таблица квантования (в большинстве случаев) не включается в файл, ибо есть набор стандартных таблиц, по которым обычно и определяется качество.
Количество элементов в ней: 64, ибо столько коэффициентов в 8x8 DCT, так что я предположу она занимает 64 байта (точно не знаю, разбираться лень)
Но мы поскольку изначально говорили про таблицу хаффмана,
то нужно сказать количество элементов в ней не 64, а столько, сколько может существовать различных кодовых слов при определенном квантовании. А их может быть довольно много.
disclaimer.
Честно говоря, я не настолько глубоко знаю формат JPEG чтобы обсуждать каждый бит и каждый оффсет. Факт, который я пытался донести — что в данном конкретном исследовании теория расходится с практикой. Что есть очень подозрительно.
>> ибо есть набор стандартных таблиц, по которым обычно и определяется качество.
Они находятся в компрессоре, в декомпрессоре таких таблиц нет.
Таблицы хаффмана восстанавливается декомпрессором из файла, где лежит 16 байтовый массив (на каждую таблицу) в котором содержится количество кодов конкретной длины (1..16 бит)
Таблиц обычно 4 — 2 на яркостную компоненту и 2 на цветовую.
Они находятся в компрессоре, в декомпрессоре таких таблиц нет.
Таблицы хаффмана восстанавливается декомпрессором из файла, где лежит 16 байтовый массив (на каждую таблицу) в котором содержится количество кодов конкретной длины (1..16 бит)
Таблиц обычно 4 — 2 на яркостную компоненту и 2 на цветовую.
по поводу терминов,
по-мне, слово «последовательный» гораздо ближе по смыслу к baseline, чем к progressive
Особенно, если учитывать то, что в baseline макро-блоки хранятся в файле один за другим, т.е. «последовательно» :)
а «прогрессивный формат», в русском понимании этого термина очень даже не плохо звучит
по-мне, слово «последовательный» гораздо ближе по смыслу к baseline, чем к progressive
Особенно, если учитывать то, что в baseline макро-блоки хранятся в файле один за другим, т.е. «последовательно» :)
а «прогрессивный формат», в русском понимании этого термина очень даже не плохо звучит
Это слово имеет несколько значений. Вам знаком термин «прогрессивная развёртка»? Присоединяюсь к вышестоящему заявлению о некорректности перевода.
еще одна калька
Почему калька? Это правильный русский перевод. Если кто подзабыл значение этого слова, загляните в словарь Ушакова:
ПРОГРЕССИ'ВНЫЙ, ая, ое; -вен, вна, вно (книжн.).
1.
Постепенно возрастающий, усиливающийся.
Прогрессивное обложение, п. налог (налоговая система, при к-рой процент обложения увеличивается по мере увеличения дохода; экон.). П. рост безработицы в Германии. Прогрессивное развитие болезней.
2.
Политически, общественно передовой, стремящийся к прогрессу.
… Освобождение Испании от гнета фашистских реакционеров не есть частное дело испанцев, а — общее дело всего передового и прогрессивного человечества. Сталин. Прогрессивные настроения.
◊
Прогрессивный паралич (мед.)
— нервно-психическое заболевание на почве сифилиса, сопровождающееся постепенным параличом отдельных частей тела и расстройством умственных способностей.
Это новояз, калька и ложный друг переводчика вместе взятые. Так же как «Силиконовая долина». То, что вы назвали «прогрессивной развёрткой» всегда называли построчной и этот термин вполне отражает суть процесса, в отличии от «прогрессивной».
Постепенно возрастающая развёртка? Усиливающаяся развёртка? ;)
Кстати, progressive жпег в терминах imagemagick'а называется interlaced, что в применении к телевидению и развёрткам суть термины ортогональные :).
Постепенно возрастающая развёртка? Усиливающаяся развёртка? ;)
Кстати, progressive жпег в терминах imagemagick'а называется interlaced, что в применении к телевидению и развёрткам суть термины ортогональные :).
Постепенно прорисовывающаяся :-)
А если серьёзно, то развёртка и тв в данном случае ни при чём, это был просто пример использования слова. Его смысловое значение подразумевает динамический характер явления, когда некое свойство изменяется от минимального значения к максимальному.
Таким образом, загрузка изображения сначала в низком разрешении, которое постепенно увеличивается по мере получения файла, вполне обоснованно называется «прогрессивной». Этимологически употребление этого термина вполне оправданно.
А если серьёзно, то развёртка и тв в данном случае ни при чём, это был просто пример использования слова. Его смысловое значение подразумевает динамический характер явления, когда некое свойство изменяется от минимального значения к максимальному.
Таким образом, загрузка изображения сначала в низком разрешении, которое постепенно увеличивается по мере получения файла, вполне обоснованно называется «прогрессивной». Этимологически употребление этого термина вполне оправданно.
Конечно, развёртка не при чём. И это был пример неправильного употребления дилетантами кальки вместо уже имеющегося устоявшегося профессионального термина. :)
Формально, употребление слова «прогрессивный» в случае жипега оправдано. Формально. Фактически же, слово «прогрессивный», как правило, употребляется всё-таки в значениях «передовой, новаторский». Кроме упомянутого неправильного употребления по отношении к построчной развёртке я сходу и не припомню других случаев. И «прогрессивный паралич» (хотя, паралич, похоже, уже устаревающий, поскольку тут чаще говорят о прогрессирующем) и прогрессивный налог — всё-таки «постепенно увеличивающиеся», а не просто «постепенные» и, тем более, не «постепенно прорисовывающийся» :).
Терминология неустоявшаяся даже в английском (применение по сути антонимов к одному и тому же явлению), что уж говорить о русском. «Последовательный» формат лично мне тоже не нравится, но «прогрессивный» на мой вкус — ещё хуже.
Формально, употребление слова «прогрессивный» в случае жипега оправдано. Формально. Фактически же, слово «прогрессивный», как правило, употребляется всё-таки в значениях «передовой, новаторский». Кроме упомянутого неправильного употребления по отношении к построчной развёртке я сходу и не припомню других случаев. И «прогрессивный паралич» (хотя, паралич, похоже, уже устаревающий, поскольку тут чаще говорят о прогрессирующем) и прогрессивный налог — всё-таки «постепенно увеличивающиеся», а не просто «постепенные» и, тем более, не «постепенно прорисовывающийся» :).
Терминология неустоявшаяся даже в английском (применение по сути антонимов к одному и тому же явлению), что уж говорить о русском. «Последовательный» формат лично мне тоже не нравится, но «прогрессивный» на мой вкус — ещё хуже.
«прогрессивный» в русском языке имеет значение «передовой, новаторский». Этот формат, конечно, является передовым, но в статье подчеркивается другая его особенность «progressive load» — «последовательная загрузка» (а не прогрессивная). Именно поэтому выбран термин «последовательный»: чтобы отразить последовательное обновление изображения при поступлении бинарных данных (в отличие от базового — когда она загружается, по сути, один раз: сверху вниз).
А чем в среднем отличаются jpeg'и с отрицательной разностью от jpeg'ов с положительной разностью (те что на втором графике)?
jpeg с прогрессивным сжатием либо плохо либо вообще не воспринимается мобилками
Sign up to leave a comment.
Оптимизация изображений, часть 4: последовательные JPEG — быть или не быть?