JPEG

JPEG Multi-Picture
Расширение имени файла	.потому что
Идентификатор единого типа (UTI)	public.mpo-Image

Внешнее изображение
Внешнее изображение
	Иллюстрация края занятости

JPEG
	Фотография европейской дикой кошки с скоростью сжатия и связанных с ними потерь, уменьшаясь слева направо
Расширение имени файла	.jpg, .jpeg, .jpe; .jif, .jfif, .jfi
Интернет -медиа -тип	Изображение/JPEG
Тип кода	JPEG
Идентификатор единого типа (UTI)	public.jpeg
Магическое число	ff d8 ff
Разработан	Объединенные экспертные эксперты , IBM , Mitsubishi Electric , AT & T , Canon Inc.
Первоначальный выпуск	18 сентября 1992 г .; 31 год назад
Тип формата	с потерей сжатия изображений Формат
Распространяется на	JPEG 2000
Стандартный	ISO / IEC 10918, ITU-T T.81, ITU-T T.83, ITU-T T.84, ITU-T T.86
Веб -сайт	JPEG .орг /jpeg /

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

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

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

Тип MIME Media для 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 ) и совместных фотографических экспертов. ^{[ 1 ]}

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

IBM
- США Петент 4 652 856-4 , 4, 1986-Котпппурам, май Мохиуддин и Джорма Дж. Риссанен -Многопользовательский арифический код без мультипейки.
- Патент США 4 905 297 - 27 февраля 1990 г. - Г. Лэнгдон, Дж. Л. Митчелл , WB Pennebaker, и Jorma J. Rissanen - кодер кодировщика арифметического кодера и декодера
- Патент США 4 935 882 - 19 июня 1990 г. - WB Pennebaker и JL Mitchell - вероятность адаптации для арифметических кодеров
Mitsubishi Electric
- JP H02202267 ( 1021672 ) - 21 января 1989 г. - Тошихиро Кимура, Шигенори Кино, Фумитака Оно, Масаюки Йошида - Система кодирования
- JP H03247123 ( 2-46275 )-26 февраля 1990 года-Томохиро Кимура, Шигенори Кино, Фумитака Оно и Масаюки Йошида-Кодирующий аппарат и метод кодирования

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

JPEG Стандарт

«JPEG» означает совместную группу фотографических экспертов , название комитета, который создал стандарт JPEG и другие стандарты кодирования изображений. «Сустав» стоял за 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 Объединенного технического комитета 1 , Подкомитет 29, Рабочая группа 1 ( ISO /IEC JTC 1 /SC 29 /WG 1)-под названием «Кодирование неподвижных картинок» . ^{[ 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 ]} Стандарты ESIF . и JFIF определяют обычно используемые форматы файлов для обмена изображениями, ориентированными на JPEG

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

Цифровое сжатие и кодирование непрерывных изображений-детали-детали ^{[ 15 ]}^{[ 17 ]}^{[ 20 ]}
Часть	Стандарт ISO/IEC	ITU-T rec.	Первая публичная дата выпуска	Последняя поправка	Заголовок	Описание
Часть 1	ISO/IEC 10918-1: 1994	T.81 (09/92)	18 сентября 1992		Требования и руководящие принципы
Часть 2	ISO/IEC 10918-2: 1995	T.83 (11/94)	11 ноября 1994 г.		Тестирование соответствия	Правила и проверки для соответствия программного обеспечения (часть 1).
Часть 3	ISO/IEC 10918-3: 1997	T.84 (07/96)	3 июля 1996 г.	1 апреля 1999	Расширения	Набор расширений для улучшения части 1, включая формат файла интерфейса неподвижного изображения (Spiff). ^{[ 21 ]}
Часть 4	ISO/IEC 10918-4: 2024	T.86 (06/98)	18 июня 1998		Маркеры APPN	Методы регистрации некоторых параметров, используемых для расширения JPEG
Часть 5	ISO/IEC 10918-5: 2013	T.871 (05/11)	14 мая 2011 г.		Формат интерфейса файла JPEG (JFIF)	Популярный формат, который был фактическим форматом файла для изображений, кодируемых стандартом JPEG. В 2009 году комитет JPEG официально создал специальную группу для стандартизации JFIF как JPEG Part 5. ^{[ 22 ]}
Часть 6	ISO/IEC 10918-6: 2013	T.872 (06/12)	Jun 2012		Применение к печатным системам	Определяет подмножество функций и инструментов приложений для обмена изображений, кодируемых в соответствии с ISO/IEC 10918-1 для печати.
Часть 7	ISO/IEC 10918-7: 2023	T.873 (06/21)	Май 2019	Ноябрь 2023 года	Справочное программное обеспечение	Обеспечивает справочные реализации системы базового кодирования JPEG

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

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

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

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

В период с 2002 по 2004 год Forgent смог получить около 105 миллионов долларов США, лицензируя свой патент около 30 компаний. В апреле 2004 года Forgent подал в суд на 31 компанию на обеспечение дополнительных лицензионных платежей. В июле того же года консорциум из 21 крупных компьютерных компаний подал контактный костюм с целью аннулирования патента. Кроме того, Microsoft рассказала об отдельном судебном процессе против Forgent в апреле 2005 года. ^{[ 27 ]} В феврале 2006 года Управление по патентам и товарным знакам Соединенных Штатов согласилось пересмотреть патент JPEG Forgent по просьбе государственного патентного фонда. ^{[ 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 года патентное управление отменило все первоначальные претензии патента, но установило, что дополнительное требование, предложенное глобальными патентными владениями (претензии 17), было действительным. ^{[ 32 ]} Глобальные патентные активы затем подали ряд судебных процессов, основанных на иске 17 его патента.

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

Global Patent Holdings также использовал патент 341 для предъявления иска или угрожать откровенным критикам патентов на широкие программные материалы, в том числе Грегори Ахарониан ^{[ 33 ]} и анонимный оператор блога веб -сайта, известный как « Трекер Patent Troll ». ^{[ 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 . Принстон утверждает, что стандарт сжатия изображения JPEG нарушает патент 056 и подал в суд на большое количество веб -сайтов, розничных продавцов, производителей камеры и устройств и посредников. Патент первоначально принадлежал и назначен в General Electric. Патент истек в декабре 2007 года, но Принстон подал в суд на большое количество компаний за «прошлое нарушение» этого патента. (Согласно американским законам о патентах, владелец патента может подать в суд на «прошлое нарушение» до шести лет до подачи иска, чтобы Принстон теоретически мог продолжать предъявлять иск о компаниях до декабря 2013 года.) По состоянию Нью -Йорк и Делавэр против более 55 компаний. Участие General Electric в иске неизвестно, хотя судебные протоколы указывают на то, что он назначил патент в Принстон в 2009 году и сохраняет определенные права в патенте. ^{[ 40 ]}

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

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

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

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

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

JPEG сжатие

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

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

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

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

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

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

Jpegtran и его графический интерфейс, jpegcrop.
Irfanview с использованием «JPG без потерь (плагин)» и «jpg -потерь вращение (плагин)», которые требуют установки плагина JPG_TRANSFORM.
Faststone Image Viewer использует «Crop To For To File» и «jpeg без потерь вращения».
Xnviewmp Использование "JPEG без потерь трансформации".
ACDSEE поддерживает без потерь вращение (но не без потерь) с вариантом «Операции без потерь JPEG».

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

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

Вращения, где изображение не равно 8 или 16, что зависит от подмены хрома, не являются потерей. Вращение такого изображения приводит к повторному рассчитанию блоков, что приводит к потере качества. ^{[ 43 ]}

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

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

Файлы JPEG

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

Цветовое определение
Компонентная регистрация подмножества
Определение соотношения сторон пикселя.

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

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

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

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

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

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

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

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

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

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

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

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

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

Обычные маркеры JPEG ^{[ 49 ]}
Короткое имя	Байты	Полезная нагрузка	Имя	Комментарии
СЕБЯ	0xff, 0xd8	никто	Начало изображения
SOF0	0xff, 0xc0	переменный размер	Начало кадра (базовый DCT )	Указывает, что это базовый JPEG на основе DCT, и определяет ширину, высоту, количество компонентов и компонентную субмплинг (например, 4: 2: 0).
SOF2	0xff, 0xc2	переменный размер	Начало кадра (прогрессивный DCT)	Указывает, что это прогрессивный JPEG на основе DCT, и определяет ширину, высоту, количество компонентов и компонентную подгрупп (например, 4: 2: 0).
DHT	0xff, 0xc4	переменный размер	Определить таблицы (ы) Хаффмана	Определяет один или несколько таблиц Хаффмана.
Дкт	0xff, 0xdb	переменный размер	Определите таблицу (ы) квантования	Определяет одну или несколько таблиц квантования.
Дри	0xff, 0xdd	4 байта	Определите интервал перезапуска	Определяет интервал между первыми n маркерами, в минимальных кодированных единицах (MCU). За этим маркером следует два байта, указывающих на фиксированный размер, поэтому его можно обрабатывать как любой другой сегмент размера переменной.
SOS	0xff, 0xda	переменный размер	Начало сканирования	Начинается сканирование изображения с верхней до двойной. В базовых изображениях DCT JPEG обычно есть одно сканирование. Прогрессивные изображения DCT JPEG обычно содержат несколько сканов. В этом маркере указывается, какой срез данных он будет содержать, и сразу же сопровождается кодированными энтропийными данными.
Rst n	0xff, 0xd n ( n = 0..7)	никто	Перезапуск	Вставлены все R макроблки , где r - интервал перезапуска, установленным маркером DRI. Не используется, если не было маркера DRI. Низкие три бита цикла кода маркера в значении от 0 до 7.
Приложение	0xff, 0xe n	переменный размер	Специфичный для приложения	Например, в файле ESIF JPEG используется маркер APP1 для хранения метаданных, изложенных в структуре, основанной на TIFF .
С	0xff, 0xfe	переменный размер	Комментарий	Содержит текстовый комментарий.
Eoi	0xff, 0xd9	никто	Конец изображения

Есть и другие начальные маркеры, которые вводят другие виды кодировки JPEG.

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

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

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

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

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

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

Кодирование

Многие из вариантов в стандарте JPEG не используются, и, как упоминалось выше, большинство программного обеспечения Image использует более простой формат 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 (называемое « снижение » или « подмножество Chroma »). Соотношения, при которых снижение, обычно выполняемое для изображений JPEG, составляют 4: 4: 4 (без снижения дискретизации), 4: 2: 2 (сокращение в 2 раза в горизонтальном направлении) или (чаще всего) 4: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 2: 0 (сокращение в 2 раза как в горизонтальных, так и в вертикальных направлениях). Для остальной части процесса сжатия Y ', CB и CR обрабатываются отдельно и очень похожим образом.

Блок -расщепление

После подгруппирования каждый канал должен быть разделен на блоки 8 × 8. В зависимости от подмены хрома, эта минимальная кодированная блока (MCU) размером 8 × 8 (4: 4: 4 - без подгруппа), 16 × 8 (4: 2: 2) или чаще всего 16 × 16 (4: 4: 2: 0). В видео сжатие называются макроблоксовыми .

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

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

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

В качестве примера, одним из таких 8-битных субимеров 8 × 8 может быть:

\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-битного изображения каждая запись в исходном блоке падает в диапазоне $[0,255]$ Полем Средняя точка диапазона (в данном случае значение 128) вычитается из каждой записи для получения диапазона данных, который сосредоточен на нуле, так что измененный диапазон $[-128,127]$ Полем Этот шаг уменьшает требования динамического диапазона на следующей стадии обработки DCT.

Этот шаг приводит к следующим значениям:

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 , а выходные значения называются *коэффициентами преобразования* . Горизонтальный индекс $u$ и вертикальный индекс $v$ .

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

\ 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]

где

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

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

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.

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

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

Квантование

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

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

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 вычисляются с помощью

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

где $G$ это неквалифицированные коэффициенты DCT; $Q$ это матрица квантования выше; и $B$ это квантованные коэффициенты DCT.

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

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

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) и округление до ближайшего целого числа

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

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

Кодирование энтропии

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

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

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

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

−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

Если i -й блок представлен $B_{i}$ и позиции в каждом блоке представлены $(p,q)$ где $p=0,1,...,7$ и $q=0,1,...,7$ , тогда любой коэффициент на изображении DCT может быть представлен как $B_{i}(p,q)$ Полем Таким образом, в приведенной выше схеме порядок кодирования пикселей (для $блока i$ -th) является $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)$ и так далее.

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

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

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

Процесс кодирования Zig-ZAG Квантовых данных начинается с кодирования длины прогона, описанного ниже, где:

$X$ -ненулевой, квантованный коэффициент переменного тока.
Длина Runlene -это количество нулей, которые были до этого ненулевого коэффициента AC.
Размер - это количество битов, необходимых для представления $x$ .
Амплитуда -это битовая представленность $x$ .

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

Символ 1	Символ 2
(Runlength, размер)	(Амплитуда)

Как длина , так и размер опираются на один и тот же байт, что означает, что каждый содержит только четыре бита информации. Более высокие биты имеют дело с количеством нулей, в то время как более низкие биты обозначают количество битов, необходимых для кодирования значения $x$ .

Это имеет непосредственное значение того, что символ 1 способен хранить только информацию о первых 15 нулей, предшествующих ненулевым коэффициенту AC. Тем не менее, JPEG определяет два специальных кодовых слова Хаффмана. Одним из них является преждевременное прекращение последовательности, когда оставшиеся коэффициенты равны нулю (называется «конец блока» или «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; оно не кодируется одинаково. См. Выше.)

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

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

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

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

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

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

Изображение	Сжатие без потерь	Сжатие с потерями
Оригинал
Обрабатывается Ханкий детектор края

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

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

Декодирование

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

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

\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]

и привлечение продукта для входа с матрицей квантования с вышеупомянутых

\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 для верхней левой части.

Следующим шагом является принятие двухмерного обратного DCT (2D типа III DCT), который дается:

$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]$

где

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

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

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

\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 к каждой записи

\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].

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

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

\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 значений на пиксели (т.е. ${\frac {1}{64}}\sum _{x=0}^{7}\sum _{y=0}^{7}|e(x,y)|=4.8750$ ).

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

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

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

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

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

Образец фотографий

Для получения информации, несомненное 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 ]}

Примечание. Приведенные выше изображения не являются IEEE / CCIR / EBU тестовыми изображениями , а настройки энкодера не указаны или не доступны.
Качество	Размер (байты)	Коэффициент сжатия	Комментарий
Самое высокое качество (Q = 100)	81,447	2.7:1	Чрезвычайно незначительные артефакты
Высокое качество (Q = 50)	14,679	15:1	Первоначальные признаки артефактов Subimage
Среднее качество (Q = 25)	9,407	23:1	Более сильные артефакты; потеря высокочастотной информации
Низкое качество (Q = 10)	4,787	46:1	Тяжелые высокочастотные потери приводят к очевидным артефактам на границах субмонтажа («макроблоккинг»)
Самое низкое качество (Q = 1)	1,523	144:1	Крайняя потеря цвета и деталей; Листья почти неузнаваемы.

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

Без потерь дальнейшее сжатие

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

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

Корреляции между величинами смежных коэффициентов в одном блоке;
Корреляции между величинами того же коэффициента в соседних блоках;
Корреляции между величинами одного и того же коэффициента/блока в разных каналах;
Коэффициенты постоянного тока, когда они взяты вместе, напоминают пониженную версию исходного изображения, умноженного на коэффициент масштабирования. Можно применять хорошо известные схемы для кодирования непрерывных изображений, достигнув, достигая несколько лучшего сжатия, чем кодированный Huffman, 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, endension .jps)-это формат на основе JPEG для стереоскопических изображений. ^{[ 61 ]}^{[ 62 ]} Он имеет ряд конфигураций, хранящихся в поле маркера JPEG APP3, но обычно содержит одно изображение двойной ширины, представляющее два изображения идентичного размера в кроссзазме по сравнению с расположением. Этот формат файла можно рассматривать как JPEG без какого -либо специального программного обеспечения или может быть обработан для рендеринга в других режимах.

JPEG Многократный формат

Multi-Picture Format JPEG (MPO, Extension .mpo)-это формат на основе JPEG для хранения нескольких изображений в одном файле. Он содержит два или более файлов JPEG, объединенных вместе. ^{[ 64 ]}^{[ 65 ]} Он также определяет сегмент маркера JPEG APP2 для описания изображения. Различные устройства используют его для хранения трехмерных изображений, таких как Fujifilm FinePix Real 3D W1 , HTC Evo 3D , JVC GY-HMZ1U AVCHD/MVC DEVENSENTION CAMORD, Nintendo 3DS , Panasonic Lumix DMC-TZ20 , DMC-TZ30, DMC-TZ60, DMC-DMC20, DMC-TZ30 , DMC-TZ60 , DMC TS4 (FT4) и Sony DSC-HX7V. Другие устройства используют его для хранения «предварительных изображений», которые могут отображаться на телевизоре.

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

Реализации

Очень важной реализацией кодека JPEG является бесплатная библиотека программирования Libjpeg независимой группы JPEG. Впервые он был опубликован в 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 поддерживает другую реализацию программного обеспечения в заголовке 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 в других аспектах.

JPEG 2000

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-битного на компонентный диапазон с соответствующими динамический Он поддерживает высокий передача Кодирование и выбор кодирования цвета RGB/ YCBCR/ ICTCP . ^{[ 81 ]}^{[ 82 ]}^{[ 83 ]}^{[ 84 ]}

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

Пути
Лучшая портативная графика , формат, основанный на кодировании внутрикарнировки HEVC
C-Cube , ранний исполнитель JPEG в форме чипа
Сравнение форматов графики
Фильтр деблокирующего (видео) , аналогичные методы деблокирования могут быть применены к JPEG
Правило проектирования для файловой системы камеры (DCF)
Felics , кодек изображения без потерь
Расширения файлов
Программа редактирования графика
Формат файла изображений с высокой эффективностью , формат контейнеров изображений для HEVC и другие форматы кодирования изображений
Ленна (тестовое изображение) , традиционное стандартное изображение, используемое для тестирования алгоритмов обработки изображений
Движение JPEG
Webp

Ссылки

^ Jump up to: ^а ^{беременный} ^в ^{дюймовый} ^и «T.81-Цифровое сжатие и кодирование непрерывных тональных изображений-требования и рекомендации» (PDF) . Ccitt . Сентябрь 1992 г. Архивировал (PDF) из оригинала 30 декабря 2019 года . Получено 12 июля 2019 года .
^ "Определение" JPEG " " . Коллинз английский словарь . Архивировано из оригинала 21 сентября 2013 года . Получено 23 мая 2013 года .
^ Хейнс, Ричард Ф.; Чуан, Шерри Л. (1 июля 1992 г.). Влияние сжатия видео на приемлемость изображений для мониторинга экспериментов по наукам о жизни (технический отчет). НАСА . NASA-TP-3239, A-92040, NAS 1,60: 3239 . Получено 13 марта 2016 года . Уровни JPEG по-прежнему подвергаются изображению, даже с большим диапазоном от 5: 1 до 120: 1 в этом исследовании, дали одинаково высокие уровни приемлемости
^ Jump up to: ^а ^{беременный} Хадсон, Грэм; Легер, Ален; Нисс, Биргер; Sebestyén, István; Ваабен, Джёрген (31 августа 2018 г.). «JPEG-1 Стандарт 25 лет: прошлые, настоящие и будущие причины успеха» . Журнал электронной визуализации . 27 (4): 1. DOI : 10.1117/1.JEI.27.4.040901 . S2CID 52164892 .
^ Светлик, Джо (31 мая 2018 г.). «Формат изображения JPEG объяснил» . Bt.com . BT Group . Архивировано из оригинала 5 августа 2019 года . Получено 5 августа 2019 года .
^ Бараниюк, Крис (15 октября 2015 г.). «Защита копирования может прийти к JPEGS» . BBC News . Би -би -си . Архивировано с оригинала 9 октября 2019 года . Получено 13 сентября 2019 года .
^ Trinkwalder, Andrea (7 октября 2016 года). «JPEG: 25 лет и не немного старый» [JPEG: 25 лет (старый) и не немного старый]. DE: Heise Online (на немецком языке). Архивировано с оригинала 5 сентября 2019 года . Получено 5 сентября 2019 года .
^ Каплан, Пол (24 сентября 2013 г.). «Что такое JPEG? Невидимый объект, который вы видите каждый день» . Атлантика . Архивировано с оригинала 9 октября 2019 года . Получено 13 сентября 2019 года .
^ «Архив http - интересная статистика» . httparchive.org . Получено 6 апреля 2016 года .
^ «Обнаружение типа MIME в Internet Explorer» . Microsoft. 13 июля 2016 года. Архивировано с оригинала 30 октября 2022 года . Получено 2 ноября 2022 года .
^ «Формат обмена файла JPEG» (PDF) . 3 сентября 2014 года. Архивировано с оригинала 3 сентября 2014 года . Получено 16 октября 2017 года . {{cite web}}: CS1 Maint: Bot: исходный статус URL неизвестен ( ссылка )
^ «Почему JPEG 2000 никогда не взлетел» . Американский национальный институт стандартов . 10 июля 2018 года. Архивировано с оригинала 16 декабря 2018 года . Получено 13 сентября 2019 года .
^ Jump up to: ^а ^{беременный} ^в ^{дюймовый} Лемос, Роберт (23 июля 2002 г.). «Поиск патентной истины в JPEG претендует» . CNET . Архивировано с оригинала 13 июля 2019 года . Получено 13 июля 2019 года .
^ 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: числовые имена: список авторов ( ссылка )
^ Jump up to: ^а ^{беременный} ISO/IEC JTC 1/SC 29. «Программа работы, (выделена на SC 29/WG 1)» . Архивировано из оригинала 31 декабря 2013 года . Получено 7 ноября 2009 года . {{cite web}}: CS1 Maint: числовые имена: список авторов ( ссылка )
^ Iso. «JTC 1/SC 29 - Кодирование информации аудио, картины, мультимедиа и гипермедиа» . Архивировано из оригинала 3 июля 2010 года . Получено 11 ноября 2009 года .
^ Jump up to: ^а ^{беременный} JPEG. «Совместная группа фотографических экспертов, домашняя страница JPEG» . Архивировано из оригинала 27 сентября 2009 года . Получено 8 ноября 2009 года .
^ «T.81: Информационные технологии-цифровое сжатие и кодирование непрерывных тональных изображений-требования и рекомендации» . ItU.int . Архивировано с оригинала 6 ноября 2012 года . Получено 7 ноября 2009 года .
^ Уильям Б. Пеннебейкер; Джоан Л. Митчелл (1993). JPEG по -прежнему Стандарт сжатия данных изображения (3 -е изд.). Спрингер. п. 291. ISBN 978-0-442-01272-4 .
^ Iso. «JTC 1/SC 29 - Кодирование информации аудио, картины, мультимедиа и гипермедиа» . Архивировано из оригинала 3 июля 2010 года . Получено 7 ноября 2009 года .
^ «Spiff, все еще формат файла интерфейса с изображением» . Библиотека Конгресса . 30 января 2012 года. Архивировано с оригинала 31 июля 2018 года . Получено 31 июля 2018 года .
^ JPEG (24 апреля 2009 г.). «JPEG XR входит в статус FDIS: формат обмена файлами JPEG (JFIF), который будет стандартизирован как JPEG Part 5» (пресс -релиз). Архивировано из оригинала 8 октября 2009 года . Получено 9 ноября 2009 года .
^ «Формат интерфейса файла JPEG (JFIF)» . ECMA TR/98 1 -е изд . ECMA International . 2009. Архивировано из оригинала 14 января 2021 года . Получено 1 августа 2011 года .
^ «Патент Forgent от JPEG» . Sourceforge . 2002. Архивировано из оригинала 13 мая 2019 года . Получено 13 июля 2019 года .
^ «Что касается недавних патентных претензий» . Jpeg.org . 19 июля 2002 года. Архивировано из оригинала 14 июля 2007 года . Получено 29 мая 2011 года .
^ «JPEG и JPEG2000 - между патентной ссорой и изменением технологий» . Архивировано из оригинала 17 августа 2004 года . Получено 16 апреля 2017 года . {{cite web}}: CS1 Maint: Bot: исходный статус URL неизвестен ( ссылка )
^ Кавамото, Рассвет (22 апреля 2005 г.). «Графический патентный костюм стреляет в Microsoft» . Cnet News . Архивировано из оригинала 20 января 2023 года . Получено 20 января 2023 года .
^ «Торговая офиса повторно проверяет патент JPEG» . Publish.com . 3 февраля 2006 года. Архивировано с оригинала 15 мая 2016 года . Получено 28 января 2009 года .
^ «USPTO: самые широкие претензии Postress утверждают, что jpeg invalid Invalid» . Groklaw.net . 26 мая 2006 г. Архивировано из оригинала 16 мая 2019 года . Получено 21 июля 2007 года .
^ «Система кодирования для снижения избыточности» . Gauss.ffii.org . Архивировано из оригинала 12 июня 2011 года . Получено 29 мая 2011 года .
^ «Патентный иск JPEG сдался» . Общественный патентный фонд. 2 ноября 2006 года. Архивировано с оригинала 2 января 2007 года . Получено 3 ноября 2006 года .
^ «Сертификат об повторной экспертизе Parte для патента США № 5,253,341» . Архивировано из оригинала 2 июня 2008 года.
^ Рабочая группа. «Розманит: Использование патентов на программное обеспечение для тишины критиков» . Eupat.ffii.org . Архивировано из оригинала 16 июля 2011 года . Получено 29 мая 2011 года .
^ «Награда в 5000 долларов на название Troll Tracker: Рэй Ниро хочет знать, кто говорит все эти неприятные вещи о нем» . Law.com . Архивировано из оригинала 21 ноября 2010 года . Получено 29 мая 2011 года .
^ Реймер, Джереми (5 февраля 2008 г.). «Охотничьи троллы: USPTO попросил пересмотреть патент на широкое изображение» . Arstechnica.com . Архивировано из оригинала 8 декабря 2008 года . Получено 29 мая 2011 года .
^ Патентное управление США - предоставление пересмотра 5 253 341 C1
^ «Судья ставит патент на jpeg на лед» . Techdirt.com . 30 апреля 2008 года. Архивировано с оригинала 14 ноября 2011 года . Получено 29 мая 2011 года .
^ «Единственное утверждение JPEG Patent отклонилось (и ударило для хорошей меры)» . Techdirt.com . 1 августа 2008 года. Архивировано с оригинала 28 ноября 2019 года . Получено 29 мая 2011 года .
^ Рабочая группа. «Домашняя страница Princeton Digital Image Corporation» . Архивировано из оригинала 11 апреля 2013 года . Получено 1 мая 2013 года .
^ Рабочая группа (3 апреля 2013 г.). «Статья о решении Принстонского суда относительно лицензионного соглашения GE» . Архивировано с оригинала 9 марта 2016 года . Получено 1 мая 2013 года .
^ «Обзор прогрессивного декодирования» . Microsoft Developer Network . Microsoft. Архивировано с оригинала 19 ноября 2012 года . Получено 23 марта 2012 года .
^ FastVideo (май 2019). «12-битный jpeg encoder на графическом процессоре» . Архивировано из оригинала 6 мая 2019 года . Получено 6 мая 2019 года .
^ «Почему вы всегда должны вращать оригинальные фотографии JPEG без потерь» . Petapixel.com . 14 августа 2012 года. Архивировано с оригинала 17 октября 2017 года . Получено 16 октября 2017 года .
^ «Формат файла JFIF как PDF» (PDF) . Архивировано (PDF) от оригинала 13 января 2021 года . Получено 19 июня 2006 года .
^ Том Лейн (29 марта 1999 г.). "JPEG сжатия изображения FAQ" . Архивировано с оригинала 10 ноября 2010 года . Получено 11 сентября 2007 года . (Q. 14: «Почему весь аргумент о форматах файлов?»)
^ «Все, что вам нужно знать о файлах JPEG | Adobe» . www.adobe.com . Получено 18 августа 2023 года .
^ Jump up to: ^а ^{беременный} «Стандартное цветовое пространство по умолчанию для Интернета - SRGB» . www.w3.org . Архивировано из оригинала 18 февраля 2022 года . Получено 18 февраля 2022 года .
^ Jump up to: ^а ^{беременный} «IEC 61966-2-1: 1999/AMD1: 2003 | IEC Webstore» . webstore.iec.ch . Архивировано из оригинала 18 февраля 2022 года . Получено 18 февраля 2022 года .
^ «ISO/IEC 10918-1: 1993 (e) с.36» . Архивировано из оригинала 1 августа 2011 года . Получено 30 ноября 2007 года .
^ Томас Г. Лейн. «Расширенные функции: выбор параметров сжатия» . Используя библиотеку IJG JPEG . Архивировано из оригинала 26 ноября 2001 года . Получено 8 октября 2008 года .
^ Райан, Дэн (20 июня 2012 г.). E - Учебные модули: серия DLR Associates . Автор. ISBN 978-1-4685-7520-0 .
^ «Вопросы частоты DC / AC - форум Doom9» . Forum.doom9.org . Архивировано с оригинала 17 октября 2017 года . Получено 16 октября 2017 года .
^ Jump up to: ^а ^{беременный} Phuc-Tue Le Dinh и Жак Патри. Архифакты сжатия видео и архивирование шумоподавления MPEG Архивировали 2006-03-14 на машине Wayback . Видеомазо. 24 февраля 2006 г. Получено 28 мая 2009 г.
^ " 3.9 Шум комара: форма искажения краевой занятости иногда связана с движением, характеризующиеся движущимися артефактами и/или пятнистыми узорами шума, наложенные на объекты (напоминающие комар, летящий вокруг головы и плеч человека)». ITU-T rec. ) 08/96 P.930 (
^ Джулия Мингвильон, Жаме Пуджол (апрель 2001 г.). «Моделирование ошибок jpeg стандартного равномерного квантования с приложениями для последовательных и прогрессивных режимов работы» (PDF) . Электронная визуализация . 10 (2): 475–485. Bibcode : 2001jei .... 10..475m . doi : 10.1117/1.1344592 . HDL : 10609/6263 . S2CID 16629522 . Архивировано (PDF) из оригинала 3 августа 2020 года . Получено 23 сентября 2019 года .
^ Jump up to: ^а ^{беременный} I. Bauermann и E. Steinbacj. Дальнейшее сжатие изображений JPEG без потерь. Прокурор Симпозиум кодирования изображения (PCS 2004), Сан -Франциско, США, 15–17 декабря 2004 года.
^ Jump up to: ^а ^{беременный} Н. Пономарен, К. Эгиазарян, В. Лукин и Дж. Астола. Дополнительное сжатие без потерь jpeggemage, proc. 4 -го INTL. Симпозиум по обработке и анализу изображений и сигнала (Pass 2005), Загреб, Хорватия, стр. 117–120, 15–17 сентября,
^ Jump up to: ^а ^{беременный} ^в ^{дюймовый} М. Стирнер и Г. Сиэлманн. Улучшено сокращение избыточности для файлов JPEG. Прокурор Симпозиум кодирования изображения (PCS 2007), Лиссабон, Португалия, 7–9 ноября 2007 г.
^ Jump up to: ^а ^{беременный} ^в Ichiro Matsuda, Yukio Nomoto, Kei Wakabayashi и Susumu Itoh. Без потерь повторное кодирование изображений JPEG с использованием блок-адаптивного внутрипрогнозации. Материалы 16 -й Европейской конференции по обработке сигналов (EUSIPCO 2008).
^ Стирнер, Матиас (19 февраля 2023 г.). "Packjpg/packjpg" . GitHub . Архивировано из оригинала 2 марта 2023 года . Получено 2 марта 2023 года .
^ Дж. Сирагуза; DC Swift (1997). «Стереоскопический дескриптор данных общего назначения» (PDF) . Vrex, Inc., Элмсфорд, Нью -Йорк, США . Архивировано из оригинала (PDF) 30 октября 2011 года.
^ Тим Кемп, JPS-файлы архивировали 2009-01-18 на машине Wayback
^ "Cgimagesource.supportedTypes" . Кларис Филимеер MBS Plug-In . Обезьяновое программное обеспечение. Архивировано из оригинала 30 декабря 2020 года . Получено 21 мая 2023 года .
^ «Многократный формат» (PDF) . 2009. Архивировано из оригинала (PDF) 5 апреля 2016 года . Получено 30 декабря 2015 года .
^ «MPO2SteReo: преобразовать файлы Fujifilm MPO в JPEG Stereo Pars» , MTBS3D.com , архивировав с оригинала 31 мая 2010 г. , полученная 12 января 2010 г.
^ Алессандро Ортис; Sebastiano Battiato (2015), Sitnik, Robert; Пуч, Уильям (ред.), «Новый метод быстрого сопоставления для адаптивного сжатия стереоскопических изображений» , трехмерная обработка изображений , трехмерная обработка изображений, измерение (3DIPM) и приложения 2015, 9393 , SPIE-Трехмерный Обработка изображений, измерение (3DIPM) и приложения 2015: 93930K, BibCode : 2015spie.9393e..0ko , doi : 10.1117/12.2086372 , s2cid 18879942 , архивировано с оригинала 3 марта 2016 года , полученная 30 апреля 2015
^ Алессандро Ортис; Франческо Рандо; Джузеппе ди Джиоре; Sebastiano Battiato, Адаптивное сжатие стереоскопических изображений , Международная конференция по анализу и обработке изображений (ICIAP) 2013, архивное из оригинала 3 марта 2016 года , получено 30 апреля 2015 г.
^ «Обзор JPEG» . jpeg.org . Архивировано с оригинала 21 октября 2017 года . Получено 16 октября 2017 года .
^ Том Лейн, 16 января 2013: JPEG-9, совместимость API/ABI и будущая роль этого проекта архивировала 2018-12-04 на машине Wayback
^ Программное обеспечение, которое использует или предоставляет Archived Libjpeg-Turbo 2017-03-18 на машине Wayback . 9 февраля 2012 года.
^ Выпуск 48789-Хром-Используйте Libjpeg-Turbo вместо архивирования Libjpeg 2015-08-01 на машине Wayback . 14 апреля 2011 г.
^ «ISO/IEC 10918-7: 2019 Информационные технологии-цифровое сжатие и кодирование непрерывных изображений-часть 7: Справочное программное обеспечение» . Iso . Архивировано из оригинала 7 мая 2022 года . Получено 7 мая 2022 года . «T.873 (05/19): Информационная технология - цифровое сжатие и кодирование неподвижных изображений неподвижных тонов: справочное программное обеспечение» . www.itu.int . Архивировано из оригинала 2 июня 2022 года . Получено 1 марта 2023 года .
^ "JPEG - JPEG XT" . jpeg.org . Архивировано с оригинала 4 марта 2018 года . Получено 3 марта 2018 года .
^ Рихтер, Томас (сентябрь 2016 г.). «JPEG на стероидах: общие методы оптимизации для сжатия изображений JPEG». 2016 IEEE Международная конференция по обработке изображений (ICIP) . С. 61–65. doi : 10.1109/icip.2016.7532319 . ISBN 978-1-4673-9961-6 Полем S2CID 14922251 .
^ «Представление проекта" Mozjpeg " . Mozilla Research . 5 марта 2014 года. Архивировано с оригинала 1 марта 2023 года . Получено 1 марта 2023 года .
^ «Объявление Guetzli: новый Encoder JPEG с открытым исходным кодом» . Research.googleblog.com . 16 марта 2017 года. Архивировано с оригинала 6 октября 2017 года . Получено 16 октября 2017 года .
^ «Представление jpegli: новая библиотека кодирования JPEG» . Google Open Source Blog. 3 апреля 2024 года. Архивировано с оригинала 3 апреля 2024 года . Получено 4 апреля 2024 года .
^ Снайерс, Джон (22 февраля 2021 г.). «Пришло время заменить JPEG на кодек изображения следующего поколения» . Облачный . Получено 14 ноября 2023 года .
^ "JPEG - JPEG XT" . jpeg.org . Архивировано с оригинала 4 марта 2018 года . Получено 3 марта 2018 года .
^ Аласильность, Джирки; Исчезающий Ассолдонк, Рууд; Букортт, Сами; Брюссель, Мартин; Композиция, Юлия-Мария; Firsching, Moritz; Томас, Томас; Нажмите, evgenii; Дай, Себастьян; Обрик, Роберт; Картофель, крест; Rhathushnyak, Александр; Снайерс, Джон; Sszabadka, Zoltan; Лоде; Верасри, Лука; Вассенберг, январь (6 июня 2019 г.). «JPEG XL Next Generation Compression and Coding Tools» . В теме Эндрю Г; Ebrahimii, Tourads (ред.). Приложения обработки изображений цифровых данных xlii Тол. 11137. с. 20. Bibcode : 2019spie11371 . doi : 10 1117/12,2529237 . ISBN 978-1-5106-2967-7 Полем S2CID 202785129 . Архивировано из оригинала 26 декабря 2021 года . Получено 26 декабря 2021 года .
^ Rhathushnyak, Александр; Вассенберг, Ян; Снайерс, Джон; Аласильность, Джирки; Вандевенн, Лоде; Верасри, Лука; Обрик, Роберт; Sszabadka, Zoltan; Нажмите, evgenii; Комса, справка-Мария; Картофель, крест; Брюссель, Мартин; Firsching, Moritz; Хасанова, Рената; Асельто Тщеславие; Букортт, Сами; Дай, Себастьян; Томас, Томас (2019). "Комплект черновика JPEG XL Image The System" Arxiv : 1908,03565 [ Ess.iv ].
^ «N79010 Окончательный вызов для предложений для стандарта кодирования изображения следующего поколения (JPEG XL)» (PDF) . ISO/IEC JTC 1/SC 29/WG 1 (ITU-T SG16) . Архивировано (PDF) из оригинала 31 октября 2022 года . Получено 29 мая 2018 года .
^ ISO/IEC 18181-1: 2022 Информационные технологии-система кодирования изображений JPEG XL-Часть 1: Система базового кодирования .
^ ISO/IEC 18181-2: 2021 Информационная технология-система кодирования изображений JPEG XL-Часть 2: Формат файла .

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

[t81-1] Jump up to: ^а ^{беременный} ^в ^{дюймовый} ^и «T.81-Цифровое сжатие и кодирование непрерывных тональных изображений-требования и рекомендации» (PDF) . Ccitt . Сентябрь 1992 г. Архивировал (PDF) из оригинала 30 декабря 2019 года . Получено 12 июля 2019 года .

[2] "Определение" JPEG " " . Коллинз английский словарь . Архивировано из оригинала 21 сентября 2013 года . Получено 23 мая 2013 года .

[3] Хейнс, Ричард Ф.; Чуан, Шерри Л. (1 июля 1992 г.). Влияние сжатия видео на приемлемость изображений для мониторинга экспериментов по наукам о жизни (технический отчет). НАСА . NASA-TP-3239, A-92040, NAS 1,60: 3239 . Получено 13 марта 2016 года . Уровни JPEG по-прежнему подвергаются изображению, даже с большим диапазоном от 5: 1 до 120: 1 в этом исследовании, дали одинаково высокие уровни приемлемости

[Hudson-4] Jump up to: ^а ^{беременный} Хадсон, Грэм; Легер, Ален; Нисс, Биргер; Sebestyén, István; Ваабен, Джёрген (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 г.). «Защита копирования может прийти к JPEGS» . BBC News . Би -би -си . Архивировано с оригинала 9 октября 2019 года . Получено 13 сентября 2019 года .

[heise-7] Trinkwalder, Andrea (7 октября 2016 года). «JPEG: 25 лет и не немного старый» [JPEG: 25 лет (старый) и не немного старый]. DE: Heise Online (на немецком языке). Архивировано с оригинала 5 сентября 2019 года . Получено 5 сентября 2019 года .

[Atlantic-8] Каплан, Пол (24 сентября 2013 г.). «Что такое JPEG? Невидимый объект, который вы видите каждый день» . Атлантика . Архивировано с оригинала 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: исходный статус URL неизвестен ( ссылка )

[12] «Почему JPEG 2000 никогда не взлетел» . Американский национальный институт стандартов . 10 июля 2018 года. Архивировано с оригинала 16 декабря 2018 года . Получено 13 сентября 2019 года .

[cnet-13] Jump up to: ^а ^{беременный} ^в ^{дюймовый} Лемос, Роберт (23 июля 2002 г.). «Поиск патентной истины в JPEG претендует» . CNET . Архивировано с оригинала 13 июля 2019 года . Получено 13 июля 2019 года .

[sc29-wg1-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: числовые имена: список авторов ( ссылка )

[jpeg-sc29-15] Jump up to: ^а ^{беременный} ISO/IEC JTC 1/SC 29. «Программа работы, (выделена на SC 29/WG 1)» . Архивировано из оригинала 31 декабря 2013 года . Получено 7 ноября 2009 года . {{cite web}}: CS1 Maint: числовые имена: список авторов ( ссылка )

[16] Iso. «JTC 1/SC 29 - Кодирование информации аудио, картины, мультимедиа и гипермедиа» . Архивировано из оригинала 3 июля 2010 года . Получено 11 ноября 2009 года .

[jpeg-jpeg-17] Jump up to: ^а ^{беременный} JPEG. «Совместная группа фотографических экспертов, домашняя страница JPEG» . Архивировано из оригинала 27 сентября 2009 года . Получено 8 ноября 2009 года .

[18] «T.81: Информационные технологии-цифровое сжатие и кодирование непрерывных тональных изображений-требования и рекомендации» . ItU.int . Архивировано с оригинала 6 ноября 2012 года . Получено 7 ноября 2009 года .

[19] Уильям Б. Пеннебейкер; Джоан Л. Митчелл (1993). JPEG по -прежнему Стандарт сжатия данных изображения (3 -е изд.). Спрингер. п. 291. ISBN 978-0-442-01272-4 .

[20] Iso. «JTC 1/SC 29 - Кодирование информации аудио, картины, мультимедиа и гипермедиа» . Архивировано из оригинала 3 июля 2010 года . Получено 7 ноября 2009 года .

[spiffloc-21] «Spiff, все еще формат файла интерфейса с изображением» . Библиотека Конгресса . 30 января 2012 года. Архивировано с оригинала 31 июля 2018 года . Получено 31 июля 2018 года .

[jfif-development-22] JPEG (24 апреля 2009 г.). «JPEG XR входит в статус FDIS: формат обмена файлами JPEG (JFIF), который будет стандартизирован как JPEG Part 5» (пресс -релиз). Архивировано из оригинала 8 октября 2009 года . Получено 9 ноября 2009 года .

[23] «Формат интерфейса файла JPEG (JFIF)» . ECMA TR/98 1 -е изд . ECMA International . 2009. Архивировано из оригинала 14 января 2021 года . Получено 1 августа 2011 года .

[24] «Патент Forgent от 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: исходный статус URL неизвестен ( ссылка )

[27] Кавамото, Рассвет (22 апреля 2005 г.). «Графический патентный костюм стреляет в Microsoft» . Cnet News . Архивировано из оригинала 20 января 2023 года . Получено 20 января 2023 года .

[reexam-28] «Торговая офиса повторно проверяет патент JPEG» . Publish.com . 3 февраля 2006 года. Архивировано с оригинала 15 мая 2016 года . Получено 28 января 2009 года .

[29] «USPTO: самые широкие претензии Postress утверждают, что jpeg invalid Invalid» . Groklaw.net . 26 мая 2006 г. Архивировано из оригинала 16 мая 2019 года . Получено 21 июля 2007 года .

[ep266049-30] «Система кодирования для снижения избыточности» . Gauss.ffii.org . Архивировано из оригинала 12 июня 2011 года . Получено 29 мая 2011 года .

[surrendered-31] «Патентный иск JPEG сдался» . Общественный патентный фонд. 2 ноября 2006 года. Архивировано с оригинала 2 января 2007 года . Получено 3 ноября 2006 года .

[GPHLaw1-32] «Сертификат об повторной экспертизе Parte для патента США № 5,253,341» . Архивировано из оригинала 2 июня 2008 года.

[GPHLaw2-33] Рабочая группа. «Розманит: Использование патентов на программное обеспечение для тишины критиков» . Eupat.ffii.org . Архивировано из оригинала 16 июля 2011 года . Получено 29 мая 2011 года .

[GPHLaw3-34] «Награда в 5000 долларов на название Troll Tracker: Рэй Ниро хочет знать, кто говорит все эти неприятные вещи о нем» . Law.com . Архивировано из оригинала 21 ноября 2010 года . Получено 29 мая 2011 года .

[GPHLaw4-35] Реймер, Джереми (5 февраля 2008 г.). «Охотничьи троллы: USPTO попросил пересмотреть патент на широкое изображение» . Arstechnica.com . Архивировано из оригинала 8 декабря 2008 года . Получено 29 мая 2011 года .

[GPHLaw11-36] Патентное управление США - предоставление пересмотра 5 253 341 C1

[GPHLaw55-37] «Судья ставит патент на jpeg на лед» . Techdirt.com . 30 апреля 2008 года. Архивировано с оригинала 14 ноября 2011 года . Получено 29 мая 2011 года .

[GPHLaw66-38] «Единственное утверждение JPEG Patent отклонилось (и ударило для хорошей меры)» . Techdirt.com . 1 августа 2008 года. Архивировано с оригинала 28 ноября 2019 года . Получено 29 мая 2011 года .

[PDICTroll-39] Рабочая группа. «Домашняя страница Princeton Digital Image Corporation» . Архивировано из оригинала 11 апреля 2013 года . Получено 1 мая 2013 года .

[PDICTroll2-40] Рабочая группа (3 апреля 2013 г.). «Статья о решении Принстонского суда относительно лицензионного соглашения GE» . Архивировано с оригинала 9 марта 2016 года . Получено 1 мая 2013 года .

[41] «Обзор прогрессивного декодирования» . Microsoft Developer Network . Microsoft. Архивировано с оригинала 19 ноября 2012 года . Получено 23 марта 2012 года .

[42] FastVideo (май 2019). «12-битный jpeg encoder на графическом процессоре» . Архивировано из оригинала 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 сжатия изображения FAQ" . Архивировано с оригинала 10 ноября 2010 года . Получено 11 сентября 2007 года . (Q. 14: «Почему весь аргумент о форматах файлов?»)

[46] «Все, что вам нужно знать о файлах JPEG | Adobe» . www.adobe.com . Получено 18 августа 2023 года .

[auto-47] Jump up to: ^а ^{беременный} «Стандартное цветовое пространство по умолчанию для Интернета - SRGB» . www.w3.org . Архивировано из оригинала 18 февраля 2022 года . Получено 18 февраля 2022 года .

[auto1-48] Jump up to: ^а ^{беременный} «IEC 61966-2-1: 1999/AMD1: 2003 | IEC Webstore» . webstore.iec.ch . Архивировано из оригинала 18 февраля 2022 года . Получено 18 февраля 2022 года .

[49] «ISO/IEC 10918-1: 1993 (e) с.36» . Архивировано из оригинала 1 августа 2011 года . Получено 30 ноября 2007 года .

[50] Томас Г. Лейн. «Расширенные функции: выбор параметров сжатия» . Используя библиотеку IJG JPEG . Архивировано из оригинала 26 ноября 2001 года . Получено 8 октября 2008 года .

[51] Райан, Дэн (20 июня 2012 г.). E - Учебные модули: серия DLR Associates . Автор. ISBN 978-1-4685-7520-0 .

[52] «Вопросы частоты DC / AC - форум Doom9» . Forum.doom9.org . Архивировано с оригинала 17 октября 2017 года . Получено 16 октября 2017 года .

[dinhpatry-53] Jump up to: ^а ^{беременный} Phuc-Tue Le Dinh и Жак Патри. Архифакты сжатия видео и архивирование шумоподавления MPEG Архивировали 2006-03-14 на машине Wayback . Видеомазо. 24 февраля 2006 г. Получено 28 мая 2009 г.

[54] " 3.9 Шум комара: форма искажения краевой занятости иногда связана с движением, характеризующиеся движущимися артефактами и/или пятнистыми узорами шума, наложенные на объекты (напоминающие комар, летящий вокруг головы и плеч человека)». ITU-T rec. ) 08/96 P.930 (

[55] Джулия Мингвильон, Жаме Пуджол (апрель 2001 г.). «Моделирование ошибок jpeg стандартного равномерного квантования с приложениями для последовательных и прогрессивных режимов работы» (PDF) . Электронная визуализация . 10 (2): 475–485. Bibcode : 2001jei .... 10..475m . doi : 10.1117/1.1344592 . HDL : 10609/6263 . S2CID 16629522 . Архивировано (PDF) из оригинала 3 августа 2020 года . Получено 23 сентября 2019 года .

[Bauermann-56] Jump up to: ^а ^{беременный} I. Bauermann и E. Steinbacj. Дальнейшее сжатие изображений JPEG без потерь. Прокурор Симпозиум кодирования изображения (PCS 2004), Сан -Франциско, США, 15–17 декабря 2004 года.

[Ponomarenko-57] Jump up to: ^а ^{беременный} Н. Пономарен, К. Эгиазарян, В. Лукин и Дж. Астола. Дополнительное сжатие без потерь jpeggemage, proc. 4 -го INTL. Симпозиум по обработке и анализу изображений и сигнала (Pass 2005), Загреб, Хорватия, стр. 117–120, 15–17 сентября,

[stirner-58] Jump up to: ^а ^{беременный} ^в ^{дюймовый} М. Стирнер и Г. Сиэлманн. Улучшено сокращение избыточности для файлов JPEG. Прокурор Симпозиум кодирования изображения (PCS 2007), Лиссабон, Португалия, 7–9 ноября 2007 г.

[matsuda-59] Jump up to: ^а ^{беременный} ^в Ichiro Matsuda, Yukio Nomoto, Kei Wakabayashi и Susumu Itoh. Без потерь повторное кодирование изображений JPEG с использованием блок-адаптивного внутрипрогнозации. Материалы 16 -й Европейской конференции по обработке сигналов (EUSIPCO 2008).

[60] Стирнер, Матиас (19 февраля 2023 г.). "Packjpg/packjpg" . GitHub . Архивировано из оригинала 2 марта 2023 года . Получено 2 марта 2023 года .

[61] Дж. Сирагуза; DC Swift (1997). «Стереоскопический дескриптор данных общего назначения» (PDF) . Vrex, Inc., Элмсфорд, Нью -Йорк, США . Архивировано из оригинала (PDF) 30 октября 2011 года.

[62] Тим Кемп, JPS-файлы архивировали 2009-01-18 на машине Wayback

[63] "Cgimagesource.supportedTypes" . Кларис Филимеер MBS Plug-In . Обезьяновое программное обеспечение. Архивировано из оригинала 30 декабря 2020 года . Получено 21 мая 2023 года .

[64] «Многократный формат» (PDF) . 2009. Архивировано из оригинала (PDF) 5 апреля 2016 года . Получено 30 декабря 2015 года .

[65] «MPO2SteReo: преобразовать файлы Fujifilm MPO в JPEG Stereo Pars» , MTBS3D.com , архивировав с оригинала 31 мая 2010 г. , полученная 12 января 2010 г.

[66] Алессандро Ортис; Sebastiano Battiato (2015), Sitnik, Robert; Пуч, Уильям (ред.), «Новый метод быстрого сопоставления для адаптивного сжатия стереоскопических изображений» , трехмерная обработка изображений , трехмерная обработка изображений, измерение (3DIPM) и приложения 2015, 9393 , SPIE-Трехмерный Обработка изображений, измерение (3DIPM) и приложения 2015: 93930K, BibCode : 2015spie.9393e..0ko , doi : 10.1117/12.2086372 , s2cid 18879942 , архивировано с оригинала 3 марта 2016 года , полученная 30 апреля 2015

[67] Алессандро Ортис; Франческо Рандо; Джузеппе ди Джиоре; Sebastiano Battiato, Адаптивное сжатие стереоскопических изображений , Международная конференция по анализу и обработке изображений (ICIAP) 2013, архивное из оригинала 3 марта 2016 года , получено 30 апреля 2015 г.

[JPEG-homepage-68] «Обзор JPEG» . jpeg.org . Архивировано с оригинала 21 октября 2017 года . Получено 16 октября 2017 года .

[TomSmartScale-69] Том Лейн, 16 января 2013: JPEG-9, совместимость API/ABI и будущая роль этого проекта архивировала 2018-12-04 на машине Wayback

[turbo-software-70] Программное обеспечение, которое использует или предоставляет Archived Libjpeg-Turbo 2017-03-18 на машине Wayback . 9 февраля 2012 года.

[Chromium-71] Выпуск 48789-Хром-Используйте Libjpeg-Turbo вместо архивирования Libjpeg 2015-08-01 на машине Wayback . 14 апреля 2011 г.

[refimpl-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». 2016 IEEE Международная конференция по обработке изображений (ICIP) . С. 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: новый Encoder JPEG с открытым исходным кодом» . Research.googleblog.com . 16 марта 2017 года. Архивировано с оригинала 6 октября 2017 года . Получено 16 октября 2017 года .

[77] «Представление jpegli: новая библиотека кодирования JPEG» . Google Open Source Blog. 3 апреля 2024 года. Архивировано с оригинала 3 апреля 2024 года . Получено 4 апреля 2024 года .

[78] Снайерс, Джон (22 февраля 2021 г.). «Пришло время заменить JPEG на кодек изображения следующего поколения» . Облачный . Получено 14 ноября 2023 года .

[79] "JPEG - JPEG XT" . jpeg.org . Архивировано с оригинала 4 марта 2018 года . Получено 3 марта 2018 года .

[spie_jpegxl-80] Аласильность, Джирки; Исчезающий Ассолдонк, Рууд; Букортт, Сами; Брюссель, Мартин; Композиция, Юлия-Мария; Firsching, Moritz; Томас, Томас; Нажмите, evgenii; Дай, Себастьян; Обрик, Роберт; Картофель, крест; Rhathushnyak, Александр; Снайерс, Джон; Sszabadka, Zoltan; Лоде; Верасри, Лука; Вассенберг, январь (6 июня 2019 г.). «JPEG XL Next Generation Compression and Coding Tools» . В теме Эндрю Г; Ebrahimii, Tourads (ред.). Приложения обработки изображений цифровых данных xlii Тол. 11137. с. 20. Bibcode : 2019spie11371 . doi : 10 1117/12,2529237 . ISBN 978-1-5106-2967-7 Полем S2CID 202785129 . Архивировано из оригинала 26 декабря 2021 года . Получено 26 декабря 2021 года .

[jpegxl_committeedraft-81] Rhathushnyak, Александр; Вассенберг, Ян; Снайерс, Джон; Аласильность, Джирки; Вандевенн, Лоде; Верасри, Лука; Обрик, Роберт; Sszabadka, Zoltan; Нажмите, evgenii; Комса, справка-Мария; Картофель, крест; Брюссель, Мартин; Firsching, Moritz; Хасанова, Рената; Асельто Тщеславие; Букортт, Сами; Дай, Себастьян; Томас, Томас (2019). "Комплект черновика JPEG XL Image The System" Arxiv : 1908,03565 [ Ess.iv ].

[jpegxl_cfp-82] «N79010 Окончательный вызов для предложений для стандарта кодирования изображения следующего поколения (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: Формат файла .

[ 1 ]

[ 2 ]

[ 3 ]

[ 4 ]

[ 5 ]

[ 6 ]

[ 7 ]

[ 8 ]

[ 9 ]

[ 10 ]

[ 11 ]

[ 12 ]

[ 13 ]

[ 14 ]

[ 15 ]

[ 16 ]

[ 17 ]

[ 18 ]

[ 19 ]

[ 20 ]

[ 21 ]

[ 22 ]

[ 23 ]

[ 24 ]

[ 25 ]

[ 26 ]

[ 27 ]

[ 28 ]

[ 29 ]

[ 30 ]

[ 31 ]

[ 32 ]

[ 33 ]

[ 34 ]

[ 35 ]

[ 36 ]

[ 37 ]

[ 38 ]

[ 39 ]

[ 40 ]

[ 41 ]

[ 42 ]

[ 43 ]

[ 44 ]

[ 45 ]

[ 46 ]

[ 47 ]

[ 48 ]

[ 49 ]

[ 50 ]

[ 51 ]

[ 52 ]

[ 53 ]

[ 54 ]

[ 55 ]

[ 56 ]

[ 57 ]

[ 58 ]

[ 59 ]

[ 60 ]

[ 61 ]

[ 62 ]

[ 63 ]

[ 64 ]

[ 65 ]

[ 66 ]

[ 67 ]

[ 68 ]

[ 69 ]

[ 70 ]

[ 71 ]

[ 72 ]

[ 73 ]

[ 74 ]

[ 75 ]

[ 76 ]

[ 77 ]

[ 78 ]

[ 79 ]

[ 80 ]

[ 81 ]

[ 82 ]

[ 83 ]

[ 84 ]

v Т и Графические форматы
Raster	ANI ANIM APNG ART AVIF BMP BPG BSAVE CAL CIN CPC CPT DDS DPX ECW EXR FITS FLIC FLIF FPX GIF HDRi HEVC ICER ICNS ICO / CUR ICS ILBM JBIG JBIG2 JNG JPEG JPEG-LS JPEG 2000 JPEG XL JPEG XR JPEG XS JPEG XT JPEG-HDR KRA MNG MIFF NRRD ORA PAM PBM / PGM / PPM / PNM PCX PGF PICtor PNG PSD / PSB PSP QOI QTVR RAS RGBE Logluv TIFF SGI TGA TIFF TIFF/EP TIFF/IT UFO / UFP WBMP WebP XBM XCF XPM XWD
Raw	CIFF DNG
Vector	AI CDR CGM DXF EMF EMF+ Gerber HVIF IGES PGML SVG VML WMF Xar
Compound	CDF DjVu EPS MODCA PDF PICT PS SWF XAML
Metadata	Exchangeable image file format (Exif) International Press Telecommunications Council § Photo metadata Extensible Metadata Platform (XMP) GIF § Metadata Steganography
Category Comparison