JPEG

From Just Solve the File Format Problem
(Difference between revisions)
Jump to: navigation, search
m
m (→‎Sample files)
 
(79 intermediate revisions by 10 users not shown)
Line 2: Line 2:
 
|formattype=electronic
 
|formattype=electronic
 
|subcat=Graphics
 
|subcat=Graphics
−
|extensions={{ext|jpg}}<br>{{ext|jpeg}}<br>{{ext|jpe}}<br>{{ext|jif}}<br>{{ext|jfif}}<br>{{ext|jfi}}
+
|thiscat=JPEG
 +
|extensions={{ext|jpg}}, {{ext|jpeg}}, {{ext|jpe}}, {{ext|jif}}
 
|mimetypes={{mimetype|image/jpeg}}
 
|mimetypes={{mimetype|image/jpeg}}
 +
|locfdd={{LoCFDD|fdd000017}}, others
 +
|pronom={{PRONOM|fmt/41}}, others
 +
|wikidata={{wikidata|Q27996264}}
 +
|released=1992
 +
|kaitai struct=jpeg
 
}}
 
}}
−
'''JPEG''', named after the Joint Photographic Experts Group, which created the format, is a lossy compressed format well-suited to photographic images. Line drawings do better with non-lossy compressed bitmaps such as [[GIF]] and [[PNG]].
+
'''JPEG''' is a popular raster image format well-suited to photographic images. It usually uses lossy [[DCT compression]]. It is named after the Joint Photographic Experts Group, the organization which developed the format. It is sometimes called '''JPEG1''', '''JPEG-1''', or '''JPEG 1992''' to help disambiguate it. (Also see [[JPEG 2000]] and [[JP2]].)
  
−
Depending on context, "JPEG" may mean the compression algorithm, or the ''JPEG interchange format'' (JIF) defined in the JPEG standard.
+
== Terminology ==
 +
''(In which we discuss the tired old question of whether JPEG is a file format, or a compression standard)''
  
 +
In the original specification (ITU-T Rec. T.81), the term ''JPEG'' refers only to an organization. The serialized form of the compression format it defines is referred to only as the "interchange format".
 +
 +
The followup ITU-T Rec. T.84 document says that ''JPEG'' can also refer to a set of ''standards'', including at least Rec. T.81, Rec. T.83, and Rec. T.84. It also informally uses ''JPEG'' to refer to the Rec. T.81 interchange format.
 +
 +
ITU-T Rec. T.851 refers to the interchange format as ''JPEG-1''.
 +
 +
The interchange format is ''almost'' a full-fledged portable file format, lacking only standard conventions and/or standard metadata elements to tell how to interpret it as an image. The missing pieces can be added in various ways. Some file formats, including [[JFIF]], do so in such a way that the interchange format is used directly as a file format. In practice, the term ''JPEG'' often refers to the family of such file formats, and this usage does not seem unreasonable, especially since there is no other suitable name. The term '''JIF''' (for ''JPEG Interchange Format'') has been tossed around, but it is an ambiguous term that doesn't necessarily refer to a file format, and it's unusable in practice due to similarity to [[GIF]].
 +
 +
It could be that ''JPEG'' is sometimes misused to mean [[JFIF]], but such an accusation might be relying on the incorrect assumption that '''.jpg''' files always use JFIF format.
 +
 +
== Portability ==
 
In and of itself, JPEG is not really a suitable format for image interchange, for several reasons:
 
In and of itself, JPEG is not really a suitable format for image interchange, for several reasons:
 
* It essentially only defines a way to store one or more arrays of numbers. It does not say how to interpret those numbers as an image. The decoder will just have to guess.
 
* It essentially only defines a way to store one or more arrays of numbers. It does not say how to interpret those numbers as an image. The decoder will just have to guess.
−
* It is large and general, and it would be unrealistic to expect every decoder to support all of it.
+
* It is large and general, and it might be unrealistic to expect every decoder to support all of it.
−
* It has no standard way to store metadata.
+
* It defines no standard metadata elements.
  
−
To address these issues, a number of JPEG subformats have been invented. [[JFIF]] is by far the most popular of them, though a significant minority of JPEG files use [[Exif]]/JPEG instead. The [[SPIFF]] file format was intended as a replacement for JFIF but never caught on widely.
+
To address these issues, a number of JPEG subformats have been invented. [[JFIF]] is by far the most popular of them, though a significant minority of JPEG files use [[Exif]] instead. The [[SPIFF]] file format was intended as a replacement for JFIF, but never caught on.
  
−
== Format ==
+
In practice, a portable JPEG file is pretty much "whatever the libjpeg software supports". This includes some varieties (such as RGB color) that do not conform to JFIF, and excludes some (such as lossless JPEG) that do.
  
−
A JPEG file consists largely of a sequence of tagged segments. Each segment begins with a two-byte "marker". The first byte of a marker is 0xff. The second may have any value except 0x00 or 0xff, and indicates the type of data stored in the segment. Segment types are assigned names; for example, 0xd9 is "SOI", and 0xe1 is "APP1".
+
== Format ==
 +
A JPEG file consists largely of a sequence of tagged segments. Each segment begins with a two-byte "marker". (The term "marker" is often used to refer to the entire segment.) The first byte of a marker is 0xff. The second may have any value except 0x00 or 0xff, and indicates the type of data stored in the segment. Segment types are assigned names; for example, 0xd9 is "SOI", and 0xe1 is "APP1".
  
 
Segment types 0x01, and 0xd0 through 0xd9, consist entirely of the two-byte marker. All other markers are followed by a two-byte integer indicating the size of the segment, followed by the payload data contained in the segment.
 
Segment types 0x01, and 0xd0 through 0xd9, consist entirely of the two-byte marker. All other markers are followed by a two-byte integer indicating the size of the segment, followed by the payload data contained in the segment.
  
−
The image data is the exception to this segmented format. It appears between the 0xda ("SOS") and 0xd9 ("EOI") segments, but there is no prefix to indicate its size. Instead, any 0xff bytes in the image data are escaped as 0xff 0x00, so that they won't be mistaken for markers.
+
The image data is the exception to this segmented format. It appears following an "SOS" (0xda) segment, but there is no prefix to indicate its size. Instead, any 0xff bytes in the image data are escaped as 0xff 0x00, so that they won't be mistaken for markers. (Note that some JPEG-like formats, such as [[JPEG-LS]] and [[JPEG 2000 codestream]], use different rules for escaping 0xff bytes.)
−
 
+
−
== Application segments ==
+
  
 +
=== Application segments ===
 
There are 16 segment types reserved for application-specific data: 0xe0 ("APP0") through 0xef ("APP15").
 
There are 16 segment types reserved for application-specific data: 0xe0 ("APP0") through 0xef ("APP15").
  
−
An APP segment's data usually begins with NUL-terminated string to identify the type of data contained in it. The actual payload data then begins after the NUL byte. This is a convention, not a part of the JPEG specification.
+
An APP segment's data often begins with NUL-terminated text string to identify the type of data contained in it. The actual payload data then begins after the NUL byte. This convention was standardized by ISO/IEC 10918-4:1999 (see ITU-T Rec. T.86), but is not as universal as one might hope. Most APP segments do have a signature of some sort, but because there is no simple matching algorithm that always works, identifying the signature can be difficult.
  
−
== Related Formats ==
+
== Identifiers ==
 +
{| class="wikitable"
 +
! Format
 +
! PRONOM
 +
! LoCFDD
 +
|-
 +
|JPEG            || {{PRONOM|fmt/41}}    || {{LoCFDD|fdd000017}}
 +
|-
 +
|Baseline JPEG    ||                      || {{LoCFDD|fdd000149}}
 +
|-
 +
|Progressive JPEG ||                      || {{LoCFDD|fdd000333}}
 +
|-
 +
|[[Lossless JPEG (original)|Lossless JPEG]] ||  || {{LoCFDD|fdd000334}}
 +
|-
 +
|Other JPEG      ||                      || {{LoCFDD|fdd000150}}
 +
|-
 +
|JFIF 1.00        || {{PRONOM|fmt/42}}
 +
|-
 +
|JFIF 1.01        || {{PRONOM|fmt/43}}
 +
|-
 +
|[[JFIF]] 1.02    || {{PRONOM|fmt/44}}    || {{LoCFDD|fdd000018}}
 +
|-
 +
|Exif 2.0 JPEG    || {{PRONOM|x-fmt/398}} ||rowspan="5"| {{LoCFDD|fdd000147}}
 +
|-
 +
|Exif 2.1 JPEG    || {{PRONOM|x-fmt/390}}
 +
|-
 +
|[[Exif]] 2.2 JPEG || {{PRONOM|x-fmt/391}}
 +
|-
 +
|Exif 2.21 JPEG    || {{PRONOM|fmt/645}}
 +
|-
 +
|Exif 2.3.x JPEG    || {{PRONOM|fmt/1507}}
 +
|-
 +
|[[SPIFF]]        || {{PRONOM|fmt/112}}  || {{LoCFDD|fdd000019}}
 +
|}
  
−
[[ICC profile]] data is contained in an APP2 "ICC_PROFILE" segment.
+
== Identification ==
 +
JPEG files begin with bytes <code>ff d8 ff</code>.
  
−
The [[Exif]] standard uses an APP1 "Exif" segment.
+
However, this does not distinguish them from [[JPEG-LS]]. To do that reliably, one may have to scan the file to look for one of the valid SOF segment types.
  
−
[[FlashPix]] data is contained in APP2 "FPXR" segments in Exif-compliant JPEGs. Refer to the [[Exif]] specification.
+
== Types of JPEG files ==
 +
The following types are not disjoint. For example, a progressive JPEG may use arithmetic coding.
  
−
[[Photoshop Image Resources]] is contained in an APP13 "Photoshop 3.0" segment.
+
Some JPEG images do not belong to any of these types. An SOF1 segment is used if no other SOF segment applies.
  
−
[[IPTC]] metadata often appears in JPEG files, embedded in [[Photoshop Image Resources]].
+
=== Baseline ===
 +
JPEGs with an SOF0 segment are known as ''Baseline'' JPEGs. They are always lossy, not progressive, use Huffman coding, and have a bit depth of 8. Every application that supports JPEG is supposed to at least support Baseline JPEG.
  
−
[[XMP]] metadata is contained in an APP1 <nowiki>"http://ns.adobe.com/xap/1.0/"</nowiki> segment.
+
=== Progressive ===
 +
Progressive JPEG rearranges the image data, so that the the first part of it represents a very low quality version of the entire image, rather than a high quality version of a small part of the image.
  
−
Many other file formats, such as [[TIFF]], [[MNG]], and [[DICOM]], can contain JPEG-compressed data or encapsulated JPEG files.
+
A progressive JPEG is identified by the presence of an SOF2, SOF6, SOF10, or SOF14 segment.
 +
 
 +
=== Non-interleaved ===
 +
Color JPEG images may be either ''interleaved'' or ''non-interleaved''.
 +
 
 +
In an interleaved JPEG, all the color components (e.g. Y, Cb, Cr) for a pixel are stored close together in the file.
 +
 
 +
In a non-interleaved JPEG, the image is separated into its color components, and each component is stored separately in the file.
 +
 
 +
Interleaving is not a simple yes/no option, because a single image may use both interleaved and non-interleaved scans (SOS segments) – in fact, progressive JPEGs usually do just that. Some JPEG decoders do not support non-interleaved images unless they use progressive encoding.
 +
 
 +
=== Arithmetic coding ===
 +
Even lossy JPEG makes use of a lossless compression algorithm. The lossless algorithm is usually [[Huffman coding]], but [[arithmetic coding]] may be used instead. JPEG's arithmetic coding usually results in a smaller file size, but it is not as widely supported as one might hope, probably because it used to be encumbered by [[patents]].
 +
 
 +
An arithmetic-coded JPEG is identified by the presence of an SOF9, SOF10, SOF11, SOF13, SOF14, or SOF15 segment.
 +
 
 +
=== 12-bit ===
 +
Except for Baseline JPEG, all lossy types of JPEG may use a bit depth of either 8 or 12 bits per sample. However, few applications support anything other than 8 bits.
 +
 
 +
Starting with version 9a, IJG libjpeg also supports bit depths of 9, 10, and 11. These depths are nonstandard, and libjpeg's implementation is nearly unusable in practice, because it only supports a single bit depth, which must be selected at compile time.
 +
 
 +
=== Lossless JPEG ===
 +
:''Main article: [[Lossless JPEG (original)]]''
 +
 
 +
JPEG supports true lossless compression, but it is used so rarely that JPEG is commonly thought of as strictly a lossy format.
 +
 
 +
A lossless JPEG is identified by the presence of an SOF3, SOF7, SOF11, or SOF15 segment.
 +
 
 +
See also the [[Lossless JPEG|Lossless JPEG disambiguation page]], for other uses of the term.
 +
 
 +
=== Hierarchical ===
 +
Also called "differential", hierarchical JPEG is vaguely similar to progressive JPEG, but geared toward storing multiple sizes of the same image, such that the decoder can select the size it prefers. Hierarchical JPEGs are, to a close approximation, nonexistent.
 +
 
 +
A hierarchical JPEG is identified by the presence of an SOF5, SOF6, SOF7, SOF13, SOF14, or SOF15 segment.
 +
 
 +
== Color format ==
 +
There are five JPEG color types that are reasonably portable:
 +
# Grayscale
 +
# YCbCr
 +
# RGB
 +
# YCCK
 +
# CMYK
 +
 
 +
To make the compression more effective, RGB images are almost always transformed to YCbCr format when they are written to a JPEG file. However, many applications will still report that such images use "RGB" color. This may be because their authors weren't aware of the transformation, or because they considered it to be an internal part of the compression algorithm as opposed to a different colorspace. Unfortunately, this inconsistent terminology can make it hard to distinguish YCbCr JPEGs from the rare JPEGs that really do use RGB color.
 +
 
 +
YCCK is a transformed version of CMYK, and the same terminology confusion exists as with YCbCr and RGB.
 +
 
 +
The JPEG format does not have any clear way to indicate the color type of an image. Decoders usually determine the color type based on several factors:
 +
* The number of color components
 +
* The presence of a JFIF application segment
 +
* The "color transform" field of the APP14 "Adobe" segment, if present
 +
* The component ID numbers ({82, 71, 66} suggests RGB)
 +
 
 +
== SmartScale ==
 +
Starting with version 7 or 8, the IJG libjpeg software has been adding nonstandard  "SmartScale" scaling and color transform features of debatable merit<ref>[http://www.libjpeg-turbo.org/About/SmartScale A Study on the Usefulness of DCT Scaling and SmartScale]</ref><ref>[http://hardwarebug.org/2010/02/01/ijg-swings-again-and-misses/ IJG swings again, and misses]</ref>.
 +
 
 +
Notably, it is possible to achieve lossless DCT compression by setting the DCT block size to 1, and using RGB color if necessary.
 +
 
 +
Version 9 introduced a "reversible color transform" feature that can improve the compression of RGB images. Files with this feature contain a JPG8 (0xf8) segment.
 +
 
 +
== Related Formats ==
 +
* [[JFIF]] is a subformat and extension, and uses APP0 "JFIF" and APP0 "JFXX" segments.
 +
* [[SPIFF]] is a subformat and extension, and uses an APP8 "SPIFF" segment.
 +
* [[JPEG-HDR]] is an extension, and uses APP11 segments.
 +
* [[JPEG XT]] is an extension.
 +
* [[JPEG 360]] is an extension, and/or a metadata format.
 +
* [[JPS]] is an extension, and uses an APP3 "_JPSJPS_" segment.
 +
* [[Multi-Picture Format]] is an extension, and uses an APP2 "MPF" segment.
 +
* The [[Exif]] standard uses an APP1 "Exif" segment.
 +
* [[FlashPix]] data is contained in APP2 "FPXR" segments in Exif-compliant JPEGs. Refer to the [[Exif]] specification.
 +
* [[Photoshop Image Resources]] is contained in an APP13 "Photoshop 3.0" segment.
 +
* [[IPTC-IIM]] metadata often appears in JPEG files, embedded in [[Photoshop Image Resources]].
 +
* [[XMP]] metadata is contained in an APP1 <nowiki>"http://ns.adobe.com/xap/1.0/"</nowiki> segment.
 +
* [[ICC profile]] data is contained in an APP2 "ICC_PROFILE" segment.
 +
* Many other file formats, such as [[TIFF]], [[MNG]]/[[JNG]], and [[PDF]], can contain JPEG-compressed data or encapsulated JPEG files.
 +
* ''(And we heard you like JPEG...)'' JPEG files themselves often contain thumbnail images in the form of embedded JPEG files, via formats such as [[Exif]], [[Photoshop Image Resources]], or [[JFIF]].
 +
 
 +
Formats that are '''not''' compatible with JPEG include [[JPEG-LS]], [[JPEG 2000]], [[JPEG XR]], and presumably [[JPEG XL]].
  
 
== Specifications ==
 
== Specifications ==
−
* [http://www.w3.org/Graphics/JPEG/itu-t81.pdf JPEG standard]
+
* [http://www.w3.org/Graphics/JPEG/itu-t81.pdf ITU-T Rec. T.81] (originally CCITT Rec. T.81): The JPEG standard
−
* [http://www.w3.org/Graphics/JPEG/jfif3.pdf JFIF standard]
+
* [http://www.itu.int/rec/T-REC-T.83/en ITU-T Rec. T.83]: Compliance testing
 +
* [http://www.itu.int/rec/T-REC-T.84/en ITU-T Rec. T.84]: Extensions
 +
* [http://www.itu.int/rec/T-REC-T.86/en ITU-T Rec. T.86]: Registration of JPEG Profiles, etc.
 +
* [http://www.itu.int/rec/T-REC-T.851-200509-I/en ITU-T Rec. T.851]: (JPEG-1)-based still-image coding using an alternative arithmetic coder
 +
* [http://www.itu.int/rec/T-REC-T.872/en ITU-T Rec. T.872]: Application to printing systems
 +
* [https://exiftool.org/TagNames/JPEG.html#Adobe ExifTool: The APP14 "Adobe" segment]
 +
* ISO/IEC 10918: Digital compression and coding of continuous-tone still images
 +
** [http://www.iso.org/iso/catalogue_detail.htm?csnumber=18902 ISO/IEC 10918-1:1994] - Requirements and guidelines
 +
*** [http://www.iso.org/iso/catalogue_detail.htm?csnumber=41504 ISO/IEC 10918-1:1994/Cor 1:2005] - Patent information update
 +
** [http://www.iso.org/iso/catalogue_detail.htm?csnumber=20689 ISO/IEC 10918-2:1995] - Compliance testing
 +
** [http://www.iso.org/iso/catalogue_detail.htm?csnumber=25037 ISO/IEC 10918-3:1997] - Extensions
 +
*** ISO/IEC 10918-3:1997/Amd 1:1999 - Refer to [[SPIFF]]
 +
** [http://www.iso.org/iso/catalogue_detail.htm?csnumber=25431 ISO/IEC 10918-4:1999] - Registration of JPEG profiles, ...
 +
*** [http://www.iso.org/iso/catalogue_detail.htm?csnumber=59454 ISO/IEC 10918-4:1999/Amd 1:2013] - Application specific marker list
 +
** ISO/IEC 10918-5:2013 - Refer to [[JFIF]]
 +
** [http://www.iso.org/iso/catalogue_detail.htm?csnumber=59634 ISO/IEC 10918-6:2013] - Application to printing systems
 +
** [https://www.iso.org/standard/75845.html ISO/IEC 10918-7:2019] - Reference software
 +
* [https://jpeg.org/jpegsystems/index.html ISO/IEC 19566: JPEG Systems] (a collection of JPEG-related standards)
 +
** [https://www.iso.org/standard/65348.html ISO/IEC 19566-1]: Packaging of information using codestreams and file formats
 +
** [https://www.iso.org/standard/67704.html ISO/IEC 19566-2]: Transport mechanisms and packaging
 +
** [https://www.iso.org/standard/73607.html ISO/IEC 19566-4]: Privacy, security and IPR features
 +
** [https://www.iso.org/standard/73604.html ISO/IEC 19566-5]: JPEG Universal Metadata Box Format (JUMBF)
 +
** ISO/IEC 19566-6 - Refer to [[JPEG 360]]
 +
** [https://www.iso.org/standard/78466.html ISO/IEC 19566-7]: JPEG Linked Media Format
 +
* [https://jpeg.org/downloads/jpeg/wg1n76028-CfP-JPEG-reference-software.pdf Final Call for Proposal for a JPEG Reference Software] (2017-07)
 +
 
 +
== Sample files ==
 +
* {{DexvertSamples|image/jpg}}
 +
 
 +
== Metaformat files ==
 +
* {{Synalysis|jpeg}}
 +
 
 +
== Software ==
 +
Nearly all serious graphics applications, including web browsers, support JPEG. This section primarily lists libraries and tools.
 +
 
 +
* [http://www.ijg.org/ The Independent JPEG Group's software], commonly known as ''libjpeg'' or ''IJG libjpeg''
 +
* [http://libjpeg-turbo.virtualgl.org/ libjpeg-turbo]
 +
* [https://github.com/thorfdbg/libjpeg Thomas Richter's libjpeg]: C++ library that supports all of the JPEG standard
 +
* [https://github.com/mozilla/mozjpeg/ mozjpeg: Improved JPEG encoding library from Mozilla]
 +
** [http://calendar.perfplanet.com/2014/mozjpeg-3-0/ Info on mozjpeg 3.0]
 +
* [https://research.googleblog.com/2017/03/announcing-guetzli-new-open-source-jpeg.html Guetzli] - JPEG encoder optimized for file size
 +
** [https://github.com/google/guetzli Source code at GitHub]
 +
* [http://coptr.digipres.org/Bad_Peggy Bad Peggy: scans images for problems]
 +
 
 +
== Notes ==
 +
When saving a JPEG image from [[Twitter]] in Google Chrome / Chromium, it will save with the default extension '''.jpg-large'''. This is due to a [https://code.google.com/p/chromium/issues/detail?id=172529 known bug] (and one which shows no signs of being solved any time soon) in the way the browser sanitises Twitter image URLs (the filename is determined to be e.g. Xyzxyzxyz.jpg:large, which is sanitised to Xyzxyzxyz.jpg-large).
 +
 
 +
== External links ==
 +
* [[Wikipedia:JPEG|JPEG (Wikipedia)]]
 +
* [https://exiftool.org/TagNames/JPEG.html ExifTool JPEG Tags]
 +
* [https://www.disktuna.com/list-of-jpeg-markers/ List of JPEG Markers]
 +
* [http://blog.sucuri.net/2013/07/malware-hidden-inside-jpg-exif-headers.html Malware Hidden Inside JPG EXIF Headers]
 +
* [http://www.theatlantic.com/technology/archive/2013/09/what-is-a-jpeg-the-invisible-object-you-see-every-day/279954/ What Is a JPEG? The Invisible Object You See Every Day]
 +
* [http://l0ss.elliepritts.com/ Project L0SS], a collection of images demonstrating the glitches and artifacts caused by repeatedly recompressing JPEG images
 +
* [http://thenextweb.com/insider/2014/03/05/mozilla-launches-jpeg-encoder-mozjpeg-improve-compression-rates-reduce-network-traffic-page-loads/ Mozilla launches JPEG encoder mozjpeg to reduce webpage loads, results show up to 10% decrease in file size]
 +
* [http://andreasgal.com/2014/07/15/improving-jpeg-image-encoding/ Improving JPEG image encoding]
 +
* [http://arstechnica.com/information-technology/2014/07/we-dont-need-new-image-formats-mozilla-works-to-build-a-better-jpeg/ We don’t need new image formats: Mozilla works to build a better JPEG]
 +
* [http://www.ams.org/samplings/feature-column/fcarc-image-compression Explanation of JPEG compression algorithm]
 +
* [https://github.com/lclevy/libcraw2/blob/master/docs/cr2_lossless.pdf Lossless JPEG decompression]
 +
* [http://xooyoozoo.github.io/yolo-octo-bugfixes/ Online demonstrator]- shows quality differences between similarly-sized images in [[JPEG]], [[JP2]], [[WebP]] and [[BPG]] formats
 +
* [https://github.com/mozilla/mozjpeg/issues/182 Method to improve JPEG compression that was the subject of a now-expired patent]
 +
* [https://medium.freecodecamp.com/how-jpg-works-a4dbd2316f35 How JPG Works]
 +
* [http://frdx.free.fr/JPEG_for_the_horseshoe_crabs.pdf JPEG for the horseshoe crabs]
 +
* [http://cloudinary.com/blog/why_jpeg_is_like_a_photocopier Why JPEG is like a photocopier] - discussion of generation loss in JPEG and other lossy formats (with examples)
 +
* [http://openpreservation.org/blog/2017/04/09/using-exiftool-to-address-tag-out-of-sequence-errors-in-images-and-a-101-level-dive-into-tags/ Using EXIFTool to address “Tag out of sequence” errors in images (and a 101 level dive into tags)]
 +
* [https://openpreservation.org/blog/2019/11/07/jpeg-got-the-blues/ JPEG Got the Blues] - on properly rendering 32-bit (CMYK) JPEGs
 +
* [https://yasoob.me/posts/understanding-and-writing-jpeg-decoder-in-python/ Understanding and Decoding a JPEG Image using Python]
  
 
== References ==
 
== References ==
−
* [http://en.wikipedia.org/wiki/JPEG JPEG (Wikipedia)]
+
<references/>
−
* [http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/JPEG.html ExifTool JPEG Tags]
+
 
 +
[[Category:Compression]]
 +
[[Category:JPEG (organization)]]

Latest revision as of 05:18, 28 December 2023

File Format
Name JPEG
Ontology
Extension(s) .jpg, .jpeg, .jpe, .jif
MIME Type(s) image/jpeg
LoCFDD fdd000017, others
PRONOM fmt/41, others
Wikidata ID Q27996264
Kaitai Struct Spec jpeg.ksy
Released 1992

JPEG is a popular raster image format well-suited to photographic images. It usually uses lossy DCT compression. It is named after the Joint Photographic Experts Group, the organization which developed the format. It is sometimes called JPEG1, JPEG-1, or JPEG 1992 to help disambiguate it. (Also see JPEG 2000 and JP2.)

Contents

[edit] Terminology

(In which we discuss the tired old question of whether JPEG is a file format, or a compression standard)

In the original specification (ITU-T Rec. T.81), the term JPEG refers only to an organization. The serialized form of the compression format it defines is referred to only as the "interchange format".

The followup ITU-T Rec. T.84 document says that JPEG can also refer to a set of standards, including at least Rec. T.81, Rec. T.83, and Rec. T.84. It also informally uses JPEG to refer to the Rec. T.81 interchange format.

ITU-T Rec. T.851 refers to the interchange format as JPEG-1.

The interchange format is almost a full-fledged portable file format, lacking only standard conventions and/or standard metadata elements to tell how to interpret it as an image. The missing pieces can be added in various ways. Some file formats, including JFIF, do so in such a way that the interchange format is used directly as a file format. In practice, the term JPEG often refers to the family of such file formats, and this usage does not seem unreasonable, especially since there is no other suitable name. The term JIF (for JPEG Interchange Format) has been tossed around, but it is an ambiguous term that doesn't necessarily refer to a file format, and it's unusable in practice due to similarity to GIF.

It could be that JPEG is sometimes misused to mean JFIF, but such an accusation might be relying on the incorrect assumption that .jpg files always use JFIF format.

[edit] Portability

In and of itself, JPEG is not really a suitable format for image interchange, for several reasons:

  • It essentially only defines a way to store one or more arrays of numbers. It does not say how to interpret those numbers as an image. The decoder will just have to guess.
  • It is large and general, and it might be unrealistic to expect every decoder to support all of it.
  • It defines no standard metadata elements.

To address these issues, a number of JPEG subformats have been invented. JFIF is by far the most popular of them, though a significant minority of JPEG files use Exif instead. The SPIFF file format was intended as a replacement for JFIF, but never caught on.

In practice, a portable JPEG file is pretty much "whatever the libjpeg software supports". This includes some varieties (such as RGB color) that do not conform to JFIF, and excludes some (such as lossless JPEG) that do.

[edit] Format

A JPEG file consists largely of a sequence of tagged segments. Each segment begins with a two-byte "marker". (The term "marker" is often used to refer to the entire segment.) The first byte of a marker is 0xff. The second may have any value except 0x00 or 0xff, and indicates the type of data stored in the segment. Segment types are assigned names; for example, 0xd9 is "SOI", and 0xe1 is "APP1".

Segment types 0x01, and 0xd0 through 0xd9, consist entirely of the two-byte marker. All other markers are followed by a two-byte integer indicating the size of the segment, followed by the payload data contained in the segment.

The image data is the exception to this segmented format. It appears following an "SOS" (0xda) segment, but there is no prefix to indicate its size. Instead, any 0xff bytes in the image data are escaped as 0xff 0x00, so that they won't be mistaken for markers. (Note that some JPEG-like formats, such as JPEG-LS and JPEG 2000 codestream, use different rules for escaping 0xff bytes.)

[edit] Application segments

There are 16 segment types reserved for application-specific data: 0xe0 ("APP0") through 0xef ("APP15").

An APP segment's data often begins with NUL-terminated text string to identify the type of data contained in it. The actual payload data then begins after the NUL byte. This convention was standardized by ISO/IEC 10918-4:1999 (see ITU-T Rec. T.86), but is not as universal as one might hope. Most APP segments do have a signature of some sort, but because there is no simple matching algorithm that always works, identifying the signature can be difficult.

[edit] Identifiers

Format PRONOM LoCFDD
JPEG fmt/41 fdd000017
Baseline JPEG fdd000149
Progressive JPEG fdd000333
Lossless JPEG fdd000334
Other JPEG fdd000150
JFIF 1.00 fmt/42
JFIF 1.01 fmt/43
JFIF 1.02 fmt/44 fdd000018
Exif 2.0 JPEG x-fmt/398 fdd000147
Exif 2.1 JPEG x-fmt/390
Exif 2.2 JPEG x-fmt/391
Exif 2.21 JPEG fmt/645
Exif 2.3.x JPEG fmt/1507
SPIFF fmt/112 fdd000019

[edit] Identification

JPEG files begin with bytes ff d8 ff.

However, this does not distinguish them from JPEG-LS. To do that reliably, one may have to scan the file to look for one of the valid SOF segment types.

[edit] Types of JPEG files

The following types are not disjoint. For example, a progressive JPEG may use arithmetic coding.

Some JPEG images do not belong to any of these types. An SOF1 segment is used if no other SOF segment applies.

[edit] Baseline

JPEGs with an SOF0 segment are known as Baseline JPEGs. They are always lossy, not progressive, use Huffman coding, and have a bit depth of 8. Every application that supports JPEG is supposed to at least support Baseline JPEG.

[edit] Progressive

Progressive JPEG rearranges the image data, so that the the first part of it represents a very low quality version of the entire image, rather than a high quality version of a small part of the image.

A progressive JPEG is identified by the presence of an SOF2, SOF6, SOF10, or SOF14 segment.

[edit] Non-interleaved

Color JPEG images may be either interleaved or non-interleaved.

In an interleaved JPEG, all the color components (e.g. Y, Cb, Cr) for a pixel are stored close together in the file.

In a non-interleaved JPEG, the image is separated into its color components, and each component is stored separately in the file.

Interleaving is not a simple yes/no option, because a single image may use both interleaved and non-interleaved scans (SOS segments) – in fact, progressive JPEGs usually do just that. Some JPEG decoders do not support non-interleaved images unless they use progressive encoding.

[edit] Arithmetic coding

Even lossy JPEG makes use of a lossless compression algorithm. The lossless algorithm is usually Huffman coding, but arithmetic coding may be used instead. JPEG's arithmetic coding usually results in a smaller file size, but it is not as widely supported as one might hope, probably because it used to be encumbered by patents.

An arithmetic-coded JPEG is identified by the presence of an SOF9, SOF10, SOF11, SOF13, SOF14, or SOF15 segment.

[edit] 12-bit

Except for Baseline JPEG, all lossy types of JPEG may use a bit depth of either 8 or 12 bits per sample. However, few applications support anything other than 8 bits.

Starting with version 9a, IJG libjpeg also supports bit depths of 9, 10, and 11. These depths are nonstandard, and libjpeg's implementation is nearly unusable in practice, because it only supports a single bit depth, which must be selected at compile time.

[edit] Lossless JPEG

Main article: Lossless JPEG (original)

JPEG supports true lossless compression, but it is used so rarely that JPEG is commonly thought of as strictly a lossy format.

A lossless JPEG is identified by the presence of an SOF3, SOF7, SOF11, or SOF15 segment.

See also the Lossless JPEG disambiguation page, for other uses of the term.

[edit] Hierarchical

Also called "differential", hierarchical JPEG is vaguely similar to progressive JPEG, but geared toward storing multiple sizes of the same image, such that the decoder can select the size it prefers. Hierarchical JPEGs are, to a close approximation, nonexistent.

A hierarchical JPEG is identified by the presence of an SOF5, SOF6, SOF7, SOF13, SOF14, or SOF15 segment.

[edit] Color format

There are five JPEG color types that are reasonably portable:

  1. Grayscale
  2. YCbCr
  3. RGB
  4. YCCK
  5. CMYK

To make the compression more effective, RGB images are almost always transformed to YCbCr format when they are written to a JPEG file. However, many applications will still report that such images use "RGB" color. This may be because their authors weren't aware of the transformation, or because they considered it to be an internal part of the compression algorithm as opposed to a different colorspace. Unfortunately, this inconsistent terminology can make it hard to distinguish YCbCr JPEGs from the rare JPEGs that really do use RGB color.

YCCK is a transformed version of CMYK, and the same terminology confusion exists as with YCbCr and RGB.

The JPEG format does not have any clear way to indicate the color type of an image. Decoders usually determine the color type based on several factors:

  • The number of color components
  • The presence of a JFIF application segment
  • The "color transform" field of the APP14 "Adobe" segment, if present
  • The component ID numbers ({82, 71, 66} suggests RGB)

[edit] SmartScale

Starting with version 7 or 8, the IJG libjpeg software has been adding nonstandard "SmartScale" scaling and color transform features of debatable merit[1][2].

Notably, it is possible to achieve lossless DCT compression by setting the DCT block size to 1, and using RGB color if necessary.

Version 9 introduced a "reversible color transform" feature that can improve the compression of RGB images. Files with this feature contain a JPG8 (0xf8) segment.

[edit] Related Formats

  • JFIF is a subformat and extension, and uses APP0 "JFIF" and APP0 "JFXX" segments.
  • SPIFF is a subformat and extension, and uses an APP8 "SPIFF" segment.
  • JPEG-HDR is an extension, and uses APP11 segments.
  • JPEG XT is an extension.
  • JPEG 360 is an extension, and/or a metadata format.
  • JPS is an extension, and uses an APP3 "_JPSJPS_" segment.
  • Multi-Picture Format is an extension, and uses an APP2 "MPF" segment.
  • The Exif standard uses an APP1 "Exif" segment.
  • FlashPix data is contained in APP2 "FPXR" segments in Exif-compliant JPEGs. Refer to the Exif specification.
  • Photoshop Image Resources is contained in an APP13 "Photoshop 3.0" segment.
  • IPTC-IIM metadata often appears in JPEG files, embedded in Photoshop Image Resources.
  • XMP metadata is contained in an APP1 "http://ns.adobe.com/xap/1.0/" segment.
  • ICC profile data is contained in an APP2 "ICC_PROFILE" segment.
  • Many other file formats, such as TIFF, MNG/JNG, and PDF, can contain JPEG-compressed data or encapsulated JPEG files.
  • (And we heard you like JPEG...) JPEG files themselves often contain thumbnail images in the form of embedded JPEG files, via formats such as Exif, Photoshop Image Resources, or JFIF.

Formats that are not compatible with JPEG include JPEG-LS, JPEG 2000, JPEG XR, and presumably JPEG XL.

[edit] Specifications

[edit] Sample files

[edit] Metaformat files

[edit] Software

Nearly all serious graphics applications, including web browsers, support JPEG. This section primarily lists libraries and tools.

[edit] Notes

When saving a JPEG image from Twitter in Google Chrome / Chromium, it will save with the default extension .jpg-large. This is due to a known bug (and one which shows no signs of being solved any time soon) in the way the browser sanitises Twitter image URLs (the filename is determined to be e.g. Xyzxyzxyz.jpg:large, which is sanitised to Xyzxyzxyz.jpg-large).

[edit] External links

[edit] References

  1. ↑ A Study on the Usefulness of DCT Scaling and SmartScale
  2. ↑ IJG swings again, and misses
Retrieved from "http://fileformats.archiveteam.org/index.php?title=JPEG&oldid=47399"
Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox