Расширение джипег как пишется

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

JPEG (полн. Joint Photographic Experts Group) – один из самых распространенных форматов сжатия графических изображений. У JPEG файла практически отсутствуют какие-либо ограничения по числу цветов (как, например, у GIF). Именно благодаря этому он имеет улучшенные параметры конвертации графических фрагментов. Отличительная особенность фотографий на основе JPEG – это наличие яркой цветовой палитры высокого качества.

Ввиду этого формат JPEG сыскал широкую популярность у пользователей различных Интернет-ресурсов. Можно с большой долей вероятности утверждать, что большинство опубликованных в сети Интернет изображений – это файлы с расширением JPEG. Фото JPEG – 42-х битная цветовая палитра, поддерживающая более 16 млн. цветов.

Диапазон степени сжатия градируется от 10:1 до 20:1. Для выбора такого диапазона может быть использована одна из многочисленных графических утилит, например, ACDSee Photo Manager.

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

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

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

Современный JPEG – кроссплатформенный формат, который одинаково хорошо поддерживается на платформе ОС Windows, Mac или Linux.

Программы для открытия JPEG файлов

Чтобы открыть и изменить JPEG расширения на базе платформы ОС Windows можно воспользоваться самыми разнообразными графическими редакторами, в частности:

  • Photo Viewer;
  • Microsoft Paint;
  • Adobe Photoshop;
  • Adobe Illustrator;
  • CorelDRAW Graphics, Corel PaintShop;
  • ACDSee Photo Manager;
  • Laughingbird The Logo Creator;
  • Roxio Creator;
  • Axel Rietschin FastPictureViewer;
  • Zoner Photo Studio, IrfanView;
  • Adobe Fireworks, PhotoOnWeb;
  • Artweaver;
  • Ability Photopaint.

Файл JPEG также адаптирован для других ОС, например, в Mac ОС расширение может быть открыто для просмотра Apple Preview, ACDSee Pro for Mac, Roxio Toast, Fireworks for Mac или Flare for Mac.

Но базе платформы ОС Linux JPEG поддерживает работу с GIMP и Gwenview. Также, открыть формат JPEG онлайн может любой интернет-браузер.  

Примечательно, что разработчики программных продуктов предусмотрительно позаботились о создании универсального ПО (кроссплатформенного ПО), адаптированного для интеграции на любую ОС: Paint.NET, GIMP, Easy-PhotoPrint EX.

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

  • поврежден или инфицирован файл;
  • файл не связан с реестром ОС (выбрано некорректное приложение для воспроизведения или не произведена инсталляция конкретного редактора);
  • недостаточно ресурсов устройства или ОС;
  • поврежденные или устаревшие драйвера.

Конвертация JPEG в другие форматы

JPEG – один из самых неприхотливых для конвертации форматов. Перевод может произвести конвертер JPEG, например, Adobe Photoshop или CorelDRAW.

Также, преобразовать онлайн HEIC файлы в Jpeg можно с помощью сервиса Heic to jpeg (поддерживает русский язык).

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

  • JPEG -> DJV;
  • JPEG -> ICON;
  • JPEG -> DJVU;
  • JPEG -> EPS.
  • JPEG -> ODG;
  • JPEG -> PDF;
  • JPEG -> BMP;
  • JPEG -> PNG.
  • JPEG -> GIF;
  • JPEG -> GP5.

Почему именно JPEG и в чем его достоинства?

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

JPEG (произносится «джейпег»[1], англ. Joint Photographic Experts Group, по названию организации-разработчика) — один из популярных растровых графических форматов, применяемый для хранения фотографий и подобных им изображений. Файлы, содержащие данные JPEG, обычно имеют расширения (суффиксы) .jpg (самое популярное), .jfif, .jpe или .jpeg. MIME-тип — image/jpeg.

Расширение джипег как пишется

Фотография заката в формате JPEG с уменьшением степени сжатия слева направо

Алгоритм JPEG позволяет сжимать изображение как с потерями, так и без потерь (режим сжатия lossless JPEG).
Поддерживаются изображения с линейным размером не более 65535 × 65535 пикселов.

В 2010 году с целью сохранения для потомков информации о популярных в начале XXI века цифровых форматах учёные из проекта PLANETS заложили инструкции по чтению формата JPEG в специальную капсулу, которую поместили в специальное хранилище в швейцарских Альпах[2].

Область применения[править | править код]

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

Формат JPEG в режиме сжатия с потерями малопригоден для сжатия чертежей, текстовой и знаковой графики, где резкий контраст между соседними пикселами приводит к появлению заметных артефактов. Такие изображения целесообразно сохранять в форматах без потерь, таких как JPEG-LS, TIFF, GIF, PNG, либо использовать режим сжатия Lossless JPEG.

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

JPEG не должен использоваться и в тех случаях, когда недопустимы даже минимальные потери, например при сжатии астрономических или медицинских изображений. В таких случаях может быть рекомендован предусмотренный стандартом JPEG режим сжатия Lossless JPEG (который, однако, не поддерживается большинством популярных кодеков) или стандарт сжатия JPEG-LS.

Сжатие[править | править код]

При сжатии изображение преобразуется из цветового пространства RGB в YCbCr. Стандарт JPEG (ISO/IEC 10918-1) не регламентирует выбор именно YCbCr, допуская и другие виды преобразования (например, с числом компонентов[3], отличным от трёх), и сжатие без преобразования (непосредственно в RGB), однако спецификация JFIF (JPEG File Interchange Format, предложенная в 1991 году специалистами компании C-Cube Microsystems, и ставшая в настоящее время стандартом де-факто) предполагает использование преобразования RGB->YCbCr.

После преобразования RGB->YCbCr для каналов изображения Cb и Cr, отвечающих за цвет, может выполняться «прореживание» (subsampling[4]), которое заключается в том, что каждому блоку из 4 пикселей (2х2) яркостного канала Y ставятся в соответствие усреднённые значения Cb и Cr (схема прореживания «4:2:0»[5]). При этом для каждого блока 2х2 вместо 12 значений (4 Y, 4 Cb и 4 Cr) используется всего 6 (4 Y и по одному усреднённому Cb и Cr). Если к качеству восстановленного после сжатия изображения предъявляются повышенные требования, прореживание может выполняться лишь в каком-то одном направлении — по вертикали (схема «4:4:0») или по горизонтали («4:2:2»), или не выполняться вовсе («4:4:4»).

Расширение джипег как пишется

Пример изображения в формате jpg.

Стандарт допускает также прореживание с усреднением Cb и Cr не для блока 2х2, а для четырёх расположенных последовательно (по вертикали или по горизонтали) пикселей, то есть для блоков 1х4, 4х1 (схема «4:1:1»), а также 2х4 и 4х2 (схема «4:1:0»). Допускается также использование различных типов прореживания для Cb и Cr, но на практике такие схемы применяются исключительно редко.

Далее яркостный компонент Y и отвечающие за цвет компоненты Cb и Cr разбиваются на блоки 8х8 пикселей. Каждый такой блок подвергается дискретному косинусному преобразованию (ДКП). Полученные коэффициенты ДКП квантуются (для Y, Cb и Cr в общем случае используются разные матрицы квантования) и пакуются с использованием кодирования серий и кодов Хаффмана. Стандарт JPEG допускает также использование значительно более эффективного арифметического кодирования, однако из-за патентных ограничений (патент на описанный в стандарте JPEG арифметический QM-кодер принадлежит IBM) на практике оно используется редко. В популярную библиотеку libjpeg последних версий включена поддержка арифметического кодирования, но с просмотром сжатых с использованием этого метода изображений могут возникнуть проблемы, поскольку многие программы просмотра не поддерживают их декодирование.

Матрицы, используемые для квантования коэффициентов ДКП, хранятся в заголовочной части JPEG-файла. Обычно они строятся так, что высокочастотные коэффициенты подвергаются более сильному квантованию, чем низкочастотные. Это приводит к огрублению мелких деталей на изображении. Чем выше степень сжатия, тем более сильному квантованию подвергаются все коэффициенты.

При сохранении изображения в JPEG-файле кодеру указывается параметр качества, задаваемый в некоторых условных единицах, например, от 1 до 100 или от 1 до 10. Большее число обычно соответствует лучшему качеству (и большему размеру сжатого файла). Однако, в самом JPEG-файле такой параметр отсутствует, а качество восстановленного изображения определяется матрицами квантования, типом прореживания цветоразностных компонентов и точностью выполнения математических операций как на стороне кодера, так и на стороне декодера. При этом даже при использовании наивысшего качества (соответствующего матрице квантования, состоящей из одних только единиц, и отсутствию прореживания цветоразностных компонентов) восстановленное изображение не будет в точности совпадать с исходным, что связано как с конечной точностью выполнения ДКП, так и с необходимостью округления значений Y, Cb, Cr и коэффициентов ДКП до ближайшего целого. Режим сжатия Lossless JPEG, не использующий ДКП, обеспечивает точное совпадение восстановленного и исходного изображений, однако его малая эффективность (коэффициент сжатия редко превышает 2) и отсутствие поддержки со стороны разработчиков программного обеспечения не способствовали популярности Lossless JPEG.

Разновидности схем сжатия JPEG[править | править код]

Стандарт JPEG предусматривает два основных способа представления кодируемых данных.

Наиболее распространённым, поддерживаемым большинством доступных кодеков, является последовательное (sequential JPEG) представление данных, предполагающее последовательный обход кодируемого изображения разрядностью 8 бит на компоненту (или 8 бит на пиксель для чёрно-белых полутоновых изображений) поблочно слева направо, сверху вниз. Над каждым кодируемым блоком изображения осуществляются описанные выше операции, а результаты кодирования помещаются в выходной поток в виде единственного «скана», то есть массива кодированных данных, соответствующего последовательно пройденному («просканированному») изображению. Основной или «базовый» (baseline) режим кодирования допускает только такое представление (и хаффмановское кодирование квантованных коэффициентов ДКП). Расширенный (extended) режим наряду с последовательным допускает также прогрессивное (progressive JPEG) представление данных, кодирование изображений разрядностью 12 бит на компоненту/пиксель (сжатие таких изображений спецификацией JFIF не поддерживается) и арифметическое кодирование квантованных коэффициентов ДКП.

В случае progressive JPEG сжатые данные записываются в выходной поток в виде набора сканов, каждый из которых описывает изображение полностью с всё большей степенью детализации. Это достигается либо путём записи в каждый скан не полного набора коэффициентов ДКП, а лишь какой-то их части: сначала — низкочастотных, в следующих сканах — высокочастотных (метод «spectral selection» то есть спектральных выборок), либо путём последовательного, от скана к скану, уточнения коэффициентов ДКП (метод «successive approximation», то есть последовательных приближений). Такое прогрессивное представление данных оказывается особенно полезным при передаче сжатых изображений с использованием низкоскоростных каналов связи, поскольку позволяет получить представление обо всём изображении уже после передачи незначительной части JPEG-файла.

Обе описанные схемы (и sequential, и progressive JPEG) базируются на ДКП и принципиально не позволяют получить восстановленное изображение абсолютно идентичным исходному. Однако стандарт допускает также сжатие, не использующее ДКП, а построенное на основе линейного предсказателя (lossless, то есть «без потерь», JPEG), гарантирующее полное, бит-в-бит, совпадение исходного и восстановленного изображений. При этом коэффициент сжатия для фотографических изображений редко достигает 2, но гарантированное отсутствие искажений в некоторых случаях оказывается востребованным. Заметно большие степени сжатия могут быть получены при использовании не имеющего, несмотря на сходство в названиях, непосредственного отношения к стандарту JPEG ISO/IEC 10918-1 (ITU T.81 Recommendation) метода сжатия JPEG-LS, описываемого стандартом ISO/IEC 14495-1 (ITU T.87 Recommendation).

Синтаксис и структура[править | править код]

Файл JPEG содержит последовательность маркеров, каждый из которых начинается с байта 0xFF, свидетельствующего о начале маркера, и байта-идентификатора. Некоторые маркеры состоят только из этой пары байтов, другие же содержат дополнительные данные, состоящие из двухбайтового поля с длиной информационной части маркера (включая длину этого поля, но за вычетом двух байтов начала маркера, то есть 0xFF и идентификатора) и собственно данных. Такая структура файла позволяет быстро отыскать маркер с необходимыми данными (например, с длиной строки, числом строк и числом цветовых компонентов сжатого изображения).

Основные маркеры JPEG[6]

Маркер Байты Длина Назначение Комментарии
SOI 0xFFD8 нет Начало изображения
SOF0 0xFFC0 переменный размер Начало фрейма (базовый, ДКП) Показывает, что изображение кодировалось в базовом режиме с использованием ДКП и кода Хаффмана. Маркер содержит число строк и длину строки изображения (двухбайтовые поля со смещением соответственно 5 и 7 относительно начала маркера), количество компонентов (байтовое поле со смещением 9 относительно начала маркера), число бит на компонент — строго 8 (байтовое поле со смещением 4 относительно начала маркера), а также соотношение компонентов (например, 4:2:0).
SOF1 0xFFC1 переменный размер Начало фрейма (расширенный, ДКП, код Хаффмана) Показывает, что изображение кодировалось в расширенном (extended) режиме с использованием ДКП и кода Хаффмана. Маркер содержит число строк и длину строки изображения, количество компонентов, число бит на компонент (8 или 12), а также соотношение компонентов (например, 4:2:0).
SOF2 0xFFC2 переменный размер Начало фрейма (прогрессивный, ДКП, код Хаффмана) Показывает, что изображение кодировалось в прогрессивном режиме с использованием ДКП и кода Хаффмана. Маркер содержит число строк и длину строки изображения, количество компонентов, число бит на компонент (8 или 12), а также соотношение компонентов (например, 4:2:0).
DHT 0xFFC4 переменный размер Содержит таблицы Хаффмана Задает одну или более таблиц Хаффмана.
DQT 0xFFDB переменный размер Содержит таблицы квантования Задает одну или более таблиц квантования.
DRI 0xFFDD 4 байта Указывает длину рестарт-интервала Задает интервал между маркерами RST n в макроблоках. При отсутствии DRI появление в потоке кодированных данных маркеров RSTn недопустимо и считается ошибкой. Если при кодировании маркеры RST n не применяются, маркер DRI либо не используется вовсе, либо интервал повторений в нём указывается равным 0.
SOS 0xFFDA переменный размер Начало сканирования Начало первого или очередного скана изображения с направлением обхода слева направо сверху вниз. Если использовался базовый режим кодирования, используется один скан. При использовании прогрессивных режимов используется несколько сканов. Маркер SOS является разделяющим между информативной (заголовком) и закодированной (собственно сжатыми данными) частями изображения.
RSTn 0xFFDn нет Перезапуск Маркеры перезапуска используются для сегментирования кодированных энтропийным кодером данных. В каждом сегменте данные декодируются независимо, что позволяет распараллелить процедуру декодирования. При повреждении кодированных данных в процессе передачи или хранения JPEG-файла использование маркеров перезапуска позволяет ограничить потери (макроблоки из неповреждённых сегментов будут восстановлены правильно). Вставляется в каждом r-м макроблоке, где r — интервал перезапуска DRI маркера. Не используется при отсутствии DRI маркера. n, младшие 3 бита маркера кода, циклы от 0 до 7.
APPn 0xFFEn переменный размер Задаётся приложением Например, в EXIF JPEG-файла используется маркер APP1 для хранения метаданных, расположенных в структуре, основанной на TIFF.
COM 0xFFFE переменный размер Комментарий Содержит текст комментария.
EOI 0xFFD9 нет Конец закодированной части изображения.

Достоинства и недостатки[править | править код]

К недостаткам сжатия по стандарту JPEG следует отнести появление на восстановленных изображениях при высоких степенях сжатия характерных артефактов: изображение рассыпается на блоки размером 8×8 пикселей (этот эффект особенно заметен на областях изображения с плавными изменениями яркости), в областях с высокой пространственной частотой (например, на контрастных контурах и границах изображения) возникают артефакты в виде шумовых ореолов. Стандарт JPEG (ISO/IEC 10918-1, Annex K, п. K.8) предусматривает использование специальных фильтров для подавления блоковых артефактов, но на практике подобные фильтры, несмотря на их высокую эффективность, практически не используются.

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

Скорость сжатия по стандарту JPEG[править | править код]

Для ускорения процесса сжатия по стандарту JPEG традиционно используется распараллеливание вычислений, в частности — при вычислении ДКП. Исторически одна из первых попыток ускорить процесс сжатия с использованием такого подхода описана в опубликованной в 1993 году статье Касперовича и Бабкина[7], в которой предлагалась оригинальная аппроксимация ДКП, делающая возможным эффективное распараллеливание вычислений с использованием 32-разрядных регистров общего назначения процессоров Intel 80386. Появившиеся позже более производительные вычислительные схемы использовали SIMD-расширения набора инструкций процессоров архитектуры x86. Значительно лучших результатов позволяют добиться схемы, использующие вычислительные возможности графических ускорителей (технологии NVIDIA CUDA и AMD FireStream) для организации параллельных вычислений не только ДКП, но и других этапов сжатия JPEG (преобразование цветовых пространств, run-level, статистическое кодирование и т. п.), причём для каждого блока 8х8 кодируемого или декодируемого изображения. В статье[8] была представлена реализация распараллеливания всех стадий алгоритма JPEG по технологии CUDA, что значительно повысило скорость сжатия и декодирования по стандарту JPEG.

См. также[править | править код]

  • JPEG-LS
  • JPEG 2000
  • libjpeg
  • MJPEG
  • MPEG
  • WebP
  • GIF
  • PNG
  • BMP
  • WBMP

Примечания[править | править код]

Ссылки[править | править код]

  • The JPEG committee homepage
  • Спецификация JFIF 1.02 (текстовый файл)
  • Различные способы оптимизации JPG файлов практически без потери качества. Источник
  • Различные способы открытия JPG файлов. Источник

JPEG (JPG) (правильно произносится как «джейпег») — это растровый графический формат изображений и фотографий с высокой степенью сжатия, который имеет расширения .jpg, .jpe, .jpeg или .jfif. Поддерживает большое количество цветов с глубиной 24 бита. Прежде всего формат необходим, чтобы хранить фото на компьютере и загружать в интернет. С ним изображения занимают мало места, сохраняя при этом высокое качество.

Содержание

  1. Особенности формата
  2. Где используется формат JPEG 
  3. Краткая история формата JPEG (JPG)
  4. JPG и PNG — в чем разница 
  5. Достоинства и недостатки формата JPG
  6. Программы и сервисы для работы с JPG
  7. Как открыть поврежденный файл JPG
  8. Программы, преобразующие JPG в другие форматы

Особенности формата

  • Во время сжатия файла есть возможность контролировать потерю качества. Нужно только вручную указать, какой уровень качества вы хотите оставить, когда сохраняете файл в JPEG-формате. Это удобно, если требуется экономить свободное место на диске, поскольку за счет потери качества можно существенно уменьшить размер файла. При этом разница между высоким и очень высоким (100%) качеством не сильно заметна визуально.
  • Есть встроенная поддержка EXIF, которая позволяет хранить метаданные: все настройки камеры, заданные на момент съемки.
  • Изображения в формате JPG можно создавать и сохранять практически во всех графических редакторах. 
  • Расширения .jpg и .jpeg работают одинаково.

Где используется формат JPEG 

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

Оцифрованная иллюстрация в JPEG-формате

В JPEG нередко хранят оцифрованные иллюстрации. Источник

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

В формате JPEG легко хранить и передавать фотографии

В JPEG часто хранят фотографии. Источник

В каких случаях формат JPG не подойдет:

  • если нельзя допустить даже небольшие потери в качестве при сжатии документа;
  • если изображение обрабатывается в несколько этапов, поскольку промежуточный результат каждый раз будет сохраняться с небольшим искажением;
  • если требуется хранить документы с резким контрастом между пикселями (например, чертежи). Для этого зачастую применяются форматы специализированных чертежных CAD-программ.

Краткая история формата JPEG (JPG)

Первые персональные компьютеры уже умели отображать и хранить цифровые изображения, но универсального способа для этого не существовало. К тому же с отправкой этих файлов с одного компьютера на другой тоже были проблемы. В 1986 году эксперты по фотографии со всего мира собрали комитет, чтобы найти удобный и эффективный способ передавать фото и видео, а также разработать процесс сжатия изображений. Его так и назвали «Объединенная группа экспертов по фотографии» (Joint Photographic Experts Group, сокращенно JPEG). Итогом их работы в 1992 году стало создание единого стандарта сжатия цифровых изображений JPEG с возможностью уменьшать размеры файла. У этой группы даже есть свой сайт. 

Сайт «Объединенной группы экспертов по фотографии» или JPEG

Фрагмент официального сайта экспертов с разделами, посвященными всем созданным ими стандартам и программам

В 2010 году ученые проекта PLANETS создали капсулу с инструкцией, как прочитать формат JPG. Так наши потомки смогут узнать о популярных в начале XXI столетия цифровых форматах. Поместили капсулу в специально созданное хранилище в Альпах. 

JPG и PNG — в чем разница 

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

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

На стоке Freepik фотографии можно скачать в JPG-формате

В бесплатном режиме на стоке Freepik фотографии обычно скачиваются в формате JPG

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

на стоке Flaticon иконки можно скачать в PNG-формате

В бесплатном режиме на стоке Flaticon можно скачать иконки только в формате PNG

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

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

Достоинства и недостатки формата JPG

К достоинствам формата JPG относятся следующие.

  • Он обеспечивает корректную работу с цветными изображениями, в которых много переходов цвета и контрастности.
  • Можно самостоятельно настроить размер файла и качество изображения в этом новом размере.
  • Его могут распознавать все браузеры и редакторы. Файлы в JPG-формате отображаются на компьютерах и мобильных устройствах без ошибок.
  • Имеет малый размер файла, поэтому не занимает много места.
  • При незначительном уменьшении размера файла качество почти не ухудшается.
  • Огромный выбор цветовой палитры.

Вот недостатки JPG-формата.

  • Если существенно уменьшить размер картинки, она может сильно исказиться.

Искажение фото при его сохранении в низком качестве и маленьком размере

Пример того, что на фото могут появиться заметные искажения, если попытаться сохранить его в Photoshop в низком качестве и маленьком размере
  • Восстановленный JPG-файл лучше не редактировать после сжатия. Иначе есть риск потери в качестве просмотра.
  • Нельзя сделать фон прозрачным.
  • Необратим процесс потери данных во время сжатия.
  • Чтобы сохранять детализацию, обязательно надо контролировать степень сжатия.
  • Плохо подходит для работы с текстом, слишком контрастным или одноцветным изображением с резкими границами, так как мелкие детали могут пикселизироваться или расплываться. Для этого лучше выбрать другие форматы.

Программы и сервисы для работы с JPG

Если вы не владеете программой Adobe Photoshop, то на помощь могут прийти более простые в освоении аналоги. 

  1. JPEG Wizard. Довольно старая программа, которая работает только с файлами формата JPG. В ней доступны все опции, которые понадобятся, чтобы отредактировать изображение. Есть возможность повернуть, обрезать снимок, поменять его разрешение, настроить цветопередачу. Выбранные картинки можно преобразовать в коллажи. Как только с файлом произойдут какие-то изменения в программе, его размер пересчитается. Большой объем файлов можно редактировать пакетом Batch Editor.

Редактирование изображения в JPEG Wizard

Интерфейс JPEG Wizard. Источник
  1. FastPictureViewer. Платная программа с несложными настройками. Подойдет для фотографов и фоторедакторов. Позволяет работать с почти всеми размерами фотографий. Просмотр, копирование, резервирование, перемещение и удаление файлов можно совершать одновременно. Программа поддерживает много графических форматов, а если подключить дополнительные кодексы, будут доступны специальные форматы типа DDS, PNM и другие. Здесь можно профессионально управлять цветом с помощью ICC v2- и v4-профилей. Доступен 30-дневный пробный период, по окончании которого программа перейдет в режим базовой хоум-версии с ограниченным функционалом.

Редактирование фото в программе FastPictureViewer

Интерфейс FastPictureViewer. Источник
  1. PhotoScape. Бесплатный редактор, упрощенная альтернатива Photoshop. В программе широкий выбор инструментов, позволяющих редактировать и обрабатывать изображения, в том числе кисти. Вы сможете изменить размер, добавить надпись, установить светотеневой баланс. Работайте не только с фотографиями, но и со скриншотами. Из нескольких снимков даже возможно создать анимацию. Имеет интуитивно понятный интерфейс, в котором легко ориентироваться даже новичку. Если ваши файлы изначально в формате RAW, их можно быстро конвертировать в JPG.

Программа PhotoScape для редактирования фото и скриншотов

Интерфейс PhotoScape. Источник
  1. Paint.net. Еще один бесплатный редактор для обработки. Входит в пакет Microsoft.net, поэтому в дополнительной установке не нуждается. У него больше возможностей, если сравнивать с классическим MS Paint. В программе большой каталог фильтров и различных эффектов, например размытие. Есть возможность изменять масштаб изображения, управлять слоями, работать с камерой и сканерами. Поддерживается планшетными компьютерами. 
  2. JPEG Compressor. Позволяет сжимать цифровые изображения в формате JPG в компактные форматы. Это удобно, если вы работаете с фото высокой четкости или если несколько файлов отправляются сразу многим получателям. При этом качество исходного изображения не пострадает. Изменять файлы можно и пакетно.

Как открыть поврежденный файл JPG

Иногда JPG-формат повреждается. На это могут влиять какие-либо ошибки или сбои в программном обеспечении, вирусные атаки, сетевые ошибки или отказ операционной системы. 

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

  • Новичкам подойдет сервис officerecovery. Работать с ним довольно просто. Нажимаем кнопку «Выбрать файл» и находим поврежденный файл на компьютере. Далее восстанавливаем документ через кнопку «Безопасная загрузка и восстановление». У сервиса есть бесплатные и платные возможности загрузки файла после процесса восстановления. 

Сервис officerecovery для восстановления файлов в формате JPG

Простой веб-интерфейс сервиса
  • Еще одна программа — Hetman File Repair. Она предназначена для ПК. Позволяет быстро и безопасно восстановить изображения и фотографии. Сначала у вас будет возможность проверить, насколько эффективно программа сработает в вашем случае. Также есть опция предварительного просмотра восстановленного файла. Если результаты бесплатной версии вас устроят, нужно зарегистрировать программу, чтобы использовать ее дальше.
  • Если файлы повредились при сжатии, можно воспользоваться программой UnJPEG. Позволяет устранить некоторые проблемы (артефакты), а также повысить четкость изображения. Еще в UnJPEG есть фильтр, позволяющий устранять случайные шумы. Программа распознает, чем является изображение (неудачно сжатое фото или рисунок, который плохо сохранили), и на этом основании ищет артефакты в файле.

Программы, преобразующие JPG в другие форматы

  1. JPEG Compressor. Упомянутая ранее программа может не только сжимать изображения, но и конвертировать JPG-файлы в другие популярные форматы, например GIF и BMP. 
  2. FileZigZag. Сервис конвертации изображений, работающий в режиме онлайн. Большое количество как входных форматов, так и тех, в которые программа преобразует. Нужно загрузить исходный файл и выбрать формат, в который нужно конвертировать. Остается дождаться ссылки на готовое изображение. Обычно много времени процесс конвертации не занимает, исключение — файлы большого размера.

Преобразование файла JPEG в PDF в сервисе FileZigZag

Интерфейс FileZigZag интуитивно понятен: выбираем файл, конечный формат и жмем на зеленую кнопку конвертации

Интерфейс FileZigZag интуитивно понятен: выбираем файл, конечный формат и жмем на зеленую кнопку конвертации

  1. ZamZar. Тоже работает в онлайн-режиме. Поддерживает более 1000 известных форматов. Помимо фото конвертирует документы и видео. От некоторых других конвертеров отличается медленным процессом преобразования файлов. Работает с 2006 года. 
  2. Adapter. Программа не только помогает изменить форматы фотографий и других изображений, видео- и аудиофайлов, но также имеет несколько удобных опций. Например, можно изменить разрешение и качество снимков, а также наложить на них текст. Сервис работает очень быстро. Подходит для установки на Windows и Mac.
  3. CoffeeCup PixConverter. Бесплатный онлайн-конвертер изображений. Им удобно пользоваться. Помимо конвертации изображение можно еще и редактировать: повернуть, изменить размер или цвет. В программу одновременно можно загрузить несколько фотографий.
  4. BatchPhoto Espresso. Этот бесплатный редактор работает на любой ОС. Позволяет конвертировать изображения, размер которых не больше 10 Мб. Прежде чем сохранить преобразованный файл, его можно переименовать, выбрать для него размер или приемлемое качество. В BatchPhoto Espresso есть инструменты, с которыми можно поменять яркость или контрастность, а также эффект скручивания и некоторые другие.

Интерфейс программы BatchPhoto Espresso для работы с JPG-форматом

Три этапа работы с картинкой и эффекты, которые можно применить
  1. CoolUtils. С этой программой файлы преобразуются в режиме реального времени, вам не придется ждать ссылку на почту для скачивания готового файла. Перед конвертацией изображение можно повернуть или поменять его размер. 

Конвертация JPEG-файла в PNG в программе CoolUtils

Преобразование JPEG в другие форматы с изменением размера в CoolUtils

JPG – часто используемый графический формат сжатого изображения, разработанный компанией Joint Photo…

JPG – часто используемый графический формат сжатого изображения, разработанный компанией Joint Photographic Experts Group (JPEG). Файлы имеют высокий уровень сжатия и поддерживают глубину цвета в 24 бит. Благодаря этим характеристикам файлы с расширениями JPG/JPEG применяются в цифровых фотоаппаратах, смартфонах, видеокамерах. Несмотря на распространенность формата, у некоторых пользователей возникает вопрос – чем открыть JPG? Рассмотрим различные варианты и возможные сложности.

jpg открыть

Область применения и свойства формата jpg

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

просмотр jpg

Положительные и отрицательные характеристики файла формата jpg

К плюсам формата относятся:

  1. Широкий диапазон уровня сжатия (качество и размер файла зависят от степени сжатия).
  2. Минимальный размер файла.
  3. Согласованность с браузерами и текстовыми редакторами.
  4. Отображение на современных устройствах.
  5. При невысоком уровне сжатия не страдает качество картинки.

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

    открыть файл jpg

    Минусы:

    1. При достаточном уровне сжатия может «развалиться» на блоки пикселей.
    2. Не поддерживает прозрачность.
    3. Не рекомендуется редактировать файл после восстановления. Каждая новая манипуляция снижает качество изображения.

      Чем и как открывать файлы jpg

      Изображения JPG используются повсеместно, поэтому программа для просмотра JPG входит в набор для стандартных опций Windows. В случае, если программа для просмотра фотографий JPG не встроена в операционную систему, файл можно открыть в Microsoft Paint, который есть в списке стандартных программ для Windows.

      как открывать файлы jpg

      Открываем на компьютере

      У рядового пользователя обычно не возникает проблем с вопросом, как открыть файл JPG на компьютере. Большое распространение получили программы для jpg/jpeg файлов. Вот некоторые из них:

      1. STDU Viewer.
      2. Faststone Image Viewer.
      3. XnView.
      4. Picasa.

        Скачать программу для просмотра jpg можно в сети интернет, если она есть в свободном доступе, либо купить лицензионную версию у разработчика. Каждая из них имеет особенности работы с jpg/jpeg файлами.

        не могу открыть jpg файл

        Открыть формат через  Windows 10

        Программа для просмотра JPG для Windows 10 отсутствует в базовом ПО. Однако в случае смены ОС с Windows 7 или 8.1, средство просмотра фотографий может присутствовать на ПК. Существует способ удостовериться, что программы для открытия jpg файлов установлены. Для этого кликните на изображение правой кнопкой мыши и найдите пункт «Открыть с помощью». Далее просмотрите список предложенных средств для просмотра.

        Воспользуйтесь программой для открытия JPG WinAero Tweaker. После запуска утилиты, перейдите в раздел «Windows Accessories» и выберите пункт «Activate Windows Photo Viewer».

        Просмотреть с помощью  Windows 7

        В Windows 7 сразу установлено ПО, которое открывает разноформатные файлы, в том числе и JPG. Если же установлено больше 2-х программ для просмотра и открытия файлов JPG, при двойном щелчке мышки на изображении, откроется программа, установленная по умолчанию. Чтобы открыть формат JPG другой программой из меню «Проводника», выбрать и нажать на кнопку «Открыть с помощью…».

        jpeg открыть

        Онлайн-просмотр

        Открыть файл JPG онлайн и просмотреть фото можно популярными программами:

        1. Apple Фото.
        2. Microsoft OneDrive.
        3. Google Диск.

          Как открыть поврежденный файл jpg?

          Как определить, что файл JPG поврежден? При попытке запуска появляется ошибка (диалоговое окно с сообщением «файл поврежден») или же не открывается вовсе. Тогда используют программы RS File Repair, PixRecovery, JPEGfix для восстановления файлов. Большинство таких программ можно бесплатно скачать в интернете.

          JPEG

          Расширение

          .jpg, .jpeg

          MIME

          image/jpeg

          Сигнатура

          0xFF 0xD8

          Опубликован

          1991 год

          Развит в

          JPEG 2000, JPEG XR, MotionJPEG

          JPEG (произносится «джейпег»[1], англ. Joint Photographic Experts Group, по названию организации-разработчика) — один из популярных графических форматов, применяемый для хранения фотоизображений и подобных им изображений. Файлы, содержащие данные JPEG, обычно имеют расширения (суффиксы) .jpeg, .jfif, .jpg, .JPG, или .JPE. Однако из них .jpg является самым популярным на всех платформах. MIME-типом является image/jpeg.

          Фотография заката в формате JPEG с уменьшением степени сжатия слева направо

          Алгоритм JPEG позволяет сжимать изображение как с потерями, так и без потерь (режим сжатия lossless JPEG). Поддерживаются изображения с линейным размером не более 65535 × 65535 пикселей.

          Содержание

          • 1 Область применения
            • 1.1 Сжатие
            • 1.2 Разновидности схем сжатия JPEG
          • 2 Синтаксис и структура
          • 3 Достоинства и недостатки
          • 4 Производительность сжатия по стандарту JPEG
          • 5 Интересные факты
          • 6 См. также
          • 7 Примечания
          • 8 Ссылки

          Область применения

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

          С другой стороны, JPEG малопригоден для сжатия чертежей, текстовой и знаковой графики, где резкий контраст между соседними пикселами приводит к появлению заметных артефактов. Такие изображения целесообразно сохранять в форматах без потерь, таких как TIFF, GIF или PNG.

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

          JPEG не должен использоваться и в тех случаях, когда недопустимы даже минимальные потери, например, при сжатии астрономических или медицинских изображений. В таких случаях может быть рекомендован предусмотренный стандартом JPEG режим сжатия Lossless JPEG (который, однако, не поддерживается большинством популярных кодеков) или стандарт сжатия JPEG-LS.

          Сжатие

          При сжатии изображение преобразуется из цветового пространства RGB в YCbCr (YUV). Следует отметить, что стандарт JPEG (ISO/IEC 10918-1) никак не регламентирует выбор именно YCbCr, допуская и другие виды преобразования (например, с числом компонентов[2], отличным от трёх), и сжатие без преобразования (непосредственно в RGB), однако спецификация JFIF (JPEG File Interchange Format, предложенная в 1991 году специалистами компании C-Cube Microsystems, и ставшая в настоящее время стандартом де-факто) предполагает использование преобразования RGB->YCbCr.

          После преобразования RGB->YCbCr для каналов изображения Cb и Cr, отвечающих за цвет, может выполняться «прореживание» (subsampling[3]), которое заключается в том, что каждому блоку из 4 пикселов (2х2) яркостного канала Y ставятся в соответствие усреднённые значения Cb и Cr (схема прореживания «4:2:0»[4]). При этом для каждого блока 2х2 вместо 12 значений (4 Y, 4 Cb и 4 Cr) используется всего 6 (4 Y и по одному усреднённому Cb и Cr). Если к качеству восстановленного после сжатия изображения предъявляются повышенные требования, прореживание может выполняться лишь в каком-то одном направлении — по вертикали (схема «4:4:0») или по горизонтали («4:2:2»), или не выполняться вовсе («4:4:4»).

          Стандарт допускает также прореживание с усреднением Cb и Cr не для блока 2х2, а для четырёх расположенных последовательно (по вертикали или по горизонтали) пикселов, то есть для блоков 1х4, 4х1 (схема «4:1:1»), а также 2х4 и 4х2 (схема «4:1:0»). Допускается также использование различных типов прореживания для Cb и Cr, но на практике такие схемы применяются исключительно редко.

          Далее яркостный компонент Y и отвечающие за цвет компоненты Cb и Cr разбиваются на блоки 8х8 пикселов. Каждый такой блок подвергается дискретному косинусному преобразованию (ДКП). Полученные коэффициенты ДКП квантуются (для Y, Cb и Cr в общем случае используются разные матрицы квантования) и пакуются с использованием кодирования серий и кодов Хаффмана. Стандарт JPEG допускает также использование значительно более эффективного арифметического кодирования, однако из-за патентных ограничений (патент на описанный в стандарте JPEG арифметический QM-кодер принадлежит IBM) на практике оно используется редко. В популярную библиотеку libjpeg последних версий включена поддержка арифметического кодирования, но с просмотром сжатых с использованием этого метода изображений могут возникнуть проблемы, поскольку многие программы просмотра не поддерживают их декодирование.

          Матрицы, используемые для квантования коэффициентов ДКП, хранятся в заголовочной части JPEG-файла. Обычно они строятся так, что высокочастотные коэффициенты подвергаются более сильному квантованию, чем низкочастотные. Это приводит к огрублению мелких деталей на изображении. Чем выше степень сжатия, тем более сильному квантованию подвергаются все коэффициенты.

          При сохранении изображения в JPEG-файле указывается параметр качества, задаваемый в некоторых условных единицах, например, от 1 до 100 или от 1 до 10. Большее число обычно соответствует лучшему качеству (и большему размеру сжатого файла). Однако даже при использовании наивысшего качества (соответствующего матрице квантования, состоящей из одних только единиц) восстановленное изображение не будет в точности совпадать с исходным, что связано как с конечной точностью выполнения ДКП, так и с необходимостью округления значений Y, Cb, Cr и коэффициентов ДКП до ближайшего целого. Режим сжатия Lossless JPEG, не использующий ДКП, обеспечивает точное совпадение восстановленного и исходного изображений, однако его малая эффективность (коэффициент сжатия редко превышает 2) и отсутствие поддержки со стороны разработчиков программного обеспечения не способствовали популярности Lossless JPEG.

          Разновидности схем сжатия JPEG

          Стандарт JPEG предусматривает два основных способа представления кодируемых данных.

          Наиболее распространённым, поддерживаемым большинством доступных кодеков, является последовательное (sequential JPEG) представление данных, предполагающее последовательный обход кодируемого изображения поблочно слева направо, сверху вниз. Над каждым кодируемым блоком изображения осуществляются описанные выше операции, а результаты кодирования помещаются в выходной поток в виде единственного «скана», то есть массива кодированных данных, соответствующего последовательно пройденному («просканированному») изображению. Основной или «базовый» (baseline) режим кодирования допускает только такое представление. Расширенный (extended) режим наряду с последовательным допускает также прогрессивное (progressive JPEG) представление данных.

          В случае progressive JPEG сжатые данные записываются в выходной поток в виде набора сканов, каждый из которых описывает изображение полностью с всё большей степенью детализации. Это достигается либо путём записи в каждый скан не полного набора коэффициентов ДКП, а лишь какой-то их части: сначала — низкочастотных, в следующих сканах — высокочастотных (метод «spectral selection» то есть спектральных выборок), либо путём последовательного, от скана к скану, уточнения коэффициентов ДКП (метод «successive approximation», то есть последовательных приближений). Такое прогрессивное представление данных оказывается особенно полезным при передаче сжатых изображений с использованием низкоскоростных каналов связи, поскольку позволяет получить представление обо всём изображении уже после передачи незначительной части JPEG-файла.

          Обе описанные схемы (и sequential, и progressive JPEG) базируются на ДКП и принципиально не позволяют получить восстановленное изображение абсолютно идентичным исходному. Однако стандарт допускает также сжатие, не использующее ДКП, а построенное на основе линейного предсказателя (lossless, то есть «без потерь», JPEG), гарантирующее полное, бит-в-бит, совпадение исходного и восстановленного изображений. При этом коэффициент сжатия для фотографических изображений редко достигает 2, но гарантированное отсутствие искажений в некоторых случаях оказывается востребованным. Заметно большие степени сжатия могут быть получены при использовании не имеющего, несмотря на сходство в названиях, непосредственного отношения к стандарту JPEG ISO/IEC 10918-1 (ITU T.81 Recommendation) метода сжатия JPEG-LS, описываемого стандартом ISO/IEC 14495-1 (ITU T.87 Recommendation).

          Синтаксис и структура

          Файл JPEG содержит последовательность маркеров, каждый из которых начинается с байта 0xFF, свидетельствующего о начале маркера, и байта-идентификатора. Некоторые маркеры состоят только из этой пары байтов, другие же содержат дополнительные данные, состоящие из двухбайтового поля с длиной информационной части маркера (включая длину этого поля, но за вычетом двух байтов начала маркера то есть 0xFF и идентификатора) и собственно данных. Такая структура файла позволяет быстро отыскать маркер с необходимыми данными (например, с длиной строки, числом строк и числом цветовых компонентов сжатого изображения).

          Основные маркеры JPEG[5]

          Маркер Байты Длина Назначение Комментарии
          SOI 0xFFD8 нет Начало изображения
          SOF0 0xFFC0 переменный размер Начало фрейма (базовый, ДКП) Показывает что изображение кодировалось в базовом режиме с использованием ДКП и кода Хаффмана. Маркер содержит число строк и длину строки изображения (двухбайтовые поля со смещением соответственно 5 и 7 относительно начала маркера), количество компонентов (байтовое поле со смещением 8 относительно начала маркера), число бит на компонент (байтовое поле со смещением 4 относительно начала маркера), а также соотношение компонентов (например, 4:2:0).
          SOF1 0xFFC1 переменный размер Начало фрейма (расширенный, ДКП, код Хаффмана) Показывает что изображение кодировалось в расширенном (extended) режиме с использованием ДКП и кода Хаффмана. Маркер содержит число строк и длину строки изображения, количество компонентов, число бит на компонент, а также соотношение компонентов (например, 4:2:0).
          SOF2 0xFFC2 переменный размер Начало фрейма (прогрессивный, ДКП, код Хаффмана) Показывает что изображение кодировалось в прогрессивном режиме с использованием ДКП и кода Хаффмана. Маркер содержит число строк и длину строки изображения, количество компонентов, число бит на компонент, а также соотношение компонентов (например, 4:2:0).
          DHT 0xFFC4 переменный размер Содержит таблицы Хаффмана Задает одну или более таблиц Хаффмана.
          DQT 0xFFDB переменный размер Содержит таблицы квантования Задает одну или более таблиц квантования.
          DRI 0xFFDD 4 байта Указывает интервал повторений Задает интервал между маркерами RST n в макроблоках.
          SOS 0xFFDA переменный размер Начало сканирования Начало первого или очередного скана изображения с направлением обхода слева направо сверху вниз. Если использовался базовый режим кодирования, используется один скан. При использовании прогрессивных режимов используется несколько сканов. Маркер SOS является разделяющим между информативной (заголовком) и закодированной (собственно сжатыми данными) частями изображения.
          RSTn 0xFFDn нет Перезапуск Вставляется в каждом r макроблоке, где r — интервал перезапуска DRI маркера. Не используется при отсутствии DRI маркера. n, младшие 3 бита маркера кода, циклы от 0 до 7.
          APPn 0xFFEn переменный размер Задаётся приложением Например, в EXIF JPEG-файла используется маркер APP1 для хранения метаданных, расположеных в структуре, основанной на TIFF.
          COM 0xFFFE переменный размер Комментарий Содержит текст комментария.
          EOI 0xFFD9 нет Конец закодированной части изображения.

          Достоинства и недостатки

          К недостаткам сжатия по стандарту JPEG следует отнести появление на восстановленных изображениях при высоких степенях сжатия характерных артефактов: изображение рассыпается на блоки размером 8×8 пикселов (этот эффект особенно заметен на областях изображения с плавными изменениями яркости), в областях с высокой пространственной частотой (например, на контрастных контурах и границах изображения) возникают артефакты в виде шумовых ореолов. Следует отметить, что стандарт JPEG (ISO/IEC 10918-1, Annex K, п. K.8) предусматривает использование специальных фильтров для подавления блоковых артефактов, но на практике подобные фильтры, несмотря на их высокую эффективность, практически не используются. Однако, несмотря на недостатки, JPEG получил очень широкое распространение из-за достаточно высокой (относительно существовавших во время его появления альтернатив) степени сжатия, поддержке сжатия полноцветных изображений и относительно невысокой вычислительной сложности.

          Производительность сжатия по стандарту JPEG

          Для ускорения процесса сжатия по стандарту JPEG традиционно используется распараллеливание вычислений, в частности — при вычислении ДКП. Исторически одна из первых попыток ускорить процесс сжатия с использованием такого подхода описана в опубликованной в 1993 г. статье Касперовича и Бабкина [6], в которой предлагалась оригинальная аппроксимация ДКП, делающая возможным эффективное распараллеливание вычислений с использованием 32-разрядных регистров общего назначения процессоров Intel 80386. Появившиеся позже более производительные вычислительные схемы использовали SIMD-расширения набора инструкций процессоров архитектуры x86. Значительно лучших результатов позволяют добиться схемы, использующие вычислительные возможности графических ускорителей (технологии NVIDIA CUDA и AMD FireStream) для организации параллельных вычислений не только ДКП, но и других этапов сжатия JPEG (преобразование цветовых пространств, run-level, статистическое кодирование и т.п.), причём для каждого блока 8х8 кодируемого или декодируемого изображения. В статье [7] была впервые[источник?] представлена реализация распараллеливания всех стадий алгоритма JPEG по технологии CUDA, что значительно ускорило производительность сжатия и декодирования по стандарту JPEG.

          Интересные факты

          В 2010 году ученые из проекта PLANETS поместили инструкции по чтению формата JPEG в специальную капсулу, которую поместили в специальный бункер в швейцарских Альпах. Сделано это было с целью сохранения для потомков информации о популярных в начале XXI века цифровых форматах.[8]

          См. также

          • JPEG-LS
          • JPEG2000
          • libjpeg
          • MJPEG
          • MPEG
          • WebP

          Примечания

          1. JPEG pronounced — Поиск в Google
          2. В соответствии с ГОСТ 34.003-90 в области информационных технологий данный термин имеет мужской род
          3. ISO/IEC 10918-1 : 1993(E) p.28. Архивировано из первоисточника 22 августа 2011.
          4. Kerr, Douglas A. «Chrominance Subsampling in Digital Images»
          5. ISO/IEC 10918-1 : 1993(E) p.36. Архивировано из первоисточника 22 августа 2011.
          6. Kasperovich, L.V., Babkin, V.F. «Fast discrete cosine transform approximation for JPEG image compression»
          7. «Использование технологии CUDA для быстрого сжатия изображений по алгоритму JPEG»
          8. Ученые законсервировали для потомков форматы JPEG и PDF. Проверено 21 мая 2010.

          Ссылки

          • The JPEG committee homepage
          • Спецификация JFIF 1.02 (текстовый файл)
          • Оптимизация JPEG. Часть 1, Часть 2, Часть 3.
          • Быстрое сжатие JPEG на видеокарте.
           Просмотр этого шаблона Медиаконтейнеры
          Видео/аудио

          3GP • ASF • AVI • Bink • DMF • DPX • EVO • FLV • Matroska (MKV) • WebM • MPEG-PS • MPEG-TS • MP4 • MXF • NUT • Ogg • Ogg Media • QuickTime • RealMedia • Smacker • RIFF • VOB • сравнение сжатие

          Аудио

          AIFF • APE • AU • DSD • DXD • MLP • MP3 • FLAC • SHN (англ.) WAV • WMA • сравнение сжатие

          Графические форматы (сжатие)
          Растровые

          Без потерь: BMP • FPX • GIF • ICO • ILBM • JBIG • PCX • PNG • PNM • PSD • RAW • TGA • WBMP • XCF • Включая сжатие с потерями: EXR • ICER • JBIG2 • JPEG / JP2 / JPEG-LS • JPEG XR (HD Photo) • PGF (англ.) • TIFF • WebP • Анимационные: APNG • GIF • MNG

          Векторные

          AI • CDR • EMF • EPS • PS • SVG • WMF • XPS • Анимационные: SVG • SWF • 3D: 3DS • VRML • X3D

          Комплексные

          CGM • DjVu • PDF

          Файл формата jpg: чем открыть, описание, особенности

          JPG – часто используемый графический формат сжатого изображения, разработанный компанией Joint Photo.

          JPG – часто используемый графический формат сжатого изображения, разработанный компанией Joint Photographic Experts Group (JPEG). Файлы имеют высокий уровень сжатия и поддерживают глубину цвета в 24 бит. Благодаря этим характеристикам файлы с расширениями JPG/JPEG применяются в цифровых фотоаппаратах, смартфонах, видеокамерах. Несмотря на распространенность формата, у некоторых пользователей возникает вопрос – чем открыть JPG? Рассмотрим различные варианты и возможные сложности.

          Область применения и свойства формата jpg

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

          Положительные и отрицательные характеристики файла формата jpg

          К плюсам формата относятся:

          1. Широкий диапазон уровня сжатия (качество и размер файла зависят от степени сжатия).
          2. Минимальный размер файла.
          3. Согласованность с браузерами и текстовыми редакторами.
          4. Отображение на современных устройствах.
          5. При невысоком уровне сжатия не страдает качество картинки.

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

          1. При достаточном уровне сжатия может “развалиться” на блоки пикселей.
          2. Не поддерживает прозрачность.
          3. Не рекомендуется редактировать файл после восстановления. Каждая новая манипуляция снижает качество изображения.

          Чем и как открывать файлы jpg

          Изображения JPG используются повсеместно, поэтому программа для просмотра JPG входит в набор для стандартных опций Windows. В случае, если программа для просмотра фотографий JPG не встроена в операционную систему, файл можно открыть в Microsoft Paint, который есть в списке стандартных программ для Windows.

          Открываем на компьютере

          У рядового пользователя обычно не возникает проблем с вопросом, как открыть файл JPG на компьютере. Большое распространение получили программы для jpg/jpeg файлов. Вот некоторые из них:

          Скачать программу для просмотра jpg можно в сети интернет, если она есть в свободном доступе, либо купить лицензионную версию у разработчика. Каждая из них имеет особенности работы с jpg/jpeg файлами.

          Открыть формат через Windows 10

          Программа для просмотра JPG для Windows 10 отсутствует в базовом ПО. Однако в случае смены ОС с Windows 7 или 8.1, средство просмотра фотографий может присутствовать на ПК. Существует способ удостовериться, что программы для открытия jpg файлов установлены. Для этого кликните на изображение правой кнопкой мыши и найдите пункт «Открыть с помощью». Далее просмотрите список предложенных средств для просмотра.

          Воспользуйтесь программой для открытия JPG WinAero Tweaker. После запуска утилиты, перейдите в раздел «Windows Accessories» и выберите пункт «Activate Windows Photo Viewer».

          Просмотреть с помощью Windows 7

          В Windows 7 сразу установлено ПО, которое открывает разноформатные файлы, в том числе и JPG. Если же установлено больше 2-х программ для просмотра и открытия файлов JPG, при двойном щелчке мышки на изображении, откроется программа, установленная по умолчанию. Чтобы открыть формат JPG другой программой из меню «Проводника», выбрать и нажать на кнопку «Открыть с помощью. ».

          Онлайн-просмотр

          Открыть файл JPG онлайн и просмотреть фото можно популярными программами:

          Как открыть поврежденный файл jpg?

          Как определить, что файл JPG поврежден? При попытке запуска появляется ошибка (диалоговое окно с сообщением «файл поврежден») или же не открывается вовсе. Тогда используют программы RS File Repair, PixRecovery, JPEGfix для восстановления файлов. Большинство таких программ можно бесплатно скачать в интернете.

          Источник статьи: http://freesoft.ru/blog/fayl-formata-jpg-chem-otkryt-opisanie-osobennosti

          Как в Windows открывать и редактировать файлы формата JPG или JPEG

          Файл с расширением JPG или JPEG является файлом изображения. Причина, по которой некоторые файлы JPEG-изображений используют JPG-расширение, а другие – JPEG, объясняется ниже, но независимо от расширения, оба файла имеют один формат.

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

          Некоторые файлы JPEG-изображений используют .Jpe расширение, но это не очень распространено. JFIF – это файлы формата обмена файлами JPEG, которые также используют сжатие JPEG, но не так популярны, как файлы JPG.

          Как открыть файл JPG/JPEG

          JPG-файлы поддерживаются всеми просмотрщиками и редакторами изображений. Это самый распространенный формат изображения.

          Вы можете открыть файлы JPG с помощью веб-браузера, например Chrome или Edge (перетащите локальные файлы JPG в окно браузера) или встроенные программы Microsoft, такие как Paint, Microsoft Windows Photos и Microsoft Windows Photo Viewer. Если вы находитесь на компьютере Mac, Apple Preview и Apple Photos могут открыть файл JPG.

          Adobe Photoshop, GIMP и практически любая другая программа, которая просматривает изображения, в том числе онлайн-сервисы, такие как Google Drive, также поддерживают JPG-файлы.

          Мобильные устройства также поддерживают открытие файлов JPG, что означает, что вы можете просматривать их в своей электронной почте и через текстовые сообщения без необходимости устанавливать дополнительное приложение для просмотра JPG.

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

          Некоторые форматы файлов используют расширения файлов, которые выглядят как .JPG файлы, но на самом деле не связаны. Примеры включают JPR (JBuilder Project или Fugawi Projection), JPS (Stereo JPEG Image или Akeeba Backup Archive) и JPGW (JPEG World).

          Как конвертировать файл JPG / JPEG

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

          Например, FileZigZag является онлайн конвертером JPG, который может сохранить файл в ряде других форматов, включая PNG, TIF / TIFF, GIF, BMP, DPX, TGA, PCX и YUV.

          Вы даже можете конвертировать файлы JPG в формат MS Word, такой как DOCX или DOC с Zamzar, который похож на FileZigZag в том, что он преобразует файл JPG в режиме онлайн. Он также сохраняет JPG в ICO, PS, PDF и WEBP, среди других форматов.

          Если вы просто хотите вставить файл JPG в документ Word, вам не нужно конвертировать файл в формат MS Word. Вместо этого используйте встроенное меню Word: ВставитьКартинка, чтобы подключить JPG непосредственно к документу, даже если у вас уже есть текст.

          Откройте файл JPG в Microsoft Paint и используйте меню ФайлСохранить как, чтобы преобразовать его в BMP, DIB, PNG, TIFF и т.д. Другие средства просмотра и редакторы JPG, упомянутые выше, поддерживают аналогичные параметры меню и форматы выходных файлов.

          Использование веб-сервиса Convertio является одним из способов преобразования JPG в EPS, если вы хотите, чтобы файл изображения был в этом формате. Если это не работает, вы можете попробовать AConvert.com.

          Несмотря на название, веб-сайт Online PNG to SVG Converter также умеет преобразовывать файлы JPG в формат изображения SVG (vector).

          Если у вас есть файл PDF и вы хотите сделать из него JPG/JPEG, попробуйте PDF.io

          Чем отличается JPG от JPEG

          Интересно, какая разница между JPEG и JPG? Форматы файлов идентичны, но в одном из расширений есть дополнительная буква. На самом деле. это единственная разница.

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

          Ситуация похожа на HTM и HTML, когда формат JPEG был впервые введен, официальным расширением файла был JPEG (с четырьмя буквами). Однако, Windows в то время требовала, чтобы все расширения файлов не превышали трёх букв, вот почему .JPG использовался для того же самого формата. Компьютеры Mac, однако, уже тогда не имели такого ограничения.

          Произошло то, что оба расширения файлов использовались в обеих системах, а затем Windows изменила свои требования, чтобы принять более длинные расширения файлов, но JPG всё ещё используется. Поэтому файлы JPG и JPEG распространяются и продолжают создаваться.

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

          Источник статьи: http://windows-school.ru/blog/fajly_formata_jpg/2019-05-14-391

          JPEG

          Felis silvestris silvestris small gradual decrease of quality.png

          A photo of a European wildcat with the compression rate decreasing and hence quality increasing, from left to right

          Filename extension

          .jpg, .jpeg, .jpe
          .jif, .jfif, .jfi

          Internet media type

          image/jpeg

          Type code JPEG
          Uniform Type Identifier (UTI) public.jpeg
          Magic number ff d8 ff
          Developed by Joint Photographic Experts Group, IBM, Mitsubishi Electric, AT&T, Canon Inc.[1]
          Initial release September 18, 1992; 30 years ago
          Type of format Lossy image compression format
          Extended to JPEG 2000
          Standard ISO/IEC 10918, ITU-T T.81, ITU-T T.83, ITU-T T.84, ITU-T T.86
          Website jpeg.org/jpeg/ Edit this at Wikidata

          Continuously varied JPEG compression (between Q=100 and Q=1) for an abdominal CT scan

          JPEG ( JAY-peg)[2] is a commonly used method of lossy compression for digital images, particularly for those images produced by digital photography. The degree of compression can be adjusted, allowing a selectable tradeoff between storage size and image quality. JPEG typically achieves 10:1 compression with little perceptible loss in image quality.[3] Since its introduction in 1992, JPEG has been the most widely used image compression standard in the world,[4][5] and the most widely used digital image format, with several billion JPEG images produced every day as of 2015.[6]

          The term «JPEG» is an acronym for the Joint Photographic Experts Group, which created the standard in 1992.[7] JPEG was largely responsible for the proliferation of digital images and digital photos across the Internet and later social media.[8]

          JPEG compression is used in a number of image file formats. JPEG/Exif is the most common image format used by digital cameras and other photographic image capture devices; along with JPEG/JFIF, it is the most common format for storing and transmitting photographic images on the World Wide Web.[9] These format variations are often not distinguished and are simply called JPEG.

          The MIME media type for JPEG is «image/jpeg,» except in older Internet Explorer versions, which provide a MIME type of «image/pjpeg» when uploading JPEG images.[10] JPEG files usually have a filename extension of «jpg» or «jpeg.» JPEG/JFIF supports a maximum image size of 65,535×65,535 pixels,[11] hence up to 4 gigapixels for an aspect ratio of 1:1. In 2000, the JPEG group introduced a format intended to be a successor, JPEG 2000, but it was unable to replace the original JPEG as the dominant image standard.[12]

          History[edit]

          Background[edit]

          The original JPEG specification published in 1992 implements processes from various earlier research papers and patents cited by the CCITT (now ITU-T) and Joint Photographic Experts Group.[1]

          The JPEG specification cites patents from several companies. The following patents provided the basis for its arithmetic coding algorithm.[1]

          • IBM
            • U.S. Patent 4,652,856 – February 4, 1986 – Kottappuram M. A. Mohiuddin and Jorma J. Rissanen – Multiplication-free multi-alphabet arithmetic code
            • U.S. Patent 4,905,297 – February 27, 1990 – G. Langdon, J.L. Mitchell, W.B. Pennebaker, and Jorma J. Rissanen – Arithmetic coding encoder and decoder system
            • U.S. Patent 4,935,882 – June 19, 1990 – W.B. Pennebaker and J.L. Mitchell – Probability adaptation for arithmetic coders
          • Mitsubishi Electric
            • JP H02202267 (1021672) – January 21, 1989 – Toshihiro Kimura, Shigenori Kino, Fumitaka Ono, Masayuki Yoshida – Coding system
            • JP H03247123 (2-46275) – February 26, 1990 – Fumitaka Ono, Tomohiro Kimura, Masayuki Yoshida, and Shigenori Kino – Coding apparatus and coding method

          The JPEG specification also cites three other patents from IBM. Other companies cited as patent holders include AT&T (two patents) and Canon Inc.[1] Absent from the list is U.S. Patent 4,698,672, filed by Compression Labs’ Wen-Hsiung Chen and Daniel J. Klenke in October 1986. The patent describes a DCT-based image compression algorithm, and would later be a cause of controversy in 2002 (see Patent controversy below).[13] However, the JPEG specification did cite two earlier research papers by Wen-Hsiung Chen, published in 1977 and 1984.[1]

          JPEG standard[edit]

          «JPEG» stands for Joint Photographic Experts Group, the name of the committee that created the JPEG standard and also other still picture coding standards. The «Joint» stood for ISO TC97 WG8 and CCITT SGVIII. Founded in 1986, the group developed the JPEG standard during the late 1980s. The group published the JPEG standard in 1992.[4]

          In 1987, ISO TC 97 became ISO/IEC JTC 1 and, in 1992, CCITT became ITU-T. Currently on the JTC1 side, JPEG is one of two sub-groups of ISO/IEC Joint Technical Committee 1, Subcommittee 29, Working Group 1 (ISO/IEC JTC 1/SC 29/WG 1) – titled as Coding of still pictures.[14][15][16] On the ITU-T side, ITU-T SG16 is the respective body. The original JPEG Group was organized in 1986,[17] issuing the first JPEG standard in 1992, which was approved in September 1992 as ITU-T Recommendation T.81[18] and, in 1994, as ISO/IEC 10918-1.

          The JPEG standard specifies the codec, which defines how an image is compressed into a stream of bytes and decompressed back into an image, but not the file format used to contain that stream.[19]
          The Exif and JFIF standards define the commonly used file formats for interchange of JPEG-compressed images.

          JPEG standards are formally named as Information technology – Digital compression and coding of continuous-tone still images. ISO/IEC 10918 consists of the following parts:

          Digital compression and coding of continuous-tone still images – Parts[15][17][20]

          Part ISO/IEC standard ITU-T Rec. First public release date Latest amendment Title Description
          Part 1 ISO/IEC 10918-1:1994 T.81 (09/92) Sep 18, 1992 Requirements and guidelines
          Part 2 ISO/IEC 10918-2:1995 T.83 (11/94) Nov 11, 1994 Compliance testing Rules and checks for software conformance (to Part 1).
          Part 3 ISO/IEC 10918-3:1997 T.84 (07/96) Jul 3, 1996 Apr 1, 1999 Extensions Set of extensions to improve the Part 1, including the Still Picture Interchange File Format (SPIFF).[21]
          Part 4 ISO/IEC 10918-4:1999 T.86 (06/98) Jun 18, 1998 Jun 29, 2012 Registration of JPEG profiles, SPIFF profiles, SPIFF tags, SPIFF colour spaces, APPn markers, SPIFF compression types and Registration Authorities (REGAUT) methods for registering some of the parameters used to extend JPEG
          Part 5 ISO/IEC 10918-5:2013 T.871 (05/11) May 14, 2011 JPEG File Interchange Format (JFIF) A popular format which has been the de facto file format for images encoded by the JPEG standard. In 2009, the JPEG Committee formally established an Ad Hoc Group to standardize JFIF as JPEG Part 5.[22]
          Part 6 ISO/IEC 10918-6:2013 T.872 (06/12) Jun 2012 Application to printing systems Specifies a subset of features and application tools for the interchange of images encoded according to the ISO/IEC 10918-1 for printing.
          Part 7 ISO/IEC 10918-7:2021 T.873 (06/21) May 2019 June 2021 Reference Software Provides reference implementations of the JPEG core coding system

          Ecma International TR/98 specifies the JPEG File Interchange Format (JFIF); the first edition was published in June 2009.[23]

          Patent controversy[edit]

          In 2002, Forgent Networks asserted that it owned and would enforce patent rights on the JPEG technology, arising from a patent that had been filed on October 27, 1986, and granted on October 6, 1987: U.S. Patent 4,698,672 by Compression Labs’ Wen-Hsiung Chen and Daniel J. Klenke.[13][24] While Forgent did not own Compression Labs at the time, Chen later sold Compression Labs to Forgent, before Chen went on to work for Cisco. This led to Forgent acquiring ownership over the patent.[13] Forgent’s 2002 announcement created a furor reminiscent of Unisys’ attempts to assert its rights over the GIF image compression standard.

          The JPEG committee investigated the patent claims in 2002 and were of the opinion that they were invalidated by prior art,[25] a view shared by various experts.[13][26]

          Between 2002 and 2004, Forgent was able to obtain about US$105 million by licensing their patent to some 30 companies. In April 2004, Forgent sued 31 other companies to enforce further license payments. In July of the same year, a consortium of 21 large computer companies filed a countersuit, with the goal of invalidating the patent. In addition, Microsoft launched a separate lawsuit against Forgent in April 2005.[27] In February 2006, the United States Patent and Trademark Office agreed to re-examine Forgent’s JPEG patent at the request of the Public Patent Foundation.[28] On May 26, 2006, the USPTO found the patent invalid based on prior art. The USPTO also found that Forgent knew about the prior art, yet it intentionally avoided telling the Patent Office. This makes any appeal to reinstate the patent highly unlikely to succeed.[29]

          Forgent also possesses a similar patent granted by the European Patent Office in 1994, though it is unclear how enforceable it is.[30]

          As of October 27, 2006, the U.S. patent’s 20-year term appears to have expired, and in November 2006, Forgent agreed to abandon enforcement of patent claims against use of the JPEG standard.[31]

          The JPEG committee has as one of its explicit goals that their standards (in particular their baseline methods) be implementable without payment of license fees, and they have secured appropriate license rights for their JPEG 2000 standard from over 20 large organizations.

          Beginning in August 2007, another company, Global Patent Holdings, LLC claimed that its patent (U.S. Patent 5,253,341) issued in 1993, is infringed by the downloading of JPEG images on either a website or through e-mail. If not invalidated, this patent could apply to any website that displays JPEG images. The patent was under reexamination by the U.S. Patent and Trademark Office from 2000 to 2007; in July 2007, the Patent Office revoked all of the original claims of the patent but found that an additional claim proposed by Global Patent Holdings (claim 17) was valid.[32] Global Patent Holdings then filed a number of lawsuits based on claim 17 of its patent.

          In its first two lawsuits following the reexamination, both filed in Chicago, Illinois, Global Patent Holdings sued the Green Bay Packers, CDW, Motorola, Apple, Orbitz, Officemax, Caterpillar, Kraft and Peapod as defendants. A third lawsuit was filed on December 5, 2007, in South Florida against ADT Security Services, AutoNation, Florida Crystals Corp., HearUSA, MovieTickets.com, Ocwen Financial Corp. and Tire Kingdom, and a fourth lawsuit on January 8, 2008, in South Florida against the Boca Raton Resort & Club. A fifth lawsuit was filed against Global Patent Holdings in Nevada. That lawsuit was filed by Zappos.com, Inc., which was allegedly threatened by Global Patent Holdings, and sought a judicial declaration that the ‘341 patent is invalid and not infringed.

          Global Patent Holdings had also used the ‘341 patent to sue or threaten outspoken critics of broad software patents, including Gregory Aharonian[33] and the anonymous operator of a website blog known as the «Patent Troll Tracker.»[34] On December 21, 2007, patent lawyer Vernon Francissen of Chicago asked the U.S. Patent and Trademark Office to reexamine the sole remaining claim of the ‘341 patent on the basis of new prior art.[35]

          On March 5, 2008, the U.S. Patent and Trademark Office agreed to reexamine the ‘341 patent, finding that the new prior art raised substantial new questions regarding the patent’s validity.[36] In light of the reexamination, the accused infringers in four of the five pending lawsuits have filed motions to suspend (stay) their cases until completion of the U.S. Patent and Trademark Office’s review of the ‘341 patent. On April 23, 2008, a judge presiding over the two lawsuits in Chicago, Illinois granted the motions in those cases.[37] On July 22, 2008, the Patent Office issued the first «Office Action» of the second reexamination, finding the claim invalid based on nineteen separate grounds.[38] On Nov. 24, 2009, a Reexamination Certificate was issued cancelling all claims.

          Beginning in 2011 and continuing as of early 2013, an entity known as Princeton Digital Image Corporation,[39] based in Eastern Texas, began suing large numbers of companies for alleged infringement of U.S. Patent 4,813,056. Princeton claims that the JPEG image compression standard infringes the ‘056 patent and has sued large numbers of websites, retailers, camera and device manufacturers and resellers. The patent was originally owned and assigned to General Electric. The patent expired in December 2007, but Princeton has sued large numbers of companies for «past infringement» of this patent. (Under U.S. patent laws, a patent owner can sue for «past infringement» up to six years before the filing of a lawsuit, so Princeton could theoretically have continued suing companies until December 2013.) As of March 2013, Princeton had suits pending in New York and Delaware against more than 55 companies. General Electric’s involvement in the suit is unknown, although court records indicate that it assigned the patent to Princeton in 2009 and retains certain rights in the patent.[40]

          Typical use[edit]

          The JPEG compression algorithm operates at its best on photographs and paintings of realistic scenes with smooth variations of tone and color. For web usage, where reducing the amount of data used for an image is important for responsive presentation, JPEG’s compression benefits make JPEG popular. JPEG/Exif is also the most common format saved by digital cameras.

          However, JPEG is not well suited for line drawings and other textual or iconic graphics, where the sharp contrasts between adjacent pixels can cause noticeable artifacts. Such images are better saved in a lossless graphics format such as TIFF, GIF, PNG, or a raw image format. The JPEG standard includes a lossless coding mode, but that mode is not supported in most products.

          As the typical use of JPEG is a lossy compression method, which reduces the image fidelity, it is inappropriate for exact reproduction of imaging data (such as some scientific and medical imaging applications and certain technical image processing work).

          JPEG is also not well suited to files that will undergo multiple edits, as some image quality is lost each time the image is recompressed, particularly if the image is cropped or shifted, or if encoding parameters are changed – see digital generation loss for details. To prevent image information loss during sequential and repetitive editing, the first edit can be saved in a lossless format, subsequently edited in that format, then finally published as JPEG for distribution.

          JPEG compression[edit]

          JPEG uses a lossy form of compression based on the discrete cosine transform (DCT). This mathematical operation converts each frame/field of the video source from the spatial (2D) domain into the frequency domain (a.k.a. transform domain). A perceptual model based loosely on the human psychovisual system discards high-frequency information, i.e. sharp transitions in intensity, and color hue. In the transform domain, the process of reducing information is called quantization. In simpler terms, quantization is a method for optimally reducing a large number scale (with different occurrences of each number) into a smaller one, and the transform-domain is a convenient representation of the image because the high-frequency coefficients, which contribute less to the overall picture than other coefficients, are characteristically small-values with high compressibility. The quantized coefficients are then sequenced and losslessly packed into the output bitstream. Nearly all software implementations of JPEG permit user control over the compression ratio (as well as other optional parameters), allowing the user to trade off picture-quality for smaller file size. In embedded applications (such as miniDV, which uses a similar DCT-compression scheme), the parameters are pre-selected and fixed for the application.

          The compression method is usually lossy, meaning that some original image information is lost and cannot be restored, possibly affecting image quality. There is an optional lossless mode defined in the JPEG standard. However, this mode is not widely supported in products.

          There is also an interlaced progressive JPEG format, in which data is compressed in multiple passes of progressively higher detail. This is ideal for large images that will be displayed while downloading over a slow connection, allowing a reasonable preview after receiving only a portion of the data. However, support for progressive JPEGs is not universal. When progressive JPEGs are received by programs that do not support them (such as versions of Internet Explorer before Windows 7)[41] the software displays the image only after it has been completely downloaded.

          There are also many medical imaging, traffic and camera applications that create and process 12-bit JPEG images both grayscale and color. 12-bit JPEG format is included in an Extended part of the JPEG specification. The libjpeg codec supports 12-bit JPEG and there even exists a high-performance version.[42]

          Lossless editing[edit]

          Several alterations to a JPEG image can be performed losslessly (that is, without recompression and the associated quality loss) as long as the image size is a multiple of 1 MCU block (Minimum Coded Unit) (usually 16 pixels in both directions, for 4:2:0 chroma subsampling). Utilities that implement this include:

          • jpegtran and its GUI, Jpegcrop.
          • IrfanView using «JPG Lossless Crop (PlugIn)» and «JPG Lossless Rotation (PlugIn)», which require installing the JPG_TRANSFORM plugin.
          • FastStone Image Viewer using «Lossless Crop to File» and «JPEG Lossless Rotate».
          • XnViewMP using «JPEG lossless transformations».
          • ACDSee supports lossless rotation (but not lossless cropping) with its «Force lossless JPEG operations» option.

          Blocks can be rotated in 90-degree increments, flipped in the horizontal, vertical and diagonal axes and moved about in the image. Not all blocks from the original image need to be used in the modified one.

          The top and left edge of a JPEG image must lie on an 8 × 8 pixel block boundary, but the bottom and right edge need not do so. This limits the possible lossless crop operations, and also prevents flips and rotations of an image whose bottom or right edge does not lie on a block boundary for all channels (because the edge would end up on top or left, where – as aforementioned – a block boundary is obligatory).

          Rotations where the image is not a multiple of 8 or 16, which value depends upon the chroma subsampling, are not lossless. Rotating such an image causes the blocks to be recomputed which results in loss of quality.[43]

          When using lossless cropping, if the bottom or right side of the crop region is not on a block boundary, then the rest of the data from the partially used blocks will still be present in the cropped file and can be recovered. It is also possible to transform between baseline and progressive formats without any loss of quality, since the only difference is the order in which the coefficients are placed in the file.

          Furthermore, several JPEG images can be losslessly joined, as long as they were saved with the same quality and the edges coincide with block boundaries.

          JPEG files[edit]

          The file format known as «JPEG Interchange Format» (JIF) is specified in Annex B of the standard. However, this «pure» file format is rarely used, primarily because of the difficulty of programming encoders and decoders that fully implement all aspects of the standard and because of certain shortcomings of the standard:

          • Color space definition
          • Component sub-sampling registration
          • Pixel aspect ratio definition.

          Several additional standards have evolved to address these issues. The first of these, released in 1992, was the JPEG File Interchange Format (or JFIF), followed in recent years by Exchangeable image file format (Exif) and ICC color profiles. Both of these formats use the actual JIF byte layout, consisting of different markers, but in addition, employ one of the JIF standard’s extension points, namely the application markers: JFIF uses APP0, while Exif uses APP1. Within these segments of the file that were left for future use in the JIF standard and are not read by it, these standards add specific metadata.

          Thus, in some ways, JFIF is a cut-down version of the JIF standard in that it specifies certain constraints (such as not allowing all the different encoding modes), while in other ways, it is an extension of JIF due to the added metadata. The documentation for the original JFIF standard states:[44]

          JPEG File Interchange Format is a minimal file format which enables JPEG bitstreams to be exchanged between a wide variety of platforms and applications. This minimal format does not include any of the advanced features found in the TIFF JPEG specification or any application specific file format. Nor should it, for the only purpose of this simplified format is to allow the exchange of JPEG compressed images.

          Image files that employ JPEG compression are commonly called «JPEG files», and are stored in variants of the JIF image format. Most image capture devices (such as digital cameras) that output JPEG are actually creating files in the Exif format, the format that the camera industry has standardized on for metadata interchange. On the other hand, since the Exif standard does not allow color profiles, most image editing software stores JPEG in JFIF format, and also includes the APP1 segment from the Exif file to include the metadata in an almost-compliant way; the JFIF standard is interpreted somewhat flexibly.[45]

          Strictly speaking, the JFIF and Exif standards are incompatible, because each specifies that its marker segment (APP0 or APP1, respectively) appear first. In practice, most JPEG files contain a JFIF marker segment that precedes the Exif header. This allows older readers to correctly handle the older format JFIF segment, while newer readers also decode the following Exif segment, being less strict about requiring it to appear first.

          JPEG filename extensions[edit]

          The most common filename extensions for files employing JPEG compression are .jpg and .jpeg, though .jpe, .jfif and .jif are also used. It is also possible for JPEG data to be embedded in other file types – TIFF encoded files often embed a JPEG image as a thumbnail of the main image; and MP3 files can contain a JPEG of cover art in the ID3v2 tag.

          Color profile[edit]

          Many JPEG files embed an ICC color profile (color space). Commonly used color profiles include sRGB and Adobe RGB. Because these color spaces use a non-linear transformation, the dynamic range of an 8-bit JPEG file is about 11 stops; see gamma curve.

          If the image doesn’t specify color profile information (untagged), the color space is assumed to be sRGB for the purposes of display on webpages.[46][47]

          Syntax and structure[edit]

          A JPEG image consists of a sequence of segments, each beginning with a marker, each of which begins with a 0xFF byte, followed by a byte indicating what kind of marker it is. Some markers consist of just those two bytes; others are followed by two bytes (high then low), indicating the length of marker-specific payload data that follows. (The length includes the two bytes for the length, but not the two bytes for the marker.) Some markers are followed by entropy-coded data; the length of such a marker does not include the entropy-coded data. Note that consecutive 0xFF bytes are used as fill bytes for padding purposes, although this fill byte padding should only ever take place for markers immediately following entropy-coded scan data (see JPEG specification section B.1.1.2 and E.1.2 for details; specifically «In all cases where markers are appended after the compressed data, optional 0xFF fill bytes may precede the marker»).

          Within the entropy-coded data, after any 0xFF byte, a 0x00 byte is inserted by the encoder before the next byte, so that there does not appear to be a marker where none is intended, preventing framing errors. Decoders must skip this 0x00 byte. This technique, called byte stuffing (see JPEG specification section F.1.2.3), is only applied to the entropy-coded data, not to marker payload data. Note however that entropy-coded data has a few markers of its own; specifically the Reset markers (0xD0 through 0xD7), which are used to isolate independent chunks of entropy-coded data to allow parallel decoding, and encoders are free to insert these Reset markers at regular intervals (although not all encoders do this).

          Common JPEG markers[48]

          Short name Bytes Payload Name Comments
          SOI 0xFF, 0xD8 none Start Of Image
          SOF0 0xFF, 0xC0 variable size Start Of Frame (baseline DCT) Indicates that this is a baseline DCT-based JPEG, and specifies the width, height, number of components, and component subsampling (e.g., 4:2:0).
          SOF2 0xFF, 0xC2 variable size Start Of Frame (progressive DCT) Indicates that this is a progressive DCT-based JPEG, and specifies the width, height, number of components, and component subsampling (e.g., 4:2:0).
          DHT 0xFF, 0xC4 variable size Define Huffman Table(s) Specifies one or more Huffman tables.
          DQT 0xFF, 0xDB variable size Define Quantization Table(s) Specifies one or more quantization tables.
          DRI 0xFF, 0xDD 4 bytes Define Restart Interval Specifies the interval between RSTn markers, in Minimum Coded Units (MCUs). This marker is followed by two bytes indicating the fixed size so it can be treated like any other variable size segment.
          SOS 0xFF, 0xDA variable size Start Of Scan Begins a top-to-bottom scan of the image. In baseline DCT JPEG images, there is generally a single scan. Progressive DCT JPEG images usually contain multiple scans. This marker specifies which slice of data it will contain, and is immediately followed by entropy-coded data.
          RSTn 0xFF, 0xDn (n=0..7) none Restart Inserted every r macroblocks, where r is the restart interval set by a DRI marker. Not used if there was no DRI marker. The low three bits of the marker code cycle in value from 0 to 7.
          APPn 0xFF, 0xEn variable size Application-specific For example, an Exif JPEG file uses an APP1 marker to store metadata, laid out in a structure based closely on TIFF.
          COM 0xFF, 0xFE variable size Comment Contains a text comment.
          EOI 0xFF, 0xD9 none End Of Image

          There are other Start Of Frame markers that introduce other kinds of JPEG encodings.

          Since several vendors might use the same APPn marker type, application-specific markers often begin with a standard or vendor name (e.g., «Exif» or «Adobe») or some other identifying string.

          At a restart marker, block-to-block predictor variables are reset, and the bitstream is synchronized to a byte boundary. Restart markers provide means for recovery after bitstream error, such as transmission over an unreliable network or file corruption. Since the runs of macroblocks between restart markers may be independently decoded, these runs may be decoded in parallel.

          JPEG codec example[edit]

          Although a JPEG file can be encoded in various ways, most commonly it is done with JFIF encoding. The encoding process consists of several steps:

          1. The representation of the colors in the image is converted from RGB to Y′CBCR, consisting of one luma component (Y’), representing brightness, and two chroma components, (CB and CR), representing color. This step is sometimes skipped.
          2. The resolution of the chroma data is reduced, usually by a factor of 2 or 3. This reflects the fact that the eye is less sensitive to fine color details than to fine brightness details.
          3. The image is split into blocks of 8×8 pixels, and for each block, each of the Y, CB, and CR data undergoes the discrete cosine transform (DCT). A DCT is similar to a Fourier transform in the sense that it produces a kind of spatial frequency spectrum.
          4. The amplitudes of the frequency components are quantized. Human vision is much more sensitive to small variations in color or brightness over large areas than to the strength of high-frequency brightness variations. Therefore, the magnitudes of the high-frequency components are stored with a lower accuracy than the low-frequency components. The quality setting of the encoder (for example 50 or 95 on a scale of 0–100 in the Independent JPEG Group’s library[49]) affects to what extent the resolution of each frequency component is reduced. If an excessively low quality setting is used, the high-frequency components are discarded altogether.
          5. The resulting data for all 8×8 blocks is further compressed with a lossless algorithm, a variant of Huffman encoding.

          The decoding process reverses these steps, except the quantization because it is irreversible. In the remainder of this section, the encoding and decoding processes are described in more detail.

          Encoding[edit]

          Many of the options in the JPEG standard are not commonly used, and as mentioned above, most image software uses the simpler JFIF format when creating a JPEG file, which among other things specifies the encoding method. Here is a brief description of one of the more common methods of encoding when applied to an input that has 24 bits per pixel (eight each of red, green, and blue). This particular option is a lossy data compression method.

          Color space transformation[edit]

          First, the image should be converted from RGB (by default sRGB,[46][47] but other color spaces are possible) into a different color space called Y′CBCR (or, informally, YCbCr). It has three components Y’, CB and CR: the Y’ component represents the brightness of a pixel, and the CB and CR components represent the chrominance (split into blue and red components). This is basically the same color space as used by digital color television as well as digital video including video DVDs. The Y′CBCR color space conversion allows greater compression without a significant effect on perceptual image quality (or greater perceptual image quality for the same compression). The compression is more efficient because the brightness information, which is more important to the eventual perceptual quality of the image, is confined to a single channel. This more closely corresponds to the perception of color in the human visual system. The color transformation also improves compression by statistical decorrelation.

          A particular conversion to Y′CBCR is specified in the JFIF standard, and should be performed for the resulting JPEG file to have maximum compatibility. However, some JPEG implementations in «highest quality» mode do not apply this step and instead keep the color information in the RGB color model,[50] where the image is stored in separate channels for red, green and blue brightness components. This results in less efficient compression, and would not likely be used when file size is especially important.

          Downsampling[edit]

          Due to the densities of color- and brightness-sensitive receptors in the human eye, humans can see considerably more fine detail in the brightness of an image (the Y’ component) than in the hue and color saturation of an image (the Cb and Cr components). Using this knowledge, encoders can be designed to compress images more efficiently.

          The transformation into the Y′CBCR color model enables the next usual step, which is to reduce the spatial resolution of the Cb and Cr components (called «downsampling» or «chroma subsampling»). The ratios at which the downsampling is ordinarily done for JPEG images are 4:4:4 (no downsampling), 4:2:2 (reduction by a factor of 2 in the horizontal direction), or (most commonly) 4:2:0 (reduction by a factor of 2 in both the horizontal and vertical directions). For the rest of the compression process, Y’, Cb and Cr are processed separately and in a very similar manner.

          Block splitting[edit]

          After subsampling, each channel must be split into 8×8 blocks. Depending on chroma subsampling, this yields Minimum Coded Unit (MCU) blocks of size 8×8 (4:4:4 – no subsampling), 16×8 (4:2:2), or most commonly 16×16 (4:2:0). In video compression MCUs are called macroblocks.

          If the data for a channel does not represent an integer number of blocks then the encoder must fill the remaining area of the incomplete blocks with some form of dummy data. Filling the edges with a fixed color (for example, black) can create ringing artifacts along the visible part of the border;
          repeating the edge pixels is a common technique that reduces (but does not necessarily eliminate) such artifacts, and more sophisticated border filling techniques can also be applied.

          Discrete cosine transform[edit]

          The 8×8 sub-image shown in 8-bit grayscale

          Next, each 8×8 block of each component (Y, Cb, Cr) is converted to a frequency-domain representation, using a normalized, two-dimensional type-II discrete cosine transform (DCT), see Citation 1 in discrete cosine transform. The DCT is sometimes referred to as «type-II DCT» in the context of a family of transforms as in discrete cosine transform, and the corresponding inverse (IDCT) is denoted as «type-III DCT».

          As an example, one such 8×8 8-bit subimage might be:

          left[{begin{array}{rrrrrrrr}52&55&61&66&70&61&64&73\63&59&55&90&109&85&69&72\62&59&68&113&144&104&66&73\63&58&71&122&154&106&70&69\67&61&68&104&126&88&68&70\79&65&60&70&77&68&58&75\85&71&64&59&55&61&65&83\87&79&69&68&65&76&78&94end{array}}right].

          Before computing the DCT of the 8×8 block, its values are shifted from a positive range to one centered on zero. For an 8-bit image, each entry in the original block falls in the range [0,255]. The midpoint of the range (in this case, the value 128) is subtracted from each entry to produce a data range that is centered on zero, so that the modified range is [-128,127]. This step reduces the dynamic range requirements in the DCT processing stage that follows.

          This step results in the following values:

          g={begin{array}{c}x\longrightarrow \left[{begin{array}{rrrrrrrr}-76&-73&-67&-62&-58&-67&-64&-55\-65&-69&-73&-38&-19&-43&-59&-56\-66&-69&-60&-15&16&-24&-62&-55\-65&-70&-57&-6&26&-22&-58&-59\-61&-67&-60&-24&-2&-40&-60&-58\-49&-63&-68&-58&-51&-60&-70&-53\-43&-57&-64&-69&-73&-67&-63&-45\-41&-49&-59&-60&-63&-52&-50&-34end{array}}right]end{array}}{Bigg downarrow }y.

          The DCT transforms an 8×8 block of input values to a linear combination of these 64 patterns. The patterns are referred to as the two-dimensional DCT basis functions, and the output values are referred to as transform coefficients. The horizontal index is u and the vertical index is v.

          The next step is to take the two-dimensional DCT, which is given by:

           G_{u,v}={frac {1}{4}}alpha (u)alpha (v)sum _{x=0}^{7}sum _{y=0}^{7}g_{x,y}cos left[{frac {(2x+1)upi }{16}}right]cos left[{frac {(2y+1)vpi }{16}}right]

          where

          If we perform this transformation on our matrix above, we get the following (rounded to the nearest two digits beyond the decimal point):

          G={begin{array}{c}u\longrightarrow \left[{begin{array}{rrrrrrrr}-415.38&-30.19&-61.20&27.24&56.12&-20.10&-2.39&0.46\4.47&-21.86&-60.76&10.25&13.15&-7.09&-8.54&4.88\-46.83&7.37&77.13&-24.56&-28.91&9.93&5.42&-5.65\-48.53&12.07&34.10&-14.76&-10.24&6.30&1.83&1.95\12.12&-6.55&-13.20&-3.95&-1.87&1.75&-2.79&3.14\-7.73&2.91&2.38&-5.94&-2.38&0.94&4.30&1.85\-1.03&0.18&0.42&-2.42&-0.88&-3.02&4.12&-0.66\-0.17&0.14&-1.07&-4.19&-1.17&-0.10&0.50&1.68end{array}}right]end{array}}{Bigg downarrow }v.

          Note the top-left corner entry with the rather large magnitude. This is the DC coefficient (also called the constant component), which defines the basic hue for the entire block. The remaining 63 coefficients are the AC coefficients (also called the alternating components).[51] The advantage of the DCT is its tendency to aggregate most of the signal in one corner of the result, as may be seen above. The quantization step to follow accentuates this effect while simultaneously reducing the overall size of the DCT coefficients, resulting in a signal that is easy to compress efficiently in the entropy stage.

          The DCT temporarily increases the bit-depth of the data, since the DCT coefficients of an 8-bit/component image take up to 11 or more bits (depending on fidelity of the DCT calculation) to store. This may force the codec to temporarily use 16-bit numbers to hold these coefficients, doubling the size of the image representation at this point; these values are typically reduced back to 8-bit values by the quantization step. The temporary increase in size at this stage is not a performance concern for most JPEG implementations, since typically only a very small part of the image is stored in full DCT form at any given time during the image encoding or decoding process.

          Quantization[edit]

          The human eye is good at seeing small differences in brightness over a relatively large area, but not so good at distinguishing the exact strength of a high frequency brightness variation. This allows one to greatly reduce the amount of information in the high frequency components. This is done by simply dividing each component in the frequency domain by a constant for that component, and then rounding to the nearest integer. This rounding operation is the only lossy operation in the whole process (other than chroma subsampling) if the DCT computation is performed with sufficiently high precision. As a result of this, it is typically the case that many of the higher frequency components are rounded to zero, and many of the rest become small positive or negative numbers, which take many fewer bits to represent.

          The elements in the quantization matrix control the compression ratio, with larger values producing greater compression. A typical quantization matrix (for a quality of 50% as specified in the original JPEG Standard), is as follows:

          Q={begin{bmatrix}16&11&10&16&24&40&51&61\12&12&14&19&26&58&60&55\14&13&16&24&40&57&69&56\14&17&22&29&51&87&80&62\18&22&37&56&68&109&103&77\24&35&55&64&81&104&113&92\49&64&78&87&103&121&120&101\72&92&95&98&112&100&103&99end{bmatrix}}.

          The quantized DCT coefficients are computed with

          B_{j,k}=mathrm {round} left({frac {G_{j,k}}{Q_{j,k}}}right){mbox{ for }}j=0,1,2,ldots ,7;k=0,1,2,ldots ,7

          where G is the unquantized DCT coefficients; Q is the quantization matrix above; and B is the quantized DCT coefficients.

          Using this quantization matrix with the DCT coefficient matrix from above results in:

          Left: a final image is built up from a series of basis functions. Right: each of the DCT basis functions that comprise the image, and the corresponding weighting coefficient. Middle: the basis function, after multiplication by the coefficient: this component is added to the final image. For clarity, the 8×8 macroblock in this example is magnified by 10x using bilinear interpolation.

          B=left[{begin{array}{rrrrrrrr}-26&-3&-6&2&2&-1&0&0\0&-2&-4&1&1&0&0&0\-3&1&5&-1&-1&0&0&0\-3&1&2&-1&0&0&0&0\1&0&0&0&0&0&0&0\0&0&0&0&0&0&0&0\0&0&0&0&0&0&0&0\0&0&0&0&0&0&0&0end{array}}right].

          For example, using −415 (the DC coefficient) and rounding to the nearest integer

          mathrm {round} left({frac {-415.37}{16}}right)=mathrm {round} left(-25.96right)=-26.

          Notice that most of the higher-frequency elements of the sub-block (i.e., those with an x or y spatial frequency greater than 4) are quantized into zero values.

          Entropy coding[edit]

          Zigzag ordering of JPEG image components

          Entropy coding is a special form of lossless data compression. It involves arranging the image components in a «zigzag» order employing run-length encoding (RLE) algorithm that groups similar frequencies together, inserting length coding zeros, and then using Huffman coding on what is left.

          The JPEG standard also allows, but does not require, decoders to support the use of arithmetic coding, which is mathematically superior to Huffman coding. However, this feature has rarely been used, as it was historically covered by patents requiring royalty-bearing licenses, and because it is slower to encode and decode compared to Huffman coding. Arithmetic coding typically makes files about 5–7% smaller.

          The previous quantized DC coefficient is used to predict the current quantized DC coefficient. The difference between the two is encoded rather than the actual value. The encoding of the 63 quantized AC coefficients does not use such prediction differencing.

          The zigzag sequence for the above quantized coefficients are shown below. (The format shown is just for ease of understanding/viewing.)

          −26
          −3 0
          −3 −2 −6
          2 −4 1 −3
          1 1 5 1 2
          −1 1 −1 2 0 0
          0 0 0 −1 −1 0 0
          0 0 0 0 0 0 0 0
          0 0 0 0 0 0 0
          0 0 0 0 0 0
          0 0 0 0 0
          0 0 0 0
          0 0 0
          0 0
          0

          If the i-th block is represented by B_{i} and positions within each block are represented by (p,q) where p=0,1,...,7 and q=0,1,...,7, then any coefficient in the DCT image can be represented as B_{i}(p,q). Thus, in the above scheme, the order of encoding pixels (for the i-th block) is B_{i}(0,0), B_{i}(0,1), B_{i}(1,0), B_{i}(2,0), B_{i}(1,1), B_{i}(0,2), B_{i}(0,3), B_{i}(1,2) and so on.

          Baseline sequential JPEG encoding and decoding processes

          This encoding mode is called baseline sequential encoding. Baseline JPEG also supports progressive encoding. While sequential encoding encodes coefficients of a single block at a time (in a zigzag manner), progressive encoding encodes similar-positioned batch of coefficients of all blocks in one go (called a scan), followed by the next batch of coefficients of all blocks, and so on. For example, if the image is divided into N 8×8 blocks {displaystyle B_{0},B_{1},B_{2},...,B_{n-1}}, then a 3-scan progressive encoding encodes DC component, B_{i}(0,0) for all blocks, i.e., for all i=0,1,2,...,N-1, in first scan. This is followed by the second scan which encoding a few more components (assuming four more components, they are B_{i}(0,1) to B_{i}(1,1), still in a zigzag manner) coefficients of all blocks (so the sequence is: {displaystyle B_{0}(0,1),B_{0}(1,0),B_{0}(2,0),B_{0}(1,1),B_{1}(0,1),B_{1}(1,0),...,B_{N}(2,0),B_{N}(1,1)}), followed by all the remained coefficients of all blocks in the last scan.

          Once all similar-positioned coefficients have been encoded, the next position to be encoded is the one occurring next in the zigzag traversal as indicated in the figure above. It has been found that baseline progressive JPEG encoding usually gives better compression as compared to baseline sequential JPEG due to the ability to use different Huffman tables (see below) tailored for different frequencies on each «scan» or «pass» (which includes similar-positioned coefficients), though the difference is not too large.

          In the rest of the article, it is assumed that the coefficient pattern generated is due to sequential mode.

          In order to encode the above generated coefficient pattern, JPEG uses Huffman encoding. The JPEG standard provides general-purpose Huffman tables; encoders may also choose to generate Huffman tables optimized for the actual frequency distributions in images being encoded.

          The process of encoding the zig-zag quantized data begins with a run-length encoding explained below, where:

          • x is the non-zero, quantized AC coefficient.
          • RUNLENGTH is the number of zeroes that came before this non-zero AC coefficient.
          • SIZE is the number of bits required to represent x.
          • AMPLITUDE is the bit-representation of x.

          The run-length encoding works by examining each non-zero AC coefficient x and determining how many zeroes came before the previous AC coefficient. With this information, two symbols are created:

          Symbol 1 Symbol 2
          (RUNLENGTH, SIZE) (AMPLITUDE)

          Both RUNLENGTH and SIZE rest on the same byte, meaning that each only contains four bits of information. The higher bits deal with the number of zeroes, while the lower bits denote the number of bits necessary to encode the value of x.

          This has the immediate implication of Symbol 1 being only able store information regarding the first 15 zeroes preceding the non-zero AC coefficient. However, JPEG defines two special Huffman code words. One is for ending the sequence prematurely when the remaining coefficients are zero (called «End-of-Block» or «EOB»), and another when the run of zeroes goes beyond 15 before reaching a non-zero AC coefficient. In such a case where 16 zeroes are encountered before a given non-zero AC coefficient, Symbol 1 is encoded «specially» as: (15, 0)(0).

          The overall process continues until «EOB» – denoted by (0, 0) – is reached.

          With this in mind, the sequence from earlier becomes:

          (0, 2)(-3);(1, 2)(-3);(0, 1)(-2);(0, 2)(-6);(0, 1)(2);(0, 1)(-4);(0, 1)(1);(0, 2)(-3);(0, 1)(1);(0, 1)(1);
          (0, 2)(5);(0, 1)(1);(0, 1)(2);(0, 1)(-1);(0, 1)(1);(0, 1)(-1);(0, 1)(2);(5, 1)(-1);(0, 1)(-1);(0, 0);

          (The first value in the matrix, −26, is the DC coefficient; it is not encoded the same way. See above.)

          From here, frequency calculations are made based on occurrences of the coefficients. In our example block, most of the quantized coefficients are small numbers that are not preceded immediately by a zero coefficient. These more-frequent cases will be represented by shorter code words.

          Compression ratio and artifacts[edit]

          This image shows the pixels that are different between a non-compressed image and the same image JPEG compressed with a quality setting of 50. Darker means a larger difference. Note especially the changes occurring near sharp edges and having a block-like shape.

          The compressed 8×8 squares are visible in the scaled-up picture, together with other visual artifacts of the lossy compression.

          The resulting compression ratio can be varied according to need by being more or less aggressive in the divisors used in the quantization phase. Ten to one compression usually results in an image that cannot be distinguished by eye from the original. A compression ratio of 100:1 is usually possible, but will look distinctly artifacted compared to the original. The appropriate level of compression depends on the use to which the image will be put.

          External image
          image icon Illustration of edge busyness[52]

          Those who use the World Wide Web may be familiar with the irregularities known as compression artifacts that appear in JPEG images, which may take the form of noise around contrasting edges (especially curves and corners), or «blocky» images. These are due to the quantization step of the JPEG algorithm. They are especially noticeable around sharp corners between contrasting colors (text is a good example, as it contains many such corners). The analogous artifacts in MPEG video are referred to as mosquito noise, as the resulting «edge busyness» and spurious dots, which change over time, resemble mosquitoes swarming around the object.[52][53]

          These artifacts can be reduced by choosing a lower level of compression; they may be completely avoided by saving an image using a lossless file format, though this will result in a larger file size. The images created with ray-tracing programs have noticeable blocky shapes on the terrain. Certain low-intensity compression artifacts might be acceptable when simply viewing the images, but can be emphasized if the image is subsequently processed, usually resulting in unacceptable quality. Consider the example below, demonstrating the effect of lossy compression on an edge detection processing step.

          Image Lossless compression Lossy compression
          Original Lossless-circle.png Lossy-circle.jpg
          Processed by
          Canny edge detector
          Lossless-circle-canny.png Lossy-circle-canny.png

          Some programs allow the user to vary the amount by which individual blocks are compressed. Stronger compression is applied to areas of the image that show fewer artifacts. This way it is possible to manually reduce JPEG file size with less loss of quality.

          Since the quantization stage always results in a loss of information, JPEG standard is always a lossy compression codec. (Information is lost both in quantizing and rounding of the floating-point numbers.) Even if the quantization matrix is a matrix of ones, information will still be lost in the rounding step.

          Decoding[edit]

          Decoding to display the image consists of doing all the above in reverse.

          Taking the DCT coefficient matrix (after adding the difference of the DC coefficient back in)

          left[{begin{array}{rrrrrrrr}-26&-3&-6&2&2&-1&0&0\0&-2&-4&1&1&0&0&0\-3&1&5&-1&-1&0&0&0\-3&1&2&-1&0&0&0&0\1&0&0&0&0&0&0&0\0&0&0&0&0&0&0&0\0&0&0&0&0&0&0&0\0&0&0&0&0&0&0&0end{array}}right]

          and taking the entry-for-entry product with the quantization matrix from above results in

          left[{begin{array}{rrrrrrrr}-416&-33&-60&32&48&-40&0&0\0&-24&-56&19&26&0&0&0\-42&13&80&-24&-40&0&0&0\-42&17&44&-29&0&0&0&0\18&0&0&0&0&0&0&0\0&0&0&0&0&0&0&0\0&0&0&0&0&0&0&0\0&0&0&0&0&0&0&0end{array}}right]

          which closely resembles the original DCT coefficient matrix for the top-left portion.

          The next step is to take the two-dimensional inverse DCT (a 2D type-III DCT), which is given by:

          f_{x,y}={frac {1}{4}}sum _{u=0}^{7}sum _{v=0}^{7}alpha (u)alpha (v)F_{u,v}cos left[{frac {(2x+1)upi }{16}}right]cos left[{frac {(2y+1)vpi }{16}}right]

          where

          Rounding the output to integer values (since the original had integer values) results in an image with values (still shifted down by 128)

          Slight differences are noticeable between the original (top) and decompressed image (bottom), which is most readily seen in the bottom-left corner.

          left[{begin{array}{rrrrrrrr}-66&-63&-71&-68&-56&-65&-68&-46\-71&-73&-72&-46&-20&-41&-66&-57\-70&-78&-68&-17&20&-14&-61&-63\-63&-73&-62&-8&27&-14&-60&-58\-58&-65&-61&-27&-6&-40&-68&-50\-57&-57&-64&-58&-48&-66&-72&-47\-53&-46&-61&-74&-65&-63&-62&-45\-47&-34&-53&-74&-60&-47&-47&-41end{array}}right]

          and adding 128 to each entry

          left[{begin{array}{rrrrrrrr}62&65&57&60&72&63&60&82\57&55&56&82&108&87&62&71\58&50&60&111&148&114&67&65\65&55&66&120&155&114&68&70\70&63&67&101&122&88&60&78\71&71&64&70&80&62&56&81\75&82&67&54&63&65&66&83\81&94&75&54&68&81&81&87end{array}}right].

          This is the decompressed subimage. In general, the decompression process may produce values outside the original input range of [0,255]. If this occurs, the decoder needs to clip the output values so as to keep them within that range to prevent overflow when storing the decompressed image with the original bit depth.

          The decompressed subimage can be compared to the original subimage (also see images to the right) by taking the difference (original − uncompressed) results in the following error values:

          left[{begin{array}{rrrrrrrr}-10&-10&4&6&-2&-2&4&-9\6&4&-1&8&1&-2&7&1\4&9&8&2&-4&-10&-1&8\-2&3&5&2&-1&-8&2&-1\-3&-2&1&3&4&0&8&-8\8&-6&-4&-0&-3&6&2&-6\10&-11&-3&5&-8&-4&-1&-0\6&-15&-6&14&-3&-5&-3&7end{array}}right]

          with an average absolute error of about 5 values per pixels (i.e., {displaystyle {frac {1}{64}}sum _{x=0}^{7}sum _{y=0}^{7}|e(x,y)|=4.8750}).

          The error is most noticeable in the bottom-left corner where the bottom-left pixel becomes darker than the pixel to its immediate right.

          Required precision[edit]

          The required implementation precision of a JPEG codec is implicitly defined through the requirements formulated for compliance to the JPEG standard. These requirements are specified in ITU.T Recommendation T.83 | ISO/IEC 10918-2. Unlike MPEG standards and many later JPEG standards, the above document defines both required implementation precisions for the encoding and the decoding process of a JPEG codec by means of a maximal tolerable error of the forwards and inverse DCT in the DCT domain as determined by reference test streams. For example, the output of a decoder implementation must not exceed an error of one quantization unit in the DCT domain when applied to the reference testing codestreams provided as part of the above standard. While unusual, and unlike many other and more modern standards, ITU.T T.83 | ISO/IEC 10918-2 does not formulate error bounds in the image domain.

          Effects of JPEG compression[edit]

          JPEG compression artifacts blend well into photographs with detailed non-uniform textures, allowing higher compression ratios. Notice how a higher compression ratio first affects the high-frequency textures in the upper-left corner of the image, and how the contrasting lines become more fuzzy. The very high compression ratio severely affects the quality of the image, although the overall colors and image form are still recognizable. However, the precision of colors suffer less (for a human eye) than the precision of contours (based on luminance). This justifies the fact that images should be first transformed in a color model separating the luminance from the chromatic information, before subsampling the chromatic planes (which may also use lower quality quantization) in order to preserve the precision of the luminance plane with more information bits.

          Sample photographs[edit]

          Visual impact of a jpeg compression on Photoshop on a picture of 4480×4480 pixels

          For information, the uncompressed 24-bit RGB bitmap image below (73,242 pixels) would require 219,726 bytes (excluding all other information headers). The filesizes indicated below include the internal JPEG information headers and some metadata. For highest quality images (Q=100), about 8.25 bits per color pixel is required. On grayscale images, a minimum of 6.5 bits per pixel is enough (a comparable Q=100 quality color information requires about 25% more encoded bits). The highest quality image below (Q=100) is encoded at nine bits per color pixel, the medium quality image (Q=25) uses one bit per color pixel. For most applications, the quality factor should not go below 0.75 bit per pixel (Q=12.5), as demonstrated by the low quality image. The image at lowest quality uses only 0.13 bit per pixel, and displays very poor color. This is useful when the image will be displayed in a significantly scaled-down size. A method for creating better quantization matrices for a given image quality using PSNR instead of the Q factor is described in Minguillón & Pujol (2001).[54]

          Note: The above images are not IEEE / CCIR / EBU test images, and the encoder settings are not specified or available.

          Image Quality Size (bytes) Compression ratio Comment
          JPEG example JPG RIP 100.jpg Highest quality (Q = 100) 81,447 2.7:1 Extremely minor artifacts
          JPEG example JPG RIP 050.jpg High quality (Q = 50) 14,679 15:1 Initial signs of subimage artifacts
          JPEG example JPG RIP 025.jpg Medium quality (Q = 25) 9,407 23:1 Stronger artifacts; loss of high frequency information
          JPEG example JPG RIP 010.jpg Low quality (Q = 10) 4,787 46:1 Severe high frequency loss leads to obvious artifacts on subimage boundaries («macroblocking»)
          JPEG example JPG RIP 001.jpg Lowest quality (Q = 1) 1,523 144:1 Extreme loss of color and detail; the leaves are nearly unrecognizable.

          The medium quality photo uses only 4.3% of the storage space required for the uncompressed image, but has little noticeable loss of detail or visible artifacts. However, once a certain threshold of compression is passed, compressed images show increasingly visible defects. See the article on rate–distortion theory for a mathematical explanation of this threshold effect. A particular limitation of JPEG in this regard is its non-overlapped 8×8 block transform structure. More modern designs such as JPEG 2000 and JPEG XR exhibit a more graceful degradation of quality as the bit usage decreases – by using transforms with a larger spatial extent for the lower frequency coefficients and by using overlapping transform basis functions.

          Lossless further compression[edit]

          From 2004 to 2008, new research emerged on ways to further compress the data contained in JPEG images without modifying the represented image.[55][56][57][58] This has applications in scenarios where the original image is only available in JPEG format, and its size needs to be reduced for archiving or transmission. Standard general-purpose compression tools cannot significantly compress JPEG files.

          Typically, such schemes take advantage of improvements to the naive scheme for coding DCT coefficients, which fails to take into account:

          • Correlations between magnitudes of adjacent coefficients in the same block;
          • Correlations between magnitudes of the same coefficient in adjacent blocks;
          • Correlations between magnitudes of the same coefficient/block in different channels;
          • The DC coefficients when taken together resemble a downscale version of the original image multiplied by a scaling factor. Well-known schemes for lossless coding of continuous-tone images can be applied, achieving somewhat better compression than the Huffman coded DPCM used in JPEG.

          Some standard but rarely used options already exist in JPEG to improve the efficiency of coding DCT coefficients: the arithmetic coding option, and the progressive coding option (which produces lower bitrates because values for each coefficient are coded independently, and each coefficient has a significantly different distribution). Modern methods have improved on these techniques by reordering coefficients to group coefficients of larger magnitude together;[55] using adjacent coefficients and blocks to predict new coefficient values;[57] dividing blocks or coefficients up among a small number of independently coded models based on their statistics and adjacent values;[56][57] and most recently, by decoding blocks, predicting subsequent blocks in the spatial domain, and then encoding these to generate predictions for DCT coefficients.[58]

          Typically, such methods can compress existing JPEG files between 15 and 25 percent, and for JPEGs compressed at low-quality settings, can produce improvements of up to 65%.[57][58]

          A freely available tool called packJPG is based on the 2007 paper «Improved Redundancy Reduction for JPEG Files.» As of version 2.5k of 2016, it reports a typical 20% reduction by transcoding.[59] JPEG XL (ISO/IEC 18181) of 2018 reports a similar reduction in its transcoding.

          Derived formats for stereoscopic 3D[edit]

          JPEG Stereoscopic[edit]

          An example of a stereoscopic .JPS file

          JPS is a stereoscopic JPEG image used for creating 3D effects from 2D images. It contains two static images, one for the left eye and one for the right eye; encoded as two side-by-side images in a single JPG file.
          JPEG Stereoscopic (JPS, extension .jps) is a JPEG-based format for stereoscopic images.[60][61] It has a range of configurations stored in the JPEG APP3 marker field, but usually contains one image of double width, representing two images of identical size in cross-eyed (i.e. left frame on the right half of the image and vice versa) side-by-side arrangement. This file format can be viewed as a JPEG without any special software, or can be processed for rendering in other modes.

          JPEG Multi-Picture Format[edit]

          JPEG Multi-Picture Format (MPO, extension .mpo) is a JPEG-based format for storing multiple images in a single file. It contains two or more JPEG files concatenated together.[62][63] It also defines a JPEG APP2 marker segment for image description. Various devices use it to store 3D images, such as Fujifilm FinePix Real 3D W1, HTC Evo 3D, JVC GY-HMZ1U AVCHD/MVC extension camcorder, Nintendo 3DS, Panasonic Lumix DMC-TZ20, DMC-TZ30, DMC-TZ60, DMC-TS4 (FT4), and Sony DSC-HX7V. Other devices use it to store «preview images» that can be displayed on a TV.

          In the last few years, due to the growing use of stereoscopic images, much effort has been spent by the scientific community to develop algorithms for stereoscopic image compression.[64][65]

          Implementations[edit]

          A very important implementation of a JPEG codec is the free programming library libjpeg of the Independent JPEG Group. It was first published in 1991 and was key for the success of the standard. This library was used in countless applications. [66] The development went quiet in 1998; when libjpeg resurfaced with the 2009 version 7, it broke ABI compatibility with previous versions. Version 8 of 2010 introduced non-standard extensions, a decision critized by the original IJG leader Tom Lane.[67]

          libjpeg-turbo, forked from the 1998 libjpeg 6b, improves on libjpeg with SIMD optimizations. Originally seen as a maintained fork of libjpeg, it has become more popular after the incompatible changes of 2009.[68][69] In 2019, it became the ITU|ISO/IEC reference implementation as ISO/IEC 10918-7 and ITU-T T.873.[70]

          ISO/IEC Joint Photography Experts Group maintains the other reference software implementation under the JPEG XT heading. It can encode both base JPEG (ISO/IEC 10918-1 and 18477–1) and JPEG XT extensions (ISO/IEC 18477 Parts 2 and 6–9), as well as JPEG-LS (ISO/IEC 14495).[71]

          There is persistent interest in encoding JPEG in unconventional ways that maximize image quality for a given file size. In 2014, Mozilla created mozjpeg from libjpeg-turbo, a slower but higher-quality encoder intended for web images.[72] In 2016, «JPEG on steroids» was introduced as an option for the ISO JPEG XT reference implementation.[73] In March 2017, Google released the open source project Guetzli, which trades off a much longer encoding time for smaller file size (similar to what Zopfli does for PNG and other lossless data formats).[74]

          JPEG XT[edit]

          JPEG XT (ISO/IEC 18477) was published in June 2015; it extends base JPEG format with support for higher integer bit depths (up to 16 bit), high dynamic range imaging and floating-point coding, lossless coding, and alpha channel coding. Extensions are backward compatible with the base JPEG/JFIF file format and 8-bit lossy compressed image. JPEG XT uses an extensible file format based on JFIF. Extension layers are used to modify the JPEG 8-bit base layer and restore the high-resolution image. Existing software is forward compatible and can read the JPEG XT binary stream, though it would only decode the base 8-bit layer.[75]

          JPEG XL[edit]

          JPEG XL (ISO/IEC 18181) was published in 2021–2022. It replaces the JPEG format with a new DCT-based royalty-free format and allows efficient transcoding as a storage option for traditional JPEG images.[76] The new format is designed to exceed the still image compression performance shown by HEVC HM, Daala and WebP. It supports billion-by-billion pixel images, up to 32-bit-per-component high dynamic range with the appropriate transfer functions (PQ and HLG), patch encoding of synthetic images such as bitmap fonts and gradients, animated images, alpha channel coding, and a choice of RGB/YCbCr/ICtCp color encoding.[77][78][79][80]

          See also[edit]

          • Better Portable Graphics, a format based on intra-frame encoding of the HEVC
          • C-Cube, an early implementer of JPEG in chip form
          • Comparison of graphics file formats
          • Deblocking filter (video), the similar deblocking methods could be applied to JPEG
          • Design rule for Camera File system (DCF)
          • FELICS, a lossless image codec
          • File extensions
          • Graphics editing program
          • High Efficiency Image File Format, image container format for HEVC and other image coding formats
          • Lenna (test image), the traditional standard image used to test image processing algorithms
          • Motion JPEG
          • WebP

          References[edit]

          1. ^ a b c d e «T.81 – DIGITAL COMPRESSION AND CODING OF CONTINUOUS-TONE STILL IMAGES – REQUIREMENTS AND GUIDELINES» (PDF). CCITT. September 1992. Retrieved 12 July 2019.
          2. ^ «Definition of «JPEG»«. Collins English Dictionary. Retrieved 2013-05-23.
          3. ^ Haines, Richard F.; Chuang, Sherry L. (1 July 1992). The effects of video compression on acceptability of images for monitoring life sciences experiments (Technical report). NASA. NASA-TP-3239, A-92040, NAS 1.60:3239. Retrieved 2016-03-13. The JPEG still-image-compression levels, even with the large range of 5:1 to 120:1 in this study, yielded equally high levels of acceptability
          4. ^ a b Hudson, Graham; Léger, Alain; Niss, Birger; Sebestyén, István; Vaaben, Jørgen (31 August 2018). «JPEG-1 standard 25 years: past, present, and future reasons for a success». Journal of Electronic Imaging. 27 (4): 1. doi:10.1117/1.JEI.27.4.040901. S2CID 52164892.
          5. ^ «The JPEG Image Format Explained». BT.com. BT Group. 31 May 2018. Archived from the original on 5 August 2019. Retrieved 5 August 2019.
          6. ^ Baraniuk, Chris (15 October 2015). «Copy Protections Could Come to JPEGs». BBC News. BBC. Retrieved 13 September 2019.
          7. ^ «JPEG: 25 Jahre und kein bisschen alt». Heise online (in German). October 2016. Retrieved 5 September 2019.
          8. ^ «What Is a JPEG? The Invisible Object You See Every Day». The Atlantic. 24 September 2013. Retrieved 13 September 2019.
          9. ^ «HTTP Archive — Interesting Stats». httparchive.org. Retrieved 2016-04-06.
          10. ^ «MIME Type Detection in Internet Explorer». Microsoft. Retrieved 2 November 2022.
          11. ^ «JPEG File Interchange Format» (PDF). 3 September 2014. Archived from the original on 3 September 2014. Retrieved 16 October 2017.{{cite web}}: CS1 maint: bot: original URL status unknown (link)
          12. ^ «Why JPEG 2000 Never Took Off». American National Standards Institute. 10 July 2018. Retrieved 13 September 2019.
          13. ^ a b c d Lemos, Robert (23 July 2002). «Finding patent truth in JPEG claim». CNET. Retrieved 13 July 2019.
          14. ^ ISO/IEC JTC 1/SC 29 (2009-05-07). «ISO/IEC JTC 1/SC 29/WG 1 – Coding of Still Pictures (SC 29/WG 1 Structure)». Archived from the original on 2013-12-31. Retrieved 2009-11-11.
          15. ^ a b ISO/IEC JTC 1/SC 29. «Programme of Work, (Allocated to SC 29/WG 1)». Archived from the original on 2013-12-31. Retrieved 2009-11-07.
          16. ^ ISO. «JTC 1/SC 29 – Coding of audio, picture, multimedia and hypermedia information». Retrieved 2009-11-11.
          17. ^ a b JPEG. «Joint Photographic Experts Group, JPEG Homepage». Retrieved 2009-11-08.
          18. ^ «T.81 : Information technology – Digital compression and coding of continuous-tone still images – Requirements and guidelines». Itu.int. Retrieved 2009-11-07.
          19. ^
            William B. Pennebaker; Joan L. Mitchell (1993). JPEG still image data compression standard (3rd ed.). Springer. p. 291. ISBN 978-0-442-01272-4.
          20. ^ ISO. «JTC 1/SC 29 – Coding of audio, picture, multimedia and hypermedia information». Retrieved 2009-11-07.
          21. ^ «SPIFF, Still Picture Interchange File Format». Library of Congress. 30 January 2012. Archived from the original on 2018-07-31. Retrieved 2018-07-31.
          22. ^ JPEG (2009-04-24). «JPEG XR enters FDIS status: JPEG File Interchange Format (JFIF) to be standardized as JPEG Part 5» (Press release). Archived from the original on 2009-10-08. Retrieved 2009-11-09.
          23. ^ «JPEG File Interchange Format (JFIF)». ECMA TR/98 1st ed. Ecma International. 2009. Retrieved 2011-08-01.
          24. ^ «Forgent’s JPEG Patent». SourceForge. 2002. Retrieved 13 July 2019.
          25. ^ «Concerning recent patent claims». Jpeg.org. 2002-07-19. Archived from the original on 2007-07-14. Retrieved 2011-05-29.
          26. ^ «JPEG and JPEG2000 – Between Patent Quarrel and Change of Technology». Archived from the original on August 17, 2004. Retrieved 2017-04-16.{{cite web}}: CS1 maint: bot: original URL status unknown (link)
          27. ^ Kawamoto, Dawn (April 22, 2005). «Graphics patent suit fires back at Microsoft». CNET News. Retrieved 2023-01-20.
          28. ^ «Trademark Office Re-examines Forgent JPEG Patent». Publish.com. February 3, 2006. Archived from the original on 2016-05-15. Retrieved 2009-01-28.
          29. ^ «USPTO: Broadest Claims Forgent Asserts Against JPEG Standard Invalid». Groklaw.net. May 26, 2006. Retrieved 2007-07-21.
          30. ^ «Coding System for Reducing Redundancy». Gauss.ffii.org. Archived from the original on 2011-06-12. Retrieved 2011-05-29.
          31. ^ «JPEG Patent Claim Surrendered». Public Patent Foundation. November 2, 2006. Retrieved 2006-11-03.
          32. ^ «Ex Parte Reexamination Certificate for U.S. Patent No. 5,253,341». Archived from the original on June 2, 2008.
          33. ^ Workgroup. «Rozmanith: Using Software Patents to Silence Critics». Eupat.ffii.org. Archived from the original on 2011-07-16. Retrieved 2011-05-29.
          34. ^ «A Bounty of $5,000 to Name Troll Tracker: Ray Niro Wants To Know Who Is saying All Those Nasty Things About Him». Law.com. Retrieved 2011-05-29.
          35. ^ Reimer, Jeremy (2008-02-05). «Hunting trolls: USPTO asked to reexamine broad image patent». Arstechnica.com. Retrieved 2011-05-29.
          36. ^ U.S. Patent Office – Granting Reexamination on 5,253,341 C1
          37. ^ «Judge Puts JPEG Patent On Ice». Techdirt.com. 2008-04-30. Retrieved 2011-05-29.
          38. ^ «JPEG Patent’s Single Claim Rejected (And Smacked Down For Good Measure)». Techdirt.com. 2008-08-01. Retrieved 2011-05-29.
          39. ^ Workgroup. «Princeton Digital Image Corporation Home Page». Archived from the original on 2013-04-11. Retrieved 2013-05-01.
          40. ^ Workgroup. «Article on Princeton Court Ruling Regarding GE License Agreement». Archived from the original on 2016-03-09. Retrieved 2013-05-01.
          41. ^ «Progressive Decoding Overview». Microsoft Developer Network. Microsoft. Retrieved 2012-03-23.
          42. ^ Fastvideo (May 2019). «12-bit JPEG encoder on GPU». Retrieved 2019-05-06.
          43. ^ «Why You Should Always Rotate Original JPEG Photos Losslessly». Petapixel.com. 14 August 2012. Retrieved 16 October 2017.
          44. ^ «JFIF File Format as PDF» (PDF).
          45. ^ Tom Lane (1999-03-29). «JPEG image compression FAQ». Retrieved 2007-09-11. (q. 14: «Why all the argument about file formats?»)
          46. ^ a b «A Standard Default Color Space for the Internet — sRGB». www.w3.org.
          47. ^ a b «IEC 61966-2-1:1999/AMD1:2003 | IEC Webstore». webstore.iec.ch.
          48. ^ «ISO/IEC 10918-1 : 1993(E) p.36».
          49. ^ Thomas G. Lane. «Advanced Features: Compression parameter selection». Using the IJG JPEG Library.
          50. ^ Ryan, Dan (2012-06-20). E — Learning Modules: Dlr Associates Series. AuthorHouse. ISBN 9781468575200.
          51. ^ «DC / AC Frequency Questions — Doom9’s Forum». forum.doom9.org. Retrieved 16 October 2017.
          52. ^ a b Phuc-Tue Le Dinh and Jacques Patry. Video compression artifacts and MPEG noise reduction Archived 2006-03-14 at the Wayback Machine. Video Imaging DesignLine. February 24, 2006. Retrieved May 28, 2009.
          53. ^ «3.9 mosquito noise: Form of edge busyness distortion sometimes associated with movement, characterized by moving artifacts and/or blotchy noise patterns superimposed over the objects (resembling a mosquito flying around a person’s head and shoulders).»
            ITU-T Rec. P.930 (08/96) Principles of a reference impairment system for video Archived 2010-02-16 at the Wayback Machine
          54. ^ Julià Minguillón, Jaume Pujol (April 2001). «JPEG standard uniform quantization error modeling with applications to sequential and progressive operation modes» (PDF). Electronic Imaging. 10 (2): 475–485. Bibcode:2001JEI….10..475M. doi:10.1117/1.1344592. hdl:10609/6263.
          55. ^ a b I. Bauermann and E. Steinbacj. Further Lossless Compression of JPEG Images. Proc. of Picture Coding Symposium (PCS 2004), San Francisco, US, December 15–17, 2004.
          56. ^ a b N. Ponomarenko, K. Egiazarian, V. Lukin and J. Astola. Additional Lossless Compression of JPEG Images, Proc. of the 4th Intl. Symposium on Image and Signal Processing and Analysis (ISPA 2005), Zagreb, Croatia, pp. 117–120, September 15–17, 2005.
          57. ^ a b c d M. Stirner and G. Seelmann. Improved Redundancy Reduction for JPEG Files. Proc. of Picture Coding Symposium (PCS 2007), Lisbon, Portugal, November 7–9, 2007
          58. ^ a b c Ichiro Matsuda, Yukio Nomoto, Kei Wakabayashi and Susumu Itoh. Lossless Re-encoding of JPEG images using block-adaptive intra prediction. Proceedings of the 16th European Signal Processing Conference (EUSIPCO 2008).
          59. ^ Stirner, Matthias (19 February 2023). «packjpg/packJPG».
          60. ^ J. Siragusa, D. C. Swift (1997). «General Purpose Stereoscopic Data Descriptor» (PDF). VRex, Inc., Elmsford, New York, US. Archived from the original (PDF) on 2011-10-30.{{cite web}}: CS1 maint: uses authors parameter (link)
          61. ^ Tim Kemp, JPS files
          62. ^ «Multi-Picture Format» (PDF). 2009. Archived from the original (PDF) on 2016-04-05. Retrieved 2015-12-30.
          63. ^ «MPO2Stereo: Convert Fujifilm MPO files to JPEG stereo pairs», Mtbs3d.com, retrieved 12 January 2010
          64. ^ Alessandro Ortis; Sebastiano Battiato (2015), Sitnik, Robert; Puech, William (eds.), «A new fast matching method for adaptive compression of stereoscopic images», Three-Dimensional Image Processing, Three-Dimensional Image Processing, Measurement (3DIPM), and Applications 2015, SPIE — Three-Dimensional Image Processing, Measurement (3DIPM), and Applications 2015, 9393: 93930K, Bibcode:2015SPIE.9393E..0KO, doi:10.1117/12.2086372, S2CID 18879942, retrieved 30 April 2015
          65. ^ Alessandro Ortis; Francesco Rundo; Giuseppe Di Giore; Sebastiano Battiato, Adaptive Compression of Stereoscopic Images, International Conference on Image Analysis and Processing (ICIAP) 2013, retrieved 30 April 2015
          66. ^ «Overview of JPEG». jpeg.org. Retrieved 2017-10-16.
          67. ^ Tom Lane, January 16, 2013: jpeg-9, API/ABI compatibility, and the future role of this project
          68. ^ Software That Uses or Provides libjpeg-turbo. February 9, 2012.
          69. ^ Issue 48789 – chromium – Use libjpeg-turbo instead of libjpeg. April 14, 2011.
          70. ^ «ISO/IEC 10918-7: 2019 Information technology — Digital compression and coding of continuous-tone still images — Part 7: Reference software». ISO.«T.873 (05/19): Information technology — Digital compression and coding of continuous-tone still images: Reference software». www.itu.int.
          71. ^ «JPEG — JPEG XT». jpeg.org.
          72. ^ «Introducing the ‘mozjpeg’ Project». Mozilla Research.
          73. ^ Richter, Thomas (September 2016). «JPEG on STEROIDS: Common optimization techniques for JPEG image compression». 2016 IEEE International Conference on Image Processing (ICIP): 61–65. doi:10.1109/ICIP.2016.7532319. ISBN 978-1-4673-9961-6. S2CID 14922251.
          74. ^ «Announcing Guetzli: A New Open Source JPEG Encoder». Research.googleblog.com. Retrieved 16 October 2017.
          75. ^ «JPEG — JPEG XT». jpeg.org.
          76. ^ Alakuijala, Jyrki; van Asseldonk, Ruud; Boukortt, Sami; Bruse, Martin; Comșa, Iulia-Maria; Firsching, Moritz; Fischbacher, Thomas; Kliuchnikov, Evgenii; Gomez, Sebastian; Obryk, Robert; Potempa, Krzysztof; Rhatushnyak, Alexander; Sneyers, Jon; Szabadka, Zoltan; Vandervenne, Lode; Versari, Luca; Wassenberg, Jan (2019-09-06). «JPEG XL next-generation image compression architecture and coding tools». In Tescher, Andrew G; Ebrahimi, Touradj (eds.). Applications of Digital Image Processing XLII. p. 20. doi:10.1117/12.2529237. ISBN 9781510629677. S2CID 202785129.
          77. ^ Rhatushnyak, Alexander; Wassenberg, Jan; Sneyers, Jon; Alakuijala, Jyrki; Vandevenne, Lode; Versari, Luca; Obryk, Robert; Szabadka, Zoltan; Kliuchnikov, Evgenii; Comsa, Iulia-Maria; Potempa, Krzysztof; Bruse, Martin; Firsching, Moritz; Khasanova, Renata; Ruud van Asseldonk; Boukortt, Sami; Gomez, Sebastian; Fischbacher, Thomas (2019). «Committee Draft of JPEG XL Image Coding System». arXiv:1908.03565 [eess.IV].
          78. ^ «N79010 Final Call for Proposals for a Next-Generation Image Coding Standard (JPEG XL)» (PDF). ISO/IEC JTC 1/SC 29/WG 1 (ITU-T SG16). Retrieved 29 May 2018.
          79. ^ ISO/IEC 18181-1:2022 Information technology — JPEG XL image coding system — Part 1: Core coding system.
          80. ^ ISO/IEC 18181-2:2021 Information technology — JPEG XL image coding system — Part 2: File format.

          External links[edit]

          • Official website Edit this at Wikidata
          • JPEG Standard (JPEG ISO/IEC 10918-1 ITU-T Recommendation T.81) at W3.org
          • JFIF File Format at W3.org
          • Example images over the full range of quantization levels from 1 to 100 at visengi.com
          • JPEG decoder open source code, copyright (C) 1995–1997, Thomas G. Lane
          JPEG

          Felis silvestris silvestris small gradual decrease of quality.png

          A photo of a European wildcat with the compression rate decreasing and hence quality increasing, from left to right

          Filename extension

          .jpg, .jpeg, .jpe
          .jif, .jfif, .jfi

          Internet media type

          image/jpeg

          Type code JPEG
          Uniform Type Identifier (UTI) public.jpeg
          Magic number ff d8 ff
          Developed by Joint Photographic Experts Group, IBM, Mitsubishi Electric, AT&T, Canon Inc.[1]
          Initial release September 18, 1992; 30 years ago
          Type of format Lossy image compression format
          Extended to JPEG 2000
          Standard ISO/IEC 10918, ITU-T T.81, ITU-T T.83, ITU-T T.84, ITU-T T.86
          Website jpeg.org/jpeg/ Edit this at Wikidata

          Continuously varied JPEG compression (between Q=100 and Q=1) for an abdominal CT scan

          JPEG ( JAY-peg)[2] is a commonly used method of lossy compression for digital images, particularly for those images produced by digital photography. The degree of compression can be adjusted, allowing a selectable tradeoff between storage size and image quality. JPEG typically achieves 10:1 compression with little perceptible loss in image quality.[3] Since its introduction in 1992, JPEG has been the most widely used image compression standard in the world,[4][5] and the most widely used digital image format, with several billion JPEG images produced every day as of 2015.[6]

          The term «JPEG» is an acronym for the Joint Photographic Experts Group, which created the standard in 1992.[7] JPEG was largely responsible for the proliferation of digital images and digital photos across the Internet and later social media.[8]

          JPEG compression is used in a number of image file formats. JPEG/Exif is the most common image format used by digital cameras and other photographic image capture devices; along with JPEG/JFIF, it is the most common format for storing and transmitting photographic images on the World Wide Web.[9] These format variations are often not distinguished and are simply called JPEG.

          The MIME media type for JPEG is «image/jpeg,» except in older Internet Explorer versions, which provide a MIME type of «image/pjpeg» when uploading JPEG images.[10] JPEG files usually have a filename extension of «jpg» or «jpeg.» JPEG/JFIF supports a maximum image size of 65,535×65,535 pixels,[11] hence up to 4 gigapixels for an aspect ratio of 1:1. In 2000, the JPEG group introduced a format intended to be a successor, JPEG 2000, but it was unable to replace the original JPEG as the dominant image standard.[12]

          History[edit]

          Background[edit]

          The original JPEG specification published in 1992 implements processes from various earlier research papers and patents cited by the CCITT (now ITU-T) and Joint Photographic Experts Group.[1]

          The JPEG specification cites patents from several companies. The following patents provided the basis for its arithmetic coding algorithm.[1]

          • IBM
            • U.S. Patent 4,652,856 – February 4, 1986 – Kottappuram M. A. Mohiuddin and Jorma J. Rissanen – Multiplication-free multi-alphabet arithmetic code
            • U.S. Patent 4,905,297 – February 27, 1990 – G. Langdon, J.L. Mitchell, W.B. Pennebaker, and Jorma J. Rissanen – Arithmetic coding encoder and decoder system
            • U.S. Patent 4,935,882 – June 19, 1990 – W.B. Pennebaker and J.L. Mitchell – Probability adaptation for arithmetic coders
          • Mitsubishi Electric
            • JP H02202267 (1021672) – January 21, 1989 – Toshihiro Kimura, Shigenori Kino, Fumitaka Ono, Masayuki Yoshida – Coding system
            • JP H03247123 (2-46275) – February 26, 1990 – Fumitaka Ono, Tomohiro Kimura, Masayuki Yoshida, and Shigenori Kino – Coding apparatus and coding method

          The JPEG specification also cites three other patents from IBM. Other companies cited as patent holders include AT&T (two patents) and Canon Inc.[1] Absent from the list is U.S. Patent 4,698,672, filed by Compression Labs’ Wen-Hsiung Chen and Daniel J. Klenke in October 1986. The patent describes a DCT-based image compression algorithm, and would later be a cause of controversy in 2002 (see Patent controversy below).[13] However, the JPEG specification did cite two earlier research papers by Wen-Hsiung Chen, published in 1977 and 1984.[1]

          JPEG standard[edit]

          «JPEG» stands for Joint Photographic Experts Group, the name of the committee that created the JPEG standard and also other still picture coding standards. The «Joint» stood for ISO TC97 WG8 and CCITT SGVIII. Founded in 1986, the group developed the JPEG standard during the late 1980s. The group published the JPEG standard in 1992.[4]

          In 1987, ISO TC 97 became ISO/IEC JTC 1 and, in 1992, CCITT became ITU-T. Currently on the JTC1 side, JPEG is one of two sub-groups of ISO/IEC Joint Technical Committee 1, Subcommittee 29, Working Group 1 (ISO/IEC JTC 1/SC 29/WG 1) – titled as Coding of still pictures.[14][15][16] On the ITU-T side, ITU-T SG16 is the respective body. The original JPEG Group was organized in 1986,[17] issuing the first JPEG standard in 1992, which was approved in September 1992 as ITU-T Recommendation T.81[18] and, in 1994, as ISO/IEC 10918-1.

          The JPEG standard specifies the codec, which defines how an image is compressed into a stream of bytes and decompressed back into an image, but not the file format used to contain that stream.[19]
          The Exif and JFIF standards define the commonly used file formats for interchange of JPEG-compressed images.

          JPEG standards are formally named as Information technology – Digital compression and coding of continuous-tone still images. ISO/IEC 10918 consists of the following parts:

          Digital compression and coding of continuous-tone still images – Parts[15][17][20]

          Part ISO/IEC standard ITU-T Rec. First public release date Latest amendment Title Description
          Part 1 ISO/IEC 10918-1:1994 T.81 (09/92) Sep 18, 1992 Requirements and guidelines
          Part 2 ISO/IEC 10918-2:1995 T.83 (11/94) Nov 11, 1994 Compliance testing Rules and checks for software conformance (to Part 1).
          Part 3 ISO/IEC 10918-3:1997 T.84 (07/96) Jul 3, 1996 Apr 1, 1999 Extensions Set of extensions to improve the Part 1, including the Still Picture Interchange File Format (SPIFF).[21]
          Part 4 ISO/IEC 10918-4:1999 T.86 (06/98) Jun 18, 1998 Jun 29, 2012 Registration of JPEG profiles, SPIFF profiles, SPIFF tags, SPIFF colour spaces, APPn markers, SPIFF compression types and Registration Authorities (REGAUT) methods for registering some of the parameters used to extend JPEG
          Part 5 ISO/IEC 10918-5:2013 T.871 (05/11) May 14, 2011 JPEG File Interchange Format (JFIF) A popular format which has been the de facto file format for images encoded by the JPEG standard. In 2009, the JPEG Committee formally established an Ad Hoc Group to standardize JFIF as JPEG Part 5.[22]
          Part 6 ISO/IEC 10918-6:2013 T.872 (06/12) Jun 2012 Application to printing systems Specifies a subset of features and application tools for the interchange of images encoded according to the ISO/IEC 10918-1 for printing.
          Part 7 ISO/IEC 10918-7:2021 T.873 (06/21) May 2019 June 2021 Reference Software Provides reference implementations of the JPEG core coding system

          Ecma International TR/98 specifies the JPEG File Interchange Format (JFIF); the first edition was published in June 2009.[23]

          Patent controversy[edit]

          In 2002, Forgent Networks asserted that it owned and would enforce patent rights on the JPEG technology, arising from a patent that had been filed on October 27, 1986, and granted on October 6, 1987: U.S. Patent 4,698,672 by Compression Labs’ Wen-Hsiung Chen and Daniel J. Klenke.[13][24] While Forgent did not own Compression Labs at the time, Chen later sold Compression Labs to Forgent, before Chen went on to work for Cisco. This led to Forgent acquiring ownership over the patent.[13] Forgent’s 2002 announcement created a furor reminiscent of Unisys’ attempts to assert its rights over the GIF image compression standard.

          The JPEG committee investigated the patent claims in 2002 and were of the opinion that they were invalidated by prior art,[25] a view shared by various experts.[13][26]

          Between 2002 and 2004, Forgent was able to obtain about US$105 million by licensing their patent to some 30 companies. In April 2004, Forgent sued 31 other companies to enforce further license payments. In July of the same year, a consortium of 21 large computer companies filed a countersuit, with the goal of invalidating the patent. In addition, Microsoft launched a separate lawsuit against Forgent in April 2005.[27] In February 2006, the United States Patent and Trademark Office agreed to re-examine Forgent’s JPEG patent at the request of the Public Patent Foundation.[28] On May 26, 2006, the USPTO found the patent invalid based on prior art. The USPTO also found that Forgent knew about the prior art, yet it intentionally avoided telling the Patent Office. This makes any appeal to reinstate the patent highly unlikely to succeed.[29]

          Forgent also possesses a similar patent granted by the European Patent Office in 1994, though it is unclear how enforceable it is.[30]

          As of October 27, 2006, the U.S. patent’s 20-year term appears to have expired, and in November 2006, Forgent agreed to abandon enforcement of patent claims against use of the JPEG standard.[31]

          The JPEG committee has as one of its explicit goals that their standards (in particular their baseline methods) be implementable without payment of license fees, and they have secured appropriate license rights for their JPEG 2000 standard from over 20 large organizations.

          Beginning in August 2007, another company, Global Patent Holdings, LLC claimed that its patent (U.S. Patent 5,253,341) issued in 1993, is infringed by the downloading of JPEG images on either a website or through e-mail. If not invalidated, this patent could apply to any website that displays JPEG images. The patent was under reexamination by the U.S. Patent and Trademark Office from 2000 to 2007; in July 2007, the Patent Office revoked all of the original claims of the patent but found that an additional claim proposed by Global Patent Holdings (claim 17) was valid.[32] Global Patent Holdings then filed a number of lawsuits based on claim 17 of its patent.

          In its first two lawsuits following the reexamination, both filed in Chicago, Illinois, Global Patent Holdings sued the Green Bay Packers, CDW, Motorola, Apple, Orbitz, Officemax, Caterpillar, Kraft and Peapod as defendants. A third lawsuit was filed on December 5, 2007, in South Florida against ADT Security Services, AutoNation, Florida Crystals Corp., HearUSA, MovieTickets.com, Ocwen Financial Corp. and Tire Kingdom, and a fourth lawsuit on January 8, 2008, in South Florida against the Boca Raton Resort & Club. A fifth lawsuit was filed against Global Patent Holdings in Nevada. That lawsuit was filed by Zappos.com, Inc., which was allegedly threatened by Global Patent Holdings, and sought a judicial declaration that the ‘341 patent is invalid and not infringed.

          Global Patent Holdings had also used the ‘341 patent to sue or threaten outspoken critics of broad software patents, including Gregory Aharonian[33] and the anonymous operator of a website blog known as the «Patent Troll Tracker.»[34] On December 21, 2007, patent lawyer Vernon Francissen of Chicago asked the U.S. Patent and Trademark Office to reexamine the sole remaining claim of the ‘341 patent on the basis of new prior art.[35]

          On March 5, 2008, the U.S. Patent and Trademark Office agreed to reexamine the ‘341 patent, finding that the new prior art raised substantial new questions regarding the patent’s validity.[36] In light of the reexamination, the accused infringers in four of the five pending lawsuits have filed motions to suspend (stay) their cases until completion of the U.S. Patent and Trademark Office’s review of the ‘341 patent. On April 23, 2008, a judge presiding over the two lawsuits in Chicago, Illinois granted the motions in those cases.[37] On July 22, 2008, the Patent Office issued the first «Office Action» of the second reexamination, finding the claim invalid based on nineteen separate grounds.[38] On Nov. 24, 2009, a Reexamination Certificate was issued cancelling all claims.

          Beginning in 2011 and continuing as of early 2013, an entity known as Princeton Digital Image Corporation,[39] based in Eastern Texas, began suing large numbers of companies for alleged infringement of U.S. Patent 4,813,056. Princeton claims that the JPEG image compression standard infringes the ‘056 patent and has sued large numbers of websites, retailers, camera and device manufacturers and resellers. The patent was originally owned and assigned to General Electric. The patent expired in December 2007, but Princeton has sued large numbers of companies for «past infringement» of this patent. (Under U.S. patent laws, a patent owner can sue for «past infringement» up to six years before the filing of a lawsuit, so Princeton could theoretically have continued suing companies until December 2013.) As of March 2013, Princeton had suits pending in New York and Delaware against more than 55 companies. General Electric’s involvement in the suit is unknown, although court records indicate that it assigned the patent to Princeton in 2009 and retains certain rights in the patent.[40]

          Typical use[edit]

          The JPEG compression algorithm operates at its best on photographs and paintings of realistic scenes with smooth variations of tone and color. For web usage, where reducing the amount of data used for an image is important for responsive presentation, JPEG’s compression benefits make JPEG popular. JPEG/Exif is also the most common format saved by digital cameras.

          However, JPEG is not well suited for line drawings and other textual or iconic graphics, where the sharp contrasts between adjacent pixels can cause noticeable artifacts. Such images are better saved in a lossless graphics format such as TIFF, GIF, PNG, or a raw image format. The JPEG standard includes a lossless coding mode, but that mode is not supported in most products.

          As the typical use of JPEG is a lossy compression method, which reduces the image fidelity, it is inappropriate for exact reproduction of imaging data (such as some scientific and medical imaging applications and certain technical image processing work).

          JPEG is also not well suited to files that will undergo multiple edits, as some image quality is lost each time the image is recompressed, particularly if the image is cropped or shifted, or if encoding parameters are changed – see digital generation loss for details. To prevent image information loss during sequential and repetitive editing, the first edit can be saved in a lossless format, subsequently edited in that format, then finally published as JPEG for distribution.

          JPEG compression[edit]

          JPEG uses a lossy form of compression based on the discrete cosine transform (DCT). This mathematical operation converts each frame/field of the video source from the spatial (2D) domain into the frequency domain (a.k.a. transform domain). A perceptual model based loosely on the human psychovisual system discards high-frequency information, i.e. sharp transitions in intensity, and color hue. In the transform domain, the process of reducing information is called quantization. In simpler terms, quantization is a method for optimally reducing a large number scale (with different occurrences of each number) into a smaller one, and the transform-domain is a convenient representation of the image because the high-frequency coefficients, which contribute less to the overall picture than other coefficients, are characteristically small-values with high compressibility. The quantized coefficients are then sequenced and losslessly packed into the output bitstream. Nearly all software implementations of JPEG permit user control over the compression ratio (as well as other optional parameters), allowing the user to trade off picture-quality for smaller file size. In embedded applications (such as miniDV, which uses a similar DCT-compression scheme), the parameters are pre-selected and fixed for the application.

          The compression method is usually lossy, meaning that some original image information is lost and cannot be restored, possibly affecting image quality. There is an optional lossless mode defined in the JPEG standard. However, this mode is not widely supported in products.

          There is also an interlaced progressive JPEG format, in which data is compressed in multiple passes of progressively higher detail. This is ideal for large images that will be displayed while downloading over a slow connection, allowing a reasonable preview after receiving only a portion of the data. However, support for progressive JPEGs is not universal. When progressive JPEGs are received by programs that do not support them (such as versions of Internet Explorer before Windows 7)[41] the software displays the image only after it has been completely downloaded.

          There are also many medical imaging, traffic and camera applications that create and process 12-bit JPEG images both grayscale and color. 12-bit JPEG format is included in an Extended part of the JPEG specification. The libjpeg codec supports 12-bit JPEG and there even exists a high-performance version.[42]

          Lossless editing[edit]

          Several alterations to a JPEG image can be performed losslessly (that is, without recompression and the associated quality loss) as long as the image size is a multiple of 1 MCU block (Minimum Coded Unit) (usually 16 pixels in both directions, for 4:2:0 chroma subsampling). Utilities that implement this include:

          • jpegtran and its GUI, Jpegcrop.
          • IrfanView using «JPG Lossless Crop (PlugIn)» and «JPG Lossless Rotation (PlugIn)», which require installing the JPG_TRANSFORM plugin.
          • FastStone Image Viewer using «Lossless Crop to File» and «JPEG Lossless Rotate».
          • XnViewMP using «JPEG lossless transformations».
          • ACDSee supports lossless rotation (but not lossless cropping) with its «Force lossless JPEG operations» option.

          Blocks can be rotated in 90-degree increments, flipped in the horizontal, vertical and diagonal axes and moved about in the image. Not all blocks from the original image need to be used in the modified one.

          The top and left edge of a JPEG image must lie on an 8 × 8 pixel block boundary, but the bottom and right edge need not do so. This limits the possible lossless crop operations, and also prevents flips and rotations of an image whose bottom or right edge does not lie on a block boundary for all channels (because the edge would end up on top or left, where – as aforementioned – a block boundary is obligatory).

          Rotations where the image is not a multiple of 8 or 16, which value depends upon the chroma subsampling, are not lossless. Rotating such an image causes the blocks to be recomputed which results in loss of quality.[43]

          When using lossless cropping, if the bottom or right side of the crop region is not on a block boundary, then the rest of the data from the partially used blocks will still be present in the cropped file and can be recovered. It is also possible to transform between baseline and progressive formats without any loss of quality, since the only difference is the order in which the coefficients are placed in the file.

          Furthermore, several JPEG images can be losslessly joined, as long as they were saved with the same quality and the edges coincide with block boundaries.

          JPEG files[edit]

          The file format known as «JPEG Interchange Format» (JIF) is specified in Annex B of the standard. However, this «pure» file format is rarely used, primarily because of the difficulty of programming encoders and decoders that fully implement all aspects of the standard and because of certain shortcomings of the standard:

          • Color space definition
          • Component sub-sampling registration
          • Pixel aspect ratio definition.

          Several additional standards have evolved to address these issues. The first of these, released in 1992, was the JPEG File Interchange Format (or JFIF), followed in recent years by Exchangeable image file format (Exif) and ICC color profiles. Both of these formats use the actual JIF byte layout, consisting of different markers, but in addition, employ one of the JIF standard’s extension points, namely the application markers: JFIF uses APP0, while Exif uses APP1. Within these segments of the file that were left for future use in the JIF standard and are not read by it, these standards add specific metadata.

          Thus, in some ways, JFIF is a cut-down version of the JIF standard in that it specifies certain constraints (such as not allowing all the different encoding modes), while in other ways, it is an extension of JIF due to the added metadata. The documentation for the original JFIF standard states:[44]

          JPEG File Interchange Format is a minimal file format which enables JPEG bitstreams to be exchanged between a wide variety of platforms and applications. This minimal format does not include any of the advanced features found in the TIFF JPEG specification or any application specific file format. Nor should it, for the only purpose of this simplified format is to allow the exchange of JPEG compressed images.

          Image files that employ JPEG compression are commonly called «JPEG files», and are stored in variants of the JIF image format. Most image capture devices (such as digital cameras) that output JPEG are actually creating files in the Exif format, the format that the camera industry has standardized on for metadata interchange. On the other hand, since the Exif standard does not allow color profiles, most image editing software stores JPEG in JFIF format, and also includes the APP1 segment from the Exif file to include the metadata in an almost-compliant way; the JFIF standard is interpreted somewhat flexibly.[45]

          Strictly speaking, the JFIF and Exif standards are incompatible, because each specifies that its marker segment (APP0 or APP1, respectively) appear first. In practice, most JPEG files contain a JFIF marker segment that precedes the Exif header. This allows older readers to correctly handle the older format JFIF segment, while newer readers also decode the following Exif segment, being less strict about requiring it to appear first.

          JPEG filename extensions[edit]

          The most common filename extensions for files employing JPEG compression are .jpg and .jpeg, though .jpe, .jfif and .jif are also used. It is also possible for JPEG data to be embedded in other file types – TIFF encoded files often embed a JPEG image as a thumbnail of the main image; and MP3 files can contain a JPEG of cover art in the ID3v2 tag.

          Color profile[edit]

          Many JPEG files embed an ICC color profile (color space). Commonly used color profiles include sRGB and Adobe RGB. Because these color spaces use a non-linear transformation, the dynamic range of an 8-bit JPEG file is about 11 stops; see gamma curve.

          If the image doesn’t specify color profile information (untagged), the color space is assumed to be sRGB for the purposes of display on webpages.[46][47]

          Syntax and structure[edit]

          A JPEG image consists of a sequence of segments, each beginning with a marker, each of which begins with a 0xFF byte, followed by a byte indicating what kind of marker it is. Some markers consist of just those two bytes; others are followed by two bytes (high then low), indicating the length of marker-specific payload data that follows. (The length includes the two bytes for the length, but not the two bytes for the marker.) Some markers are followed by entropy-coded data; the length of such a marker does not include the entropy-coded data. Note that consecutive 0xFF bytes are used as fill bytes for padding purposes, although this fill byte padding should only ever take place for markers immediately following entropy-coded scan data (see JPEG specification section B.1.1.2 and E.1.2 for details; specifically «In all cases where markers are appended after the compressed data, optional 0xFF fill bytes may precede the marker»).

          Within the entropy-coded data, after any 0xFF byte, a 0x00 byte is inserted by the encoder before the next byte, so that there does not appear to be a marker where none is intended, preventing framing errors. Decoders must skip this 0x00 byte. This technique, called byte stuffing (see JPEG specification section F.1.2.3), is only applied to the entropy-coded data, not to marker payload data. Note however that entropy-coded data has a few markers of its own; specifically the Reset markers (0xD0 through 0xD7), which are used to isolate independent chunks of entropy-coded data to allow parallel decoding, and encoders are free to insert these Reset markers at regular intervals (although not all encoders do this).

          Common JPEG markers[48]

          Short name Bytes Payload Name Comments
          SOI 0xFF, 0xD8 none Start Of Image
          SOF0 0xFF, 0xC0 variable size Start Of Frame (baseline DCT) Indicates that this is a baseline DCT-based JPEG, and specifies the width, height, number of components, and component subsampling (e.g., 4:2:0).
          SOF2 0xFF, 0xC2 variable size Start Of Frame (progressive DCT) Indicates that this is a progressive DCT-based JPEG, and specifies the width, height, number of components, and component subsampling (e.g., 4:2:0).
          DHT 0xFF, 0xC4 variable size Define Huffman Table(s) Specifies one or more Huffman tables.
          DQT 0xFF, 0xDB variable size Define Quantization Table(s) Specifies one or more quantization tables.
          DRI 0xFF, 0xDD 4 bytes Define Restart Interval Specifies the interval between RSTn markers, in Minimum Coded Units (MCUs). This marker is followed by two bytes indicating the fixed size so it can be treated like any other variable size segment.
          SOS 0xFF, 0xDA variable size Start Of Scan Begins a top-to-bottom scan of the image. In baseline DCT JPEG images, there is generally a single scan. Progressive DCT JPEG images usually contain multiple scans. This marker specifies which slice of data it will contain, and is immediately followed by entropy-coded data.
          RSTn 0xFF, 0xDn (n=0..7) none Restart Inserted every r macroblocks, where r is the restart interval set by a DRI marker. Not used if there was no DRI marker. The low three bits of the marker code cycle in value from 0 to 7.
          APPn 0xFF, 0xEn variable size Application-specific For example, an Exif JPEG file uses an APP1 marker to store metadata, laid out in a structure based closely on TIFF.
          COM 0xFF, 0xFE variable size Comment Contains a text comment.
          EOI 0xFF, 0xD9 none End Of Image

          There are other Start Of Frame markers that introduce other kinds of JPEG encodings.

          Since several vendors might use the same APPn marker type, application-specific markers often begin with a standard or vendor name (e.g., «Exif» or «Adobe») or some other identifying string.

          At a restart marker, block-to-block predictor variables are reset, and the bitstream is synchronized to a byte boundary. Restart markers provide means for recovery after bitstream error, such as transmission over an unreliable network or file corruption. Since the runs of macroblocks between restart markers may be independently decoded, these runs may be decoded in parallel.

          JPEG codec example[edit]

          Although a JPEG file can be encoded in various ways, most commonly it is done with JFIF encoding. The encoding process consists of several steps:

          1. The representation of the colors in the image is converted from RGB to Y′CBCR, consisting of one luma component (Y’), representing brightness, and two chroma components, (CB and CR), representing color. This step is sometimes skipped.
          2. The resolution of the chroma data is reduced, usually by a factor of 2 or 3. This reflects the fact that the eye is less sensitive to fine color details than to fine brightness details.
          3. The image is split into blocks of 8×8 pixels, and for each block, each of the Y, CB, and CR data undergoes the discrete cosine transform (DCT). A DCT is similar to a Fourier transform in the sense that it produces a kind of spatial frequency spectrum.
          4. The amplitudes of the frequency components are quantized. Human vision is much more sensitive to small variations in color or brightness over large areas than to the strength of high-frequency brightness variations. Therefore, the magnitudes of the high-frequency components are stored with a lower accuracy than the low-frequency components. The quality setting of the encoder (for example 50 or 95 on a scale of 0–100 in the Independent JPEG Group’s library[49]) affects to what extent the resolution of each frequency component is reduced. If an excessively low quality setting is used, the high-frequency components are discarded altogether.
          5. The resulting data for all 8×8 blocks is further compressed with a lossless algorithm, a variant of Huffman encoding.

          The decoding process reverses these steps, except the quantization because it is irreversible. In the remainder of this section, the encoding and decoding processes are described in more detail.

          Encoding[edit]

          Many of the options in the JPEG standard are not commonly used, and as mentioned above, most image software uses the simpler JFIF format when creating a JPEG file, which among other things specifies the encoding method. Here is a brief description of one of the more common methods of encoding when applied to an input that has 24 bits per pixel (eight each of red, green, and blue). This particular option is a lossy data compression method.

          Color space transformation[edit]

          First, the image should be converted from RGB (by default sRGB,[46][47] but other color spaces are possible) into a different color space called Y′CBCR (or, informally, YCbCr). It has three components Y’, CB and CR: the Y’ component represents the brightness of a pixel, and the CB and CR components represent the chrominance (split into blue and red components). This is basically the same color space as used by digital color television as well as digital video including video DVDs. The Y′CBCR color space conversion allows greater compression without a significant effect on perceptual image quality (or greater perceptual image quality for the same compression). The compression is more efficient because the brightness information, which is more important to the eventual perceptual quality of the image, is confined to a single channel. This more closely corresponds to the perception of color in the human visual system. The color transformation also improves compression by statistical decorrelation.

          A particular conversion to Y′CBCR is specified in the JFIF standard, and should be performed for the resulting JPEG file to have maximum compatibility. However, some JPEG implementations in «highest quality» mode do not apply this step and instead keep the color information in the RGB color model,[50] where the image is stored in separate channels for red, green and blue brightness components. This results in less efficient compression, and would not likely be used when file size is especially important.

          Downsampling[edit]

          Due to the densities of color- and brightness-sensitive receptors in the human eye, humans can see considerably more fine detail in the brightness of an image (the Y’ component) than in the hue and color saturation of an image (the Cb and Cr components). Using this knowledge, encoders can be designed to compress images more efficiently.

          The transformation into the Y′CBCR color model enables the next usual step, which is to reduce the spatial resolution of the Cb and Cr components (called «downsampling» or «chroma subsampling»). The ratios at which the downsampling is ordinarily done for JPEG images are 4:4:4 (no downsampling), 4:2:2 (reduction by a factor of 2 in the horizontal direction), or (most commonly) 4:2:0 (reduction by a factor of 2 in both the horizontal and vertical directions). For the rest of the compression process, Y’, Cb and Cr are processed separately and in a very similar manner.

          Block splitting[edit]

          After subsampling, each channel must be split into 8×8 blocks. Depending on chroma subsampling, this yields Minimum Coded Unit (MCU) blocks of size 8×8 (4:4:4 – no subsampling), 16×8 (4:2:2), or most commonly 16×16 (4:2:0). In video compression MCUs are called macroblocks.

          If the data for a channel does not represent an integer number of blocks then the encoder must fill the remaining area of the incomplete blocks with some form of dummy data. Filling the edges with a fixed color (for example, black) can create ringing artifacts along the visible part of the border;
          repeating the edge pixels is a common technique that reduces (but does not necessarily eliminate) such artifacts, and more sophisticated border filling techniques can also be applied.

          Discrete cosine transform[edit]

          The 8×8 sub-image shown in 8-bit grayscale

          Next, each 8×8 block of each component (Y, Cb, Cr) is converted to a frequency-domain representation, using a normalized, two-dimensional type-II discrete cosine transform (DCT), see Citation 1 in discrete cosine transform. The DCT is sometimes referred to as «type-II DCT» in the context of a family of transforms as in discrete cosine transform, and the corresponding inverse (IDCT) is denoted as «type-III DCT».

          As an example, one such 8×8 8-bit subimage might be:

          left[{begin{array}{rrrrrrrr}52&55&61&66&70&61&64&73\63&59&55&90&109&85&69&72\62&59&68&113&144&104&66&73\63&58&71&122&154&106&70&69\67&61&68&104&126&88&68&70\79&65&60&70&77&68&58&75\85&71&64&59&55&61&65&83\87&79&69&68&65&76&78&94end{array}}right].

          Before computing the DCT of the 8×8 block, its values are shifted from a positive range to one centered on zero. For an 8-bit image, each entry in the original block falls in the range [0,255]. The midpoint of the range (in this case, the value 128) is subtracted from each entry to produce a data range that is centered on zero, so that the modified range is [-128,127]. This step reduces the dynamic range requirements in the DCT processing stage that follows.

          This step results in the following values:

          g={begin{array}{c}x\longrightarrow \left[{begin{array}{rrrrrrrr}-76&-73&-67&-62&-58&-67&-64&-55\-65&-69&-73&-38&-19&-43&-59&-56\-66&-69&-60&-15&16&-24&-62&-55\-65&-70&-57&-6&26&-22&-58&-59\-61&-67&-60&-24&-2&-40&-60&-58\-49&-63&-68&-58&-51&-60&-70&-53\-43&-57&-64&-69&-73&-67&-63&-45\-41&-49&-59&-60&-63&-52&-50&-34end{array}}right]end{array}}{Bigg downarrow }y.

          The DCT transforms an 8×8 block of input values to a linear combination of these 64 patterns. The patterns are referred to as the two-dimensional DCT basis functions, and the output values are referred to as transform coefficients. The horizontal index is u and the vertical index is v.

          The next step is to take the two-dimensional DCT, which is given by:

           G_{u,v}={frac {1}{4}}alpha (u)alpha (v)sum _{x=0}^{7}sum _{y=0}^{7}g_{x,y}cos left[{frac {(2x+1)upi }{16}}right]cos left[{frac {(2y+1)vpi }{16}}right]

          where

          If we perform this transformation on our matrix above, we get the following (rounded to the nearest two digits beyond the decimal point):

          G={begin{array}{c}u\longrightarrow \left[{begin{array}{rrrrrrrr}-415.38&-30.19&-61.20&27.24&56.12&-20.10&-2.39&0.46\4.47&-21.86&-60.76&10.25&13.15&-7.09&-8.54&4.88\-46.83&7.37&77.13&-24.56&-28.91&9.93&5.42&-5.65\-48.53&12.07&34.10&-14.76&-10.24&6.30&1.83&1.95\12.12&-6.55&-13.20&-3.95&-1.87&1.75&-2.79&3.14\-7.73&2.91&2.38&-5.94&-2.38&0.94&4.30&1.85\-1.03&0.18&0.42&-2.42&-0.88&-3.02&4.12&-0.66\-0.17&0.14&-1.07&-4.19&-1.17&-0.10&0.50&1.68end{array}}right]end{array}}{Bigg downarrow }v.

          Note the top-left corner entry with the rather large magnitude. This is the DC coefficient (also called the constant component), which defines the basic hue for the entire block. The remaining 63 coefficients are the AC coefficients (also called the alternating components).[51] The advantage of the DCT is its tendency to aggregate most of the signal in one corner of the result, as may be seen above. The quantization step to follow accentuates this effect while simultaneously reducing the overall size of the DCT coefficients, resulting in a signal that is easy to compress efficiently in the entropy stage.

          The DCT temporarily increases the bit-depth of the data, since the DCT coefficients of an 8-bit/component image take up to 11 or more bits (depending on fidelity of the DCT calculation) to store. This may force the codec to temporarily use 16-bit numbers to hold these coefficients, doubling the size of the image representation at this point; these values are typically reduced back to 8-bit values by the quantization step. The temporary increase in size at this stage is not a performance concern for most JPEG implementations, since typically only a very small part of the image is stored in full DCT form at any given time during the image encoding or decoding process.

          Quantization[edit]

          The human eye is good at seeing small differences in brightness over a relatively large area, but not so good at distinguishing the exact strength of a high frequency brightness variation. This allows one to greatly reduce the amount of information in the high frequency components. This is done by simply dividing each component in the frequency domain by a constant for that component, and then rounding to the nearest integer. This rounding operation is the only lossy operation in the whole process (other than chroma subsampling) if the DCT computation is performed with sufficiently high precision. As a result of this, it is typically the case that many of the higher frequency components are rounded to zero, and many of the rest become small positive or negative numbers, which take many fewer bits to represent.

          The elements in the quantization matrix control the compression ratio, with larger values producing greater compression. A typical quantization matrix (for a quality of 50% as specified in the original JPEG Standard), is as follows:

          Q={begin{bmatrix}16&11&10&16&24&40&51&61\12&12&14&19&26&58&60&55\14&13&16&24&40&57&69&56\14&17&22&29&51&87&80&62\18&22&37&56&68&109&103&77\24&35&55&64&81&104&113&92\49&64&78&87&103&121&120&101\72&92&95&98&112&100&103&99end{bmatrix}}.

          The quantized DCT coefficients are computed with

          B_{j,k}=mathrm {round} left({frac {G_{j,k}}{Q_{j,k}}}right){mbox{ for }}j=0,1,2,ldots ,7;k=0,1,2,ldots ,7

          where G is the unquantized DCT coefficients; Q is the quantization matrix above; and B is the quantized DCT coefficients.

          Using this quantization matrix with the DCT coefficient matrix from above results in:

          Left: a final image is built up from a series of basis functions. Right: each of the DCT basis functions that comprise the image, and the corresponding weighting coefficient. Middle: the basis function, after multiplication by the coefficient: this component is added to the final image. For clarity, the 8×8 macroblock in this example is magnified by 10x using bilinear interpolation.

          B=left[{begin{array}{rrrrrrrr}-26&-3&-6&2&2&-1&0&0\0&-2&-4&1&1&0&0&0\-3&1&5&-1&-1&0&0&0\-3&1&2&-1&0&0&0&0\1&0&0&0&0&0&0&0\0&0&0&0&0&0&0&0\0&0&0&0&0&0&0&0\0&0&0&0&0&0&0&0end{array}}right].

          For example, using −415 (the DC coefficient) and rounding to the nearest integer

          mathrm {round} left({frac {-415.37}{16}}right)=mathrm {round} left(-25.96right)=-26.

          Notice that most of the higher-frequency elements of the sub-block (i.e., those with an x or y spatial frequency greater than 4) are quantized into zero values.

          Entropy coding[edit]

          Zigzag ordering of JPEG image components

          Entropy coding is a special form of lossless data compression. It involves arranging the image components in a «zigzag» order employing run-length encoding (RLE) algorithm that groups similar frequencies together, inserting length coding zeros, and then using Huffman coding on what is left.

          The JPEG standard also allows, but does not require, decoders to support the use of arithmetic coding, which is mathematically superior to Huffman coding. However, this feature has rarely been used, as it was historically covered by patents requiring royalty-bearing licenses, and because it is slower to encode and decode compared to Huffman coding. Arithmetic coding typically makes files about 5–7% smaller.

          The previous quantized DC coefficient is used to predict the current quantized DC coefficient. The difference between the two is encoded rather than the actual value. The encoding of the 63 quantized AC coefficients does not use such prediction differencing.

          The zigzag sequence for the above quantized coefficients are shown below. (The format shown is just for ease of understanding/viewing.)

          −26
          −3 0
          −3 −2 −6
          2 −4 1 −3
          1 1 5 1 2
          −1 1 −1 2 0 0
          0 0 0 −1 −1 0 0
          0 0 0 0 0 0 0 0
          0 0 0 0 0 0 0
          0 0 0 0 0 0
          0 0 0 0 0
          0 0 0 0
          0 0 0
          0 0
          0

          If the i-th block is represented by B_{i} and positions within each block are represented by (p,q) where p=0,1,...,7 and q=0,1,...,7, then any coefficient in the DCT image can be represented as B_{i}(p,q). Thus, in the above scheme, the order of encoding pixels (for the i-th block) is B_{i}(0,0), B_{i}(0,1), B_{i}(1,0), B_{i}(2,0), B_{i}(1,1), B_{i}(0,2), B_{i}(0,3), B_{i}(1,2) and so on.

          Baseline sequential JPEG encoding and decoding processes

          This encoding mode is called baseline sequential encoding. Baseline JPEG also supports progressive encoding. While sequential encoding encodes coefficients of a single block at a time (in a zigzag manner), progressive encoding encodes similar-positioned batch of coefficients of all blocks in one go (called a scan), followed by the next batch of coefficients of all blocks, and so on. For example, if the image is divided into N 8×8 blocks {displaystyle B_{0},B_{1},B_{2},...,B_{n-1}}, then a 3-scan progressive encoding encodes DC component, B_{i}(0,0) for all blocks, i.e., for all i=0,1,2,...,N-1, in first scan. This is followed by the second scan which encoding a few more components (assuming four more components, they are B_{i}(0,1) to B_{i}(1,1), still in a zigzag manner) coefficients of all blocks (so the sequence is: {displaystyle B_{0}(0,1),B_{0}(1,0),B_{0}(2,0),B_{0}(1,1),B_{1}(0,1),B_{1}(1,0),...,B_{N}(2,0),B_{N}(1,1)}), followed by all the remained coefficients of all blocks in the last scan.

          Once all similar-positioned coefficients have been encoded, the next position to be encoded is the one occurring next in the zigzag traversal as indicated in the figure above. It has been found that baseline progressive JPEG encoding usually gives better compression as compared to baseline sequential JPEG due to the ability to use different Huffman tables (see below) tailored for different frequencies on each «scan» or «pass» (which includes similar-positioned coefficients), though the difference is not too large.

          In the rest of the article, it is assumed that the coefficient pattern generated is due to sequential mode.

          In order to encode the above generated coefficient pattern, JPEG uses Huffman encoding. The JPEG standard provides general-purpose Huffman tables; encoders may also choose to generate Huffman tables optimized for the actual frequency distributions in images being encoded.

          The process of encoding the zig-zag quantized data begins with a run-length encoding explained below, where:

          • x is the non-zero, quantized AC coefficient.
          • RUNLENGTH is the number of zeroes that came before this non-zero AC coefficient.
          • SIZE is the number of bits required to represent x.
          • AMPLITUDE is the bit-representation of x.

          The run-length encoding works by examining each non-zero AC coefficient x and determining how many zeroes came before the previous AC coefficient. With this information, two symbols are created:

          Symbol 1 Symbol 2
          (RUNLENGTH, SIZE) (AMPLITUDE)

          Both RUNLENGTH and SIZE rest on the same byte, meaning that each only contains four bits of information. The higher bits deal with the number of zeroes, while the lower bits denote the number of bits necessary to encode the value of x.

          This has the immediate implication of Symbol 1 being only able store information regarding the first 15 zeroes preceding the non-zero AC coefficient. However, JPEG defines two special Huffman code words. One is for ending the sequence prematurely when the remaining coefficients are zero (called «End-of-Block» or «EOB»), and another when the run of zeroes goes beyond 15 before reaching a non-zero AC coefficient. In such a case where 16 zeroes are encountered before a given non-zero AC coefficient, Symbol 1 is encoded «specially» as: (15, 0)(0).

          The overall process continues until «EOB» – denoted by (0, 0) – is reached.

          With this in mind, the sequence from earlier becomes:

          (0, 2)(-3);(1, 2)(-3);(0, 1)(-2);(0, 2)(-6);(0, 1)(2);(0, 1)(-4);(0, 1)(1);(0, 2)(-3);(0, 1)(1);(0, 1)(1);
          (0, 2)(5);(0, 1)(1);(0, 1)(2);(0, 1)(-1);(0, 1)(1);(0, 1)(-1);(0, 1)(2);(5, 1)(-1);(0, 1)(-1);(0, 0);

          (The first value in the matrix, −26, is the DC coefficient; it is not encoded the same way. See above.)

          From here, frequency calculations are made based on occurrences of the coefficients. In our example block, most of the quantized coefficients are small numbers that are not preceded immediately by a zero coefficient. These more-frequent cases will be represented by shorter code words.

          Compression ratio and artifacts[edit]

          This image shows the pixels that are different between a non-compressed image and the same image JPEG compressed with a quality setting of 50. Darker means a larger difference. Note especially the changes occurring near sharp edges and having a block-like shape.

          The compressed 8×8 squares are visible in the scaled-up picture, together with other visual artifacts of the lossy compression.

          The resulting compression ratio can be varied according to need by being more or less aggressive in the divisors used in the quantization phase. Ten to one compression usually results in an image that cannot be distinguished by eye from the original. A compression ratio of 100:1 is usually possible, but will look distinctly artifacted compared to the original. The appropriate level of compression depends on the use to which the image will be put.

          External image
          image icon Illustration of edge busyness[52]

          Those who use the World Wide Web may be familiar with the irregularities known as compression artifacts that appear in JPEG images, which may take the form of noise around contrasting edges (especially curves and corners), or «blocky» images. These are due to the quantization step of the JPEG algorithm. They are especially noticeable around sharp corners between contrasting colors (text is a good example, as it contains many such corners). The analogous artifacts in MPEG video are referred to as mosquito noise, as the resulting «edge busyness» and spurious dots, which change over time, resemble mosquitoes swarming around the object.[52][53]

          These artifacts can be reduced by choosing a lower level of compression; they may be completely avoided by saving an image using a lossless file format, though this will result in a larger file size. The images created with ray-tracing programs have noticeable blocky shapes on the terrain. Certain low-intensity compression artifacts might be acceptable when simply viewing the images, but can be emphasized if the image is subsequently processed, usually resulting in unacceptable quality. Consider the example below, demonstrating the effect of lossy compression on an edge detection processing step.

          Image Lossless compression Lossy compression
          Original Lossless-circle.png Lossy-circle.jpg
          Processed by
          Canny edge detector
          Lossless-circle-canny.png Lossy-circle-canny.png

          Some programs allow the user to vary the amount by which individual blocks are compressed. Stronger compression is applied to areas of the image that show fewer artifacts. This way it is possible to manually reduce JPEG file size with less loss of quality.

          Since the quantization stage always results in a loss of information, JPEG standard is always a lossy compression codec. (Information is lost both in quantizing and rounding of the floating-point numbers.) Even if the quantization matrix is a matrix of ones, information will still be lost in the rounding step.

          Decoding[edit]

          Decoding to display the image consists of doing all the above in reverse.

          Taking the DCT coefficient matrix (after adding the difference of the DC coefficient back in)

          left[{begin{array}{rrrrrrrr}-26&-3&-6&2&2&-1&0&0\0&-2&-4&1&1&0&0&0\-3&1&5&-1&-1&0&0&0\-3&1&2&-1&0&0&0&0\1&0&0&0&0&0&0&0\0&0&0&0&0&0&0&0\0&0&0&0&0&0&0&0\0&0&0&0&0&0&0&0end{array}}right]

          and taking the entry-for-entry product with the quantization matrix from above results in

          left[{begin{array}{rrrrrrrr}-416&-33&-60&32&48&-40&0&0\0&-24&-56&19&26&0&0&0\-42&13&80&-24&-40&0&0&0\-42&17&44&-29&0&0&0&0\18&0&0&0&0&0&0&0\0&0&0&0&0&0&0&0\0&0&0&0&0&0&0&0\0&0&0&0&0&0&0&0end{array}}right]

          which closely resembles the original DCT coefficient matrix for the top-left portion.

          The next step is to take the two-dimensional inverse DCT (a 2D type-III DCT), which is given by:

          f_{x,y}={frac {1}{4}}sum _{u=0}^{7}sum _{v=0}^{7}alpha (u)alpha (v)F_{u,v}cos left[{frac {(2x+1)upi }{16}}right]cos left[{frac {(2y+1)vpi }{16}}right]

          where

          Rounding the output to integer values (since the original had integer values) results in an image with values (still shifted down by 128)

          Slight differences are noticeable between the original (top) and decompressed image (bottom), which is most readily seen in the bottom-left corner.

          left[{begin{array}{rrrrrrrr}-66&-63&-71&-68&-56&-65&-68&-46\-71&-73&-72&-46&-20&-41&-66&-57\-70&-78&-68&-17&20&-14&-61&-63\-63&-73&-62&-8&27&-14&-60&-58\-58&-65&-61&-27&-6&-40&-68&-50\-57&-57&-64&-58&-48&-66&-72&-47\-53&-46&-61&-74&-65&-63&-62&-45\-47&-34&-53&-74&-60&-47&-47&-41end{array}}right]

          and adding 128 to each entry

          left[{begin{array}{rrrrrrrr}62&65&57&60&72&63&60&82\57&55&56&82&108&87&62&71\58&50&60&111&148&114&67&65\65&55&66&120&155&114&68&70\70&63&67&101&122&88&60&78\71&71&64&70&80&62&56&81\75&82&67&54&63&65&66&83\81&94&75&54&68&81&81&87end{array}}right].

          This is the decompressed subimage. In general, the decompression process may produce values outside the original input range of [0,255]. If this occurs, the decoder needs to clip the output values so as to keep them within that range to prevent overflow when storing the decompressed image with the original bit depth.

          The decompressed subimage can be compared to the original subimage (also see images to the right) by taking the difference (original − uncompressed) results in the following error values:

          left[{begin{array}{rrrrrrrr}-10&-10&4&6&-2&-2&4&-9\6&4&-1&8&1&-2&7&1\4&9&8&2&-4&-10&-1&8\-2&3&5&2&-1&-8&2&-1\-3&-2&1&3&4&0&8&-8\8&-6&-4&-0&-3&6&2&-6\10&-11&-3&5&-8&-4&-1&-0\6&-15&-6&14&-3&-5&-3&7end{array}}right]

          with an average absolute error of about 5 values per pixels (i.e., {displaystyle {frac {1}{64}}sum _{x=0}^{7}sum _{y=0}^{7}|e(x,y)|=4.8750}).

          The error is most noticeable in the bottom-left corner where the bottom-left pixel becomes darker than the pixel to its immediate right.

          Required precision[edit]

          The required implementation precision of a JPEG codec is implicitly defined through the requirements formulated for compliance to the JPEG standard. These requirements are specified in ITU.T Recommendation T.83 | ISO/IEC 10918-2. Unlike MPEG standards and many later JPEG standards, the above document defines both required implementation precisions for the encoding and the decoding process of a JPEG codec by means of a maximal tolerable error of the forwards and inverse DCT in the DCT domain as determined by reference test streams. For example, the output of a decoder implementation must not exceed an error of one quantization unit in the DCT domain when applied to the reference testing codestreams provided as part of the above standard. While unusual, and unlike many other and more modern standards, ITU.T T.83 | ISO/IEC 10918-2 does not formulate error bounds in the image domain.

          Effects of JPEG compression[edit]

          JPEG compression artifacts blend well into photographs with detailed non-uniform textures, allowing higher compression ratios. Notice how a higher compression ratio first affects the high-frequency textures in the upper-left corner of the image, and how the contrasting lines become more fuzzy. The very high compression ratio severely affects the quality of the image, although the overall colors and image form are still recognizable. However, the precision of colors suffer less (for a human eye) than the precision of contours (based on luminance). This justifies the fact that images should be first transformed in a color model separating the luminance from the chromatic information, before subsampling the chromatic planes (which may also use lower quality quantization) in order to preserve the precision of the luminance plane with more information bits.

          Sample photographs[edit]

          Visual impact of a jpeg compression on Photoshop on a picture of 4480×4480 pixels

          For information, the uncompressed 24-bit RGB bitmap image below (73,242 pixels) would require 219,726 bytes (excluding all other information headers). The filesizes indicated below include the internal JPEG information headers and some metadata. For highest quality images (Q=100), about 8.25 bits per color pixel is required. On grayscale images, a minimum of 6.5 bits per pixel is enough (a comparable Q=100 quality color information requires about 25% more encoded bits). The highest quality image below (Q=100) is encoded at nine bits per color pixel, the medium quality image (Q=25) uses one bit per color pixel. For most applications, the quality factor should not go below 0.75 bit per pixel (Q=12.5), as demonstrated by the low quality image. The image at lowest quality uses only 0.13 bit per pixel, and displays very poor color. This is useful when the image will be displayed in a significantly scaled-down size. A method for creating better quantization matrices for a given image quality using PSNR instead of the Q factor is described in Minguillón & Pujol (2001).[54]

          Note: The above images are not IEEE / CCIR / EBU test images, and the encoder settings are not specified or available.

          Image Quality Size (bytes) Compression ratio Comment
          JPEG example JPG RIP 100.jpg Highest quality (Q = 100) 81,447 2.7:1 Extremely minor artifacts
          JPEG example JPG RIP 050.jpg High quality (Q = 50) 14,679 15:1 Initial signs of subimage artifacts
          JPEG example JPG RIP 025.jpg Medium quality (Q = 25) 9,407 23:1 Stronger artifacts; loss of high frequency information
          JPEG example JPG RIP 010.jpg Low quality (Q = 10) 4,787 46:1 Severe high frequency loss leads to obvious artifacts on subimage boundaries («macroblocking»)
          JPEG example JPG RIP 001.jpg Lowest quality (Q = 1) 1,523 144:1 Extreme loss of color and detail; the leaves are nearly unrecognizable.

          The medium quality photo uses only 4.3% of the storage space required for the uncompressed image, but has little noticeable loss of detail or visible artifacts. However, once a certain threshold of compression is passed, compressed images show increasingly visible defects. See the article on rate–distortion theory for a mathematical explanation of this threshold effect. A particular limitation of JPEG in this regard is its non-overlapped 8×8 block transform structure. More modern designs such as JPEG 2000 and JPEG XR exhibit a more graceful degradation of quality as the bit usage decreases – by using transforms with a larger spatial extent for the lower frequency coefficients and by using overlapping transform basis functions.

          Lossless further compression[edit]

          From 2004 to 2008, new research emerged on ways to further compress the data contained in JPEG images without modifying the represented image.[55][56][57][58] This has applications in scenarios where the original image is only available in JPEG format, and its size needs to be reduced for archiving or transmission. Standard general-purpose compression tools cannot significantly compress JPEG files.

          Typically, such schemes take advantage of improvements to the naive scheme for coding DCT coefficients, which fails to take into account:

          • Correlations between magnitudes of adjacent coefficients in the same block;
          • Correlations between magnitudes of the same coefficient in adjacent blocks;
          • Correlations between magnitudes of the same coefficient/block in different channels;
          • The DC coefficients when taken together resemble a downscale version of the original image multiplied by a scaling factor. Well-known schemes for lossless coding of continuous-tone images can be applied, achieving somewhat better compression than the Huffman coded DPCM used in JPEG.

          Some standard but rarely used options already exist in JPEG to improve the efficiency of coding DCT coefficients: the arithmetic coding option, and the progressive coding option (which produces lower bitrates because values for each coefficient are coded independently, and each coefficient has a significantly different distribution). Modern methods have improved on these techniques by reordering coefficients to group coefficients of larger magnitude together;[55] using adjacent coefficients and blocks to predict new coefficient values;[57] dividing blocks or coefficients up among a small number of independently coded models based on their statistics and adjacent values;[56][57] and most recently, by decoding blocks, predicting subsequent blocks in the spatial domain, and then encoding these to generate predictions for DCT coefficients.[58]

          Typically, such methods can compress existing JPEG files between 15 and 25 percent, and for JPEGs compressed at low-quality settings, can produce improvements of up to 65%.[57][58]

          A freely available tool called packJPG is based on the 2007 paper «Improved Redundancy Reduction for JPEG Files.» As of version 2.5k of 2016, it reports a typical 20% reduction by transcoding.[59] JPEG XL (ISO/IEC 18181) of 2018 reports a similar reduction in its transcoding.

          Derived formats for stereoscopic 3D[edit]

          JPEG Stereoscopic[edit]

          An example of a stereoscopic .JPS file

          JPS is a stereoscopic JPEG image used for creating 3D effects from 2D images. It contains two static images, one for the left eye and one for the right eye; encoded as two side-by-side images in a single JPG file.
          JPEG Stereoscopic (JPS, extension .jps) is a JPEG-based format for stereoscopic images.[60][61] It has a range of configurations stored in the JPEG APP3 marker field, but usually contains one image of double width, representing two images of identical size in cross-eyed (i.e. left frame on the right half of the image and vice versa) side-by-side arrangement. This file format can be viewed as a JPEG without any special software, or can be processed for rendering in other modes.

          JPEG Multi-Picture Format[edit]

          JPEG Multi-Picture Format (MPO, extension .mpo) is a JPEG-based format for storing multiple images in a single file. It contains two or more JPEG files concatenated together.[62][63] It also defines a JPEG APP2 marker segment for image description. Various devices use it to store 3D images, such as Fujifilm FinePix Real 3D W1, HTC Evo 3D, JVC GY-HMZ1U AVCHD/MVC extension camcorder, Nintendo 3DS, Panasonic Lumix DMC-TZ20, DMC-TZ30, DMC-TZ60, DMC-TS4 (FT4), and Sony DSC-HX7V. Other devices use it to store «preview images» that can be displayed on a TV.

          In the last few years, due to the growing use of stereoscopic images, much effort has been spent by the scientific community to develop algorithms for stereoscopic image compression.[64][65]

          Implementations[edit]

          A very important implementation of a JPEG codec is the free programming library libjpeg of the Independent JPEG Group. It was first published in 1991 and was key for the success of the standard. This library was used in countless applications. [66] The development went quiet in 1998; when libjpeg resurfaced with the 2009 version 7, it broke ABI compatibility with previous versions. Version 8 of 2010 introduced non-standard extensions, a decision critized by the original IJG leader Tom Lane.[67]

          libjpeg-turbo, forked from the 1998 libjpeg 6b, improves on libjpeg with SIMD optimizations. Originally seen as a maintained fork of libjpeg, it has become more popular after the incompatible changes of 2009.[68][69] In 2019, it became the ITU|ISO/IEC reference implementation as ISO/IEC 10918-7 and ITU-T T.873.[70]

          ISO/IEC Joint Photography Experts Group maintains the other reference software implementation under the JPEG XT heading. It can encode both base JPEG (ISO/IEC 10918-1 and 18477–1) and JPEG XT extensions (ISO/IEC 18477 Parts 2 and 6–9), as well as JPEG-LS (ISO/IEC 14495).[71]

          There is persistent interest in encoding JPEG in unconventional ways that maximize image quality for a given file size. In 2014, Mozilla created mozjpeg from libjpeg-turbo, a slower but higher-quality encoder intended for web images.[72] In 2016, «JPEG on steroids» was introduced as an option for the ISO JPEG XT reference implementation.[73] In March 2017, Google released the open source project Guetzli, which trades off a much longer encoding time for smaller file size (similar to what Zopfli does for PNG and other lossless data formats).[74]

          JPEG XT[edit]

          JPEG XT (ISO/IEC 18477) was published in June 2015; it extends base JPEG format with support for higher integer bit depths (up to 16 bit), high dynamic range imaging and floating-point coding, lossless coding, and alpha channel coding. Extensions are backward compatible with the base JPEG/JFIF file format and 8-bit lossy compressed image. JPEG XT uses an extensible file format based on JFIF. Extension layers are used to modify the JPEG 8-bit base layer and restore the high-resolution image. Existing software is forward compatible and can read the JPEG XT binary stream, though it would only decode the base 8-bit layer.[75]

          JPEG XL[edit]

          JPEG XL (ISO/IEC 18181) was published in 2021–2022. It replaces the JPEG format with a new DCT-based royalty-free format and allows efficient transcoding as a storage option for traditional JPEG images.[76] The new format is designed to exceed the still image compression performance shown by HEVC HM, Daala and WebP. It supports billion-by-billion pixel images, up to 32-bit-per-component high dynamic range with the appropriate transfer functions (PQ and HLG), patch encoding of synthetic images such as bitmap fonts and gradients, animated images, alpha channel coding, and a choice of RGB/YCbCr/ICtCp color encoding.[77][78][79][80]

          See also[edit]

          • Better Portable Graphics, a format based on intra-frame encoding of the HEVC
          • C-Cube, an early implementer of JPEG in chip form
          • Comparison of graphics file formats
          • Deblocking filter (video), the similar deblocking methods could be applied to JPEG
          • Design rule for Camera File system (DCF)
          • FELICS, a lossless image codec
          • File extensions
          • Graphics editing program
          • High Efficiency Image File Format, image container format for HEVC and other image coding formats
          • Lenna (test image), the traditional standard image used to test image processing algorithms
          • Motion JPEG
          • WebP

          References[edit]

          1. ^ a b c d e «T.81 – DIGITAL COMPRESSION AND CODING OF CONTINUOUS-TONE STILL IMAGES – REQUIREMENTS AND GUIDELINES» (PDF). CCITT. September 1992. Retrieved 12 July 2019.
          2. ^ «Definition of «JPEG»«. Collins English Dictionary. Retrieved 2013-05-23.
          3. ^ Haines, Richard F.; Chuang, Sherry L. (1 July 1992). The effects of video compression on acceptability of images for monitoring life sciences experiments (Technical report). NASA. NASA-TP-3239, A-92040, NAS 1.60:3239. Retrieved 2016-03-13. The JPEG still-image-compression levels, even with the large range of 5:1 to 120:1 in this study, yielded equally high levels of acceptability
          4. ^ a b Hudson, Graham; Léger, Alain; Niss, Birger; Sebestyén, István; Vaaben, Jørgen (31 August 2018). «JPEG-1 standard 25 years: past, present, and future reasons for a success». Journal of Electronic Imaging. 27 (4): 1. doi:10.1117/1.JEI.27.4.040901. S2CID 52164892.
          5. ^ «The JPEG Image Format Explained». BT.com. BT Group. 31 May 2018. Archived from the original on 5 August 2019. Retrieved 5 August 2019.
          6. ^ Baraniuk, Chris (15 October 2015). «Copy Protections Could Come to JPEGs». BBC News. BBC. Retrieved 13 September 2019.
          7. ^ «JPEG: 25 Jahre und kein bisschen alt». Heise online (in German). October 2016. Retrieved 5 September 2019.
          8. ^ «What Is a JPEG? The Invisible Object You See Every Day». The Atlantic. 24 September 2013. Retrieved 13 September 2019.
          9. ^ «HTTP Archive — Interesting Stats». httparchive.org. Retrieved 2016-04-06.
          10. ^ «MIME Type Detection in Internet Explorer». Microsoft. Retrieved 2 November 2022.
          11. ^ «JPEG File Interchange Format» (PDF). 3 September 2014. Archived from the original on 3 September 2014. Retrieved 16 October 2017.{{cite web}}: CS1 maint: bot: original URL status unknown (link)
          12. ^ «Why JPEG 2000 Never Took Off». American National Standards Institute. 10 July 2018. Retrieved 13 September 2019.
          13. ^ a b c d Lemos, Robert (23 July 2002). «Finding patent truth in JPEG claim». CNET. Retrieved 13 July 2019.
          14. ^ ISO/IEC JTC 1/SC 29 (2009-05-07). «ISO/IEC JTC 1/SC 29/WG 1 – Coding of Still Pictures (SC 29/WG 1 Structure)». Archived from the original on 2013-12-31. Retrieved 2009-11-11.
          15. ^ a b ISO/IEC JTC 1/SC 29. «Programme of Work, (Allocated to SC 29/WG 1)». Archived from the original on 2013-12-31. Retrieved 2009-11-07.
          16. ^ ISO. «JTC 1/SC 29 – Coding of audio, picture, multimedia and hypermedia information». Retrieved 2009-11-11.
          17. ^ a b JPEG. «Joint Photographic Experts Group, JPEG Homepage». Retrieved 2009-11-08.
          18. ^ «T.81 : Information technology – Digital compression and coding of continuous-tone still images – Requirements and guidelines». Itu.int. Retrieved 2009-11-07.
          19. ^
            William B. Pennebaker; Joan L. Mitchell (1993). JPEG still image data compression standard (3rd ed.). Springer. p. 291. ISBN 978-0-442-01272-4.
          20. ^ ISO. «JTC 1/SC 29 – Coding of audio, picture, multimedia and hypermedia information». Retrieved 2009-11-07.
          21. ^ «SPIFF, Still Picture Interchange File Format». Library of Congress. 30 January 2012. Archived from the original on 2018-07-31. Retrieved 2018-07-31.
          22. ^ JPEG (2009-04-24). «JPEG XR enters FDIS status: JPEG File Interchange Format (JFIF) to be standardized as JPEG Part 5» (Press release). Archived from the original on 2009-10-08. Retrieved 2009-11-09.
          23. ^ «JPEG File Interchange Format (JFIF)». ECMA TR/98 1st ed. Ecma International. 2009. Retrieved 2011-08-01.
          24. ^ «Forgent’s JPEG Patent». SourceForge. 2002. Retrieved 13 July 2019.
          25. ^ «Concerning recent patent claims». Jpeg.org. 2002-07-19. Archived from the original on 2007-07-14. Retrieved 2011-05-29.
          26. ^ «JPEG and JPEG2000 – Between Patent Quarrel and Change of Technology». Archived from the original on August 17, 2004. Retrieved 2017-04-16.{{cite web}}: CS1 maint: bot: original URL status unknown (link)
          27. ^ Kawamoto, Dawn (April 22, 2005). «Graphics patent suit fires back at Microsoft». CNET News. Retrieved 2023-01-20.
          28. ^ «Trademark Office Re-examines Forgent JPEG Patent». Publish.com. February 3, 2006. Archived from the original on 2016-05-15. Retrieved 2009-01-28.
          29. ^ «USPTO: Broadest Claims Forgent Asserts Against JPEG Standard Invalid». Groklaw.net. May 26, 2006. Retrieved 2007-07-21.
          30. ^ «Coding System for Reducing Redundancy». Gauss.ffii.org. Archived from the original on 2011-06-12. Retrieved 2011-05-29.
          31. ^ «JPEG Patent Claim Surrendered». Public Patent Foundation. November 2, 2006. Retrieved 2006-11-03.
          32. ^ «Ex Parte Reexamination Certificate for U.S. Patent No. 5,253,341». Archived from the original on June 2, 2008.
          33. ^ Workgroup. «Rozmanith: Using Software Patents to Silence Critics». Eupat.ffii.org. Archived from the original on 2011-07-16. Retrieved 2011-05-29.
          34. ^ «A Bounty of $5,000 to Name Troll Tracker: Ray Niro Wants To Know Who Is saying All Those Nasty Things About Him». Law.com. Retrieved 2011-05-29.
          35. ^ Reimer, Jeremy (2008-02-05). «Hunting trolls: USPTO asked to reexamine broad image patent». Arstechnica.com. Retrieved 2011-05-29.
          36. ^ U.S. Patent Office – Granting Reexamination on 5,253,341 C1
          37. ^ «Judge Puts JPEG Patent On Ice». Techdirt.com. 2008-04-30. Retrieved 2011-05-29.
          38. ^ «JPEG Patent’s Single Claim Rejected (And Smacked Down For Good Measure)». Techdirt.com. 2008-08-01. Retrieved 2011-05-29.
          39. ^ Workgroup. «Princeton Digital Image Corporation Home Page». Archived from the original on 2013-04-11. Retrieved 2013-05-01.
          40. ^ Workgroup. «Article on Princeton Court Ruling Regarding GE License Agreement». Archived from the original on 2016-03-09. Retrieved 2013-05-01.
          41. ^ «Progressive Decoding Overview». Microsoft Developer Network. Microsoft. Retrieved 2012-03-23.
          42. ^ Fastvideo (May 2019). «12-bit JPEG encoder on GPU». Retrieved 2019-05-06.
          43. ^ «Why You Should Always Rotate Original JPEG Photos Losslessly». Petapixel.com. 14 August 2012. Retrieved 16 October 2017.
          44. ^ «JFIF File Format as PDF» (PDF).
          45. ^ Tom Lane (1999-03-29). «JPEG image compression FAQ». Retrieved 2007-09-11. (q. 14: «Why all the argument about file formats?»)
          46. ^ a b «A Standard Default Color Space for the Internet — sRGB». www.w3.org.
          47. ^ a b «IEC 61966-2-1:1999/AMD1:2003 | IEC Webstore». webstore.iec.ch.
          48. ^ «ISO/IEC 10918-1 : 1993(E) p.36».
          49. ^ Thomas G. Lane. «Advanced Features: Compression parameter selection». Using the IJG JPEG Library.
          50. ^ Ryan, Dan (2012-06-20). E — Learning Modules: Dlr Associates Series. AuthorHouse. ISBN 9781468575200.
          51. ^ «DC / AC Frequency Questions — Doom9’s Forum». forum.doom9.org. Retrieved 16 October 2017.
          52. ^ a b Phuc-Tue Le Dinh and Jacques Patry. Video compression artifacts and MPEG noise reduction Archived 2006-03-14 at the Wayback Machine. Video Imaging DesignLine. February 24, 2006. Retrieved May 28, 2009.
          53. ^ «3.9 mosquito noise: Form of edge busyness distortion sometimes associated with movement, characterized by moving artifacts and/or blotchy noise patterns superimposed over the objects (resembling a mosquito flying around a person’s head and shoulders).»
            ITU-T Rec. P.930 (08/96) Principles of a reference impairment system for video Archived 2010-02-16 at the Wayback Machine
          54. ^ Julià Minguillón, Jaume Pujol (April 2001). «JPEG standard uniform quantization error modeling with applications to sequential and progressive operation modes» (PDF). Electronic Imaging. 10 (2): 475–485. Bibcode:2001JEI….10..475M. doi:10.1117/1.1344592. hdl:10609/6263.
          55. ^ a b I. Bauermann and E. Steinbacj. Further Lossless Compression of JPEG Images. Proc. of Picture Coding Symposium (PCS 2004), San Francisco, US, December 15–17, 2004.
          56. ^ a b N. Ponomarenko, K. Egiazarian, V. Lukin and J. Astola. Additional Lossless Compression of JPEG Images, Proc. of the 4th Intl. Symposium on Image and Signal Processing and Analysis (ISPA 2005), Zagreb, Croatia, pp. 117–120, September 15–17, 2005.
          57. ^ a b c d M. Stirner and G. Seelmann. Improved Redundancy Reduction for JPEG Files. Proc. of Picture Coding Symposium (PCS 2007), Lisbon, Portugal, November 7–9, 2007
          58. ^ a b c Ichiro Matsuda, Yukio Nomoto, Kei Wakabayashi and Susumu Itoh. Lossless Re-encoding of JPEG images using block-adaptive intra prediction. Proceedings of the 16th European Signal Processing Conference (EUSIPCO 2008).
          59. ^ Stirner, Matthias (19 February 2023). «packjpg/packJPG».
          60. ^ J. Siragusa, D. C. Swift (1997). «General Purpose Stereoscopic Data Descriptor» (PDF). VRex, Inc., Elmsford, New York, US. Archived from the original (PDF) on 2011-10-30.{{cite web}}: CS1 maint: uses authors parameter (link)
          61. ^ Tim Kemp, JPS files
          62. ^ «Multi-Picture Format» (PDF). 2009. Archived from the original (PDF) on 2016-04-05. Retrieved 2015-12-30.
          63. ^ «MPO2Stereo: Convert Fujifilm MPO files to JPEG stereo pairs», Mtbs3d.com, retrieved 12 January 2010
          64. ^ Alessandro Ortis; Sebastiano Battiato (2015), Sitnik, Robert; Puech, William (eds.), «A new fast matching method for adaptive compression of stereoscopic images», Three-Dimensional Image Processing, Three-Dimensional Image Processing, Measurement (3DIPM), and Applications 2015, SPIE — Three-Dimensional Image Processing, Measurement (3DIPM), and Applications 2015, 9393: 93930K, Bibcode:2015SPIE.9393E..0KO, doi:10.1117/12.2086372, S2CID 18879942, retrieved 30 April 2015
          65. ^ Alessandro Ortis; Francesco Rundo; Giuseppe Di Giore; Sebastiano Battiato, Adaptive Compression of Stereoscopic Images, International Conference on Image Analysis and Processing (ICIAP) 2013, retrieved 30 April 2015
          66. ^ «Overview of JPEG». jpeg.org. Retrieved 2017-10-16.
          67. ^ Tom Lane, January 16, 2013: jpeg-9, API/ABI compatibility, and the future role of this project
          68. ^ Software That Uses or Provides libjpeg-turbo. February 9, 2012.
          69. ^ Issue 48789 – chromium – Use libjpeg-turbo instead of libjpeg. April 14, 2011.
          70. ^ «ISO/IEC 10918-7: 2019 Information technology — Digital compression and coding of continuous-tone still images — Part 7: Reference software». ISO.«T.873 (05/19): Information technology — Digital compression and coding of continuous-tone still images: Reference software». www.itu.int.
          71. ^ «JPEG — JPEG XT». jpeg.org.
          72. ^ «Introducing the ‘mozjpeg’ Project». Mozilla Research.
          73. ^ Richter, Thomas (September 2016). «JPEG on STEROIDS: Common optimization techniques for JPEG image compression». 2016 IEEE International Conference on Image Processing (ICIP): 61–65. doi:10.1109/ICIP.2016.7532319. ISBN 978-1-4673-9961-6. S2CID 14922251.
          74. ^ «Announcing Guetzli: A New Open Source JPEG Encoder». Research.googleblog.com. Retrieved 16 October 2017.
          75. ^ «JPEG — JPEG XT». jpeg.org.
          76. ^ Alakuijala, Jyrki; van Asseldonk, Ruud; Boukortt, Sami; Bruse, Martin; Comșa, Iulia-Maria; Firsching, Moritz; Fischbacher, Thomas; Kliuchnikov, Evgenii; Gomez, Sebastian; Obryk, Robert; Potempa, Krzysztof; Rhatushnyak, Alexander; Sneyers, Jon; Szabadka, Zoltan; Vandervenne, Lode; Versari, Luca; Wassenberg, Jan (2019-09-06). «JPEG XL next-generation image compression architecture and coding tools». In Tescher, Andrew G; Ebrahimi, Touradj (eds.). Applications of Digital Image Processing XLII. p. 20. doi:10.1117/12.2529237. ISBN 9781510629677. S2CID 202785129.
          77. ^ Rhatushnyak, Alexander; Wassenberg, Jan; Sneyers, Jon; Alakuijala, Jyrki; Vandevenne, Lode; Versari, Luca; Obryk, Robert; Szabadka, Zoltan; Kliuchnikov, Evgenii; Comsa, Iulia-Maria; Potempa, Krzysztof; Bruse, Martin; Firsching, Moritz; Khasanova, Renata; Ruud van Asseldonk; Boukortt, Sami; Gomez, Sebastian; Fischbacher, Thomas (2019). «Committee Draft of JPEG XL Image Coding System». arXiv:1908.03565 [eess.IV].
          78. ^ «N79010 Final Call for Proposals for a Next-Generation Image Coding Standard (JPEG XL)» (PDF). ISO/IEC JTC 1/SC 29/WG 1 (ITU-T SG16). Retrieved 29 May 2018.
          79. ^ ISO/IEC 18181-1:2022 Information technology — JPEG XL image coding system — Part 1: Core coding system.
          80. ^ ISO/IEC 18181-2:2021 Information technology — JPEG XL image coding system — Part 2: File format.

          External links[edit]

          • Official website Edit this at Wikidata
          • JPEG Standard (JPEG ISO/IEC 10918-1 ITU-T Recommendation T.81) at W3.org
          • JFIF File Format at W3.org
          • Example images over the full range of quantization levels from 1 to 100 at visengi.com
          • JPEG decoder open source code, copyright (C) 1995–1997, Thomas G. Lane

          Понравилась статья? Поделить с друзьями:
        1. Расширение ворд как пишется
        2. Расшиблась как пишется
        3. Расшибет как правильно пишется
        4. Расчетливый как пишется суффикс
        5. Расшестка как правильно пишется