CS50 PSET5 Images and Formats

CS50 PSET5 Images and Formats
Contents
1 ASCII 1
1.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Bit width . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.3 Publication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.4 Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.5 Other standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 ASCII control characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 ASCII control code chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 ASCII printable characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 ASCII printable code chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Variants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.1 7-bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.2 8-bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5.3 Unicode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.6 Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.7 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.8 Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.9 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.10 Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.11 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Image le formats 12
2.1 Image le sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Image le compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Major graphic le formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
i
ii CONTENTS
2.3.1 Raster formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2 Vector formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.3 Compound formats (see also Metale) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.4 Stereo formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 BMP le format 18
3.1 Device-independent bitmaps and the BMP le format . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 File structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.1 DIBs in memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.2 Bitmap le header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.3 DIB header (bitmap information header) . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.4 Color table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.5 Pixel storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.6 RGB video subtypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.7 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.8 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Usage of BMP format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4 Related formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.6 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4 Hexadecimal 24
4.1 Representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.1 Written representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.2 Early written representations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.3 Verbal and digital representations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.4 Signs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.5 Hexadecimal exponential notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2 Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.1 Binary conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.2 Division-remainder in source base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.3 Addition and multiplication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.4 Tools for conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 Real numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3.1 Powers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4 Cultural . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
CONTENTS iii
4.4.1 Etymology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4.2 Use in Chinese culture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4.3 Primary numeral system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.5 Key to number base notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.6 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5 JPEG 31
5.1 The JPEG standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2 Typical usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3 JPEG compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3.1 Lossless editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.4 JPEG les . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.4.1 JPEG lename extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.4.2 Color prole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.5 Syntax and structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.6 JPEG codec example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.6.1 Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.6.2 Compression ratio and artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.6.3 Decoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.6.4 Required precision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.7 Eects of JPEG compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.7.1 Sample photographs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.8 Lossless further compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.9 Derived formats for stereoscopic 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.9.1 JPEG Stereoscopic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.9.2 JPEG Multi-Picture Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.10 Patent issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.11 Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.12 Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.13 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.14 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.15 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6 Graphics Interchange Format 48
6.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
iv CONTENTS
6.2 Pronunciation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.3 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.4 File format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.5 Palettes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.5.1 True color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.6 Example GIF le . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.6.1 Image coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.6.2 Image decoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.6.3 LZW code lengths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.6.4 Uncompressed GIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.7 Compression example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.8 Interlacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.9 Animated GIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.10 Unisys and LZW patent enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.11 Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.11.1 PNG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.11.2 Animation formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.12 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.13 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.14 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
7 Portable Network Graphics 60
7.1 History and development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
7.2 PNG Working Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.3 Technical details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.3.1 File header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.3.2 Chunks within the le . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
7.3.3 Color depth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.3.4 Transparency of image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.3.5 Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.3.6 Interlacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.3.7 Animation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.4 Comparison to other le formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.4.1 Comparison to Graphics Interchange Format (GIF) . . . . . . . . . . . . . . . . . . . . . 65
7.4.2 Comparison to JPEG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7.4.3 Comparison to JPEG-LS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
CONTENTS v
7.4.4 Comparison to TIFF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.5 Software support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.5.1 Bitmap graphics editor support for PNG . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.5.2 Web browser support for PNG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
7.5.3 Operating system support for PNG icons . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.6 File size and optimization software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.6.1 Compared to GIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.6.2 File size factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.6.3 Image editing software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.6.4 Optimizing tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.6.5 Icon optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.7 See also . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.9 Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.10 External links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.10.1 libpng.org . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.10.2 W3C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.10.3 Others . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.11 Text and image sources, contributors, and licenses . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.11.1 Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7.11.2 Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
7.11.3 Content license . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Chapter 1
ASCII
Not to be confused with MS Windows-1252 or other
types of Extended ASCII.
This article is about the character encoding. For other
uses, see ASCII (disambiguation).
NATHAN GEORGE THOMAS The American
A chart of ASCII from a 1972 printer manual
Standard Code for Information Interchange (ASCII
/ski/ ASS-kee)
[1]
is a character-encoding scheme orig-
inally based on the English alphabet that encodes 128
specied characters - the numbers 0-9, the letters a-z
and A-Z, some basic punctuation symbols, some control
codes that originated with Teletype machines, and a blank
space - into the 7-bit binary integers.
[2]
ASCII codes represent text in computers,
communications equipment, and other devices that
use text. Most modern character-encoding schemes are
based on ASCII, though they support many additional
characters.
ASCII developed from telegraphic codes. Its rst com-
mercial use was as a 7-bit teleprinter code promoted by
Bell data services. Work on the ASCII standard be-
gan on October 6, 1960, with the rst meeting of the
American Standards Association's (ASA) X3.2 subcom-
mittee. The rst edition of the standard was published
during 1963,
[3][4]
a major revision during 1967,
[5]
and the
most recent update during 1986.
[6]
Compared to earlier
telegraph codes, the proposed Bell code and ASCII were
both ordered for more convenient sorting (i.e., alphabet-
ization) of lists, and added features for devices other than
teleprinters.
ASCII includes denitions for 128 characters: 33 are
non-printing control characters (many now obsolete)
[7]
that aect how text and space are processed
[8]
and 95
printable characters, including the space (which is con-
sidered an invisible graphic
[9][10]
).
The IANA prefers the name US-ASCII.
[11]
ASCII was
the most commonly used character encoding on the
World Wide Web until December 2007, when it was sur-
passed by UTF-8,
[12][13][14]
which includes ASCII as a
subset.
1.1 History
The American Standard Code for Information Inter-
change (ASCII) was developed under the auspices of
a committee of the American Standards Association,
called the X3 committee, by its X3.2 (later X3L2) sub-
committee, and later by that subcommittees X3.2.4
working group. The ASA became the United States of
America Standards Institute or USASI
[15]
and ultimately
the American National Standards Institute.
1
2 CHAPTER 1. ASCII
1.1.1 Bit width
The X3.2 subcommittee designed ASCII based on the
earlier teleprinter encoding systems. Like other character
encodings, ASCII species a correspondence between
digital bit patterns and character symbols (i.e. graphemes
and control characters). This allows digital devices to
communicate with each other and to process, store,
and communicate character-oriented information such
as written language. Before ASCII was developed, the
encodings in use included 26 alphabetic characters, 10
numerical digits, and from 11 to 25 special graphic sym-
bols. To include all these, and control characters com-
patible with the Comit Consultatif International Tl-
phonique et Tlgraphique (CCITT) International Tele-
graph Alphabet No. 2 (ITA2) standard, Fieldata, and
early EBCDIC, more than 64 codes were required for
ASCII.
The committee debated the possibility of a shift function
(like in ITA2), which would allow more than 64 codes to
be represented by a six-bit code. In a shifted code, some
character codes determine choices between options for
the following character codes. It allows compact encod-
ing, but is less reliable for data transmission; an error in
transmitting the shift code typically makes a long part of
the transmission unreadable. The standards committee
decided against shifting, and so ASCII required at least a
seven-bit code.
[16]
The committee considered an eight-bit code, since eight
bits (octets) would allow two four-bit patterns to ef-
ciently encode two digits with binary-coded decimal.
However, it would require all data transmission to send
eight bits when seven could suce. The committee voted
to use a seven-bit code to minimize costs associated with
data transmission. Since perforated tape at the time could
record eight bits in one position, it also allowed for a
parity bit for error checking if desired.
[17]
Eight-bit ma-
chines (with octets as the native data type) that did not
use parity checking typically set the eighth bit to 0.
[18]
1.1.2 Organization
The code itself was patterned so that most control codes
were together, and all graphic codes were together, for
ease of identication. The rst two columns (32 po-
sitions) were reserved for control characters.
[19]
The
space character had to come before graphics to make
sorting easier, so it became position 20;
[20]
for the same
reason, many special signs commonly used as separators
were placed before digits. The committee decided it was
important to support upper case 64-character alphabets,
and chose to pattern ASCII so it could be reduced easily
to a usable 64-character set of graphic codes,
[21]
as was
done in the DEC SIXBIT code. Lower case letters were
therefore not interleaved with upper case. To keep op-
tions available for lower case letters and other graphics,
the special and numeric codes were arranged before the
letters, and the letter A was placed in position 41 to
match the draft of the corresponding British standard.
[22]
The digits 09 were arranged so they correspond to val-
ues in binary prexed with 011, making conversion with
binary-coded decimal straightforward.
Many of the non-alphanumeric characters were posi-
tioned to correspond to their shifted position on type-
writers; an important subtlety is that these were based
on mechanical typewriters, not electric typewriters.
[23]
Mechanical typewriters followed the standard set by the
Remington No. 2 (1878), the rst typewriter with a shift
key, and the shifted values of 23456789- were extquot-
edbl#$%_&'() early typewriters omitted 0 and 1, us-
ing O (capital letter o) and l (lowercase letter L) instead,
but 1! and 0) pairs became standard once 0 and 1 be-
came common. Thus, in ASCII ! extquotedbl#$% were
placed in column 2, rows 15, corresponding to the digits
15 in the adjacent column. The parentheses could not
correspond to 9 and 0, however, because the place corre-
sponding to 0 was taken by the space character. This was
accommodated by removing _ (underscore) from 6 and
shifting the remaining characters left; this corresponded
to many European typewriters, which placed the paren-
theses with 8 and 9. This discrepancy from typewriters
led to bit-paired keyboards, notably the Teletype Model
33, which used the left-shifted layout corresponding to
ASCII, not to traditional mechanical typewriters. Elec-
tric typewriters, notably the more recently introduced
IBM Selectric (1961), used a somewhat dierent layout
that has become standard on computers following the
IBM PC (1981), especially Model M (1984) and thus
shift values for symbols on modern keyboards do not cor-
respond as closely to the ASCII table as earlier keyboards
did. The /? pair also dates to the No. 2, and the ,< .> pairs
were used on some keyboards (others, including the No.
2, did not shift , (comma) or . (full stop) so they could be
used in uppercase without unshifting). However, ASCII
split the ;: pair (dating to No. 2), and rearranged math-
ematical symbols (varied conventions, commonly -* =+)
to :* ;+ -=.
1.1. HISTORY 3
Some common characters were not included notably
while ^`~ were included as diacritics for interna-
tional use, and <> for mathematical use, together with
the simple line characters \| (in addition to common /).
The @ symbol was not used in continental Europe and
the committee expected it would be replaced by an ac-
cented in the French variation, so the @ was placed in
position 40, right before the letter A.
[24]
The control codes felt essential for data transmission were
the start of message (SOM), end of address (EOA), end
of message (EOM), end of transmission (EOT), who
are you? extquotedbl (WRU), are you? extquotedbl
(RU), a reserved device control (DC0), synchronous idle
(SYNC), and acknowledge (ACK). These were posi-
tioned to maximize the Hamming distance between their
bit patterns.
[25]
1.1.3 Publication
With the other special characters and control codes lled
in, ASCII was published as ASA X3.4-1963, leaving 28
code positions without any assigned meaning, reserved
for future standardization, and one unassigned control
code.
[26]
There was some debate at the time whether there
should be more control characters rather than the lower
case alphabet.
[27]
The indecision did not last long: during
May 1963 the CCITT Working Party on the New Tele-
graph Alphabet proposed to assign lower case characters
to columns 6 and 7,
[28]
and International Organization
for Standardization TC 97 SC 2 voted during October
to incorporate the change into its draft standard.
[29]
The
X3.2.4 task group voted its approval for the change to
ASCII at its May 1963 meeting.
[30]
Locating the lower-
case letters in columns 6 and 7 caused the characters to
dier in bit pattern from the upper case by a single bit,
which simplied case-insensitive character matching and
the construction of keyboards and printers.
The X3 committee made other changes, including other
new characters (the brace and vertical bar characters),
[31]
renaming some control characters (SOM became start of
header (SOH)) and moving or removing others (RU was
removed).
[32]
ASCII was subsequently updated as USASI
X3.4-1967, then USASI X3.4-1968, ANSI X3.4-1977,
and nally, ANSI X3.4-1986 (the rst two are occa-
sionally retronamed ANSI X3.4-1967, and ANSI X3.4-
1968).
The X3 committee also addressed how ASCII should be
transmitted (least signicant bit rst), and how it should
be recorded on perforated tape. They proposed a 9-track
standard for magnetic tape, and attempted to deal with
some forms of punched card formats.
1.1.4 Use
ASCII itself was rst used commercially during 1963 as
a seven-bit teleprinter code for American Telephone &
Telegraph's TWX (TeletypeWriter eXchange) network.
TWX originally used the earlier ve-bit ITA2, which
was also used by the competing Telex teleprinter sys-
tem. Bob Bemer introduced features such as the escape
sequence.
[3]
His British colleague Hugh McGregor Ross
helped to popularize this workaccording to Bemer, so
much so that the code that was to become ASCII was rst
called the Bemer-Ross Code in Europe.
[33]
Because of
his extensive work on ASCII, Bemer has been called the
father of ASCII.
[34]
On March 11, 1968, U.S. President Lyndon B. John-
son mandated that all computers purchased by the United
States federal government support ASCII, stating:
[35]
I have also approved recommendations of
the Secretary of Commerce regarding stan-
dards for recording the Standard Code for In-
formation Interchange on magnetic tapes and
paper tapes when they are used in computer
operations. All computers and related equip-
ment congurations brought into the Federal
Government inventory on and after July 1,
1969, must have the capability to use the Stan-
dard Code for Information Interchange and the
formats prescribed by the magnetic tape and
paper tape standards when these media are
used.
1.1.5 Other standards
Other international standards bodies have ratied charac-
ter encodings such as ISO/IEC 646 that are identical or
nearly identical to ASCII, with extensions for characters
outside the English alphabet and symbols used outside the
United States, such as the symbol for the United King-
doms pound sterling (). Almost every country needed
an adapted version of ASCII, since ASCII suited the
needs of only the USA and a few other countries. For ex-
ample, Canada had its own version that supported French
4 CHAPTER 1. ASCII
characters. Other adapted encodings include ISCII (In-
dia), VISCII (Vietnam), and YUSCII (Yugoslavia). Al-
though these encodings are sometimes referred to as
ASCII, true ASCII is dened strictly only by the ANSI
standard.
ASCII was incorporated into the Unicode character set as
the rst 128 symbols, so the 7-bit ASCII characters have
the same numeric codes in both sets. This allows UTF-8
to be backward compatible with 7-bit ASCII, as a UTF-
8 le containing only ASCII characters is identical to an
ASCII le containing the same sequence of characters.
Even more importantly, forward compatibility is ensured
as software that recognizes only 7-bit ASCII characters
as special and does not alter bytes with the highest bit set
(as is often done to support 8-bit ASCII extensions such
as ISO-8859-1) will preserve UTF-8 data unchanged.
[36]
1.2 ASCII control characters
Main article: Control character
ASCII reserves the rst 32 codes (numbers 031 deci-
mal) for control characters: codes originally intended not
to represent printable information, but rather to control
devices (such as printers) that make use of ASCII, or
to provide meta-information about data streams such as
those stored on magnetic tape.
For example, character 10 represents the line feed
function (which causes a printer to advance its paper),
and character 8 represents backspace. RFC2822 refers
to control characters that do not include carriage re-
turn, line feed or white space as non-whitespace control
characters.
[37]
Except for the control characters that pre-
scribe elementary line-oriented formatting, ASCII does
not dene any mechanism for describing the structure or
appearance of text within a document. Other schemes,
such as markup languages, address page and document
layout and formatting.
The original ASCII standard used only short descriptive
phrases for each control character. The ambiguity this
caused was sometimes intentional, for example where a
character would be used slightly dierently on a terminal
link than on a data stream, and sometimes accidental, for
example with the meaning of delete.
Probably the most inuential single device on the inter-
pretation of these characters was the Teletype Model 33
ASR, which was a printing terminal with an available
paper tape reader/punch option. Paper tape was a very
popular medium for long-term program storage until the
1980s, less costly and in some ways less fragile than mag-
netic tape. In particular, the Teletype Model 33 machine
assignments for codes 17 (Control-Q, DC1, also known
as XON), 19 (Control-S, DC3, also known as XOFF),
and 127 (Delete) became de facto standards. The Model
33 was also notable for taking the description of Control-
G (BEL, meaning audibly alert the operator) literally; the
unit contained an actual bell which it rang when it re-
ceived a BEL character. Because the keytop for the O
key also showed a left-arrow symbol (from ASCII-1963,
which had this character instead of underscore), a non-
compliant use of code 15 (Control-O, Shift In) inter-
preted as delete previous character was also adopted
by many early timesharing systems but eventually became
neglected.
When a Teletype 33 ASR equipped with the automatic
paper tape reader received a Control-S (XOFF, an abbre-
viation for transmit o), it caused the tape reader to stop;
receiving Control-Q (XON, transmit on) caused the
tape reader to resume. This technique became adopted
by several early computer operating systems as a hand-
shaking signal warning a sender to stop transmission be-
cause of impending overow; it persists to this day in
many systems as a manual output control technique. On
some systems Control-S retains its meaning but Control-
Q is replaced by a second Control-S to resume output.
The 33 ASR also could be congured to employ Control-
R (DC2) and Control-T (DC4) to start and stop the tape
punch; on some units equipped with this function, the
corresponding control character lettering on the keycap
above the letter was TAPE and TAPE respectively.
[38]
Code 127 is ocially named delete but the Teletype la-
bel was rubout. Since the original standard did not give
detailed interpretation for most control codes, interpreta-
tions of this code varied. The original Teletype meaning,
and the intent of the standard, was to make it an ignored
character, the same as NUL (all zeroes). This was useful
specically for paper tape, because punching the all-ones
bit pattern on top of an existing mark would obliterate
it.
[39]
Tapes designed to be hand edited could even be
produced with spaces of extra NULs (blank tape) so that
a block of characters could be rubbed out and then re-
placements put into the empty space.
Some software assigned special meanings to ASCII char-
acters sent to the software from the terminal. Operat-
1.2. ASCII CONTROL CHARACTERS 5
ing systems from Digital Equipment Corporation, for ex-
ample, interpreted DEL as an input character as mean-
ing remove previously-typed input character,
[40][41]
and
this interpretation also became common in Unix systems.
Most other systems used BS for that meaning and used
DEL to mean remove the character at the cursor. That
latter interpretation is the most common now.
Many more of the control codes have been given mean-
ings quite dierent from their original ones. The es-
cape character (ESC, code 27), for example, was in-
tended originally to allow sending other control charac-
ters as literals instead of invoking their meaning. This
is the same meaning of escape encountered in URL
encodings, C language strings, and other systems where
certain characters have a reserved meaning. Over time
this meaning has been co-opted and has eventually been
changed. In modern use, an ESCsent to the terminal usu-
ally indicates the start of a command sequence, usually
in the form of a so-called extquotedblANSI escape code
extquotedbl (or, more properly, a extquotedblControl Se-
quence Introducer extquotedbl) beginning with ESC fol-
lowed by a extquotedbl[ extquotedbl (left-bracket) char-
acter. An ESC sent from the terminal is most often used
as an out-of-band character used to terminate an oper-
ation, as in the TECO and vi text editors. In graphical
user interface (GUI) and windowing systems, ESC gen-
erally causes an application to abort its current operation
or to exit (terminate) altogether.
The inherent ambiguity of many control characters, com-
bined with their historical usage, created problems when
transferring plain text les between systems. The
best example of this is the newline problem on various
operating systems. Teletype machines required that a
line of text be terminated with both Carriage Return
(which moves the printhead to the beginning of the line)
and Line Feed (which advances the paper one line with-
out moving the printhead). The name Carriage Return
comes from the fact that on a manual typewriter the car-
riage holding the paper moved while the position where
the typebars struck the ribbon remained stationary. The
entire carriage had to be pushed (returned) to the right in
order to position the left margin of the paper for the next
line.
DEC operating systems (OS/8, RT-11, RSX-11, RSTS,
TOPS-10, etc.) used both characters to mark the end of
a line so that the console device (originally Teletype ma-
chines) would work. By the time so-called glass TTYs
(later called CRTs or terminals) came along, the conven-
tion was so well established that backward compatibil-
ity necessitated continuing the convention. When Gary
Kildall cloned RT-11 to create CP/M he followed estab-
lished DEC convention. Until the introduction of PC
DOS in 1981, IBM had no hand in this because their
1970s operating systems used EBCDIC instead of ASCII
and they were oriented toward punch-card input and line
printer output on which the concept of carriage return
was meaningless. IBMs PC DOS (also marketed as MS-
DOS by Microsoft) inherited the convention by virtue of
being a clone of CP/M, and Windows inherited it from
MS-DOS.
Unfortunately, requiring two characters to mark the end
of a line introduces unnecessary complexity and ques-
tions as to how to interpret each character when encoun-
tered alone. To simplify matters plain text data streams,
including les, on Multics
[42]
used line feed (LF) alone
as a line terminator. Unix and Unix-like systems, and
Amiga systems, adopted this convention from Multics.
The original Macintosh OS, Apple DOS, and ProDOS,
on the other hand, used carriage return (CR) alone as a
line terminator; however, since Apple replaced it with the
Unix-based OS X operating system, they now use line
feed (LF) as well.
Computers attached to the ARPANET included ma-
chines running operating systems such as TOPS-10 and
TENEXusing CR-LF line endings, machines running op-
erating systems such as Multics using LF line endings,
and machines running operating systems such as OS/360
that represented lines as a character count followed by the
characters of the line and that used EBCDIC rather than
ASCII. The Telnet protocol dened an ASCII Network
Virtual Terminal (NVT), so that connections between
hosts with dierent line-ending conventions and charac-
ter sets could be supported by transmitting a standard
text format over the network; it used ASCII, along with
CR-LF line endings, and software using other conven-
tions would translate between the local conventions and
the NVT.
[43]
The File Transfer Protocol adopted the Tel-
net protocol, including use of the Network Virtual Ter-
minal, for use when transmitting commands and trans-
ferring data in the default ASCII mode.
[44][45]
This adds
complexity to implementations of those protocols, and
to other network protocols, such as those used for E-
mail and the World Wide Web, on systems not using the
NVTs CR-LF line-ending convention.
[46][47]
Older operating systems such as TOPS-10, along with
CP/M, tracked le length only in units of disk blocks and
6 CHAPTER 1. ASCII
used Control-Z (SUB) to mark the end of the actual text
in the le. For this reason, EOF, or end-of-le, was used
colloquially and conventionally as a three-letter acronym
(TLA) for Control-Z instead of SUBstitute. For a variety
of reasons, the end-of-text code, ETXaka Control-C, was
inappropriate and using Z as the control code to end a le
is analogous to it ending the alphabet, a very convenient
mnemonic aid. An historic common, and still prevalent,
convention uses the ETX aka Control-C code convention
to interrupt and halt a program via an input data stream,
usually from a keyboard.
In C library and Unix conventions, the null character
is used to terminate text strings; such null-terminated
strings can be known in abbreviation as ASCIZ or
ASCIIZ, where here Z stands for zero.
1.2.1 ASCII control code chart
[1] The Unicode characters fromthe area U+2400 to U+2421
reserved for representing control characters when it is
necessary to print or display them rather than have them
perform their intended function. Some browsers may not
display these properly.
[2] Caret notation often used to represent control characters
on a terminal. On most text terminals, holding down the
Ctrl key while typing the second character will type the
control character. Sometimes the shift key is not needed,
for instance ^@ may be typable with just Ctrl and 2.
[3] Character Escape Codes in C programming language and
many other languages inuenced by it, such as Java and
Perl (though not all implementations necessarily support
all escape codes).
[4] The Backspace character can also be entered by pressing
the Backspace key on some systems.
[5] The ambiguity of Backspace is due to early terminals de-
signed assuming the main use of the keyboard would be
to manually punch paper tape while not connected to a
computer. To delete the previous character, one had to
back up the paper tape punch, which for mechanical and
simplicity reasons was a button on the punch itself and not
the keyboard, then type the rubout character. They there-
fore placed a key producing rubout at the location used
on typewriters for backspace. When systems used these
terminals and provided command-line editing, they had to
use the rubout code to perform a backspace, and often
did not interpret the backspace character (they might echo
extquotedbl^H for backspace). Other terminals not de-
signed for paper tape made the key at this location produce
Backspace, and systems designed for these used that char-
acter to back up. Since the delete code often produced a
backspace eect, this also forced terminal manufacturers
to make any Delete key produce something other than the
Delete character.
[6] The Tab character can also be entered by pressing the Tab
key on most systems.
[7] The Carriage Return character can also be entered by
pressing the Enter or Return key on most systems.
[8] The '\e' escape sequence is not part of ISO C and many
other language specications. However, it is understood
by several compilers, including GCC.
[9] The Escape character can also be entered by pressing the
Esc key on some systems.
[10] ^^ means Ctrl+^ (pressing the Ctrl and caret keys).
[11] The Delete character can sometimes be entered by press-
ing the Backspace key on some systems.
Other representations might be used by specialist equip-
ment, for example ISO 2047 graphics or hexadecimal
numbers.
1.3 ASCII printable characters
Codes 20 to 7E, known as the printable characters,
represent letters, digits, punctuation marks, and a few
miscellaneous symbols. There are 95 printable charac-
ters in total.
[lower-alpha 1]
Code 20, the space character, denotes the space be-
tween words, as produced by the space-bar of a key-
board. Since the space character is considered an invisi-
ble graphic (rather than a control character)
[10][9]
and thus
would not normally be visible, it is represented here by
Unicode character U+2420 extquotedbl extquotedbl;
Unicode characters U+2422 extquotedbl extquotedbl
and U+2423 extquotedbl extquotedbl are also available
for use when a visible representation of a space is neces-
sary.
Code 7F corresponds to the non-printable Delete
(DEL) control character and is therefore omitted from
this chart; it is covered in the previous sections chart.
Earlier versions of ASCII used the up-arrow instead
of the caret (5E) and the left-arrow instead of the
underscore (5F).
[48]
1.5. VARIANTS 7
1.3.1 ASCII printable code chart
1.4 Aliases
AJune 1992 RFC
[49]
and the Internet Assigned Numbers
Authority registry of character sets
[11]
recognize the fol-
lowing case-insensitive aliases for ASCII as suitable for
use on the Internet:
ANSI_X3.4-1968 (canonical name)
iso-ir-6
ANSI_X3.4-1986
ISO_646.irv:1991
ASCII
ISO646-US
US-ASCII (preferred MIME name)
[11]
us
IBM367
cp367
csASCII
Of these, the IANA encourages use of the name US-
ASCII for Internet uses of ASCII (even if it is a
redundant acronym, but the US is needed because of
abuse of the ASCII term). One often nds this in the op-
tional charset parameter in the Content-Type header of
some MIME messages, in the equivalent meta element
of some HTML documents, and in the encoding declara-
tion part of the prologue of some XML documents.
1.5 Variants
As computer technology spread throughout the world,
dierent standards bodies and corporations developed
many variations of ASCII to facilitate the expression
of non-English languages that used Roman-based al-
phabets. One could class some of these variations
as extquotedblASCII extensions extquotedbl, although
some misuse that term to represent all variants, includ-
ing those that do not preserve ASCIIs character-map in
the 7-bit range. Furthermore the ASCII extensions have
also been mislabelled as ASCII.
Many other countries developed variants of ASCII to in-
clude non-English letters (e.g. , , , ), currency sym-
bols (e.g. , ), etc.
The PETSCII code Commodore International used for
their 8-bit systems is probably unique among post-1970
codes in being based on ASCII-1963, instead of the more
common ASCII-1967, such as found on the ZXSpectrum
computer. Atari 8-bit computers and Galaksija comput-
ers also used ASCII variants.
1.5.1 7-bit
From early in its development,
[50]
ASCII was intended to
be just one of several national variants of an international
character code standard, ultimately published as ISO/IEC
646 (1972), which would share most characters in com-
mon but assign other locally useful characters to several
code points reserved for national use. However, the
four years that elapsed between the publication of ASCII-
1963 and ISOs rst acceptance of an international rec-
ommendation during 1967
[51]
caused ASCIIs choices for
the national use characters to seem to be de facto stan-
dards for the world, causing confusion and incompatibil-
ity once other countries did begin to make their own as-
signments to these code points.
ISO/IEC646, like ASCII, was a 7-bit character set. It did
not make any additional codes available, so the same code
points encoded dierent characters in dierent coun-
tries. Escape codes were dened to indicate which na-
tional variant applied to a piece of text, but they were
rarely used, so it was often impossible to know what
variant to work with and therefore which character a
code represented, and in general, text-processing systems
could cope with only one variant anyway.
Because the bracket and brace characters of ASCII were
assigned to national use code points that were used for
accented letters in other national variants of ISO/IEC
646, a German, French, or Swedish, etc. programmer
using their national variant of ISO/IEC 646, rather than
ASCII, had to write, and thus read, something such as
ai='n';
instead of
{ a[i]='\n'; }
8 CHAPTER 1. ASCII
C trigraphs were created to solve this problem for ANSI
C, although their late introduction and inconsistent imple-
mentation in compilers limited their use. Many program-
mers kept their computers on US-ASCII, so plain-text in
Swedish, German etc. (for example, in e-mail or Usenet)
contained extquotedbl{, } extquotedbl and similar vari-
ants in the middle of words, something those program-
mers got used to.
1.5.2 8-bit
Eventually, as 8-, 16- and 32-bit (and later 64-bit) com-
puters began to replace 18- and 36-bit computers as the
norm, it became common to use an 8-bit byte to store
each character in memory, providing an opportunity for
extended, 8-bit, relatives of ASCII. In most cases these
developed as true extensions of ASCII, leaving the origi-
nal character-mapping intact, but adding additional char-
acter denitions after the rst 128 (i.e., 7-bit) characters.
Most early home computer systems developed their own
8-bit character sets containing line-drawing and game
glyphs, and often lled in some or all of the control char-
acters from 0-31 with more graphics. Kaypro CP/M
computers used the upper 128 characters for the Greek
alphabet. The IBM PC dened code page 437, which re-
placed the control-characters with graphic symbols such
as smiley faces, and mapped additional graphic charac-
ters to the upper 128 positions. Operating systems such
as DOS supported these code-pages, and manufacturers
of IBM PCs supported them in hardware. Digital Equip-
ment Corporation developed the Multinational Character
Set (DEC-MCS) for use in the popular VT220 terminal;
this was one of the rst extensions designed more for in-
ternational languages than for block graphics. The Mac-
intosh dened Mac OS Roman and Postscript also de-
ned a set, both of these contained both international let-
ters and typographic punctuation marks instead of graph-
ics, more like modern character sets. The ISO/IEC 8859
standard (derived from the DEC-MCS) nally provided
a standard that most systems copied (at least as accu-
rately as they copied ASCII, but with many substitu-
tions). A popular further extension designed by Mi-
crosoft, Windows-1252 (often mislabeled as ISO-8859-
1), added the typographic punctuation marks needed for
traditional text printing.
ISO-8859-1, Windows-1252, and the original 7-bit
ASCII were the most common character encodings un-
til 2008 when UTF-8 became more common.
[13]
1.5.3 Unicode
Unicode and the ISO/IEC10646 Universal Character Set
(UCS) have a much wider array of characters, and their
various encoding forms have begun to supplant ISO/IEC
8859 and ASCII rapidly in many environments. While
ASCII is limited to 128 characters, Unicode and the UCS
support more characters by separating the concepts of
unique identication (using natural numbers called code
points) and encoding (to 8-, 16- or 32-bit binary formats,
called UTF-8, UTF-16 and UTF-32).
To allow backward compatibility, the 128 ASCII and
256 ISO-8859-1 (Latin 1) characters are assigned Uni-
code/UCS code points that are the same as their codes in
the earlier standards. Therefore, ASCII can be consid-
ered a 7-bit encoding scheme for a very small subset of
Unicode/UCS, and ASCII (when prexed with 0 as the
eighth bit) is valid UTF-8.
1.6 Order
ASCII-code order is also called ASCIIbetical order.
[52]
Collation of data is sometimes done in this order rather
than standard alphabetical order (collating sequence).
The main deviations in ASCII order are:
All uppercase come before lowercase letters, for ex-
ample, Z before a
Digits and many punctuation marks come before let-
ters; for example, 4 precedes one
Numbers are sorted navely as strings; for example,
10 precedes 2
An intermediate orderreadily implementedconverts
uppercase letters to lowercase before comparing ASCII
values. Nave number sorting can be averted by zero-
lling all numbers (e.g. 02 will sort before 10 as ex-
pected), although this is an external x and has nothing
to do with the ordering itself.
1.7 See also
3568 ASCII, an asteroid named after the character
encoding
1.9. REFERENCES 9
ASCII art
ASCII Ribbon Campaign
Extended ASCII
HTML decimal character rendering
1.8 Notes
[1] Printed out, the characters are: !
extquotedbl#$%&'()*+,./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~
1.9 References
Footnotes
[1] Pronunciation for ASCII. Merriam Webster (audio).
Retrieved 2008-04-14.
[2] R. Shirley (August 2007). RFC 4949. Retrieved 2013-
12-23.
[3] Brandel, Mary (July 6, 1999). 1963: The Debut of
ASCII. CNN. Retrieved 2008-04-14.
[4] American Standard Code for Information Interchange,
ASA X3.4-1963. American Standards Association.
June 17, 1963. Retrieved 2014-05-23.
[5] USA Standard Code for Information Interchange, USAS
X3.4-1967. United States of America Standards Institute.
July 7, 1967.
[6] American National Standard for Information Systems
Coded Character Sets 7-Bit American National Stan-
dard Code for Information Interchange (7-Bit ASCII),
ANSI X3.4-1986. American National Standards Institute.
March 26, 1986.
[7] Maini, Anil Kumar (2007). Digital Electronics: Princi-
ples, Devices and Applications. John Wiley and Sons. p.
28. ISBN 978-0-470-03214-5. In addition, it denes
codes for 33 nonprinting, mostly obsolete control charac-
ters that aect how the text is processed.
[8] International Organization for Standardization (Decem-
ber 1, 1975). extquotedblThe set of control characters
for ISO 646 extquotedbl. Internet Assigned Numbers Au-
thority Registry. Alternate U.S. version: . Accessed 2008-
04-14.
[9] RFC20: ASCII format for Network Interchange, ANSI
X3.4-1968, October 16, 1969.
[10] Mackenzie 1980, p. 223.
[11] Internet Assigned Numbers Authority (May 14, 2007).
extquotedblCharacter Sets extquotedbl. Accessed 2008-
04-14.
[12] Dubost, Karl (May 6, 2008). UTF-8 Growth On The
Web. W3C Blog. World Wide Web Consortium. Re-
trieved 2010-08-15.
[13] Davis, Mark (May 5, 2008). Moving to Unicode 5.1.
Ocial Google Blog. Google. Retrieved 2010-08-15.
[14] Davis, Mark (Jan 28, 2010). Unicode nearing 50% of
the web. Ocial Google Blog. Google. Retrieved 2010-
08-15.
[15] Mackenzie 1980, p. 211.
[16] Mackenzie 1980, p. 215, Decision 4.
[18] Stanley A. Sawyer, Steven George Krantz (1995). A TeX
Primer for Scientists. CRC Press, LLC. p. 13. ISBN 978-
0-8493-7159-2.
[19] Mackenzie 1980, p. 220, Decisions 8,9.
[23] John J. G. Savard. Computer Keyboards. Retrieved
2014-08-24.
[24] Mackenzie 1980, p. 243.
[25] Mackenzie 1980, pp. 243-245.
[26] Mackenzie 1980, pp. 66, 245.
[27] Mackenzie 1980, p. 435.
[28] Brief Report: Meeting of CCITT Working Party on the
New Telegraph Alphabet, May 1315, 1963.
[29] Report of ISO/TC/97/SC 2 Meeting of October 2931,
1963.
[30] Report on Task Group X3.2.4, June 11, 1963, Pentagon
Building, Washington, DC.
[31] Report of Meeting No. 8, Task Group X3.2.4, December
17 and 18, 1963
[32] Mackenzie 1980, p. 247248.
10 CHAPTER 1. ASCII
[33] Bob Bemer (n.d.). Bemer meets Europe. Trailing-
edge.com. Accessed 2008-04-14. Employed at IBM at
that time
[34] Biography of Robert William Bemer.
[35] Lyndon B. Johnson (March 11, 1968). MemorandumAp-
proving the Adoption by the Federal Government of a
Standard Code for Information Interchange. The Amer-
ican Presidency Project. Accessed 2008-04-14.
[36] utf-8(7) - Linux manual page. Man7.org. 2014-02-26.
[37] RFC 2822 (April 2001). NO-WS-CTL.
[38] McConnell, Robert; Haynes, James; Warren, RIchard.
Understanding ASCII Codes. Retrieved 11 May 2014.
[39] Re: editor and word processor history (was: Re: RTF
for emacs) extquotedbl.
[40] PDP-6 Multiprogramming System Manual. Digital
Equipment Corporation. 1965. p. 43.
[41] PDP-10 Reference Handbook, Book 3, Communicating
with the Monitor. Digital Equipment Corporation. 1969.
p. 5-5.
[42] Ossanna, J. F.; Saltzer, J. H. (November 1719, 1970).
Technical and human engineering problems in connect-
ing terminals to a time-sharing system. Proceedings of
the November 1719, 1970, Fall Joint Computer Confer-
ence. p. 357: AFIPS Press. pp. 355362. Using a
new-line function (combined carriage-return and line-
feed) is simpler for both man and machine than requiring
both functions for starting a new line; the American Na-
tional Standard X3.4-19687 permits the line-feed code to
carry the new-line meaning.
[43] T. O'Sullivan (May 19, 1971). TELNET Protocol. IETF.
pp. 4-5. RFC 158. https://tools.ietf.org/html/rfc158.
[44] Nancy J. Neigus (Aug 12, 1973). File Transfer Protocol.
IETF. RFC 542. https://tools.ietf.org/html/rfc542. Re-
trieved 2013-01-28.
[45] Jon Postel (June 1980). File Transfer Protocol. IETF.
RFC 765. https://tools.ietf.org/html/rfc765. Retrieved
2013-01-28.
[46] EOL translation plan for Mercurial
[47] Daniel J. Bernstein. Bare LFs in SMTP. Retrieved
2013-01-28.
[48] ASA X3.4-1963.
[49] RFC 1345 (June 1992).
[50] Specic Criteria, attachment to memo from R. W.
Reach, X3-2 Meeting September 14 and 15, Septem-
ber 18, 1961
[51] R. Marchal, ISO/TC 97 Computers and Information
Processing: Acceptance of Draft ISO Recommendation
No. 1052, December 22, 1967
[52] ASCIIbetical denition. PC Magazine. Retrieved 2008-
04-14.
Bibliography
Mackenzie, Charles E. (1980). Coded Character
Sets, History and Development. Addison-Wesley.
ISBN 0-201-14460-3.
1.10 Further reading
Bemer, R. W. (1960). A Proposal for Character
Code Compatibility. Communications of the ACM
3 (2): 7172. doi:10.1145/366959.366961.
Bemer, R. W (May 23, 2003). The Babel of Codes
Prior to ASCII: The 1960 Survey of Coded Charac-
ter Sets: The Reasons for ASCII. from:
--- Bemer, R. W. (December 1960). Survey
of coded character representation. Com-
munications of the ACM 3 (12): 639641.
doi:10.1145/367487.367493.
--- Smith, H. J.; Williams, F. A. (December
1960). Survey of punched card codes.
Communications of the ACM 3 (12): 642.
doi:10.1145/367487.367491.
Robinson, G. S. & Cargill, C. (1996). History and
impact of computer standards. Computer 29 (10):
7985. doi:10.1109/2.539725.
American National Standard Code for Information
Interchange. American National Standards Institute.
1977.
1.11 External links
The ASCII subset of Unicode
1.11. EXTERNAL LINKS 11
Fischer, Eric. The Evolution of Character Codes,
1874-1968.
Scanned copy of American Standard Code for In-
formation Interchange ASA standard X3.4-1963
Chapter 2
Image le formats
This article is about digital image formats used to store
photographic and other images. For disk-image le
formats, see Disk image. For digital le formats in
general, see File format.
Image le formats are standardized means of organizing
and storing digital images. Image les are composed of
digital data in one of these formats that can be rasterized
for use on a computer display or printer. An image le
format may store data in uncompressed, compressed, or
vector formats. Once rasterized, an image becomes a grid
of pixels, each of which has a number of bits to designate
its color equal to the color depth of the device displaying
it.
2.1 Image le sizes
Generally speaking, in raster images, Image le size is
positively correlated to the number of pixels in an image
and the color depth, or bits per pixel, of the image. Im-
ages can be compressed in various ways, however. Com-
pression uses an algorithmthat stores an exact representa-
tion or an approximation of the original image in a smaller
number of bytes that can be expanded back to its uncom-
pressed form with a corresponding decompression algo-
rithm. Considering dierent compressions, it is common
for two images of the same number of pixels and color
depth to have a very dierent compressed le size. Con-
sidering exactly the same compression, number of pix-
els, and color depth for two images, dierent graphical
complexity of the original images may also result in very
dierent le sizes after compression due to the nature
of compression algorithms. With some compression for-
mats, images that are less complex may result in smaller
compressed le sizes. This characteristic sometimes re-
sults in a smaller le size for some lossless formats than
lossy formats. For example, graphically simple images
(i.e. images with large continuous regions like line art or
animation sequences) may be losslessly compressed into
a GIF or PNG format and result in a smaller le size than
a lossy JPEG format.
Vector images, unlike raster images, can be any dimen-
sion independent of le size. File size increases only with
the addition of more vectors.
For example, a 640 * 480 pixel image with 24-bit color
would occupy almost a megabyte of space:
640 * 480 * 24 = 7,372,800 bits = 921,600 bytes
2.2 Image le compression
There are two types of image le compression algo-
rithms: lossless and lossy.
Lossless compression algorithms reduce le size while
preserving a perfect copy of the original uncompressed
image. Lossless compression generally, but not always,
results in larger les than lossy compression. Lossless
compression should be used to avoid accumulating stages
of re-compression when editing images.
Lossy compression algorithms preserve a representation
of the original uncompressed image that may appear to be
a perfect copy, but it is not a perfect copy. Often lossy
compression is able to achieve smaller le sizes than loss-
less compression. Most lossy compression algorithms al-
lowfor variable compression that trades image quality for
le size.
12
2.3. MAJOR GRAPHIC FILE FORMATS 13
2.3 Major graphic le formats
Including proprietary types, there are hundreds of image
le types. The PNG, JPEG, and GIF formats are most of-
ten used to display images on the Internet. These graphic
formats are listed and briey described below, separated
into the two main families of graphics: raster and vector.
In addition to straight image formats, Metale for-
mats are portable formats which can include both raster
and vector information. Examples are application-
independent formats such as WMF and EMF. The
metale format is an intermediate format. Most Win-
dows applications open metales and then save them in
their own native format. Page description language
refers to formats used to describe the layout of a printed
page containing text, objects and images. Examples are
PostScript, PDF and PCL.
2.3.1 Raster formats
JPEG/JFIF
JPEG(Joint Photographic Experts Group) is a lossy com-
pression method; JPEG-compressed images are usually
stored in the JFIF (JPEG File Interchange Format) le
format. The JPEG/JFIF lename extension is JPG or
JPEG. Nearly every digital camera can save images in
the JPEG/JFIF format, which supports 8-bit grayscale
images and 24-bit color images (8 bits each for red, green,
and blue). JPEG applies lossy compression to images,
which can result in a signicant reduction of the le size.
Applications can determine the degree of compression to
apply, and the amount of compression aects the visual
quality of the result. When not too great, the compres-
sion does not noticeably aect or detract from the im-
ages quality, but JPEG les suer generational degrada-
tion when repeatedly edited and saved. (JPEG also pro-
vides lossless image storage, but the lossless version is not
widely supported.)
JPEG 2000
JPEG 2000 is a compression standard enabling both loss-
less and lossy storage. The compression methods used
are dierent from the ones in standard JFIF/JPEG; they
improve quality and compression ratios, but also require
more computational power to process. JPEG 2000 also
adds features that are missing in JPEG. It is not nearly as
common as JPEG, but it is used currently in professional
movie editing and distribution (some digital cinemas, for
example, use JPEG 2000 for individual movie frames).
Exif
The Exif (Exchangeable image le format) format is a
le standard similar to the JFIF format with TIFF ex-
tensions; it is incorporated in the JPEG-writing software
used in most cameras. Its purpose is to record and to stan-
dardize the exchange of images with image metadata be-
tween digital cameras and editing and viewing software.
The metadata are recorded for individual images and in-
clude such things as camera settings, time and date, shut-
ter speed, exposure, image size, compression, name of
camera, color information. When images are viewed or
edited by image editing software, all of this image infor-
mation can be displayed.
The actual Exif metadata as such may be carried within
dierent host formats, e.g. TIFF, JFIF (JPEG) or PNG.
IFF-META is another example.
TIFF
The TIFF (Tagged Image File Format) format is a exi-
ble format that normally saves 8 bits or 16 bits per color
(red, green, blue) for 24-bit and 48-bit totals, respec-
tively, usually using either the TIFF or TIF lename ex-
tension. The tagged structure was designed to be eas-
ily extendible, and many vendors have introduced pro-
prietary special-purpose tags with the result that no
one reader handles every avor of TIFF le.. TIFFs can
be lossy and lossless; some oer relatively good lossless
compression for bi-level (black&white) images. Some
digital cameras can save images in TIFF format, using the
LZW compression algorithm for lossless storage. TIFF
image format is not widely supported by web browsers.
TIFF remains widely accepted as a photograph le stan-
dard in the printing business. TIFF can handle device-
specic color spaces, such as the CMYK dened by a
particular set of printing press inks. OCR (Optical Char-
acter Recognition) software packages commonly gener-
ate some form of TIFF image (often monochromatic) for
scanned text pages.
14 CHAPTER 2. IMAGE FILE FORMATS
RAW
RAW refers to raw image formats that are available on
some digital cameras, rather than to a specic format.
These formats usually use a lossless or nearly lossless
compression, and produce le sizes smaller than the TIFF
formats. Although there is a standard raw image format,
(ISO 12234-2, TIFF/EP), the raw formats used by most
cameras are not standardized or documented, and dier
among camera manufacturers.
Most camera manufacturers have their own software for
decoding or developing their raw le format, but there
are also many third-party raw le converter applications
available that accept raw les from most digital cameras.
Some graphic programs and image editors may not accept
some or all raw le formats, and some older ones have
been eectively orphaned already.
As far as videocameras are concerned, ARRI's Arriex
D-20 and D-21 cameras provide raw 3K-resolution sen-
sor data with Bayer pattern as still images (one per frame)
in a proprietary format (.ari le extension). Red Digi-
tal Cinema Camera Company, with its Mysterium sen-
sor family of still and video cameras, uses its propri-
etary raw format called REDCODE (.R3D extension),
which stores still as well as audio+video information in
one lossy-compressed le.
GIF
GIF (Graphics Interchange Format) is limited to an 8-bit
palette, or 256 colors. This makes the GIF format suit-
able for storing graphics with relatively few colors such
as simple diagrams, shapes, logos and cartoon style im-
ages. The GIF format supports animation and is still
widely used to provide image animation eects. Its LZW
lossless compression is more eective when large areas
have a single color, and less eective for photographic or
dithered images.
BMP
The BMP le format (Windows bitmap) handles graph-
ics les within the Microsoft Windows OS. Typically,
BMP les are uncompressed, and therefore large and
lossless; their advantage is their simple structure and wide
acceptance in Windows programs.
PNG
The PNG (Portable Network Graphics) le format was
created as a free, open-source alternative to GIF. The
PNG le format supports 8 bit paletted images (with op-
tional transparency for all palette colors) and 24 bit true-
color (16 million colors) or 48 bit truecolor with and with-
out alpha channel - while GIF supports only 256 colors
and a single transparent color.
Compared to JPEG, PNG excels when the image has
large, uniformly colored areas. Even for photographs
where JPEG is often the choice for nal distribution
since its compression technique typically yields smaller
le sizes PNG is still well-suited to storing images dur-
ing the editing process because of its lossless compres-
sion.
PNG provides a patent-free replacement for GIF (though
GIF is itself now patent-free), and can also replace many
common uses of TIFF. Indexed-color, grayscale, and
truecolor images are supported, plus an optional alpha
channel. The Adam7 interlacing allows an early preview,
even when only a small percentage of the image data has
been transmitted. PNG can store gamma and chromatic-
ity data for improved color matching on heterogeneous
platforms.
PNG is designed to work well in online viewing applica-
tions like web browsers and can be fully streamed with
a progressive display option. PNG is robust, providing
both full le integrity checking and simple detection of
common transmission errors.
Animated formats derived from PNG are MNG and
APNG. The latter is supported by Mozilla Firefox and
Opera and is backwards compatible with PNG.
PPM, PGM, PBM, and PNM
Netpbm format is a family including the portable
pixmap le format (PPM), the portable graymap le
format (PGM) and the portable bitmap le format
(PBM). These are either pure ASCII les or raw binary
les with an ASCII header that provide very basic func-
tionality and serve as a lowest common denominator for
converting pixmap, graymap, or bitmap les between dif-
ferent platforms. Several applications refer to them col-
lectively as PNM (Portable aNy Map).
WEBP
WebP is a new open image format that uses both loss-
less and lossy compression. It was designed by Google to
reduce image le size to speed up web page loading: its
principal purpose is to supersede JPEG as the primary
format for photographs on the web. WebP is based on
VP8's intra-frame coding and uses a container based on
RIFF.
HDR raster formats
Most typical raster formats cannot store HDR data (32
bit oating point values per pixel component), which is
why some relatively old or complex formats are still pre-
dominant here, and worth mentioning separately. Newer
alternatives are showing up, though. RGBE is the for-
mat for HDR images originating from Radiance and also
supported by Adobe Photoshop.
Other raster formats
JPEG XR (New JPEG standard based on Microsoft
HD Photo)
SGI
PCX (Personal Computer eXchange), obsolete
Sun Raster is an obsolete format
TGA (TARGA), obsolete
ILBM (IFF-style format for up to 32 bit in planar
representation, plus optional 64 bit extensions)
DEEP (IFF-style format used by TVPaint)
IMG (Graphical Environment Manager image le;
planar, run-length encoded)
ILBM - Interleaved Bitmap, used by Electronic arts
PLBM - Planar Bitmap, proprietary Amiga format
ECW (Enhanced Compression Wavelet)
IMG (ERDAS IMAGINE Image)
SID (multiresolution seamless image database, Mr-
SID)
CD5 (Chasys Draw Image)
FITS (Flexible Image Transport System)
PGF (Progressive Graphics File)
PAM (Portable Arbitrary Map) is a late addition to
the Netpbm family
XCF (eXperimental Computing Facility format, na-
tive GIMP format)
PSD (Adobe PhotoShop Document)
PSP (Corel Paint Shop Pro)
VICAR le format (NASA/JPL image transport
format)
2.3.2 Vector formats
Main article: Vector graphics
As opposed to the raster image formats above (where
the data describes the characteristics of each individual
pixel), vector image formats contain a geometric descrip-
tion which can be rendered smoothly at any desired dis-
play size.
At some point, all vector graphics must be rasterized in
order to be displayed on digital monitors. Vector im-
ages may also be displayed with analog CRT technol-
ogy such as that used in some electronic test equipment,
medical monitors, radar displays, laser shows and early
video games. Plotters are printers that use vector data
rather than pixel data to draw graphics.
CGM
CGM (Computer Graphics Metale) is a le format for
2D vector graphics, raster graphics, and text, and is de-
ned by ISO/IEC 8632. All graphical elements can be
specied in a textual source le that can be compiled into
a binary le or one of two text representations. CGM
provides a means of graphics data interchange for com-
puter representation of 2D graphical information inde-
pendent from any particular application, system, plat-
form, or device. It has been adopted to some extent in
the areas of technical illustration and professional design,
but has largely been superseded by formats such as SVG
and DXF.
16 CHAPTER 2. IMAGE FILE FORMATS
Gerber format (RS-274X)
The Gerber format (aka Extended Gerber, RS-274X) was
developed by Gerber Systems Corp., now Ucamco, and
is a 2D bi-level image description format. It is the de
facto standard format used by printed circuit board or
PCB software. It is also widely used in other industries
requiring high-precision 2D bi-level images.
SVG
SVG (Scalable Vector Graphics) is an open standard cre-
ated and developed by the World Wide Web Consortium
to address the need (and attempts of several corporations)
for a versatile, scriptable and all-purpose vector format
for the web and otherwise. The SVG format does not
have a compression scheme of its own, but due to the tex-
tual nature of XML, an SVG graphic can be compressed
using a program such as gzip. Because of its scripting
potential, SVG is a key component in web applications:
interactive web pages that look and act like applications.
Other 2D vector formats
AI (Adobe Illustrator)
CDR (CorelDRAW)
DrawingML
GEM metales (interpreted and written by the
Graphical Environment Manager VDI subsystem)
Graphics Layout Engine
HPGL, introduced on Hewlett-Packard plotters, but
generalized into a printer language
HVIF (Haiku Vector Icon Format)
MathML
NAPLPS (North American Presentation Layer Pro-
tocol Syntax)
ODG (OpenDocument Graphics)
!DRAW, a native vector graphic format (in sev-
eral backward compatible versions) for the RISC-
OS computer system begun by Acorn in the mid-
1980s and still present on that platform today
POV-Ray markup language
PPT (Microsoft PowerPoint)
Precision Graphics Markup Language, a W3C sub-
mission that was not adopted as a recommendation.
PSTricks and PGF/TikZ are languages for creating
graphics in TeX documents.
ReGIS, used by DEC computer terminals
Remote imaging protocol
VML (Vector Markup Language)
WMF / EMF (Windows Metale / Enhanced
Metale)
Xar format used in vector applications from Xara
XPS (XML Paper Specication)
3D vector formats
AMF - Additive Manufacturing File Format
Asymptote - A language that lifts TeX to 3D.
.blend - Blender
COLLADA
.dgn
.dwf
.dwg
.dxf
eDrawings
.t - OpenFlight
HSF
IGES
IMML - Immersive Media Markup Language
IPA
JT
OpenGEX - Open Game Engine Exchange
PRC
STEP
SKP
STL - A stereolithography format
U3D - Universal 3D le format
VRML - Virtual Reality Modeling Language
XAML
XGL
XVL
xVRML
X3D
.3D
3DF
.3DM
.3ds - Autodesk 3D Studio
3DXML
X3D - Vector format used in 3D applications from
Xara
2.3.3 Compound formats (see also
Metale)
These are formats containing both pixel and vector data,
possible other data, e.g. the interactive features of PDF.
EPS (Encapsulated PostScript)
PDF (Portable Document Format)
PostScript, a page description language with strong
graphics capabilities
PICT (Classic Macintosh QuickDraw le)
SWF (Shockwave Flash)
XAML User interface language using vector graph-
ics for images.
2.3.4 Stereo formats
MPO The Multi Picture Object (.mpo) format con-
sists of multiple JPEG images (Camera & Imaging
Products Association) (CIPA).
PNS The PNG Stereo (.pns) format consists of a
side-by-side image based on PNG (Portable Net-
work Graphics).
JPS The JPEG Stereo (.jps) format consists of a
side-by-side image format based on JPEG.
Chapter 3
BMP le format
The BMP le format, also known as bitmap image
le or device independent bitmap (DIB) le format
or simply a bitmap, is a raster graphics image le format
used to store bitmap digital images, independently of the
display device (such as a graphics adapter), especially on
Microsoft Windows
[2]
and OS/2
[3]
operating systems.
The BMP le format is capable of storing 2D digital
images of arbitrary width, height, and resolution, both
monochrome and color, in various color depths, and op-
tionally with data compression, alpha channels, and color
proles. The Windows Metale (WMF) specication
covers the BMP le format.
[4]
Among others wingdi.h
denes BMP constants and structures.
3.1 Device-independent bitmaps
and the BMP le format
Microsoft has dened a particular representation of color
bitmaps of dierent color depths, as an aid to exchang-
ing bitmaps between devices and applications with a vari-
ety of internal representations. They called these device-
independent bitmaps or DIBs, and the le format for them
is called DIB le format or BMP image le format.
According to Microsoft support:
[5]
A device-independent bitmap (DIB) is
a format used to dene device-independent
bitmaps in various color resolutions. The
main purpose of DIBs is to allow bitmaps
to be moved from one device to another
(hence, the device-independent part of the
name). A DIB is an external format, in con-
trast to a device-dependent bitmap, which ap-
pears in the system as a bitmap object (cre-
ated by an application...). A DIB is nor-
mally transported in metales (usually using
the StretchDIBits() function), BMP les, and
the Clipboard (CF_DIB data format).
The following sections discuss the data stored in the BMP
le or DIB in detail. This is the standard BMP le
format.
[5]
Some applications create bitmap image les
which are not compliant with the current Microsoft doc-
umentation. Also, not all elds are used; a value of 0 will
be found in these unused elds.
3.2 File structure
The bitmap image le consists of xed-size structures
(headers) as well as variable-size structures appearing in
a predetermined sequence. Many dierent versions of
some of these structures can appear in the le, due to the
long evolution of this le format.
Referring to the diagram 1, the bitmap le is composed
of structures in the following order:
3.2.1 DIBs in memory
A bitmap image le loaded into memory becomes a DIB
data structure an important component of the Windows
GDI API. The in-memory DIB data structure is almost
the same as the BMP le format, but it does not contain
the 14-byte bitmap le header and begins with the DIB
header. For DIBs loaded in memory, the color table can
also consist of 16 bit entries, that constitute indexes to the
currently realized palette
[8]
(an additional level of indi-
rection), instead of explicit RGB color denitions. In all
cases, the pixel array must begin at a memory address that
18
3.2. FILE STRUCTURE 19
is a multiple of 4 bytes. In non-packed DIBs loaded in
memory, the optional color prole data should be located
immediately after the color table and before the gap1 and
pixel array
[7]
(unlike in diag. 1).
When the size of gap1 and gap2 is zero, the in-memory
DIB data structure is customarily referred to as packed
DIB and can be referred to by a single pointer pointing
to the beginning of the DIB header. In all cases, the pixel
array must begin at a memory address that is a multiple
of 4 bytes. In some cases it may be necessary to adjust
the number of entries in the color table in order to force
the memory address of the pixel array to a multiple of
4 bytes.
[8]
For packed DIBs loaded in memory, the
optional color prole data should immediately follow
the pixel array, as depicted in diag. 1 (with gap1=0 and
gap2=0).
[7]
Packed DIBs are required by Windows clipboard API
functions as well as by some Windows patterned brush
and resource functions.
[9]
3.2.2 Bitmap le header
This block of bytes is at the start of the le and is used
to identify the le. A typical application reads this block
rst to ensure that the le is actually a BMP le and that
it is not damaged. The rst two bytes of the BMP le
format are the character 'B' then the character 'M' in 1-
byte ASCII encoding. All of the integer values are stored
in little-endian format (i.e. least-signicant byte rst).
The size value occupies 4 bytes by default. However, with
the use of the 4 reserved bytes, this value can occupy
8 bytes (64 bits) while still conforming to the BMPle
header format.
3.2.3 DIB header (bitmap information
header)
This block of bytes tells the application detailed informa-
tion about the image, which will be used to display the
image on the screen. The block also matches the header
used internally by Windows and OS/2 and has several dif-
ferent variants. All of themcontain a dword (32 bit) eld,
specifying their size, so that an application can easily de-
termine which header is used in the image. The reason
that there are dierent headers is that Microsoft extended
the DIB format several times. The new extended headers
can be used with some GDI functions instead of the older
ones, providing more functionality. Since the GDI sup-
ports a function for loading bitmap les, typical Windows
applications use that functionality. One consequence of
this is that for such applications, the BMP formats that
they support match the formats supported by the Win-
dows version being run. See the table below for more
information.
Versions after BITMAPCOREHEADER only add
elds to the end of the header of the previous ver-
sion. For example: BITMAPV2INFOHEADER
adds elds to BITMAPINFOHEADER and
BITMAPV3INFOHEADER adds elds to
BITMAPV2INFOHEADER.
An integrated alpha channel has been introduced with the
undocumented BITMAPV3INFOHEADER and with
the documented BITMAPV4HEADER (since Windows
95) and is used within Windows XP logon and theme sys-
tem as well as Microsoft Oce (since v2000); it is sup-
ported by some image editing software, such as Adobe
Photoshop since version 7 and Adobe Flash since version
MX 2004 (then known as Macromedia Flash). It is also
supported by GIMP, Google Chrome, Microsoft Power-
Point and Microsoft Word.
For compatibility reasons, most applications use the
older DIB headers for saving les. With OS/2 not more
supported after Windows 2000, for now the common
Windows format is the BITMAPINFOHEADERheader.
See next table for its description. All values are stored as
unsigned integers, unless explicitly noted.
An OS/2 2.x OS22XBITMAPHEADER aka BITMAP-
COREHEADER2 contains 24 additional bytes not yet
explained here.
[3]
The compression method (oset 30)
can be:
3.2.4 Color table
The color table (palette) occurs in the BMP image le
directly after the BMP le header, the DIB header (and
after optional three red, green and blue bitmasks if the
BITMAPINFOHEADER header with BI_BITFIELDS
option is used). Therefore, its oset is the size of the
BITMAPFILEHEADER plus the size of the DIB header
(plus optional 12 bytes for the three bit masks).
Note: On Windows CE the BITMAPINFOHEADER header can
be used with the BI_ALPHABITFIELDS
[6]
option in the biCom-
20 CHAPTER 3. BMP FILE FORMAT
pression member.
The number of entries in the palette is either 2
n
or a
smaller number specied in the header (in the OS/2
BITMAPCOREHEADER header format, only the full-
size palette is supported).
[3][5]
In most cases, each entry in
the color table occupies 4 bytes, in the order blue, green,
red, 0x00 (see below for exceptions). This is indexed in
the BITMAPINFOHEADER under the function biBit-
Count.
The color table is a block of bytes (a table) listing the
colors used by the image. Each pixel in an indexed color
image is described by a number of bits (1, 4, or 8) which
is an index of a single color described by this table. The
purpose of the color palette in indexed color bitmaps is
to inform the application about the actual color that each
of these index values corresponds to. The purpose of the
color table in non-indexed (non-palettized) bitmaps is to
list the colors used by the bitmap for the purposes of opti-
mization on devices with limited color display capability
and to facilitate future conversion to dierent pixel for-
mats and paletization.
The colors in the color table are usually specied in the
4-byte per entry RGBA32 format. The color table used
with the OS/2 BITMAPCOREHEADER uses the 3-byte
per entry RGB24 format.
[3][5]
For DIBs loaded in mem-
ory, the color table can optionally consist of 2-byte entries
- these entries constitute indexes to the currently realized
palette
[8]
instead of explicit RGB color denitions.
Microsoft does not disallow the presence of a valid al-
pha channel bit mask
[11]
in BITMAPV4HEADER and
BITMAPV5HEADER for 1bpp, 4bpp and 8bpp indexed
color images, which indicates that the color table entries
can also specify an alpha component using the 8.8.8.[0-
8].[0-8] format via the RGBQUAD.rgbReserved
[12]
member. However, some versions of Microsofts doc-
umentation disallow this feature by stating that the RG-
BQUAD.rgbReserved member must be zero.
As mentioned above, the color table is normally not used
when the pixels are in the 16-bit per pixel (16bpp) for-
mat (and higher); there are normally no color table en-
tries in those bitmap image les. However, the Microsoft
documentation (on the MSDN web site as of Nov. 16,
2010
[13]
) species that for 16bpp (and higher), the color
table can be present to store a list of colors intended for
optimization on devices with limited color display capa-
bility, while it also species, that in such cases, no indexed
palette entries are present in this Color Table. This may
seem like a contradiction if no distinction is made be-
tween the mandatory palette entries and the optional color
list.
3.2.5 Pixel storage
The bits representing the bitmap pixels are packed in
rows. The size of each row is rounded up to a multiple of
4 bytes (a 32-bit DWORD) by padding.
For images with height > 1, multiple padded rows are
stored consecutively, forming a Pixel Array.
The total number of bytes necessary to store one row of
pixels can be calculated as:
RowSize =
BitsPerPixelImageWidth+31
32
4,
ImageWidth is expressed in pixels.
The total amount of bytes necessary to store an array of
pixels in an n bits per pixel (bpp) image, with 2
n
colors,
can be calculated by accounting for the eect of round-
ing up the size of each row to a multiple of a 4 bytes, as
follows:
PixelArraySize = RowSize |ImageHeight|
ImageHeight is expressed in pixels. The ab-
solute value is necessary because ImageHeight
can be negative
Pixel array (bitmap data)
The pixel array is a block of 32-bit DWORDs, that de-
scribes the image pixel by pixel. Normally pixels are
stored upside-down with respect to normal image raster
scan order, starting in the lower left corner, going from
left to right, and then row by row from the bottom to the
top of the image.
[5]
Unless BITMAPCOREHEADER is
used, uncompressed Windows bitmaps also can be stored
from the top to bottom, when the Image Height value is
negative.
In the original OS/2 DIB, the only four legal values of
color depth were 1, 4, 8, and 24 bits per pixel (bpp).
[5]
Contemporary DIB Headers allow pixel formats with 1,
2, 4, 8, 16, 24 and 32 bits per pixel (bpp).
[14]
GDI+ also
permits 64 bits per pixel.
[15]
3.2. FILE STRUCTURE 21
Padding bytes (not necessarily 0) must be appended to the
end of the rows in order to bring up the length of the rows
to a multiple of four bytes. When the pixel array is loaded
into memory, each row must begin at a memory address
that is a multiple of 4. This address/oset restriction is
mandatory only for Pixel Arrays loaded in memory. For
le storage purposes, only the size of each row must be a
multiple of 4 bytes while the le oset can be arbitrary.
[5]
A 24-bit bitmap with Width=1, would have 3 bytes of
data per row (blue, green, red) and 1 byte of padding,
while Width=2 would have 2 bytes of padding, Width=3
would have 3 bytes of padding, and Width=4 would not
have any padding at all.
Compression
Indexed color images may be compressed with 4-bit
or 8-bit RLE or Human 1D algorithm.
OS/2 BITMAPCOREHEADER2 24bpp images
may be compressed with the 24-bit RLE algorithm.
The 16bpp and 32bpp images are always stored un-
compressed.
Note that images in all color depths can be stored
without compression if so desired.
Pixel format
In a bitmap image le on a disk or a bitmap image in
memory, the pixels can be dened by a varying number
of bits.
The 1-bit per pixel (1bpp) format supports 2 distinct
colors, (for example: black and white). The pixel
values are stored in each bit, with the rst (left-most)
pixel in the most-signicant bit of the rst byte.
[5]
Each bit is an index into a table of 2 colors. An unset
bit will refer to the rst color table entry, and a set
bit will refer to the last (second) color table entry.
The 2-bit per pixel (2bpp) format supports 4 distinct
colors and stores 4 pixels per 1 byte, the left-most
pixel being in the two most signicant bits (Windows
CE only:
[16]
). Each pixel value is a 2-bit index into
a table of up to 4 colors.
The 4-bit per pixel (4bpp) format supports 16 dis-
tinct colors and stores 2 pixels per 1 byte, the left-
most pixel being in the more signicant nibble.
[5]
Each pixel value is a 4-bit index into a table of up to
16 colors.
The 8-bit per pixel (8bpp) format supports 256 dis-
tinct colors and stores 1 pixel per 1 byte. Each byte
is an index into a table of up to 256 colors.
The 16-bit per pixel (16bpp) format supports 65536
distinct colors and stores 1 pixel per 2 byte WORD.
Each WORD can dene the alpha, red, green and
blue samples of the pixel.
The 24-bit pixel (24bpp) format supports
16,777,216 distinct colors and stores 1 pixel
value per 3 bytes. Each pixel value denes the red,
green and blue samples of the pixel (8.8.8.0.0 in
RGBAX notation). Specically in the order (blue,
green and red, 8-bits per each sample).
[5]
The 32-bit per pixel (32bpp) format supports
4,294,967,296 distinct colors and stores 1 pixel per
4 byte DWORD. Each DWORD can dene the Al-
pha, Red, Green and Blue samples of the pixel.
In order to resolve the ambiguity of which bits dene
which samples, the DIB Headers provide certain defaults
as well as specic BITFIELDS which are bit masks that
dene the membership of particular group of bits in a
pixel to a particular channel. The following diagram de-
nes this mechanism:
The BITFIELDS mechanism depicted in RGBAX sample length
notation
Diag. 2 The BITFIELDS mechanism for a 32 bit pixel
depicted in RGBAX sample length notation
The sample elds dened by the BITFIELDS bit masks
have to be contiguous and non-overlapping but the or-
der of the sample elds is arbitrary. The most ubiq-
uitous eld order is: Alpha, Blue, Green, Red (MSB
to LSB). The red, green and blue bit masks are valid
only when the Compression member of the DIB header
is set to BI_BITFIELDS. The alpha bit mask is valid
whenever it is present in the DIB header or when
the Compression member of the DIB header is set to
BI_ALPHABITFIELDS
[6]
(Windows CE only).
22 CHAPTER 3. BMP FILE FORMAT
The BITFIELDS mechanism depicted in RGBAX sample length
notation
Diag. 3 The pixel format with an alpha channel in a 16
bit pixel (in RGBAX sample Length notation) actually
generated by Adobe Photoshop
[16]
All of the possible pixel formats in a DIB
3.2.6 RGB video subtypes
The BITFIELD mechanism described above allows for
the denition of tens of thousands dierent pixel formats,
however only several of them are used in practice,
[16]
all
palettized formats RGB8, RGB4, and RGB1 (marked in
yellow in the table above, dshow.h MEDIASUBTYPE
names) and:
In version 2.1.4 FFmpeg supported (in its own termi-
nology) the BMP pixel formats bgra, bgr24, rgb565le,
rgb555le, rgb444le, rgb8, bgr8, rgb4_byte, bgr4_byte,
gray, pal8, and monob; i.e., bgra was the only supported
pixel format with transparency.
[18]
3.2.7 Example 1
Following is an example of a 22 pixel, 24-bit bitmap
(Windows DIB header BITMAPINFOHEADER) with
pixel format RGB24.
Example 2 of a 42 pixel bitmap, with 32 bits/pixel
encoding
3.2.8 Example 2
Following is an example of a 42 pixel, 32-bit bitmap
with opacity values in the alpha channel (Windows
0 1
0
1
Example 1 of a 22 pixel bitmap, with 24 bits/pixel encoding
DIB Header BITMAPV4HEADER) with pixel format
ARGB32.
Note that the bitmap data starts with the lower left hand
corner of the image.
3.3 Usage of BMP format
The simplicity of the BMP le format, and its widespread
familiarity in Windows and elsewhere, as well as the fact
that this format is relatively well documented and free of
patents, makes it a very common format that image pro-
cessing programs from many operating systems can read
and write. ICO and CUR les contain bitmaps starting
with a BITMAPINFOHEADER.
Many older graphical user interfaces used bitmaps in their
built-in graphics subsystems;
[19]
for example, the Mi-
crosoft Windows and OS/2 platforms GDI subsystem,
where the specic format used is the Windows and OS/2
bitmap le format, usually named with the le extension
of .BMP.
[20]
While most BMP les have a relatively large le size due
to lack of any compression (or generally low-ratio run-
length encoding on palletized images), many BMP les
can be considerably compressed with lossless data com-
pression algorithms such as ZIP because they contain re-
dundant data. Some formats, such as RAR, even include
routines specically targeted at ecient compression of
such data.
3.4 Related formats
Main article: Image le formats
The X Window System uses a similar XBM format for
black-and-white images, and XPM (pixelmap) for color
images. There are also a variety of raw formats, which
saves raw data with no other information. The Portable
Pixmap (PPM) and Truevision TGA formats also exist,
but are less often used or only for special purposes;
for example, TGA can contain transparency information.
Other bitmap le formats are in existence.
[21]
3.5 References
[1] .bmp MIME type not registered at IANA
[2] James D. Murray, William vanRyper (1996-04).
Encyclopedia of Graphics File Formats, Second Edi-
tion. O'Reilly. bmp. ISBN 1-56592-161-5. Retrieved
2014-03-07.
[3] James D. Murray, William vanRyper (1996-04).
Encyclopedia of Graphics File Formats, Second
Edition. O'Reilly. os2bmp. ISBN 1-56592-161-5.
[4] extquotedbl[MS-WMF]: Windows Metale Format.
MSDN. 2014-02-13. Retrieved 2014-03-12.
[5] DIBs and Their Uses. Microsoft Help and Support.
2005-02-11.
[6] MSDN - BITMAPINFOHEADER (Windows CE 5.0):
BI_ALPHABITFIELDS in biCompression member
[7] MSDN Bitmap Header Types
[8] MSDN BITMAPINFO Structure
[9] Feng Yuan - Windows graphics programming: Win32
GDI and DirectDraw: Packed Device-Independent
Bitmap (CreateDIBPatternBrush, CreateDIBPattern-
BrushPt, FindResource, LoadResource, LockResource)
[10] JPEG and PNG Extensions for Specic Bitmap Func-
tions and Structures.
[11] MSDN - BITMAPV4HEADER: The member
bV4AlphaMask
[12] MSDN - RGBQUAD: rgbReserved member
[13] see note under biClrUsed MSDN BITMAPINFO-
HEADER
[14] MSDN - BITMAPINFOHEADER: The member biBit-
Count
[15] Types of Bitmaps. MSDN. 2012-06-03. Retrieved
2014-03-16.
[16] MSDN: Windows CE - BITMAPINFOHEADER Struc-
ture
[17] Uncompressed RGB Video Subtypes. dshow.h.
MSDN. Retrieved 2014-03-11.
[18] Image Formats. FFmpeg General Documentation.
2014. Retrieved 2014-02-23.
[19] Julian Smart, Stefan Csomor, and Kevin Hock (2006).
Cross-Platform GUI Programming with Wxwidgets. Pren-
tice Hall. ISBN 0-13-147381-6.
[20] Bitmap Image File (BMP), Version 5. Digital Preserva-
tion. Library of Congress. 2014-01-08. Retrieved 2014-
03-11.
[21] List of bitmap le types. Search File-Extensions.org.
3.6 External links
Bitmap File Structure, at digicamsoft.com
An introduction to DIBs (Device Independent
Bitmaps), at herdsoft.com
A simple bitmap loader C++ class, at kalytta.com
(A2R10G10B10 not yet supported)
The BMP File Format, Part 1 By David Char-
lap at Dr. Dobbs journal of software tools (dr-
dobbs.com), March 1995
Free Online BMP Converter
Chapter 4
Hexadecimal
In mathematics and computing, hexadecimal (also base
16, or hex) is a positional numeral system with a radix,
or base, of 16. It uses sixteen distinct symbols, most of-
ten the symbols 09 to represent values zero to nine, and
A, B, C, D, E, F (or alternatively af) to represent val-
ues ten to fteen. Hexadecimal numerals are widely used
by computer systems designers and programmers. Sev-
eral dierent notations are used to represent hexadeci-
mal constants in computing languages; the prex 0x
is widespread due to its use in Unix and C (and related
operating systems and languages). Alternatively, some
authors denote hexadecimal values using a sux or sub-
script. For example, one could write 0x2AF3 or 2AF3
16
,
depending on the choice of notation.
As an example, the hexadecimal number 2AF3
16
can be
converted to an equivalent decimal representation. Ob-
serve that 2AF3
16
is equal to a sum of (2000
16
+ A00
16
+ F0
16
+ 3
16
), by decomposing the numeral into a series
of place value terms. Converting each term to decimal,
one can further write: (2
16
16
3
) + (A
16
16
2
) + (F
16
16
1
) + (3
16
16
0
),
(2 4096) + (10 256) + (15 16) + (3 1), or 10995.
Each hexadecimal digit represents four binary digits
(bits), and the primary use of hexadecimal notation is
a human-friendly representation of binary-coded values
in computing and digital electronics. One hexadecimal
digit represents a nibble, which is half of an octet or
byte (8 bits). For example, byte values can range from
0 to 255 (decimal), but may be more conveniently repre-
sented as two hexadecimal digits in the range 00 to FF.
Hexadecimal is also commonly used to represent com-
puter memory addresses.
4.1 Representation
4.1.1 Written representation
Using 09 and AF
In situations where there is no context, hexadecimal num-
bers can be ambiguous and confused with numbers ex-
pressed in other bases. There are several conventions for
expressing values unambiguously. A numerical subscript
(itself written in decimal) can give the base explicitly:
159
10
is decimal 159; 159
16
is hexadecimal 159, which
is equal to 345
10
. Other authors prefer a text subscript,
such as 159 and 159, or 159 and 159.
In linear text systems, such as those used in most com-
puter programming environments, a variety of methods
have arisen:
In URIs (including URLs), character codes are
written as hexadecimal pairs prexed with %: http:
//www.example.com/name%20with%20spaces
where %20 is the space (blank) character (code
value 20 in hex, 32 in decimal).
In XML and XHTML, characters can be expressed
as hexadecimal numeric character references using
the notation &#xcode;, where code is the 1- to 6-
digit hex number assigned to the character in the
Unicode standard. Thus ’ represents the
curled right single quote (Unicode value 2019 in
hex, 8217 in decimal).
Color references in HTML and CSS and X Win-
dow can be expressed with six hexadecimal digits
(two each for the red, green, and blue components,
in that order) prexed with #: white, for example, is
represented #FFFFFF .
[1]
CSS allows 3-hexdigit ab-
breviations with one hexdigit per component: #FA3
abbreviates #FFAA33 (a golden orange: ).
24
4.1. REPRESENTATION 25
*nix (Unix and related) shells, AT&T assembly
language, and likewise the C programming lan-
guage, which was designed for Unix (and the syn-
tactic descendants of C including C++, C#,
Java, JavaScript, Python and Windows PowerShell)
use the prex 0x for numeric constants repre-
sented in hex: 0x5A3. Character and string con-
stants may express character codes in hexadeci-
mal with the prex \x followed by two hex digits:
'\x1B' represents the Esc control character; extquot-
edbl\x1B[0m\x1B[25;1H is a string containing 11
characters (plus a trailing NUL to mark the end
of the string) with two embedded Esc characters.
[2]
To output an integer as hexadecimal with the printf
function family, the format conversion code %X or
%x is used.
In the Unicode standard, a character value is repre-
sented with U+ followed by the hex value: U+20AC
is the Euro sign ().
In MIME (e-mail extensions) quoted-printable en-
coding, characters that cannot be represented as lit-
eral ASCII characters are represented by their codes
as two hexadecimal digits (in ASCII) prexed by an
equal to sign =, as in Espa=F1a to send Espaa
(Spain). (Hexadecimal F1, equal to decimal 241, is
the code number for the lower case n with tilde in
the ISO/IEC 8859-1 character set.)
In Intel-derived assembly languages, hexadecimal is
denoted with a suxed H or h: FFh or 05A3H.
Some implementations require a leading zero when
the rst hexadecimal digit character is not a decimal
digit, so one would write 0FFh instead of FFh
Other assembly languages (6502, Motorola), Pascal,
Delphi, some versions of BASIC (Commodore),
Game Maker Language, Godot, GDScript, and
Forth use $ as a prex: $5A3.
Some assembly languages (Microchip) use the no-
tation H'ABCD' (for ABCD
16
).
Ada and VHDL enclose hexadecimal numerals in
based numeric quotes extquotedbl: 16#5A3#. For
bit vector constants VHDL uses the notation x
extquotedbl5A3.
[3]
Verilog represents hexadecimal constants in the
form 8'hFF, where 8 is the number of bits in the
value and FF is the hexadecimal constant.
Modula-2 and some other languages use # as a pre-
x: #05A3
The Smalltalk language uses the prex 16r: 16r5A3
PostScript and the Bourne shell and its deriva-
tives denote hex with prex 16#: 16#5A3. For
PostScript, binary data (such as image pixels) can
be expressed as unprexed consecutive hexadecimal
pairs: AA213FD51B3801043FBC...
In early systems when a Macintosh crashed, one or
two lines of hexadecimal code would be displayed
under the Sad Mac to tell the user what went wrong.
Common Lisp uses the prexes #x and #16r.
MSX BASIC,
[4]
QuickBASIC, FreeBASIC and
Visual Basic prex hexadecimal numbers with &H:
&H5A3
BBC BASIC and Locomotive BASIC use & for
hex.
[5]
TI-89 and 92 series uses a 0h prex: 0h5A3
The most common format for hexadecimal on
IBMmainframes (zSeries) and midrange computers
(IBM System i) running the traditional OSs (zOS,
zVSE, zVM, TPF, IBM i) is X'5A3', and is used in
Assembler, PL/I, COBOL, JCL, scripts, commands
and other places. This format was common on other
(and now obsolete) IBM systems as well. Occasion-
ally quotation marks were used instead of apostro-
phes.
Donald Knuth introduced the use of a particular
typeface to represent a particular radix in his book
The TeXbook.
[6]
Hexadecimal representations are
written there in a typewriter typeface: 5A3
Any IPv6 address can be written as eight
groups of four hexadecimal digits, where
each group is separated by a colon (:).
This, for example, is a valid IPv6 address:
2001:0db8:85a3:0000:0000:8a2e:0370:7334; this
can be abbreviated as 2001:db8:85a3::8a2e:370:
7334.
ALGOL 68 uses the prex 16r to denote hexadeci-
mal numbers: 16r5a3. Binary, quaternary (base-4)
and octal numbers can be specied similarly.
26 CHAPTER 4. HEXADECIMAL
There is no universal convention to use lowercase or up-
percase for the letter digits, and each is prevalent or pre-
ferred in particular environments by community stan-
dards or convention.
4.1.2 Early written representations
Bruce Alan Martins hexadecimal notation proposal
The choice of the letters A through F to represent the
digits above nine was not universal in the early history of
computers.
During the 1950s, some installations favored using
the digits 0 through 5 with a macron character ( ex-
tquotedbl extquotedbl) to denote the values 1015.
Bendix G-15 computers used the letters U through
Z.
The Librascope LGP-30 used the letters F, G, J, K,
Q and W.
[7]
Bruce Alan Martin of Brookhaven National Labora-
tory considered the choice of AF ridiculous and
in a 1968 letter to the editor of the CACMproposed
an entirely new set of symbols based on the bit lo-
cations, which did not gain much acceptance.
[8]
Soviet programmable calculators 3-34 and simi-
lar used the symbols extquotedbl extquotedbl, L,
C, extquotedbl extquotedbl, E, extquotedbl
extquotedbl (space) on their displays.
4.1.3 Verbal and digital representations
There are no traditional numerals to represent the quan-
tities from ten to fteen letters are used as a substitute
and most European languages lack non-decimal names
for the numerals above ten. Even though English has
names for several non-decimal powers (pair for the rst
binary power, score for the rst vigesimal power, dozen,
gross, and great gross for the rst three duodecimal pow-
ers), no English name describes the hexadecimal pow-
ers (decimal 16, 256, 4096, 65536, ... ). Some peo-
ple read hexadecimal numbers digit by digit like a phone
number: 4DA is four-dee-ay. However, the letter A
sounds like eight, C sounds like three, and D can
easily be mistaken for the extquotedbl-ty sux: Is it
4D or forty? Other people avoid confusion by using the
NATO phonetic alphabet: 4DA is four-delta-alfa, the
Joint Army/Navy Phonetic Alphabet (four-dog-able),
or a similar ad hoc system.
Hexadecimal nger-counting scheme.
Systems of counting on digits have been devised for both
binary and hexadecimal. Arthur C. Clarke suggested us-
ing each nger as an on/o bit, allowing nger counting
from zero to 1023
10
on ten ngers. Another system for
counting up to FF
16
(255
10
) is illustrated on the right.
4.1.4 Signs
The hexadecimal system can express negative numbers
the same way as in decimal: 2A to represent 42
10
and
so on.
However, some prefer instead to use the hexadecimal
4.2. CONVERSION 27
notation to express the exact bit patterns used in the
processor, so a sequence of hexadecimal digits may rep-
resent a signed or even a oating point value. This way,
the negative number 42
10
can be written as FFFF FFD6
in a 32-bit CPU register (in twos-complement), as C228
0000 in a 32-bit FPU register or C045 0000 0000 0000
in a 64-bit FPU register (in the IEEE oating-point stan-
dard).
4.1.5 Hexadecimal exponential notation
Just as decimal numbers can be represented in
exponential notation so too can hexadecimal. By
convention, the letter p represents times two raised to the
power of, whereas e serves a similar purpose in decimal.
The number after the p is decimal and represents the
binary exponent.
Usually the number is normalised: that is, the leading
hexadecimal digit is 1 (unless the value is exactly 0).
Example: 1.3DEp42 represents 1.3DE
16
2
42
.
Hexadecimal exponential notation is required by the
IEEE 754 binary oating-point standard. This notation
can be produced by some versions of the printf family of
functions by using the %a conversion.
4.2 Conversion
4.2.1 Binary conversion
Most computers manipulate binary data, but it is di-
cult for humans to work with the large number of digits
for even a relatively small binary number. Although most
humans are familiar with the base 10 system, it is much
easier to map binary to hexadecimal than to decimal be-
cause each hexadecimal digit maps to a whole number
of bits (4
10
). This example converts 1111
2
to base ten.
Since each position in a binary numeral can contain ei-
ther a 1 or a 0, its value may be easily determined by its
position from the right:
0001
2
= 1
10
0010
2
= 2
10
0100
2
= 4
10
1000
2
= 8
10
Therefore:
With little practice, mapping 1111
2
to F
16
in one step
becomes easy: see table in Written representation. The
advantage of using hexadecimal rather than decimal in-
creases rapidly with the size of the number. When the
number becomes large, conversion to decimal is very te-
dious. However, when mapping to hexadecimal, it is triv-
ial to regard the binary string as 4-digit groups and map
each to a single hexadecimal digit.
This example shows the conversion of a binary number
to decimal, mapping each digit to the decimal value, and
adding the results.
Compare this to the conversion to hexadecimal, where
each group of four digits can be considered indepen-
dently, and converted directly:
The conversion from hexadecimal to binary is equally di-
rect.
The octal system can also be useful as a tool for people
who need to deal directly with binary computer data. Oc-
tal represents data as three bits per character, rather than
four.
4.2.2 Division-remainder in source base
As with all bases there is a simple algorithm for con-
verting a representation of a number to hexadecimal by
doing integer division and remainder operations in the
source base. In theory, this is possible from any base, but
for most humans only decimal and for most computers
only binary (which can be converted by far more ecient
methods) can be easily handled with this method.
Let d be the number to represent in hexadecimal, and the
series hh...h
2
h
1
be the hexadecimal digits representing
the number.
1. i := 1
2. h := d mod 16
3. d := (dh) / 16
4. If d = 0 (return series h) else increment i and go to
step 2
16 may be replaced with any other base that may be
desired.
The following is a JavaScript implementation of the
above algorithm for converting any number to a hexadec-
imal in String representation. Its purpose is to illustrate
the above algorithm. To work with data seriously, how-
ever, it is much more advisable to work with bitwise op-
erators.
function toHex(d) { var r = d % 16; var result; if (d-r
== 0) result = toChar(r); else result = toHex( (d-r)/16 )
+ toChar(r); return result; } function toChar(n) { const
alpha = 0123456789ABCDEF extquotedbl; return
alpha.charAt(n); }
4.2.3 Addition and multiplication
x 1 2 3 4 5 6 7 8 9 A B C D E F 10
1
2
3
4
5
6
7
8
9
A
B
C
D
E
F
10
2 4 6 8 A C E 10 12 14 16 18 1A 1C 1E 20
1 2 3 4 5 6 7 8 9 A B C D E F 10
3 6 9 C F 12 15 18 1B 1E 21 24 27 2A 2D 30
4 8 C 10 14 18 1C 20 24 28 2C 30 34 38 3C 40
5 A F 14 19 1E 23 28 2D 32 37 3C 41 46 4B 50
6 C 12 18 1E 24 2A 30 36 3C 42 48 4E 54 5A 60
7 E 15 1C 23 2A 31 38 3F 46 4D 54 5B 62 69 70
8 10 18 20 28 30 38 40 48 50 58 60 68 70 78 80
9 12 1B 24 2D 36 3F 48 51 5A 63 6C 75 7E 87 90
A 14 1E 28 32 3C 46 50 5A 64 6E 78 82 8C 96 A0
B 16 21 2C 37 42 4D 58 63 6E 79 84 8F 9A A5 B0
C 18 24 30 3C 48 54 60 6C 78 84 90 9C A8 B4 C0
D 1A 27 34 41 4E 5B 68 75 82 8F 9C A9 B6 C3 D0
E 1C 2A 38 46 54 62 70 7E 8C 9A A8 B6 C4 D2 E0
F 1E 2D 3C 4B 5A 69 78 87 96 A5 B4 C3 D2 E1 F0
10 20 30 40 50 60 70 80 90 A0 B0 C0 D0 E0 F0 100
A hexadecimal multiplication table
It is also possible to make the conversion by assigning
each place in the source base the hexadecimal represen-
tation of its place value and then performing multiplica-
tion and addition to get the nal representation. That is,
to convert the number B3AD to decimal one can split the
hexadecimal number into its digits: B (11
10
), 3 (3
10
), A
(10
10
) and D (13
10
), and then get the nal result by mul-
tiplying each decimal representation by 16
p
, where p is
the corresponding hex digit position, counting from right
to left, beginning with 0. In this case we have B3AD =
(11 16
3
) + (3 16
2
) + (10 16
1
) + (13 16
0
), which
is 45997 base 10.
4.2.4 Tools for conversion
Most modern computer systems with graphical user in-
terfaces provide a built-in calculator utility, capable of
performing conversions between various radices, in gen-
eral including hexadecimal.
In Microsoft Windows, the Calculator utility can be set to
Scientic mode (called Programmer mode in some ver-
sions), which allows conversions between radix 16 (hex-
adecimal), 10 (decimal), 8 (octal) and 2 (binary), the
bases most commonly used by programmers. In Scien-
tic Mode, the on-screen numeric keypad includes the
hexadecimal digits A through F, which are active when
Hex is selected. In hex mode, however, the Windows
Calculator supports only integers.
4.3 Real numbers
As with other numeral systems, the hexadecimal sys-
tem can be used to represent rational numbers, although
recurring digits are common since sixteen (10) has only
a single prime factor (two):
where an overline denotes a recurring pattern.
For any base, 0.1 (or 1/10) is always equivalent to one
divided by the representation of that base value in its
own number system: Counting in base 3 is 0, 1, 2, 10
(three). Thus, whether dividing one by two for binary or
dividing one by sixteen for hexadecimal, both of these
fractions are written as 0.1. Because the radix 16 is a
perfect square (4), fractions expressed in hexadecimal
have an odd period much more often than decimal ones,
and there are no cyclic numbers (other than trivial single
digits). Recurring digits are exhibited when the denomi-
nator in lowest terms has a prime factor not found in the
radix; thus, when using hexadecimal notation, all frac-
tions with denominators that are not a power of two result
in an innite string of recurring digits (such as thirds and
fths). This makes hexadecimal (and binary) less con-
venient than decimal for representing rational numbers
since a larger proportion lie outside its range of nite rep-
resentation.
All rational numbers nitely representable in hex-
adecimal are also nitely representable in decimal,
duodecimal, and sexagesimal: that is, any hexadecimal
number with a nite number of digits has a nite num-
ber of digits when expressed in those other bases. Con-
4.5. KEY TO NUMBER BASE NOTATION 29
versely, only a fraction of those nitely representable in
the latter bases are nitely representable in hexadecimal.
For example, decimal 0.1 corresponds to the innite re-
curring representation 0.199999999999... in hexadeci-
mal. However, hexadecimal is more ecient than bases
12 and 60 for representing fractions with powers of two
in the denominator (e.g., decimal one sixteenth is 0.1 in
hexadecimal, 0.09 in duodecimal, 0:3:45 in sexagesimal
and 0.0625 in decimal).
4.3.1 Powers
Possibly the most widely used powers, powers of two, are
easier to show using base 16. The rst sixteen powers of
two are shown below.
Since four squared is sixteen, powers of four have an even
easier relation:
This also makes tetration simpler when using two and four
since:
3
2 = 2
4
= 10,
4
2 = 2
16
= 10000 and
5
2 = 2
65536
= (1 followed by 16384 zeros).
4.4 Cultural
4.4.1 Etymology
The word hexadecimal is composed of hexa-, derived
from the Greek (hex) for six, and -decimal, de-
rived from the Latin for tenth. Websters Third New
International online derives hexadecimal as an alter-
ation of the all-Latin sexadecimal (which appears in
the earlier Bendix documentation). The earliest date
attested for hexadecimal in Merriam-Webster Colle-
giate online is 1954, placing it safely in the category
of international scientic vocabulary (ISV). It is com-
mon in ISV to mix Greek and Latin combining forms
freely. The word extquotedblsexagesimal extquotedbl
(for base 60) retains the Latin prex. Donald Knuth
has pointed out that the etymologically correct term is
senidenary (or possibly sedenary), from the Latin
termfor grouped by 16. (The terms binary, ternary
and quaternary are from the same Latin construc-
tion, and the etymologically correct terms for deci-
mal and octal arithmetic are denary and octonary,
respectively.)
[9]
Alfred B. Taylor used senidenary in his
mid-1800s work on alternative number bases, although
he rejected base 16 because of its incommodious num-
ber of digits.
[10][11]
Schwartzman notes that the expected
form from usual Latin phrasing would be sexadecimal,
but computer hackers would be tempted to shorten that
word to sex.
[12]
The etymologically proper Greek term
would be hexadecadic (although in Modern Greek deca-
hexadic () is more commonly used).
4.4.2 Use in Chinese culture
The traditional Chinese units of weight were base-16. For
example, one jn () in the old systemequals sixteen taels.
The suanpan (Chinese abacus) could be used to perform
hexadecimal calculations.
4.4.3 Primary numeral system
Similar to dozenal advocacy, there have been occasional
attempts to promote hexadecimal as the preferred nu-
meral system. These attempts usually propose pronun-
ciation and/or symbology.
[13]
Sometimes the proposal
unies standard measures so that they are multiples of
16.
[14][15][16]
An example of unifying standard measures is
hexadecimal time, which subdivides a day by 16 so
that there are 16 hexhours in a day.
[16]
4.5 Key to number base notation
Simple key for notations used in article:
4.6 See also
Base32, Base64 (content encoding schemes)
Hex editor
Hex dump
4.7 References
[1] Hexadecimal web colors explained.
[2] The string extquotedbl\x1B[0m\x1B[25;1H species the
character sequence Esc [ 0 m Esc [ 2 5 ; 1 H Nul. These
are the escape sequences used on an ANSI terminal that
reset the character set and color, and then move the cursor
to line 25.
[3] The VHDL MINI-REFERENCE: VHDL IDENTI-
FIERS, NUMBERS, STRINGS, AND EXPRESSIONS
[4] MSX is Coming Part 2: Inside MSX Compute!, issue
56, January 1985, p. 52
[5] BBC BASIC programs are not fully portable to Microsoft
BASIC (without modication) since the latter takes & to
prex octal values. (Microsoft BASIC primarily uses &O
to prex octal, and it uses &H to prex hexadecimal, but
the ampersand alone yields a default interpretation as an
octal prex.
[6] Donald E. Knuth. The TeXbook (Computers and Type-
setting, Volume A). Reading, Massachusetts: Addison
Wesley, 1984. ISBN 0-201-13448-9. The source code of
the book in TeX(and a required set of macros CTAN.org)
is available online on CTAN.
[7] This somewhat odd sequence was from the next six se-
quential numeric keyboard codes in the LGP-30s 6-bit
character code. LGP-30 PROGRAMMING MANUAL
[8] Letters to the editor: On binary notation, Bruce Alan Mar-
tin, Associated Universities Inc., Communications of the
ACM, Volume 11, Issue 10 (October 1968) Page: 658
doi:10.1145/364096.364107
[9] Knuth, Donald. (1969). The Art of Computer Program-
ming, Volume 2. ISBN 0-201-03802-1. (Chapter 17.)
[10] A.B. Taylor, Report on Weights and Measures, Pharma-
ceutical Association, 8th Annual Session, Boston, Sept.
15, 1859. See pages and 33 and 41.
[11] Alfred B. Taylor, Octonary numeration and its applica-
tion to a system of weights and measures, Proc Amer.
Phil. Soc. Vol XXIV, Philadelphia, 1887; pages 296-366.
See pages 317 and 322.
[12] Schwartzman, S. (1994). The Words of Mathematics: an
etymological dictionary of mathematical terms used in En-
glish. ISBN 0-88385-511-9.
[13] Base 4^2 Hexadecimal Symbol Proposal.
[14] Intuitor Hex Headquarters.
[15] Aproposal for addition of the six Hexadecimal digits (A-
F) to Unicode.
[16] Nystrom, John William (1862). Project of a New System
of Arithmetic, Weight, Measure and Coins: Proposed to be
called the Tonal System, with Sixteen to the Base. Philadel-
phia.
Chapter 5
JPEG
For other uses, see JPEG (disambiguation).
In computing, JPEG (/dep/ JAY-peg)
[1]
(seen most
Continuously varied JPEG compression (between Q=100 and
Q=1) for an abdominal CT scan.
often with the .jpg or .jpeg lename extension) is a com-
monly used method of lossy compression for digital im-
ages, particularly for those images produced by digital
photography. The degree of compression can be ad-
justed, allowing a selectable tradeobetween storage size
and image quality. JPEG typically achieves 10:1 com-
pression with little perceptible loss in image quality.
JPEG compression is used in a number of image le for-
mats. 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. These format variations are of-
ten not distinguished, and are simply called JPEG.
The term JPEG is an acronym for the Joint Photo-
graphic Experts Group, which created the standard. The
MIME media type for JPEG is image/jpeg (dened in
RFC 1341), except in Internet Explorer, which pro-
vides a MIME type of image/pjpeg when uploading JPEG
images.
[2]
JPEG/JFIF supports a maximum image size of
6553565535 pixels
[3]
one to four gigapixels (1000
megapixels), depending on aspect ratio (from panoramic
3:1 to square).
5.1 The JPEG standard
The name JPEG stands for Joint Photographic Ex-
perts 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. In 1987 ISO TC 97 became ISO/IEC
JTC1 and in 1992 CCITT became ITU-T. Currently on
the JTC1 side JPEGis one of two sub-groups of ISO/IEC
Joint Technical Committee 1, Subcommittee 29, Work-
ing Group 1 (ISO/IEC JTC 1/SC 29/WG 1) titled as
Coding of still pictures.
[4][5][6]
On the ITU-T side ITU-T
SG16 is the respective body. The original JPEG group
was organized in 1986,
[7]
issuing the rst JPEG standard
in 1992, which was approved in September 1992 as ITU-
T Recommendation T.81
[8]
and in 1994 as ISO/IEC
10918-1.
The JPEG standard species the codec, which denes
how an image is compressed into a stream of bytes and
decompressed back into an image, but not the le format
used to contain that stream.
[9]
The Exif and JFIF stan-
dards dene the commonly used le formats for inter-
change of JPEG-compressed images.
JPEG standards are formally named as Information tech-
nology Digital compression and coding of continuous-
tone still images. ISO/IEC 10918 consists of the follow-
ing parts:
31
32 CHAPTER 5. JPEG
Ecma International TR/98 species the JPEG File Inter-
change Format (JFIF); the rst edition was published in
June 2009.
[12]
5.2 Typical usage
The JPEG compression algorithm is at its best on pho-
tographs and paintings of realistic scenes with smooth
variations of tone and color. For web usage, where the
amount of data used for an image is important, JPEG is
very popular. JPEG/Exif is also the most common for-
mat saved by digital cameras.
On the other hand, JPEG may not be as well suited for
line drawings and other textual or iconic graphics, where
the sharp contrasts between adjacent pixels can cause no-
ticeable artifacts. Such images may be better saved in a
lossless graphics format such as TIFF, GIF, PNG, or a
raw image format. The JPEG standard actually 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 somewhat reduces the image delity, it
should not be used in scenarios where the exact repro-
duction of the data is required (such as some scientic
and medical imaging applications and certain technical
image processing work).
JPEGis also not well suited to les that will undergo mul-
tiple edits, as some image quality will usually be lost each
time the image is decompressed and recompressed, par-
ticularly if the image is cropped or shifted, or if encoding
parameters are changed see digital generation loss for
details. To avoid this, an image that is being modied or
may be modied in the future can be saved in a lossless
format, with a copy exported as JPEG for distribution.
5.3 JPEG compression
JPEG uses a lossy form of compression based on the
discrete cosine transform (DCT). This mathematical op-
eration converts each frame/eld of the video source from
the spatial (2D) domain into the frequency domain (aka
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 reduc-
ing information is called quantization. In simpler terms,
quantization is a method for optimally reducing a large
number scale (with dierent occurrences of each num-
ber) into a smaller one, and the transform-domain is a
convenient representation of the image because the high-
frequency coecients, which contribute less to the over-
all picture than other coecients, are characteristically
small-values with high compressibility. The quantized
coecients are then sequenced and losslessly packed into
the output bitstream. Nearly all software implementa-
tions of JPEG permit user control over the compression-
ratio (as well as other optional parameters), allowing the
user to trade o picture-quality for smaller le size. In
embedded applications (such as miniDV, which uses a
similar DCT-compression scheme), the parameters are
pre-selected and xed for the application.
The compression method is usually lossy, meaning that
some original image information is lost and cannot be
restored, possibly aecting image quality. There is an
optional lossless mode dened in the JPEG standard.
However, this mode is not widely supported in products.
Widespread use of the format has stimulated the adoption
of simulated HDR modes in inexpensive cameras and
smartphones, notably recent models of Apples iPhone,
to correct the loss of shadow and highlight detail.
There is also an interlaced Progressive JPEG format, in
which data is compressed in multiple passes of progres-
sively higher detail. This is ideal for large images that
will be displayed while downloading over a slow connec-
tion, allowing a reasonable preview after receiving only
a portion of the data. However, support for progressive
JPEGs is not universal. When progressive JPEGs are re-
ceived by programs that do not support them(such as ver-
sions of Internet Explorer before Windows 7)
[13]
the soft-
ware only displays the image after it has been completely
downloaded.
There are also many medical imaging and trac systems
that create and process 12-bit JPEG images, normally
grayscale images. The 12-bit JPEG format has been part
of the JPEG specication for some time, but this format
is not as widely supported.
5.3.1 Lossless editing
See also: jpegtran and Commons:User:Cropbot
A number of alterations to a JPEG image can be per-
5.4. JPEG FILES 33
formed losslessly (that is, without recompression and the
associated quality loss) as long as the image size is a mul-
tiple of 1 MCUblock (MinimumCoded Unit) (usually 16
pixels in both directions, for 4:2:0 chroma subsampling).
Utilities that implement this include jpegtran, with user
interface Jpegcrop, and the JPG_TRANSFORM plugin
to IrfanView.
Blocks can be rotated in 90 degree increments, ipped
in the horizontal, vertical and diagonal axes and moved
about in the image. Not all blocks fromthe original image
need to be used in the modied 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 ips and rotations of an im-
age 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).
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 le and can be recovered. It is also
possible to transform between baseline and progressive
formats without any loss of quality, since the only dier-
ence is the order in which the coecients are placed in
the le.
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.
5.4 JPEG les
The le format known as JPEG Interchange Format
(JIF) is specied in Annex B of the standard. However,
this pure le format is rarely used, primarily because of
the diculty of programming encoders and decoders that
fully implement all aspects of the standard and because
of certain shortcomings of the standard:
Color space denition
Component sub-sampling registration
Pixel aspect ratio denition.
Several additional standards have evolved to address
these issues. The rst of these, released in 1992, was
JPEG File Interchange Format (or JFIF), followed in re-
cent years by Exchangeable image le format (Exif) and
ICC color proles. Both of these formats use the actual
JIF byte layout, consisting of dierent markers, but in ad-
dition employ one of the JIF standards extension points,
namely the application markers: JFIF use APP0, while
Exif use APP1. Within these segments of the le, that
were left for future use in the JIF standard and aren't read
by it, these standards add specic metadata.
Thus, in some ways JFIF is a cutdown version of the JIF
standard in that it species certain constraints (such as
not allowing all the dierent encoding modes), while in
other ways it is an extension of JIF due to the added meta-
data. The documentation for the original JFIF standard
states:
[14]
JPEG File Interchange Format is a minimal le
format which enables JPEG bitstreams to be ex-
changed between a wide variety of platforms
and applications. This minimal format does not
include any of the advanced features found in
the TIFF JPEG specication or any application
specic le format. Nor should it, for the only
purpose of this simplied format is to allow the
exchange of JPEG compressed images.
Image les that employ JPEGcompression are commonly
called JPEG les, and are stored in variants of the JIF
image format. Most image capture devices (such as dig-
ital cameras) that output JPEG are actually creating les
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
proles, most image editing software stores JPEGin JFIF
format, and also include the APP1 segment fromthe Exif
le to include the metadata in an almost-compliant way;
the JFIF standard is interpreted somewhat exibly.
[15]
Strictly speaking, the JFIF and Exif standards are in-
compatible because they each specify that their marker
segment (APP0 or APP1, respectively) appears rst. In
practice, most JPEG les 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 rst.
34 CHAPTER 5. JPEG
5.4.1 JPEG lename extensions
The most common lename extensions for les employ-
ing JPEG compression are .jpg and .jpeg, though .jpe,
.jf and .jif are also used. It is also possible for JPEG
data to be embedded in other le types TIFF encoded
les often embed a JPEG image as a thumbnail of the
main image; and MP3 les can contain a JPEG of cover
art, in the ID3v2 tag.
5.4.2 Color prole
Many JPEG les embed an ICC color prole (color
space). Commonly used color proles include sRGB and
Adobe RGB. Because these color spaces use a non-linear
transformation, the dynamic range of an 8-bit JPEG le
is about 11 stops; see gamma curve.
5.5 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 indicating the
length of marker-specic 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 ll bytes for padding purposes,
although this ll byte padding should only ever take place
for markers immediately following entropy-coded scan
data (see JPEG specication section B.1.1.2 and E.1.2
for details; specically In all cases where markers are
appended after the compressed data, optional 0xFF ll
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 stung
(see JPEG specication 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; specically the Reset markers (0xD0 through
0xD7), which are used to isolate independent chunks of
entropy-coded data to allow parallel decoding, and en-
coders are free to insert these Reset markers at regular
intervals (although not all encoders do this).
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-specic 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 unre-
liable network or le corruption. Since the runs of mac-
roblocks between restart markers may be independently
decoded, these runs may be decoded in parallel.
5.6 JPEG codec example
Although a JPEG le can be encoded in various ways,
most commonly it is done with JFIF encoding. The en-
coding process consists of several steps:
1. The representation of the colors in the image is con-
verted from RGB to YCBCR, consisting of one
luma component (Y'), representing brightness, and
two chroma components, (CB and CR), represent-
ing color. This step is sometimes skipped.
2. The resolution of the chroma data is reduced, usu-
ally by a factor of 2 or 3. This reects the fact that
the eye is less sensitive to ne color details than to
ne brightness details.
3. The image is split into blocks of 88 pixels, and for
each block, each of the Y, CB, and CR data under-
goes the Discrete Cosine Transform (DCT), which
was developed in 1974 by N. Ahmed, T. Natara-
jan and K. R. Rao; see Citation 1 in Discrete cosine
transform. A DCT is similar to a Fourier transform
in the sense that it produces a kind of spatial fre-
quency spectrum.
4. The amplitudes of the frequency components are
quantized. Human vision is much more sensitive to
small variations in color or brightness over large ar-
eas than to the strength of high-frequency brightness
5.6. JPEG CODEC EXAMPLE 35
variations. Therefore, the magnitudes of the high-
frequency components are stored with a lower accu-
racy than the low-frequency components. The qual-
ity setting of the encoder (for example 50 or 95 on
a scale of 0100 in the Independent JPEG Groups
library
[17]
) aects to what extent the resolution of
each frequency component is reduced. If an exces-
sively low quality setting is used, the high-frequency
components are discarded altogether.
5. The resulting data for all 88 blocks is further
compressed with a lossless algorithm, a variant of
Human encoding.
The decoding process reverses these steps, except the
quantization because it is irreversible. In the remainder
of this section, the encoding and decoding processes are
described in more detail.
5.6.1 Encoding
Many of the options in the JPEG standard are not com-
monly used, and as mentioned above, most image soft-
ware uses the simpler JFIF format when creating a JPEG
le, which among other things species the encoding
method. Here is a brief description of one of the more
common methods of encoding when applied to an input
that has 24 bits per pixel (eight each of red, green, and
blue). This particular option is a lossy data compression
method.
Color space transformation
First, the image should be converted from RGB into
a dierent color space called YCBCR (or, informally,
YCbCr). It has three components Y', CB and CR: the
Y' component represents the brightness of a pixel, and
the CB and CR components represent the chrominance
(split into blue and red components). This is basically
the same color space as used by digital color television as
well as digital video including video DVDs, and is simi-
lar to the way color is represented in analog PAL video
and MAC (but not by analog NTSC, which uses the YIQ
color space). The YCBCRcolor space conversion allows
greater compression without a signicant eect on per-
ceptual image quality (or greater perceptual image quality
for the same compression). The compression is more ef-
cient because the brightness information, which is more
important to the eventual perceptual quality of the image,
is conned to a single channel. This more closely corre-
sponds to the perception of color in the human visual sys-
tem. The color transformation also improves compres-
sion by statistical decorrelation.
A particular conversion to YCBCR is specied in the
JFIF standard, and should be performed for the result-
ing JPEG le to have maximum compatibility. However,
some JPEG implementations in highest quality mode
do not apply this step and instead keep the color informa-
tion in the RGB color model, where the image is stored
in separate channels for red, green and blue brightness
components. This results in less ecient compression,
and would not likely be used when le size is especially
important.
Downsampling
Due to the densities of color- and brightness-sensitive re-
ceptors in the human eye, humans can see considerably
more ne detail in the brightness of an image (the Y' com-
ponent) than in the hue and color saturation of an image
(the Cb and Cr components). Using this knowledge, en-
coders can be designed to compress images more e-
ciently.
The transformation into the YCBCR color model
enables the next usual step, which is to reduce
the spatial resolution of the Cb and Cr compo-
nents (called extquotedbldownsampling extquotedbl or
extquotedblchroma subsampling extquotedbl). The ra-
tios at which the downsampling is ordinarily done for
JPEG images are 4:4:4 (no downsampling), 4:2:2 (reduc-
tion by a factor of 2 in the horizontal direction), or (most
commonly) 4:2:0 (reduction by a factor of 2 in both the
horizontal and vertical directions). For the rest of the
compression process, Y', Cb and Cr are processed sepa-
rately and in a very similar manner.
Block splitting
After subsampling, each channel must be split into 88
blocks. Depending on chroma subsampling, this yields
(Minimum Coded Unit) MCU blocks of size 88 (4:4:4
no subsampling), 168 (4:2:2), or most commonly
1616 (4:2:0). In video compression MCUs are called
macroblocks.
If the data for a channel does not represent an integer
number of blocks then the encoder must ll the remaining
36 CHAPTER 5. JPEG
area of the incomplete blocks with some form of dummy
data. Filling the edges with a xed color (for example,
black) can create ringing artifacts along the visible part of
the border; repeating the edge pixels is a common tech-
nique that reduces (but does not necessarily completely
eliminate) such artifacts, and more sophisticated border
lling techniques can also be applied.
Discrete cosine transform
The 88 sub-image shown in 8-bit grayscale
Next, each 88 block of each component (Y, Cb, Cr)
is converted to a frequency-domain representation, us-
ing a normalized, two-dimensional type-II discrete cosine
transform (DCT), which was introduced by N. Ahmed,
T. Natarajan and K. R. Rao in 1974; see Citation 1 in
Discrete cosine transform. The DCT is sometimes re-
ferred to as type-II DCT in the context of a family of
transforms as in discrete cosine transform, and the corre-
sponding inverse (IDCT) is denoted as type-III DCT.
As an example, one such 88 8-bit subimage might be:
52 55 61 66 70 61 64 73
63 59 55 90 109 85 69 72
62 59 68 113 144 104 66 73
63 58 71 122 154 106 70 69
67 61 68 104 126 88 68 70
79 65 60 70 77 68 58 75
85 71 64 59 55 61 65 83
87 79 69 68 65 76 78 94
.
Before computing the DCT of the 88 block, its values
are shifted from a positive range to one centered around
zero. For an 8-bit image, each entry in the original block
falls in the range [0, 255] . The midpoint of the range
(in this case, the value 128) is subtracted from each entry
to produce a data range that is centered around zero, so
that the modied range is [128, 127] . This step reduces
the dynamic range requirements in the DCT processing
stage that follows. (Aside from the dierence in dynamic
range within the DCT stage, this step is mathematically
equivalent to subtracting 1024 from the DC coecient
after performing the transform which may be a better
way to perform the operation on some architectures since
it involves performing only one subtraction rather than 64
of them.)
This step results in the following values:
g =
x
76 73 67 62 58 67 64 55
65 69 73 38 19 43 59 56
66 69 60 15 16 24 62 55
65 70 57 6 26 22 58 59
61 67 60 24 2 40 60 58
49 63 68 58 51 60 70 53
43 57 64 69 73 67 63 45
41 49 59 60 63 52 50 34
y.
The next step is to take the two-dimensional DCT, which
is given by:
G
u,v
=
1
4
(u)(v)
7
x=0
7
y=0
g
x,y
cos
[
(2x + 1)u
16
]
cos
[
(2y + 1)v
16
]
where
u is the horizontal spatial frequency, for the integers
0 u < 8 .
The DCT transforms an 88 block of input values to a linear
combination of these 64 patterns. The patterns are referred to as
the two-dimensional DCT basis functions, and the output values
are referred to as transform coecients. The horizontal index is
u and the vertical index is v .
v is the vertical spatial frequency, for the integers
0 v < 8 .
(u) =
{
1
2
, if u = 0
1, otherwise
is a normalizing scale
factor to make the transformation orthonormal
g
x,y
is the pixel value at coordinates (x, y)
G
u,v
is the DCT coecient at coordinates (u, v).
If we perform this transformation on our matrix above,
we get the following (rounded to the nearest two digits
beyond the decimal point):
G =
u
415.38 30.19 61.20 27.24 56.12 20.10 2.39 0.46

4.47 21.86 60.76 10.25 13.15 7.09 8.54 4.88
46.83 7.37 77.13 24.56 28.91 9.93 5.42 5.65
48.53 12.07 34.10 14.76 10.24 6.30 1.83 1.95
12.12 6.55 13.20 3.95 1.87 1.75 2.79 3.14
7.73 2.91 2.38 5.94 2.38 0.94 4.30 1.85
1.03 0.18 0.42 2.42 0.88 3.02 4.12 0.66
0.17 0.14 1.07 4.19 1.17 0.10 0.50 1.68
v.
Note the top-left corner entry with the rather large mag-
nitude. This is the DC coecient. The remaining 63 co-
ecients are called the AC coecients. The advantage
of the DCT is its tendency to aggregate most of the sig-
nal in one corner of the result, as may be seen above. The
quantization step to follow accentuates this eect while
simultaneously reducing the overall size of the DCT co-
ecients, resulting in a signal that is easy to compress
eciently in the entropy stage.
The DCT temporarily increases the bit-depth of the data,
since the DCT coecients of an 8-bit/component im-
age take up to 11 or more bits (depending on delity
of the DCT calculation) to store. This may force the
codec to temporarily use 16-bit bins to hold these coef-
cients, doubling the size of the image representation at
this point; they are typically reduced back to 8-bit values
by the quantization step. The temporary increase in size
at this stage is not a performance concern for most JPEG
implementations, because typically only a very small part
of the image is stored in full DCT form at any given time
during the image encoding or decoding process.
Quantization
The human eye is good at seeing small dierences in
brightness over a relatively large area, but not so good
at distinguishing the exact strength of a high frequency
brightness variation. This allows one to greatly reduce
the amount of information in the high frequency compo-
nents. This is done by simply dividing each component in
the frequency domain by a constant for that component,
and then rounding to the nearest integer. This rounding
operation is the only lossy operation in the whole process
(other than chroma subsampling) if the DCT computa-
tion is performed with suciently high precision. As a
result of this, it is typically the case that many of the
higher frequency components are rounded to zero, and
many of the rest become small positive or negative num-
bers, which take many fewer bits to represent.
The elements in the quantization matrix control the com-
pression ratio, with larger values producing greater com-
pression. A typical quantization matrix (for a quality of
50% as specied in the original JPEG Standard), is as
follows:
38 CHAPTER 5. JPEG
Q =
16 11 10 16 24 40 51 61
12 12 14 19 26 58 60 55
14 13 16 24 40 57 69 56
14 17 22 29 51 87 80 62
18 22 37 56 68 109 103 77
24 35 55 64 81 104 113 92
49 64 78 87 103 121 120 101
72 92 95 98 112 100 103 99
.
The quantized DCT coecients are computed with
B
j,k
= round
(
G
j,k
Q
j,k
)
for j = 0, 1, 2, . . . , 7; k = 0, 1, 2, . . . , 7
where G is the unquantized DCT coecients; Q is the
quantization matrix above; and B is the quantized DCT
coecients.
Using this quantization matrix with the DCT coecient
matrix from above results in:
B =
26 3 6 2 2 1 0 0
0 2 4 1 1 0 0 0
3 1 5 1 1 0 0 0
3 1 2 1 0 0 0 0
1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
.
For example, using 415 (the DC coecient) and round-
ing to the nearest integer
round
(
415.37
16
)
= round (25.96) = 26.
Entropy coding
Main article: Entropy encoding
Entropy coding is a special form of lossless data com-
pression. It involves arranging the image components
in a extquotedblzigzag extquotedbl order employing run-
length encoding (RLE) algorithm that groups similar fre-
quencies together, inserting length coding zeros, and then
using Human coding on what is left.
The JPEG standard also allows, but does not require, de-
coders to support the use of arithmetic coding, which is
Zigzag ordering of JPEG image components
mathematically superior to Human coding. However,
this feature has rarely been used as it was historically cov-
ered by patents requiring royalty-bearing licenses, and
because it is slower to encode and decode compared to
Human coding. Arithmetic coding typically makes les
about 57% smaller.
The previous quantized DC coecient is used to predict
the current quantized DC coecient. The dierence be-
tween the two is encoded rather than the actual value.
The encoding of the 63 quantized AC coecients does
not use such prediction dierencing.
The zigzag sequence for the above quantized coecients
are shown below. (The format shown is just for ease of
understanding/viewing.)
If the i-th block is represented by B
i
and positions within
each block are represented by (p, q) where p = 0, 1, ..., 7
and q = 0, 1, ..., 7 , then any coecient in the DCT im-
age can be represented as B
i
(p, q) . Thus, in the above
scheme, the order of encoding pixels (for the i -th block)
is B
i
(0, 0) , B
i
(0, 1) , B
i
(1, 0) , B
i
(2, 0) , B
i
(1, 1) ,
B
i
(0, 2) , B
i
(0, 3) , B
i
(1, 2) and so on.
This encoding mode is called baseline sequential encod-
ing. Baseline JPEG also supports progressive encoding.
While sequential encoding encodes coecients of a sin-
gle block at a time (in a zigzag manner), progressive
encoding encodes similar-positioned coecients of all
blocks in one go, followed by the next positioned coe-
Baseline sequential JPEG encoding and decoding processes
cients of all blocks, and so on. So, if the image is divided
into N 88 blocks B
0
, B
1
, B
2
, ..., B
n1
, then progres-
sive encoding encodes B
i
(0, 0) for all blocks, i.e., for all
i = 0, 1, 2, ..., N 1 . This is followed by encoding
B
i
(0, 1) coecient of all blocks, followed by B
i
(1, 0) -
th coecient of all blocks, then B
i
(2, 0) -th coecient
of all blocks, and so on.
It should be noted here that once all similar-positioned
coecients have been encoded, the next position to be
encoded is the one occurring next in the zigzag traversal
as indicated in the gure above. It has been found that
Baseline Progressive JPEG encoding usually gives better
compression as compared to Baseline Sequential JPEG
due to the ability to use dierent Human tables (see be-
low) tailored for dierent frequencies on each scan or
pass (which includes similar-positioned coecients),
though the dierence is not too large.
In the rest of the article, it is assumed that the coecient
pattern generated is due to sequential mode.
In order to encode the above generated coecient pat-
tern, JPEG uses Human encoding. The JPEG standard
provides general-purpose Human tables; encoders may
also choose to generate Human tables optimized for the
actual frequency distributions in images being encoded.
The process of encoding the zig-zag quantized data be-
gins with a run-length encoding explained below, where
x is the non-zero, quantized AC coecient.
RUNLENGTH is the number of zeroes that came be-
fore this non-zero AC coecient.
SIZE is the number of bits required to represent x .
AMPLITUDE is the bit-representation of x .
The run-length encoding works by examining each non-
zero AC coecient x and determining how many zeroes
came before the previous AC coecient. With this in-
formation, two symbols are created:
Both RUNLENGTH and SIZE rest on the same byte,
meaning that each only contains 4-bits of information.
The higher bits deal with the number of zeroes, while the
lower bits denote the number of bits necessary to encode
the value of x .
This has the immediate implication of Symbol 1 being
only able store information regarding the rst 15 zeroes
preceding the non-zero AC coecient. However, JPEG
denes two special Human code words. One is for end-
ing the sequence prematurely when the remaining co-
ecients are zero (called End-of-Block or EOB),
and another when the run of zeroes goes beyond 15 be-
fore reaching a non-zero AC coecient. In such a case
where 16 zeroes are encountered before a given non-zero
AC coecient, Symbol 1 is encoded specially as: (15,
0)(0).
The overall process continues until EOB - denoted by
(0, 0) - is reached.
With this in mind, the sequence from earlier becomes:
(0, 2)(3); (1, 2)(3); (0, 2)(2); (0, 3)(6); (0, 2)(2);
(0, 3)(4); (0, 1)(1); (0, 2)(3); (0, 1)(1);
(0, 1)(1); (0, 3)(5); (0, 1)(1); (0, 2)(2); (0, 1)(1); (0,
1)(1); (0, 2)(2); (5, 1)(1); (0, 1)(1); (0, 0).
(The rst value in the matrix, 26, is the DC coecient;
it is not encoded the same way. See above.)
From here, frequency calculations are made based on oc-
currences of the coecients. In our example block, most
of the quantized coecients are small numbers that are
not preceded immediately by a zero coecient. These
more-frequent cases will be represented by shorter code
words.
5.6.2 Compression ratio and artifacts
The resulting compression ratio can be varied according
to need by being more or less aggressive in the divisors
used in the quantization phase. Ten to one compression
usually results in an image that cannot be distinguished
by eye from the original. 100 to one compression is usu-
ally possible, but will look distinctly artifacted compared
to the original. The appropriate level of compression de-
40 CHAPTER 5. JPEG
This image shows the pixels that are dierent between a non-
compressed image and the same image JPEG compressed with
a quality setting of 50. Darker means a larger dierence. Note
especially the changes occurring near sharp edges and having a
block-like shape.
pends on the use to which the image will be put.
Those who use the World Wide Web may be familiar with
the irregularities known as compression artifacts that ap-
pear in JPEG images, which may take the form of noise
around contrasting edges (especially curves and corners),
or 'blocky' images. These are due to the quantization
step of the JPEG algorithm. They are especially no-
ticeable around sharp corners between contrasting colors
(text is a good example as it contains many such corners).
The analogous artifacts in MPEG video are referred to as
mosquito noise, as the resulting edge busyness and spu-
rious dots, which change over time, resemble mosquitoes
swarming around the object.
[18][19]
These artifacts can be reduced by choosing a lower level
of compression; they may be eliminated by saving an im-
age using a lossless le format, though for photographic
images this will usually result in a larger le size. The
images created with ray-tracing programs have notice-
able blocky shapes on the terrain. Certain low-intensity
compression artifacts might be acceptable when simply
viewing the images, but can be emphasized if the image
is subsequently processed, usually resulting in unaccept-
able quality. Consider the example below, demonstrating
the eect of lossy compression on an edge detection pro-
The compressed 88-squares are visible in the scaled up picture,
together with other visual artifacts of the lossy compression.
cessing step.
Some programs allow the user to vary the amount by
which individual blocks are compressed. Stronger com-
pression is applied to areas of the image that show fewer
artifacts. This way it is possible to manually reduce JPEG
le size with less loss of quality.
JPEGartifacts, like pixelation, are occasionally intention-
ally exploited for artistic purposes, as in Jpegs, by Ger-
man photographer Thomas Ru.
[20][21]
Since the quantization stage always results in a loss of in-
formation, JPEG standard is always a lossy compression
codec. (Information is lost both in quantizing and round-
ing of the oating-point numbers.) Even if the quantiza-
tion matrix is a matrix of ones, information will still be
lost in the rounding step.
5.6.3 Decoding
Decoding to display the image consists of doing all the
above in reverse.
Taking the DCT coecient matrix (after adding the dif-
ference of the DC coecient back in)
26 3 6 2 2 1 0 0
0 2 4 1 1 0 0 0
3 1 5 1 1 0 0 0
3 1 2 1 0 0 0 0
1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
and taking the entry-for-entry product with the quantiza-

tion matrix from above results in
416 33 60 32 48 40 0 0
0 24 56 19 26 0 0 0
42 13 80 24 40 0 0 0
42 17 44 29 0 0 0 0
18 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
which closely resembles the original DCT coecient ma-

trix for the top-left portion.
The next step is to take the two-dimensional inverse DCT
(a 2D type-III DCT), which is given by:
f
x,y
=
1
4
7
u=0
7
v=0
(u)(v)F
u,v
cos
[
(2x+1)u
16
]
cos
[
(2y+1)v
16
]
where
x is the pixel row, for the integers 0 x < 8 .
y is the pixel column, for the integers 0 y < 8 .
(u) is dened as above, for the integers 0 u <
8 .
F
u,v
is the reconstructed approximate coecient at
coordinates (u, v).
f
x,y
is the reconstructed pixel value at coordinates
(x, y)
Rounding the output to integer values (since the original
had integer values) results in an image with values (still
shifted down by 128)
Notice the slight dierences between the original (top)
and decompressed image (bottom), which is most readily
seen in the bottom-left corner.
66 63 71 68 56 65 68 46
71 73 72 46 20 41 66 57
70 78 68 17 20 14 61 63
63 73 62 8 27 14 60 58
58 65 61 27 6 40 68 50
57 57 64 58 48 66 72 47
53 46 61 74 65 63 62 45
47 34 53 74 60 47 47 41
and adding 128 to each entry
62 65 57 60 72 63 60 82
57 55 56 82 108 87 62 71
58 50 60 111 148 114 67 65
65 55 66 120 155 114 68 70
70 63 67 101 122 88 60 78
71 71 64 70 80 62 56 81
75 82 67 54 63 65 66 83
81 94 75 54 68 81 81 87
.
This is the decompressed subimage. In general, the de-
compression process may produce values outside of the
original input range of [0, 255] . If this occurs, the de-
coder needs to clip the output values keep them within
42 CHAPTER 5. JPEG
that range to prevent overow when storing the decom-
pressed image with the original bit depth.
The decompressed subimage can be compared to the
original subimage (also see images to the right) by tak-
ing the dierence (original uncompressed) results in
the following error values:
10 10 4 6 2 2 4 9
6 4 1 8 1 2 7 1
4 9 8 2 4 10 1 8
2 3 5 2 1 8 2 1
3 2 1 3 4 0 8 8
8 6 4 0 3 6 2 6
10 11 3 5 8 4 1 0
6 15 6 14 3 5 3 7
with an average absolute error of about 5 values per pixels

(i.e.,
1
64
7
x=0
7
y=0
|e(x, y)| = 4.9197 ).
The error is most noticeable in the bottom-left corner
where the bottom-left pixel becomes darker than the pixel
to its immediate right.
5.6.4 Required precision
The encoding description in the JPEG standard does not
x the precision needed for the output compressed image.
However, the JPEG standard (and the similar MPEG
standards) includes some precision requirements for the
decoding, including all parts of the decoding process
(variable length decoding, inverse DCT, dequantization,
renormalization of outputs); the output from the refer-
ence algorithm must not exceed:
a maximum 1 bit of dierence for each pixel com-
ponent
low mean square error over each 88-pixel block
very low mean error over each 88-pixel block
very low mean square error over the whole image
extremely low mean error over the whole image
These assertions are tested on a large set of randomized
input images, to handle the worst cases. The former IEEE
11801990 standard contained some similar precision re-
quirements. The precision has a consequence on the im-
plementation of decoders, and it is critical because some
encoding processes (notably used for encoding sequences
of images like MPEG) need to be able to construct, on
the encoder side, a reference decoded image. In order
to support 8-bit precision per pixel component output,
dequantization and inverse DCT transforms are typically
implemented with at least 14-bit precision in optimized
decoders.
5.7 Eects of JPEG compression
JPEG compression artifacts blend well into photographs
with detailed non-uniformtextures, allowing higher com-
pression ratios. Notice how a higher compression ra-
tio rst aects the high-frequency textures in the upper-
left corner of the image, and how the contrasting lines
become more fuzzy. The very high compression ra-
tio severely aects the quality of the image, although
the overall colors and image form are still recognizable.
However, the precision of colors suer less (for a human
eye) than the precision of contours (based on luminance).
This justies the fact that images should be rst trans-
formed in a color model separating the luminance from
the chromatic information, before subsampling the chro-
matic planes (which may also use lower quality quantiza-
tion) in order to preserve the precision of the luminance
plane with more information bits.
5.7.1 Sample photographs
For information, the uncompressed 24-bit RGB bitmap
image below(73,242 pixels) would require 219,726 bytes
(excluding all other information headers). The lesizes
indicated below include the internal JPEG information
headers and some meta-data. For highest quality im-
ages (Q=100), about 8.25 bits per color pixel is required.
On grayscale images, a minimum of 6.5 bits per pixel
is enough (a comparable Q=100 quality color informa-
tion requires about 25% more encoded bits). The high-
est quality image below (Q=100) is encoded at 9 bits per
color pixel, the medium quality image (Q=25) uses 1 bit
per color pixel. For most applications, the quality fac-
tor should not go below 0.75 bit per pixel (Q=12.5), as
demonstrated by the low quality image. The image at
lowest quality uses only 0.13 bit per pixel, and displays
very poor color. This is useful when the image will be
displayed in a signicantly scaled down size.
5.9. DERIVED FORMATS FOR STEREOSCOPIC 3D 43
The medium quality photo uses only 4.3% of the storage
space required for the uncompressed image, but has lit-
tle noticeable loss of detail or visible artifacts. However,
once a certain threshold of compression is passed, com-
pressed images show increasingly visible defects. See the
article on ratedistortion theory for a mathematical ex-
planation of this threshold eect. A particular limitation
of JPEG in this regard is its non-overlapped 88 block
transform structure. More modern designs such as JPEG
2000 and JPEG XR exhibit a more graceful degradation
of quality as the bit usage decreases by using transforms
with a larger spatial extent for the lower frequency coe-
cients and by using overlapping transformbasis functions.
5.8 Lossless further compression
From 2004 to 2008, new research has emerged on ways
to further compress the data contained in JPEG images
without modifying the represented image.
[22][23][24][25]
This has applications in scenarios where the original im-
age is only available in JPEG format, and its size needs
to be reduced for archival or transmission. Standard
general-purpose compression tools cannot signicantly
compress JPEG les.
Typically, such schemes take advantage of improvements
to the naive scheme for coding DCT coecients, which
fails to take into account:
Correlations between magnitudes of adjacent coef-
cients in the same block;
Correlations between magnitudes of the same coef-
cient in adjacent blocks;
Correlations between magnitudes of the same coef-
cient/block in dierent channels;
The DC coecients when taken together resem-
ble a downscale version of the original image mul-
tiplied by a scaling factor. Well-known schemes
for lossless coding of continuous-tone images can
be applied, achieving somewhat better compression
than the Human coded DPCM used in JPEG.
Some standard but rarely used options already exist in
JPEG to improve the eciency of coding DCT coe-
cients: the arithmetic coding option, and the progressive
coding option (which produces lower bitrates because
values for each coecient are coded independently, and
each coecient has a signicantly dierent distribu-
tion). Modern methods have improved on these tech-
niques by reordering coecients to group coecients of
larger magnitude together;
[22]
using adjacent coecients
and blocks to predict new coecient values;
[24]
dividing
blocks or coecients up among a small number of in-
dependently coded models based on their statistics and
adjacent values;
[23][24]
and most recently, by decoding
blocks, predicting subsequent blocks in the spatial do-
main, and then encoding these to generate predictions for
DCT coecients.
[25]
Typically, such methods can compress existing JPEG
les between 15 and 25 percent, and for JPEGs com-
pressed at low-quality settings, can produce improve-
ments of up to 65%.
[24][25]
A freely available tool called packJPG
[26]
is based on the
2007 paper Improved Redundancy Reduction for JPEG
Files.
5.9 Derived formats for stereo-
scopic 3D
5.9.1 JPEG Stereoscopic
An example of a stereoscopic .JPS le
JPEGStereoscopic (JPS, extension .jps) is a JPEG-based
format for stereoscopic images.
[27][28]
It has a range of
congurations stored in the JPEGAPP3 marker eld, 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 le format can be viewed as a
JPEG without any special software, or can be processed
for rendering in other modes.
5.9.2 JPEG Multi-Picture Format
JPEG Multi-Picture Format (MPO, extension .mpo) is a
JPEG-based format for multi-view images. It contains
44 CHAPTER 5. JPEG
two or more JPEG les concatenated together.
[29][30]
There are also special EXIF elds describing its purpose.
This is used by the Fujilm FinePix Real 3D W1 cam-
era, Panasonic Lumix DMC-TZ20, DMC-TZ30, DMC-
TZ60& DMC-TS4 (FT4), Sony DSC-HX7V, HTC Evo
3D, the JVC GY-HMZ1U AVCHD/MVC extension
camcorder and by the Nintendo 3DS for its 3D Camera.
5.10 Patent issues
In 2002, Forgent Networks asserted that it owned and
would enforce patent rights on the JPEGtechnology, aris-
ing froma patent that had been led on October 27, 1986,
and granted on October 6, 1987 (U.S. Patent 4,698,672).
The announcement created a furor reminiscent of Unisys'
attempts to assert its rights over the GIF image compres-
sion standard.
The JPEG committee investigated the patent claims in
2002 and were of the opinion that they were invalidated
by prior art.
[31]
Others also concluded that Forgent did
not have a patent that covered JPEG.
[32]
Nevertheless,
between 2002 and 2004 Forgent was able to obtain about
US$105 million by licensing their patent to some 30 com-
panies. 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 led
a countersuit, with the goal of invalidating the patent. In
addition, Microsoft launched a separate lawsuit against
Forgent in April 2005.
[33]
In February 2006, the United
States Patent and Trademark Oce agreed to re-examine
Forgents JPEG patent at the request of the Public Patent
Foundation.
[34]
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, and did not tell the
Patent Oce, making any appeal to reinstate the patent
highly unlikely to succeed.
[35]
Forgent also possesses a similar patent granted by the Eu-
ropean Patent Oce in 1994, though it is unclear how
enforceable it is.
[36]
As of October 27, 2006, the U.S. patents 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.
[37]
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, LLCclaimed that its patent (U.S. Patent
5,253,341) issued in 1993, is infringed by the download-
ing of JPEGimages on either a website or through e-mail.
If not invalidated, this patent could apply to any website
that displays JPEG images. The patent emerged in July
2007 following a seven-year reexamination by the U.S.
Patent and Trademark Oce in which all of the origi-
nal claims of the patent were revoked, but an additional
claim (claim 17) was conrmed.
[38]
In its rst two lawsuits following the reexamination, both
led in Chicago, Illinois, Global Patent Holdings sued
the Green Bay Packers, CDW, Motorola, Apple, Orb-
itz, Ocemax, Caterpillar, Kraft and Peapod as defen-
dants. A third lawsuit was led on December 5, 2007
in South Florida against ADT Security Services, Auto-
Nation, Florida Crystals Corp., HearUSA, MovieTick-
ets.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 fth law-
suit was led against Global Patent Holdings in Nevada.
That lawsuit was led by Zappos.com, Inc., which was al-
legedly threatened by Global Patent Holdings, and seeks
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
[39]
and the anony-
mous operator of a website blog known as the Patent
Troll Tracker.
[40]
On December 21, 2007, patent lawyer
Vernon Francissen of Chicago asked the U.S. Patent and
Trademark Oce to reexamine the sole remaining claim
of the '341 patent on the basis of new prior art.
[41]
On March 5, 2008, the U.S. Patent and Trademark Oce
agreed to reexamine the '341 patent, nding that the new
prior art raised substantial new questions regarding the
patents validity.
[42]
In light of the reexamination, the ac-
cused infringers in four of the ve pending lawsuits have
led motions to suspend (stay) their cases until comple-
tion of the U.S. Patent and Trademark Oces review
of the '341 patent. On April 23, 2008, a judge presid-
ing over the two lawsuits in Chicago, Illinois granted the
motions in those cases.
[43]
On July 22, 2008, the Patent
Oce issued the rst Oce Action of the second re-
examination, nding the claim invalid based on nineteen
separate grounds.
[44]
On Nov. 24, 2009, a Reexamina-
5.12. IMPLEMENTATIONS 45
tion Certicate was issued cancelling all claims.
Beginning in 2011 and continuing as of early 2013, an
entity known as Princeton Digital Image Corporation,
[45]
based in Eastern Texas, began suing large numbers of
companies for alleged infringement of U.S. Patent No.
4,813,056 (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, re-
tailers, camera and device manufacturers and resellers.
The patent was originally owned and assigned to Gen-
eral 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 ling of a lawsuit, so Princeton could
theoretically have continued suing companies until De-
cember 2013.) As of March 2013, Princeton had suits
pending in New York and Delaware against more than 55
companies. General Electrics 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.
[46]
5.11 Standards
Main articles: Joint Photographic Experts Group
Published Standards and Joint Bi-level Image experts
Group Published Standards
Here are some examples of standards created by ISO/IEC
JTC1 SC29 Working Group 1 (WG 1), which includes
the Joint Photographic Experts Group and Joint Bi-level
Image experts Group:
JPEG (lossy and lossless): ITU-T T.81, ISO/IEC
10918-1
JPEG extensions: ITU-T T.84
JPEG-LS (lossless, improved): ITU-T T.87,
ISO/IEC 14495-1
JBIG (lossless, bi-level pictures, fax): ITU-T T.82,
ISO/IEC 11544
JBIG2 (bi-level pictures): ITU-T T.88, ISO/IEC
14492
JPEG 2000: ITU-T T.800, ISO/IEC 15444-1
JPEG 2000 extensions: ITU-T T.801
JPEG XR (formerly called HD Photo prior to stan-
dardization) : ITU-T T.832, ISO/IEC 29199-2
5.12 Implementations
A very important implementation of a JPEG codec is
the free programming library libjpeg of the Independent
JPEG Group. It was rst published in 1991 and was key
for the success of the standard.
[47]
This library or a direct
derivative of it is used in countless applications.
5.13 See also
C-Cube an early implementer of JPEG in chip form
Comparison of graphics le formats
Comparison of layout engines (graphics)
Deblocking lter (video), the similar deblocking
methods could be applied to JPEG
Design rule for Camera File system (DCF)
File extensions
Graphics editing program
Image compression
Image le formats
Lenna, the traditional standard image used to test
image processing algorithms
Lossless Image Codec FELICS
Motion JPEG
PGF
PNG
WebP
46 CHAPTER 5. JPEG
5.14 References
[1] Denition of JPEG extquotedbl extquotedbl. Collins
English Dictionary. Retrieved 23 May 2013.
[2] MIME Type Detection in Internet Explorer: Uploaded
MIME Types (msdn.microsoft.com)
[3] JPEG File Layout and Format
[4] 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) extquotedbl. Retrieved 2009-11-11.
[5] ISO/IECJTC1/SC29. Programme of Work, (Allocated
to SC 29/WG 1) extquotedbl. Retrieved 2009-11-07.
[6] ISO. JTC 1/SC 29 Coding of audio, picture, multime-
dia and hypermedia information. Retrieved 2009-11-11.
[7] JPEG. Joint Photographic Experts Group, JPEG Home-
page. Retrieved 2009-11-08.
[8] T.81 : Information technology Digital compression and
coding of continuous-tone still images Requirements
and guidelines. Retrieved 2009-11-07.
[9] William B. Pennebaker and Joan L. Mitchell (1993).
JPEG still image data compression standard (3rd ed.).
Springer. p. 291. ISBN 978-0-442-01272-4.
[10] ISO. JTC 1/SC 29 Coding of audio, picture, multime-
dia and hypermedia information. Retrieved 2009-11-07.
[11] JPEG (2009-04-24). Press Release 48th WG1 meet-
ing, Maui, USA JPEG XR enters FDIS status, JPEG
File Interchange Format (JFIF) to be standardized as
JPEG Part 5. Retrieved 2009-11-09.
[12] JPEG File Interchange Format (JFIF) extquotedbl.
ECMA TR/98 1st ed. Ecma International. 2009. Re-
trieved 2011-08-01.
[13] Progressive Decoding Overview. Microsoft Developer
Network. Microsoft. Retrieved 2012-03-23.
[14] JFIF File Format as PDF (PDF).
[15] Tom Lane (1999-03-29). JPEG image compression
FAQ. Retrieved 2007-09-11. (q. 14: Why all the argu-
ment about le formats? extquotedbl)
[16] ISO/IEC 10918-1 : 1993(E) p.36.
[17] Thomas G. Lane. Advanced Features: Compression pa-
rameter selection. Using the IJG JPEG Library.
[18] Phuc-Tue Le Dinh and Jacques Patry. Video compression
artifacts and MPEG noise reduction. Video Imaging De-
signLine. February 24, 2006. Retrieved May 28, 2009.
[19] extquotedbl3.9 mosquito noise: Form of edge busyness
distortion sometimes associated with movement, charac-
terized by moving artifacts and/or blotchy noise patterns
superimposed over the objects (resembling a mosquito
ying around a persons head and shoulders). ITU-T Rec.
P.930 (08/96) Principles of a reference impairment sys-
tem for video
[20] jpegs, Thomas Ru, Aperture, May 31, 2009, 132 pp.,
ISBN 978-1-59711-093-8
[21] Review: jpegs by Thomas Ru, by Joerg Colberg, Apr
17, 2009
[22] I. Bauermann and E. Steinbacj. Further Lossless Com-
pression of JPEG Images. Proc. of Picture Coding Sym-
posium (PCS 2004), San Francisco, USA, December 15
17, 2004.
[23] 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 Process-
ing and Analysis (ISPA 2005), Zagreb, Croatia, pp.117
120, September 1517, 2005.
[24] M. Stirner and G. Seelmann. Improved Redundancy Re-
duction for JPEG Files. Proc. of Picture Coding Sympo-
sium (PCS 2007), Lisbon, Portugal, November 79, 2007
[25] Ichiro Matsuda, Yukio Nomoto, Kei Wakabayashi and
Susumu Itoh. Lossless Re-encoding of JPEG images us-
ing block-adaptive intra prediction. Proceedings of the
16th European Signal Processing Conference (EUSIPCO
2008).
[26] Latest Binary Releases of packJPG: V2.3a. January 3,
2008.
[27] J. Siragusa, D. C. Swift, General Purpose Stereoscopic
Data Descriptor, VRex, Inc., Elmsford, New York,
USA, 1997.
[28] Tim Kemp, JPS les
[29] Multi-Picture Format (PDF). Retrieved 2011-05-29.
[30] cybereality, MPO2Stereo: Convert Fujilm MPO les to
JPEG stereo pairs, mtbs3d, retrieved 12 January 2010
[31] Concerning recent patent claims. Jpeg.org. 2002-07-
19. Retrieved 2011-05-29.
[32] JPEG and JPEG2000 Between Patent Quarrel and
Change of Technology at the Wayback Machine (archived
August 17, 2004)
[33] Kawamoto, Dawn (April 22, 2005). Graphics patent suit
res back at Microsoft. CNET News. Retrieved 2009-
01-28.
[34] Trademark Oce Re-examines Forgent JPEG Patent.
Publish.com. February 3, 2006. Retrieved 2009-01-28.
[35] USPTO: Broadest Claims Forgent Asserts Against JPEG
Standard Invalid. Groklaw.net. May 26, 2006. Re-
trieved 2007-07-21.
[36] Coding System for Reducing Redundancy.
Gauss.i.org. Retrieved 2011-05-29.
[37] JPEG Patent Claim Surrendered. Public Patent Foun-
dation. November 2, 2006. Retrieved 2006-11-03.
[38] Ex Parte Reexamination Certicate for U.S. Patent No.
5,253,341
[39] Workgroup. Rozmanith: Using Software Patents to Si-
lence Critics. Eupat.i.org. Retrieved 2011-05-29.
[40] 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.
[41] Reimer, Jeremy (2008-02-05). Hunting trolls: USPTO
asked to reexamine broad image patent. Arstech-
nica.com. Retrieved 2011-05-29.
[42] U.S. Patent Oce Granting Reexamination on
5,253,341 C1
[43] Judge Puts JPEG Patent On Ice. Techdirt.com. 2008-
04-30. Retrieved 2011-05-29.
[44] JPEG Patents Single Claim Rejected (And Smacked
Down For Good Measure) extquotedbl. Techdirt.com.
2008-08-01. Retrieved 2011-05-29.
[45] Workgroup. Princeton Digital Image Corporation Home
Page. Retrieved 2013-05-01.
[46] Workgroup. Article on Princeton Court Ruling Regard-
ing GE License Agreement. Retrieved 2013-05-01.
[47] http://jpeg.org/jpeg
5.15 External links
JPEG Standard (JPEG ISO/IEC 10918-1 ITU-T
Recommendation T.81) at W3.org
Ocial Joint Photographic Experts Group site
JFIF File Format at W3.org
JPEG viewer in 250 lines of easy to understand
python code
Wotsit.orgs entry on the JPEG format
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 le, along with a matching decompressor at
code.google.com
Example of .JPG le decoding
Jpeg Decoder Open Source Code , Copyright (C)
19951997, Thomas G. Lane.
JPEG compression and decompression on GPU.
Chapter 6
Graphics Interchange Format
GIF redirects here. For other uses, see GIF (disam-
biguation).
The Graphics Interchange Format (better known by
its acronym GIF; /df/ or /f/) is a bitmap image for-
mat that was introduced by CompuServe in 1987
[1]
and
has since come into widespread usage on the World Wide
Web due to its wide support and portability.
The format supports up to 8 bits per pixel for each im-
age, allowing a single image to reference its own palette
of up to 256 dierent colors chosen from the 24-bit RGB
color space. It also supports animations and allows a sep-
arate palette of up to 256 colors for each frame. These
palette limitations make the GIF format unsuitable for re-
producing color photographs and other images with con-
tinuous color, but it is well-suited for simpler images such
as graphics or logos with solid areas of color.
GIF images are compressed using the Lempel-Ziv-Welch
(LZW) lossless data compression technique to reduce the
le size without degrading the visual quality. This com-
pression technique was patented in 1985. Controversy
over the licensing agreement between the software patent
holder, Unisys, and CompuServe in 1994 spurred the
development of the Portable Network Graphics (PNG)
standard. All the relevant patents have now expired.
6.1 History
CompuServe introduced the GIF format in 1987 to pro-
vide a color image format for their le downloading areas,
replacing their earlier run-length encoding (RLE) format,
which was black and white only. GIF became popular
because it used LZW data compression, which was more
ecient than the run-length encoding that formats such
as PCX and MacPaint used, and fairly large images could
therefore be downloaded in a reasonably short time, even
with very slow modems.
The original version of the GIF format was called 87a.
[1]
In 1989, CompuServe released an enhanced version,
called 89a,
[2]
which added support for animation de-
lays (multiple images in a stream were already supported
in 87a), transparent background colors, and storage of
application-specic metadata. The 89a specication also
supports incorporating text labels as text (not embedding
them in the graphical data), but as there is little control
over display fonts, this feature is not widely used. The two
versions can be distinguished by looking at the rst six
bytes of the le (the extquotedblmagic number extquot-
edbl or signature), which, when interpreted as ASCII,
read GIF87a and GIF89a, respectively.
GIF was one of the rst two image formats commonly
used on Web sites, the other being the black and white
XBM.
The feature of storing multiple images in one le, accom-
panied by control data, is used extensively on the Web to
produce simple animations. The optional interlacing fea-
ture, which stores image scan lines out of order in such a
fashion that even a partially downloaded image was some-
what recognizable, also helped GIFs popularity, as a user
could abort the download if it was not what was required.
In 2012, the word GIF was ocially recognized as a
verb as well as a noun, meaning to create a GIF le. The
United States wing of the Oxford University Press voted
it their word of the year, saying that GIFs have evolved
into a tool with serious applications including research
and journalism.
[3][4]
48
6.3. USAGE 49
6.2 Pronunciation
A humorous image announcing the launch of a White House
Tumblr suggests pronouncing GIF with a hard G.
The creators of the format pronounced GIF as Jif
with a soft extquotedblG extquotedbl /df/ as in gin.
Steve Wilhite says that the intended pronunciation de-
liberately echoes the American peanut butter brand, Jif,
and CompuServe employees would often say Choosy
developers choose GIF, spoong this brands television
commercials.
[5]
An alternative pronunciation with a hard G (/f/ as
in graphics) is in widespread usage.
[6]
The American
Heritage Dictionary
[7]
cites both, acknowledging jif as
the primary pronunciation, while the Cambridge Dictio-
nary of American English
[8]
oers only the gif pronun-
ciation. Merriam-Websters Collegiate Dictionary
[9]
cites
both pronunciations, but places gif in the default posi-
tion ( extquotedbl\gif, jif\ extquotedbl).
The disagreement over the pronunciation has led to
heated Internet debate. On the occasion of re-
ceiving a lifetime achievement award at the 2013
Webby Award ceremony, Wilhite rejected the alternative
pronunciation,
[6][10][11]
and his speech led to 17,000 posts
on Twitter and 50 news articles.
[12]
The White House
[6]
and TV program Jeopardy!
[11]
also waded into the debate
during 2013.
6.3 Usage
GIFs are suitable for sharp-edged line art (such as lo-
gos) with a limited number of colors. This takes ad-
vantage of the formats lossless compression, which
favors at areas of uniform color with well dened
edges.
GIFs can be used to store low-color sprite data for
games.
GIFs can be used for small animations and low-
resolution lm clips.
Since a single GIF image palette is limited to 256
colors, it is not usually used as a format for digital
photography. Digital photographers use image le
formats capable of reproducing a greater range of
colors, such as TIFF, RAW or JPEG.
6.4 File format
File:Empty.gif in a hex editor
Conceptually, a GIF le describes a xed-sized graphical
area (the logical screen) populated with zero or more
images. Many GIF les have a single image that lls
the entire logical screen. Others divide the logical screen
into separate sub-images. The images may also function
as animation frames in an animated GIF le, but again
these need not ll the entire logical screen.
GIF les start with a xed-length header (GIF87a or
GIF89a) giving the version, followed by a xed-length
50 CHAPTER 6. GRAPHICS INTERCHANGE FORMAT
Logical Screen Descriptor giving the size and other char-
acteristics of the logical screen. The screen descriptor
may also specify the presence and size of a Global Color
Table, which follows next if present.
Thereafter, the le is divided into segments, each intro-
duced by a 1-byte sentinel:
An image (introduced by 0x2C, a comma ',')
An extension block (introduced by 0x21, an excla-
mation point '!')
The trailer (a single byte of value 0x3B, a semi-
colon ';'), which should be the last byte of the le.
An image starts with a xed-length Image Descriptor,
which may specify the presence and size of a Local Color
Table (which follows next if present). The image data fol-
lows: one byte giving the bit width of the unencoded sym-
bols (which must be at least 2 bits wide, even for bi-color
images), followed by a linked list of sub-blocks contain-
ing the LZW-encoded data.
Extension blocks (blocks that extend the 87a deni-
tion via a mechanism already dened in the 87a spec)
consist of the sentinel, an additional byte specifying the
type of extension, and a linked list of sub-blocks with
the extension data. Extension blocks that modify an im-
age (like the Graphic Control Extension that species the
optional animation delay time and optional transparent
background color) must immediately precede the seg-
ment with the image they refer to.
The linked lists used by the image data and the exten-
sion blocks consist of series of sub-blocks, each sub-block
beginning with a byte giving the number of subsequent
data bytes in the sub-block (1 to 255). The series of sub-
blocks is terminated by an empty sub-block (a 0 byte).
This structure allows the le to be parsed even if not all
parts are understood. A GIF marked 87a may contain
extension blocks; the intent is that a decoder can read and
display the le without the features covered in extensions
it does not understand.
The full detail of the le format is covered in the GIF
specication.
[2]
An example of a GIF image saved with a 'web-safe' palette and
dithered using the FloydSteinberg method. Due to the reduced
number of colors in the image, there are obvious display issues.
6.5 Palettes
GIF is palette-based: the colors used in an image (a
frame) in the le have their RGB values dened in a
palette table that can hold up to 256 entries, and the data
for the image refer to the colors by their indices (0255)
in the palette table. The color denitions in the palette
can be drawn from a color space of millions of shades
(2
24
shades, 8 bits for each primary), but the maximum
number of colors a frame can use is 256. This limitation
seemed reasonable when GIF was developed because few
people could aord the hardware to display more col-
ors simultaneously. Simple graphics, line drawings, car-
toons, and grey-scale photographs typically need fewer
than 256 colors.
As a further renement, each frame can designate one in-
dex as a transparent background color extquotedbl: any
pixel assigned this index takes on the color of the pixel in
the same position from the background, which may have
been determined by a previous frame of animation.
Many techniques, collectively called dithering, have been
developed to approximate a wider range of colors with a
6.6. EXAMPLE GIF FILE 51
small color palette by using pixels of two or more colors
to approximate in-between colors. These techniques sac-
rice spatial resolution to approximate deeper color reso-
lution. While not part of the GIF specication, dithering
can of course be used in images subsequently encoded as
GIF images. This is often not an ideal solution for GIF
images, both because the loss of spatial resolution typi-
cally makes an image look fuzzy on the screen, and be-
cause the dithering patterns often interfere with the com-
pressibility of the image data, working against GIFs main
purpose.
In the early days of graphical web browsers, graphics
cards with 8-bit buers (allowing only 256 colors) were
common and it was fairly common to make GIF images
using the websafe palette. This ensured predictable dis-
play, but severely limited the choice of colors. Now that
32-bit graphics cards, which support 24-bit color, are the
norm, palettes can be populated with the optimum colors
for individual images.
A small color table may suce for small images, and
keeping the color table small allows the le to be down-
loaded faster. Both the 87a and 89a specications allow
color tables of 2
n
colors for any n from 1 through 8. Most
graphics applications will read and display GIF images
with any of these table sizes; but some do not support
all sizes when creating images. Tables of 2, 16, and 256
colors are widely supported.
6.5.1 True color
Although the GIF format is almost never used for True
Color images, it is possible to do so.
[13][14]
A GIF im-
age can include multiple image blocks, each of which can
have its own 256-color palette, and the blocks can be tiled
to create a complete image. Alternatively, the GIF89a
specication introduced the idea of a transparent color
where each image block can include its own palette of
255 visible colors plus one transparent color. A complete
image can be created by layering image blocks with the
visible portion of each layer showing through the trans-
parent portions of the layers above.
To render a full-color image as a GIF, the original image
must be broken down into smaller regions having no more
than 255 or 256 dierent colors. Each of these regions is
then stored as a separate image block with its own local
palette and when the image blocks are displayed together
(either by tiling or by layering partially transparent im-
age blocks) the complete, full-color image appears. For
An animated GIF illustrating a technique for displaying more
than the typical limit of 256 colors
example, breaking an image into tiles of 16 by 16 pixels
(256 pixels in total) ensures that no tile has more than the
local palette limit of 256 colors, although larger tiles may
be used and similar colors merged resulting in some loss
of color information.
[13]
Since each image block requires its own local color ta-
ble, a GIF le having lots of image blocks can be very
large, limiting the usefulness of full-color GIFs.
[14]
Ad-
ditionally, not all GIF rendering programs handle tiled
or layered images correctly. Many rendering programs
interpret tiles or layers as animation frames and display
them in sequence as an endless animation
[13]
with most
web browsers automatically displaying the frames with a
delay time of 0.1 seconds or more.
[15][16]
6.6 Example GIF le
Microsofts Paint program saves a small black and white
image as the following GIF le. Paint does not make
optimal use of the GIF format; due to the unnecessarily
large color table (storing a full 256 colors instead of the
used 2) and symbol width, this GIF le is not an ecient
representation of the 15-pixel image (illustrated enlarged
above).
Although the Graphics Control Extension block declares
Sample image (enlarged), actual size 3 pixels wide by 5 high
color index 16 (hexadecimal 10) to be transparent, that
index is not used in the image. The only color indexes ap-
pearing in the image data are decimal 40 and 255, which
the Global Color Table maps to black and white, respec-
tively.
Note that the hex numbers in the following tables are in
little-endian byte order, as the format specication pre-
scribes.
byte# hexadecimal text or (hex) value Meaning 0: 47 49
46 38 39 61 GIF89a Header Logical Screen Descriptor
6: 03 00 3 - logical screen width in pixels 8: 05 00 5 -
logical screen height in pixels A: F7 - GCT follows for
256 colors with resolution 3 x 8 bits/primary B: 00 0 -
background color #0 C: 00 - default pixel aspect ratio R
G B Global Color Table D: 00 00 00 0 0 0 - color #0
black 10: 80 00 00 128 0 0 - color #1 : : 85: 00 00 00 0
0 0 - color #40 black : : 30A: FF FF FF 255 255 255 -
Bytes Dh to 30Ch in the example dene a palette of 256 colors.
color #255 white 30D: 21 F9 Graphic Control Extension
30F: 04 4 - 4 bytes of GCE data follow 310: 01 - there
is a transparent background color 311: 00 00 - delay for
animation: not used 313: 10 16 - color #16 is transparent
314: 00 - end of GCE block 315: 2C Image Descriptor
316: 00 00 00 00 (0,0) - NW corner position of image in
logical screen 31A: 03 00 05 00 (3,5) - image width and
height in pixels 31E: 00 - no local color table 31F: 08 8
Start of image - LZW minimum code size 320: 0B 11 -
11 bytes of LZW encoded image data follow 321: 00 51
FC 1B 28 70 A0 C1 83 01 01 32C: 00 - end of image
data 32D: 3B GIF le terminator
6.6.1 Image coding
The image pixel data, scanned horizontally from top left,
are converted by LZW encoding to codes that are then
mapped into bytes for storing in the le. The pixel codes
typically don't match the 8-bit size of the bytes, so the
codes are packed into bytes by a little-Endian scheme:
the least signicant bit of the rst code is stored in the
least signicant bit of the rst byte, higher order bits of
the code into higher order bits of the byte, spilling over
into the loworder bits of the next byte as necessary. Each
subsequent code is stored starting at the least signicant
bit not already used.
This byte stream is stored in the le as a series of sub-
6.6. EXAMPLE GIF FILE 53
blocks. Each sub-block has a maximum length 255
bytes and is prexed with a byte indicating the number
of data bytes in the sub-block. The series of sub-blocks
is terminated by an empty sub-block (a single 0 byte, in-
dicating a sub-block with 0 data bytes).
For the sample image above the reversible mapping be-
tween 9-bit codes and bytes is shown below.
A slight compression is evident: pixel colors dened ini-
tially by 15 bytes are exactly represented by 12 code bytes
including control codes. The encoding process that pro-
duces the 9-bit codes is shown below. A local string ac-
cumulates pixel color numbers from the palette, with no
output action as long as the local string can be found in a
code table. There is special treatment of the rst two pix-
els that arrive before the table grows from its initial size
by additions of strings. After each output code, the local
string is initialized to the latest pixel color (that could not
be included in the output code).
Table 9-bit string --> code code Action #0 | 000h Initial-
ize root table of 9-bit codes palette | : colors | : #255
| 0FFh clr | 100h end | 101h | 100h Clear Pixel Local |
color Palette string | BLACK #40 28 | 028h 1st pixel al-
ways to output WHITE #255 FF | String found in table
28 FF | 102h Always add 1st string to table FF | Initial-
ize local string WHITE #255 FF FF | String not found
in table | 0FFh - output code for previous string FF FF |
103h - add latest string to table FF | - initialize local string
WHITE #255 FF FF | String found in table BLACK #40
FF FF 28 | String not found in table | 103h - output code
for previous string FF FF 28 | 104h - add latest string to
table 28 | - initialize local string WHITE #255 28 FF |
String found in table WHITE #255 28 FF FF | String not
found in table | 102h - output code for previous string 28
FF FF | 105h - add latest string to table FF | - initialize
local string WHITE #255 FF FF | String found in table
WHITE #255 FF FF FF | String not found in table | 103h
- output code for previous string FF FF FF | 106h - add
latest string to table FF | - initialize local string WHITE
#255 FF FF | String found in table WHITE #255 FF FF
FF | String found in table WHITE #255 FF FF FF FF |
String not found in table | 106h - output code for previ-
ous string FF FF FF FF| 107h - add latest string to table
FF | - initialize local string WHITE #255 FF FF | String
found in table WHITE #255 FF FF FF | String found in
table WHITE #255 FF FF FF FF | String found in table
No more pixels 107h - output code for last string 101h
End
For clarity the table is shown above as being built of
strings of increasing length. That scheme can function
but the table consumes an unpredictable amount of mem-
ory. Memory can be saved in practice by noting that each
new string to be stored consists of a previously stored
string augmented by one character. It is economical to
store at each address only two words: an existing address
and one character.
The LZW algorithm requires a search of the table for
each pixel. A linear search through up to 4096 addresses
would make the coding slow. In practice the codes can
be stored in order of numerical value; this allows each
search to be done by a SAR (Successive Approximation
Register, as used in some ADCs), with only 12 magnitude
comparisons. For this eciency an extra table is needed
to convert between codes and actual memory addresses;
the extra table upkeeping is needed only when a newcode
is stored which happens at much less than pixel rate.
6.6.2 Image decoding
Decoding begins by mapping the stored bytes back to 9-
bit codes. These are decoded to recover the pixel colors
as shown below. A table identical to the one used in the
encoder is built by adding strings by this rule:
Is incoming code found in table? YES: add string for
local code followed by rst byte of string for incoming
code NO: add string for local code followed by copy of
its own rst byte shift 9-bit ----> Local Table Pixel code
code code --> string Palette color Action 100h 000h | #0
Initialize root table of 9-bit codes : | palette : | colors
0FFh | #255 100h | clr 101h | end 028h | #40 BLACK
Decode 1st pixel 0FFh 028h | Incoming code found in
table | #255 WHITE - output string from table 102h | 28
FF - add to table 103h 0FFh | Incoming code not found
in table 103h | FF FF - add to table | - output string from
table | #255 WHITE | #255 WHITE 102h 103h | Incom-
ing code found in table | - output string from table | #40
BLACK | #255 WHITE 104h | FF FF 28 - add to table
103h 102h | Incoming code found in table | - output string
from table | #255 WHITE | #255 WHITE 105h | 28 FF
FF - add to table 106h 103h | Incoming code not found
in table 106h | FF FF FF - add to table | - output string
from table | #255 WHITE | #255 WHITE | #255 WHITE
107h 106h | Incoming code not found in table 107h | FF
FF FF FF - add to table | - output string from table | #255
WHITE | #255 WHITE | #255 WHITE | #255 WHITE
101h | End
6.6.3 LZW code lengths
Shorter code lengths can be used for palettes smaller than
the 256 colors in the example. If the palette is only 64
colors (so color indexes are 6 bits wide), the symbols can
range from 0 to 63, and the symbol width can be taken
to be 6 bits, with codes starting at 7 bits. In fact, the
symbol width need not match the palette size: as long as
the values decoded are always less than the number of
colors in the palette, the symbols can be any width from
2 to 8, and the palette size any power of 2 from 2 to 256.
For example, if only the rst four colors (values 0 to 3)
of the palette are used, the symbols can taken to be 2 bits
wide with codes starting at 3 bits.
Conversely, the symbol width could be set at 8, even if
only values 0 and 1 are used; these data would only re-
quire a 2-color table. Although there would be no point
in encoding the le that way, something similar typically
happens for bi-color images: the minimum symbol width
is 2, even if only values 0 and 1 are used.
The code table initially contains codes that are one bit
longer than the symbol size in order to accommodate the
two special codes clr and end and codes for strings that
are added during the process. When the table is full the
code length increases to give space for more strings, up
to a maximum code 4095 = FFF(hex). As the decoder
builds its table it tracks these increases in code length and
it is able to unpack incoming bytes accordingly.
6.6.4 Uncompressed GIF
The GIF encoding process can be modied to create a
le without LZW compression that is still viewable as a
GIF image. This technique was introduced originally as
a way to avoid patent infringement. Uncompressed GIF
can also be a useful intermediate format for a graphics
programmer because individual pixels are accessible for
reading or painting. An uncompressed GIF le can be
converted to an ordinary GIF le simply by passing it
through an image editor.
The modied encoding method ignores building the
LZW table and emits only the root palette codes and
the codes for CLEAR and STOP. This yields a simpler
encoding (a 1-to-1 correspondence between code values
and palette codes) but sacrices all of the compression:
each pixel in the image generates an output code indicat-
ing its color index. When processing an uncompressed
GIF, a standard GIF decoder will not be prevented from
A 46 x 46 uncompressed GIF with 7-bit symbols (128 colors, 8-
bit codes). Click on the image for an explanation of the code.
writing strings to its dictionary table, but the code width
must never increase since that triggers a dierent packing
of bits to bytes.
If the symbol width is n, the codes of width n+1 fall nat-
urally into two blocks: the lower block of 2
n
codes for
coding single symbols, and the upper block of 2
n
codes
that will be used by the decoder for sequences of length
greater than one. Of that upper block, the rst two codes
are already taken: 2
n
for CLEAR and 2
n
+ 1 for STOP.
The decoder must also be prevented from using the last
code in the upper block, 2
n+1
1, because when the de-
coder lls that slot, it will increase the code width. Thus
in the upper block there are 2
n
3 codes available to the
decoder that won't trigger an increase in code width. Be-
cause the decoder is always one step behind in maintain-
ing the table, it does not generate a table entry upon re-
ceiving the rst code from the encoder, but will generate
one for each succeeding code. Thus the encoder can gen-
erate 2
n
2 codes without triggering an increase in code
width. Therefore the encoder must emit extra CLEAR
codes at intervals of 2
n
2 codes or less to make the
decoder reset the coding dictionary. The GIF standard
allows such extra CLEAR codes to be inserted in the im-
age data at any time. The composite data stream is parti-
tioned into sub-blocks that each carry from1 to 255 bytes.
For the sample 3x5 image above, the following 9-bit
codes represent clear (100) followed by image pixels
6.8. INTERLACING 55
in scan order and stop (101).
9-bit codes: 100 028 0FF 0FF 0FF 028 0FF 0FF 0FF
0FF 0FF 0FF 0FF 0FF 0FF 0FF 101
After the above codes are mapped to bytes, the uncom-
pressed le diers from the compressed le thus:
: 320: 14 20 20 bytes uncompressed image data follow
321: 00 51 FC FB F7 0F C5 BF 7F FF FE FD FB F7 EF
DF BF 7F 01 01 335: 00 - end :
6.7 Compression example
The trivial example of a large image of solid color demon-
strates the variable-length LZWcompression used in GIF
les.
------------------------+-------------------------+--------
------------------------------------- CODE | PIXELS |
NOTES ------------------------+-------------------------
+--------------------------------------------- no. | value
| length | this code | accumulated | Relations using
N apply only to same- N | N+256| (bits) | N |
N(N+1)/2 |<-- color pixels until coding table is full.
________________________________________________________________________________________________
0: | 100h | 9 | | | Clear code table -------+-------+ +--------
---+-------------+-------------------------- 1: | FFh | | 1 | 1 |
Top left pixel color chosen as the | | | | | highest index of a
256-color palette -------+-------+ +-----------+-------------
+-------------------------- 2: | 102h | | 2 | 3 | -------+-------+
+-----------+-------------+-------------------------- 3: | 103h
| | 3 | 6 | : : | | : : | 255: | 1FFh | | 255 | 32 640 | Last
9-bit code -------+-------+--------+-----------+-------------
+-------------------------- 256: | 200h | 10 | 256 | 32 896
| : : | | : : | 767: | 3FFh | | 767 | 294 528 | Last 10-bit
code -------+-------+--------+-----------+-------------+----
---------------------- 768: | 400h | 11 | 768 | 295 296 | : :
| | : | : | 1791: | 7FFh | | 1791 | 1 604 736 | Last 11-bit
code -------+-------+--------+-----------+-------------+-----
--------------------- 1792: | 800h | 12 | 1792 | 1 606 528
| : : | | : | : | 3839: | FFFh | | 3839 | 7 370 880 | Code
table full -------+-------+ +-----------+-------------+-------
------------------- : | FFFh | | 3839 | The maximum code
may repeat for more same-color pixels. : | | | | Overall
data compression asymptotically approaches : | | | | 3839
x 8 / 12 = 2559-1/3 -------+-------+ +-----------+--------
-----+-------------------------- | 101h | | | | End of image data
_____________________________________________________________________________
The code values shown are packed into bytes which are
then packed into blocks of up to 255 bytes. A block of
image data begins with a byte that declares the number
of bytes to follow. The last block of data for an image is
marked by a zero block-length byte.
6.8 Interlacing
The GIF Specication allows each image within the logi-
cal screen of a GIF le to specify that it is interlaced; i.e.,
that the order of the raster lines in its data block is not
sequential. This allows a partial display of the image that
can be recognized before the full image is painted.
An interlaced image is divided from top to bottom into
strips 8 pixels high, and the rows of the image are pre-
sented in the following order:
Pass 1: Line 0 (the top-most line) from each strip.
Pass 2: Line 4 from each strip.
Pass 3: Lines 2 and 6 from each strip.
Pass 4: Lines 1, 3, 5, and 7 from each strip.
The pixels within each line are not interlaced, but pre-
sented consecutively from left to right. As with non-
interlaced images, there is no break between the data for
one line and the data for the next. The indicator that an
image is interlaced is a bit set in the images header block.
6.9 Animated GIF
Basic animation was added to the GIF89a spec via the
Graphics Control Extension (GCE), which allows various
images (frames) in the le to be painted with time delays.
An animated GIF le comprises a number of frames that
are displayed in succession, each introduced by its own
GCE, which gives the time delay to wait after the frame
is drawn. Global information at the start of the le applies
by default to all frames. The data is stream-oriented, so
the le-oset of the start of each GCE depends on the
length of preceding data. Within each frame the LZW-
coded image data is arranged in sub-blocks of up to 255
bytes; the size of each sub-block is declared by the byte
that precedes it.
By default, however, an animation displays the sequence
of frames only once, stopping when the last frame is
The GIFformat can be used to display animation, as in this image
of Newtons Cradle.
displayed. Since GIF is designed to allow users to de-
ne new blocks, Netscape in the 1990s used the Ap-
plication Extension block (intended to allow vendors to
add application-specic information to the GIF le) to
implement the Netscape Application Block (NAB).
[17]
This block, placed immediately before all the animation
frames, species the number of times the sequence of
frames should be played. (The value 0 signies continu-
ous display.) Support for these repeating animations rst
appeared in Netscape Navigator version 2.0, and then
spread to other browsers.
[18]
Most browsers now recog-
nize and support NAB, though it is not strictly part of the
GIF89a specication.
The following example shows the structure of the
animation le Rotating earth (large).gif shown (as a
thumbnail) at the top of the article.
byte# hexadecimal text or (hex) value Meaning 0: 47 49
46 38 39 61 GIF89a Header Logical Screen Descriptor
6: 90 01 400 - width in pixels 8: 90 01 400 - height in
pixels A: F7 - GCT follows for 256 colors with resolu-
tion 3 x 8bits/primary B: 00 0 - background color #0 C:
00 - default pixel aspect ratio D: Global Color Table :
30D: 21 FF Application Extension block 30F: 0B 11 -
eleven bytes of data follow 310: 4E 45 54 53 43 41 50
45 NETSCAPE - 8-character application name 32 2E 30
2.0 - application authentication code 31B: 03 3 - three
more bytes of data 31C: 01 1 - data sub-block index (al-
ways 1) 31D: FF FF 65535 - unsigned number of repeti-
tions 31F: 00 - end of App Extension block 320: 21 F9
Graphic Control Extension for frame #1 322: 04 4 - four
bytes of data follow323: 08 - no transparency 324: 09 00
- 0.09 sec delay before painting next frame 326: 00 - no
transparent color 327: 00 - end of GCE block 328: 2C
Image Descriptor 329: 00 00 00 00 (0,0) - NW corner of
frame at 0, 0 32D: 90 01 90 01 (400,400) - Frame width
and height: 400 x 400 331: 00 - no local color table; no
interlace 332: 08 8 LZW min code size 333: FF 255 -
255 bytes of LZW encoded image data follow 334: data
433: FF 255 - 255 bytes of LZW encoded image data
follow data : 92BA: 00 - end of LZW data for this frame
92BB: 21 F9 Graphic Control Extension for frame #2 : :
153B7B:21 F9 Graphic Control Extension for frame #44
: 15CF35:3B File terminator
The animation delay for each frame is specied in the
GCE in hundredths of a second. Some economy of data
is possible where a frame need only rewrite a portion of
the pixels of the display, because the Image Descriptor
can dene a smaller rectangle to be rescanned instead of
the whole image. Displays that do not support animated
GIFs show only the rst frame.
Internet Explorer slows down GIFs if the frame-rate is
20 frames per second or higher and Microsoft reports
that Google Chrome and Safari also slowdown some GIF
animations.
[19]
6.10 Unisys and LZW patent en-
forcement
In 1977 and 1978, Jacob Ziv and Abraham Lempel pub-
lished a pair of papers on a new class of lossless data-
compression algorithms, now collectively referred to as
LZ77 and LZ78. In 1983, Terry Welch developed a fast
variant of LZ78 which was named LempelZivWelch
(LZW).
[20][21]
Welch led a patent application for the LZW method in
June 1983. The resulting patent, US 4558302, granted
in December 1985, was assigned to Sperry Corporation
who subsequently merged with Burroughs Corporation
in 1986 and formed Unisys.
[20]
Further patents were ob-
tained in the United Kingdom, France, Germany, Italy,
Japan and Canada.
In June 1984, an article by Welch was published in the
IEEE magazine which publicly described the LZW tech-
nique for the rst time.
[22]
LZW became a popular data
compression technique and, when the patent was granted,
Unisys entered into licensing agreements with over a hun-
6.11. ALTERNATIVES 57
dred companies.
[20][23]
The popularity of LZW led CompuServe to choose it as
the compression technique for their GIF format, devel-
oped in 1987. At the time, CompuServe was not aware
of the patent.
[20]
Unisys became aware that the GIF for-
mat used the LZW compression technique and entered
into licensing negotiations with CompuServe in January
1993. The subsequent agreement was announced on 24
December 1994.
[21]
Unisys stated that they expected all
major commercial on-line information services compa-
nies employing the LZW patent to license the technology
from Unisys at a reasonable rate, but that they would not
require licensing, or fees to be paid, for non-commercial,
non-prot GIF-based applications, including those for
use on the on-line services.
[23]
Following this announcement, there was widespread con-
demnation of CompuServe and Unisys, and many soft-
ware developers threatened to stop using the GIF format.
The PNGformat (see below) was developed in 1995 as an
intended replacement.
[20][21][22]
However, obtaining sup-
port from the makers of Web browsers and other soft-
ware for the PNG format proved dicult and it was not
possible to replace the GIF format, although PNG has
gradually increased in popularity.
[20]
The libungif library,
based on Eric S. Raymond's giib, allows creation of
GIFs that followed the data format but avoided the com-
pression features, thus avoiding use of the Unisys LZW
patent.
[24]
In August 1999, Unisys changed the details of their li-
censing practice, announcing the option for owners of
certain non-commercial and private websites to obtain li-
censes on payment of a one-time license fee of $5000
or $7500.
[25]
Such licenses were not required for website
owners or other GIF users who had used licensed soft-
ware to generate GIFs. Nevertheless, Unisys was sub-
jected to thousands of online attacks and abusive emails
from users believing that they were going to be charged
$5000 or sued for using GIFs on their websites.
[26]
De-
spite giving free licenses to hundreds of non-prot organi-
zations, schools and governments, Unisys was completely
unable to generate any good publicity and continued to be
condemned by individuals and organizations such as the
League for Programming Freedomwho started the Burn
All GIFs campaign.
[27]
The United States LZW patent expired on 20 June
2003.
[28]
The counterpart patents in the United Kingdom,
France, Germany and Italy expired on 18 June 2004, the
Japanese counterpart patents expired on 20 June 2004
and the counterpart Canadian patent expired on 7 July
2004.
[28]
Consequently, while Unisys has further patents
and patent applications relating to improvements to the
LZW technique,
[28]
the GIF format may now be used
freely.
[29]
6.11 Alternatives
6.11.1 PNG
Portable Network Graphics (PNG) was designed as a
replacement for the GIF format in order to avoid in-
fringement of Unisys patent on the LZW compression
technique.
[20]
PNG oers better compression and more
features than GIF,
[30]
animation being the only signi-
cant exception. PNG is more suitable than GIF in in-
stances where true-color imaging and alpha transparency
are required.
Although support for PNG format came slowly, new
web browsers generally support PNG. Older versions of
Internet Explorer do not support all features of PNG.
Versions 6 and earlier do not support alpha channel
transparency without using Microsoft-specic HTML
extensions.
[31]
Gamma correction of PNG images was
not supported before version 8, and the display of these
images in earlier versions may have the wrong tint.
[32]
PNG les can be much larger than GIF les in situations
where a GIF and a PNG le were created from the same
high-quality image source, as PNG is capable of stor-
ing more color depth and transparency information than
GIF. However, for identical 8-bit (or lower) image data,
PNG les are typically smaller than the equivalent GIFs,
due to the more ecient compression techniques used in
PNG encoding.
[33]
Complete support for the GIF format
is complicated chiey by the complex canvas structure it
allows, though this is what enables the compact animation
features.
6.11.2 Animation formats
MNG was originally developed as a PNG-based solution
for animations. MNG reached version 1.0 in 2001, but
few applications support it.
In 2006, an extension to the PNG format called APNG
was proposed as alternative to the MNG format by
Mozilla. APNG provide the ability to animate PNG les,
while retaining backwards compatibility in decoders that
cannot understand the animation chunk (unlike MNG).
Older decoders will simply render the rst frame of the
animation. The PNG group ocially rejected APNG
as an ocial extension on April 20, 2007.
[34]
There
have been several subsequent proposals for a simple ani-
mated graphics format based on PNG using several dif-
ferent approaches.
[35]
Nevertheless, Animated Portable
Network Graphics is still under development by Mozilla
and is supported in Firefox 3
[36][37]
while MNG support
was dropped.
[38][39]
Embedded Adobe Flash objects and MPEGs are used
on some websites to display simple video, but require
the use of an additional browser plugin. WebM and
WebP are in development and are supported by some
web browsers.
[40]
Other options for web animation in-
clude serving individual frames using AJAX, or animat-
ing SVG images using JavaScript or SMIL.
6.12 See also
Comparison of layout engines (graphics)
GNU plotutils (supports pseudo-gif format which
uses run-length encoding rather than LZW)
Software patent
Microsoft GIF Animator, a free program to create
simple animated GIFs
6.13 References
[1] Graphics Interchange Format, Version 87a. W3C. 15
June 1987. Retrieved 13 October 2012.
[2] Graphics Interchange Format, Version 89a. W3C. 31
July 1990. Retrieved 6 March 2009.
[3] Flood, Alison (2013-04-27). Gif is Americas word of
the year? Now thats what I call an omnishambles | Ali-
son Flood | Books | guardian.co.uk. London: Guardian.
[4] Oxford Dictionaries USA Word of the Year 2012 | Ox-
fordWords blog. Blog.oxforddictionaries.com. 2012-
11-13. Retrieved 2013-05-01.
[5] Olsen, Steve. The GIF Pronunciation Page. Retrieved
6 March 2009.
[6] Gifs inventor says ignore dictionaries and say 'Jif' ex-
tquotedbl. BBC News. 2013-05-22. Retrieved 2013-05-
22.
[7] GIF. The American Heritage Abbreviations Dictionary,
Third Edition. Houghton Miin Company. 2005. Re-
trieved 2007-04-15.
[8] GIF. The Cambridge Dictionary of American English.
Cambridge University Press. Retrieved 2014-02-19.
[9] Gif - Denition from the Merriam-Webster Dictionary.
Merriam-Webster Dictionary. Merriam-Webster, Incor-
porated. Retrieved 6 June 2013.
[10] O'Leary, Amy (21 May 2013). An Honor for the Creator
of the GIF. New York Times. Retrieved 22 May 2013.
[11] Rothberg, Daniel (4 December 2013).
extquotedbl'Jeopardy' wades into 'GIF' pronuncia-
tion battle. Los Angeles Times (Los Angeles Times).
[12] O'Leary, Amy (23 May 2013). Battle Over GIF' Pro-
nunciation Erupts. The New York Times.
[13] Andreas Kleinert (2007). GIF 24 Bit (truecolor) exten-
sions. Retrieved 23 March 2012.
[14] Philip Howard. True-Color GIF Example. Retrieved
23 March 2012.
[15] Animated GIF Minimum Frame Delay Browser Compat-
ibility Study
[16] They're dierent! How to match the animation rate of
gif les accross [sic] browsers. Developers Blog. 14 Feb
2012. Retrieved 23 May 2014.
[17] Royal Frazier. All About GIF89a. Retrieved 7 January
2013.
[18] Scott Walter (1996). Web Scripting Secret Weapons. Que
Publishing. ISBN 0-7897-0947-3.
[19] Animated GIFs slow down to under 20 frames per second
[20] Greg Roelofs. History of the Portable Network Graphics
(PNG) Format. Retrieved 23 March 2012.
[21] Stuart Caie. Sad day... GIFpatent dead at 20. Retrieved
23 March 2012.
[22] The GIF Controversy: A Software Developers Perspec-
tive
[23] Unisys Claries Policy Regarding Patent Use in On-Line
Service Oerings archived by League for Programming
Freedom
[24] FSF.org
[25] LZW Software and Patent Information at the Wayback
Machine (archived 8 June 2009) clarication of 2
September 1999
[26] Unisys Not Suing (most) Webmasters for Using GIFs
Slashdot investigation into the controversy
[27] Burn All GIFs Aproject of the League for Programming
Freedom
[28] License Information on GIF and Other LZW-based Tech-
nologies at the Wayback Machine (archived 2 June 2009)
[29] Why There Are No GIF Files on GNUWeb Pages. Free
Software Foundation. Retrieved 19 May 2012.
[30] PNG versus GIF Compression. Retrieved 8 June 2009.
[31] AlphaImageLoader Filter
[32] Whats New in Internet Explorer 7. MSDN. Retrieved 6
March 2009.
[33] PNG Image File Format. Retrieved 8 June 2009.
[34] VOTE FAILED: APNG 20070405a. SourceForge
mailing list. 2007-04-20.
[35] Discussion for a simple animated PNG format.
Archived from the original on 2009-02-26. Retrieved
2011-07-12.
[36] APNG Specication MozillaWiki
[37] Mozilla Labs Blog Archive Better animations in Fire-
fox 3
[38] Bug 195280 Removal of MNG/JNG support
[39] Bug 18574 restore support for MNG animation format
and JNG image format
[40] Chromium Blog: Chrome 32 Beta: Animated WebP
images and faster Chrome for Android touch input.
Blog.chromium.org. 2013-11-21. Retrieved 2014-02-01.
6.14 External links
spec-gif89a.txt GIF 89a specication on w3.org
LZW and GIF explained
Replacing a Dictionary with a Square Root sug-
gestions for compressing GIFs without using LZW
compression
Gifology
Animated GIFs Documentary produced by O
Book (web series)
Chapter 7
Portable Network Graphics
Portable Network Graphics
[2]
(PNG,
[3]
pronounced
ping), is a raster graphics le format that supports
lossless data compression. PNG was created as an im-
proved, non-patented replacement for Graphics Inter-
change Format (GIF), and is the most used lossless image
compression format on the Internet.
[4]
PNG supports palette-based images (with palettes of 24-
bit RGB or 32-bit RGBA colors), grayscale images (with
or without alpha channel), and full-color non-palette-
based RGB[A] images (with or without alpha channel).
PNG was designed for transferring images on the In-
ternet, not for professional-quality print graphics, and
therefore does not support non-RGB color spaces such
as CMYK.
PNG les nearly always use le extension PNG or png
and are assigned MIMEmedia type image/png. PNGwas
approved for this use by the Internet Engineering Steering
Group on 14 October 1996,
[5]
and was published as an
ISO/IEC standard in 2004.
[1]
7.1 History and development
See also: Graphics Interchange Format Unisys and
LZW patent enforcement
The motivation for creating the PNG format was in
early 1995, after it became known that the LempelZiv
Welch (LZW) data compression algorithm used in the
Graphics Interchange Format (GIF) format was patented
by Unisys. There were also other problems with the
GIF format that made a replacement desirable, notably
its limit of 256 colors at a time when computers able to
display far more than 256 colors were growing common.
A January 1995 precursory discussion thread, on the
usenet newsgroup comp.graphics with the subject
Thoughts on a GIF-replacement le format, had many
propositions, which would later be part of the PNG le
format. In this thread, Oliver Fromme, author of the
popular DOS JPEG viewer QPEG, proposed the PING
name, meaning PING is not GIF, and also the PNG
extension.
[6]
Although GIF allows for animation, it was decided that
PNG should be a single-image format.
[7]
In 2001, the
developers of PNG published the Multiple-image Net-
work Graphics (MNG) format, with support for anima-
tion. MNG achieved moderate application support, but
not enough among mainstream web browsers and no us-
age among web site designers or publishers. In 2008, cer-
tain Mozilla developers published the Animated Portable
Network Graphics (APNG) format with similar goals.
APNG is a format that is natively supported by Gecko-
and Presto-based web browsers, but as of 2013, usage of
APNG remains very minimal.
1 October 1996: Version 1.0 of the PNG specica-
tion was released, and later appeared as RFC 2083.
It became a W3C Recommendation on 1 October
1996.
31 December 1998: Version 1.1, with some small
changes and the addition of three new chunks, was
released.
11 August 1999: Version 1.2, adding one extra
chunk, was released.
10 November 2003: PNG became an International
Standard (ISO/IEC 15948:2003). This version of
PNG diers only slightly from version 1.2 and adds
no new chunks.
60
7.3. TECHNICAL DETAILS 61
3 March 2004: ISO/IEC 15948:2004.
[1]
7.2 PNG Working Group
The original PNG specication was authored by an ad-
hoc group of computer graphics experts and enthusiasts.
Discussions and decisions about the format were done ex-
clusively via email. The original authors listed on RFC
2083 are:
[8]
Editor: Thomas Boutell
Contributing Editor: Tom Lane
Authors (in alphabetical order): Mark Adler,
Thomas Boutell, Christian Brunschen, Adam M.
Costello, Lee Daniel Crocker, Andreas Dilger,
Oliver Fromme, Jean-loup Gailly, Chris Herborth,
Aleks Jakulin, Neal Kettler, Tom Lane, Alexander
Lehmann, Chris Lilley, Dave Martindale, Owen
Mortensen, Keith S. Pickens, Robert P. Poole,
Glenn Randers-Pehrson, Greg Roelofs, Willem van
Schaik, Guy Schalnat, Paul Schmidt, Tim Wegner,
Jeremy Wohl
7.3 Technical details
The PNG image viewed with a hex editor
7.3.1 File header
A PNG le starts with an 8-byte signature:
[9]
(see hex
editor image at right)
7.3.2 Chunks within the le
After the header comes a series of chunks, each of which
conveys certain information about the image. Chunks de-
clare themselves as critical or ancillary, and a program
encountering an ancillary chunk that it does not under-
stand can safely ignore it. This chunk-based storage layer
structure, similar in concept to a container format, is de-
signed to allow the PNG format to be extended while
maintaining compatibility with older versionsit pro-
vides forward compatibility, and this same le structure
(with dierent signature and chunks) is used in the asso-
ciated MNG, JNG, and APNG formats.
A chunk consists of four parts: length (4 bytes), chunk
type/name (4 bytes), chunk data (length bytes) and CRC
(cyclic redundancy code/checksum; 4 bytes). The CRCis
a network-byte-order CRC-32 computed over the chunk
type and chunk data, but not the length.
Chunks are given a four-letter case sensitive ASCII
type/name; compare FourCC. The case of the dierent
letters in the name (bit 5 of the numeric value of the char-
acter) is a bit eld that provides the decoder with some
information on the nature of chunks it does not recognize.
The case of the rst letter indicates whether the chunk is
critical or not. If the rst letter is uppercase, the chunk
is critical; if not, the chunk is ancillary. Critical chunks
contain information that is necessary to read the le. If a
decoder encounters a critical chunk it does not recognize,
it must abort reading the le or supply the user with an
appropriate warning.
The case of the second letter indicates whether the chunk
is public (either in the specication or the registry of
special-purpose public chunks) or private (not stan-
dardised). Uppercase is public and lowercase is pri-
vate. This ensures that public and private chunk names
can never conict with each other (although two private
chunk names could conict).
The third letter must be uppercase to conformto the PNG
specication. It is reserved for future expansion. De-
coders should treat a chunk with a lower case third letter
the same as any other unrecognised chunk.
62 CHAPTER 7. PORTABLE NETWORK GRAPHICS
The case of the fourth letter indicates whether the chunk
is safe to copy by editors that do not recognize it. If low-
ercase, the chunk may be safely copied regardless of the
extent of modications to the le. If uppercase, it may
only be copied if the modications have not touched any
critical chunks.
Critical chunks
Adecoder must be able to interpret critical chunks to read
and render a PNG le.
IHDRmust be the rst chunk; it contains the images
width, height, color type and bit depth.
[10]
PLTE contains the palette; list of colors.
IDAT contains the image, which may be split among
multiple IDAT chunks. Such splitting increases le-
size slightly, but makes it possible to generate a PNG
in a streaming manner. The IDAT chunk contains
the actual image data, which is the output stream of
the compression algorithm.
[11]
IEND marks the image end.
The PLTE chunk is essential for color type 3 (indexed
color). It is optional for color types 2 and 6 (truecolor
and truecolor with alpha) and it must not appear for color
types 0 and 4 (grayscale and grayscale with alpha).
Ancillary chunks
Other image attributes that can be stored in PNG les
include gamma values, background color, and textual
metadata information. PNG also supports color manage-
ment through the inclusion of ICCcolor space proles.
[12]
bKGD gives the default background color. It is in-
tended for use when there is no better choice avail-
able, such as in standalone image viewers (but not
web browsers; see below for more details).
cHRMgives the chromaticity coordinates of the dis-
play primaries and white point.
gAMA species gamma.
hIST can store the histogram, or total amount of
each color in the image.
iCCP is an ICC color prole.
iTXt contains UTF-8 text, compressed or not,
with an optional language tag. iTXt chunk with
the keyword 'XML:com.adobe.xmp' can contain
Extensible Metadata Platform (XMP).
pHYs holds the intended pixel size and/or aspect ra-
tio of the image.
sBIT (signicant bits) indicates the color-accuracy
of the source data.
sPLT suggests a palette to use if the full range of
colors is unavailable.
sRGB indicates that the standard sRGB color space
is used.
sTERstereo-image indicator chunk for stereoscopic
images.
[13]
tEXt can store text that can be represented in
ISO/IEC8859-1, with one name=value pair for each
chunk.
tIME stores the time that the image was last
changed.
tRNS contains transparency information. For in-
dexed images, it stores alpha channel values for one
or more palette entries. For truecolor and grayscale
images, it stores a single pixel value that is to be re-
garded as fully transparent.
zTXt contains compressed text with the same limits
as tEXt.
The lowercase rst letter in these chunks indicates that
they are not needed for the PNG specication. The low-
ercase last letter in some chunks indicates that they are
safe to copy, even if the application concerned does not
understand them.
7.3.3 Color depth
PNG images can either use palette-indexed color or be
made up of one or more channels (numerical values di-
rectly representing quantities about the pixels). When
there is more than one channel in an image all channels
have the same number of bits allocated per pixel (known
as the bit depth of the channel). Although the PNGspeci-
cation always talks about the bit depth of channels, most
7.3. TECHNICAL DETAILS 63
software and users generally talk about the total number
of bits per pixel (sometimes also referred to as bit depth
or color depth). If there is more than one channel, the
number of bits per pixel is higher than the number of bits
per channel, as shown in the illustration at right.
The number of channels will depend on whether the im-
age is grayscale or color and whether it has an alpha chan-
nel. PNG allows the following combinations of channels,
called the color type.
The color type is specied in the color type eld, which
is a bit eld, as explained in the table below at right. Not
all combinations are valid, however: there is no indexed
grayscale, which would be color types 1 and 5; trans-
parency in palette images is indicated by the presence of
a tRNS chunk, not a separate channel, so there is no color
type 7.
0: grayscale
2: red, green and blue: rgb/truecolor
3: indexed: channel containing indices into a palette
of colors
4: grayscale and alpha: level of transparency for
each pixel
6: red, green, blue and alpha
With indexed color images, the palette is always stored in
RGB at a depth of 8 bits per channel (24 bits per palette
entry). Additionally, an optional array of 8-bit alpha val-
ues of the palette entries may be included. The palette
must not have more entries than the image bit depth al-
lows for, but it may have fewer (for example, if an image
only uses 90 colors then it does not need palette entries
for all 256 colors).
Indexed color PNGs are allowed to have 1, 2, 4 or 8 bits
per pixel by the standard; grayscale images with no al-
pha channel allow for 1, 2, 4, 8 or 16 bits per pixel. Ev-
erything else uses a bit depth per channel of either 8 or
16. The combinations this allows are given in the table
above. The standard requires that decoders can read all
supported color formats, but many image editors can only
produce a small subset of them.
7.3.4 Transparency of image
PNG oers a variety of transparency options. With true-
color and grayscale images either a single pixel value can
be declared as transparent or an alpha channel can be
added (enabling any percentage of partial transparency to
be used). For paletted images, alpha values can be added
to palette entries. The number of such values stored may
be less than the total number of palette entries, in which
case the remaining entries are considered fully opaque.
The scanning of pixel values for binary transparency is
supposed to be performed before any color reduction to
avoid pixels becoming unintentionally transparent. This
is most likely to pose an issue for systems that can decode
16-bits-per-channel images (as they must to be compliant
with the specication) but only output at 8 bits per chan-
nel (the norm for all but the highest end systems).
Alpha storage can be associated (premultiplied) or
unassociated, but PNG standardized
[15]
on unasso-
ciated (non-premultiplied) alpha so that images with
separate transparency masks can be stored losslessly.
7.3.5 Compression
PNG uses a 2-stage compression process:
pre-compression: ltering (prediction)
compression: DEFLATE
PNG uses a non-patented lossless data compression
method known as DEFLATE, which is the same algo-
rithm used in the zlib compression library.
Filtering
Before DEFLATE is applied, the data is precompressed,
via a prediction method: a single lter method is used for
the entire image, while for each image line, a lter type
is chosen that transforms the data so that it is hopefully
more easily compressed.
[16]
There is only one lter method in the current PNG speci-
cation (denoted method 0), and thus in practice the only
choice is which lter type to apply to each line. For this
method, the lter predicts the value of each pixel based on
the values of previous neighboring pixels, and subtracts
the predicted color of the pixel from the actual value,
as in DPCM. An image line ltered in this way is of-
ten more compressible than the raw image line would be,
especially if it is similar to the line above, since the dier-
ences from prediction will generally be clustered around
C B D
X A
PNGs lter method 0 can use the data in pixels A, B, and C to
predict the value for X.
A PNG with 256 colors, which is only 251 bytes large with pre-
lter. The same image as a GIF would be more than thirteen
times larger.
0, rather than spread over all possible image values. This
is particularly important in relating separate rows, since
DEFLATE has no understanding that an image is a 2D
entity, and instead just sees the image data as a stream of
bytes.
There are ve lter types for lter method 0; each type
predicts the value of each byte (of the image data before
ltering) based on the corresponding byte of the pixel to
the left (A), the pixel above (B), and the pixel above and
to the left (C) or some combination thereof, and encodes
the dierence between the predicted value and the actual
value. Filters are applied to byte values, not pixels; pixel
values may be one or two bytes, or several values per byte,
but never cross byte boundaries. The lter types are:
[17]
The Paeth lter is based on an algorithm by Alan W.
Paeth.
[18]
Compare to the version of DPCM used in
lossless JPEG, and to the discrete wavelet transform us-
ing 12, 21, or (for the Paeth predictor) 22 windows
and Haar wavelets.
Compression is further improved by choosing lter types
adaptively on a line-by-line basis. This improvement, and
a heuristic method of implementing it commonly used
by PNG-writing software, were created by Lee Daniel
Crocker, who tested the methods on many images dur-
ing the creation of the format;
[19]
the choice of lter is a
component of le size optimization, as discussed below.
If interlacing is used, each stage of the interlacing is l-
tered separately, meaning that the image can be progres-
sively rendered as each stage is received; however, inter-
lacing generally makes compression less eective.
7.3.6 Interlacing
An illustration of Adam7 interlacing over a 1616 image.
PNG oers an optional 2-dimensional, 7-pass interlacing
schemethe Adam7 algorithm. This is more sophisti-
cated than GIFs 1-dimensional, 4-pass scheme, and al-
lows a clearer low-resolution image to be visible earlier in
the transfer, particularly if interpolation algorithms such
as bicubic interpolation are used.
[20]
7.4. COMPARISON TO OTHER FILE FORMATS 65
However, the 7-pass scheme tends to reduce the datas
compressibility more than simpler schemes.
7.3.7 Animation
PNG itself does not support animation at all. MNG is an
extension to PNG that does; it was designed by members
of the PNG Group. MNG shares PNGs basic structure
and chunks, but it is signicantly more complex and has
a dierent le signature, which automatically renders it
incompatible with standard PNG decoders.
The complexity of MNG led to the proposal of APNG
by developers of the Mozilla Foundation. It is based
on PNG, supports animation and is simpler than MNG.
APNG oers fallback to single-image display for PNG
decoders that do not support APNG. However, neither
of these formats is currently widely supported. APNG
is supported in Firefox 3.0 and Opera 9.5,
[21]
but since
Opera changed its layout engine to Blink support was
dropped. The latest version of Safari on iOS 8 supports
APNG.
[22]
The PNG Group decided in April 2007 not
to embrace APNG.
[23]
Several alternatives were under
discussion, ANG, aNIM/mPNG, PNG in GIF and its
subset RGBA in GIF.
[24]
7.4 Comparison to other le for-
mats
7.4.1 Comparison to Graphics Inter-
change Format (GIF)
On small images, GIF can achieve greater compres-
sion than PNG (see the section on lesize, below).
On most images, except for the above case, a GIF
will have a larger le-size than an indexed PNG.
PNG gives a much wider range of transparency
options than GIF, including alpha channel trans-
parency.
Whereas GIF is limited to 8-bit indexed color, PNG
gives a much wider range of color depths, including
24-bit (8 bits per channel) and 48-bit (16 bits per
channel) truecolor, allowing for greater color preci-
sion, smoother fades, etc.
[25]
When an alpha channel
is added, up to 64 bits per pixel (before compres-
sion) are possible.
When converting an image from the PNG for-
mat to GIF, the image quality may suer due to
posterization if the PNG image has more than 256
colors.
GIF intrinsically supports animated images. PNG
supports animation only via unocial extensions
(see the section on animation, above).
PNG images are less widely supported by older browsers.
In particular, IE6 has limited support for PNG.
[26]
7.4.2 Comparison to JPEG
Composite image comparing lossy compression in JPEG with
lossless compression in PNG: the JPEG artifacts are easily vis-
ible in the background, where the PNG image has solid color.
JPEG (Joint Photographic Experts Group) format can
produce a smaller le than PNG for photographic (and
photo-like) images, since JPEG uses a lossy encoding
method specically designed for photographic image
data, which is typically dominated by soft, low-contrast
transitions, and an amount of noise or similar irregular
structures. Using PNG instead of a high-quality JPEG
for such images would result in a large increase in lesize
with negligible gain in quality. In contrast, when stor-
ing images that contain text, line art, or graphics im-
ages with sharp transitions and large areas of solid color
the PNG format can compress image data more than
JPEG can. Additionally, PNG is lossless, while JPEG
produces noticeable visual artifacts around high-contrast
areas. Where an image contains both sharp transitions
and photographic parts, a choice must be made between
the two eects. JPEG does not support transparency.
Because JPEG uses lossy compression, it also suers
from generation loss, where repeatedly decoding and re-
encoding an image to save it again causes a loss of infor-
mation each time, degrading the image. This does not
happen with repeated viewing or copying, but only if the
le is edited and saved over again. Because PNG is loss-
less, it is suitable for storing images to be edited. While
PNG is reasonably ecient when compressing photo-
graphic images, there are lossless compression formats
designed specically for photographic images, lossless
JPEG 2000 and Adobe DNG (digital negative) for ex-
ample. However these formats are either not widely sup-
ported, or are proprietary. An image can be stored loss-
lessly and converted to JPEGformat only for distribution,
so that there is no generation loss.
The PNG specication does not include a standard for
embedding Exif image data from sources such as digital
cameras. Instead, PNG has various dedicated ancillary
chunks for storing the metadata that other le formats
(such as JPEG) would typically store in Exif format.
Early web browsers did not support PNG images; JPEG
and GIF were the main image formats. JPEG was com-
monly used when exporting images containing gradients
for web pages, because of GIFs limited color depth.
However, JPEG compression causes a gradient to blur
slightly. A PNG le will reproduce a gradient as accu-
rately as possible for a given bit depth, while keeping the
le size small. PNG became the optimal choice for small
gradient images as web browser support for the format
improved. No images at all are needed to display gra-
dients in modern browsers, as gradients can be created
using CSS.
7.4.3 Comparison to JPEG-LS
JPEG-LS is a near-lossless image format by the Joint
Photographic Experts Group, though far less widely
known and supported than the other lossy JPEG format
discussed above. It is directly comparable with PNG, and
has a standard set of test images.
[27]
On the Waterloo
Repertoire ColorSet, a standard set of test images (un-
related to the JPEG-LS conformance test set), JPEG-LS
generally performs better than PNG, by 1015%, but on
some images PNG performs substantially better, on the
order of 5075%.
[28]
Thus, if both of these formats are
options and le size is an important criterion, they should
both be considered, depending on the image.
7.4.4 Comparison to TIFF
Tagged Image File Format (TIFF) is a format that incor-
porates an extremely wide range of options. While this
makes TIFF useful as a generic format for interchange
between professional image editing applications, it makes
adding support for it to applications a much bigger task
and so it has little support in applications not concerned
with image manipulation (such as web browsers). The
high level of extensibility also means that most applica-
tions provide only a subset of possible features, poten-
tially creating user confusion and compatibility issues.
The most common general-purpose, lossless compression
algorithmused with TIFF is LempelZivWelch (LZW).
This compression technique, also used in GIF, was cov-
ered by patents until 2003. TIFF also supports the com-
pression algorithm PNG uses (i.e. Compression Tag
0008
16
'Adobe-style') with medium usage and support
by applications. TIFF also oers special-purpose lossless
compression algorithms like CCITTGroup IV, which can
compress bilevel images (e.g., faxes or black-and-white
text) better than PNGs compression algorithm.
PNG supports non-premultiplied alpha only
[15]
whereas
TIFF also supports associated (premultiplied) alpha.
7.5 Software support
7.5.1 Bitmap graphics editor support for
PNG
Main article: Comparison of raster graphics editors
The PNG format is widely supported by graphics pro-
grams, including Adobe Photoshop, Corel's Photo-Paint
and Paint Shop Pro, the GIMP, GraphicConverter,
Helicon Filter, ImageMagick, Inkscape, IrfanView, Pixel
image editor, Paint.NET and Xara Photo & Graphic De-
signer and many others. Some programs bundled with
popular operating systems which support PNG include
Microsoft's Paint and Apple's iPhoto and Preview, with
the GIMP also often being bundled with popular Linux
7.5. SOFTWARE SUPPORT 67
distributions.
Adobe Fireworks (formerly by Macromedia) uses PNG
as its native le format, allowing other image editors and
preview utilities to view the attened image. However,
Fireworks by default also stores meta data for layers, an-
imation, vector data, text and eects. Such les should
not be distributed directly. Fireworks can instead export
the image as an optimized PNG without the extra meta
data for use on web pages, etc.
7.5.2 Web browser support for PNG
Main article: Web browser image format support
PNG support rst appeared in Internet Explorer 4.0b1
and in Netscape 4.04.
[29]
Despite calls by the Free Software Foundation
[30]
and the
World Wide Web Consortium (W3C),
[31]
tools such as
gif2png,
[32]
and campaigns such as Burn All GIFs,
[33]
PNG adoption on websites has been fairly slow due to
late and buggy support in Internet Explorer, particularly
regarding transparency.
[34]
PNG compatible browsers include: Apple Safari, Google
Chrome, Mozilla Firefox, Opera, Camino, Internet Ex-
plorer 7 (still numerous issues),
[35]
Internet Explorer 8
(still some issues), Internet Explorer 9 and many others.
For the complete comparison, see Comparison of web
browsers (Image format support).
Especially versions of Internet Explorer (Windows) be-
low 9.0 have numerous problems which prevent it from
correctly rendering PNG images.
[35]
4.0 crashes on large PNG chunks.
[36]
4.0 does not include the functionality to view .png
les,
[37]
but there is a registry x.
[35]
5.0 and 5.01 have broken OBJECT support.
[38]
5.01 prints palette images with black (or dark gray)
backgrounds under Windows 98, sometimes with
radically altered colors.
[39]
6.0 fails to display PNG images of 4097 or 4098
bytes in size.
[40]
6.0 cannot open a PNGle that contains one or more
zero-length IDAT chunks. This issue was rst xed
in security update 947864 (MS08-024). For more
information, see this article in the Microsoft Knowl-
edge Base: 947864 MS08-024: Cumulative Secu-
rity Update for Internet Explorer
[41]
6.0 sometimes completely loses ability to display
PNGs, but there are various xes.
[42]
6.0 and below have broken alpha-channel trans-
parency support (will display the default background
color instead).
[43][44][45]
However there are various
xes:
--- Degradable PNG Transparency for IE6
--- webfx - PNG Behavior (IE behavior/.htc)
--- The PNG problem in Windows Internet Ex-
plorer (IE behavior/.htc) (unmaintained)
--- TwinHelix - Near-native PNGsupport with al-
pha opacity to IE 5.5 and 6 (IE behavior/.htc)
--- A Better IE 5.5 and 6 PNG Fix (supports CSS
background-position, background-repeat) (IE
behavior/.htc)
--- 24ways.org - Transparent PNGs in Internet
Explorer 6 by Drew McLellan (JavaScript)
--- PNG-24 Alpha Transparency With Microsoft
Internet Explorer or better (MSIE 5.5+)
(PHP)
--- PNGPong, an open source solution to display
transparent PNGs in IE, Firefox, and Safari
without the use of lters, PHP, or complicated
Javascript and CSS (JavaScript+Flash)
--- Cross Browser PNG Transparency (CSS)
--- CSS PNG x (with background call none x)
(CSS)
--- SitePoint - Use 8-bit PNGs with Fireworks
--- Use 8-bit PNGs with Photoshop and pngquant
--- dillerdesign belatedPNG (JavaScript+VML)
--- Dean Edwardss IE7.js and IE8.js xes this is-
sue (for specially-named .PNG les, for per-
formance reasons), and other IE 5.5, 6, and 7
CSS incompatibilities as well.
7.0 and below cannot combine 8-bit alpha trans-
parency AND element opacity (CSS - lter: Al-
pha (opacity=xx)) without lling partially transpar-
ent sections with black.
[46]
8.0 and below have inconsistent/broken gamma
support.
[35]
8.0 and below don't have color-correction
support.
[35]
7.5.3 Operating system support for PNG
icons
PNG icons have been supported in most distributions
of Linux since at least 1999, in desktop environments
such as GNOME.
[47]
In 2006, Microsoft Windows sup-
port for PNG icons was introduced in Windows Vista.
[48]
PNG icons are supported in AROS, Mac OS X, iOS and
MorphOS as well. In addition, Android makes a large use
of PNGs.
7.6 File size and optimization soft-
ware
PNGle size can vary signicantly depending on howit is
encoded and compressed; this is discussed and a number
of tips are given in PNG: The Denitive Guide.
[28]
7.6.1 Compared to GIF
Compared to GIF les, a PNG le with the same in-
formation (256 colors, no ancillary chunks/metadata),
compressed by an eective compressor will normally be
smaller than GIF. Depending on the le and the compres-
sor, PNG may range from somewhat smaller (10%) to
signicantly smaller (50%) to somewhat larger (5%), but
is rarely signicantly larger
[28]
for large images. This is
attributed to the performance of PNGs DEFLATE com-
pared to GIFs LZW, and because the added precom-
pression layer of PNGs predictive lters take account of
the 2-dimensional image structure to further compress
les; as ltered data encodes dierences between pix-
els, they will tend to cluster closer to 0, rather than being
spread across all possible values, and thus be more easily
compressed by DEFLATE. However, some versions of
Adobe Photoshop, CorelDRAW and MS Paint provide
poor PNGcompression, creating the impression that GIF
is more ecient.
[28]
7.6.2 File size factors
PNG les vary in size due to a number of factors:
color depth Color depth can range from 1 to 64 bits per
pixel.
ancillary chunks PNGsupports metadatathis may be
useful for editing, but unnecessary for viewing, as on
websites.
interlacing As each pass of the Adam7 algorithmis sep-
arately ltered, this can increase le size.
[28]
lter As a precompression stage, each line is ltered by
a predictive lter, which can change from line to
line. As the ultimate DEFLATE step operates on
the whole images ltered data, one cannot optimize
this row-by-row; the choice of lter for each row
is thus potentially very variable, though heuristics
exist.
[49]
compression With additional computation, DEFLATE
compressors can produce smaller les.
There is thus a lesize trade-obetween high color depth,
maximal metadata (including color space information,
together with information that does not aect display),
interlacing, and speed of compression, which all yield
large les, with lower color depth, fewer or no ancillary
chunks, no interlacing, and tuned but computationally in-
tensive ltering and compression. For dierent purposes
one will choose dierent trade-os: a maximal le may
be best for archiving and editing, while a stripped down
le may be best for use on a website, and similarly fast
but poor compression is preferred when repeatedly edit-
ing and saving a le, while slow but high compression is
preferred when a le is stable: when archiving or post-
ing. Interlacing is a trade-o: it dramatically speeds up
early rendering of large les (improves latency), but may
increase le size (decrease throughput) for little gain, par-
ticularly for small les.
[28]
Lossy PNG compression
Even though PNG has been designed as a lossless for-
mat, PNG encoders can pre-process image data in a lossy
fashion (so as to reduce colors used) to improve PNG
compression.
[50]
7.6. FILE SIZE AND OPTIMIZATION SOFTWARE 69
7.6.3 Image editing software
Some programs are more ecient than others when sav-
ing PNG les, this relates to implementation of the PNG
compression used by the program.
Many graphics programs (such as Apples Preview soft-
ware) save PNGs with large amounts of metadata and
color-correction data that are generally unnecessary for
Web viewing. Unoptimized PNG les from Adobe Fire-
works are also notorious for this since they contain op-
tions to make the image editable in supported editors.
Also CorelDRAW (at least version 11) sometimes pro-
duces PNGs which cannot be opened by Internet Ex-
plorer (versions 68).
Adobe Photoshop's performance on PNG les has im-
proved in the CS Suite when using the Save For Web fea-
ture (which also allows explicit PNG/8 use).
Adobes Fireworks saves larger PNG les than many pro-
grams by default. This stems from the mechanics of its
Save format: the images produced by Fireworks save
function include large, private chunks, containing com-
plete layer and vector information. This allows further
lossless editing. When saved with the Export option, Fire-
works PNGs are competitive with those produced by
other image editors, but are no longer editable as any-
thing but attened bitmaps. Fireworks is unable to save
size-optimized vector-editable PNGs.
Other notable examples of poor PNG compressors in-
clude:
Microsofts Paint for Windows XP
Microsoft Picture It! Photo Premium 9
Poor compression increases the PNG le size but does
not aect the image quality or compatibility of the le
with other programs.
Because GIF is de facto limited to 256 colors (GIF87a
Standard), image editors must automatically reduce the
color depth when saving an image in GIF format. Often,
when people save the same truecolor image as PNG and
GIF, they see that the GIF is smaller, and do not real-
ize that this is due to the color depth reduction, and that
it is possible to create a 256-color PNG that has identi-
cal quality to the GIF with a smaller le size. Further,
some tools may automatically create PNG les as 24-bit,
even if the source image is 8-bit, bloating the le.
[28]
This
leads to the misconception that PNG les are larger than
equivalent GIF les.
7.6.4 Optimizing tools
Various tools are available for optimizing PNG les; they
do this by:
(optionally) removing ancillary chunks,
reducing color depth, either:
--- use a palette (instead of RGB) if the image has
256 or fewer colors,
--- use a smaller palette, if the image has 2, 4, or
16 colors, or
--- (optionally) lossily discard some of the data in
the original image,
optimizing line-by-line lter choice, and
optimizing DEFLATE compression.
Tool list
pngcrush has been existing for the longest time
among the popular PNG optimizers. It allows for
multiple trials on lter selection and compression ar-
guments, and nally choose the smallest one. This
working model is used in almost every png opti-
mizer.
OptiPNG was based on pngcrush and eectively su-
persedes it, by iterating over a wider range of com-
pression parameters and performing trials in mem-
ory for faster execution,
[51]
as well as performing au-
tomatic bit depth, color type and color palette reduc-
tion where possible. (pngcrush has the ability to do
color reduction in a later version.)
Advpng from package AdvanceCOMP was made to
use 7-zips deater (which is slower but have smaller
output than zlib), to optimize png les. However,
since PNG is ltered before deate compression,
while advpng uses lter 0 globally (in other words
it only uses unltered data), its not a good consider-
ation for png optimization. (In most scenarios, l-
tering helps more than a good deater.)
Advdef from the same package, however, is able to
recompress the zlib stream, acting as a re-deater.
pngout was made with the authors own deater
(same to the authors zip utility, kzip), while keeps
all facilities of color reduction / ltering. However,
pngout doesn't allowfor using several trials on lters
in a single run, so its suggested to use its commercial
GUI version, pngoutwin, or used with a wrapper to
automates the trials or to recompress using its own
deater while keep the lter line by line.
[52]
zopipng was also made with a self-own deater,
zopi. It has all the optimizing features op-
tipng/pngcrush have (including automating trials)
while providing a good deater.
A simple comparison of their features is listed below.
Before zopipng was available, a good way in practice
to perform a png optimization is to use a combination
of 2 tools in sequence for optimal compression: one
which optimizes lters (and removes ancillary chunks),
and one which optimizes DEFLATE. Although pngout
oers both but only one type of lter can be specied in
a single run, therefore it can be used with a wrapper tool
or in combination with optipng or pngcrush,
[52]
acting as
a re-deater, like advdef.
Ancillary chunk removal
For removing ancillary chunks, most PNG optimization
tools have the ability to remove all color correction data
from PNG les (gamma, white balance, ICC color pro-
le, standard RGB color prole). This often results in
much smaller le sizes. For example, the following com-
mand line options achieve this with pngcrush:
pngcrush -rem gAMA -rem cHRM -rem iCCP -rem
sRGB InputFile.png OutputFile.png
Ancillary chunks can also be losslessly removed using the
free Win32 program PNGExtra.
Filter optimization
OptiPNG, pngcrush, pngout, and zopipng all oer op-
tions applying one of the lter types 04 globally (using
the same lter type for all lines) or with a pseudo lter
(numbered 5), which for each line chooses one of the l-
ter types 04 using an adaptive algorithm. Zopipng of-
fers 3 dierent adaptive method, including a brute-force
search that attempts to optimize the ltering.
[58]
pngout and zopipng provide an option to
preserve/reuse
[52][59]
the line-by-line lter set present in
the input image.
OptiPNG, pngcrush and zopipng provide options to try
dierent lter strategies in a single run and choose the
best. The freeware command line version of pngout
doesn't oer this, but the commercial version, pngoutwin,
does.
[60]
DEFLATE optimization
AdvanceCOMP advdef, advpng, Ken Silverman's
PNGOUT and zopipng employ DEFLATE compres-
sion algorithms that are more exhaustive and produce
smaller les than the zlib reference implementation used
by the other compressors.
advpng doesn't have an option to apply lters and always
uses lter 0 globally (leaving the image data unltered);
therefore it should not be used where the image benets
signicantly from ltering. By contrast, advdef from the
same package doesn't deal with PNG structure and acts
only as a re-deater, retaining any existing lter settings.
Wrapper tools
Wrapper tools that simplify this workow include:
ImageOptim, a GUI front-end for Mac OS X; Kashmir
Web Optimizer- GUI front-end for Windows; pngoptima
cmd batch script for Windows; imgopt, a command-line
shell script that also losslessly optimizes JPEG images,
Smush.it, an image-optimizing web service; TinyPNG,
which provides compression by reducing the number of
colors in the image automatically, but preserving alpha
transparency; and Compress PNG that allows users to
pick the number of colors that should be used.
The littleutils is another open-source package, containing
a wrapper script called opt-png that uses pngcrush and
a variant of pngrewrite to reduce bit-depth when possi-
ble. Perl scripts might wish to employ Image-Pngslimmer
which allows some dynamic optimization.
The current version of IrfanViewcan use PNGOUT as an
external plug-in, obviating the need for a separate com-
pressor.
An open source Windows program called FileOptimizer
losslessly optimizes many letypes, including PNG. It
runs multiple PNG optimization programs: advpng, ap-
7.8. REFERENCES 71
ngopt, optipng, PngOptimizer, pngout, pngrewrite, and
pngwolf.
Performance All wrapper tools are designed to use
the optimizers to do several tries, then select the best re-
sult. Most wrappers just run all optimizers, and select
the smallest le, so the best lter may not be paired with
best deater.
[61]
Such wrappers may take longer to run,
but not always have a good output (although, likely to be
good enough compress to the le before optimization).
pngoptim is a Windows command-line wrapper that runs
in a reasonable way so that best lter is paired with best
deater,
[62]
thus may always produce the smallest image
le with less eort compared to other wrappers brute
way.
7.6.5 Icon optimization
Since icons intended for Windows Vista and later ver-
sions may contain PNG subimages, the optimizations can
be applied to them as well. At least one icon editor,
Pixelformer, is able to perform a special optimization
pass while saving ICO les, thereby reducing their sizes.
FileOptimizer (mentioned above) can also handle ICO
les.
Icons for Mac OS X may also contain PNG subimages,
yet there isn't such tool available.
7.7 See also
Computer graphics, including:
--- Comparison of layout engines (graphics)
Image editing
Image le formats
libpng
Related graphics le formats
--- APNG Animated PNG
--- JPEG Network Graphics (JNG)
--- Multiple-image Network Graphics (MNG)
Similar le formats
--- Graphics Interchange Format (GIF)
--- X PixMap for portable icons
Scalable Vector Graphics
WebP
7.8 References
[1] ISO/IEC 15948:2004 - Information technology -- Com-
puter graphics and image processing -- Portable Network
Graphics (PNG): Functional specication. Retrieved
2011-02-19.
[2] History of PNG. Libpng.org. 29 May 2010. Retrieved
2010-10-20.
[3] Richard Stallman - Software Patents (University of Cal-
gary 2005) extquotedbl. YouTube. 2012-04-13. Re-
trieved 2014-02-01.
[4] Matthias Gelbmann (January 31, 2013). The PNG im-
age le format is now more popular than GIF. W3Techs.
Q-Success. Retrieved March 22, 2013. PNG is now
used on 62.4% of all websites, just ahead of GIF with
62.3%.
[5] IANA.org
[6] TBH View prole More options (6 January 1995).
Thoughts on a GIF-replacement le format.
Groups.google.com. Retrieved 2010-10-20.
[7] PNG standard, section 8.4. PNG itself is strictly a
single-image format. (...) In the future, a multiple-image
format based on PNG may be dened. Such a format will
be considered a separate le format
[8] Thomas Boutell (1 March 1997). PNG (Portable Net-
work Graphics) Specication 1.0.
[9] PNG (Portable Network Graphics) Specication, Ver-
sion 1.112. Appendix: Rationale. Libpng.org. Re-
trieved 2010-10-20.
[10] Glenn Randers-Pehrson & Thomas Boutell (editors)
(1999). Chunk Specications. PNG (Portable Network
Graphics) Specication, Version 1.2. Massachusetts Insti-
tute of Technology (MIT). Retrieved 30 Jan 2011.
[11] Portable Network Graphics (PNG) Specication (Sec-
ond Edition) extquotedbl. W3.org. Retrieved 2013-05-
01.
ond Edition) Information technology Computer graph-
ics and image processing Portable Network Graphics
(PNG): Functional specication. ISO/IEC 15948:2003
(E) W3C Recommendation 10 November 2003.
[13] PNG News from 2006. Libpng.org.
[14] Portable Network Graphics (PNG) Specication (Second
Edition): 11.2.2 IHDR Image header.
[15] PNG Specication: Rationale
ond Edition): 9 Filtering. W3.org. Retrieved 2010-10-
20.
[17] Filter Algorithms. PNG Specication.
[18] Paeth, A.W., Image File Compression Made Easy, in
Graphics Gems II, James Arvo, editor. Academic Press,
San Diego, 1991. ISBN 0-12-064480-0.
[19] Crocker, Lee Daniel (July 1995). PNG: The Portable
Network Graphic Format. Dr. Dobbs Journal 20 (232):
3644.
[20] Introduction to PNG. nuwen.net. Retrieved 2010-10-
20.
[21] Opera Desktop Team: Post-Alpha Opera 9.5 Release.
My.opera.com. Retrieved 2010-10-20.
[22] iOS 8 and iPhone 6 for web developers and design-
ers: next evolution for Safari and native webapps. mo-
bilexweb.com. 2014-09-17. Retrieved 2014-09-24.
[23] Vote failed: APNG 20070405a. 20 April 2007.
[24] Comparison of animated PNG format proposals
[25] A Basic Introduction to PNG Features. Libpng.org.
[26] GIF, PNG, JPG. Which One To Use? extquotedbl. Site-
point.com. 3 August 2009. Retrieved 2010-10-20.
[27] T.87 : Lossless and near-lossless compression of
continuous-tone still images - Baseline. International
Telecommunication Union. Retrieved 20 March 2011.
[28] Chapter 9. Compression and Filtering, in PNG: The
Denitive Guide by Greg Roelofs.
[29] Use of PNG Images to Display Data. Oregon Water
Science Center. 16 February 2006.
[30] Why There Are No GIF les on GNUWeb Pages. GNU
Operating System. 16 December 2008.
[31] PNG Fact Sheet. World Wide Web Consortium. 7 Oc-
tober 1996.
[32] Catb.org
[33] Burnallgifs.org
[34] PNG Transparency in Internet Explorer. PC Magazine.
5 October 2004.
[35] Browsers with PNG Support. 14 March 2009.
[36] Windows Explorer Crashes When I Click on a Fireworks
PNG File to View It. Adobe Systems. 5 June 2007.
[37] Unable to view .png images with Internet Explorer 4.0.
Microsoft Knowledge Base.
[38] PNG Graphics That Are Inside of an Object Tag Print as
a Negative Image. Microsoft Knowledge Base.
[39] PNG Images Are Printed Improperly in Internet Ex-
plorer 5.01. Microsoft Knowledge Base.
[40] You cannot view some PNG images in Internet Explorer
6. Microsoft Knowledge Base.
[41] You cannot use Internet Explorer 6 to open a PNG le
that contains one or more zero-length IDAT chunks. Mi-
crosoft Knowledge Base.
[42] PNG Frequently Asked Questions.
[43] PhD: Portable Network Graphics Lose Transparency in
Web Browser. Microsoft Knowledge Base.
[44] PNG Files Do Not Show Transparency in Internet Ex-
plorer. Microsoft Knowledge Base.
[45] Lovitt, Michael (21 December 2002). Cross-Browser
Variable Opacity with PNG: A Real Solution. A List
Apart.
[46] IE7 alpha transparent PNG + opacity. Channel 9.
[47] Fulbright, Michael (1999). GNOME 1.0 Library
Roadmap.
[48] Windows Vista - Icons. OOne. 2007. Retrieved 2007-
11-12.
[49] The ltering is used to increase the similarity to the data,
hence increasing the compression ratio. However, there is
theoretically no formula for similarity, nor absolute rela-
tionship between the similarity and compressor, thus un-
less the compression is done, one can't tell one lter set is
better than another.
[50] PNG can be a lossy format. Pngmini.com. Retrieved
2014-02-01.
[51] Trua, Cosmin. A guide to PNG optimization.
[52] Use pngout -f6 to reuse previous lter set
[53] The tools oering such feature could act as a pure re-
deater to PNG les.
[54] The reference deater implementation, zlib, is not good
enough. See Page Zopi, zip format in 7-zip and pngout
[55] Not only advpng doesn't support color reduction, it also
fails with the images with a reduced colorspace
[56] Advpng can only apply lter 0 globally, thus its neither
yes or no, but N/A.
[57] Advdef only works to inate the deated data, and re-
deate it
[58] [optipng|pngcrush|pngout] -f OR zopipng --lters
[59] zopipng --lters=p
[60] Pngoutwins setting dialog for optimization oers the user
a selection of lter strategies.
[61] If not congured correctly, zopipng and pngout, the op-
timizers with virtually best deaters, may use a very poor
lter therefore beaten by those optimizers who tries to ap-
ply all lter strategies and choose the smallest one but with
a poor deater, zlib.
[62] PNGOptims workow
7.9 Further reading
Roelofs, Greg (April 1997). Linux Gazette: His-
tory of the Portable Network Graphics (PNG) For-
mat. Linux Journal (Specialized Systems Consul-
tants, Inc.) 1997 (36es). ISSN 1075-3583.
Roelofs, Greg (2003). PNG: The Denitive Guide
(2nd ed.). O'Reilly Media. ISBN 1-56592-542-4.
7.10 External links
7.10.1 libpng.org
PNG Home Site
libpng Home Page
The Story of PNG by Greg Roelofs
7.10.2 W3C
PNG Specication (Latest Edition)
Test inline PNG images
7.10.3 Others
An introduction to the PNG image format In-
cluding test images, le editing tips, and reviews of
PNG image tools for Windows.
RFC 2083
PNG transparency test
The Lonely Planet PNG-based animation for
web browsers
More information about PNG color correction
The GD-library to generate dynamic PNG-les with
PHP
A guide to PNG optimization
PNG Adam7 interlacing
JavaScript PNG library Generate client-side PNG
les using JavaScript
lodepng: by Lode Vandevenne. An open source
PNG encoder and decoder for C and C++ with no
external dependencies.
PNGJ: A pure Java PNG encoder and decoder.
OptiPNG PNG optimizer
Encoding Web Shells in PNG les: Encoding hu-
man readable data inside an IDAT block.
Visual comparison of lossy compression techniques
used in PNG and JPEG formats.
7.11 Text and image sources, contributors, and licenses
7.11.1 Text
ASCII Source: http://en.wikipedia.org/wiki/ASCII?oldid=627673066 Contributors: AxelBoldt, The Epopt, Lee Daniel Crocker, Elo-
quence, Mav, Bryan Derksen, Zundark, Hajhouse, Christian List, Nate Silva, Ortolan88, William Avery, Maury Markowitz, Caltrop, Mjb,
Hotlorp, B4hand, Pichai Asokan, Patrick, RTC, Tim Starling, JakeVortex, AdamRaizen, Liftarn, Valery Beaud, Tannin, Axlrosen, Takuya-
Murata, Mpolo, Egil, Ahoerstemeier, Kricxjo, Snoyes, Angela, Elpollo, DropDeadGorgias, UserGoogol, IMSoP, Deisenbe, Cema, Jeandr
du Toit, Rob Hooft, Nikola Smolenski, Jengod, Uriber, Emperorbma, Timwi, Jallan, Nohat, RickK, Ww, Dysprosia, Tedius Zanarukando,
Jay, Fuzheado, Michaeln, Gutza, Traal, Lfwlfw, Pedant17, Furrykef, Tempshill, Omegatron, Ed g2s, Wernher, Bevo, Indefatigable, Anon-
Moos, MrWeeble, Donarreiskoer, Robbot, Noldoaran, Owain, Psychonaut, Modulatum, Lowellian, P0lyglut, Kwi, Yosri, Yacht, DHN,
Hadal, Tbutzon, Wereon, Naelphin, Bbx, Superm401, Pengo, Per Abrahamsen, GreatWhiteNortherner, Tobias Bergemann, David Gerard,
Pabouk, Giftlite, Gwalla, Mkhadpe, DocWatson42, Brouhaha, Ike, DavidCary, Fudoreaper, Levin, Lupin, Herbee, Monedula, Everyk-
ing, Enf, Curps, Sunny256, CyborgTosser, LarryGilbert, Mboverload, VampWillow, Python eggs, Pne, Bobblewik, Dfrankow, Vadmium,
Gazibara, The Singing Badger, Evertype, Taka, OwenBlacker, Maximaximax, Gauss, Kevin B12, Elektron, Icairns, Vishahu, KeithTyler,
Scovetta, Karl Dickman, Abdull, Hobart, Corti, Mike Rosoft, Kune, Mjec, Larrybob, Mindspillage, Discospinster, Rich Farmbrough, Gua-
nabot, ORBIT, B2382F29, R.123, Dbachmann, Hhielscher, Dmeranda, Bender235, Andrejj, Kjoonlee, Kaisershatner, ReallyNiceGuy,
Plugwash, Elwikipedista, Spitzak, CanisRufus, Maclean25, El C, Zenohockey, Kwamikagami, Poiuyuiop, Edward Z. Yang, PhilHibbs,
Shanes, Spearhead, Susvolans, Nickj, Jonathan Drain, Bobo192, Mike Schwartz, Xevious, Johnteslade, Elipongo, Matt Britt, Jjk, Redquark,
Sjoerd visscher, Ignaciomella, Shlomital, RenesisX, Thewayforward, Cherlin, GatesPlusPlus, Jumbuck, Patsw, Musiphil, AMR, Alansohn,
Transnite, Guy Harris, Geo Swan, Sl, ABCD, Sade, AzaToth, Sligocki, Saga City, Wtshymanski, Cburnett, KTC, Ceyockey, Kbolino,
Oleg Alexandrov, Stephen, TigerShark, Tripodics, Myleslong, MattGiuca, Lincher, WadeSimMiser, Apokrif, Cbdorsett, Wikiklrsc, Frungi,
Eyreland, Wayward, Gimboid13, Gerbrant, Graham87, Ilya, BD2412, Galwhaa, Kbdank71, FreplySpang, Reisio, Icey, Rjwilmsi, Tizio,
, NatusRoma, Vary, Amire80, PatrickSauncy, Tangotango, Salix alba, SMC, Jerey Henning, Oblivious, Brighteror-
ange, Fish and karate, Titoxd, RobertG, Kerowyn, RexNL, Swtpc6800, Brendan Moody, Intgr, Fresheneesz, Chris is me, NevilleDNZ,
Bgwhite, NSR, The Rambling Man, YurikBot, Wavelength, NTBot, Jetheji, Phantomsteve, RussBot, Fabartus, Piet Delport, Groogle,
Jasonglchu, Hydrargyrum, Stephenb, Manop, Gaius Cornelius, Bisqwit, Wimt, Dmlandfair, Stassats, Anomie, Keka, 24ip, Cleared as
led, LodeRunner, SixSix, Zwobot, GreggTownsend, BOT-Superzerocool, Morgan Leigh, DeadEyeArrow, CLW, Wardog, Paul Mag-
nussen, Emijrp, Zzuuzz, Closedmouth, Mike Selinker, Pb30, Josh3580, GraemeL, LeonardoRob0t, JLaTondre, Shimonnyman, Worm-
Nut, Maxamegalon2000, Mardus, Elliskev, DVD R W, Finell, Krtki, Chris Chittleborough, Eigenlambda, Dancraggs, BonsaiViking, Jsnx,
SmackBot, Doomdayx, Direvus, Pgk, Basil.bourque, Jagged 85, ZeroEgo, LuNatic, Relaxing, Xaosux, Gilliam, Brianski, Ohnoitsjamie,
Betacommand, ERcheck, Gene Thomas, Bjmullan, 32X, Oli Filth, EncMstr, Domthedude001, SchftyThree, Gutworth, Nbarth, Baa, Gra-
cenotes, Nonky, Can't sleep, clown will eat me, Aleksandar unjar, Glloq, Onorem, Ganche, Benjamin Mako Hill, Pboyd04, UU, BIL,
Cybercobra, Fullstop, Tompsci, Drphilharmonic, Mwtoews, Wizardman, Ultraexactzz, LeoNomis, TextAlchemist, Swatjester, Vanished
user 9i39j3, MagnaMopus, Paulschou, Minna Sora no Shita, PeterThoeny, IronGargoyle, Loadmaster, George The Dragon, Ekohlwey,
Waggers, Thelibragirl, Nathanaeljones, PSUMark2006, Kvng, Dl2000, Phuzion, Hu12, Iridescent, Dreftymac, Adriatikus, Shoeofdeath,
J Di, Twas Now, Octane, Caolote, Courcelles, Bitsecure, Dragonscales, Tawkerbot2, Vanisaac, CRGreathouse, Chaosrxn, KerryVeen-
stra, Porterjoh, GeorgeLouis, Orayzio, MeekMark, Mikehead, Jordan Brown, Cydebot, Clappingsimon, Mblumber, Peripitus, G1234,
ST47, Gimmetrow, Thijs!bot, Epbr123, Kubanczyk, Mercury, Nick Comber, N5iln, Electron9, Java13690, Dfrg.msc, AgentPeppermint,
CharlotteWebb, Sean William, CTZMSC3, AntiVandalBot, Luna Santin, Diabolical mdog, Quintote, Ralos, DennisWithem, JAnDbot, As-
meurer, Deective, Leuko, BCube, Extropian314, LittleOldMe, Magioladitis, A12n, Freedomlinux, Bongwarrior, VoABot II, Faizhaider,
Ling.Nut, Nikevich, KJRehberg, NotACow, Jesseili, Panser Born, Khazaei.mr, Animum, MetsBot, Allstarecho, Roomoor, JMyrleFuller,
DerHexer, Lelkesa, Gwern, Stephenchou0722, Eugenwpg, Magnus Bakken, MartinBot, Ellers, Naohiro19, Speck-Made, Mark Rosen-
thal, Bryant1410, ChrisTek, LittleOldMe old, LouDogg, RockMFR, J.delanoy, Mange01, Wa3frp, Thesean43, Smite-Meister, Dispenser,
McSly, Jmajeremy, Loohcsnuf, Raise exception, Nwbeeson, Ron1947, Potatoswatter, Tearsinraine, Mpwrmnt, Gtg204y, Potaco99, Mar-
tial75, 28bytes, TreasuryTag, Onegin1, Je G., Cadby Waydell Bainbrydge, Boujois, Sergent Tooj, TXiKiBoT, GimmeBot, Java7837,
Rei-bot, T-bonham, Jeanhaney, Sintaku, Seraphim, Dendodge, JhsBot, Raymondwinn, Ohhzone, Eubulides, Iamzemasterraf, Bennythe-
boy, Michael Frind, Logan, Yaksar, SieBot, Jesdisciple, Nestea Zen, Jbmurray, RJaguar3, Yintan, Mothmolevna, LeadSongDog, Arda Xi,
Pxma, Barabuski, Dwiakigle, Oxymoron83, JDBravo, ColbertTOLDMETODOIT, Latics, Mikeisgay12345, MarkMLl, Treekids, Kalidasa
777, Emk (ja), HairyWombat, SallyForth123, Chris D Heath, ClueBot, Prohlep, The Thing That Should Not Be, WaltBusterkeys, Sandy-
Jax, Mild Bill Hiccup, Uncle Milty, Hevelius, CounterVandalismBot, Harland1, Jonathanrcoxhead, Namazu-tron, Squorky1, Alexbot,
Donaldgdavis, Tyler, Resuna, Computer97, Joeawfjdls453, Gwolf, Zoezoo, StevenDH, 9thbit, Darkicebot, XLinkBot, Hotcrocodile,
Fastily, BodhisattvaBot, Wario456, Ost316, Eric N Fischer, Mitch Ames, Skarebo, SilvonenBot, Dsimic, HexaChord, Dcanright, Ghetto-
blaster, DougsTech, Crimsunwulf, FrankGinzoFella, UnknownzD, Scientus, WorldlyWebster, Download, LaaknorBot, CarsracBot, Favo-
nian, Quercus solaris, Tide rolls, Lightbot, OlEnglish, Gail, Ilikepie00, Legobot, ZX81, Yobot, OrgasGirl, Cyanoa Crylate, 126pk, THEN
WHO WAS PHONE?, KillaDamo, Newwikiprole001, WikiWikiHacker, ZapThunderstrike, AnomieBOT, Arjun G. Menon, Rubinbot,
Aditya, Augietrautz, Mahmudmasri, Materialscientist, Citation bot, Elm-39, Tbvdm, Kriceslo, Xqbot, Gromolyak, Vegpu, Addihockey10,
Rts.bn.vs, Mono .lck, 4twenty42o, Ched, Robbgodshaw, Feldhaus, ProtectionTaggingBot, Ashershow1, Amaury, Shadowjams, A. di M.,
Giulio.orru, Coroboy, FFraenz, Soccerimp, Citation bot 1, Winterst, Pinethicket, I dream of horses, A8UDI, SpaceFlight89, DixonD-
Bot, Lotje, MarkOverton222, Kylegwot, Tbhotch, TjBot, DexDor, Salvio giuliano, Dave Cornutt, EmausBot, IAMDESU, Gimmetoo,
Slightsmile, Werieth, John Cline, F, Terr0rist333, Cobaltcigs, Wikiloop, LWChris, ClueBot NG, Matthiaspaul, Movses-bot, Giobe2000,
Codysnider, Frietjes, Spel-Punc-Gram, SirEpicMan, Widr, Helpful Pixie Bot, BG19bot, Vagobot, Kurepalaku, The Mark of the Beast,
7.11. TEXT AND IMAGE SOURCES, CONTRIBUTORS, AND LICENSES 75
Robert Moyse, MusikAnimal, Badon, BattyBot, Slapmaster3000, ChrisGualtieri, 7Keypad, Runlevel1, Dexbot, Codename Lisa, Rock-
sissor, Chrsclmn, BDE1982, SFK2, UNOwenNYC, Andyhowlett, Razibot, Lgfcd, Faizan, I am One of Many, Dairhead, Eleeeeeephan,
Kovl, Comp.arch, Glaisher, RozitaFogelman, Jianhui67, VishantG, Meteor sandwich yum, Liebfrautits, VictorLucas, EAR47, Monkbot,
Prottush, Muelleum, GH ghe, Plumbag3 and Anonymous: 710
Image le formats Source: http://en.wikipedia.org/wiki/Image_file_formats?oldid=627188859 Contributors: Zundark, Dcljr, Kierant,
AnonMoos, RickBeton, Chris 73, DavidCary, JamesHoadley, Utcursch, Keoniphoenix, GreenReaper, Rich Farmbrough, Hhielscher,
Koenige, Mancomb, Dystopos, Shenme, Teeks99, Varuna, Alansohn, Hu, Ronark, Rick Sidwell, Mikeo, Zshzn, Trevie, Phillipsacp,
AlbertCahalan, Waldir, Magister Mathematicae, Jijinmachina, Rjwilmsi, Wikibofh, Jdowland, DoubleBlue, Nihiltres, Gurch, Yurik-
Bot, Wavelength, StuOfInterest, Hydrargyrum, Cpuwhiz11, Wiki alf, Welsh, Aaron Schulz, Shotgunlee, Xpclient, FF2010, Closed-
mouth, Ketsuekigata, SmackBot, KnowledgeOfSelf, Hydrogen Iodide, KaiUwe, TFMcQ, Thunderboltz, Fitch, Pandion auk, MindlessXD,
Kslays, Gilliam, Brianski, Bluebot, Oli Filth, TheSpectator, Jerome Charles Potts, ERobson, Kitteh, Frap, Reclarke, Rrburke, Aldaron,
Ne0Freedom, AdmiralMemo, A5b, Bostwickenator, Spiritia, LSD, Peterlewis, CyrilB, Beetstra, Dicklyon, Ojan, UncleDouggie, GDal-
limore, RekishiEJ, Thatsfearagain, Davidbspalding, Karloman2, CmdrObot, Spankman, KyraVixen, Yaris678, Mdc299f, Crossmr, ST47,
Hounddog32, Jguard18, Ebichu63, Epbr123, Ultimus, N5iln, Bobblehead, Dfrg.msc, Icep, Jtmoon, MER-C, Instinct, LittleOldMe, SteveS-
ims, VoABot II, BucsWeb, Catgut, LaVieEntiere, Esanchez7587, Jackson Peebles, HotXRock, Shredder46, Petrwiki, Hodlipson, Mikael
Hggstrm, Jorfer, Stanqo, Tweisbach, Vanished user 39948282, Bonadea, Martial75, Tkgd2007, SoCalSuperEagle, Ryan032, Anna Lin-
coln, Elphion, J0EY Bukkake, Programcpp, Madhero88, Billinghurst, PeterEasthope, Dirkbb, Meters, Skarz, Jungegift, Darxus, Ben
Boldt, Tresiden, Baltimark, PookeyMaster, Oxymoron83, Jdaloner, Johnakinjr01, Bencherlite (AWB), Dillard421, Paiev, Paulinho28,
Hebbster, Kauai68, TheDooD111, HairyWombat, Loren.wilton, ClueBot, Hippo99, Digitalkiller, Senderovich, Drmies, Robmontagna,
Paulcmnt, Excirial, Anon lynx, Vanisheduser12345, Lartoven, Sun Creator, Sonicdrewdriver, NuclearWarfare, Matty0wnz, Swindbot,
ZX787, BarretB, XLinkBot, Spitre, Dlpkbr, Little Mountain 5, Skarebo, WikHead, Addbot, Legaladvantagellc, Ghettoblaster, Some
jerk on the Internet, Mabdul, Atethnekos, Blethering Scot, Jncraton, Charstiny, Chamal N, Tassedethe, Ale66, Math Champion, Yobot,
Kpharshan, AnomieBOT, Ciphers, 1exec1, Jim1138, Galoubet, Piano non troppo, Kingpin13, Halfs, Materialscientist, Gsmgm, Andrew-
916, Ched, Ubermensk, Nantucketnoon, A.amitkumar, Dougofborg, FrescoBot, Michael93555, Outback the koala, Davydoo, I dream
of horses, Quantumsilversh, Lotje, Rio98765, Jpcha2, Barry Pearson, Jerd10, EmausBot, John of Reading, Logical Cowboy, Im-
munize, Dewritech, Mo ainm, Checkingfax, Walter.Arrighetti, AOC25, Tolly4bolly, Bomazi, Davidcarroll123456, 28bot, ClueBot NG,
MelbourneStar, 123Hedgehog456, Very trivial, Widr, Antiqueight, Treyofdenmark, Be..anyone, Ankamsarav, Nospildoh, Mark Arsten,
Designer4u, Glacialfox, Klilidiplomus, JGM73, Murughendra, SergeantHippyZombie, Basemetal, TwoTwoHello, Faizan, Bughuntr, Fu-
miko Take, Jodosma, Tentinator, Airsynth, Serpinium, Sahya04, Nikmolnar, Eduardo Leal 20, XavierXerxes, Lovepercy4ever, Kisses888,
Poepkop, BethNaught, Avi0307, Patchoulol and Anonymous: 404
BMP le format Source: http://en.wikipedia.org/wiki/BMP_file_format?oldid=627641569 Contributors: Zundark, DopeshJustin, (, Al-
o, Ootachi, Aragorn2, Evercat, GRAHAMUK, Radiojon, Silvonen, Savirr, Robbot, Astronautics, Tomchiukc, Nurg, Jleedev, Alerante,
Chrisdolan, Ssd, AlistairMcMillan, OverlordQ, Aeconley, Maximaximax, Marc Mongenet, Quota, GreenReaper, R, Poccil, Jkl, Dis-
cospinster, Rich Farmbrough, Andros 1337, Qutezuce, Ardonik, Pavel Vozenilek, ESkog, Plugwash, Nabla, Theinfo, Marco255, Jpgordon,
Rodrigouf, Cwolfsheep, Dee Earley, Nk, Larry V, Minghong, Nsaa, Alansohn, Guy Harris, CyberSkull, Atlant, Keenan Pepper, RHa-
worth, LrdChaos, Rocastelo, Jacobolus, Phillipsacp, Josh Parris, Koavf, Jake Wartenberg, Flarn2006, Wackelpudding, Skyler, RobertG,
Margosbot, Gurch, Imnotminkus, Baszoetekouw, Chobot, Kjlewis, RobotE, Splintercellguy, RussBot, Serinde, Jengelh, Phlip, FTPlus,
Yuhong, Sikon, CambridgeBayWeather, Rsrikanth05, Akhristov, Wiki alf, Cquan, Bota47, Xpclient, Yudiweb, Rwxrwxrwx, Viory, Rai-
jinili, Trent Arms, DmitriyV, Oneirist, GrinBot, Teo64x, SmackBot, Incnis Mrsi, Unyoyega, Technologeist, Eidako, Eskimbot, SmartGuy
Old, JoeKearney, Thumperward, Oli Filth, Craig t moore, DHN-bot, Frap, OrphanBot, VMS Mosaic, Cmarquezu, Duckbill, Looris, War-
ren, Acdx, Vina-iwbot, ArglebargleIV, Stevenmc, Dreslough, Soumyasch, 16@r, Beetstra, Dicklyon, Anonymous anonymous, Naaman
Brown, Hiroe, Yoderj, Mdanh2002, GDallimore, Aeons, Superjoe30, CmdrObot, LarsB, WeggeBot, Cydebot, Aanderson@amherst.edu,
Verdy p, Kristian Vange, Kubanczyk, Bobblehead, Escarbot, Konman72, Gioto, Guy Macon, 100DashSix, Magioladitis, VoABot II,
Emilng, Steevm, 28421u2232nfenfcenc, MartinBot, JeromeJerome, Freeboson, Dylan anglada, BigrTex, Kimse, Adys, Lefter, Berserkerz
Crit, RenniePet, Rbakker99, Lordeaswar, Cometstyles, Dcouzin, VolkovBot, Lee.Sailer, Olafdruemmer, Je G., TXiKiBoT, Harkath-
maker, Rei-bot, Vice8641, LeaveSleaves, DieBuche, Blackjack II, Katimawan2005, Softtest123, Meters, Itamzbr, Burntsauce, Newsaholic,
Djmckee1, SieBot, Nestea Zen, Jauerback, GovernmentMan, G0dsweed, Zero2ninE, Nuttycoconut, Hatster301, Svick, JohnnyMrNinja,
WikiLaurent, Pkkao, ClueBot, Arakunem, Kanhef, Alexbot, Sun Creator, LobStoR, DanielPharos, Aitias, XLinkBot, Wikijpp, Addbot,
MrOllie, Jill-Jnn, Ginosbot, Weisebar, Lightbot, Handige Harrie, Math Champion, Yobot, AnomieBOT, Ippopotamus, Ciphers, 9258fahs-
kh917fas, Materialscientist, Felyza, Xqbot, DataWraith, Xtboris, Mydatasaver, Amaury, Vaxquis, AJCham, Kierkkadon, SwanQ, Para-
noid.android, Michelin106, Pinethicket, Tamariki, Terrorants, Jschnur, RedBot, DixonDBot, Throwaway85, Kerfue090, Stewpeas, Kev-
inrich47, EmausBot, Mellonj123, PeterJanRoes, GoingBatty, Benhut1, Wikipelli, David D Allen, Fred Gandt, 1234r00t, Wayne Slam, L
Kensington, Mattcha, ClueBot NG, Kotarou3, Verpies, Cntras, VBNetDude, Be..anyone, Helpful Pixie Bot, Tudor002, CitationCleaner-
Bot, Flipnitro, Zzarch, Mrt3366, Codename Lisa, Brandonscurtis, Teppy001, TheManOnTheWiki, Stacie Croquet, AlexBuzaev27 and
Anonymous: 290
Hexadecimal Source: http://en.wikipedia.org/wiki/Hexadecimal?oldid=627566483 Contributors: AxelBoldt, Uriyan, The Anome, Jeron-
imo, Andre Engels, Karl E. V. Palmen, Ted Longstae, PierreAbbat, SimonP, Ktsquare, Heron, Karl Palmen, Hirzel, B4hand, Spi, Ed-
ward, Patrick, RTC, D, Michael Hardy, Tenbaset, Liftarn, Wapcaplet, AlexR, Lament, TakuyaMurata, Eric119, Minesweeper, Alo, Egil,
Ahoerstemeier, Cyp, Haakon, Mac, J'raxis, Angela, Glenn, IMSoP, Kaihsu, Palfrey, Hpa, Dcoetzee, Paul Stansifer, Doradus, Furrykef,
Omegatron, Bevo, Raul654, Pakaran, BenRG, Robbot, Fredrik, Huppybanny, Chris 73, R3m0t, RedWolf, Calmypal, Rorro, Adhemar,
Mendalus, Wereon, Saraphim, Robbe, Giftlite, Marnanel, Jao, Kim Bruning, Fudoreaper, Binadot, Curps, Mellum, Pascal666, The zoro,
VampWillow, Golbez, Vadmium, Noe, Beland, MarkSweep, Quarl, Aulis Eskola, Wzwz, Elektron, Pmanderson, Zfr, Biot, Nickptar,
Arosa, Uaxuctum, Jh51681, Thorwald, Mike Rosoft, Freakofnurture, Slady, JTN, Chris j wood, Discospinster, Rich Farmbrough, NrDg,
Inkypaws, Wrp103, Paul August, ESkog, Andrejj, Plugwash, CanisRufus, Livajo, Bobo192, John Vandenberg, Mtruch, Unused0022,
Jerryseinfeld, Obradovic Goran, Wayfarer, Poweroid, Alansohn, Barium, Sligocki, Malo, Bart133, Blobglob, Munthe, Super-Magician,
ReyBrujo, Paul Martin, Alfvaen, BlastOButter42, DV8 2XL, Gene Nygaard, Forderud, Oleg Alexandrov, A D Monroe III, Kelly Martin,
Woohookitty, Linas, 25or6to4, Guy M, Tripodics, Splintax, MattGiuca, Trevorparsons, Waldir, Havarhen, Gniw, Gerbrant, Graham87,
Magister Mathematicae, TAKASUGI Shinji, Kbdank71, JIP, Zzedar, Josh Parris, Sjakkalle, Peter 2005, SMC, Concordia, Nicolas1981,
Kevmitch, MatthewMastracci, StuartBrady, FlaBot, Radix, Mathbot, Nihiltres, Vsion, Rbonvall, Nimur, DarthGanon, Srleer, Glenn
L, PZ, Chobot, Bornhj, DVdm, Bgwhite, Nominaladversary, YurikBot, Alethiareg, Daverocks, Mythsearcher, Stephenb, Rintrah, David
Woodward, Pseudomonas, Wimt, NawlinWiki, Anomie, Wiki alf, Msikma, FrankHamersley, Keka, Jndrline, Ezeu, Ttam, FlyingPenguins,
Wknight94, Light current, Tcsetattr, Rfsmit, Arthur Rubin, JoanneB, MathsIsFun, GrinBot, Aforencich, robot, SmackBot, Light-
minute, Ashenai, KMcD, Incnis Mrsi, Prodego, J7, KocjoBot, Guyalsfere, Aaron of Mpls, Anwar saadat, Chris the speller, MK8, Oli Filth,
EncMstr, MalafayaBot, Match 213, SchftyThree, DHN-bot, Cassivs, Colonies Chris, Starbuck-2, Modest Genius, Can't sleep, clown will
eat me, Pkchan, Rrburke, Thrane, Triviator, Jiddisch, MichaelBillington, Shadow1, DylanW, Drphilharmonic, Maelnuneb, Quarkington,
Luigi.a.cruz, LeoNomis, Kukini, HYC, SashatoBot, StuartMurray, Fubaz, Errorx666, Attys, Gandalf44, Kuru, Cronholm144, Nharipra,
Masciare, Minna Sora no Shita, Meco, GorillazFanAdam, Stephen B Streater, Norm mit, Gclinkscales, Yksyksyks, Tony Fox, Courcelles,
Tawkerbot2, Gco, Daggerstab, Irwangatot, Stmrlbs, IntrigueBlue, HenkeB, Vwollan, Hibou8, Chrislk02, Bufdaemon, UberScienceNerd,
Thijs!bot, Tomasf, Reswobslc, Scottmsg, AgentPeppermint, Escarbot, Hmrox, AntiVandalBot, Majorly, Chubbles, Opelio, Scepia, Dark-
lilac, Myanw, MER-C, IanOsgood, Leotolstoy, Acroterion, Magioladitis, Bongwarrior, VoABot II, A4, Swpb, Think outside the box, Tr-
ishm, Pausch, Alekjds, David Eppstein, Timmeh77, Thibbs, DerHexer, JaGa, Rettetast, Mschel, Defproc, Robert, Mausy5043, Sege1701,
J.delanoy, Pharaoh of the Wizards, Carre, Tikiwont, Extransit, OKeh, Unkx80, Spyforthemoon, S91by, Rwessel, Hanacy, Cometstyles,
Equazcion, Paulmmn, MBerrill, SoCalSuperEagle, RJASE1, VolkovBot, Dzogchenpa, Terrybots, TobyDZ, BlakeCS, Philip Trueman,
Fran Rogers, TXiKiBoT, TwilligToves, Elphion, JhsBot, Don4of4, Broadbot, Memorized128, Belamp, Ricardo Cancho Niemietz, AJRob-
bins, James175, Masterofpsi, EmxBot, TheStarman, Jur123, The Mysterious Gamer, SieBot, Weeliljimmy, Corpcon, Jerryobject, Android
Mouse, Radon210, Exert, Mooiehoed, AlexWaelde, Chridd, Waylonbutler, Trang Oul, Oxymoron83, Smaug123, Techman224, BenoniBot,
Divineword, , Felixaldonso, Tomdobb, Beou, Shishirmital, ClueBot, Bernard Ladenthin, CloneDeath, The Thing That Should
Not Be, Wysprgr2005, Wutsje, AirdishStraus, Hauptmech, Idex76, DragonBot, Panchoy, Copyeditor42, Excirial, Mate2code, Zac439,
Hans Adler, M.O.X, LobStoR, Thingg, Versus22, PCHS-NJROTC, Johnuniq, Cool halo 2, MarmotteNZ, Dr.Luke.sc, BodhisattvaBot, Jo-
vianeye, SilvonenBot, Jlcoving, Dmillard10, Wyatt915, Addbot, Ghettoblaster, Some jerk on the Internet, Wickey-nl, Lanukkunal, Henkt,
AndersBot, AnnaFrance, Quercus solaris, Fireaxe888, Tassedethe, Numbo3-bot, Sdoking, AndreCapaGarcia, Tide rolls, , Luckas-
bot, Yobot, Bunnyhop11, Ptbotgourou, The Grumpy Hacker, THEN WHO WAS PHONE?, Terrorist of bush, AnomieBOT, The Son of
Man, Rubinbot, Aditya, Phluid61, GB fan, Xqbot, Gindar, Rts.bn.vs, Bodinagamin, Wizardist, RibotBOT, Douglas W. Jones, Jvr725, Sesu
Prime, Rnno, Nageh, Dantheman4114, StaticVision, BenzolBot, Robo37, Moonwolf24, Pinethicket, Elockid, Calmer Waters, RedBot,
Meaghan, Double sharp, Lotje, Specs112, Fastilysock, Bearboat, Nucleosynthesis, Elium2, EmausBot, Gfoley4, Ajraddatz, N, Psr12,
Splibubay, Quondum, Ae.davies1992, Easyguyevo, Donner60, Gcjdavid, 28bot, Petrb, ClueBot NG, Nateho, Matthiaspaul, DarkJXD, Joel
B. Lewis, Kluonius, BG19bot, Roberticus, Duoservo, DookieDungeon, Mr.briancochran, HTML2011, Aisteco, Oalders, Indiana State,
Thewikicontributor, Spectral sequence, Lugia2453, Isarra (HG), SFK2, Smart people USA, Hamerbro, Epicgenius, FrigidNinja, Chewie
Enterprises, Bellteda, -1, Justabeginner, BlitzGreg, Trax support, Lich counter, Hatem Khattab and Anonymous: 589
JPEG Source: http://en.wikipedia.org/wiki/JPEG?oldid=626079782 Contributors: Damian Yerrick, AxelBoldt, Derek Ross, Zundark,
The Anome, Tarquin, Alex, Ted Longstae, William Avery, Ben-Zin, Hannes Hirzel, Mjb, Heron, B4hand, Frecklefoot, Edward, Bde-
sham, D, Michael Hardy, Graue, (, Ahoerstemeier, Haakon, Stevenj, Nanshu, Glenn, Llull, Rl, Rob Hooft, Crissov, Timwi, Dcoetzee,
Ed Cormany, Stone, Tpbradbury, E23, Furrykef, RayKiddy, Ed g2s, Francs2000, Donarreiskoer, Robbot, Ke4roh, Hankwang, Wanion,
Astronautics, Psychonaut, Academic Challenger, Rursus, Roscoe x, Bkell, Wikibot, Michael Snow, Garrett Albright, Kostiq, Lupo, Su-
perm401, Filemon, Pabouk, Giftlite, Dbenbenn, Smjg, DocWatson42, Ksheka, ShaunMacPherson, Inkling, BenFrantzDale, Lisbk, Flem-
inra, Markus Kuhn, JamesHoadley, Ssd, Daniel Brockman, Xorx77, Spe88, Jmcnamera, Neilc, Tom k&e, Chowbok, Toytoy, Slowk-
ing Man, Antandrus, OverlordQ, MarkSweep, Kaldari, Marc Mongenet, Zfr, Timothy57, Willhsmit, Porges, Mike Rosoft, Mormegil,
Perey, ChrisRuvolo, Freakofnurture, Imroy, Slady, Bruzie, Discospinster, Rich Farmbrough, Lmcgign, Qutezuce, Notinasnaid, Samboy,
Horkana, Mani1, KaiSeun, Hhielscher, Bender235, ZeroOne, Kbh3rd, Kjoonlee, JoeSmack, Plugwash, Syp, Kaszeta, *drew, Edwin-
stearns, Kwamikagami, Shanes, Causa sui, David Crawshaw, Longhair, Fir0002, Dee Earley, Mathieu, SpeedyGonsales, Alphax, Pho-
tonique, Sleske, Minghong, Foxandpotatoes, Jumbuck, Danski14, Alansohn, Guy Harris, Interiot, Arthena, CyberSkull, AzaToth, Hino-
tori, Goldom, Antialias, PAR, Dschwen, ProhibitOnions, Rick Sidwell, Cburnett, Gpvos, Mnemo, Vuo, H2g2bob, Mattbrundage, Bruce89,
STrRedWolf, Stuartyeates, Alkarex, TigerShark, Bryan986, LOL, Rocastelo, Sburke, Guy M, Phillipsacp, WadeSimMiser, Eyreland,
Simsong, Karam.Anthony.K, Brownsteve, Allen3, Audiodude, Pawnbroker, Mandarax, Graham87, Kbdank71, Jclemens, Mulligatawny,
Jshadias, Rjwilmsi, Koavf, Strait, Arisa, TeemuN, ATLBeer, Alejo2083, FlaBot, WWC, Musical Linguist, Lawrencegold, Loggie, Nivix,
Rune.welsh, RexNL, Gurch, Nimur, Alphachimp, Chobot, DVdm, Bgwhite, Adoniscik, Gwernol, YurikBot, Wavelength, Klingoncow-
boy4, Crotalus horridus, Xcrivener, Huw Powell, Jimp, Charles Gaudette, Brandmeister (old), Fabartus, Muchness, Piet Delport, Groogle,
Cancan101, Stephenb, Gaius Cornelius, Rsrikanth05, Akhristov, Wimt, FelixH, NawlinWiki, Aeusoes1, Janke, Grafen, Trademarx, Daniel
Mietchen, Zwobot, Xompanthy, Shotgunlee, DeadEyeArrow, Xpclient, Ghclark, Wknight94, Superdood, Mugunth Kumar, Zzuuzz, Viory,
KGasso, DGaw, JoanneB, Ian Fieggen, DmitriyV, Ilmari Karonen, RG2, Amit man, Cmglee, Finell, AndrewWTaylor, Benhoyt, A bit iy,
RupertMillard, SmackBot, Eugen Dedu, Slashme, KnowledgeOfSelf, McGeddon, Blue520, WookieInHeat, Timeshifter, Alsandro, Slo-
man, Brianski, TRosenbaum, ERcheck, Wookipedian, Kurykh, MK8, Oli Filth, Alexwagner, Toybuilder, Jerome Charles Potts, Nbarth,
Kostmo, DHN-bot, Konstable, Audriusa, Can't sleep, clown will eat me, Frap, Neo139, Berland, Gnp, GeorgeMoney, UU, Calbaer, Cr-
boyer, Cybercobra, Khukri, Dream out loud, Warren, Mayank geek, Daniel.Cardenas, Mchavez, Ozhiker, Soumyasch, Jcoy, Brett.donald,
Feraudyh, Pedantic of Purley, Beetstra, Boomshadow, Jmgonzalez, Dicklyon, Larrymcp, GilbertoSilvaFan, Waggers, Tendim, H, Yoderj,
Skabraham, Peter M Dodge, JoeBot, Newone, Twas Now, Aeons, Mikay, Tawkerbot2, Harold f, JForget, Ale jrb, Tamarkot, Jesse Vi-
viano, Green caterpillar, NickW557, Requestion, Grammaticus Repairo, Gogo Dodo, Llort, Chasingsol, Paul Heckbert, Quibik, Cgrenier,
Kozuch, Omicronpersei8, Thijs!bot, Epbr123, Jedibob5, N5iln, Dtgriscom, Marek69, Bobblehead, Electron9, Michael A. White, No-
bar, Escarbot, AntiVandalBot, Luna Santin, Seaphoto, Fru1tbat, Farosdaughter, Myanw, Eleos, MikeLynch, JAnDbot, Almwi, Dogru144,
Deective, MER-C, PhilKnight, HAl, LittleOldMe, Steveprutz, Dakusan, SteveSims, Benstown, VoABot II, Rajb245, Clivestaples, Nyq,
Yevgeniwebmaster, Biker JR, JNW, WODUP, Kriegae, Elliotbay, Fabrictramp, WhatamIdoing, Glen, Chris G, Stolsvik, AVRS, Martin-
Bot, Andewulfe, Graham101, NAHID, Nikpapag, Seandylanw, Speck-Made, Mschel, J.delanoy, Kimse, Trusilver, AltiusBimm, 06109599,
AlexMld, Dispenser, Ncmvocalist, L'Aquatique, Compact disk, Plasticup, NewEnglandYankee, Shoessss, 2help, Ja 62, Rickyrazz, Tuxick,
Reelrt, Pegase, Timotab, TCMike, Epson291, TXiKiBoT, GDonato, Nxavar, CoJaBo, Milkcrate, LeaveSleaves, Mamuf, Mwilso24, Me-
ters, Falcon8765, Jakub Vrna, Balko Kabo, Ish rishabh, Ben Boldt, Lonwolve, Joe4440, Gaelen S., Manning james, AlphaPyro, Euryalus,
Gerakibot, Tardis5923, Zardragon1, Flyer22, Anow2, Oxymoron83, Yswismer, Rhsimard, Anakin101, Tree Kittens, Kauai68, Escape Or-
bit, C0nanPayne, Emk (ja), Sanao, Church, Martarius, Elassint, ClueBot, GorillaWarfare, XenonofArcticus, Lonelyprogrammer264, The
Thing That Should Not Be, Chocoforfriends, Techdawg667, Jan1nad, Lawrence Cohen, Ndenison, Wysprgr2005, Timbo76, Smrti18, Lego-
cool, Alexbot, M4gnum0n, Rcooley, Jamesedwardlong, NuclearWarfare, Ca michelbach, ChrisHodgesUK, AbJ32, Aitias, DumZiBoT,
XLinkBot, Yangez, Wikiuser100, Amarrajsingh, Mifter, Dekart, Badgernet, Cortega, Deineka, Addbot, Ghettoblaster, Henry.guillotine,
Fernsalan, MrZoolook, Shervinemami, Justanemokid, Jncraton, CanadianLinuxUser, MrOllie, Demkop, Favonian, West.andrew.g, 5 al-
bert square, Hussainsab100, 84user, Lightbot, Meisam, Boardersparadise, Tohd8BohaithuGh1, Ptbotgourou, Carminox, Gobbleswog-
gler, ArchonMagnus, Kcacciatore, AnomieBOT, Andrewrp, 1exec1, Justme89, Wuyongzheng, Mrbobotron, Xqbot, Lmitchell6, Andrew-
916, Jerey Mall, HannesP, Lilllian76, Prunesqualer, ToraNeko, Shadowjams, FrescoBot, Kkj11210, Fbrazill, Nicoontheweb, Mfwitten,
Pinethicket, Tamariki, SpaceFlight89, Funkybearman, RobinK, Full-date unlinking bot, SchreyP, Lotje, Rixs, Cheng chai fung, Athaba,
Miracle Pen, MisterPook, DARTH SIDIOUS 2, Mean as custard, Deityguns, Jeherve, LightStarch, Noname58, DASHBot, 3-5 le, Emaus-
Bot, John of Reading, Joesehpwilliam, Mk dexter, Bdijkstra, Nuujinn, Greypyjamas2, Wikipelli, Lucas Thoms, Max theprintspace, Luna-
gron, AvicBot, Kzl.zawlin, Davidolivan, JamesGeddes, Palashrijan, Tristaess, , Xboxmaster17, Reim, FalseAlarm, Kevjonesin,
Sbmeirow, Atcold, Bogdinamita, Bomazi, Generalnat2, Richgel999, CharlieEchoTango, ClueBot NG, Gareth Grith-Jones, Jack Green-
maven, Kangdang, Widr, Be..anyone, Helpful Pixie Bot, HMSSolent, BG19bot, Walrus068, PhnomPencil, Pitzik4, Frze, Onewhohelps,
Atl123, Bahersabry, Conifer, Fylbecatulous, WP Randomno, Nfvr, Geyserit, Tjb777, Khazar2, Ornicks, JYBot, Fyodorser, SarahPalmer-
son, Mogism, Jogfalls1947, Kulandru mor, Kitsurenda, Loopylo2000, Caspar Cedro, Lethosor, Comp.arch, Enderchestfrantic, LauraALo,
ScienceRandomness, DudeWithAFeud, Itmanve, Norasisl, Hollyrood and Anonymous: 684
Graphics Interchange Format Source: http://en.wikipedia.org/wiki/Graphics_Interchange_Format?oldid=627565151 Contributors:
Damian Yerrick, Tuxisuau, Bryan Derksen, Zundark, Tarquin, Stephen Gilbert, Koyaanis Qatsi, Andre Engels, Jrincayc, Toby Bartels, Kurt
Jansson, Maury Markowitz, Mjb, Hirzel, Dwheeler, Olivier, Ubiquity, Patrick, Michael Hardy, Kwertii, Dante Alighieri, Menchi, Ixfd64,
Chinju, Ellywa, Ahoerstemeier, Haakon, Nanshu, Ciphergoth, Scott, IMSoP, Evercat, Mxn, Ilyanep, Pipian, Emperorbma, Popsracer,
RodC, Guaka, Timwi, Dcoetzee, Nohat, AC, Andrewman327, DJ Clayworth, ThomasStrohmann, E23, Furrykef, Saltine, AnonMoos,
BenRG, Pollinator, Cluth, Robbot, Ktims, Caroig, RedWolf, Dittaeva, Psychonaut, Chris Roy, Elysdir, Bkaindl, Lupo, Xanzzibar, Cyrius,
Superm401, Pengo, Unfree, David Gerard, Giftlite, DocWatson42, Jthiesen, var Arnfjr Bjarmason, Ssd, BillyH, Jason Quinn, Siroxo,
Xorx77, Falcon Kirtaran, Darrien, Yath, Sonjaaa, LucasVB, Fangz, Beland, OverlordQ, MarkSweep, Jossi, Marc Mongenet, Sam Hoce-
var, Asbestos, Jcw69, Quota, Neale Monks, Louisisthebest 007, Mmj, M1ss1ontomars2k4, Zondor, Porges, Mike Rosoft, Jwolfe, Poccil,
Imroy, Discospinster, Rich Farmbrough, Fortmac, Shevett, Mjpieters, Altmany, Bender235, Spinal83, Kbh3rd, Kaisershatner, Nwallins,
Plugwash, BACbKA, Evice, BlueNight, *drew, J-Star, Joanjoc, Kwamikagami, RoyBoy, BrokenSegue, Shlomital, Kjkolb, Zetawoof,
Minghong, Pearle, Nsaa, Bigtrick, Alansohn, CyberSkull, Nealcardwell, Andrewpmk, AzaToth, Wangry, Ciaran H, Fergie, Ynhockey,
Pion, DavidCWG, Aranae, Wtmitchell, Ronark, Paul1337, ReyBrujo, Stephan Leeds, Mikeo, LiquidXY, MIT Trekkie, Dwiki, Dtobias,
Ron Ritzman, Stuartyeates, Madmardigan53, Camw, Rocastelo, Sburke, MiaowMiaow, Reinier Jonker, Phillipsacp, WadeSimMiser, SDC,
Doco, Karam.Anthony.K, Palica, Mandarax, Graham87, El Mariachi, Magister Mathematicae, Bforte, Rjwilmsi, Mfwills, Arabani, Wah-
keenah, Ulillillia, NeonMerlin, Brighterorange, Ravik, Utuado, Husky, STDestiny, FlaBot, Splarka, Arnero, Undeference, Mindfrieze,
Gurch, KFP, Ahunt, Daev, Chobot, DVdm, Metaeducation, Klingoncowboy4, Crotalus horridus, Pburka, Aaron Walden, Hydrargyrum,
Sikon, Pseudomonas, Ugur Basak, Big Brother 1984, NawlinWiki, Duran, Irishguy, Brandon, RUL3R, Mgcsinc, Jepower, Syrthiss, Izaak,
Xpclient, Mxcatania, Sandstein, Mercury1, Zzuuzz, Ageekgal, Closedmouth, Moogsi, E Wing, GraemeL, JoanneB, Andyluciano, Flow-
ersofnight, DmitriyV, Ilmari Karonen, Archer7, NeilN, Anonymous-san, Ufoolme, Mussnoon, Chris Chittleborough, TravisTX, Veinor,
SmackBot, Nihonjoe, Estoy Aqu, RickMeasham, The Gerg, Unyoyega, Zyxw, BiT, Edonovan, Shai-kun, Gilliam, Portillo, Ohnoitsjamie,
Quadratic, MK8, Stubblyhead, MalafayaBot, OrangeDog, The Rogue Penguin, Nbarth, Kostmo, Audriusa, Can't sleep, clown will eat
me, CharlesJS, Lacker, Reclarke, VMS Mosaic, GeorgeMoney, Khoikhoi, Doodle77, CapitalFirstLetter, Wybot, Viking880, Vina-iwbot,
Vasiliy Faronov, Mike Richardson, L337p4wn, Akira Tomosuke, Marfresbo, Benreynolds4, Ben Moore, Monni95, Basmandude, Ace
Class Shadow, Sharcho, Rip-Saw, Loulaughlin, EdC, Big Smooth, Uwe W., Hu12, Norm mit, JeW, Iridescent, Harlekeyn, Newone,
Erick295, GDallimore, Cherry Cotton, Jestix, Tawkerbot2, George100, Godgundam10, Thud495, JForget, Linuxerist, R0, Cmdr Adeon,
Dgw, DannyKitty, OMGsplosion, Wratmann, RufusW, Gogo Dodo, Tawkerbot4, Surturz, Btharper1221, Landroo, Jono4174, Thijs!bot,
Epbr123, Marek69, John254, A3RO, Zachary, Navdar, Dzubint, Big gun, AntiVandalBot, Luna Santin, Guy Macon, Jasoneppink, Olexandr
Kravchuk, Dylan Lake, Chill doubt, Dybdal, Gwengoat, Deective, MER-C, Arch dude, Belg4mit, Sitethief, PhilKnight, Patrick Maitland,
Magioladitis, VoABot II, Timhood, Yandman, Maverick34, JamesBWatson, Culverin, AsgardBot, Allstarecho, Styrofoam1994, Benkel-
ley, .*, DerHexer, Esanchez7587, Hbent, Hdt83, MartinBot, NatalyaAF, Speck-Made, R'n'B, CommonsDelinker, Vorratt, Kimse, Hans
Dunkelberg, Mike.lifeguard, Maproom, Andareed, Kippek, Pyrospirit, Noahcs, AntiSpamBot, NewEnglandYankee, Mattygabe, Yamex5,
Knulclunk, Taylor250, Motter, Hanacy, Cometstyles, Remember the dot, Paulmmn, VolkovBot, TallNapoleon, AlnoktaBOT, TheOther-
Jesse, Philip Trueman, Fran Rogers, Gwenh, PGSONIC, Cherryplumtree121, Myspaceman, Nxavar, Jeanhaney, Elphion, Slysplace, Man-
nafredo, Cuddlyable3, LongGoneVista, Silenceisvilence, Jamelan, Bitbut, Logan, Austriacus, Aldo.medri, Benoitr007, SieBot, TJRC,
Nubiatech, Dnedrow, Gerakibot, Mungo Kitsch, Girl.at.bat, Caltas, X-Fi6, Calabraxthis, Poohead121, Yamenah, Keilana, Theaveng,
Zurqoxn, Oxymoron83, Nuttycoconut, Hello71, Onebadtown, Svick, Spitre19, Spartan-James, Stieg, Anchor Link Bot, AutoGyro, Denis-
arona, Matt72ny, Martarius, ClueBot, Owczi, Pommyjosh2, Ohmygodeven, The Thing That Should Not Be, RvLeshrac, Lawrence Cohen,
Harland1, Malibuswanted, DragonBot, Excirial, Alexbot, Mate2code, Resoru, Mikoleg, Estirabot, SimonJ1990, Resonate one, Stoo,
Iohannes Animosus, Kaiba, Dekisugi, MPeller, Ottawa4ever, Thingg, Ubardak, Johnuniq, DumZiBoT, FrickaFricka, Salamangkero,
Sftpbr, Dthpsc, Rigby27, Frood, Badgernet, Gifanimations, RyanCross, ForeverFreeSpeech, Tony22tony, Addbot, Some jerk on the In-
ternet, Ronhjones, OBloodyHell, Fieldday-sunday, Ethanpet113, Scientus, Fluernutter, SpillingBot, Eivindbot, Chestranch, AtheWeath-
erman, Jasper Deng, Tide rolls, Lightbot, Zorrobot, Jarble, Legobot, Luckas-bot, Yobot, Ptbotgourou, Jannic86, Lovingruby951, Swis-
terTwister, MichaelMcKitt2011, 20I.170.20, Suppjcs, AnomieBOT, Jim1138, Kingpin13, Materialscientist, Jellystones, Xqbot, Capri-
corn42, The Magnicent Clean-keeper, TechBot, Mi703, Martnym, The MP, Kinginthecorner, Maxtaurus1, Pmlineditor, Frankie0607,
Optimiced, SassoBot, Amaury, Samkay64, Piccolist, Selvasoft2003, BartomiejB, RicHard-59, Aleksa Lukic, Fbrazill, Rahul Sapre, Di-
vineAlpha, HamburgerRadio, 51l3n7, Tamariki, HRoestBot, Soldiers of Filth, Ngyikp, RedBot, SpaceFlight89, Niri.M, Gif2png, Al-
doaldoz, Lotje, Vrenator, Begoon, Wo.luren, Flash Ahhh!, Superhero22, DARTH SIDIOUS 2, RjwilmsiBot, NameIsRon, Arctic Mugi-
wara, Joesehpwilliam, Dewritech, Racerx11, RA0808, Wikipelli, K6ka, Lucas Thoms, AvicBot, Theoceprankster, Allforrous, Treer,
ArachanoxReal, Tolly4bolly, Thine Antique Pen, Mlschafer, Pun, Morderwurst, ClamDip, Senator2029, ClueBot NG, Gareth Grith-
Jones, MelbourneStar, Shaddim, Skoot13, O.Koslowski, Johnlikestoread, Widr, Antiqueight, Deep Thought, Techpodusa, Helpful Pixie
Bot, Novusuna, Bwoebi, Som999, Robk19966, Backfrontside, U40U50U60, Northamerica1000, Fannieo, Wiki13, Frze, Mark Arsten,
Onewhohelps, DPBT1, Cncmaster, Wowowowowowo, Merritttttt, Gzbernini, Guanaco55, Tutelary, Miszatomic, Pratyya Ghosh, Mdann52,
Timothy Gu, Khazar2, EuroCarGT, Maccompatible, PurplePieman, Nouniquenames, Mogism, Andrevac96, Lugia2453, Jamesx12345,
Lolo Lympian, Sriharsh1234, Joshua J Davies, Motherfricker, Spencer gibson, Corn cheese, MisterShiney, Thomathompson, Epicgenius,
UrbanDragon 33, Harmione, DreadRed, Jodosma, Mattram, Krotov maksim, Amnixiel, Flat Out, LarsGoogol, Comp.arch, Andrewgrohs,
Grecfest, Naomitwin, ParamMudgal, Goncalor, Spartanninja77, Editani, Kharlomach, Meemo16, Thedaydreamdragon, Swagmasta221b,
Thelegendthatwalks, Song il guk, Com9000, Cfaiith 98, RajeshMCIT, Valfontissucks, QuartzReload, Theman4815162342, Billy Fusco,
Tblake87 and Anonymous: 804
Portable Network Graphics Source: http://en.wikipedia.org/wiki/Portable_Network_Graphics?oldid=626994778 Contributors: Damian
Yerrick, The Epopt, Lee Daniel Crocker, Eloquence, Zundark, Tarquin, Taw, Mark, Youssefsan, XJaM, Ben-Zin, Mjb, Dwheeler,
Twilsonb, Patrick, AdSR, Bewildebeast, Menchi, Sannse, TakuyaMurata, Delirium, Minesweeper, Alo, Ahoerstemeier, Nanshu, Jd-
forrester, Julesd, Whkoh, Tobias Conradi, Mxn, Tomv, Hashar, Mulad, Emperorbma, Crissov, Dcoetzee, E23, Furrykef, Grendelkhan, Ed
g2s, Bevo, Stormie, AnonMoos, Jamesday, Robbot, Ruinia, Noldoaran, Fredrik, R3m0t, Peak, Lowellian, Stewartadcock, Qwm, Engerim,
Superm401, Tobias Bergemann, Peterklevy, Giftlite, Gwalla, Dbenbenn, Smjg, DocWatson42, DavidCary, Dinomite, Nichalp, Lupin, Zig-
ger, Leyman, Curps, Ssd, Behnam, Proslaes, Edcolins, Vadmium, Decoy, Keith Edkins, Aside, Gdr, Bgraabek, LucasVB, OverlordQ,
Quarl, Tim Pritlove, Cynical, B.d.mills, Ojw, Quota, BeakerK44, Zondor, Leonbloy, Eisnel, Ericg, SimonEast, Perey, Freakofnurture,
Rich Farmbrough, Hydrox, Pmsyyz, Qutezuce, Rspeer, Ardonik, Smyth, Dave souza, Notinasnaid, D-Notice, AlanBarrett, Hhielscher,
Gronky, Sbo, Night Gyr, Bender235, ZeroOne, MattTM, Yinon, Plugwash, Elwikipedista, Evice, Philip6854, Purplefeltangel, Kwamik-
agami, RoyBoy, PatrikR, Nigelj, Reinyday, John Vandenberg, R. S. Shaw, Foobaz, Sriram sh, Shlomital, Bawol, WikiLeon, Minghong,
Pearle, Jakew, Qwe, Arthena, CyberSkull, Andrewpmk, Ronline, Minority Report, Lightdarkness, Apoc2400, Cdc, DreamGuy, Aranae,
Ronark, Paul1337, Gpvos, H2g2bob, Kazvorpal, Cristan, Kbolino, Falcorian, Patrick T. Wynne, MickWest, NantonosAedui, Simetrical,
Beanluc, Sburke, Miaow Miaow, Jacobolus, Phillipsacp, MattGiuca, Scjessey, Pol098, Riumplus, Eyreland, Zzyzx11, Gerbrant, Marudub-
shinki, Graham87, David Levy, DePiep, Reisio, Jshadias, Pmj, Rjwilmsi, Jsled, Arabani, Loudenvier, Himasaram, Gudeldar, Kazrak,
Morbid-o, Brighterorange, Kurt, FlaBot, Crazycomputers, DuLithgow, BjKa, Bmicomp, Chobot, Bgwhite, WriterHound, Kjlewis, Yurik-
Bot, Klingoncowboy4, RattusMaximus, Pile0nades, Crotalus horridus, Todd Vierling, Charles Gaudette, Jtkiefer, Lexi Marie, Splette,
Rapomon, Amanaplanacanalpanama, Sikon, Wimt, Ugur Basak, Hm2k, Mipadi, Falling Cloud, Test-tools, Chick Bowen, Emfraser, Di-
rectEON, Saoshyant, Caiyu, Matthew0028, EEMIV, Snarius, DeadEyeArrow, Tmichie, Xpclient, Max Schwarz, Mxcatania, Analogue-
dragon, Jecowa, CWenger, Ian Fieggen, JLaTondre, DmitriyV, Smurfy, Heresiarch, KJBracey, GrinBot, Cyber Dog, NetRolller 3D, Chris
Chittleborough, Burton Radons, Jsnx, SmackBot, Unyoyega, Technologeist, Delldot, Ajm81, Timeshifter, AnOddName, Boris Barowski,
Whollabilla, Lorian, Dioxaz, Matt0401, Robert Wellock, Simon123, MalafayaBot, Mr Poo, Tigerhawkvok, Jerome Charles Potts, ERob-
son, Nbarth, EdgeOfEpsilon, Omniplex, DHN-bot, KieferSkunk, Ado, Simpsons contributor, Jereyarcand, Mihai Capot, Yaf, TheGerm,
Frap, Ultra-Loser, VMS Mosaic, GeorgeMoney, Cybercobra, Mr Minchin, DoubleAW, DylanW, IE, Last Avenue, Doodle77, Mwtoews,
Compnerd, SashatoBot, Kuru, Hannes Agnarsson Johnson, Wissons, Soumyasch, Alpha Omicron, Masiano, Beetstra, Tiji, Ro, Rjgibb,
Dicklyon, Larrymcp, Ace Frahm, Bookish, JeW, JoeBot, J Di, GDallimore, TherstM, FIshstick, Trialsanderrors, FatalError, JForget,
DJPhazer, KX36, Feinorgh, Gavin Compton, ShelfSkewed, Requestion, Cydebot, Blicher, Aanderson@amherst.edu, Luckyherb, Strom,
Kwaku, GangstaEB, Akadewboy, Thijs!bot, Wikid77, Jastern949, Wermlandsdata, GentlemanGhost, N5iln, Bobblehead, Libertyernie2,
Escarbot, Mr MaRo, Peashy, Trlkly, AntiVandalBot, Luna Santin, Lovibond, Labongo, Jaredroberts, JAnDbot, Deective, Arch dude,
Gavia immer, Jahoe, Vituperex, SteveSims, Magioladitis, VoABot II, A4, Ff1959, Scowie, Conteordeo, CountingPine, Rugops, Arz1969,
Glen, Jpo51, Kayau, Gwern, Speck-Made, R'n'B, Dubrict, Vorratt, J.delanoy, Jesant13, Yonidebot, HotWheels53, Roelofs, Arite, Nemo bis,
Doug4, TottyBot, Althepal, KylieTastic, Joshua Issac, Remember the dot, Flatscan, Dozen, Bonadea, Marc Esnouf, Idioma-bot, Funandtrvl,
VolkovBot, LokiClock, Philip Trueman, Hqb, Rei-bot, GrahamStw, Jeanhaney, Elphion, Billinghurst, Peu, Rwell3471, Burntsauce, AP61,
Wikisuper, Mikemoral, Avayak, K. Annoyomous, VVVBot, Rmunn, Nemo20000, I Love Pi, Jerryobject, DaBler, Lightmouse, Svick,
JohnnyMrNinja, Vundicind, Denisarona, ImageRemovalBot, ClueBot, Brian lindholm, The Thing That Should Not Be, Glennrp, Funky-
WhiteBlood, Jrettgraphics, Mitchman1411, TheAmigo42, Niceguyedc, Yk4ever, DragonBot, Excirial, Mate2code, PixelBot, RedYeti,
Chininazu12, LobStoR, Skunkboy74, XLinkBot, Saeed.Veradi, Odoepner, Dekart, ZooFari, REA002, CalumH93, Addbot, Ghettoblaster,
TutterMouse, Maschelos, Scientus, Ismouton, Jim10701, MrOllie, 84user, Lightbot, Zorrobot, , Luckas-bot, Yobot, Ptbotgourou,
Bryan.burgers, Stummee, AnomieBOT, Ippopotamus, Ciphers, Jim1138, Picasticks, Materialscientist, NirajBhawnani, Suit, Neurolysis,
ArthurBot, Xqbot, Melmann, Yumeyao, DSisyphBot, Explorer09, Tyrol5, Xorxos, PeaceLoveHarmony, Smallman12q, Oehr, Urgos, Rom-
nempire, Fbrazill, Recognizance, Ankit1 nagpal, Ehoeks, DivineAlpha, Paranoid.android, Citation bot 1, Tamariki, HRoestBot, Jusses2,
Dcwaterboy, RedBot, le ottante, Banej, Tim1357, DixonDBot, Dark Lord of the Sith, Lotje, Thelennonorth, Pilk, Perhelion, EmausBot,
Mellonj123, Hdu hh, Bettymnz4, Marioandangel, Wikipelli, Ida Shaw, Shuipzv3, Tajymoid, Sonic12228, 12b3, Tolly4bolly, WalterTross,
CasparCG, Iketsi, Senator2029, Rocketrod1960, Sonicyouth86, Mikhail Ryazanov, ClueBot NG, Dremeley, Phanuruch8555, Frietjes,
Delusion23, Widr, Helpful Pixie Bot, Krist Wood, Ndanielm, BG19bot, SallySE, Alex Ratushnyak, Ceradon, Adam.tolley, Tylergoer-
ing, Isacdaavid, Narohi, Conifer, Rangers94, Lolo Lympian, Npham20, Corn cheese, C5st4wr6ch, UrbanDragon 33, Michipedian, Davi-
dLeighEllis, Ugog Nizdast, Worbleduck, Abitslow, Monkbot, Ashok0783, DoktorRF, OKNoah, GiorgioMalvone, Venomzx and Anony-
mous: 472
7.11.2 Images
File:ASCII_Code_Chart-Quick_ref_card.png Source: http://upload.wikimedia.org/wikipedia/commons/e/e0/ASCII_Code_
Chart-Quick_ref_card.png License: Public domain Contributors: See above description Original artist: Namazu-tron
File:Adam7_passes.gif Source: http://upload.wikimedia.org/wikipedia/commons/2/27/Adam7_passes.gif License: Public domain Con-
tributors: Own work Original artist: CountingPine
File:AllBMPformats.png Source: http://upload.wikimedia.org/wikipedia/commons/d/da/AllBMPformats.png License: Public domain
Contributors: Own work Original artist: Verpies
File:BMPfileFormat.png Source: http://upload.wikimedia.org/wikipedia/commons/c/c4/BMPfileFormat.png License: Public domain
Contributors: Own work Original artist: Verpies
File:BitfieldsSLN.png Source: http://upload.wikimedia.org/wikipedia/commons/3/3c/BitfieldsSLN.png License: Public domain Con-
tributors: Own work Original artist: Verpies
File:Bmp_format.svg Source: http://upload.wikimedia.org/wikipedia/commons/e/e8/Bmp_format.svg License: Pub-
lic domain Contributors: Recreation of raster image, File:Bmp format.png by Craig t moore, in SVG format. Orig-
inal artist: <a href='//commons.wikimedia.org/wiki/User:DoktorMandrake' title='User:DoktorMandrake' class='mw-
redirect'>Doktor</a><a href='//commons.wikimedia.org/wiki/User_talk:DoktorMandrake' title='User talk:DoktorMandrake'
class='mw-redirect'>Mandrake</a>
File:Bruce_Martin_hexadecimal_notation_proposal.png Source: http://upload.wikimedia.org/wikipedia/commons/9/90/Bruce_
Martin_hexadecimal_notation_proposal.png License: Attribution Contributors: Letters to the editor: On binary notation, Bruce A. Martin,
Associated Universities Inc., Communications of the ACM, Volume 11, Issue 10 (October 1968) Page: 658 Original artist: Bruce A.
Martin, Applied Mathematics Department, Brookhaven National Laboratory
File:Commons-logo.svg Source: http://upload.wikimedia.org/wikipedia/en/4/4a/Commons-logo.svg License: ? Contributors: ? Original
artist: ?
File:Comparison_of_JPEG_and_PNG.png Source: http://upload.wikimedia.org/wikipedia/commons/a/a4/Comparison_of_JPEG_
and_PNG.png License: ? Contributors: English Wikipedia Original artist: en:User:Toniht, cropped by en:User:Plugwash
File:Continuously_varied_JPEG_compression_for_an_abdominal_CT_scan_-_1471-2342-12-24-S1.ogv Source:
http://upload.wikimedia.org/wikipedia/commons/f/f3/Continuously_varied_JPEG_compression_for_an_abdominal_CT_scan_-_
1471-2342-12-24-S1.ogv License: CC-BY-2.0 Contributors: Flint A (2012). extquotedblDetermining optimal medical image compres-
sion: psychometric and image distortion analysis extquotedbl. BMC Medical Imaging. DOI:10.1186/1471-2342-12-24. PMID 22849336.
PMC: 3431233. Original artist: Flint A
File:Dctjpeg.png Source: http://upload.wikimedia.org/wikipedia/commons/2/23/Dctjpeg.png License: Public domain Contributors: ?
Original artist: ?
File:Edit-clear.svg Source: http://upload.wikimedia.org/wikipedia/en/f/f2/Edit-clear.svg License: ? Contributors: ? Original artist: ?
File:Empty_GIF_hex.png Source: http://upload.wikimedia.org/wikipedia/commons/c/cc/Empty_GIF_hex.png License: GPL Contribu-
tors: Own work Original artist: Authors of the Bless Hex Editor
File:Felis_silvestris_silvestris_small_gradual_decrease_of_quality.png Source: http://upload.wikimedia.org/wikipedia/commons/e/
e9/Felis_silvestris_silvestris_small_gradual_decrease_of_quality.png License: CC-BY-3.0 Contributors:
Felis_silvestris_silvestris.jpg Original artist: Felis_silvestris_silvestris.jpg: Michael Gbler
File:Folder_Hexagonal_Icon.svg Source: http://upload.wikimedia.org/wikipedia/en/4/48/Folder_Hexagonal_Icon.svg License: ? Con-
tributors: ? Original artist: ?
File:GIFPAL.png Source: http://upload.wikimedia.org/wikipedia/commons/4/43/GIFPAL.png License: Public domain Contributors:
Own work (Original caption: I created this work entirely by myself.) Original artist: Cuddlyable3 (talk)
File:GifSample.gif Source: http://upload.wikimedia.org/wikipedia/commons/1/19/GifSample.gif License: Public domain Contributors:
Own work (Original caption: I created this work entirely by myself.) Original artist: Cuddlyable3 (talk)
File:Hexadecimal-counting.jpg Source: http://upload.wikimedia.org/wikipedia/commons/b/b5/Hexadecimal-counting.jpg License:
Public domain Contributors: Own work Original artist: <img alt='Mate2code.svg' src='//upload.wikimedia.org/wikipedia/commons/
thumb/b/b0/Mate2code.svg/24px-Mate2code.svg.png' width='24' height='24' srcset='//upload.wikimedia.org/wikipedia/commons/
thumb/b/b0/Mate2code.svg/36px-Mate2code.svg.png 1.5x, //upload.wikimedia.org/wikipedia/commons/thumb/b/b0/Mate2code.svg/
48px-Mate2code.svg.png 2x' data-le-width='360' data-le-height='360' /> mate2code
File:Hexadecimal_multiplication_table.svg Source: http://upload.wikimedia.org/wikipedia/commons/e/eb/Hexadecimal_
multiplication_table.svg License: Public domain Contributors: Created by Bernard Ladenthin Original artist: Bernard Ladenthin
File:JPEG_ZigZag.svg Source: http://upload.wikimedia.org/wikipedia/commons/4/43/JPEG_ZigZag.svg License: Public domain Con-
tributors: self-made after Interiots en:Image:JPEG ZigZag.jpg Original artist: Alex Khristov
File:JPEG_example_JPG_RIP_001.jpg Source: http://upload.wikimedia.org/wikipedia/commons/3/38/JPEG_example_JPG_RIP_
001.jpg License: CC-BY-SA-3.0 Contributors: Transferred from en.wikipedia; transferred to Commons by User:Masur using
CommonsHelper. Original artist: Original uploader was Toytoy at en.wikipedia
File:JPEG_example_JPG_RIP_010.jpg Source: http://upload.wikimedia.org/wikipedia/commons/3/38/JPEG_example_JPG_RIP_
File:JPEG_example_JPG_RIP_025.jpg Source: http://upload.wikimedia.org/wikipedia/commons/8/8c/JPEG_example_JPG_RIP_
File:JPEG_example_JPG_RIP_050.jpg Source: http://upload.wikimedia.org/wikipedia/commons/e/e0/JPEG_example_JPG_RIP_
File:JPEG_example_JPG_RIP_100.jpg Source: http://upload.wikimedia.org/wikipedia/commons/b/b4/JPEG_example_JPG_RIP_
File:JPEG_example_image.jpg Source: http://upload.wikimedia.org/wikipedia/commons/b/be/JPEG_example_image.jpg License:
CC-BY-SA-3.0 Contributors: ? Original artist: ?
File:JPEG_example_image_decompressed.jpg Source: http://upload.wikimedia.org/wikipedia/commons/d/d4/JPEG_example_
image_decompressed.jpg License: CC-BY-SA-3.0 Contributors: Transferred from en.wikipedia; transferred to Commons by User:Shizhao
using CommonsHelper. Original artist: Original uploader was Cburnett at en.wikipedia
File:JPEG_example_subimage.svg Source: http://upload.wikimedia.org/wikipedia/commons/6/61/JPEG_example_subimage.svg Li-
cense: CC-BY-SA-3.0 Contributors: Own work in Inkscape based on the following data:
<img class='mwe-math-fallback-png-inline tex' alt=' \begin{bmatrix} 52 ,,&,, 55 ,,&,, 61
,,&,, 66 ,,&,, 70 ,,&,, 61 ,,&,, 64 ,,&,, 73 \\
63 ,,&,, 59 ,,&,, 55 ,,&,, 90 ,,&,, 109 ,,&,, 85
,,&,, 69 ,,&,, 72 \\ 62 ,,&,, 59 ,,&,, 68 ,,&,, 113
,,&,, 144 ,,&,, 104 ,,&,, 66 ,,&,, 73 \\ 63 ,,&,,
58 ,,&,, 71 ,,&,, 122 ,,&,, 154 ,,&,, 106 ,,&,,
70 ,,&,, 69 \\ 67 ,,&,, 61 ,,&,, 68 ,,&,, 104 ,,&,,
126 ,,&,, 88 ,,&,, 68 ,,&,, 70 \\ 79 ,,&,, 65 ,,&,,
60 ,,&,, 70 ,,&,, 77 ,,&,, 68 ,,&,, 58 ,,&,, 75 \\
85 ,,&,, 71 ,,&,, 64 ,,&,, 59 ,,&,, 55 ,,&,, 61
,,&,, 65 ,,&,, 83 \\ 87 ,,&,, 79 ,,&,, 69 ,,&,,
68 ,,&,, 65 ,,&,, 76 ,,&,, 78 ,,&,, 94 \end{bmatrix} '
src='//upload.wikimedia.org/math/9/b/8/9b8048a0f8bdfed7f8b8eaefc58656e8.png' />
Original artist: en:User:Cburnett
File:JPEG_process.svg Source: http://upload.wikimedia.org/wikipedia/commons/6/68/JPEG_process.svg License: Public domain Con-
tributors: Own work Original artist: User:Konstable
File:JPS-sample.jpg Source: http://upload.wikimedia.org/wikipedia/commons/c/c7/JPS-sample.jpg License: CC-BY-SA-3.0 Contribu-
tors: Own work Original artist: Matthias Stirner
File:Jpegvergroessert.jpg Source: http://upload.wikimedia.org/wikipedia/commons/1/15/Jpegvergroessert.jpg License: CC-BY-SA-3.0
Contributors: ? Original artist: ?
File:Lichtenstein_jpeg_difference.png Source: http://upload.wikimedia.org/wikipedia/commons/f/ff/Lichtenstein_jpeg_difference.
png License: CC-BY-SA-3.0 Contributors: Own work Original artist: Alessio Damato
File:Lossless-circle-canny.png Source: http://upload.wikimedia.org/wikipedia/commons/1/1c/Lossless-circle-canny.png License: Pub-
lic domain Contributors: Own work Original artist: Meisam
File:Lossless-circle.png Source: http://upload.wikimedia.org/wikipedia/commons/f/f9/Lossless-circle.png License: Public domain Con-
tributors: Own work Original artist: Meisam
File:Lossy-circle-canny.png Source: http://upload.wikimedia.org/wikipedia/commons/6/6e/Lossy-circle-canny.png License: Public do-
main Contributors: Own work Original artist: Meisam
File:Lossy-circle.jpg Source: http://upload.wikimedia.org/wikipedia/commons/e/ed/Lossy-circle.jpg License: Public domain Contribu-
tors: Own work Original artist: Meisam
File:Newtons_cradle_animation_book_2.gif Source: http://upload.wikimedia.org/wikipedia/commons/d/d3/Newtons_cradle_
animation_book_2.gif License: CC-BY-SA-3.0 Contributors: Image:Newtons cradle animation book.gif Original artist: DemonDeLuxe
(Dominique Toussaint)
File:PNG-Gradient.png Source: http://upload.wikimedia.org/wikipedia/commons/8/89/PNG-Gradient.png License: Public domain
Contributors: ? Original artist: ?
File:PNG-Gradient_hex.png Source: http://upload.wikimedia.org/wikipedia/commons/1/17/PNG-Gradient_hex.png License: GPL
Contributors: Own work Original artist: Authors of the Bless Hex Editor
File:PNG_transparency_demonstration_1.png Source: http://upload.wikimedia.org/wikipedia/commons/4/47/PNG_transparency_
demonstration_1.png License: CC-BY-SA-3.0 Contributors: Own work: Rendered in POV-Ray by user:ed_g2s. Original artist: POV-
Ray source code
File:PNG_transparency_demonstration_2.png Source: http://upload.wikimedia.org/wikipedia/commons/9/9a/PNG_transparency_
demonstration_2.png License: CC-BY-SA-3.0 Contributors: Own work: Rendered in POV-Ray by user:ed_g2s. Original artist: POV-
Ray source code
File:Pixel-prediction.svg Source: http://upload.wikimedia.org/wikipedia/commons/3/39/Pixel-prediction.svg License: Public domain
Contributors: Own work Original artist: ZooFari
File:Quilt_design_as_46x46_uncompressed_GIF.gif Source: http://upload.wikimedia.org/wikipedia/commons/b/bb/Quilt_design_
as_46x46_uncompressed_GIF.gif License: Public domain Contributors: I created this image fromscratch. I release it to the Public Domain.
Original artist: Elphion (talk) 16:43, 31 May 2011 (UTC)
File:Rotating_earth_(large).gif Source: http://upload.wikimedia.org/wikipedia/commons/2/2c/Rotating_earth_%28large%29.gif Li-
cense: CC-BY-SA-3.0 Contributors: Based upon a NASA image, see [1]. Original artist: Marvel
File:SLNotation44440.png Source: http://upload.wikimedia.org/wikipedia/commons/8/84/SLNotation44440.png License: Public do-
main Contributors: Own work Original artist: Verpies
File:Searchtool.svg Source: http://upload.wikimedia.org/wikipedia/en/6/61/Searchtool.svg License: ? Contributors: ? Original artist: ?
File:SmallFullColourGIF.gif Source: http://upload.wikimedia.org/wikipedia/commons/a/aa/SmallFullColourGIF.gif License: CC-BY-
SA-3.0 Contributors: Own work Original artist: GDallimore
File:Sunflower_as_gif_websafe.gif Source: http://upload.wikimedia.org/wikipedia/commons/a/a0/Sunflower_as_gif_websafe.gif Li-
cense: Public domain Contributors:
Sunower_as_PNG.png Original artist: Sunower_as_PNG.png: Uwe W.
File:Symbol_neutral_vote.svg Source: http://upload.wikimedia.org/wikipedia/en/8/89/Symbol_neutral_vote.svg License: ? Contribu-
tors: ? Original artist: ?
File:White_House_Tumblr_launch_image.jpg Source: http://upload.wikimedia.org/wikipedia/commons/9/93/White_
House_Tumblr_launch_image.jpg License: Public domain Contributors: http://whitehouse.tumblr.com/post/48938628507/
the-white-house-tumbling-things Original artist: Whitehouse.gov, Tumblr
7.11.3 Content license
Creative Commons Attribution-Share Alike 3.0

CS50 PSET5 Images and Formats

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

CS50 PSET5 Images and Formats

Hochgeladen von

Copyright:

Verfügbare Formate

CS50 PSET5 Images and Formats

415.38 30.19 61.20 27.24 56.12 20.10 2.39 0.46

and taking the entry-for-entry product with the quantiza-

which closely resembles the original DCT coecient ma-

and adding 128 to each entry

with an average absolute error of about 5 values per pixels

Das könnte Ihnen auch gefallen