Оптимизация изображений. Уровни сжатия JPG

Для любителей фотографии сезон длится круглый год. За это время можно отснять просто гигантский объём материала, как по количеству единиц кадров, так и по общему весу файлов на диске.

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

Мы не сильно погрешим против истины, если скажем, что фотограф – это человек с фотоаппаратом, талантом и знаниями, плюс своя аудитория.

В конце концов, не только фотографы-профессионалы жаждут презентовать своё творчество зрителям, которые могут стать еще и потенциальными клиентами впоследствии.

Буквально все, у кого есть современные устройства, активно эксплуатируют всемирную паутину для донесения застывших моментов реальности широкой публике.

Так, для хранения большого количества фотографий на компьютере может оказаться полезным графический формат Jpeg2000 - он позволит экономить дисковое пространство.

Но при размещении фотографий высокого качества в интернете, могут появиться определённые трудности.

Общая картина с приличными по скорости интернет-каналами заставляет желать лучшего. А уж высокоскоростная передача данных стационарного (оптика, ADSL и т.д.) и мобильного (UMTS, WiMax, LTE) типов доступна далеко не везде.

Вот ведь ирония: сейчас компания Yota разворачивает в ряде регионов сети 4G, на основе LTE Advanced. В то время, как предшественник - 3G, представлен скорее фрагментарно, ограничиваясь мегаполисами и связывающими их крупными транспортными артериями.

Внушительный процент всех существующих интернет-каналов (радио и проводных) представлен низкоскоростными каналами.

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

Вывод на экран полноразмерного снимка при медленном интернете может достигать минут. Можно ли что-нибудь сделать? Пожалуй, что да.

Progressive JPEG - эффективное использование PJPEG

Речь здесь пойдёт не о каналах и провайдерах и не о тех случаях, когда постятся фотки с мобильника в Контакт. Но если загружаем снимки на 16 Мп в Panoramio, то достаточно пары кликов, чтобы существенно улучшить и скорость загрузки фото, и комфорт для зрителей.

Всё это при том же самом размере файлов и кадров.

Как правило, основная масса фото отправляется на сервер в формате JPEG после предварительной обработки - цвето и яркостная коррекция, обрезка и прочее.

И здесь есть шанс повлиять на ситуацию. При сохранении снимка в JPEG, по умолчанию используется метод Baseline. Снимок, созданный с его применением, в браузере "разворачивается" последовательно сверху донизу - по мере загрузки файла.

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

И так – до победного конца. Но часто пользователь понятия не имеет о том, что находится на загружаемом фото и нужно ли оно ему.

Однако, приходится ждать, пока достаточный для понимания сути снимка объём загрузится.

Избежать такого неудобства для пользователя несложно: технология JPEG имеет ещё один метод построения снимка – прогрессивный метод или Progressive JPEG .

В нём весь массив данных может быть разделён особым образом на несколько групп по частотам либо по разрядам значений пикселей. Количество таких групп можно задать при сохранении файла.

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

При этом грузится сразу весь снимок, но сниженного качества, т.к. передаётся лишь часть информации. Можно не дожидаясь вывода всех групп принять решение – нужен нам этот снимок или нет.

Так, последовательно друг за другом грузятся все группы (в стандарте они называются СКАНЫ):

Каждый новый передаваемый скан последовательно улучшает качество изображения. В конце концов, после передачи ряда сканов – загружается всё фото:

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

В последнее время часто встречаются статьи о том, как не показывать пользователям пустое место на странице, пока там не загрузилось изображение. Подобную технологию можно встретить на сайтах и в приложениях Medium и Facebook .

Когда я первый раз писал о загрузке изображений на Medium , мне было интересно реконструировать используемую этим ресурсом технологию. Я увидел её в действии, когда подключился к медленному интернету в самолёте. Первоначальная загрузка изображения с низкой детализацией и переход к конечному изображению после отложенной загрузки - отличная идея.

Этот приём улучшает восприятие веб-страниц пользователями?

Быстрый рендеринг всегда лучше медленного. Главное — вывести на экран хоть что-то, пусть это и не готовый контент.

Но уверены ли мы в этом? Изучив комментарии на Reddit , я нашёл много интересных (в том числе и негативных) комментариев. Вот два из них:

«Кто и когда решил, что если показывать сначала картинку низкого качества, загрузка будет казаться более быстрой? По мне, так все эти эффекты только отвлекают и выглядят ужасно. Загрузка уж точно не кажется более быстрой. Я все равно не могу понять, что на изображении, пока оно не загрузилось, есть там размытая заглушка или нет».
- dwb , Hacker News

Исследования о восприятии пользователями

Я решил найти научные исследования, которые могли бы подтвердить или опровергнуть позитивное восприятие таких приёмов. Но я не смог найти ни одного, которое бы подтверждало, что размытые изображения повышают «субъективную» скорость загрузки. В этот момент я вспомнил о прогрессивном JPEG .

Назад к основам: прогрессивный JPEG

Уже давно существует встроенная в изображения «технология прогрессивной загрузки». Хороший пример - прогрессивный JPEG .

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

«Изображения в прогрессивном JPEG лучше, потому что они быстрее. Субъективная скорость важнее, чем настоящая скорость . Даже если мы загрузим на сайт слишком много изображений, то с помощью прогрессивного JPEG можно отобразить намного больше информации».

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

Базовое кодирование JPEG — изображения

Прогрессивное кодирование JPEG — изображения

Кодировка JPEG позволяет создавать и свои собственные скрипты сканирования. С их помощью можно сделать изображения, закодированные в гибридном режиме , совмещающем в себе свойства прогрессивного и базового JPEG .

С точки зрения пользователя, методы прогрессивной загрузки, такие как Blur-up и SQIP , похожи на прогрессивный JPEG : сначала браузер показывает изображение с низкой детализацией, а после загрузки заменяет его оригинальным.

Что интересно, большинство JPEG-файлов используют базовый режим. Прогрессивные JPEG-изображения составляют максимум 7% от всех файлов JPEG . Если прогрессивная кодировка субъективно ускоряет загрузку, почему прогрессивный JPEG не получил большего распространения?

Исследование

Мне удалось найти только одно исследование по теме, озаглавленное «Прогрессивный рендеринг изображений: добро или зло?»

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

Согласно результатам этого исследования, людям сложнее воспринимать прогрессивные JPEG , хотя на первый взгляд они и должны улучшать опыт пользователей.

Недавно я упомянул об этом исследовании в дискуссии, посвящённой LQIP («изображениям-заглушкам низкой детализации», от английского Low-Quality Image Placeholders ). Сразу в нескольких ответах прозвучали сомнения в научной строгости исследования :

Многие ставили под сомнение состоятельность этой работы. Она идёт вразрез со всеми общепринятыми представлениями о пользе прогрессивного рендеринга, и пока что никто не представил второго исследования с похожими результатами. Нужно больше данных.

Ограниченное и спорное исследование. Чтобы делать какие-либо выводы, нужны большие объёмы данных.

Получается, что на данный момент существует только одно исследование, и то воспринятое с изрядной долей скепсиса. Возникает вопрос: можно ли измерить субъективную скорость загрузки с помощью существующих инструментов?

Измеряем субъективную скорость загрузки

Представим две следующих раскадровки, записанных с некого сайта:

Схема загрузки одного и того же сайта.

Пользователь субъективно воспринимает версию B как загружающуюся быстрее, чем версия A . Это происходит из-за того, что отдельные части страницы в версии B загружаются быстрее, чем в версии А.

В некотором роде это похоже на ситуацию с прогрессивными изображениями, только в более крупном масштабе - загрузить контент как можно быстрее, пусть и неокончательную его версию.

Чтобы оценить, как быстро загружается страница, сегодня используются такие показатели, как индекс скорости (Speed Index ). Он измеряет процент того, насколько визуально закончена загрузка страницы. Чем ниже результат, тем лучше:

Формула индекса скорости

Изначально Speed Index измерял прогресс, сравнивая изменения в гистограммах каждого из основных цветов (красного, зелёного и синего ). Этот метод называется «средняя разница гистограмм ». Он помогает избежать ошибок, когда все элементы страницы могут одновременно сдвигаться на несколько пикселей в процессе загрузки. Подробно ознакомиться с работой алгоритма Speed Index можно в разделе документации, посвящённом измерению визуального прогресса .

Я решил испытать, как работает с заглушками низкой детализации тест WebPagetest :

Раскадровка, демонстрирующая степень визуальной завершённости в процентах.

Мы видим, что изображение загружается между 8 и 10 секундами. Размытая заглушка увеличивает процент завершённости с 75 до 83. Загрузка окончательной версии изображения доводит эту цифру до 93%.

Получается, что, согласно алгоритму Speed Index , заглушка вносит свой вклад в визуальную завершённость страницы. Видно и то, что заглушка не воспринимается как завершённая зона.

Speed Index - не единственный способ измерения скорости рендеринга страницы. В инструментах разработчика Chrome есть возможность запустить проверку производительности. Зайдите в меню Audits → Perform an audit → Run audit .

После выполнения проверка выдаёт вот такой отчёт:

Обратите внимание на размытую заглушку, которая затем превращается в финальное изображение.

Один из показателей проверки называется “Perceptual Speed Index ” («Субъективный индекс скорости ») и показывает значение 4,245. Что он означает? Возможно, это то же самое, что и Speed Index из теста WebPagetest ?

Подход Speed Index с измерением схожести пикселей (та самая «средняя разница гистограмм ») имеет свои недостатки. К примеру, он не учитывает визуальную схожесть фигур, цветов и объектов.

Четыре разных фигуры с одинаковым количеством чёрных и белых пикселей.

В большинстве случаев это не сильно повлияет на оценку визуальной завершённости - на практике Speed Index и Perceptual Speed Index в значительной степени совпадают.

«В ходе масштабных исследований (с использованием собранных WebPagetest видеозаписей более чем 500 страниц из мобильного рейтинга Alexa ) мы увидели, что SI и PSI демонстрируют линейную корреляцию с коэффициентом 0,91», - Измерение скорости загрузки видимой части страницы при помощи P erceptual Speed Index (PSI )

Perceptual Speed Index («Субъективный индекс скорости»)

В документации к инструментам Google Lighthouse сказано, что PSI измеряется при помощи модуля Speedline . Он рассчитывает субъективный индекс скорости исходя из тех же принципов, что и обычный индекс скорости. Но при этом учитывает видимый прогресс загрузки, используя SSIM , а не разницу гистограмм.

SSIM («структурное сходство », от английского Structural Similarity ) используется для измерения сходства двух изображений. Этот метод моделирует восприятие изображений человеческим глазом и учитывает, насколько похожи фигуры, цвета и объекты. Но на этом применение SSIM не ограничивается. Интересно использование структурного сходства при оптимизации сжатия изображений. Например, кодировка cjpeg-dssim использует максимальную степень сжатия jpeg и создаёт изображение с SSIM , близким к оригинальному.

В примере, приведенном ниже, показаны SVG-изображения , созданные в Primitive и проверенные в Image SSIM JS . Чем больше фигур мы используем, тем ближе оценка к изначальному изображению, где SSIM = 1 .

От автора: прогрессивные изображения на HTTP2 быстрее отрисовываются на экране, что повышает восприятие производительности. Используйте сканирующие слои JPEG изображений для показа понятного контента при отправке всего лишь 25% от самого изображения. Для максимального увеличения производительности ключевых изображений используйте HTTP2 Server Push для сканирующих слоев JPEG.

Проблемы с изображениями

Изображения очень важны: они завлекают нас, бесят, побуждают к чему-либо. Интернет в известной нам форме зависит от изображений. Изображения составляют ~65% от общего веса страницы, а также они сильно связаны со временем загрузки страницы и индексом скорости. Если коротко, изображения очень тяжелые и все замедляют.

Сжимайте!

Сжатие – лучший способ исправления отрицательного эффекта от загрузки изображений. С помощью сервисов типа ImageOptim от Kornel Lesiński, который использует замечательные библиотеки mozjpeg и pngquant, можно уменьшить вес изображений без визуальных потерь качества. Благодаря библиотекам типа DSSIM мы можем тестировать качество изображений на разных уровнях сжатия.

Плохая новость заключается в том, что даже после сжатия изображений в среднем на ~29% с помощью описанных выше инструментов, а также при использовании других форматов типа WebP, изображения все равно остаются самыми большими файлами на сайте. Ближайший собрат в этом отношении – JS. Нужно найти способ, как быстрее поставлять эти компоненты, чтобы быстрее завлекать пользователя.

Знакомство с многоканальной передачей

Частично вопрос производительности решается с помощью HTTP2. Одно из главных преимуществ данного протокола – многоканальная передача – способность обрабатывать несколько запросов и ответов за раз, используя одно TCP соединение.

Многоканальная передача ускоряет загрузку файлов с сайта. В зависимости от структуры сайта можно выставить приоритет ресурсов при многоканальной передаче: если критическому CSS поставить высокий приоритет, он будет загружаться быстрее через HTTP2. Кроме того, подгружая еще не запрошенные файлы через HTTP2 Server Push, при правильном подходе можно серьезно улучшить восприятие производительности. Более подробно на эту тему чуть ниже.

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

Все прогрессивно

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

Загрузка файлов с сайта через HTTP2 Multiplexing начинается одновременно, и первичные, легковесные слои прогрессивных и чересстрочных изображений начнут отрисовываться намного быстрее, чем последовательно закодированные изображения. Последовательно закодированные изображения отрисовываются наподобие жалюзи: стока за строкой, пока не загрузится все изображение.

Джон Меллор из Google в 2012 году уже говорил о восприятии производительности и индексе скорости при загрузке сканирующих слоев прогрессивных JPEG изображений через HTTP2 Multiplexing. Он экспериментировал с протоколом SPDY, предшественником HTTP2. Сегодня мы можем продвинуть еще дальше его открытие и заставить прогрессивные изображения загружаться еще быстрее.

Возвращаем власть в наши руки или сканирующие файлы

По умолчанию в прогрессивных JPEG изображениях 10 сканирующих слоев. То есть для загрузки изображения с исходным качеством проходит 10 итераций с загрузкой слоев с информацией. Первый слой JPEG изображений всегда имеет высокую пикселизацию и зачастую выполнен в черно-белом варианте для экономии на цветовых каналах. Хотите узнать, как выглядят все слои? Воспользуйтесь инструментом jsk от Frédéric Kayser, в котором прогрессивное изображение можно разбить на отдельные слои.

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

Современные тенденции и подходы в веб-разработке

Узнайте алгоритм быстрого роста с нуля в сайтостроении

В отличие от PNG изображений, где для создания черессточных слоев используется фиксированный метод кодировки Adam7, JPEG кодировки можно расширить директивами: флаг «-scans» для кодировок JPEG. С mozjpeg флаги можно использовать следующим образом: «cjpeg -quality 75 -scans customscans.txt -outfile output.jpg input.jpg». Кодеры JPEG принимают текстовые файлы с вашими командами для создания слоев.

Каждая строка в сканирующих файлах задает новый сканирующий слой. Каждый слой хранит много информации о цветовом канале, индексе матрицы и потерях.

В сканирующем файле есть три канала – яркость (Y), синий (Cb) и красный (Cr) под номерами 0, 1 и 2 соответственно. Индекс матрицы в файле начинается с 0 и идет до 63, покрывая блок в 64 пикселя (кодировка JPEG имеет блок 8х8).

Креативим

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

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

Скрипт сканирования выше – лишь один пример настройки кодировки прогрессивных JPEG изображений: используя этот подход, можно воссоздать технику LQIP от Guy Podjarny в прогрессивных изображениях JPEG, как показал Jon Sneyers.

Push! Push! Push!

Для еще более быстрой загрузки изображений в HTTP есть еще один инструмент — Server Push. На серверах с поддержкой HTTP2 есть возможность помечать отдельные слои прогрессивных JPEG изображений высоким приоритетом, что заставит сервер передать эти слои в Push-кэш браузера пользователя еще до самого запроса на изображение. Браузеры могут выстраивать структуру страницы и отрисовывать первичные слои изображения из кэша, ускоряя тем самым для пользователей воспринимаемую отрисовку изображений.

Более подробно изучить HTTP2 Server Push можно в замечательной статье в разделе Performance Advent Calendar .

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

Заключение

Благодаря многоканальной передаче через HTTP2, прогрессивные и чересстрочные изображения отрисовываются гораздо быстрее.

Управление созданием прогрессивных JPEG изображений может дать пользователю лучший визуальный опыт.

HTTP2 Server Push может улучшить восприятие производительности важных изображений.

Продолжаем начатый разговор об оптимизации изображений. Оптимизировать (сжимать) мы можем не только сторонние изображения, с которыми что-то сделали или те изображения авторами которых мы являемся, но и просто открывать их в Фотошоп с одной лишь целью - оптимизации.

Это могут быть, например, памятные фотографии с праздника или отдыха, которые мы хотим хранить на диске самого компьютера или съёмных носителях (флэш-накопители, жёсткие внешние диски).

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

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

Итак, изображение в Фотошоп готово к сохранению в формате отличном от формата Фотошоп, то есть оптимизации. Если во вкладке «Файл» верхнего меню мы выберем опцию «Сохранить», то, допустим это наше творение, сохранится в формате PSD, то есть файл будет «фотошоповским». Но выбрав другую опцию, которая присутствует в подавляющем большинстве компьютерных программ и именуется «Сохранить как», то в этом случае у нас появляется возможность выбора, - каким типом файла быть нашему творению за пределами Фотошоп:

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

Это окошко откроется перед нами с уже установленными самим Фотошоп настройками. Мы можем, ничего не предпринимая, с ними согласиться нажатием кнопки «Ок». И при таких наших действиях мы можем «спать спокойно» (юмор), процедура оптимизации прошла успешно. А можем в процессе оптимизации и поучаствовать. Давайте увеличим масштаб видимости до 200%, закрыв предварительно открытое окошко регулировки уровня сжатия:

(Расположение кнопки выбора масштаба для версий CS4, CS5).

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

Изменение масштаба видимости было произведено для того, чтобы лучше видеть, что происходит с изображением, когда мы меняем настройки. Можем процент масштаба сделать ещё больше, а можем и вовсе этого не делать.

Итак, окно настроек перед глазами и мы можем преступать к сжатию изображения:

Для того чтобы видеть как меняется объём файла (изображения) нам нужно, щелчком левой кнопки мыши, поставить галочку в пустом квадратике рядом с надписью «Просмотр». После чего, всё теми же щелчками мыши, выбирать поочерёдно то одну то другую разновидность формата (Базовый стандартный, Базовый оптимизированный, Прогрессивный), дополнительно изменяя и количество шагов (3,4,5):

При всём том, что мы делаем, нам не следует забывать и о самом изображении. Ведь эти регулировки ради него. Поэтому мы не концентрируем всё своё внимание лишь на показателе объёма, а смотрим и на изменения, которые происходят с изображением.

Наши действия по выбору формата оптимизации (сжатия) могут быть дополнены изменением и других параметров изображения:

И опять у нас есть возможность на одном из нескольких параметров остановить свой выбор: Это может быть Низкий, Средний или Высокий, а может и Наилучший. Достаточно одного щелчка кнопкой мышки и варианты к нашим услугам. Мы можем и не раскрывать перечень вариантов, а просто подвигать ползунок - это будет тем же самым выбором из перечня вариантов параметра:

Следя за изменениями изображения и объёма файла, в то время, когда меняем параметры изображения и разновидность формата, мы прекращаем регулировку в тот момент, когда сочтём нужным. То есть тогда, когда по нашему мнению и объём файла достаточно уменьшился и видимой потери качества картинки не произошло. Ну и далее жмём кнопку «Ок», в этом же окошке.

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

Все файлы имеют свою кодировку (код) и именно по коду они и распознаются различными программами и операционными системами. То есть у файлов-изображений свой код, а у файлов-текстов свой, ну и так далее. Эти коды различными программами и операционными системами воспринимаются не одинаково, по этим самым причинам мы можем видеть незначительные отклонения в отображении значений параметров.

Например, мы сжали (оптимизировали) изображение и его объём в Фотошоп таков:

Оптимизированный файл JPG (изображение) я сохраню на рабочем столе компьютера. При наведении курсора на значок файла ОС Windows покажет несколько другое значение.

Стандарт JPEG определяет различные режимы сжатия. Только три из них широко используются:

• Baseline Sequential
• Расширенная Последовательная
• Progressive

Единственное различие в первой находится в ряде таблиц допускается. В противном случае они кодируются и декодируются точно так же.

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

• Последовательный поток JPEG в градациях серого будет иметь одно сканирование.
• Цветовой последовательный поток JPEG может иметь одно или три сканирования.

JPEG принимает 8x8 блоков данных пикселей и применяет дискретное косинусное преобразование к этим данным. 64-пиксельные данные становятся 64 DCT-коэффициентами. Первый коэффициент DCT называется коэффициентом «DC», а другой 63 называется «AC».

Это путаная терминология, основанная на аналогии с постоянным током и переменным током. Коэффициент DC аналогичен среднему значению пикселя блока.

В последовательном JPEG, 64 коэффициента в блоке кодируются вместе (с коэффициентами DC и AC, закодированными по-разному). В Progressive JPEG DC и AC коэффициенты сканируют кодированные битовые поля (настраиваемого размера) в пределах коэффициента. Теоретически у вас может быть отдельное сканирование для каждого бита каждого компонента.

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

Прогрессивное кодирование может быть медленнее, чем последовательное, поскольку вам необходимо сделать несколько проходов над данными.

Вопрос о скорости в прогрессивном декодировании зависит от того, как это делается. Если вы полностью декодируете все изображение, прогрессивный, возможно, будет медленнее, чем последовательный. Если ваш декодер показывает затухание изображения, поскольку он обрабатывает поток, он будет намного медленнее, чем последовательный. Каждый раз, когда вы обновляете дисплей, вам необходимо выполнить обратное преобразование DCT, upsampling и color.

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

Там нет никакой разницы в качестве между прогрессивной и последовательной