JPEG

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

Непрерывно варьируемое сжатие JPEG (от Q=100 до Q=1) для КТ брюшной полости

JPEG ( / ˈ dʒ eɪ p ɛ ɡ / JAY -peg , сокращение от Joint Photographic Experts Group ) ^[2] — это широко используемый метод сжатия с потерями для цифровых изображений , особенно для изображений, полученных с помощью цифровой фотографии . Степень сжатия можно регулировать, что позволяет выбирать компромисс между размером хранилища и качеством изображения . JPEG обычно достигает сжатия 10:1 с незначительной ощутимой потерей качества изображения. ^[3] С момента своего появления в 1992 году JPEG стал наиболее широко используемым стандартом сжатия изображений в мире ^{[4] [5]} и наиболее широко используемым форматом цифровых изображений : по состоянию на 2015 год ежедневно производилось несколько миллиардов изображений JPEG. ^[6]

Объединенная группа экспертов по фотографии создала стандарт в 1992 году. ^[7] JPEG в значительной степени способствовал распространению цифровых изображений и цифровых фотографий в Интернете, а позднее и в социальных сетях . ^{[8] [ циклическая ссылка ]} Сжатие JPEG используется в ряде форматов файлов изображений . JPEG/ Exif — наиболее распространенный формат изображений, используемый цифровыми камерами и другими устройствами захвата фотографических изображений; наряду с JPEG/ JFIF , это наиболее распространенный формат для хранения и передачи фотографических изображений во Всемирной паутине . ^[9] Эти вариации формата часто не различаются и называются просто JPEG.

Тип носителя MIME для JPEG — «image/jpeg», за исключением старых версий Internet Explorer , которые предоставляют тип MIME «image/pjpeg» при загрузке изображений JPEG. ^[10] Файлы JPEG обычно имеют расширение имени файла «jpg» или «jpeg». JPEG/JFIF поддерживает максимальный размер изображения 65 535×65 535 пикселей, ^[11] следовательно, до 4 гигапикселей для соотношения сторон 1:1. В 2000 году группа JPEG представила формат, предназначенный для преемника, JPEG 2000 , но он не смог заменить оригинальный JPEG в качестве доминирующего стандарта изображений. ^[12]

История

Фон

Первоначальная спецификация JPEG, опубликованная в 1992 году, реализует процессы из различных более ранних исследовательских работ и патентов, цитируемых CCITT (теперь ITU-T ) и Joint Photographic Experts Group. ^[1]

Спецификация JPEG ссылается на патенты нескольких компаний. Следующие патенты легли в основу алгоритма арифметического кодирования . ^[1]

• ИБМ
  • Патент США 4652856 - 4 февраля 1986 г. - Коттаппурам М.А. Мохиуддин и Йорма Дж. Риссанен - ​​Многоалфавитный арифметический код без умножения.
  • Патент США 4,905,297 – 27 февраля 1990 г. – G. Langdon, JL Mitchell , WB Pennebaker и Jorma J. Rissanen – Система арифметического кодирования и декодирования
  • Патент США 4,935,882 – 19 июня 1990 г. – WB Pennebaker и JL Mitchell – Вероятностная адаптация для арифметических кодеров
• Мицубиси Электрик
  • JP H02202267  (1021672) - 21 января 1989 г. - Тошихиро Кимура, Сигенори Кино, Фумитака Оно, Масаюки Ёсида - Система кодирования
  • JP H03247123  (2-46275) - 26 февраля 1990 г. - Томохиро Кимура, Сигенори Кино, Фумитака Оно и Масаюки Ёсида - Устройство кодирования и метод кодирования.

Спецификация JPEG также ссылается на три других патента от IBM. Другие компании, указанные в качестве владельцев патентов, включают AT&T (два патента) и Canon Inc. ^[1] В списке отсутствует патент США 4,698,672 , поданный Compression Labs ' Wen-Hsiung Chen и Daniel J. Klenke в октябре 1986 года. Патент описывает алгоритм сжатия изображений на основе DCT и позже стал причиной споров в 2002 году (см. Патентные споры ниже). ^[13] Однако спецификация JPEG ссылается на две более ранние исследовательские работы Wen-Hsiung Chen, опубликованные в 1977 и 1984 годах. ^[1]

стандарт JPEG

«JPEG» означает Joint Photographic Experts Group , название комитета, который создал стандарт JPEG и другие стандарты кодирования неподвижных изображений. «Joint» означает ISO TC97 WG8 и CCITT SGVIII. Основанная в 1986 году, группа разработала стандарт JPEG в конце 1980-х годов. Группа опубликовала стандарт JPEG в 1992 году. ^[4]

В 1987 году ISO TC 97 стал ISO/IEC JTC 1, а в 1992 году CCITT стал ITU-T. В настоящее время со стороны JTC1 JPEG является одной из двух подгрупп ISO / IEC Joint Technical Committee 1 , Subcommittee 29, Working Group 1 ( ISO/IEC JTC 1/SC 29 /WG 1) — под названием Coding of still pictures . ^{[14] [15] [16]} Со стороны ITU-T соответствующим органом является ITU-T SG16. Первоначальная группа JPEG была организована в 1986 году, ^[17] выпустив первый стандарт JPEG в 1992 году, который был утвержден в сентябре 1992 года как Рекомендация ITU-T T.81 ^[18] и в 1994 году как ISO / IEC 10918-1 .

Стандарт JPEG определяет кодек , который определяет, как изображение сжимается в поток байтов и распаковывается обратно в изображение, но не формат файла, используемый для хранения этого потока. ^[19] Стандарты Exif и JFIF определяют наиболее часто используемые форматы файлов для обмена изображениями, сжатыми с помощью JPEG.

Стандарты JPEG официально называются Информационные технологии – Цифровое сжатие и кодирование непрерывных тоновых неподвижных изображений . ISO/IEC 10918 состоит из следующих частей:

Ecma International TR /98 определяет формат обмена файлами JPEG (JFIF); первое издание было опубликовано в июне 2009 года. ^[23]

Патентный спор

В 2002 году Forgent Networks заявила, что владеет и будет обеспечивать соблюдение патентных прав на технологию JPEG, вытекающих из патента, который был подан 27 октября 1986 года и выдан 6 октября 1987 года: патент США 4 698 672 от Compression Labs ' Wen-Hsiung Chen и Daniel J. Klenke. ^{[13] [24]} Хотя Forgent в то время не владела Compression Labs, Чен позже продала Compression Labs Forgent, прежде чем Чен перешел на работу в Cisco . Это привело к тому, что Forgent приобрела право собственности на патент. ^[13] Заявление Forgent от 2002 года вызвало фурор, напоминающий попытки Unisys отстоять свои права на стандарт сжатия изображений GIF.

Комитет JPEG исследовал патентные заявки в 2002 году и пришел к выводу, что они были признаны недействительными в соответствии с предшествующим уровнем техники ^[25] , и эту точку зрения разделяли различные эксперты. ^{[13] [26]}

В период с 2002 по 2004 год Forgent удалось получить около 105 миллионов долларов США, лицензировав свой патент примерно 30 компаниям. В апреле 2004 года Forgent подала в суд на 31 другую компанию, чтобы добиться дополнительных лицензионных платежей. В июле того же года консорциум из 21 крупной компьютерной компании подал встречный иск с целью признания патента недействительным. Кроме того, в апреле 2005 года Microsoft подала отдельный иск против Forgent. ^[27] В феврале 2006 года Патентное и товарное ведомство США согласилось повторно рассмотреть патент Forgent на JPEG по запросу Public Patent Foundation. ^[28] 26 мая 2006 года USPTO признало патент недействительным на основании предшествующего уровня техники. USPTO также обнаружило, что Forgent знала о предшествующем уровне техники, но намеренно избегала сообщать об этом Патентному ведомству. Это делает любую апелляцию о восстановлении патента крайне маловероятной. ^[29]

Forgent также владеет аналогичным патентом, выданным Европейским патентным ведомством в 1994 году, хотя неясно, насколько он имеет юридическую силу. ^[30]

По состоянию на 27 октября 2006 года 20-летний срок действия патента США, по-видимому, истек, и в ноябре 2006 года Forgent согласилась отказаться от принудительного исполнения патентных исков против использования стандарта JPEG. ^[31]

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

Начиная с августа 2007 года другая компания, Global Patent Holdings, LLC, заявила, что ее патент ( патент США 5,253,341 ), выданный в 1993 году, нарушается загрузкой изображений JPEG либо на веб-сайте, либо по электронной почте. Если бы этот патент не был признан недействительным, он мог бы применяться к любому веб-сайту, отображающему изображения JPEG. Патент находился на повторной экспертизе в Бюро по патентам и товарным знакам США с 2000 по 2007 год; в июле 2007 года Патентное ведомство отменило все первоначальные притязания на патент, но обнаружило, что дополнительное притязание, предложенное Global Patent Holdings (притязание 17), было действительным. ^[32] Затем Global Patent Holdings подала ряд исков на основании притязания 17 своего патента.

В своих первых двух исках после повторной проверки, оба поданные в Чикаго, штат Иллинойс, Global Patent Holdings предъявила иски к Green Bay Packers , CDW , Motorola , Apple , Orbitz , Officemax , Caterpillar , Kraft и Peapod в качестве ответчиков. Третий иск был подан 5 декабря 2007 года в Южной Флориде против ADT Security Services , AutoNation , Florida Crystals Corp., HearUSA, MovieTickets.com , Ocwen Financial Corp. и Tire Kingdom , а четвертый иск 8 января 2008 года в Южной Флориде против Boca Raton Resort & Club . Пятый иск был подан против Global Patent Holdings в Неваде. Этот иск был подан Zappos.com , Inc., которой якобы угрожала Global Patent Holdings, и которая добивалась судебного заявления о том, что патент '341 является недействительным и не нарушенным.

Global Patent Holdings также использовала патент '341 для подачи в суд или угроз откровенным критикам широких патентов на программное обеспечение, включая Грегори Аароняна ^[33] и анонимного оператора веб-блога, известного как « Patent Troll Tracker ». ^[34] 21 декабря 2007 года патентный юрист Вернон Фрэнсиссен из Чикаго обратился в Бюро по патентам и товарным знакам США с просьбой пересмотреть единственное оставшееся требование патента '341 на основе нового предшествующего уровня техники. ^[35]

5 марта 2008 года Патентное и товарное бюро США согласилось провести повторную экспертизу патента '341, обнаружив, что новый предшествующий уровень техники поднимает существенные новые вопросы относительно действительности патента. ^[36] В свете повторной экспертизы обвиняемые нарушители в четырех из пяти ожидающих рассмотрения исков подали ходатайства о приостановлении (отсрочке) своих дел до завершения рассмотрения патента '341 Патентным и товарным бюро США. 23 апреля 2008 года судья, председательствовавший на двух судебных процессах в Чикаго, штат Иллинойс, удовлетворил ходатайства по этим делам. ^[37] 22 июля 2008 года Патентное ведомство выдало первое «Действие ведомства» второй повторной экспертизы, признав иск недействительным по девятнадцати отдельным основаниям. ^[38] 24 ноября 2009 года было выдано свидетельство о повторной экспертизе, отменяющее все иски.

Начиная с 2011 года и по состоянию на начало 2013 года, организация, известная как Princeton Digital Image Corporation, ^[39] базирующаяся в Восточном Техасе, начала подавать в суд на большое количество компаний за предполагаемое нарушение патента США 4,813,056 . Princeton утверждает, что стандарт сжатия изображений JPEG нарушает патент '056, и подала в суд на большое количество веб-сайтов, розничных продавцов, производителей камер и устройств и реселлеров. Первоначально патент принадлежал и был передан General Electric. Срок действия патента истек в декабре 2007 года, но Princeton подала в суд на большое количество компаний за «прошлое нарушение» этого патента. (Согласно патентному законодательству США, владелец патента может подать в суд за «прошлое нарушение» за шесть лет до подачи иска, поэтому Принстон теоретически мог продолжать судиться с компаниями до декабря 2013 года.) По состоянию на март 2013 года Принстон имел иски, ожидающие рассмотрения в Нью-Йорке и Делавэре против более чем 55 компаний. Участие General Electric в иске неизвестно, хотя судебные записи указывают на то, что она передала патент Принстону в 2009 году и сохраняет определенные права на патент. ^[40]

Типичное использование

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

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

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

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

сжатие JPEG

JPEG использует сжатие с потерями, основанное на дискретном косинусном преобразовании (DCT) . Эта математическая операция преобразует каждый кадр/поле источника видео из пространственной (2D) области в частотную область (также известную как область преобразования). Перцептивная модель, основанная на человеческой психовизуальной системе, отбрасывает высокочастотную информацию, то есть резкие переходы интенсивности и цветового оттенка. В области преобразования процесс уменьшения информации называется квантованием. Проще говоря, квантование — это метод оптимального уменьшения большой числовой шкалы (с различным вхождением каждого числа) до меньшей, а область преобразования — это удобное представление изображения, поскольку высокочастотные коэффициенты, которые вносят меньший вклад в общую картину, чем другие коэффициенты, характеризуются малыми значениями с высокой сжимаемостью. Затем квантованные коэффициенты упорядочиваются и без потерь упаковываются в выходной битовый поток. Почти все программные реализации JPEG позволяют пользователю контролировать степень сжатия (а также другие необязательные параметры), что позволяет пользователю выбирать компромисс между качеством изображения и меньшим размером файла. Во встраиваемых приложениях (например, miniDV, который использует похожую схему DCT-сжатия) параметры предварительно выбираются и фиксируются для приложения.

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

Существует также формат чересстрочного прогрессивного JPEG, в котором данные сжимаются в несколько проходов с прогрессивно более высокой детализацией. Это идеально подходит для больших изображений, которые будут отображаться во время загрузки по медленному соединению, позволяя разумный предварительный просмотр после получения только части данных. Однако поддержка прогрессивных JPEG не является универсальной. Когда прогрессивные JPEG получаются программами, которые их не поддерживают (например, версии Internet Explorer до Windows 7 ) ^[41], программное обеспечение отображает изображение только после его полной загрузки.

Существует также множество приложений для медицинской визуализации, дорожного движения и камер, которые создают и обрабатывают 12-битные изображения JPEG как в оттенках серого, так и в цвете. 12-битный формат JPEG включен в расширенную часть спецификации JPEG. Кодек libjpeg поддерживает 12-битный JPEG, и даже существует высокопроизводительная версия. ^[42]

Редактирование без потерь

Несколько изменений в изображении JPEG могут быть выполнены без потерь (то есть без повторного сжатия и связанной с этим потери качества), пока размер изображения кратен 1 блоку MCU (минимальная кодированная единица) (обычно 16 пикселей в обоих направлениях, для цветовой субдискретизации 4:2:0 ). Утилиты, реализующие это, включают:

• jpegtran и его графический интерфейс Jpegcrop.
• IrfanView использует «JPG Lossless Crop (PlugIn)» и «JPG Lossless Rotation (PlugIn)», для которых требуется установка плагина JPG_TRANSFORM.
• FastStone Image Viewer с функциями «Обрезка без потерь в файл» и «Поворот JPEG без потерь».
• XnViewMP использует «преобразования JPEG без потерь».
• ACDSee поддерживает поворот без потерь (но не кадрирование без потерь) с помощью опции «Принудительные операции JPEG без потерь».

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

Верхний и левый край изображения JPEG должны лежать на границе блока 8 × 8 пикселей (или 16 × 16 пикселей для больших размеров MCU), но нижний и правый край не должны этого делать. Это ограничивает возможные операции обрезки без потерь и предотвращает перевороты и повороты изображения, нижний или правый край которого не лежит на границе блока для всех каналов (потому что край окажется сверху или слева, где, как упоминалось выше, граница блока обязательна).

Повороты, где изображение не кратно 8 или 16, значение которых зависит от подвыборки цветности, не являются без потерь. Поворот такого изображения приводит к пересчету блоков, что приводит к потере качества. ^[43]

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

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

JPEG-файлы

Формат файла, известный как «JPEG Interchange Format» (JIF), указан в Приложении B стандарта. Однако этот «чистый» формат файла используется редко, в первую очередь из-за сложности программирования кодеров и декодеров, которые полностью реализуют все аспекты стандарта, а также из-за некоторых недостатков стандарта:

• Определение цветового пространства
• Регистрация подвыборки компонентов
• Определение соотношения сторон пикселя.

Для решения этих проблем было разработано несколько дополнительных стандартов. Первым из них, выпущенным в 1992 году, был формат обмена файлами JPEG (или JFIF), за которым в последние годы последовали формат файла изображения Exchangeable (Exif) и цветовые профили ICC . Оба эти формата используют фактическую байтовую структуру JIF, состоящую из различных маркеров , но, кроме того, используют одну из точек расширения стандарта JIF, а именно маркеры приложений : JFIF использует APP0, в то время как Exif использует APP1. В этих сегментах файла, которые были оставлены для будущего использования в стандарте JIF и не считываются им, эти стандарты добавляют определенные метаданные.

Таким образом, в некотором смысле JFIF является урезанной версией стандарта JIF, поскольку он определяет определенные ограничения (например, не допускает все различные режимы кодирования), в то время как в других отношениях он является расширением JIF из-за добавленных метаданных. В документации к исходному стандарту JFIF указано: ^[44]

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

Файлы изображений, использующие сжатие JPEG, обычно называются «файлами JPEG» и хранятся в вариантах формата изображения JIF. Большинство устройств захвата изображений (например, цифровые камеры), которые выводят JPEG, на самом деле создают файлы в формате Exif , который индустрия камер стандартизировала для обмена метаданными. С другой стороны, поскольку стандарт Exif не допускает цветовых профилей, большинство программ для редактирования изображений хранят JPEG в формате JFIF и включают сегмент APP1 из файла Exif, чтобы включить метаданные почти совместимым образом; стандарт JFIF интерпретируется довольно гибко. ^[45]

Строго говоря, стандарты JFIF и Exif несовместимы, поскольку каждый из них указывает, что его сегмент маркера (APP0 или APP1 соответственно) должен появляться первым. На практике большинство файлов JPEG содержат сегмент маркера JFIF, который предшествует заголовку Exif. Это позволяет старым считывателям правильно обрабатывать сегмент JFIF старого формата, в то время как новые считыватели также декодируют следующий сегмент Exif, будучи менее строгими в отношении требования, чтобы он появлялся первым.

Расширения имени файла JPEG

Наиболее распространенными расширениями имен файлов, использующих сжатие JPEG, являются .jpgи , .jpegхотя также используются и . [ ^46] Данные JPEG также могут быть встроены в другие типы файлов — файлы в кодировке TIFF часто встраивают изображение JPEG в качестве миниатюры основного изображения; а файлы MP3 могут содержать JPEG обложки в теге ID3v2 ..jpe.jfif.jif

Цветовой профиль

Многие файлы JPEG содержат цветовой профиль ICC ( цветовое пространство ). Обычно используемые цветовые профили включают sRGB и Adobe RGB . Поскольку эти цветовые пространства используют нелинейное преобразование, динамический диапазон 8-битного файла JPEG составляет около 11 ступеней ; см. гамма-кривую .

Если изображение не содержит информации о цветовом профиле ( без тегов ), предполагается, что цветовое пространство — sRGB для целей отображения на веб-страницах. ^{[47] [48]}

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

Изображение JPEG состоит из последовательности сегментов , каждый из которых начинается с маркера , каждый из которых начинается с байта 0xFF, за которым следует байт, указывающий, какой это тип маркера. Некоторые маркеры состоят только из этих двух байтов; за другими следуют два байта (старший, затем младший), указывающие длину полезных данных, специфичных для маркера, которые следуют далее. (Длина включает два байта для длины, но не два байта для маркера.) За некоторыми маркерами следуют данные с энтропийным кодированием ; длина такого маркера не включает данные с энтропийным кодированием. Обратите внимание, что последовательные байты 0xFF используются в качестве байтов заполнения для целей заполнения , хотя это заполнение байтами заполнения должно иметь место только для маркеров, следующих сразу за данными сканирования с энтропийным кодированием (подробности см. в разделе B.1.1.2 и E.1.2 спецификации JPEG; в частности, «Во всех случаях, когда маркеры добавляются после сжатых данных, необязательные байты заполнения 0xFF могут предшествовать маркеру»).

В энтропийно-кодированных данных после любого байта 0xFF кодировщик вставляет байт 0x00 перед следующим байтом, так что не должно быть маркера там, где его нет, что предотвращает ошибки кадрирования. Декодеры должны пропустить этот байт 0x00. Эта техника, называемая байтовой стаффингом (см. спецификацию JPEG, раздел F.1.2.3), применяется только к энтропийно-кодированным данным, а не к данным полезной нагрузки маркера. Однако следует отметить, что энтропийно-кодированные данные имеют несколько собственных маркеров; в частности, маркеры сброса (от 0xD0 до 0xD7), которые используются для изоляции независимых фрагментов энтропийно-кодированных данных для обеспечения параллельного декодирования, и кодировщики могут свободно вставлять эти маркеры сброса через регулярные интервалы (хотя не все кодировщики это делают).

Существуют и другие маркеры начала кадра , которые представляют другие виды кодировок JPEG.

Поскольку несколько поставщиков могут использовать один и тот же тип маркера APP n , маркеры, специфичные для приложения, часто начинаются со стандартного или имени поставщика (например, «Exif» или «Adobe») или какой-либо другой идентификационной строки.

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

Пример кодека JPEG

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

1. Представление цветов в изображении преобразуется из RGB в Y′C _B C _R , состоящее из одного компонента яркости (Y'), представляющего яркость, и двух компонентов цветности (C _B и C _R ), представляющих цвет. Этот шаг иногда пропускается.
2. Разрешение данных цветности обычно уменьшается в 2 или 3 раза. Это отражает тот факт, что глаз менее чувствителен к мелким цветовым деталям, чем к мелким деталям яркости.
3. Изображение разбивается на блоки размером 8×8 пикселей, и для каждого блока данные Y, C _B и C _R подвергаются дискретному косинусному преобразованию (DCT). DCT похоже на преобразование Фурье в том смысле, что оно создает своего рода спектр пространственных частот.
4. Амплитуды частотных компонентов квантуются . Человеческое зрение гораздо более чувствительно к небольшим изменениям цвета или яркости на больших площадях, чем к силе высокочастотных изменений яркости. Поэтому величины высокочастотных компонентов сохраняются с меньшей точностью, чем низкочастотные компоненты. Настройка качества кодировщика (например, 50 или 95 по шкале 0–100 в библиотеке Independent JPEG Group ^[50] ) влияет на то, в какой степени уменьшается разрешение каждого частотного компонента. Если используется чрезмерно низкая настройка качества, высокочастотные компоненты полностью отбрасываются.
5. Полученные данные для всех блоков 8×8 дополнительно сжимаются с помощью алгоритма без потерь, варианта кодирования Хаффмана .

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

Кодирование

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

Преобразование цветового пространства

Во-первых, изображение должно быть преобразовано из RGB (по умолчанию sRGB, ^{[47] [48],} но возможны и другие цветовые пространства ) в другое цветовое пространство, называемое Y′C _B C _R (или, неформально, YCbCr). Оно имеет три компонента Y', C _B и C _R : компонент Y' представляет яркость пикселя, а компоненты C _B и C _R представляют цветность (разделенную на синюю и красную компоненты). Это в основном то же самое цветовое пространство, которое используется цифровым цветным телевидением, а также цифровым видео, включая видео DVD . Преобразование цветового пространства Y′C _B C _R обеспечивает большее сжатие без существенного влияния на воспринимаемое качество изображения (или большее воспринимаемое качество изображения при том же сжатии). Сжатие более эффективно, поскольку информация о яркости, которая более важна для конечного воспринимаемого качества изображения, ограничена одним каналом. Это более точно соответствует восприятию цвета в зрительной системе человека. Преобразование цвета также улучшает сжатие за счет статистической декорреляции .

Конкретное преобразование в Y′C _B C _R указано в стандарте JFIF и должно быть выполнено для того, чтобы полученный файл JPEG имел максимальную совместимость. Однако некоторые реализации JPEG в режиме «наивысшего качества» не применяют этот шаг и вместо этого сохраняют цветовую информацию в цветовой модели RGB, ^[51] где изображение хранится в отдельных каналах для красного, зеленого и синего компонентов яркости. Это приводит к менее эффективному сжатию и вряд ли будет использоваться, когда размер файла особенно важен.

Понижение частоты дискретизации

Благодаря плотности цвето- и яркостно-чувствительных рецепторов в человеческом глазу, люди могут видеть значительно больше мелких деталей в яркости изображения (компонент Y'), чем в оттенке и насыщенности цвета изображения (компоненты Cb и Cr). Используя эти знания, можно разработать кодировщики для более эффективного сжатия изображений.

Преобразование в цветовую модель Y′C _B C _R позволяет перейти к следующему обычному шагу, который заключается в уменьшении пространственного разрешения компонентов Cb и Cr (называется « понижением разрешения » или « субдискретизацией цветности »). Соотношения, при которых обычно выполняется понижение разрешения для изображений JPEG, составляют 4:4:4 (без понижения разрешения), 4:2:2 (уменьшение в 2 раза по горизонтали) или (чаще всего) 4:2:0 (уменьшение в 2 раза как по горизонтали, так и по вертикали). Для остальной части процесса сжатия Y', Cb и Cr обрабатываются отдельно и очень похожим образом.

Разделение блоков

После субдискретизации каждый канал должен быть разделен на блоки 8×8. В зависимости от субдискретизации цветности это дает блоки Minimum Coded Unit (MCU) размером 8×8 (4:4:4 — без субдискретизации), 16×8 (4:2:2) или, что наиболее часто встречается, 16×16 (4:2:0). В сжатии видео MCU называются макроблоками .

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

Дискретное косинусное преобразование

Часть изображения 8×8, показанная в 8-битных оттенках серого

Затем каждый блок 8×8 каждого компонента (Y, Cb, Cr) преобразуется в представление в частотной области с использованием нормализованного двумерного дискретного косинусного преобразования (DCT) типа II, см. Ссылку 1 в дискретном косинусном преобразовании. DCT иногда называют «DCT типа II» в контексте семейства преобразований, как в дискретном косинусном преобразовании , а соответствующее обратное (IDCT) обозначается как «DCT типа III».

В качестве примера можно привести следующее 8-битное подизображение размером 8×8:

${\displaystyle \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&94\end{array}}\right].}$

Перед вычислением DCT блока 8×8 его значения смещаются из положительного диапазона в диапазон, центрированный на нуле. Для 8-битного изображения каждая запись в исходном блоке попадает в диапазон . Средняя точка диапазона (в данном случае значение 128) вычитается из каждой записи для получения диапазона данных, центрированного на нуле, так что измененный диапазон равен . Этот шаг снижает требования к динамическому диапазону на следующем этапе обработки DCT. ${\displaystyle [0,255]}$ ${\displaystyle [-128,127]}$

Результатом этого шага являются следующие значения:

${\displaystyle 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&-34\end{array}}\right]\end{array}}{\Bigg \downarrow }y.}$

DCT преобразует блок входных значений 8×8 в линейную комбинацию этих 64 шаблонов. Шаблоны называются двумерными базисными функциями DCT , а выходные значения называются коэффициентами преобразования . Горизонтальный индекс равен , а вертикальный индекс равен . ${\displaystyle u}$ ${\displaystyle v}$

Следующим шагом является использование двумерного DCT, которое задается формулой:

${\displaystyle \ 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)u\pi }{16}}\right]\cos \left[{\frac {(2y+1)v\pi }{16}}\right]}$

где

• ${\displaystyle \ u}$— горизонтальная пространственная частота для целых чисел . ${\displaystyle \ 0\leq u<8}$
• ${\displaystyle \ v}$— вертикальная пространственная частота для целых чисел . ${\displaystyle \ 0\leq v<8}$
• ${\displaystyle \alpha (u)={\begin{cases}{\frac {1}{\sqrt {2}}},&{\mbox{if }}u=0\\1,&{\mbox{otherwise}}\end{cases}}}$нормирующий масштабный коэффициент, делающий преобразование ортонормальным
• ${\displaystyle \ g_{x,y}}$это значение пикселя в координатах ${\displaystyle \ (x,y)}$
• ${\displaystyle \ G_{u,v}}$- коэффициент DCT в координатах ${\displaystyle \ (u,v).}$

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

${\displaystyle 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.68\end{array}}\right]\end{array}}{\Bigg \downarrow }v.}$

Обратите внимание на запись в верхнем левом углу с довольно большой величиной. Это коэффициент DC (также называемый постоянной составляющей), который определяет основной оттенок для всего блока. Остальные 63 коэффициента являются коэффициентами AC (также называемыми переменными составляющими). ^​​[52] Преимущество DCT заключается в его тенденции агрегировать большую часть сигнала в одном углу результата, как можно увидеть выше. Следующий шаг квантования подчеркивает этот эффект, одновременно уменьшая общий размер коэффициентов DCT, в результате чего получается сигнал, который легко эффективно сжимать на этапе энтропии.

DCT временно увеличивает битовую глубину данных, поскольку коэффициенты DCT 8-битного/компонентного изображения занимают до 11 или более бит (в зависимости от точности расчета DCT) для хранения. Это может заставить кодек временно использовать 16-битные числа для хранения этих коэффициентов, удваивая размер представления изображения на этом этапе; эти значения обычно уменьшаются до 8-битных значений на этапе квантования. Временное увеличение размера на этом этапе не является проблемой производительности для большинства реализаций JPEG, поскольку обычно только очень небольшая часть изображения сохраняется в полной форме DCT в любой момент времени во время процесса кодирования или декодирования изображения.

Квантование

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

Элементы матрицы квантования управляют степенью сжатия, причем большие значения обеспечивают большее сжатие. Типичная матрица квантования (для качества 50%, как указано в исходном стандарте JPEG), выглядит следующим образом:

${\displaystyle 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&99\end{bmatrix}}.}$

Квантованные коэффициенты DCT вычисляются с помощью

${\displaystyle 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}$

где — неквантованные коэффициенты ДКП; — матрица квантования, указанная выше; — квантованные коэффициенты ДКП. ${\displaystyle G}$ ${\displaystyle Q}$ ${\displaystyle B}$

Использование этой матрицы квантования с матрицей коэффициентов DCT, приведенной выше, приводит к следующему:

Слева: конечное изображение создается из ряда базисных функций. Справа: каждая из базисных функций DCT, составляющих изображение, и соответствующий весовой коэффициент. Посередине: базисная функция после умножения на коэффициент: этот компонент добавляется к конечному изображению. Для ясности макроблок 8×8 в этом примере увеличен в 10 раз с помощью билинейной интерполяции.

${\displaystyle 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&0\end{array}}\right].}$

Например, используя −415 (коэффициент DC) и округляя до ближайшего целого числа

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

Обратите внимание, что большинство высокочастотных элементов субблока (т. е. те, у которых пространственная частота x или y больше 4) квантуются в нулевые значения.

Энтропийное кодирование

Зигзагообразный порядок компонентов изображения JPEG

Энтропийное кодирование — это особая форма сжатия данных без потерь . Оно включает в себя упорядочивание компонентов изображения в « зигзагообразном » порядке с использованием алгоритма кодирования длин серий (RLE), который группирует похожие частоты вместе, вставляя нули кодирования длины, а затем применяя кодирование Хаффмана к тому, что осталось.

Стандарт JPEG также позволяет, но не требует, чтобы декодеры поддерживали использование арифметического кодирования , которое математически превосходит кодирование Хаффмана. Однако эта функция использовалась редко, поскольку исторически она была защищена патентами, требующими лицензий с выплатой роялти, и потому что она медленнее кодируется и декодируется по сравнению с кодированием Хаффмана. Арифметическое кодирование обычно делает файлы примерно на 5–7% меньше ^{[ требуется цитата ]} .

Предыдущий квантованный коэффициент DC используется для предсказания текущего квантованного коэффициента DC. Кодируется разница между ними, а не фактическое значение. Кодирование 63 квантованных коэффициентов AC не использует такое предсказание дифференциации.

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

Если i -й блок представлен как , а позиции внутри каждого блока представлены как , где и , то любой коэффициент в изображении DCT может быть представлен как . Таким образом, в приведенной выше схеме порядок кодирования пикселей (для i -го блока) — , , , , , , , и так далее. ${\displaystyle B_{i}}$ ${\displaystyle (p,q)}$ ${\displaystyle p=0,1,...,7}$ ${\displaystyle q=0,1,...,7}$ ${\displaystyle B_{i}(p,q)}$ ${\displaystyle B_{i}(0,0)}$ ${\displaystyle B_{i}(0,1)}$ ${\displaystyle B_{i}(1,0)}$ ${\displaystyle B_{i}(2,0)}$ ${\displaystyle B_{i}(1,1)}$ ${\displaystyle B_{i}(0,2)}$ ${\displaystyle B_{i}(0,3)}$ ${\displaystyle B_{i}(1,2)}$

Базовые последовательные процессы кодирования и декодирования JPEG

Этот режим кодирования называется базовым последовательным кодированием. Базовый JPEG также поддерживает прогрессивное кодирование. В то время как последовательное кодирование кодирует коэффициенты одного блока за раз (зигзагообразным образом), прогрессивное кодирование кодирует схоже расположенную партию коэффициентов всех блоков за один раз (называется сканированием ) , за которой следует следующая партия коэффициентов всех блоков и т. д. Например, если изображение разделено на N блоков 8×8 , то прогрессивное кодирование с 3 сканированиями кодирует компонент постоянного тока для всех блоков, т. е. для всех , в первом сканировании. За этим следует второе сканирование, которое кодирует еще несколько компонентов (предполагая, что еще четыре компонента, они должны , все еще зигзагообразным образом) коэффициенты всех блоков (поэтому последовательность: ), за которыми следуют все оставшиеся коэффициенты всех блоков в последнем сканировании. ${\displaystyle B_{0},B_{1},B_{2},...,B_{n-1}}$ ${\displaystyle B_{i}(0,0)}$ ${\displaystyle i=0,1,2,...,N-1}$ ${\displaystyle B_{i}(0,1)}$ ${\displaystyle B_{i}(1,1)}$ ${\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)}$

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

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

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

Процесс кодирования зигзагообразных квантованных данных начинается с кодирования длин серий, описанного ниже, где:

• x — ненулевой квантованный коэффициент переменного тока.
• RUNLENGTH — это количество нулей, которые стояли перед этим ненулевым коэффициентом AC.
• РАЗМЕР — это количество бит, необходимое для представления x .
• АМПЛИТУДА — это битовое представление x .

Кодирование длины серии работает путем проверки каждого ненулевого коэффициента AC x и определения того, сколько нулей было перед предыдущим коэффициентом AC. С помощью этой информации создаются два символа:

И RUNLENGTH , и SIZE находятся на одном и том же байте, что означает, что каждый из них содержит только четыре бита информации. Старшие биты имеют дело с количеством нулей, тогда как младшие биты обозначают количество битов, необходимых для кодирования значения x .

Это имеет непосредственное значение, что Символ 1 может хранить информацию только о первых 15 нулях, предшествующих ненулевому коэффициенту AC. Однако JPEG определяет два специальных кодовых слова Хаффмана. Одно предназначено для преждевременного завершения последовательности, когда оставшиеся коэффициенты равны нулю (называется «End-of-Block» или «EOB»), а другое — когда последовательность нулей выходит за пределы 15, не достигнув ненулевого коэффициента AC. В таком случае, когда 16 нулей встречаются перед заданным ненулевым коэффициентом AC, Символ 1 кодируется «специально» как: (15, 0)(0).

Весь процесс продолжается до тех пор, пока не будет достигнут «EOB» — обозначенный (0, 0).

Учитывая это, последовательность, приведенная ранее, становится следующей:

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

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

(Первое значение в матрице, −26, является коэффициентом DC; он кодируется не так. См. выше.)

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

Коэффициент сжатия и артефакты

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

Исходное изображение

На увеличенном изображении видны сжатые квадраты 8×8, а также другие визуальные артефакты сжатия с потерями .

Результирующий коэффициент сжатия может варьироваться в зависимости от необходимости, делая его более или менее агрессивным в делителях, используемых на этапе квантования. Сжатие десять к одному обычно приводит к изображению, которое невозможно отличить на глаз от оригинала. Коэффициент сжатия 100:1 обычно возможен, но будет выглядеть отчетливо артефактным по сравнению с оригиналом. Соответствующий уровень сжатия зависит от того, для чего будет использоваться изображение.

Те, кто пользуется Всемирной паутиной, могут быть знакомы с неровностями, известными как артефакты сжатия , которые появляются в изображениях JPEG, которые могут принимать форму шума вокруг контрастных краев (особенно кривых и углов) или «блочных» изображений. Они возникают из-за шага квантования алгоритма JPEG. Они особенно заметны вокруг острых углов между контрастными цветами (текст является хорошим примером, так как он содержит много таких углов). Аналогичные артефакты в видео MPEG называются комариным шумом , поскольку результирующая «загруженность краев» и ложные точки, которые меняются со временем, напоминают комаров, роящихся вокруг объекта. ^{[53] [54]}

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

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

Поскольку этап квантования всегда приводит к потере информации, стандарт JPEG всегда является кодеком сжатия с потерями. (Информация теряется как при квантовании, так и при округлении чисел с плавающей точкой.) Даже если матрица квантования представляет собой матрицу единиц , информация все равно будет потеряна на этапе округления.

Расшифровка

Декодирование для отображения изображения заключается в выполнении всех вышеперечисленных действий в обратном порядке.

Берем матрицу коэффициентов DCT (после добавления разницы коэффициентов DC обратно)

${\displaystyle \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&0\end{array}}\right]}$

и взятие произведения «вход-вход» с матрицей квантования сверху приводит к

${\displaystyle \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&0\end{array}}\right]}$

что очень похоже на исходную матрицу коэффициентов DCT для верхней левой части.

Следующим шагом является использование двумерного обратного дискретного косинусного преобразования (двумерного дискретного косинусного преобразования типа III), которое определяется по формуле:

${\displaystyle 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)u\pi }{16}}\right]\cos \left[{\frac {(2y+1)v\pi }{16}}\right]}$

где

• ${\displaystyle \ x}$— строка пикселей для целых чисел . ${\displaystyle \ 0\leq x<8}$
• ${\displaystyle \ y}$— столбец пикселей для целых чисел . ${\displaystyle \ 0\leq y<8}$
• ${\displaystyle \ \alpha (u)}$— нормализующий масштабный коэффициент, определенный ранее для целых чисел . ${\displaystyle \ 0\leq u<8}$
• ${\displaystyle \ F_{u,v}}$— приближенный коэффициент DCT в координатах ${\displaystyle \ (u,v).}$
• ${\displaystyle \ f_{x,y}}$это восстановленное значение пикселя в координатах ${\displaystyle \ (x,y)}$

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

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

${\displaystyle \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&-41\end{array}}\right]}$

и добавляя 128 к каждой записи

${\displaystyle \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&87\end{array}}\right].}$

Это распакованное подизображение. В общем случае процесс распаковки может выдавать значения, выходящие за пределы исходного входного диапазона . Если это происходит, декодеру необходимо обрезать выходные значения, чтобы они оставались в пределах этого диапазона, чтобы предотвратить переполнение при сохранении распакованного изображения с исходной битовой глубиной. ${\displaystyle [0,255]}$

Распакованное подизображение можно сравнить с исходным подизображением (см. также изображения справа), взяв разницу (исходное − несжатое), что дает следующие значения ошибок:

${\displaystyle \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&7\end{array}}\right]}$

со средней абсолютной ошибкой около 5 значений на пиксель (т.е. ). ${\displaystyle {\frac {1}{64}}\sum _{x=0}^{7}\sum _{y=0}^{7}|e(x,y)|=4.8750}$

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

Требуемая точность

Требуемая точность реализации кодека JPEG неявно определяется через требования, сформулированные для соответствия стандарту JPEG. Эти требования указаны в Рекомендации ITU.T T.83 | ISO/IEC 10918-2. В отличие от стандартов MPEG и многих более поздних стандартов JPEG, указанный выше документ определяет как требуемую точность реализации для процесса кодирования, так и декодирования кодека JPEG посредством максимально допустимой ошибки прямого и обратного DCT в домене DCT, определяемой эталонными тестовыми потоками. Например, выход реализации декодера не должен превышать ошибку одной единицы квантования в домене DCT при применении к эталонным тестовым кодовым потокам, предоставленным как часть указанного выше стандарта. Хотя это необычно и в отличие от многих других и более современных стандартов, ITU.T T.83 | ISO/IEC 10918-2 не формулирует границы ошибок в области изображения.

Эффекты сжатия JPEG

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

Примеры фотографий

Визуальное воздействие сжатия JPEG в Photoshop на изображение размером 4480x4480 пикселей

Для информации, несжатое 24-битное растровое изображение RGB ниже (73 242 пикселя) потребует 219 726 байт (исключая все остальные заголовки информации). Указанные ниже размеры файлов включают внутренние заголовки информации JPEG и некоторые метаданные . Для изображений наивысшего качества (Q=100) требуется около 8,25 бит на пиксель цвета. Для изображений в оттенках серого достаточно минимум 6,5 бит на пиксель (для сопоставимой цветовой информации качества Q=100 требуется примерно на 25% больше кодированных бит). Изображение наивысшего качества ниже (Q=100) кодируется девятью битами на пиксель цвета, изображение среднего качества (Q=25) использует один бит на пиксель цвета. Для большинства приложений коэффициент качества не должен опускаться ниже 0,75 бит на пиксель (Q=12,5), как показано на изображении низкого качества. Изображение самого низкого качества использует всего 0,13 бит на пиксель и отображает очень плохие цвета. Это полезно, когда изображение будет отображаться в значительно уменьшенном размере. Метод создания лучших матриц квантования для заданного качества изображения с использованием PSNR вместо Q-фактора описан в Minguillón & Pujol (2001). ^[55]

Фотография среднего качества использует всего 4,3% дискового пространства, необходимого для несжатого изображения, но имеет мало заметных потерь деталей или видимых артефактов. Однако, как только определенный порог сжатия преодолен, сжатые изображения показывают все более заметные дефекты. См. статью о теории скорости искажения для математического объяснения этого порогового эффекта. Особым ограничением JPEG в этом отношении является его неперекрывающаяся структура преобразования блоков 8×8. Более современные разработки, такие как JPEG 2000 и JPEG XR, демонстрируют более изящное ухудшение качества по мере уменьшения использования битов — за счет использования преобразований с большей пространственной протяженностью для коэффициентов более низкой частоты и за счет использования перекрывающихся базисных функций преобразования.

Дальнейшее сжатие без потерь

С 2004 по 2008 год появились новые исследования способов дальнейшего сжатия данных, содержащихся в изображениях JPEG, без изменения представленного изображения. ^{[56] [57] [58] [59]} Это имеет применение в сценариях, где исходное изображение доступно только в формате JPEG, и его размер необходимо уменьшить для архивации или передачи. Стандартные инструменты сжатия общего назначения не могут значительно сжимать файлы JPEG.

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

• Корреляции между величинами соседних коэффициентов в одном блоке;
• Корреляции между величинами одного и того же коэффициента в соседних блоках;
• Корреляции между величинами одного и того же коэффициента/блока в разных каналах;
• Коэффициенты DC, взятые вместе, напоминают уменьшенную версию исходного изображения, умноженную на коэффициент масштабирования. Могут быть применены известные схемы кодирования без потерь для изображений с непрерывным тоном, что позволяет достичь несколько лучшего сжатия, чем DPCM с кодировкой Хаффмана, используемая в JPEG.

Некоторые стандартные, но редко используемые опции уже существуют в JPEG для повышения эффективности кодирования коэффициентов DCT: опция арифметического кодирования и опция прогрессивного кодирования (которая обеспечивает более низкие битрейты, поскольку значения для каждого коэффициента кодируются независимо, и каждый коэффициент имеет существенно отличающееся распределение). Современные методы улучшили эти методы путем переупорядочивания коэффициентов для группировки коэффициентов большей величины вместе; ^[56] использования смежных коэффициентов и блоков для прогнозирования новых значений коэффициентов; ^[58] разделения блоков или коэффициентов среди небольшого числа независимо кодированных моделей на основе их статистики и смежных значений; ^{[57] [58]} и совсем недавно путем декодирования блоков, прогнозирования последующих блоков в пространственной области и последующего их кодирования для генерации прогнозов для коэффициентов DCT. ^[59]

Обычно такие методы позволяют сжимать существующие файлы JPEG на 15–25 процентов, а для файлов JPEG, сжатых с низкими настройками качества, можно добиться улучшения до 65%. ^{[58] [59]}

Свободно доступный инструмент packJPG основан на статье 2007 года «Улучшенное снижение избыточности для файлов JPEG». Начиная с версии 2.5k 2016 года, он сообщает о типичном снижении на 20% за счет транскодирования. ^[60] JPEG XL (ISO/IEC 18181) 2018 года сообщает о похожем снижении при транскодировании.

Производные форматы для стереоскопического 3D

JPEG стереоскопический

Пример стереоскопического .JPS-файла

JPS — это стереоскопическое изображение JPEG, используемое для создания 3D-эффектов из 2D-изображений. Оно содержит два статических изображения, одно для левого глаза и одно для правого глаза; закодировано как два изображения бок о бок в одном файле JPG. JPEG Stereoscopic (JPS, расширение .jps) — это основанный на JPEG формат для стереоскопических изображений. ^{[61] [62]} Он имеет ряд конфигураций, хранящихся в поле маркера JPEG APP3, но обычно содержит одно изображение двойной ширины, представляющее два изображения одинакового размера в перекрестном (т. е. левая рамка на правой половине изображения и наоборот) расположении бок о бок. Этот формат файла можно просматривать как JPEG без какого-либо специального программного обеспечения или обрабатывать для рендеринга в других режимах.

Формат JPEG Multi-Picture

JPEG Multi-Picture Format (MPO, расширение .mpo) — это основанный на JPEG формат для хранения нескольких изображений в одном файле. Он содержит два или более файлов JPEG, объединенных вместе. ^{[64] [65]} Он также определяет сегмент маркера JPEG APP2 для описания изображения. Различные устройства используют его для хранения 3D-изображений, например, 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) и Sony DSC-HX7V. Другие устройства используют его для хранения «предварительных изображений», которые можно отображать на телевизоре.

За последние несколько лет, в связи с растущим использованием стереоскопических изображений, научное сообщество приложило немало усилий для разработки алгоритмов сжатия стереоскопических изображений. ^{[66] [67]}

Реализации

Очень важной реализацией кодека JPEG является свободная программная библиотека libjpeg от Independent JPEG Group. Она была впервые опубликована в 1991 году и сыграла ключевую роль в успехе стандарта. Эта библиотека использовалась в бесчисленном количестве приложений. ^[68] Разработка затихла в 1998 году; когда libjpeg снова появился в версии 7 2009 года, она нарушила совместимость ABI с предыдущими версиями. Версия 8 2010 года представила нестандартные расширения, решение, которое критиковал первоначальный лидер IJG Том Лейн. ^[69]

libjpeg-turbo , ответвление от libjpeg 6b 1998 года, улучшает libjpeg с оптимизацией SIMD . Первоначально рассматриваемый как поддерживаемый форк libjpeg, он стал более популярным после несовместимых изменений 2009 года. ^{[70] [71]} В 2019 году он стал эталонной реализацией ITU|ISO/IEC как ISO/IEC 10918-7 и ITU-T T.873. ^[72]

ISO/IEC Joint Photography Experts Group поддерживает другую реализацию эталонного программного обеспечения под заголовком JPEG XT . Он может кодировать как базовый JPEG (ISO/IEC 10918-1 и 18477–1), так и расширения JPEG XT (ISO/IEC 18477 части 2 и 6–9), а также JPEG-LS (ISO/IEC 14495). ^[73] В 2016 году «JPEG на стероидах» был представлен как опция для эталонной реализации ISO JPEG XT. ^[74]

Существует постоянный интерес к кодированию JPEG нетрадиционными способами, которые максимизируют качество изображения для заданного размера файла. В 2014 году Mozilla создала MozJPEG из libjpeg-turbo, более медленного, но более качественного кодировщика, предназначенного для веб-изображений. ^[75] В марте 2017 года Google выпустила проект с открытым исходным кодом Guetzli , который предлагает гораздо более длительное время кодирования для меньшего размера файла (аналогично тому, что Zopfli делает для PNG и других форматов данных без потерь). ^[76]

В апреле 2024 года Google представила Jpegli — новую библиотеку кодирования JPEG, которая предлагает расширенные возможности и улучшение коэффициента сжатия на 35% при высоких настройках сжатия, при этом скорость кодирования сопоставима с MozJPEG. ^[77]

Преемники

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

JPEG-LS-файлы

Возникнув в 1993 году и опубликованный как ISO-14495-1/ITU-T.87, JPEG LS предлагает формат файла без потерь с низкой сложностью, который был более эффективен, чем исходная реализация JPEG без потерь. Он также имеет режим с потерями, близкий к режиму без потерь. Его функциональность в значительной степени ограничена этим, и в других аспектах он во многом разделяет те же ограничения исходного JPEG.

JPEG2000

JPEG 2000 был опубликован как ISO/IEC 15444 в декабре 2000 года. Он основан на дискретном вейвлет-преобразовании (DWT) и был разработан, чтобы полностью заменить исходный стандарт JPEG и превзойти его во всех отношениях. Он допускает до 38 бит на цветовой канал и 16384 каналов, больше, чем любой другой формат, с множеством цветовых пространств и, таким образом, высоким динамическим диапазоном (HDR). Кроме того, он поддерживает кодирование альфа-прозрачности, изображения размером миллиарды миллиардов пикселей, что также больше, чем любой другой формат, и сжатие без потерь. Он значительно улучшил коэффициент сжатия с потерями со значительно меньшим количеством видимых артефактов при высоких уровнях сжатия. ^[78]

JPEG-XT-формат

JPEG XT (ISO/IEC 18477) был опубликован в июне 2015 года; он расширяет базовый формат JPEG поддержкой более высоких целочисленных битовых глубин (до 16 бит), визуализации с высоким динамическим диапазоном и кодирования с плавающей точкой, кодирования без потерь и кодирования альфа-канала. Расширения обратно совместимы с базовым форматом файла JPEG/JFIF и 8-битным сжатым с потерями изображением. JPEG XT использует расширяемый формат файла на основе JFIF. Слои расширения используются для изменения 8-битного базового слоя JPEG и восстановления изображения с высоким разрешением. Существующее программное обеспечение совместимо с прямой версией и может читать двоичный поток JPEG XT, хотя оно будет декодировать только базовый 8-битный слой. ^[79]

JPEG-XL-файл

JPEG XL (ISO/IEC 18181) был опубликован в 2021–2022 годах. Он заменяет формат JPEG новым бесплатным форматом на основе DCT и обеспечивает эффективное перекодирование в качестве варианта хранения для традиционных изображений JPEG. ^[80] Новый формат разработан, чтобы превзойти производительность сжатия неподвижных изображений, показанную HEIF HM, Daala и WebP . Он поддерживает изображения размером миллиард на миллиард пикселей, до 32 бит на компонент с высоким динамическим диапазоном с соответствующими функциями передачи ( PQ и HLG ), кодирование патчей синтетических изображений, таких как растровые шрифты и градиенты, анимированные изображения, кодирование альфа-канала и выбор цветового кодирования RGB/YCbCr/ ICtCp . ^{[81] [82] [83] [84]}

Смотрите также

• АВИФ
• Better Portable Graphics — формат, основанный на внутрикадровом кодировании HEVC.
• C-Cube , один из первых разработчиков JPEG в виде чипа
• Сравнение форматов графических файлов
• Фильтр деблокирования (видео) , аналогичные методы деблокирования можно применить к JPEG
• Правило проектирования файловой системы камеры (DCF)
• FELICS , кодек изображений без потерь
• Расширения файлов
• Программа для редактирования графики
• Высокоэффективный формат файла изображения , формат контейнера изображений для HEVC и других форматов кодирования изображений
• Ленна (тестовое изображение) — традиционное стандартное изображение, используемое для тестирования алгоритмов обработки изображений.
• Движение JPEG
• ВебП

Ссылки

1. "T.81 – ЦИФРОВОЕ СЖАТИЕ И КОДИРОВАНИЕ НЕПРЕРЫВНЫХ ТОНАЛЬНЫХ ИЗОБРАЖЕНИЙ – ТРЕБОВАНИЯ И РУКОВОДСТВО" (PDF) . CCITT . Сентябрь 1992 г. Архивировано (PDF) из оригинала 30 декабря 2019 г. . Получено 12 июля 2019 г. .
2. "Определение "JPEG"". Collins English Dictionary . Архивировано из оригинала 21 сентября 2013 года . Получено 23 мая 2013 года .
3. Haines, Richard F.; Chuang, Sherry L. (1 июля 1992 г.). Влияние сжатия видео на приемлемость изображений для мониторинга экспериментов в области естественных наук (технический отчет). NASA . NASA-TP-3239, A-92040, NAS 1.60:3239 . Получено 13 марта 2016 г. Уровни сжатия неподвижных изображений JPEG, даже с большим диапазоном от 5:1 до 120:1 в этом исследовании, дали одинаково высокие уровни приемлемости.
4. Хадсон, Грэм; Леже, Ален; Нисс, Биргер; Себастьен, Иштван; Ваабен, Йорген (31 августа 2018 г.). «Стандарту JPEG-1 25 лет: причины успеха в прошлом, настоящем и будущем». Журнал электронных изображений . 27 (4): 1. doi : 10.1117/1.JEI.27.4.040901 . S2CID  52164892.
5. Светлик, Джо (31 мая 2018 г.). «Объяснение формата изображения JPEG». BT.com . BT Group . Архивировано из оригинала 5 августа 2019 г. . Получено 5 августа 2019 г. .
6. Баранюк, Крис (15 октября 2015 г.). «Защита от копирования может появиться в JPEG». BBC News . BBC . Архивировано из оригинала 9 октября 2019 г. . Получено 13 сентября 2019 г. .
7. Тринквальдер, Андреа (7 октября 2016 г.). «JPEG: 25 Jahre und kein bisschen alt» [JPEG: 25 лет (старше) и ни капельки не стар). de:Heise онлайн (на немецком языке). Архивировано из оригинала 5 сентября 2019 года . Проверено 5 сентября 2019 г.
8. Каплан, Пол (24 сентября 2013 г.). «Что такое JPEG? Невидимый объект, который вы видите каждый день» . The Atlantic . Архивировано из оригинала 9 октября 2019 г. Получено 13 сентября 2019 г.
9. "Архив HTTP – Интересная статистика". httparchive.org . Получено 6 апреля 2016 г. .
10. «Определение типа MIME в Internet Explorer». Microsoft. 13 июля 2016 г. Архивировано из оригинала 30 октября 2022 г. Получено 2 ноября 2022 г.
11. "Формат обмена файлами JPEG" (PDF) . 3 сентября 2014 г. Архивировано из оригинала 3 сентября 2014 г. Получено 16 октября 2017 г.{{cite web}}: CS1 maint: bot: original URL status unknown (link)
12. «Почему JPEG 2000 никогда не взлетал». Американский национальный институт стандартов . 10 июля 2018 г. Архивировано из оригинала 16 декабря 2018 г. Получено 13 сентября 2019 г.
13. Лемос, Роберт (23 июля 2002 г.). «Поиск патентной истины в иске JPEG». CNET . Архивировано из оригинала 13 июля 2019 г. Получено 13 июля 2019 г.
14. ISO/IEC JTC 1/SC 29 (7 мая 2009 г.). "ISO/IEC JTC 1/SC 29/WG 1 – Кодирование неподвижных изображений (структура SC 29/WG 1)". Архивировано из оригинала 31 декабря 2013 г. Получено 11 ноября 2009 г.{{cite web}}: CS1 maint: numeric names: authors list (link)
15. ISO/IEC JTC 1/SC 29. "Programme of Work, (Allocated to SC 29/WG 1)". Архивировано из оригинала 31 декабря 2013 г. Получено 7 ноября 2009 г.{{cite web}}: CS1 maint: numeric names: authors list (link)
16. ISO. "JTC 1/SC 29 – Кодирование аудио, изображений, мультимедиа и гипермедиа информации". Архивировано из оригинала 3 июля 2010 года . Получено 11 ноября 2009 года .
17. JPEG. "Joint Photographic Experts Group, JPEG Homepage". Архивировано из оригинала 27 сентября 2009 года . Получено 8 ноября 2009 года .
18. "T.81: Информационные технологии – Цифровое сжатие и кодирование неподвижных изображений с непрерывным тоном – Требования и рекомендации". Itu.int . Архивировано из оригинала 6 ноября 2012 г. Получено 7 ноября 2009 г.
19. Уильям Б. Пеннебейкер; Джоан Л. Митчелл (1993). Стандарт сжатия данных неподвижных изображений JPEG (3-е изд.). Springer. стр. 291. ISBN 978-0-442-01272-4.
20. ISO. "JTC 1/SC 29 – Кодирование аудио, изображений, мультимедиа и гипермедиа информации". Архивировано из оригинала 3 июля 2010 года . Получено 7 ноября 2009 года .
21. "SPIFF, Still Picture Interchange File Format". Библиотека Конгресса . 30 января 2012 г. Архивировано из оригинала 31 июля 2018 г. Получено 31 июля 2018 г.
22. JPEG (24 апреля 2009 г.). "JPEG XR получает статус FDIS: формат обмена файлами JPEG (JFIF) будет стандартизирован как JPEG Часть 5" (пресс-релиз). Архивировано из оригинала 8 октября 2009 г. Получено 9 ноября 2009 г.
23. "Формат обмена файлами JPEG (JFIF)". ECMA TR/98 1-е изд . Ecma International . 2009. Архивировано из оригинала 14 января 2021 г. Получено 1 августа 2011 г.
24. "Патент Forgent's JPEG". SourceForge . 2002. Архивировано из оригинала 13 мая 2019 г. Получено 13 июля 2019 г.
25. "Относительно недавних патентных претензий". Jpeg.org . 19 июля 2002 г. Архивировано из оригинала 14 июля 2007 г. Получено 29 мая 2011 г.
26. "JPEG и JPEG2000 – между патентным спором и сменой технологий". Архивировано из оригинала 17 августа 2004 года . Получено 16 апреля 2017 года .{{cite web}}: CS1 maint: bot: original URL status unknown (link)
27. Кавамото, Дон (22 апреля 2005 г.). «Графический патентный иск дает отпор Microsoft». Новости CNET . Архивировано из оригинала 20 января 2023 г. Получено 20 января 2023 г.
28. "Trademark Office Re-examines Forgent JPEG Patent". Publish.com . 3 февраля 2006 г. Архивировано из оригинала 15 мая 2016 г. Получено 28 января 2009 г.
29. "USPTO: Broadest Claims Forgent Asserts Against JPEG Standard Invalid". Groklaw.net . 26 мая 2006 г. Архивировано из оригинала 16 мая 2019 г. Получено 21 июля 2007 г.
30. "Coding System for Reducing Redundancy". Gauss.ffii.org . Архивировано из оригинала 12 июня 2011 . Получено 29 мая 2011 .
31. "JPEG Patent Claim Surendered". Public Patent Foundation. 2 ноября 2006 г. Архивировано из оригинала 2 января 2007 г. Получено 3 ноября 2006 г.
32. "Ex Parte Reexamination Certificate for US Patent No. 5,253,341". Архивировано из оригинала 2 июня 2008 г.
33. Рабочая группа. "Rozmanith: Использование патентов на программное обеспечение для подавления критиков". Eupat.ffii.org . Архивировано из оригинала 16 июля 2011 г. Получено 29 мая 2011 г.
34. "Награда в 5000 долларов за имя охотника за троллями: Рэй Ниро хочет знать, кто говорит о нем все эти гадости". Law.com . Архивировано из оригинала 21 ноября 2010 года . Получено 29 мая 2011 года .
35. Реймер, Джереми (5 февраля 2008 г.). «Охота на троллей: USPTO попросили пересмотреть широкий патент на изображение». Arstechnica.com . Архивировано из оригинала 8 декабря 2008 г. Получено 29 мая 2011 г.
36. Патентное ведомство США – Разрешение на повторную экспертизу 5,253,341 C1
37. "Судья заморозил патент JPEG". Techdirt.com . 30 апреля 2008 г. Архивировано из оригинала 14 ноября 2011 г. Получено 29 мая 2011 г.
38. "Единственная заявка на патент JPEG отклонена (и повержена для верности)". Techdirt.com . 1 августа 2008 г. Архивировано из оригинала 28 ноября 2019 г. Получено 29 мая 2011 г.
39. Рабочая группа. "Домашняя страница Princeton Digital Image Corporation". Архивировано из оригинала 11 апреля 2013 года . Получено 1 мая 2013 года .
40. Рабочая группа (3 апреля 2013 г.). "Статья о решении суда Принстона относительно лицензионного соглашения GE". Архивировано из оригинала 9 марта 2016 г. Получено 1 мая 2013 г.
41. "Обзор прогрессивного декодирования". Microsoft Developer Network . Microsoft. Архивировано из оригинала 19 ноября 2012 г. Получено 23 марта 2012 г.
42. Fastvideo (май 2019). "12-битный JPEG-кодер на GPU". Архивировано из оригинала 6 мая 2019 года . Получено 6 мая 2019 года .
43. «Почему всегда следует вращать исходные фотографии JPEG без потерь». Petapixel.com . 14 августа 2012 г. Архивировано из оригинала 17 октября 2017 г. Получено 16 октября 2017 г.
44. "Формат файла JFIF как PDF" (PDF) . Архивировано (PDF) из оригинала 13 января 2021 г. . Получено 19 июня 2006 г. .
45. Том Лейн (29 марта 1999 г.). "Часто задаваемые вопросы о сжатии изображений JPEG". Архивировано из оригинала 10 ноября 2010 г. Получено 11 сентября 2007 г.(вопрос 14: «К чему все эти споры о форматах файлов?»)
46. "Все, что вам нужно знать о файлах JPEG | Adobe". www.adobe.com . Получено 18 августа 2023 г. .
47. "Стандартное цветовое пространство по умолчанию для Интернета - sRGB". www.w3.org . Архивировано из оригинала 18 февраля 2022 г. Получено 18 февраля 2022 г.
48. "IEC 61966-2-1:1999/AMD1:2003 | IEC Webstore". webstore.iec.ch . Архивировано из оригинала 18 февраля 2022 г. Получено 18 февраля 2022 г.
49. "ISO/IEC 10918-1: 1993(E) p.36". Архивировано из оригинала 1 августа 2011 г. Получено 30 ноября 2007 г.
50. Томас Г. Лейн. "Расширенные возможности: выбор параметров сжатия". Использование библиотеки IJG JPEG . Архивировано из оригинала 26 ноября 2001 г. Получено 8 октября 2008 г.
51. Райан, Дэн (20 июня 2012 г.). E - Учебные модули: Dlr Associates Series. AuthorHouse. ISBN 978-1-4685-7520-0.
52. "DC / AC Frequency Questions - Doom9's Forum". forum.doom9.org . Архивировано из оригинала 17 октября 2017 . Получено 16 октября 2017 .
53. Phuc-Tue Le Dinh и Jacques Patry. Артефакты сжатия видео и шумоподавление MPEG Архивировано 14 марта 2006 г. на Wayback Machine . Video Imaging DesignLine. 24 февраля 2006 г. Получено 28 мая 2009 г.
54. " 3.9 шум комара: Форма искажения краевой загруженности, иногда связанная с движением, характеризующаяся движущимися артефактами и/или неоднородными шумовыми узорами, наложенными на объекты (напоминающие комара, летающего вокруг головы и плеч человека)". Рекомендация МСЭ-Т P.930 (08/96) Принципы системы эталонных искажений для видео Архивировано 16.02.2010 на Wayback Machine
55. Julià Minguillón, Jaume Pujol (апрель 2001 г.). «Моделирование ошибок равномерного квантования стандарта JPEG с приложениями к последовательным и прогрессивным режимам работы» (PDF) . Electronic Imaging . 10 (2): 475–485. Bibcode :2001JEI....10..475M. doi :10.1117/1.1344592. hdl :10609/6263. S2CID  16629522. Архивировано (PDF) из оригинала 3 августа 2020 г. . Получено 23 сентября 2019 г. .
56. I. Bauermann и E. Steinbacj. Дальнейшее сжатие изображений JPEG без потерь. Proc. of Picture Coding Symposium (PCS 2004), Сан-Франциско, США, 15–17 декабря 2004 г.
57. Н. Пономаренко, К. Егиазарян, В. Лукин и Дж. Астола. Дополнительное сжатие изображений JPEG без потерь, Труды 4-го Международного симпозиума по обработке и анализу изображений и сигналов (ISPA 2005), Загреб, Хорватия, стр. 117–120, 15–17 сентября 2005 г.
58. М. Штирнер и Г. Зеелманн. Улучшенное снижение избыточности для файлов JPEG. Труды Симпозиума по кодированию изображений (PCS 2007), Лиссабон, Португалия, 7–9 ноября 2007 г.
59. Ичиро Мацуда, Юкио Номото, Кей Вакабаяши и Сусуму Ито. Перекодирование изображений JPEG без потерь с использованием блочно-адаптивного внутрикадрового предсказания. Труды 16-й Европейской конференции по обработке сигналов (EUSIPCO 2008).
60. Штирнер, Маттиас (19 февраля 2023 г.). "packjpg/packJPG". GitHub . Архивировано из оригинала 2 марта 2023 г. . Получено 2 марта 2023 г. .
61. J. Siragusa; DC Swift (1997). "Универсальный дескриптор стереоскопических данных" (PDF) . VRex, Inc., Элмсфорд, Нью-Йорк, США . Архивировано из оригинала (PDF) 30 октября 2011 г.
62. Тим Кемп, файлы JPS, архив 2009-01-18 на Wayback Machine
63. "CGImageSource.SupportedTypes". Плагин Claris FileMaker MBS . Программное обеспечение MonkeyBread. Архивировано из оригинала 30 декабря 2020 г. Получено 21 мая 2023 г.
64. "Multi-Picture Format" (PDF) . 2009. Архивировано из оригинала (PDF) 5 апреля 2016 года . Получено 30 декабря 2015 года .
65. "MPO2Stereo: Преобразование файлов Fujifilm MPO в стереопары JPEG", Mtbs3d.com , заархивировано из оригинала 31 мая 2010 г. , извлечено 12 января 2010 г.
66. Алессандро Ортис; Себастьяно Баттиато (2015), Ситник, Роберт; Пьюч, Уильям (ред.), "Новый быстрый метод сопоставления для адаптивного сжатия стереоскопических изображений", Обработка трехмерных изображений , Обработка трехмерных изображений, Измерение (3DIPM), и приложения 2015, 9393 , SPIE - Обработка трехмерных изображений, Измерение (3DIPM), и приложения 2015: 93930K, Bibcode : 2015SPIE.9393E..0KO, doi : 10.1117/12.2086372, S2CID  18879942, архивировано из оригинала 3 марта 2016 г. , извлечено 30 апреля 2015 г.
67. Алессандро Ортис; Франческо Рундо; Джузеппе Ди Джоре; Себастьяно Баттиато, Адаптивное сжатие стереоскопических изображений, Международная конференция по анализу и обработке изображений (ICIAP) 2013, архивировано из оригинала 3 марта 2016 г. , извлечено 30 апреля 2015 г.
68. "Обзор JPEG". jpeg.org . Архивировано из оригинала 21 октября 2017 г. Получено 16 октября 2017 г.
69. Том Лейн, 16 января 2013 г.: jpeg-9, совместимость API/ABI и будущая роль этого проекта. Архивировано 04.12.2018 на Wayback Machine.
70. Программное обеспечение, использующее или предоставляющее libjpeg-turbo Архивировано 18.03.2017 на Wayback Machine . 9 февраля 2012 г.
71. Проблема 48789 – chromium – Используйте libjpeg-turbo вместо libjpeg Архивировано 01.08.2015 на Wayback Machine . 14 апреля 2011 г.
72. "ISO/IEC 10918-7: 2019 Информационные технологии. Цифровое сжатие и кодирование неподвижных изображений с непрерывным тоном. Часть 7. Справочное программное обеспечение". ISO . Архивировано из оригинала 7 мая 2022 г. . Получено 7 мая 2022 г. ."T.873 (05/19): Информационные технологии - Цифровое сжатие и кодирование неподвижных изображений с непрерывным тоном: Справочное программное обеспечение". www.itu.int . Архивировано из оригинала 2 июня 2022 г. . Получено 1 марта 2023 г. .
73. "JPEG - JPEG XT". jpeg.org . Архивировано из оригинала 4 марта 2018 года . Получено 3 марта 2018 года .
74. Рихтер, Томас (сентябрь 2016 г.). «JPEG на СТЕРОИДАХ: общие методы оптимизации для сжатия изображений JPEG». Международная конференция IEEE по обработке изображений (ICIP) 2016 г. стр. 61–65. doi :10.1109/ICIP.2016.7532319. ISBN 978-1-4673-9961-6. S2CID  14922251.
75. «Представляем проект 'mozjpeg'». Mozilla Research . 5 марта 2014 г. Архивировано из оригинала 1 марта 2023 г. Получено 1 марта 2023 г.
76. "Представляем Guetzli: новый кодировщик JPEG с открытым исходным кодом". Research.googleblog.com . 16 марта 2017 г. Архивировано из оригинала 6 октября 2017 г. Получено 16 октября 2017 г.
77. "Представляем Jpegli: новую библиотеку кодирования JPEG". Блог Google Open Source. 3 апреля 2024 г. Архивировано из оригинала 3 апреля 2024 г. Получено 4 апреля 2024 г.
78. Снейерс, Джон (22 февраля 2021 г.). «Пора заменить JPEG на кодек изображений следующего поколения». Cloudinary . Получено 14 ноября 2023 г. .
79. "JPEG - JPEG XT". jpeg.org . Архивировано из оригинала 4 марта 2018 года . Получено 3 марта 2018 года .
80. Алакуйала, Юрки; ван Ассельдонк, Рууд; Букортт, Сами; Брюс, Мартин; Комша, Юлия-Мария; Фиршинг, Мориц; Фишбахер, Томас; Ключников Евгений; Гомес, Себастьян; Обрик, Роберт; Потемпа, Кшиштоф; Ратушняк, Александр; Снейерс, Джон; Шабадка, Золтан; Вандервенн, Лоде; Версари, Лука; Вассенберг, январь (6 сентября 2019 г.). «Архитектура сжатия изображений нового поколения и инструменты кодирования JPEG XL». В Тешере, Эндрю Г; Эбрахими, Турадж (ред.). Применение цифровой обработки изображений XLII . Том. 11137. с. 20. Бибкод : 2019SPIE11137E..0KA. doi : 10.1117/12.2529237. ISBN 978-1-5106-2967-7. S2CID  202785129. Архивировано из оригинала 26 декабря 2021 г. . Получено 26 декабря 2021 г. .
81. Ратушняк, Александр; Вассенберг, Ян; Снейерс, Джон; Алакуйала, Юрки; Вандевенн, Лоде; Версари, Лука; Обрик, Роберт; Шабадка, Золтан; Ключников Евгений; Комса, Юлия-Мария; Потемпа, Кшиштоф; Брюс, Мартин; Фиршинг, Мориц; Хасанова Рената; Рууд ван Ассельдонк; Букортт, Сами; Гомес, Себастьян; Фишбахер, Томас (2019). «Проект комитета системы кодирования изображений JPEG XL». arXiv : 1908.03565 [eess.IV].
82. "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) . Архивировано (PDF) из оригинала 31 октября 2022 г. . Получено 29 мая 2018 г. .
83. ISO/IEC 18181-1:2022 Информационные технологии. Система кодирования изображений JPEG XL. Часть 1. Основная система кодирования.
84. ISO/IEC 18181-2:2021 Информационные технологии. Система кодирования изображений JPEG XL. Часть 2. Формат файла.

Внешние ссылки

• Официальный сайт
• Стандарт JPEG (JPEG ISO/IEC 10918-1 Рекомендация ITU-T T.81) на W3.org
• Формат файла JFIF на W3.org
• Примеры изображений по всему диапазону уровней квантования от 1 до 100 на сайте visangi.com
• Открытый исходный код декодера JPEG, авторское право (C) 1995–1997, Thomas G. Lane