Joint photographic experts group

Overview of JPEG

The JPEG standard (ISO/IEC 10918) was created in 1992 (latest version, 1994) as the result of a process that started in 1986. Though, this standard is generally considered as a single specification, in reality it is composed of four separate parts and an amalgam of coding modes.

Part 1 of JPEG (ISO/IEC 10918-1 | ITU-T Recommendation T.81) specifies the core coding technology and it incorporates many options for encoding photographic images. Part 2 defines the compliance testing. Part 3 defines a set of extensions to the coding technologies of Part 1, and via an amendment the SPIFF file format was introduced. Part 4 focuses on the registration of JPEG profiles, SPIFF profiles, SPIFF tags, SPIFF color spaces, SPIFF compression types, and defines the Registration Authorities. And lastly, Part 5 specifies the JPEG File Interchange Format (JFIF). Without any doubt, it can be stated that JPEG has been one of the most successful multimedia standards defined so far.

While JPEG (Rec. ITU T.81 | ISO/IEC 10918) is still the most dominant still image format around, it may seem surprising that ISO/IEC never provided a reference software demonstrating a proper implementation of the standard. Therefore, JPEG initiated an initiative to create a new reference implementation for ISO/IEC 10918. More information on the call can be found here.

JPEG currently includes the following parts:

Part 1: Requirements and guidelines

Specifies the core coding system, consisting of the well-known Huffman-coded DCT based lossy image format, but also including the arithmetic coding option, lossless coding and hierarchical coding.

Part 2: Compliance testing

Specifies conformance testing, and as such provides test procedures and test data to test JPEG encoders and decoders for conformance.

Part 3: Extensions

Specifies various extensions of the JPEG format, as such spatially variable quantization, tiling, selective refinement and the SPIFF file format.

Part 4: Registration authorities

Registers known application markers, SPIFF tags profiles, compression types and registration authorities.

Part 5: File Interchange Format

Specifies the JPEG File Interchange Format (JFIF) which includes the chroma upsampling and YCbCr to RGB transformation.

Part 6: Application to printing systems

Specifies markers that refine the colour space interpretation of JPEG codestreams, such as to enable the embedding of ICC profiles and to allow the encoding in the CMYK colour model.

Part 7: Reference Software

Provides JPEG Reference Software implementations.

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

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

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

Содержание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

МаркерБайтыДлинаНазначениеКомментарии
SOI0xFFD8нетНачало изображения
SOF00xFFC0переменный размерНачало фрейма (базовый, ДКП)Показывает, что изображение кодировалось в базовом режиме с использованием ДКП и кода Хаффмана. Маркер содержит число строк и длину строки изображения (двухбайтовые поля со смещением соответственно 5 и 7 относительно начала маркера), количество компонентов (байтовое поле со смещением 9 относительно начала маркера), число бит на компонент — строго 8 (байтовое поле со смещением 4 относительно начала маркера), а также соотношение компонентов (например, 4:2:0).
SOF10xFFC1переменный размерНачало фрейма (расширенный, ДКП, код Хаффмана)Показывает, что изображение кодировалось в расширенном (extended) режиме с использованием ДКП и кода Хаффмана. Маркер содержит число строк и длину строки изображения, количество компонентов, число бит на компонент (8 или 12), а также соотношение компонентов (например, 4:2:0).
SOF20xFFC2переменный размерНачало фрейма (прогрессивный, ДКП, код Хаффмана)Показывает, что изображение кодировалось в прогрессивном режиме с использованием ДКП и кода Хаффмана. Маркер содержит число строк и длину строки изображения, количество компонентов, число бит на компонент (8 или 12), а также соотношение компонентов (например, 4:2:0).
DHT0xFFC4переменный размерСодержит таблицы ХаффманаЗадает одну или более таблиц Хаффмана.
DQT0xFFDBпеременный размерСодержит таблицы квантованияЗадает одну или более таблиц квантования.
DRI0xFFDD4 байтаУказывает длину рестарт-интервалаЗадает интервал между маркерами RST n в макроблоках. При отсутствии DRI появление в потоке кодированных данных маркеров RSTn недопустимо и считается ошибкой. Если при кодировании маркеры RST n не применяются, маркер DRI либо не используется вовсе, либо интервал повторений в нём указывается равным 0.
SOS0xFFDAпеременный размерНачало сканированияНачало первого или очередного скана изображения с направлением обхода слева направо сверху вниз. Если использовался базовый режим кодирования, используется один скан. При использовании прогрессивных режимов используется несколько сканов. Маркер SOS является разделяющим между информативной (заголовком) и закодированной (собственно сжатыми данными) частями изображения.
RSTn0xFFDnнетПерезапускМаркеры перезапуска используются для сегментирования кодированных энтропийным кодером данных. В каждом сегменте данные декодируются независимо, что позволяет распараллелить процедуру декодирования. При повреждении кодированных данных в процессе передачи или хранения JPEG-файла использование маркеров перезапуска позволяет ограничить потери (макроблоки из неповреждённых сегментов будут восстановлены правильно). Вставляется в каждом r-м макроблоке, где r — интервал перезапуска DRI маркера. Не используется при отсутствии DRI маркера. n, младшие 3 бита маркера кода, циклы от 0 до 7.
APPn0xFFEnпеременный размерЗадаётся приложениемНапример, в EXIF JPEG-файла используется маркер APP1 для хранения метаданных, расположенных в структуре, основанной на TIFF.
COM0xFFFEпеременный размерКомментарийСодержит текст комментария.
EOI0xFFD9нетКонец закодированной части изображения.

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

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

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

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

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

The Joint Photographic Experts Group (JPEG) is the joint committee between ISO/IEC JTC 1 and ITU-T (formerly CCITT) that created and maintains the JPEG, JPEG 2000, and JPEG XR standards. It is one of two sub-groups of ISO/IEC Joint Technical Committee 1, Subcommittee 29, Working Group 1 (ISO/IEC JTC 1/SC 29/WG 1) – titled as Coding of still pictures. [1] [2] [3] In the ITU-T, its work falls in the domain of the ITU-T Visual Coding Experts Group (VCEG). ISO/IEC JTC1 SC29 Working Group 1 (working together with ITU-T Study Group 16 – SG16 [4] and previously also with Study Group 8 – SG8 [5] [6] ) is responsible for the JPEG and JBIG standards. [7] The scope of the organization includes the work of both the Joint Photographic Experts Group and Joint Bi-level Image Experts Group. [1] [8]

In April 1983, ISO started to work to add photo quality graphics to text terminals. In the m >[9] [10] They were historically targeted on image communication. In 1986, it was dec >[11] The JPEG committee was created in 1986. [12] In 1988, it was dec >[11] The group typically meets three times annually in North America, Asia and Europe. The group often meets jointly with the JBIG committee. [10] [13] The current JPEG pres >[14] [15] who was previously chairman of the JPEG 2000 development group [16] and led the MPEG-4 standards committee. [17]

Contents

Joint Bi-level Image experts Group [ edit ]

The Joint Bi-level Image experts Group (JBIG) is the second sub-group of the same working group (ISO/IEC JTC 1/SC 29/WG 1) as the Joint Photographic Experts Group, which focuses on binary images. [1] They created the JBIG and JBIG2 standard. [7] [13]

Standards published and under development [ edit ]

The JPEG (Joint Photographic Experts Group) as a sub-group of ISO/IEC JTC 1/SC 29/WG 1 – Coding of Still Pictures (working as a joint team with ITU-T SG 16) have developed various standards, which have been published by ITU-T and/or ISO/IEC. The standards developed by the JPEG and JBIG sub-groups are referred to as a joint development of ISO/IEC JTC 1/SC 29/WG 1 and ITU-T SG 16. The JPEG standards consist of different Parts. Each part covers a certain aspect of the whole specification. Some of the published JPEG standards were revised by later amendments and/or new editions. Standards developed and under development by JPEG are shown in the table below. [2] [18]

Joint Photographic Experts Group — standards published and under development

Common NamePartFirst public release date (First edition)ISO/IEC NumberITU NumberFormal Title
JPEGPart 11992ISO/IEC 10918-1ITU-T Rec. T.81Information technology – Digital compression and coding of continuous-tone still images – Requirements and guidelines
Part 21994ISO/IEC 10918-2ITU-T Rec. T.83Information technology – Digital compression and coding of continuous-tone still images – Compliance testing
Part 31996ISO/IEC 10918-3ITU-T Rec. T.84Information technology – Digital compression and coding of continuous-tone still images: Extensions
Part 41998ISO/IEC 10918-4ITU-T Rec. T.86Information technology – Digital compression and coding of continuous-tone still images: Registration of JPEG profiles, SPIFF profiles, SPIFF tags, SPIFF colour spaces, APPn markers, SPIFF compression types and Registration Authorities (REGAUT)
Part 52013ISO/IEC 10918-5ITU-T Rec. T.871Information technology – Digital compression and coding of continuous-tone still images: JPEG File Interchange Format (JFIF) [19]
Part 62013ISO/IEC 10918-6ITU-T Rec. T.872Information technology – Digital compression and coding of continuous-tone still images: Application to printing systems
Part 72019ISO/IEC 10918-7ITU-T Rec. T.873Information technology – Digital compression and coding of continuous-tone still images: Reference software [20]
JPEG-LSPart 11998ISO/IEC 14495-1ITU-T Rec. T.87Information technology – Lossless and near-lossless compression of continuous-tone still images: Baseline
Part 22002ISO/IEC 14495-2ITU-T Rec. T.870Information technology – Lossless and near-lossless compression of continuous-tone still images: Extensions
JPEG 2000Part 12000ISO/IEC 15444-1ITU-T Rec. T.800Information technology – JPEG 2000 image coding system – Core coding system
Part 22004ISO/IEC 15444-2ITU-T Rec. T.801Information technology – JPEG 2000 image coding system: Extensions
Part 32002ISO/IEC 15444-3ITU-T Rec. T.802Information technology – JPEG 2000 image coding system: Motion JPEG 2000
Part 42002ISO/IEC 15444-4ITU-T Rec. T.803Information technology – JPEG 2000 image coding system: Conformance testing
Part 52003ISO/IEC 15444-5ITU-T Rec. T.804Information technology – JPEG 2000 image coding system: Reference software
Part 62003ISO/IEC 15444-6ITU-T Rec. T.805Information technology – JPEG 2000 image coding system: Compound image file format
Part 82007ISO/IEC 15444-8ITU-T Rec. T.807Information technology – JPEG 2000 image coding system: Secure JPEG 2000
Part 92005ISO/IEC 15444-9ITU-T Rec. T.808Information technology – JPEG 2000 image coding system: Interactivity tools, APIs and protocols
Part 102008ISO/IEC 15444-10ITU-T Rec. T.809Information technology –JPEG 2000 image coding system: Extensions for three-dimensional data
Part 112007ISO/IEC 15444-11ITU-T Rec. T.810Information technology – JPEG 2000 image coding system: Wireless
Part 122004ISO/IEC 15444-12Information technology – JPEG 2000 image coding system – Part 12: ISO base media file format
Part 132008ISO/IEC 15444-13ITU-T Rec. T.812Information technology – JPEG 2000 image coding system: An entry level JPEG 2000 encoder
Part 142013ISO/IEC 15444-14ITU-T Rec. T.813Information technology – JPEG 2000 image coding system: XML structural representation and reference
MRC1999ISO/IEC 16485ITU-T Rec. T.44Information technology – Mixed Raster Content (MRC)
JPSearchPart 12007ISO/IEC TR 24800-1Information technology – JPSearch – Part 1: System framework and components
Part 22011ISO/IEC 24800-2Information technology – JPSearch – Part 2: Registration, identification and management of schema and ontology
Part 32010ISO/IEC 24800-3Information technology – JPSearch – Part 3: Query format
Part 42010ISO/IEC 24800-4Information technology – JPSearch – Part 4: File format for metadata embedded in image data (JPEG and JPEG 2000)
Part 52011ISO/IEC 24800-5Information technology – JPSearch – Part 5: Data interchange format between image repositories
Part 62012ISO/IEC 24800-6Information technology – JPSearch – Part 6: Reference software
JPEG XRPart 12011ISO/IEC TR 29199-1T.Sup2Information technology – JPEG XR image coding system – Part 1: System architecture
Part 22009ISO/IEC 29199-2ITU-T Rec. T.832Information technology – JPEG XR image coding system – Part 2: Image coding specification
Part 32010ISO/IEC 29199-3ITU-T Rec. T.833Information technology – JPEG XR image coding system – Part 3: Motion JPEG XR
Part 42010ISO/IEC 29199-4ITU-T Rec. T.834Information technology – JPEG XR image coding system – Part 4: Conformance testing
Part 52010ISO/IEC 29199-5ITU-T Rec. T.835Information technology – JPEG XR image coding system – Part 5: Reference software
AICPart 12017ISO/IEC TR 29170-1Information technology – Advanced image coding and evaluation methodologies – Part 1: Guidelines for codec evaluation
Part 22015ISO/IEC 29170-2Information technology – Advanced image coding and evaluation – Part 2: Evaluation procedure for nearly lossless coding
JPEG XTPart 12015ISO/IEC 18477-1Information technology – Scalable Compression and Coding of Continuous-Tone Still Images – Part 1: Core Coding System Specification
Part 22016ISO/IEC 18477-2Information technology – Scalable Compression and Coding of Continuous-Tone Still Images – Part 2: Coding of High Dynamic Range Images
Part 32015ISO/IEC 18477-3Information technology – Scalable Compression and Coding of Continuous-Tone Still Images – Part 3: Box file format
Part 42017ISO/IEC 18477-4Information technology – Scalable Compression and Coding of Continuous-Tone Still Images – Part 4: Conformance Testing
Part 52018ISO/IEC 18477-5Information technology – Scalable Compression and Coding of Continuous-Tone Still Images – Part 5: Reference software
Part 62016ISO/IEC 18477-6Information technology – Scalable Compression and Coding of Continuous-Tone Still Images – Part 6: IDR Integer coding
Part 72017ISO/IEC 18477-7Information technology – Scalable Compression and Coding of Continuous-Tone Still Images – Part 7: HDR Floating-Point Coding
Part 82016ISO/IEC 18477-8Information technology – Scalable Compression and Coding of Continuous-Tone Still Images – Part 8: Lossless and Near-lossless Coding
Part 92016ISO/IEC 18477-9Information technology – Scalable Compression and Coding of Continuous-Tone Still Images – Part 9: Alpha channel coding

JPEG XL [ edit ]

In 2017, JTC1/SC29/WG1 issued a Call for proposals for JPEG XL – the next generation image coding standard. [21] The standard is expected to follow still image compression performance shown by HEVC HM, Daala and WebP. The core requirements include better compression efficiency, 8–10 bits per component, RGB/YCbCr/ICtCp color encoding, animated images, alpha channel coding, Rec.709 color space and gamma, Rec.2100 w >[22] The current target publication date is October 2019. [23] The reference software implementation of JPEG XL will losslessly transcode JPEG images while reducing their size by 20%, [24] and will also include lightweight lossless conversion to JPEG for backward compatibility.

Оцените статью
Много толка
Добавить комментарий