Filename extension |
|
---|---|
Internet media type | image/jpeg |
Type code | JPEG |
Uniform Type Identifier (UTI) | public.jpeg |
Magic number | ff d8 ff |
Developed by | Joint Photographic Experts Group, IBM, Mitsubishi Electric, AT&T, Canon Inc.[1] |
Initial release | September 18, 1992 |
Type of format | Lossy image compression format |
Standard | ISO/IEC 10918, ITU-T T.81, ITU-T T.83, ITU-T T.84, ITU-T T.86 |
Website | www |
JPEG is a commonly used method of lossy compression for digital images, particularly for those images produced by digital photography. The degree of compression can be adjusted, allowing a selectable tradeoff between storage size and image quality. JPEG typically achieves 10:1 compression with little perceptible loss in image quality.[2] Since its introduction in 1992, JPEG has been the most widely used image compression standard in the world,[3][4] and the most widely used digital image format, with several billion JPEG images produced every day as of 2015.[5]
The term "JPEG" is an initialism/acronym for the Joint Photographic Experts Group, which created the standard in 1992. The basis for JPEG is the discrete cosine transform (DCT),[1] a lossy image compression technique that was first proposed by Nasir Ahmed in 1972.[6] JPEG was largely responsible for the proliferation of digital images and digital photos across the Internet, and later social media.[7]
JPEG compression is used in a number of image file formats. JPEG/Exif is the most common image format used by digital cameras and other photographic image capture devices; along with JPEG/JFIF, it is the most common format for storing and transmitting photographic images on the World Wide Web.[8] These format variations are often not distinguished, and are simply called JPEG.
The MIME media type for JPEG is image/jpeg, except in older Internet Explorer versions, which provides a MIME type of image/pjpeg when uploading JPEG images.[9] JPEG files usually have a filename extension of .jpg or .jpeg. JPEG/JFIF supports a maximum image size of 65,535×65,535 pixels,[10] hence up to 4 gigapixels for an aspect ratio of 1:1. In 2000, the JPEG group introduced a format intended to be a successor, JPEG 2000, but it was unable to replace the original JPEG as the dominant image standard.[11]
History[]
Background[]

Nasir Ahmed invented the discrete cosine transform (DCT) in 1972. DCT is the basis for JPEG.
The original JPEG specification published in 1992 implements processes from various earlier research papers and patents cited by the CCITT (now ITU-T) and Joint Photographic Experts Group.[1] The main basis for JPEG's lossy compression algorithm is the discrete cosine transform (DCT),[1][12] which was first proposed by Nasir Ahmed as an image compression technique in 1972.[6][12] Ahmed developed a practical DCT algorithm with T. Natarajan of Kansas State University and K. R. Rao of the University of Texas in 1973.[6] Their seminal 1974 paper[13] is cited in the JPEG specification, along with several later research papers that did further work on DCT, including a 1977 paper by Wen-Hsiung Chen, C.H. Smith and S.C. Fralick that described a fast DCT algorithm,[1][14] as well as a 1978 paper by N.J. Narasinha and S.C. Fralick, and a 1984 paper by B.G. Lee.[1] The specification also cites a 1984 paper by Wen-Hsiung Chen and W.K. Pratt as an influence on its quantization algorithm,[1][15] and David A. Huffman's 1952 paper for its Huffman coding algorithm.[1]
The JPEG specification cites patents from several companies. The following patents provided the basis for its arithmetic coding algorithm.[1]
- IBM
- U.S. Patent 4,652,856 – February 4, 1986 – Kottappuram M. A. Mohiuddin and Jorma J. Rissanen – Multiplication-free multi-alphabet arithmetic code
- U.S. Patent 4,905,297 – February 27, 1990 – G. Langdon, J.L. Mitchell, W.B. Pennebaker, and Jorma J. Rissanen – Arithmetic coding encoder and decoder system
- U.S. Patent 4,935,882 – June 19, 1990 – W.B. Pennebaker and J.L. Mitchell – Probability adaptation for arithmetic coders
- Mitsubishi Electric
- JP H02202267 (1021672) – January 21, 1989 – Toshihiro Kimura, Shigenori Kino, Fumitaka Ono, Masayuki Yoshida – Coding system
- JP H03247123 (2-46275) – February 26, 1990 – Fumitaka Ono, Tomohiro Kimura, Masayuki Yoshida, and Shigenori Kino – Coding apparatus and coding method
The JPEG specification also cites three other patents from IBM. Other companies cited as patent holders include AT&T (two patents) and Canon Inc.[1] Absent from the list is U.S. Patent 4,698,672, filed by Compression Labs' Wen-Hsiung Chen and Daniel J. Klenke in October 1986. The patent describes a DCT-based image compression algorithm, and would later be a cause of controversy in 2002 (see Patent controversy below).[16] However, the JPEG specification did cite two earlier research papers by Wen-Hsiung Chen, published in 1977 and 1984.[1]
JPEG standard[]
"JPEG" stands for Joint Photographic Experts Group, the name of the committee that created the JPEG standard and also other still picture coding standards. The "Joint" stood for ISO TC97 WG8 and CCITT SGVIII. Founded in 1986, the group developed the JPEG standard during the late 1980s. Among several transform coding techniques they examined, they selected the discrete cosine transform (DCT), as it was by far the most efficient practical compression technique. The group published the JPEG standard in 1992.[3]
In 1987, ISO TC 97 became ISO/IEC JTC1 and, in 1992, CCITT became ITU-T. Currently on the JTC1 side, JPEG 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.[17][18][19] On the ITU-T side, ITU-T SG16 is the respective body. The original JPEG Group was organized in 1986,[20] issuing the first JPEG standard in 1992, which was approved in September 1992 as ITU-T Recommendation T.81[21] and, in 1994, as ISO/IEC 10918-1.
The JPEG standard specifies the codec, which defines how an image is compressed into a stream of bytes and decompressed back into an image, but not the file format used to contain that stream.[22] The Exif and JFIF standards define the commonly used file formats for interchange of JPEG-compressed images.
JPEG standards are formally named as Information technology – Digital compression and coding of continuous-tone still images. ISO/IEC 10918 consists of the following parts:
Part | ISO/IEC standard | ITU-T Rec. | First public release date | Latest amendment | Title | Description |
---|---|---|---|---|---|---|
Part 1 | ISO/IEC 10918-1:1994 | T.81 (09/92) | Sep 18, 1992 | Requirements and guidelines | ||
Part 2 | ISO/IEC 10918-2:1995 | T.83 (11/94) | Nov 11, 1994 | Compliance testing | Rules and checks for software conformance (to Part 1). | |
Part 3 | ISO/IEC 10918-3:1997 | T.84 (07/96) | Jul 3, 1996 | Apr 1, 1999 | Extensions | Set of extensions to improve the Part 1, including the Still Picture Interchange File Format (SPIFF).[24] |
Part 4 | ISO/IEC 10918-4:1999 | T.86 (06/98) | Jun 18, 1998 | Jun 29, 2012 | Registration of JPEG profiles, SPIFF profiles, SPIFF tags, SPIFF colour spaces, APPn markers, SPIFF compression types and Registration Authorities (REGAUT) | methods for registering some of the parameters used to extend JPEG |
Part 5 | ISO/IEC 10918-5:2013 | T.871 (05/11) | May 14, 2011 | JPEG File Interchange Format (JFIF) | A popular format which has been the de facto file format for images encoded by the JPEG standard. In 2009, the JPEG Committee formally established an Ad Hoc Group to standardize JFIF as JPEG Part 5.[25] | |
Part 6 | ISO/IEC 10918-6:2013 | T.872 (06/12) | Jun 2012 | Application to printing systems | Specifies a subset of features and application tools for the interchange of images encoded according to the ISO/IEC 10918-1 for printing. |
Ecma International TR/98 specifies the JPEG File Interchange Format (JFIF); the first edition was published in June 2009.[26]
Patent controversy[]
In 2002, Forgent Networks asserted that it owned and would enforce patent rights on the JPEG technology, arising from a patent that had been filed on October 27, 1986, and granted on October 6, 1987: U.S. Patent 4,698,672 by Compression Labs' Wen-Hsiung Chen and Daniel J. Klenke.[16][27] While Forgent did not own Compression Labs at the time, Chen later sold Compression Labs to Forgent, before Chen went on to work for Cisco. This led to Forgent acquiring ownership over the patent.[16] Forgent's 2002 announcement created a furor reminiscent of Unisys' attempts to assert its rights over the GIF image compression standard.
The JPEG committee investigated the patent claims in 2002 and were of the opinion that they were invalidated by prior art,[28] a view shared by various experts.[16][29] The patent describes an image compression algorithm based on the discrete cosine transform (DCT),[16] a lossy image compression technique that originated from a 1974 paper by Nasir Ahmed, T. Natarajan and K. R. Rao.[1][12][13] Wen-Hsiung Chen further developed their DCT technique, describing a fast DCT algorithm in a 1977 paper with C.H. Smith and S.C. Fralick.[14][16] The 1992 JPEG specification cites both the 1974 Ahmed paper and the 1977 Chen paper for its DCT algorithm, as well as a 1984 paper by Chen and W.K. Pratt for its quantization algorithm.[1][15] Compression Labs was founded by Chen, and was the first company to commercialize DCT technology.[30] By the time Chen had filed his patent for a DCT-based image compression algorithm with Klenke in 1986, most of what would later become the JPEG standard had already been formulated in prior literature.[16] JPEG representative Richard Clark also claimed that Chen himself sat in one of the JPEG committees, but Forgent denied this claim.[16]
Between 2002 and 2004, Forgent was able to obtain about US$105 million by licensing their patent to some 30 companies. In April 2004, Forgent sued 31 other companies to enforce further license payments. In July of the same year, a consortium of 21 large computer companies filed a countersuit, with the goal of invalidating the patent. In addition, Microsoft launched a separate lawsuit against Forgent in April 2005.[31] In February 2006, the United States Patent and Trademark Office agreed to re-examine Forgent's JPEG patent at the request of the Public Patent Foundation.[32] On May 26, 2006 the USPTO found the patent invalid based on prior art. The USPTO also found that Forgent knew about the prior art, yet it intentionally avoided telling the Patent Office. This makes any appeal to reinstate the patent highly unlikely to succeed.[33]
Forgent also possesses a similar patent granted by the European Patent Office in 1994, though it is unclear how enforceable it is.[34]
As of October 27, 2006, the U.S. patent's 20-year term appears to have expired, and in November 2006, Forgent agreed to abandon enforcement of patent claims against use of the JPEG standard.[35]
The JPEG committee has as one of its explicit goals that their standards (in particular their baseline methods) be implementable without payment of license fees, and they have secured appropriate license rights for their JPEG 2000 standard from over 20 large organizations.
Beginning in August 2007, another company, Global Patent Holdings, LLC claimed that its patent (U.S. Patent 5,253,341) issued in 1993, is infringed by the downloading of JPEG images on either a website or through e-mail. If not invalidated, this patent could apply to any website that displays JPEG images. The patent was under reexamination by the U.S. Patent and Trademark Office from 2000-2007; in July 2007, the Patent Office revoked all of the original claims of the patent but found that an additional claim proposed by Global Patent Holdings (claim 17) was valid.[36] Global Patent Holdings then filed a number of lawsuits based on claim 17 of its patent.
In its first two lawsuits following the reexamination, both filed in Chicago, Illinois, Global Patent Holdings sued the Green Bay Packers, CDW, Motorola, Apple, Orbitz, Officemax, Caterpillar, Kraft and Peapod as defendants. A third lawsuit was filed on December 5, 2007 in South Florida against ADT Security Services, AutoNation, Florida Crystals Corp., HearUSA, MovieTickets.com, Ocwen Financial Corp. and Tire Kingdom, and a fourth lawsuit on January 8, 2008 in South Florida against the Boca Raton Resort & Club. A fifth lawsuit was filed against Global Patent Holdings in Nevada. That lawsuit was filed by Zappos.com, Inc., which was allegedly threatened by Global Patent Holdings, and sought a judicial declaration that the '341 patent is invalid and not infringed.
Global Patent Holdings had also used the '341 patent to sue or threaten outspoken critics of broad software patents, including Gregory Aharonian[37] and the anonymous operator of a website blog known as the "Patent Troll Tracker."[38] On December 21, 2007, patent lawyer Vernon Francissen of Chicago asked the U.S. Patent and Trademark Office to reexamine the sole remaining claim of the '341 patent on the basis of new prior art.[39]
On March 5, 2008, the U.S. Patent and Trademark Office agreed to reexamine the '341 patent, finding that the new prior art raised substantial new questions regarding the patent's validity.[40] In light of the reexamination, the accused infringers in four of the five pending lawsuits have filed motions to suspend (stay) their cases until completion of the U.S. Patent and Trademark Office's review of the '341 patent. On April 23, 2008, a judge presiding over the two lawsuits in Chicago, Illinois granted the motions in those cases.[41] On July 22, 2008, the Patent Office issued the first "Office Action" of the second reexamination, finding the claim invalid based on nineteen separate grounds.[42] On Nov. 24, 2009, a Reexamination Certificate was issued cancelling all claims.
Beginning in 2011 and continuing as of early 2013, an entity known as Princeton Digital Image Corporation,[43] based in Eastern Texas, began suing large numbers of companies for alleged infringement of U.S. Patent 4,813,056. Princeton claims that the JPEG image compression standard infringes the '056 patent and has sued large numbers of websites, retailers, camera and device manufacturers and resellers. The patent was originally owned and assigned to General Electric. The patent expired in December 2007, but Princeton has sued large numbers of companies for "past infringement" of this patent. (Under U.S. patent laws, a patent owner can sue for "past infringement" up to six years before the filing of a lawsuit, so Princeton could theoretically have continued suing companies until December 2013.) As of March 2013, Princeton had suits pending in New York and Delaware against more than 55 companies. General Electric's involvement in the suit is unknown, although court records indicate that it assigned the patent to Princeton in 2009 and retains certain rights in the patent.[44]
Typical usage[]
The JPEG compression algorithm operates at its best on photographs and paintings of realistic scenes with smooth variations of tone and color. For web usage, where reducing the amount of data used for an image is important for responsive presentation, JPEG's compression benefits make JPEG popular. JPEG/Exif is also the most common format saved by digital cameras.
However, JPEG is not well suited for line drawings and other textual or iconic graphics, where the sharp contrasts between adjacent pixels can cause noticeable artifacts. Such images are better saved in a lossless graphics format such as TIFF, GIF, PNG, or a raw image format. The JPEG standard includes a lossless coding mode, but that mode is not supported in most products.
As the typical use of JPEG is a lossy compression method, which reduces the image fidelity, it is inappropriate for exact reproduction of imaging data (such as some scientific and medical imaging applications and certain technical image processing work).
JPEG is also not well suited to files that will undergo multiple edits, as some image quality is lost each time the image is recompressed, particularly if the image is cropped or shifted, or if encoding parameters are changed – see digital generation loss for details. To prevent image information loss during sequential and repetitive editing, the first edit can be saved in a lossless format, subsequently edited in that format, then finally published as JPEG for distribution.
JPEG compression[]
Baseline sequential JPEG encoding and decoding processes
JPEG uses a lossy form of compression based on the discrete cosine transform (DCT). This mathematical operation converts each frame/field of the video source from the spatial (2D) domain into the frequency domain (a.k.a. transform domain). A perceptual model based loosely on the human psychovisual system discards high-frequency information, i.e. sharp transitions in intensity, and color hue. In the transform domain, the process of reducing information is called quantization. In simpler terms, quantization is a method for optimally reducing a large number scale (with different occurrences of each number) into a smaller one, and the transform-domain is a convenient representation of the image because the high-frequency coefficients, which contribute less to the overall picture than other coefficients, are characteristically small-values with high compressibility. The quantized coefficients are then sequenced and losslessly packed into the output bitstream. Nearly all software implementations of JPEG permit user control over the compression ratio (as well as other optional parameters), allowing the user to trade off picture-quality for smaller file size. In embedded applications (such as miniDV, which uses a similar DCT-compression scheme), the parameters are pre-selected and fixed for the application.
The compression method is usually lossy, meaning that some original image information is lost and cannot be restored, possibly affecting image quality. There is an optional lossless mode defined in the JPEG standard. However, this mode is not widely supported in products.
There is also an interlaced progressive JPEG format, in which data is compressed in multiple passes of progressively higher detail. This is ideal for large images that will be displayed while downloading over a slow connection, allowing a reasonable preview after receiving only a portion of the data. However, support for progressive JPEGs is not universal. When progressive JPEGs are received by programs that do not support them (such as versions of Internet Explorer before Windows 7)[45] the software displays the image only after it has been completely downloaded.
There are also many medical imaging, traffic and camera applications that create and process 12-bit JPEG images both grayscale and color. 12-bit JPEG format is included in an Extended part of the JPEG specification. The libjpeg codec supports 12-bit JPEG and there even exists a high-performance version.[46]
Lossless editing[]
A number of alterations to a JPEG image can be performed losslessly (that is, without recompression and the associated quality loss) as long as the image size is a multiple of 1 MCU block (Minimum Coded Unit) (usually 16 pixels in both directions, for 4:2:0 chroma subsampling). Utilities that implement this include:
- jpegtran and its GUI, Jpegcrop.
- IrfanView using "JPG Lossless Crop (PlugIn)" and "JPG Lossless Rotation (PlugIn)", which require installing the JPG_TRANSFORM plugin.
- FastStone Image Viewer using "Lossless Crop to File" and "JPEG Lossless Rotate".
- XnViewMP using "JPEG lossless transformations".
- ACDSee supports lossless rotation (but not lossless cropping) with its "Force lossless JPEG operations" option.
Blocks can be rotated in 90-degree increments, flipped in the horizontal, vertical and diagonal axes and moved about in the image. Not all blocks from the original image need to be used in the modified one.
The top and left edge of a JPEG image must lie on an 8 × 8 pixel block boundary, but the bottom and right edge need not do so. This limits the possible lossless crop operations, and also prevents flips and rotations of an image whose bottom or right edge does not lie on a block boundary for all channels (because the edge would end up on top or left, where – as aforementioned – a block boundary is obligatory).
Rotations where the image is not a multiple of 8 or 16, which value depends upon the chroma subsampling, are not lossless. Rotating such an image causes the blocks to be recomputed which results in loss of quality.[47]
When using lossless cropping, if the bottom or right side of the crop region is not on a block boundary, then the rest of the data from the partially used blocks will still be present in the cropped file and can be recovered. It is also possible to transform between baseline and progressive formats without any loss of quality, since the only difference is the order in which the coefficients are placed in the file.
Furthermore, several JPEG images can be losslessly joined together, as long as they were saved with the same quality and the edges coincide with block boundaries.
JPEG files[]
The file format known as "JPEG Interchange Format" (JIF) is specified in Annex B of the standard. However, this "pure" file format is rarely used, primarily because of the difficulty of programming encoders and decoders that fully implement all aspects of the standard and because of certain shortcomings of the standard:
- Color space definition
- Component sub-sampling registration
- Pixel aspect ratio definition.
Several additional standards have evolved to address these issues. The first of these, released in 1992, was the JPEG File Interchange Format (or JFIF), followed in recent years by Exchangeable image file format (Exif) and ICC color profiles. Both of these formats use the actual JIF byte layout, consisting of different markers, but in addition, employ one of the JIF standard's extension points, namely the application markers: JFIF uses APP0, while Exif uses APP1. Within these segments of the file that were left for future use in the JIF standard and are not read by it, these standards add specific metadata.
Thus, in some ways, JFIF is a cut-down version of the JIF standard in that it specifies certain constraints (such as not allowing all the different encoding modes), while in other ways, it is an extension of JIF due to the added metadata. The documentation for the original JFIF standard states:[48]
- JPEG File Interchange Format is a minimal file format which enables JPEG bitstreams to be exchanged between a wide variety of platforms and applications. This minimal format does not include any of the advanced features found in the TIFF JPEG specification or any application specific file format. Nor should it, for the only purpose of this simplified format is to allow the exchange of JPEG compressed images.
Image files that employ JPEG compression are commonly called "JPEG files", and are stored in variants of the JIF image format. Most image capture devices (such as digital cameras) that output JPEG are actually creating files in the Exif format, the format that the camera industry has standardized on for metadata interchange. On the other hand, since the Exif standard does not allow color profiles, most image editing software stores JPEG in JFIF format, and also includes the APP1 segment from the Exif file to include the metadata in an almost-compliant way; the JFIF standard is interpreted somewhat flexibly.[49]
Strictly speaking, the JFIF and Exif standards are incompatible, because each specifies that its marker segment (APP0 or APP1, respectively) appear first. In practice, most JPEG files contain a JFIF marker segment that precedes the Exif header. This allows older readers to correctly handle the older format JFIF segment, while newer readers also decode the following Exif segment, being less strict about requiring it to appear first.
JPEG filename extensions[]
The most common filename extensions for files employing JPEG compression are .jpg and .jpeg, though .jpe, .jfif and .jif are also used. It is also possible for JPEG data to be embedded in other file types – TIFF encoded files often embed a JPEG image as a thumbnail of the main image; and MP3 files can contain a JPEG of cover art in the ID3v2 tag.
Color profile[]
Many JPEG files embed an ICC color profile (color space). Commonly used color profiles include sRGB and Adobe RGB. Because these color spaces use a non-linear transformation, the dynamic range of an 8-bit JPEG file is about 11 stops; see gamma curve.
Syntax and structure[]
A JPEG image consists of a sequence of segments, each beginning with a marker, each of which begins with a 0xFF byte, followed by a byte indicating what kind of marker it is. Some markers consist of just those two bytes; others are followed by two bytes (high then low), indicating the length of marker-specific payload data that follows. (The length includes the two bytes for the length, but not the two bytes for the marker.) Some markers are followed by entropy-coded data; the length of such a marker does not include the entropy-coded data. Note that consecutive 0xFF bytes are used as fill bytes for padding purposes, although this fill byte padding should only ever take place for markers immediately following entropy-coded scan data (see JPEG specification section B.1.1.2 and E.1.2 for details; specifically "In all cases where markers are appended after the compressed data, optional 0xFF fill bytes may precede the marker").
Within the entropy-coded data, after any 0xFF byte, a 0x00 byte is inserted by the encoder before the next byte, so that there does not appear to be a marker where none is intended, preventing framing errors. Decoders must skip this 0x00 byte. This technique, called byte stuffing (see JPEG specification section F.1.2.3), is only applied to the entropy-coded data, not to marker payload data. Note however that entropy-coded data has a few markers of its own; specifically the Reset markers (0xD0 through 0xD7), which are used to isolate independent chunks of entropy-coded data to allow parallel decoding, and encoders are free to insert these Reset markers at regular intervals (although not all encoders do this).
Short name | Bytes | Payload | Name | Comments |
---|---|---|---|---|
SOI | 0xFF, 0xD8 | none | Start Of Image | |
SOF0 | 0xFF, 0xC0 | variable size | Start Of Frame (baseline DCT) | Indicates that this is a baseline DCT-based JPEG, and specifies the width, height, number of components, and component subsampling (e.g., 4:2:0). |
SOF2 | 0xFF, 0xC2 | variable size | Start Of Frame (progressive DCT) | Indicates that this is a progressive DCT-based JPEG, and specifies the width, height, number of components, and component subsampling (e.g., 4:2:0). |
DHT | 0xFF, 0xC4 | variable size | Define Huffman Table(s) | Specifies one or more Huffman tables. |
DQT | 0xFF, 0xDB | variable size | Define Quantization Table(s) | Specifies one or more quantization tables. |
DRI | 0xFF, 0xDD | 4 bytes | Define Restart Interval | Specifies the interval between RSTn markers, in Minimum Coded Units (MCUs). This marker is followed by two bytes indicating the fixed size so it can be treated like any other variable size segment. |
SOS | 0xFF, 0xDA | variable size | Start Of Scan | Begins a top-to-bottom scan of the image. In baseline DCT JPEG images, there is generally a single scan. Progressive DCT JPEG images usually contain multiple scans. This marker specifies which slice of data it will contain, and is immediately followed by entropy-coded data. |
RSTn | 0xFF, 0xDn (n=0..7) | none | Restart | Inserted every r macroblocks, where r is the restart interval set by a DRI marker. Not used if there was no DRI marker. The low three bits of the marker code cycle in value from 0 to 7. |
APPn | 0xFF, 0xEn | variable size | Application-specific | For example, an Exif JPEG file uses an APP1 marker to store metadata, laid out in a structure based closely on TIFF. |
COM | 0xFF, 0xFE | variable size | Comment | Contains a text comment. |
EOI | 0xFF, 0xD9 | none | End Of Image |
There are other Start Of Frame markers that introduce other kinds of JPEG encodings.
Since several vendors might use the same APPn marker type, application-specific markers often begin with a standard or vendor name (e.g., "Exif" or "Adobe") or some other identifying string.
At a restart marker, block-to-block predictor variables are reset, and the bitstream is synchronized to a byte boundary. Restart markers provide means for recovery after bitstream error, such as transmission over an unreliable network or file corruption. Since the runs of macroblocks between restart markers may be independently decoded, these runs may be decoded in parallel.
Effects of JPEG compression[]
JPEG compression artifacts blend well into photographs with detailed non-uniform textures, allowing higher compression ratios. Notice how a higher compression ratio first affects the high-frequency textures in the upper-left corner of the image, and how the contrasting lines become more fuzzy. The very high compression ratio severely affects the quality of the image, although the overall colors and image form are still recognizable. However, the precision of colors suffer less (for a human eye) than the precision of contours (based on luminance). This justifies the fact that images should be first transformed in a color model separating the luminance from the chromatic information, before subsampling the chromatic planes (which may also use lower quality quantization) in order to preserve the precision of the luminance plane with more information bits.
Lossless further compression[]
From 2004 to 2008, new research emerged on ways to further compress the data contained in JPEG images without modifying the represented image.[51][52][53][54] This has applications in scenarios where the original image is only available in JPEG format, and its size needs to be reduced for archiving or transmission. Standard general-purpose compression tools cannot significantly compress JPEG files.
Typically, such schemes take advantage of improvements to the naive scheme for coding DCT coefficients, which fails to take into account:
- Correlations between magnitudes of adjacent coefficients in the same block;
- Correlations between magnitudes of the same coefficient in adjacent blocks;
- Correlations between magnitudes of the same coefficient/block in different channels;
- The DC coefficients when taken together resemble a downscale version of the original image multiplied by a scaling factor. Well-known schemes for lossless coding of continuous-tone images can be applied, achieving somewhat better compression than the Huffman coded DPCM used in JPEG.
Some standard but rarely used options already exist in JPEG to improve the efficiency of coding DCT coefficients: the arithmetic coding option, and the progressive coding option (which produces lower bitrates because values for each coefficient are coded independently, and each coefficient has a significantly different distribution). Modern methods have improved on these techniques by reordering coefficients to group coefficients of larger magnitude together;[51] using adjacent coefficients and blocks to predict new coefficient values;[53] dividing blocks or coefficients up among a small number of independently coded models based on their statistics and adjacent values;[52][53] and most recently, by decoding blocks, predicting subsequent blocks in the spatial domain, and then encoding these to generate predictions for DCT coefficients.[54]
Typically, such methods can compress existing JPEG files between 15 and 25 percent, and for JPEGs compressed at low-quality settings, can produce improvements of up to 65%.[53][54]
A freely available tool called packJPG[55] is based on the 2007 paper "Improved Redundancy Reduction for JPEG Files."
Derived formats for stereoscopic 3D[]
JPEG Stereoscopic[]
JPS is a stereoscopic JPEG image used for creating 3D effects from 2D images. It contains two static images, one for the left eye and one for the right eye; encoded as two side-by-side images in a single JPG file. JPEG Stereoscopic (JPS, extension .jps) is a JPEG-based format for stereoscopic images.[56][57] It has a range of configurations stored in the JPEG APP3 marker field, but usually contains one image of double width, representing two images of identical size in cross-eyed (i.e. left frame on the right half of the image and vice versa) side-by-side arrangement. This file format can be viewed as a JPEG without any special software, or can be processed for rendering in other modes.
JPEG Multi-Picture Format[]
JPEG Multi-Picture Format (MPO, extension .mpo) is a JPEG-based format for storing multiple images in a single file. It contains two or more JPEG files concatenated together.[58][59] It also defines a JPEG APP2 marker segment for image description. Various devices use it to store 3D images, such as Fujifilm FinePix Real 3D W1, HTC Evo 3D, JVC GY-HMZ1U AVCHD/MVC extension camcorder, Nintendo 3DS, Panasonic Lumix DMC-TZ20, DMC-TZ30, DMC-TZ60, DMC-TS4 (FT4), and Sony DSC-HX7V. Other devices use it to store "preview images" that can be displayed on a TV.
In the last few years, due to the growing use of stereoscopic images, much effort has been spent by the scientific community to develop algorithms for stereoscopic image compression.[60][61]
Implementations[]
A very important implementation of a JPEG codec is the free programming library libjpeg of the Independent JPEG Group. It was first published in 1991 and was key for the success of the standard.[62] This library or a direct derivative of it is used in countless applications. Recent versions introduce proprietary extensions which broke ABI compatibility with previous versions.
In March 2017, Google released the open source project Guetzli, which trades off a much longer encoding time for smaller file size (similar to what Zopfli does for PNG and other lossless data formats).[63]
ISO/IEC Joint Photography Experts Group maintains a reference software implementation which can encode both base JPEG (ISO/IEC 10918-1 and 18477-1) and JPEG XT extensions (ISO/IEC 18477 Parts 2 and 6-9), as well as JPEG-LS (ISO/IEC 14495).[64]
JPEG XT[]
JPEG XT (ISO/IEC 18477) was published in June 2015; it extends base JPEG format with support for higher integer bit depths (up to 16 bit), high dynamic range imaging and floating-point coding, lossless coding, and alpha channel coding. Extensions are backward compatible with the base JPEG/JFIF file format and 8-bit lossy compressed image. JPEG XT uses an extensible file format based on JFIF. Extension layers are used to modify the JPEG 8-bit base layer and restore the high-resolution image. Existing software is forward compatible and can read the JPEG XT binary stream, though it would only decode the base 8-bit layer.[65]
JPEG XL[]
Since August 2017, JTC1/SC29/WG1 issued a series of draft calls for proposals on JPEG XL – the next generation image compression standard with substantially better compression efficiency (60% improvement) comparing to JPEG.[66] The standard is expected to exceed the still image compression performance shown by HEVC HM, Daala and WebP, and unlike previous efforts attempting to replace JPEG, to provide lossless more efficient recompression transport and storage option for traditional JPEG images.[67][68][69] The core requirements include support for very high-resolution images (at least 40 MP), 8–10 bits per component, RGB/YCbCr/ICtCp color encoding, animated images, alpha channel coding, Rec.709 color space (sRGB) and gamma function (2.4-power), Rec.2100 wide color gamut color space (Rec.2020) and high dynamic range transfer functions (PQ and HLG), and high-quality compression of synthetic images, such as bitmap fonts and gradients. The standard should also offer higher bit depths (12–16 bit integer and floating point), additional color spaces and transfer functions (such as Log C from Arri), embedded preview images, lossless alpha channel encoding, image region coding, and low-complexity encoding. Any patented technologies would be licensed on a royalty-free basis. The proposals were submitted by September 2018, leading to a committee draft in July 2019, with current target publication date in October 2019.[70][69]
See also[]
- Better Portable Graphics, a format based on intra-frame encoding of the HEVC
- C-Cube, an early implementer of JPEG in chip form
- Comparison of graphics file formats
- Comparison of layout engines (graphics)
- Deblocking filter (video), the similar deblocking methods could be applied to JPEG
- Design rule for Camera File system (DCF)
- File extensions
- Graphics editing program
- High Efficiency Image File Format, image container format for HEVC and other image coding formats
- Lenna (test image), the traditional standard image used to test image processing algorithms
- Lossless Image Codec FELICS
- Motion JPEG
- WebP
References[]
- ↑ 1.00 1.01 1.02 1.03 1.04 1.05 1.06 1.07 1.08 1.09 1.10 1.11 1.12 "T.81 – DIGITAL COMPRESSION AND CODING OF CONTINUOUS-TONE STILL IMAGES – REQUIREMENTS AND GUIDELINES" (PDF). CCITT. September 1992. Retrieved 12 July 2019.
{{cite web}}
: - ↑ Haines, Richard F.; Chuang, Sherry L. (1 July 1992). The effects of video compression on acceptability of images for monitoring life sciences experiments (Technical report). NASA. NASA-TP-3239, A-92040, NAS 1.60:3239. Retrieved 2016-03-13.
The JPEG still-image-compression levels, even with the large range of 5:1 to 120:1 in this study, yielded equally high levels of acceptability
{{cite tech report}}
: - ↑ 3.0 3.1 Hudson, Graham; Léger, Alain; Niss, Birger; Sebestyén, István; Vaaben, Jørgen (31 August 2018). "JPEG-1 standard 25 years: past, present, and future reasons for a success". Journal of Electronic Imaging 27 (04): 1. doi:10.1117/1.JEI.27.4.040901.
- ↑ "The JPEG image format explained". BT.com. BT Group. 31 May 2018. Retrieved 5 August 2019.
{{cite web}}
: - ↑ Baraniuk, Chris (15 October 2015). "Copy protections could come to JPegs". BBC News. BBC. https://www.bbc.co.uk/news/technology-34538705. Retrieved 13 September 2019.
- ↑ 6.0 6.1 6.2 Ahmed, Nasir (January 1991). "How I Came Up With the Discrete Cosine Transform". Digital Signal Processing 1 (1): 4–5. doi:10.1016/1051-2004(91)90086-Z. https://www.scribd.com/doc/52879771/DCT-History-How-I-Came-Up-with-the-Discrete-Cosine-Transform.
- ↑ "What Is a JPEG? The Invisible Object You See Every Day". The Atlantic. 24 September 2013. Retrieved 13 September 2019.
{{cite web}}
: - ↑ "HTTP Archive - Interesting Stats". httparchive.org. Retrieved 2016-04-06.
{{cite web}}
: - ↑ MIME Type Detection in Internet Explorer: Uploaded MIME Types (msdn.microsoft.com)
- ↑ "Wayback Machine" (PDF). 3 September 2014. Archived from the original on 3 September 2014. Retrieved 16 October 2017.
{{cite web}}
: CS1 maint: bot: original URL status unknown (link) - ↑ "Why JPEG 2000 Never Took Off". American National Standards Institute. 10 July 2018. Retrieved 13 September 2019.
{{cite web}}
: - ↑ 12.0 12.1 12.2 "JPEG: 25 Jahre und kein bisschen alt" (in de). Heise online. October 2016. https://www.heise.de/newsticker/meldung/JPEG-25-Jahre-und-kein-bisschen-alt-3342519.html. Retrieved 5 September 2019.
- ↑ 13.0 13.1 Ahmed, Nasir; Natarajan, T.; Rao, K. R. (January 1974), "Discrete Cosine Transform", IEEE Transactions on Computers C-23 (1): 90–93, doi:10.1109/T-C.1974.223784
- ↑ 14.0 14.1 Chen, Wen-Hsiung; Smith, C.; Fralick, S. (1977). "A Fast Computational Algorithm for the Discrete Cosine Transform". IEEE Transactions on Communications 25 (9): 1004–1009. doi:10.1109/TCOM.1977.1093941. ISSN 0090-6778.
- ↑ 15.0 15.1 Chen, Wen-Hsiung; Pratt, W.K. (1984). "Scene Adaptive Coder". IEEE Transactions on Communications 32 (3): 225–232. doi:10.1109/TCOM.1984.1096066. ISSN 0090-6778.
- ↑ 16.0 16.1 16.2 16.3 16.4 16.5 16.6 16.7 Lemos, Robert (23 July 2002). "Finding patent truth in JPEG claim". CNET. https://www.cnet.com/news/finding-patent-truth-in-jpeg-claim/. Retrieved 13 July 2019.
- ↑ ISO/IEC JTC 1/SC 29 (2009-05-07). "ISO/IEC JTC 1/SC 29/WG 1 – Coding of Still Pictures (SC 29/WG 1 Structure)". Archived from the original on 2013-12-31. Retrieved 2009-11-11.
{{cite web}}
: CS1 maint: numeric names: authors list (link) - ↑ 18.0 18.1 ISO/IEC JTC 1/SC 29. "Programme of Work, (Allocated to SC 29/WG 1)". Archived from the original on 2013-12-31. Retrieved 2009-11-07.
{{cite web}}
: CS1 maint: numeric names: authors list (link) - ↑ ISO. "JTC 1/SC 29 – Coding of audio, picture, multimedia and hypermedia information". Retrieved 2009-11-11.
{{cite web}}
: - ↑ 20.0 20.1 JPEG. "Joint Photographic Experts Group, JPEG Homepage". Retrieved 2009-11-08.
{{cite web}}
: - ↑ "T.81 : Information technology – Digital compression and coding of continuous-tone still images – Requirements and guidelines". Itu.int. Retrieved 2009-11-07.
{{cite web}}
: - ↑ William B. Pennebaker; Joan L. Mitchell (1993). JPEG still image data compression standard (3rd ed.). Springer. p. 291. ISBN 978-0-442-01272-4. https://books.google.com/?id=AepB_PZ_WMkC&pg=PA291&dq=JPEG+%22did+not+specify+a+file+format%22#v=onepage&q=JPEG%20%22did%20not%20specify%20a%20file%20format%22&f=false.
- ↑ ISO. "JTC 1/SC 29 – Coding of audio, picture, multimedia and hypermedia information". Retrieved 2009-11-07.
{{cite web}}
: - ↑ "SPIFF, Still Picture Interchange File Format". Library of Congress. Archived from the original on 2018-07-31. Retrieved 2018-07-31.
{{cite web}}
: - ↑ JPEG (2009-04-24). "JPEG XR enters FDIS status: JPEG File Interchange Format (JFIF) to be standardized as JPEG Part 5" (Press release). Archived from the original on 2009-10-08. https://web.archive.org/web/20091008041637/http://www.jpeg.org/newsrel25.html. Retrieved 2009-11-09.
- ↑ "JPEG File Interchange Format (JFIF)". ECMA TR/98 1st ed. Ecma International. 2009. Retrieved 2011-08-01.
{{cite web}}
: - ↑ "Forgent's JPEG Patent". SourceForge. 2002. https://pmt.sourceforge.io/SVG-patents/jpeg.html. Retrieved 13 July 2019.
- ↑ "Concerning recent patent claims". Jpeg.org. 2002-07-19. Archived from the original on 2007-07-14. Retrieved 2011-05-29.
{{cite web}}
: - ↑ "JPEG and JPEG2000 – Between Patent Quarrel and Change of Technology". Archived from the original on August 17, 2004. Retrieved 2017-04-16.
{{cite web}}
: CS1 maint: bot: original URL status unknown (link) - ↑ Stanković, Radomir S.; Astola, Jaakko T. (2012). "Reminiscences of the Early Work in DCT: Interview with K.R. Rao". Reprints from the Early Days of Information Sciences 60. http://ticsp.cs.tut.fi/reports/ticsp-report-60-reprint-rao-corrected.pdf. Retrieved 13 October 2019.
- ↑ Kawamoto, Dawn (April 22, 2005). "Graphics patent suit fires back at Microsoft". CNET News. Retrieved 2009-01-28.
{{cite web}}
: - ↑ "Trademark Office Re-examines Forgent JPEG Patent". Publish.com. February 3, 2006. Retrieved 2009-01-28.
{{cite web}}
: - ↑ "USPTO: Broadest Claims Forgent Asserts Against JPEG Standard Invalid". Groklaw.net. May 26, 2006. Retrieved 2007-07-21.
{{cite web}}
: - ↑ "Coding System for Reducing Redundancy". Gauss.ffii.org. Retrieved 2011-05-29.
{{cite web}}
: - ↑ "JPEG Patent Claim Surrendered". Public Patent Foundation. November 2, 2006. Retrieved 2006-11-03.
{{cite web}}
: - ↑ Ex Parte Reexamination Certificate for U.S. Patent No. 5,253,341 Archived June 2, 2008, at the Wayback Machine
- ↑ Workgroup. "Rozmanith: Using Software Patents to Silence Critics". Eupat.ffii.org. Archived from the original on 2011-07-16. Retrieved 2011-05-29.
{{cite web}}
: - ↑ "A Bounty of $5,000 to Name Troll Tracker: Ray Niro Wants To Know Who Is saying All Those Nasty Things About Him". Law.com. Retrieved 2011-05-29.
{{cite web}}
: - ↑ Reimer, Jeremy (2008-02-05). "Hunting trolls: USPTO asked to reexamine broad image patent". Arstechnica.com. Retrieved 2011-05-29.
{{cite web}}
: - ↑ U.S. Patent Office – Granting Reexamination on 5,253,341 C1
- ↑ "Judge Puts JPEG Patent On Ice". Techdirt.com. 2008-04-30. Retrieved 2011-05-29.
{{cite web}}
: - ↑ "JPEG Patent's Single Claim Rejected (And Smacked Down For Good Measure)". Techdirt.com. 2008-08-01. Retrieved 2011-05-29.
{{cite web}}
: - ↑ Workgroup. "Princeton Digital Image Corporation Home Page". Retrieved 2013-05-01.
{{cite web}}
: - ↑ Workgroup. "Article on Princeton Court Ruling Regarding GE License Agreement". Archived from the original on 2016-03-09. Retrieved 2013-05-01.
{{cite web}}
: - ↑ "Progressive Decoding Overview". Microsoft Developer Network. Microsoft. Retrieved 2012-03-23.
{{cite web}}
: - ↑ Fastvideo (May 2019). "12-bit JPEG encoder on GPU". Retrieved 2019-05-06.
{{cite web}}
: - ↑ "Why You Should Always Rotate Original JPEG Photos Losslessly". Petapixel.com. Retrieved 16 October 2017.
{{cite web}}
: - ↑ "JFIF File Format as PDF" (PDF).
{{cite web}}
: - ↑ Tom Lane (1999-03-29). "JPEG image compression FAQ". Retrieved 2007-09-11.
{{cite web}}
: (q. 14: "Why all the argument about file formats?") - ↑ "ISO/IEC 10918-1 : 1993(E) p.36".
{{cite web}}
: - ↑ 51.0 51.1 I. Bauermann and E. Steinbacj. Further Lossless Compression of JPEG Images. Proc. of Picture Coding Symposium (PCS 2004), San Francisco, US, December 15–17, 2004.
- ↑ 52.0 52.1 N. Ponomarenko, K. Egiazarian, V. Lukin and J. Astola. Additional Lossless Compression of JPEG Images, Proc. of the 4th Intl. Symposium on Image and Signal Processing and Analysis (ISPA 2005), Zagreb, Croatia, pp. 117–120, September 15–17, 2005.
- ↑ 53.0 53.1 53.2 53.3 M. Stirner and G. Seelmann. Improved Redundancy Reduction for JPEG Files. Proc. of Picture Coding Symposium (PCS 2007), Lisbon, Portugal, November 7–9, 2007
- ↑ 54.0 54.1 54.2 Ichiro Matsuda, Yukio Nomoto, Kei Wakabayashi and Susumu Itoh. Lossless Re-encoding of JPEG images using block-adaptive intra prediction. Proceedings of the 16th European Signal Processing Conference (EUSIPCO 2008).
- ↑ "Latest Binary Releases of packJPG: V2.3a". January 3, 2008. Archived from the original on January 23, 2009.
{{cite web}}
: - ↑ "General Purpose Stereoscopic Data Descriptor" (PDF). VRex, Inc., Elmsford, New York, US. 1997. Archived from the original (PDF) on 2011-10-30.
{{cite web}}
: ; authors - ↑ Tim Kemp, JPS files
- ↑ "Multi-Picture Format" (PDF). 2009. Retrieved 2015-12-30.
{{cite web}}
: - ↑ MPO2Stereo: Convert Fujifilm MPO files to JPEG stereo pairs, http://www.mtbs3d.com/phpbb/viewtopic.php?f=3&t=4124&start=15, retrieved 12 January 2010
- ↑ Alessandro Ortis; Sebastiano Battiato (2015), "A new fast matching method for adaptive compression of stereoscopic images", Three-Dimensional Image Processing, Three-Dimensional Image Processing, Measurement (3DIPM), and Applications 2015 (SPIE - Three-Dimensional Image Processing, Measurement (3DIPM), and Applications 2015) 9393: 93930K, Bibcode 2015SPIE.9393E..0KO, doi:10.1117/12.2086372, http://iplab.dmi.unict.it/publication/503, retrieved 30 April 2015
- ↑ Alessandro Ortis; Francesco Rundo; Giuseppe Di Giore; Sebastiano Battiato, Adaptive Compression of Stereoscopic Images, International Conference on Image Analysis and Processing (ICIAP) 2013, http://iplab.dmi.unict.it/publication/49, retrieved 30 April 2015
- ↑ "Overview of JPEG". jpeg.org. Retrieved 2017-10-16.
{{cite web}}
: - ↑ "Announcing Guetzli: A New Open Source JPEG Encoder". Research.googleblog.com. Retrieved 16 October 2017.
{{cite web}}
: - ↑ "JPEG - JPEG XT". jpeg.org.
{{cite web}}
: - ↑ "JPEG - JPEG XT". jpeg.org.
{{cite web}}
: - ↑ "JPEG - Next-Generation Image Compression (JPEG XL) Final Draft Call for Proposals". Jpeg.org. Retrieved 29 May 2018.
{{cite web}}
: - ↑ Alakuijala, Jyrki; van Asseldonk, Ruud; Boukortt, Sami; Bruse, Martin; Comșa, Iulia-Maria; Firsching, Moritz; Fischbacher, Thomas; Kliuchnikov, Evgenii; Gomez, Sebastian; Obryk, Robert; Potempa, Krzysztof; Rhatushnyak, Alexander; Sneyers, Jon; Szabadka, Zoltan; Vandervenne, Lode; Versari, Luca; Wassenberg, Jan (2019-09-06). "JPEG XL next-generation image compression architecture and coding tools".
{{cite web}}
: - ↑ https://qiita.com/fg11894/items/5ae0be6b620535880d0d. Retrieved 22 August 2019.
{{cite web}}
: ; title - ↑ 69.0 69.1 Lua error in Module:Citation/CS1/Identifiers at line 361: invalid value (nil) at index 1 in table for 'concat'.
- ↑ "N79010 Final Call for Proposals for a Next-Generation Image Coding Standard (JPEG XL)" (PDF). ISO/IEC JTC 1/SC 29/WG 1 (ITU-T SG16). Retrieved 29 May 2018.
{{cite web}}
:
External links[]
- JPEG Standard (JPEG ISO/IEC 10918-1 ITU-T Recommendation T.81) at W3.org
- Official Joint Photographic Experts Group (JPEG) site
- JFIF File Format at W3.org
- JPEG viewer in 250 lines of easy to understand Python code
- Example images over the full range of quantization levels from 1 to 100 at visengi.com
- Public domain JPEG compressor in a single C++ source file, along with a matching decompressor at code.google.com
- JPEG decoder open source code, copyright (C) 1995–1997, Thomas G. Lane