Editing JPEG (section)

==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 encoding|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 [[Data padding|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).

{| class="wikitable"
|+ Common JPEG markers<ref>{{cite web | url = http://www.digicamsoft.com/itu/itu-t81-36.html | title = ISO/IEC 10918-1: 1993(E) p.36 | access-date = 2007-11-30 | archive-date = 2011-08-01 | archive-url = https://web.archive.org/web/20110801031604/http://www.digicamsoft.com/itu/itu-t81-36.html | url-status = live }}</ref>
! Short name
! Bytes
! Payload
! Name
! Comments
|-
! SOI
| 0xFF, 0xD8 || ''none'' || Start Of Image
|
|-
! SOF0
| 0xFF, 0xC0 || ''variable size'' || Start Of Frame (baseline [[Discrete cosine transform|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 RST''n'' 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.
|-
! RST''n''
| 0xFF, 0xD''n'' (''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.
|-
! APP''n''
| 0xFF, 0xE''n'' || ''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 APP''n'' 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.