JPEG

Мультиизображение JPEG
Расширение имени файла	.потому что
Единый идентификатор типа (UTI)	public.mpo-изображение

Внешний образ
Внешний образ
	Иллюстрация периферийной занятости

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
Стандартный	ИСО/МЭК 10918, МСЭ-Т Т.81, МСЭ-Т Т.83, МСЭ-Т Т.84, МСЭ-Т Т.86
Веб-сайт	JPEG .org /jpeg /

Постоянно варьируемое сжатие JPEG (от Q=100 до Q=1) для брюшной полости . компьютерной томографии

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

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

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

История

Фон

Исходная спецификация JPEG, опубликованная в 1992 году, реализует процессы из различных более ранних исследовательских работ и патентов , на которые ссылаются CCITT (ныне ITU-T ) и Объединенная группа экспертов по фотографии. ^{[ 1 ]}

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

ИБМ
- Патент США 4 652 856 - 4 февраля 1986 г. - Коттаппурам М. А. Мохиуддин и Йорма Дж. Риссанен - Многоалфавитный арифметический код без умножения.
- Патент США 4905297 - 27 февраля 1990 г. - Г. Лэнгдон, Дж. Л. Митчелл , У. Б. Пеннебейкер и Йорма Дж. Риссанен - Система арифметического кодирования и декодера.
- Патент США 4 935 882 - 19 июня 1990 г. - У. Б. Пеннебейкер и Дж. Л. Митчелл - Вероятностная адаптация для арифметических кодеров.
Митсубиси Электрик
- JP H02202267 ( 1021672 ) - 21 января 1989 г. - Тошихиро Кимура, Сигенори Кино, Фумитака Оно, Масаюки Ёсида - Система кодирования
- JP H03247123 ( 2-46275 ) - 26 февраля 1990 г. - Томохиро Кимура, Сигенори Кино, Фумитака Оно и Масаюки Ёсида - Устройство кодирования и метод кодирования.

Спецификация JPEG также ссылается на три других патента IBM. Среди других компаний, названных держателями патентов, — AT&T (два патента) и Canon Inc. ^{[ 1 ]} В списке отсутствует патент США № 4698672 , поданный Вен-Сюном Ченом и Дэниелом Дж. Кленке из Compression Labs в октябре 1986 года. Патент описывает алгоритм сжатия изображения на основе DCT и позже стал причиной споров в 2002 году (см. Патентные споры ниже). ^{[ 13 ]} Однако спецификация JPEG цитирует две более ранние исследовательские работы Вэнь-Сюн Чена, опубликованные в 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 ]} Со стороны МСЭ-Т соответствующим органом является ИК16 МСЭ-Т. Первоначальная группа JPEG была организована в 1986 году. ^{[ 17 ]} выпуск первого стандарта JPEG в 1992 г., который был утвержден в сентябре 1992 г. как ITU-T T.81. Рекомендация ^{[ 18 ]} и в 1994 году как ISO / IEC 10918-1 .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

JPEG-сжатие

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

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

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

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

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

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

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

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

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

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

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

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

JPEG-файлы

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

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

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

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

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

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

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

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

Наиболее распространенные расширения имен файлов , использующих сжатие JPEG: .jpg и .jpeg, хотя .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. Этот метод, называемый вставкой байтов (см. раздел F.1.2.3 спецификации JPEG), применяется только к данным энтропийного кодирования, а не к данным полезной нагрузки маркера. Однако обратите внимание, что данные, закодированные энтропийно, имеют несколько собственных маркеров; в частности, маркеры сброса (от 0xD0 до 0xD7), которые используются для изоляции независимых фрагментов данных с энтропийным кодированием для обеспечения параллельного декодирования, и кодировщики могут свободно вставлять эти маркеры сброса через регулярные промежутки времени (хотя не все кодировщики делают это).

Общие маркеры JPEG ^{[ 49 ]}
Короткое имя	Байты	Полезная нагрузка	Имя	Комментарии
СЕБЯ	0xFF, 0xD8	никто	Начало изображения
СОФ0	0xFF, 0xC0	переменный размер	Начало кадра (базовый DCT )	Указывает, что это базовый JPEG на основе DCT, и определяет ширину, высоту, количество компонентов и субдискретизацию компонентов (например, 4:2:0).
СОФ2	0xFF, 0xC2	переменный размер	Начало кадра (прогрессивный DCT)	Указывает, что это JPEG на основе прогрессивного DCT, и указывает ширину, высоту, количество компонентов и субдискретизацию компонентов (например, 4:2:0).
ДХТ	0xFF, 0xC4	переменный размер	Определить таблицы Хаффмана	Указывает одну или несколько таблиц Хаффмана.
ДКТ	0xFF, 0xDB	переменный размер	Определить таблицу(и) квантования	Задает одну или несколько таблиц квантования.
ДРИ	0xFF, 0xDD	4 байта	Определить интервал перезапуска	Указывает интервал между RST n маркерами в минимальных кодовых единицах (MCU). За этим маркером следуют два байта, указывающие фиксированный размер, поэтому его можно рассматривать как любой другой сегмент переменного размера.
SOS	0xFF, 0xDA	переменный размер	Начало сканирования	Начинает сканирование изображения сверху вниз. В базовых изображениях DCT JPEG обычно выполняется одно сканирование. Изображения Progressive DCT JPEG обычно содержат несколько сканирований. Этот маркер указывает, какой фрагмент данных он будет содержать, и сразу за ним следуют данные с энтропийным кодированием.
RST н	0xFF, 0xD n ( n =0..7)	никто	Перезапуск	Вставляется каждые r макроблоков, где r — интервал перезапуска, заданный маркером DRI. Не используется, если нет маркера DRI. Младшие три бита кода маркера циклически изменятся от 0 до 7.
Приложение №	0xFF, 0xE н	переменный размер	Для конкретного приложения	Например, файл Exif JPEG использует маркер APP1 для хранения метаданных, расположенных в структуре, близкой к TIFF .
С	0xFF, 0xFE	переменный размер	Комментарий	Содержит текстовый комментарий.
ВЗ	0xFF, 0xD9	никто	Конец изображения

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

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

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

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

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

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

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

Кодирование

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

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

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

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

Понижение разрешения

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

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

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

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

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

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

Затем каждый блок 8×8 каждого компонента (Y, Cb, Cr) преобразуется в представление в частотной области с использованием нормализованного двумерного дискретного косинусного преобразования (DCT) типа II, см. Цитату 1 в дискретном косинусном преобразовании. . ДКП иногда называют «ДКП типа II» в контексте семейства преобразований, например дискретного косинусного преобразования , а соответствующее обратное преобразование (IDCT) обозначается как «ДКП типа 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 шаблонов. Шаблоны называются двумерными *базисными функциями* ДКП , а выходные значения называются *коэффициентами преобразования* . Горизонтальный индекс $u$ и вертикальный индекс $v$ .

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

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

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

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

Квантование

Человеческий глаз хорошо различает небольшие различия в яркости на относительно большой площади, но не очень хорошо различает точную силу высокочастотных изменений яркости. Это позволяет значительно уменьшить объем информации в высокочастотных компонентах. Это делается путем простого деления каждого компонента в частотной области на константу для этого компонента, а затем округления до ближайшего целого числа. Эта операция округления является единственной операцией с потерями во всем процессе (кроме субдискретизации цветности), если вычисление 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$ – неквантованные коэффициенты ДКП; $Q$ — приведенная выше матрица квантования; и $B$ — квантованные коэффициенты ДКП.

Использование этой матрицы квантования с приведенной выше матрицей коэффициентов 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 (коэффициент постоянного тока) и округляя до ближайшего целого числа.

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

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

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

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

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

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

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

−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$ -го блока) равен $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 благодаря возможности использовать разные таблицы Хаффмана (см. ниже), адаптированные для разных частот при каждом «сканировании» или «проходе» (включая аналогичные позиционированные коэффициенты), хотя разница не слишком велика.

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

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

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

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

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

Символ 1	Символ 2
(ДЛИНА, РАЗМЕР)	(АМПЛИТУДА)

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

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

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

Степень сжатия и артефакты

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

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

$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. Эти требования указаны в Рекомендации ITU.T T.83 | ИСО/МЭК 10918-2. В отличие от стандартов MPEG и многих более поздних стандартов JPEG, вышеупомянутый документ определяет как требуемую точность реализации для процесса кодирования, так и процесса декодирования кодека JPEG посредством максимально допустимой ошибки прямого и обратного DCT в домене DCT, определенной с помощью эталонного теста. потоки. Например, выходные данные реализации декодера не должны превышать ошибку в одну единицу квантования в области DCT при применении к кодовым потокам эталонного тестирования, предусмотренным как часть вышеупомянутого стандарта. Несмотря на то, что ITU.T T.83 | является необычным и в отличие от многих других, более современных стандартов, стандарт 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	Первые признаки артефактов фрагментов изображений
Среднее качество (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.

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

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

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

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

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

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

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

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

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

Формат нескольких изображений JPEG

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

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

Реализации

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

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

Объединенная группа экспертов по фотографии ISO/IEC поддерживает другую реализацию эталонного программного обеспечения под заголовком 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 ]} Новый формат призван превзойти производительность сжатия неподвижных изображений, продемонстрированную HEVC HM, Daala и WebP . до 32 бит на компонент Он поддерживает изображения размером в миллиард на миллиард пикселей, широкий динамический диапазон с соответствующими функциями передачи ( PQ и HLG ), патч-кодирование синтетических изображений, таких как растровые шрифты и градиенты, анимированные изображения, альфа-канал. кодирование и выбор цветовой кодировки RGB/YCbCr/ ICtCp . ^{[ 81 ]}^{[ 82 ]}^{[ 83 ]}^{[ 84 ]}

См. также

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

Ссылки

^ Перейти обратно: ^а ^б ^с ^д ^и «T.81 – ЦИФРОВОЕ СЖАТИЕ И КОДИРОВАНИЕ НЕПРЕРЫВНЫХ СТАЦИОНАРНЫХ ИЗОБРАЖЕНИЙ – ТРЕБОВАНИЯ И РУКОВОДСТВА» (PDF) . ССИТТ . Сентябрь 1992 г. Архивировано (PDF) из оригинала 30 декабря 2019 г. . Проверено 12 июля 2019 г.
^ «Определение «JPEG» » . Словарь английского языка Коллинза . Архивировано из оригинала 21 сентября 2013 года . Проверено 23 мая 2013 г.
^ Хейнс, Ричард Ф.; Чуанг, Шерри Л. (1 июля 1992 г.). Влияние сжатия видео на приемлемость изображений для мониторинга экспериментов в области медико-биологических наук (технический отчет). НАСА . НАСА-ТП-3239, А-92040, НАС 1.60:3239 . Проверено 13 марта 2016 г. Уровни сжатия неподвижных изображений JPEG, даже при широком диапазоне от 5:1 до 120:1 в этом исследовании, дали одинаково высокий уровень приемлемости.
^ Перейти обратно: ^а ^б Хадсон, Грэм; Леже, Ален; Нисс, Биргер; Себастьен, Иштван; Ваабен, Йорген (31 августа 2018 г.). «Стандарту JPEG-1 25 лет: причины успеха в прошлом, настоящем и будущем» . Журнал электронных изображений . 27 (4): 1. doi : 10.1117/1.JEI.27.4.040901 . S2CID 52164892 .
^ Светлик, Джо (31 мая 2018 г.). «Описание формата изображения JPEG» . BT.com . Группа БТ . Архивировано из оригинала 5 августа 2019 года . Проверено 5 августа 2019 г.
^ Баранюк, Крис (15 октября 2015 г.). «Защита от копирования может появиться в формате JPEG» . Новости Би-би-си . Би-би-си . Архивировано из оригинала 9 октября 2019 года . Проверено 13 сентября 2019 г.
^ Тринквальдер, Андреа (7 октября 2016 г.). «JPEG: 25 лет (устарело) и ни капельки не старело» [JPEG: 25 лет (устарело) и ни капельки не старело]. de:Heise онлайн (на немецком языке). Архивировано из оригинала 5 сентября 2019 года . Проверено 5 сентября 2019 г.
^ Каплан, Пол (24 сентября 2013 г.). «Что такое JPEG? Невидимый объект, который вы видите каждый день» . Атлантика . Архивировано из оригинала 9 октября 2019 года . Проверено 13 сентября 2019 г.
^ «HTTP-архив – интересная статистика» . httparchive.org . Проверено 6 апреля 2016 г.
^ «Определение типа MIME в Internet Explorer» . Майкрософт. 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 г.
^ Перейти обратно: ^а ^б ^с ^д Лемос, Роберт (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: числовые имена: список авторов ( ссылка )
^ Перейти обратно: ^а ^б ISO/IEC JTC 1/SC 29. «Программа работы (перенесена в SC 29/WG 1)» . Архивировано из оригинала 31 декабря 2013 года . Проверено 7 ноября 2009 г. {{cite web}}: CS1 maint: числовые имена: список авторов ( ссылка )
^ ИСО. «JTC 1/SC 29 – Кодирование аудио, изображений, мультимедиа и гипермедийной информации» . Архивировано из оригинала 3 июля 2010 года . Проверено 11 ноября 2009 г.
^ Перейти обратно: ^а ^б JPEG. «Объединенная группа экспертов в области фотографии, домашняя страница JPEG» . Архивировано из оригинала 27 сентября 2009 года . Проверено 8 ноября 2009 г.
^ «T.81: Информационные технологии. Цифровое сжатие и кодирование неподвижных изображений с непрерывным тоном. Требования и рекомендации» . Itu.int . Архивировано из оригинала 6 ноября 2012 года . Проверено 7 ноября 2009 г.
^ Уильям Б. Пеннебейкер; Джоан Л. Митчелл (1993). Стандарт сжатия данных неподвижных изображений JPEG (3-е изд.). Спрингер. п. 291. ИСБН 978-0-442-01272-4 .
^ ИСО. «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-е изд . Экма Интернешнл . 2009. Архивировано из оригинала 14 января 2021 года . Проверено 1 августа 2011 г.
^ «Патент Форджента на JPEG» . СоурсФордж . 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 . Архивировано из оригинала 20 января 2023 года . Проверено 20 января 2023 г.
^ «Ведомство по товарным знакам пересматривает патент на подделку JPEG» . Публикация.com . 3 февраля 2006 г. Архивировано из оригинала 15 мая 2016 г. . Проверено 28 января 2009 г.
^ «ВПТЗ США: самые широкие претензии ложны, утверждения против стандарта JPEG недействительны» . Гроклав.нет . 26 мая 2006 г. Архивировано из оригинала 16 мая 2019 г. . Проверено 21 июля 2007 г.
^ «Система кодирования для уменьшения избыточности» . Gauss.ffii.org . Архивировано из оригинала 12 июня 2011 года . Проверено 29 мая 2011 г.
^ «Заявка на патент JPEG отклонена» . Общественный патентный фонд. 2 ноября 2006 г. Архивировано из оригинала 2 января 2007 г. Проверено 3 ноября 2006 г.
^ «Свидетельство о повторной экспертизе ex parte на патент США № 5 253 341» . Архивировано из оригинала 2 июня 2008 года.
^ Рабочая группа. «Розманит: использование патентов на программное обеспечение, чтобы заставить замолчать критиков» . Eupat.ffii.org . Архивировано из оригинала 16 июля 2011 года . Проверено 29 мая 2011 г.
^ «Награда в размере 5000 долларов за имя следопыта троллей: Рэй Ниро хочет знать, кто говорит о нем все эти гадости» . 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 отклонена (и отвергнута заочно)» . Techdirt.com . 1 августа 2008 г. Архивировано из оригинала 28 ноября 2019 г. . Проверено 29 мая 2011 г.
^ Рабочая группа. «Домашняя страница Princeton Digital Image Corporation» . Архивировано из оригинала 11 апреля 2013 года . Проверено 1 мая 2013 г.
^ Рабочая группа (3 апреля 2013 г.). «Статья о решении Принстонского суда относительно лицензионного соглашения GE» . Архивировано из оригинала 9 марта 2016 года . Проверено 1 мая 2013 г.
^ «Обзор прогрессивного декодирования» . Сеть разработчиков Microsoft . Майкрософт. Архивировано из оригинала 19 ноября 2012 года . Проверено 23 марта 2012 г.
^ Фаствидео (май 2019). «12-битный кодер JPEG на графическом процессоре» . Архивировано из оригинала 6 мая 2019 года . Проверено 6 мая 2019 г.
^ «Почему всегда следует поворачивать оригинальные фотографии JPEG без потерь» . Petapixel.com . 14 августа 2012 года. Архивировано из оригинала 17 октября 2017 года . Проверено 16 октября 2017 г.
^ «Формат файла JFIF в формате PDF» (PDF) . Архивировано (PDF) из оригинала 13 января 2021 года . Проверено 19 июня 2006 г.
^ Том Лейн (29 марта 1999 г.). «Часто задаваемые вопросы по сжатию изображений JPEG» . Архивировано из оригинала 10 ноября 2010 года . Проверено 11 сентября 2007 г. (вопрос 14: «К чему все эти споры о форматах файлов?»)
^ «Все, что вам нужно знать о файлах JPEG | Adobe» . www.adobe.com . Проверено 18 августа 2023 г.
^ Перейти обратно: ^а ^б «Стандартное цветовое пространство по умолчанию для Интернета — sRGB» . www.w3.org . Архивировано из оригинала 18 февраля 2022 года . Проверено 18 февраля 2022 г.
^ Перейти обратно: ^а ^б «МЭК 61966-2-1:1999/AMD1:2003 | Интернет-магазин МЭК» . webstore.iec.ch . Архивировано из оригинала 18 февраля 2022 года . Проверено 18 февраля 2022 г.
^ «ИСО/МЭК 10918-1: 1993(Е) стр.36» . Архивировано из оригинала 1 августа 2011 года . Проверено 30 ноября 2007 г.
^ Томас Дж. Лейн. «Дополнительные возможности: выбор параметров сжатия» . Использование библиотеки JPEG IJG . Архивировано из оригинала 26 ноября 2001 года . Проверено 8 октября 2008 г.
^ Райан, Дэн (20 июня 2012 г.). Модули электронного обучения: серия Dlr Associates . АвторДом. ISBN 978-1-4685-7520-0 .
^ «Вопросы о частоте постоянного/переменного тока — Форум Doom9» . forum.doom9.org . Архивировано из оригинала 17 октября 2017 года . Проверено 16 октября 2017 г.
^ Перейти обратно: ^а ^б Фук-Ту Ле Динь и Жак Патри. Артефакты сжатия видео и шумоподавление MPEG. Архивировано 14 марта 2006 г. на Wayback Machine . Видеоизображение DesignLine. 24 февраля 2006 г. Проверено 28 мая 2009 г.
^ « 3.9 Комариный шум: форма искажения краевой занятости, иногда связанная с движением, характеризующаяся движущимися артефактами и / или пятнистыми шумовыми рисунками, наложенными на объекты (напоминающими комара, летающего вокруг головы и плеч человека)». Рек. МСЭ-Т. P.930 (08/96) Принципы системы эталонного искажения видео. Архивировано 16 февраля 2010 г. на Wayback Machine.
^ Хулия Мингильон, Жауме Пухоль (апрель 2001 г.). «Моделирование ошибок квантования по стандарту JPEG с применением к последовательным и прогрессивным режимам работы» (PDF) . Электронная визуализация . 10 (2): 475–485. Бибкод : 2001JEI....10..475M . дои : 10.1117/1.1344592 . hdl : 10609/6263 . S2CID 16629522 . Архивировано (PDF) из оригинала 3 августа 2020 г. Проверено 23 сентября 2019 г.
^ Перейти обратно: ^а ^б И. Бауэрман и Э. Штайнбач. Дальнейшее сжатие изображений JPEG без потерь. Учеб. Симпозиума по кодированию изображений (PCS 2004), Сан-Франциско, США, 15–17 декабря 2004 г.
^ Перейти обратно: ^а ^б Н. Пономаренко, К. Егиазарян, В. Лукин и Я. Астола. Дополнительное сжатие изображений JPEG без потерь, Учеб. 4-го Международного Материалы симпозиума по обработке и анализу изображений и сигналов (ISPA 2005), Загреб, Хорватия, стр. 107–111. 117–120, 15–17 сентября 2005 г.
^ Перейти обратно: ^а ^б ^с ^д М. Штирнер и Г. Зельманн. Улучшено снижение избыточности для файлов JPEG. Учеб. Симпозиума по кодированию изображений (PCS 2007), Лиссабон, Португалия, 7–9 ноября 2007 г.
^ Перейти обратно: ^а ^б ^с Ичиро Мацуда, Юкио Номото, Кей Вакабаяши и Сусуму Ито. Перекодирование изображений JPEG без потерь с использованием блочно-адаптивного внутреннего предсказания. Материалы 16-й Европейской конференции по обработке сигналов (EUSIPCO 2008).
^ Штирнер, Матиас (19 февраля 2023 г.). "packjpg/packJPG" . Гитхаб . Архивировано из оригинала 2 марта 2023 года . Проверено 2 марта 2023 г.
^ Дж. Сирагуса; Округ Колумбия Свифт (1997). «Дескриптор стереоскопических данных общего назначения» (PDF) . VRex, Inc., Элмсфорд, Нью-Йорк, США . Архивировано из оригинала (PDF) 30 октября 2011 года.
^ Тим Кемп, файлы JPS , заархивированные 18 января 2009 г. на Wayback Machine.
^ «CGImageSource.SupportedTypes» . Плагин Claris FileMaker MBS . Программное обеспечение MonkeyBread. Архивировано из оригинала 30 декабря 2020 года . Проверено 21 мая 2023 г.
^ «Формат нескольких изображений» (PDF) . 2009. Архивировано из оригинала (PDF) 5 апреля 2016 года . Проверено 30 декабря 2015 г.
^ «MPO2Stereo: конвертируйте файлы Fujifilm MPO в стереопары JPEG» , Mtbs3d.com , заархивировано из оригинала 31 мая 2010 г. , получено 12 января 2010 г.
^ Алессандро Ортис; Себастьяно Баттиато (2015), Ситник, Роберт; Пьюх, Уильям (ред.), «Новый метод быстрого сопоставления для адаптивного сжатия стереоскопических изображений» , Обработка трехмерных изображений , Обработка трехмерных изображений, измерение (3DIPM) и приложения 2015, 9393 , SPIE — Трехмерные Обработка изображений, измерение (3DIPM) и приложения 2015: 93930K, Bibcode : 2015SPIE.9393E..0KO , doi : 10.1117/12.2086372 , S2CID 18879942 , заархивировано из оригинала 3 марта 2016 г. , получено 30 апреля 2015 г.
^ Алессандро Ортис; Франческо Рундо; Джузеппе Ди Джоре; Себастьяно Баттиато, Адаптивное сжатие стереоскопических изображений , Международная конференция по анализу и обработке изображений (ICIAP), 2013 г., заархивировано из оригинала 3 марта 2016 г. , получено 30 апреля 2015 г.
^ «Обзор JPEG» . jpeg.org . Архивировано из оригинала 21 октября 2017 года . Проверено 16 октября 2017 г.
↑ Том Лейн, 16 января 2013 г.: jpeg-9, совместимость API/ABI и будущая роль этого проекта. Архивировано 4 декабря 2018 г. на Wayback Machine.
^ Программное обеспечение, которое использует или предоставляет libjpeg-turbo. Архивировано 18 марта 2017 г. на Wayback Machine . 9 февраля 2012 г.
^ Проблема 48789 — хром — используйте libjpeg-turbo вместо libjpeg. Архивировано 1 августа 2015 г. на Wayback Machine . 14 апреля 2011 г.
^ «ISO/IEC 10918-7: 2019 Информационные технологии. Цифровое сжатие и кодирование неподвижных изображений с непрерывным тоном. Часть 7. Справочное программное обеспечение» . ИСО . Архивировано из оригинала 7 мая 2022 года . Проверено 7 мая 2022 г. «T.873 (19 мая): Информационные технологии. Цифровое сжатие и кодирование неподвижных изображений с непрерывным тоном: Справочное программное обеспечение» . www.itu.int . Архивировано из оригинала 2 июня 2022 года . Проверено 1 марта 2023 г.
^ «JPEG — JPEG XT» . jpeg.org . Архивировано из оригинала 4 марта 2018 года . Проверено 3 марта 2018 г.
^ Рихтер, Томас (сентябрь 2016 г.). «JPEG на стероидах: общие методы оптимизации сжатия изображений JPEG». Международная конференция IEEE по обработке изображений (ICIP) , 2016 г. стр. 61–65. дои : 10.1109/ICIP.2016.7532319 . ISBN 978-1-4673-9961-6 . S2CID 14922251 .
^ «Представляем проект «mozjpeg»» . Исследование Мозиллы . 5 марта 2014 г. Архивировано из оригинала 1 марта 2023 г. Проверено 1 марта 2023 г.
^ «Анонсируем Guetzli: новый кодировщик JPEG с открытым исходным кодом» . Research.googleblog.com . 16 марта 2017 года. Архивировано из оригинала 6 октября 2017 года . Проверено 16 октября 2017 г.
^ «Представляем Jpegli: новую библиотеку кодирования JPEG» . Блог Google с открытым исходным кодом. 3 апреля 2024 года. Архивировано из оригинала 3 апреля 2024 года . Проверено 4 апреля 2024 г.
^ Снейерс, Джон (22 февраля 2021 г.). «Пришло время заменить JPEG кодеком изображения следующего поколения» . Облачно . Проверено 14 ноября 2023 г.
^ «JPEG — JPEG XT» . jpeg.org . Архивировано из оригинала 4 марта 2018 года . Проверено 3 марта 2018 г.
^ Алакуйала, Юрки; из Ассельдонка, Рууд; Букортт, Сами; Брюс, Мартин; Соседка Юлия-Мария; Фиршинг, Мориц; Фишбахер, Томас; Ключников Евгений; Гомес, Себастьян; Обрик, Роберт; Потемпа, Кристофер; Ратушняк, Александр; Снейерс, Джон; Шабадка, Золтан; Вандервенн, Лоде; Версари, Люк; Вассенберг, январь (6 сентября 2019 г.). «Архитектура сжатия изображений нового поколения JPEG XL и инструменты кодирования» . В Тешере, Эндрю Дж.; Эбрахими, Турадж (ред.). Применение цифровой обработки изображений XLII . Том. 11137. с. 20. Бибкод : 2019SPIE11137E..0KA . дои : 10.1117/12.2529237 . ISBN 978-1-5106-2967-7 . S2CID 202785129 . Архивировано из оригинала 26 декабря 2021 года . Проверено 26 декабря 2021 г.
^ Ратушняк, Александр; Вассенберг, Ян; Снейерс, Джон; Алакуйала, Юрки; Вандевенн, Лоде; Версари, Люк; Обрик, Роберт; Шабадка, Золтан; Ключников Евгений; Комса, Юлия-Мария; Потемпа, Кристофер; Брюс, Мартин; Фиршинг, Мориц; Хасанова Рената; Красный Ассельдонка; Букортт, Сами; Гомес, Себастьян; Фишбахер, Томас (2019). «Проект комитета системы кодирования изображений JPEG XL». arXiv : 1908.03565 [ eess.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] Перейти обратно: ^а ^б ^с ^д ^и «T.81 – ЦИФРОВОЕ СЖАТИЕ И КОДИРОВАНИЕ НЕПРЕРЫВНЫХ СТАЦИОНАРНЫХ ИЗОБРАЖЕНИЙ – ТРЕБОВАНИЯ И РУКОВОДСТВА» (PDF) . ССИТТ . Сентябрь 1992 г. Архивировано (PDF) из оригинала 30 декабря 2019 г. . Проверено 12 июля 2019 г.

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

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

[Hudson-4] Перейти обратно: ^а ^б Хадсон, Грэм; Леже, Ален; Нисс, Биргер; Себастьен, Иштван; Ваабен, Йорген (31 августа 2018 г.). «Стандарту JPEG-1 25 лет: причины успеха в прошлом, настоящем и будущем» . Журнал электронных изображений . 27 (4): 1. doi : 10.1117/1.JEI.27.4.040901 . S2CID 52164892 .

[5] Светлик, Джо (31 мая 2018 г.). «Описание формата изображения JPEG» . BT.com . Группа БТ . Архивировано из оригинала 5 августа 2019 года . Проверено 5 августа 2019 г.

[6] Баранюк, Крис (15 октября 2015 г.). «Защита от копирования может появиться в формате JPEG» . Новости Би-би-си . Би-би-си . Архивировано из оригинала 9 октября 2019 года . Проверено 13 сентября 2019 г.

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

[Atlantic-8] Каплан, Пол (24 сентября 2013 г.). «Что такое JPEG? Невидимый объект, который вы видите каждый день» . Атлантика . Архивировано из оригинала 9 октября 2019 года . Проверено 13 сентября 2019 г.

[9] «HTTP-архив – интересная статистика» . httparchive.org . Проверено 6 апреля 2016 г.

[10] «Определение типа MIME в Internet Explorer» . Майкрософт. 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] Перейти обратно: ^а ^б ^с ^д Лемос, Роберт (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] Перейти обратно: ^а ^б ISO/IEC JTC 1/SC 29. «Программа работы (перенесена в SC 29/WG 1)» . Архивировано из оригинала 31 декабря 2013 года . Проверено 7 ноября 2009 г. {{cite web}}: CS1 maint: числовые имена: список авторов ( ссылка )

[16] ИСО. «JTC 1/SC 29 – Кодирование аудио, изображений, мультимедиа и гипермедийной информации» . Архивировано из оригинала 3 июля 2010 года . Проверено 11 ноября 2009 г.

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

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

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

[20] ИСО. «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-е изд . Экма Интернешнл . 2009. Архивировано из оригинала 14 января 2021 года . Проверено 1 августа 2011 г.

[24] «Патент Форджента на JPEG» . СоурсФордж . 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 . Архивировано из оригинала 20 января 2023 года . Проверено 20 января 2023 г.

[reexam-28] «Ведомство по товарным знакам пересматривает патент на подделку JPEG» . Публикация.com . 3 февраля 2006 г. Архивировано из оригинала 15 мая 2016 г. . Проверено 28 января 2009 г.

[29] «ВПТЗ США: самые широкие претензии ложны, утверждения против стандарта JPEG недействительны» . Гроклав.нет . 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] «Свидетельство о повторной экспертизе ex parte на патент США № 5 253 341» . Архивировано из оригинала 2 июня 2008 года.

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

[GPHLaw3-34] «Награда в размере 5000 долларов за имя следопыта троллей: Рэй Ниро хочет знать, кто говорит о нем все эти гадости» . 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 отклонена (и отвергнута заочно)» . 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 . Майкрософт. Архивировано из оригинала 19 ноября 2012 года . Проверено 23 марта 2012 г.

[42] Фаствидео (май 2019). «12-битный кодер JPEG на графическом процессоре» . Архивировано из оригинала 6 мая 2019 года . Проверено 6 мая 2019 г.

[43] «Почему всегда следует поворачивать оригинальные фотографии JPEG без потерь» . Petapixel.com . 14 августа 2012 года. Архивировано из оригинала 17 октября 2017 года . Проверено 16 октября 2017 г.

[44] «Формат файла JFIF в формате PDF» (PDF) . Архивировано (PDF) из оригинала 13 января 2021 года . Проверено 19 июня 2006 г.

[45] Том Лейн (29 марта 1999 г.). «Часто задаваемые вопросы по сжатию изображений JPEG» . Архивировано из оригинала 10 ноября 2010 года . Проверено 11 сентября 2007 г. (вопрос 14: «К чему все эти споры о форматах файлов?»)

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

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

[auto1-48] Перейти обратно: ^а ^б «МЭК 61966-2-1:1999/AMD1:2003 | Интернет-магазин МЭК» . webstore.iec.ch . Архивировано из оригинала 18 февраля 2022 года . Проверено 18 февраля 2022 г.

[49] «ИСО/МЭК 10918-1: 1993(Е) стр.36» . Архивировано из оригинала 1 августа 2011 года . Проверено 30 ноября 2007 г.

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

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

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

[dinhpatry-53] Перейти обратно: ^а ^б Фук-Ту Ле Динь и Жак Патри. Артефакты сжатия видео и шумоподавление MPEG. Архивировано 14 марта 2006 г. на Wayback Machine . Видеоизображение DesignLine. 24 февраля 2006 г. Проверено 28 мая 2009 г.

[54] « 3.9 Комариный шум: форма искажения краевой занятости, иногда связанная с движением, характеризующаяся движущимися артефактами и / или пятнистыми шумовыми рисунками, наложенными на объекты (напоминающими комара, летающего вокруг головы и плеч человека)». Рек. МСЭ-Т. P.930 (08/96) Принципы системы эталонного искажения видео. Архивировано 16 февраля 2010 г. на Wayback Machine.

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

[Bauermann-56] Перейти обратно: ^а ^б И. Бауэрман и Э. Штайнбач. Дальнейшее сжатие изображений JPEG без потерь. Учеб. Симпозиума по кодированию изображений (PCS 2004), Сан-Франциско, США, 15–17 декабря 2004 г.

[Ponomarenko-57] Перейти обратно: ^а ^б Н. Пономаренко, К. Егиазарян, В. Лукин и Я. Астола. Дополнительное сжатие изображений JPEG без потерь, Учеб. 4-го Международного Материалы симпозиума по обработке и анализу изображений и сигналов (ISPA 2005), Загреб, Хорватия, стр. 107–111. 117–120, 15–17 сентября 2005 г.

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

[matsuda-59] Перейти обратно: ^а ^б ^с Ичиро Мацуда, Юкио Номото, Кей Вакабаяши и Сусуму Ито. Перекодирование изображений JPEG без потерь с использованием блочно-адаптивного внутреннего предсказания. Материалы 16-й Европейской конференции по обработке сигналов (EUSIPCO 2008).

[60] Штирнер, Матиас (19 февраля 2023 г.). "packjpg/packJPG" . Гитхаб . Архивировано из оригинала 2 марта 2023 года . Проверено 2 марта 2023 г.

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

[62] Тим Кемп, файлы JPS , заархивированные 18 января 2009 г. на Wayback Machine.

[63] «CGImageSource.SupportedTypes» . Плагин Claris FileMaker MBS . Программное обеспечение MonkeyBread. Архивировано из оригинала 30 декабря 2020 года . Проверено 21 мая 2023 г.

[64] «Формат нескольких изображений» (PDF) . 2009. Архивировано из оригинала (PDF) 5 апреля 2016 года . Проверено 30 декабря 2015 г.

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

[66] Алессандро Ортис; Себастьяно Баттиато (2015), Ситник, Роберт; Пьюх, Уильям (ред.), «Новый метод быстрого сопоставления для адаптивного сжатия стереоскопических изображений» , Обработка трехмерных изображений , Обработка трехмерных изображений, измерение (3DIPM) и приложения 2015, 9393 , SPIE — Трехмерные Обработка изображений, измерение (3DIPM) и приложения 2015: 93930K, Bibcode : 2015SPIE.9393E..0KO , doi : 10.1117/12.2086372 , S2CID 18879942 , заархивировано из оригинала 3 марта 2016 г. , получено 30 апреля 2015 г.

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

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

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

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

[Chromium-71] Проблема 48789 — хром — используйте libjpeg-turbo вместо libjpeg. Архивировано 1 августа 2015 г. на Wayback Machine . 14 апреля 2011 г.

[refimpl-72] «ISO/IEC 10918-7: 2019 Информационные технологии. Цифровое сжатие и кодирование неподвижных изображений с непрерывным тоном. Часть 7. Справочное программное обеспечение» . ИСО . Архивировано из оригинала 7 мая 2022 года . Проверено 7 мая 2022 г. «T.873 (19 мая): Информационные технологии. Цифровое сжатие и кодирование неподвижных изображений с непрерывным тоном: Справочное программное обеспечение» . www.itu.int . Архивировано из оригинала 2 июня 2022 года . Проверено 1 марта 2023 г.

[73] «JPEG — JPEG XT» . jpeg.org . Архивировано из оригинала 4 марта 2018 года . Проверено 3 марта 2018 г.

[74] Рихтер, Томас (сентябрь 2016 г.). «JPEG на стероидах: общие методы оптимизации сжатия изображений JPEG». Международная конференция IEEE по обработке изображений (ICIP) , 2016 г. стр. 61–65. дои : 10.1109/ICIP.2016.7532319 . ISBN 978-1-4673-9961-6 . S2CID 14922251 .

[75] «Представляем проект «mozjpeg»» . Исследование Мозиллы . 5 марта 2014 г. Архивировано из оригинала 1 марта 2023 г. Проверено 1 марта 2023 г.

[76] «Анонсируем Guetzli: новый кодировщик JPEG с открытым исходным кодом» . Research.googleblog.com . 16 марта 2017 года. Архивировано из оригинала 6 октября 2017 года . Проверено 16 октября 2017 г.

[77] «Представляем Jpegli: новую библиотеку кодирования JPEG» . Блог Google с открытым исходным кодом. 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] Алакуйала, Юрки; из Ассельдонка, Рууд; Букортт, Сами; Брюс, Мартин; Соседка Юлия-Мария; Фиршинг, Мориц; Фишбахер, Томас; Ключников Евгений; Гомес, Себастьян; Обрик, Роберт; Потемпа, Кристофер; Ратушняк, Александр; Снейерс, Джон; Шабадка, Золтан; Вандервенн, Лоде; Версари, Люк; Вассенберг, январь (6 сентября 2019 г.). «Архитектура сжатия изображений нового поколения JPEG XL и инструменты кодирования» . В Тешере, Эндрю Дж.; Эбрахими, Турадж (ред.). Применение цифровой обработки изображений XLII . Том. 11137. с. 20. Бибкод : 2019SPIE11137E..0KA . дои : 10.1117/12.2529237 . ISBN 978-1-5106-2967-7 . S2CID 202785129 . Архивировано из оригинала 26 декабря 2021 года . Проверено 26 декабря 2021 г.

[jpegxl_committeedraft-81] Ратушняк, Александр; Вассенберг, Ян; Снейерс, Джон; Алакуйала, Юрки; Вандевенн, Лоде; Версари, Люк; Обрик, Роберт; Шабадка, Золтан; Ключников Евгений; Комса, Юлия-Мария; Потемпа, Кристофер; Брюс, Мартин; Фиршинг, Мориц; Хасанова Рената; Красный Ассельдонка; Букортт, Сами; Гомес, Себастьян; Фишбахер, Томас (2019). «Проект комитета системы кодирования изображений JPEG XL». arXiv : 1908.03565 [ eess.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 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