Pixelated image of an opossum on the steps of a snowy deck, facing the camera, with a bowl of food in the background

Annotated Guide to Opossum.png

A PNG file created by Glenn Randers-Pehrson

Annotated by Jeff Thompson

Purchase the book from Black Rock Press

• • •

Jump to a section of the file:

Internet GIF tax, / January '95. / PNG to the rescue!

Glenn Randers-Pehrson

In 1994, the internet was in an early heyday; AOL had about three million active users with lots of other folks participating in other online platforms. The internet was shifting from primarily a text-based experience to one full of media, in particular GIFs, an image format introduced by CompuServe in the late 1980s. But, though popular, the GIF format was quietly embroiled in a year-long legal battle over the data compression technique it used called LZW. Three days before Christmas of 1994, a deal was announced where CompuServe would charge royalties to any software that supported GIFs. This created a huge stir among online communities, notably the comp.graphics newsgroup, where the Portable Network Graphics (PNG) format would later have its start.

But amid days of complaints and arguments, on 3 January 1995 Thomas Boutell made a post suggesting that a new image file format be created, one that used technologies that were free of any patents. JPG had existed at this time for a couple of years, but its compression was lossy, meaning the image could not be reconstructed at full resolution the way GIF or TIFF (another popular format at the time) allowed.

After Boutell's original post, a "group of strangers" formed, working entirely online and by consensus (though with Boutell as the "Benevolent Dictator," a role inspired by Linus Torvalds' work leading the development of the Linux kernel). Many of the early discussions still archived in comp.graphics. PNG, as it would eventually be called, was originally known by a variety of names, including Peanut Butter Format (aka "Chunky GIF") and the recursive dig PNG's Not GIF. Only a day after the first post, a working draft of the file format was published by Boutell; this version of PNG looks very much like the format we have today. The first working draft was passed by WC3 at the fourth International WWW Conference in December of that year. In 1996 PNG was given the official Internet Media type image/png by the Internet Assigned Numbers Authority. By 1997 it was widely supported by Microsoft Office, Photoshop and Illustrator, Internet Explorer and Netscape Navigator. Today, nearly 70% of all websites have at least one PNG image on them.

This website, part of a larger project in collaboration with Black Rock Press, is an annotated version of the image above. Taken by long-time PNG contributor Glenn Randers-Pehrson, it features an opossum aptly named PNG who frequented his family's deck in search of cat food. This image is one of the so-called "paleo PNGs," considered the first to be successfully encoded into this new image file format and uploaded to the internet. Sadly, Randers-Pehrson died in 2018 but these images are still readable today.

The annotations here break down this early PNG image into its constituent parts, offering technical and historical information on how images are encoded into PNG files, as well as the layers of technology and the human decisions that all pour into and shape something as seemingly simple and benign as a file format.

PNG Authors

Authors involved in the development of the first stable release of the PNG file format, released on 1 May 1995:

  • Michael Abrash
  • Michael Console Battilana
  • Bradley Bell
  • Andrei Belogortseff
  • C. Steven Blackwood
  • Robert K. Blaine
  • John Bradley
  • John Bridges
  • Rick Byrnes
  • Tony Caine
  • George Campbell
  • Mike Ceranski
  • Lee Crocker
  • Karen Crowther
  • E. Nicholas Cupery
  • Thomas Boutell
  • Gary Elfring
  • Julie England
  • Steve Estvanik
  • Jim Faliveno
  • Dan Farmer
  • Oliver Fromme
  • John Gallant
  • Lawrence Gozum
  • Phil Grenetz
  • Diana Gruber
  • David Hofmann
  • Michael D. Jones
  • Lutz Kretzschmar
  • Tom Lane
  • Steve Lee
  • Ralph Mariano
  • David K. Mason
  • Randy Maclean
  • Brad McLane
  • Al Meadows
  • Scott Miller
  • Jeff Napier
  • Peter Nielsen
  • David Noakes
  • Dick Oliver
  • Elizabeth Piegari
  • Dan Richardson
  • John Richardson
  • Steve Rimmer
  • Greg Roelofs
  • Guy Eric Schalnat
  • Paul Schmidt
  • Monty Shelton
  • Steve Sneed
  • David Snyder
  • Chuck Steenburgh
  • Raja Thiagarajan
  • Peter Tiemann
  • Glen Tippetts
  • Rod Underhill
  • John Wagner
  • Bruce F. Webster
  • Tim Wegner
  • Rosemary West
  • Thomas R. White
  • Charles L. Wiedemann
  • Terry Wilkinson
  • Ben Williams
  • Jeff Woods

This list is somewhat of a departure from what is published in other official sources. Greg Roelofs' History of the Portable Network Graphics (PNG) Format notes "All of the PNG authors were male—a fact that is still true" followed by the offhand parenthetical "(I'm sure there's a dissertation in there somewhere.)" However, earlier versions of the PNG specification have quite a few additional names that were involved in the beginning stages of the format's creation. I have chosen to list all of these names, which include several women whose careers are (very briefly) highlighted here:

  • Karen Crowther-Chun (created Redwood Games, a company that made the shareware games Math Rescue, Word Rescue, and Pickle Wars)
  • Julie England (worked on PMView and PMSnap shareware for OS/2)
  • Diana Gruber (VP and senior programmer at Ted Gruber Software Inc, did math for games including Atari's Pong; currently works as a mathematician designing slot machine "par sheets" and other gambling platforms)
  • Elizabeth Piegari (design and art for Depth Dwellers game)
  • Rosemary West (co-creator of LoveDOS, a chat program where you form a romantic relationship with DOS; trained as a linguist and now a relationship coach)

Like all long-term projects, some contributors drift in and out while others continue the difficult work of maintaining what has been built. Whenever possible and not merely PNG trivia, the names of people who added specific features are included in the annotations below.

Formatting Conventions

The data in a PNG file is an intricate mix of metadata and compressed pixel values, all stored and read in various formats. To better understand what is listed here, it's worth taking a moment to talk about the various formats that this data is stored in:

  • Decimal numbers: base ten, the numbers we're most familiar with
  • Hexadecimal numbers: like decimal but base sixteen; uses numbers 0–9 followed by the letters A–F
  • Binary: raw 0s and 1s, the most fundamental unit in computing
  • ASCII: numerical codes for letters and other typographical symbols

Different parts of a PNG file require decoders to read the data in these various formats. For each portion of this PNG file, three items are listed: the position in the file where it is found, the data stored there, and an annotation describing that part.

For example, all PNG files include the letters P N G in the "signature" section at the start of the file. These letters are located at indices 2–4 and read as ASCII characters. It would be listed like this:

Index

2–4

ASCII

P N G

Annotation

This is an example of an annotation. (It's below the data on smaller screens and to the right on larger ones.)

Similarly, the color type used in the file is listed in the next section, read as a decimal number:

Index

26

Decimal

2

Annotation

Another annotation, this time a decimal number that indicates the color type used in this image is "truecolor," or RGB.

Binary data is listed in the same way as characters and numbers. However, at times we need to read individual binary digits (0s and 1s) within a single byte (a series of eight bits). The position of these bits is notated using the index followed by a colon and the index of the bits being read. For example:

Index

43:6–7

Binary ←

1 0 0 1
1 1 0 0

Annotation

And another annotation, explaining the compression method used for the image's pixel data, found in the first two bits (index 43, bits 0–1).

Note that a PNG decoder may be required to read bits in the left-to-right order that English-speakers are used to, but at other times they are read right-to-left. When required, the annotation will indicate the direction that individual bits are to be read with ← and → arrows. Some hexadecimal values will also be read this way.

Signature

A big, gaping, gory hole.

Thomas Boutell, in the initial proposal for PNG to the comp.graphics Usenet group

Index

1–8

Various

\x89
P
N
G
\r
\n
\x1A
\n

Annotation

Every PNG file begins with a "signature," a series of pre-defined bytes that tell the computer what kind of file it is and catch errors in transmission online. The full signature was proposed by Tom Lane on 26 Jan 1995 and is required for all PNG files.

Details for each part of this signature are described below.

Index

1

ASCII

\x89

Annotation

The first byte in the PNG signature is a "magic number," a value that is deliberately not an ASCII character (137 is above the highest value specified by ASCII). When combined with some of the other bytes in the signature, this helps catch files transferred over the internet in ASCII mode (instead of binary, which is required for images) and text files that might be misread as an image file. Early versions of the PNG specification use a period here instead (spelling out . P N G with the next three bytes).

Index

2–4

ASCII

P N G

Annotation

Spells out P N G when read as ASCII. Thomas Boutell's original pitch for what would become PNG was posted to the comp.graphics Usenet newsgroup and included this suggestion for a name:

I think the only solution to the GIF Licensing Problem is a new standard... I have not yet selected a compression scheme... I am seeking advice in this matter. I'm calling it PBF (Portable Bitmap Format). The preferred filename extension is, obviously, .pbf.

Other early names included FIG (Fig Isn't GIF) and PIG (Portable Internet Graphics). The name PNG was proposed by Oliver Fromme on 6 Jan 1995. Once the name PNG was selected, versions of the specification include the note "PNG is pronounced 'Ping'."

Index

5–6

ASCII

\r \n

Annotation

Carriage return (\r) and line-feed (\n) characters, which work similarly to the first character of the signature, helping ensure a bad transfer hasn't altered the file. These two bytes both reflect the intent that PNG be an image format for the internet: they act as "ASCII armor," referring to the ASCII mode that some File Transfer Protocol (FTP) software defaults to instead of binary. These bytes simulate a text file and, if read that way, the decoder will immediately see that the expected signature has been altered and can expect that the rest of the file is damaged too.

These bytes also reveal layers of symbols which modern computers regularly use but are relics of much older technologies. The carriage return is a control character found on typewriters and, later, teletype machines that sends the carriage back to the far-left position on the same line. (This actually dates back even further and is found in the Baudot code for telegraphs as early as 1901.) The new-line character works similarly, moving the carriage to the next line, like pushing the return key on your keyboard.

Index

7

Hexadecimal

\x1A

Annotation

Equivalent to Ctrl+z which stops the raw file from being displayed on MS-DOS. Though few if any users will have this issue today, it was a big enough of a concern in the mid-1990s that this byte was included in the signature. Like \r and \n, Ctrl+z is a control character representing a change to the system rather than characters to be added to the text.

Index

8

ASCII

\n

Annotation

A final new-line character which catches additional file transfer errors. The specification is vague here, only noting that this final byte "checks for the inverse of the CR-LF [carriage return and new-line] translation problem" on bytes 5–6.

IHDR Length

To understand a program you must become both the machine and the program.

Alan Perlis

Index

9–12

Binary

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
1 1 0 1

Annotation

Each section of the PNG file is called a "chunk." With the exception of the signature, all chunks can be of varying length. In order to let the decoder know how long the upcoming chunk will be, the first four bytes of each chunk lists its length in bytes.

To calculate the length of the IHDR Header (the section that comes next) we must convert the binary representation of the length to a decimal number.

Binary values can be converted to decimal using this formula:

[first digit] × 231 +
[second digit] × 230
. . .
[second-to-last digit] × 21 +
[last digit] × 20

By substituting the values in the bytes from this section (and skipping any zeroes before we hit a one) we can calculate the length of the IHDR Header like this:

(1 × 23) + (1 × 22) + (0 × 21) + (1 × 20) = 13

Giving us a length of 13 bytes.

IHDR Header

Data is what distinguishes the dilettante from the artist.

George V. Higgins

Index

13–16

ASCII

I H D R

Annotation

Start of the header, which spells out I H D R in ASCII. This section includes all necessary metadata about the file and can also include optional information added by the encoder (though none is present in this file).

Index

17–20

Binary

0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 1
0 0 1 0
0 0 0 0

Annotation

These four bytes give us the width of the image in pixels. The decoder must convert these bytes into to a decimal number, like with the IHDR Length above.

In this case, we find our image is 288 pixels wide.

Since 1111 1111 1111 1111 is the largest four-byte binary value possible, a PNG file could theoretically be a maximum of 2,147,483,647 pixels wide and/or high. However, the DEFLATE algorithm (discussed below) used to compress the pixel data or one's operating system may lower this limit.

Index

22–24

Binary

0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
1 1 1 0
0 1 1 1

Annotation

The height of the image, calculated just like the width, giving us 231 pixels.

Index

25

Decimal

8

Annotation

Read as the decimal value, this gives us the bit depth of eight for the image. This means that the color of a single pixel is represented by eight binary bits (a single byte), a typical bit depth for the time.

Index

26

Decimal

2

Annotation

PNG supports several different color types. 2 means "truecolor" with no alpha (transparency), more commonly known as red, green, blue (RGB).

Since we know from the previous byte that there are eight bits per pixel, this does not divide into an even number of bits for each color value. Instead, red and green are allotted three bits each and only two for blue. This is because the human eye is less sensitive to blue and the resulting loss of detail in the blue channel is less noticeable than it would be for red or green.

Other color types include:

  • 0: grayscale
  • 3: indexed color
  • 4: grayscale with alpha
  • 6: truecolor with alpha

Index

27

Decimal

0

Annotation

Indicates the compression method used, with 0 meaning the DEFLATE algorithm, which has been the only method allowed since the creation of the PNG format.

See the annotation at index 44 for more details.

Index

28

Decimal

0

Annotation

Before the pixel data is compressed, each row of pixels is processed using one of five filters to further reduce the file size. While the PNG specification technically allows for other types of filtering, filter method 0 listed here is the only one that has ever been supported.

For each row, the filter type is dynamically selected from one of five filters:

  • None
  • Sub: the difference between the current pixel and the one to the left
  • Up: same as Sub but up one row
  • Average: difference between the current and average of up and left
  • Paeth: more complex; uses pixels to left, up, and upper-left

The filters are applied to the bytes that form the row, rather than on the RGB values of the pixels.

Index

29

Decimal

0

Annotation

PNG images can be interlaced, where every other pixel in every other row is loaded first, then the remaining pixels filled in. This allows for a degraded version of the image to be displayed more quickly on a slow internet connection – another nod to the intent that PNG be a format designed specifically for the web.

A value of 0 here means no interlacing; a value of one means interlacing with the Adam7 algorithm, invented by Adam M. Costello in 1995, the same year PNG was first developed.

CRC32 on IHDR

Labour without joy is base. Labour without sorrow is base.
Sorrow without labour is base. Joy without labour is base.

John Ruskin

Index

30–33

Binary

0 0 1 1
0 0 0 1
0 1 1 1
1 0 1 1
0 0 0 1
1 1 0 0
0 1 1 0
1 1 1 1

Annotation

Each chunk of a PNG file is followed by a four-byte error check sequence (with the exception of the signature at the start of the file). These bytes are the result of a mathematical calculation on the binary bits of the preceding chunk.

The particular error-detecting method used in PNG is called Cyclic Redundancy Check (CRC). The version that PNG uses is referred to as CRC32 because it takes in 32-bits (made from four bytes of eight bits each). Developed by W. Wesley Peterson in 1961 while working at IBM, CRC is specifically designed to detect errors in communications networks. The math involved in calculating CRC32 is outside the scope here, but involves a formula made of carefully-chosen polynomials:

x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x1 + x0

These polynomials have been picked to catch as many errors as possible and avoid "collision," where the bits in the chunk were wrong but the algorithm said they were correct. The math for calculating CRC32 is designed to be quick and easy for computers, and has led to its use in the ethernet specification as well and being added to the PNG specification by Greg Roelofs on 7 January 1995.

PNG decoding software first calculates the CRC32 value for the section it just received and compares it to the pre-computed CRC32 found in the file. If they are the same, we can safely assume there are no errors in transmission.

IDAT Length

I haue read the truest computer of Times, and the best Arithmetician that euer breathed, and he reduceth thy dayes into a short number.

Richard Braithwait (1613)

Index

34–37

Binary

0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 1 0
0 0 0 0
0 0 0 0
0 0 0 0

Annotation

The IHDR may be followed by additional, non-required chunks such as a color palette (for indexed color images), transparency and gamma data, and even text or copyright info. In the case of our image, we do not have any of these chunks, meaning that what comes next is the compressed pixel data, a chunk (or series of chunks) called IDAT.

These four bytes give us the length of the upcoming IDAT chunk, just like the IHDR length bytes above. When converted to decimal, we see the IDAT section is 8192 bytes long. Since the IDAT section starts at index 38, the data should end at index 8229.

The IDAT length does not include these length bytes or the CRC32 error check, but does include the I D A T label below.

IDAT

What kind of machine do you want? I can do anything. Machines are better than people. Machines can do anything. I can be an adding machine, subtracting machine, gumball machine, soda pop dispensing machine, jukebox...

Sam the Robot (Sesame Street)

Index

38–41

ASCII

I D A T

Annotation

The IDAT chunk(s) store compressed pixel data. Each IDAT section begins with I D A T written in ASCII. As we'll see below, there are three additional IDAT chunks in this image, found at indices 8242, 16446, and 24650. There are no markers between IDAT chunks other than the text I D A T.

The first letter of the I D A T identifier is a capital letter, meaning the chunk is "critical" (required as part of the PNG spec). Encoders can add additional, non-required "ancillary" chunks before the IDAT section, as mentioned above. Ancillary chunks must start with a lowercase letter.

The idea of chunks with this kind of identifier dates to 1985 and Electronic Arts' Interchange File Format (IFF). IFF used four-byte ASCII chunk IDs just like PNG. (IFF chunks were themselves inspired by the first Macintosh operating system, released a year before.) This system of IDs is known as "FourCC codes" – see EA IFF 85 Standard for Interchange File Formats for more information.

In the early development of PNG there was much discussion about IFF and whether PNG should simply be an extension of that format. Some versions of the specification include a "Rationale" appendix that points out several reasons, but Lee Daniel Crocker's post to comp.graphics in late 1995 looks back at this decision from an interesting point of view:

"It is my personal opinion that many Amiga users and IFF advocates are so blinded by the technical issues that they fail to see that technical merit has almost nothing to do with market acceptance. The PNG project would have failed miserably if we had used IFF, for the simple reason that it has the reputation (deservedly or not--but that doesn't matter) of being ill-specified, hard to code, and too machine-specific... I would venture to guess that even now, only a few weeks after the release of the spec, there are more programs supporting PNG than support all the ILBM [Interleaved Bitmap Format] options that PNG supports. That is no accident. We did our jobs well."

Others point to difficulty finding information on the IFF format without paying for "thousands of pages" of Amiga documentation, something hard to imagine today when materials like the various PNG specifications and even discussions about how the format developed are readily available online.

Compression Method and Flags

Sun sets over GIF.
With PNG on the horizon,
Web is dark no more.

Michael N. Randers-Pehrson

Index

42

Hexadecimal ←

78

Annotation

Read as a hexadecimal number, this value gives us two key pieces of information for decoding the image's pixels: the compression method used and additional "flags" that tell us how the pixel data is compressed. The value 7 8 here can be split into two digits, read from right-to-left (we'll see more of this "reverse" order shortly).

The right-most digit gives us the compression method (CM) used. 8 means DEFLATE, the only method allowed in the PNG specification.

The left-most digit gives us the "window size" (CINFO) used by DEFLATE. To calculate this, we use this formula:

2(8 + CINFO) = 2(8 + 7) = 32768

The values here are the default settings for PNG images; anything other than this would be unusual or an error.

Index

43

Binary

1 0 0 1
1 1 0 0

Annotation

This byte gives us several "flags," or additional info about how the pixel data below is compressed. Like CM and CINFO, this is read from right-to-left, though we view these values in their binary representation.

The details of these flags are shown below.

Index

43:0–4

Binary

1 0 0 1
1 1 0 0

Annotation

These values are "check bits" (FCHECK), which can be used to verify that the compression information is correct. We can ignore them, as they're only used to ensure the FCHECK calculation works out later.

Index

43:5

Binary

1 0 0 1
1 1 0 0

Annotation

This bit tells us if a preset dictionary is used to compress the data (FDICT). 0 means no dictionary; this is the only option allowed in the specification.

Index

43:6–7

Binary ←

1 0 0 1
1 1 0 0

Annotation

The last two bits (read right-to-left) tell us the compression level (FLEVEL) that was applied to the image when it was created. 01 means fast compression, which is the default. We do not need this information to decode the image, but it does tell us if the image might benefit from recompressing.

With all the information above decoded, we can then use the values at 43:0–4 to verify that this data was received correctly by calculating (CMF × 256 + FLG) % 31, where CMF and FLG are listed as decimal values. The result should always equal zero.

Using the values from our file:

(120 × 256 + 156) % 31 = 30876 % 31 = 0

Which gives a result of zero, as expected. A non-zero result would mean an error.

Pixel Data

In art, this amounts to going into the gallery and doing long division out loud: the only reason we’d speak is to show off our facility doing something trivial.

Andrei Pop

Index

44–8229

Binary

1 1 0 0
1 1 0 1
0 1 1 1
1 1 0 1
...
0 1 0 1
0 1 1 0
0 1 1 1
1 0 1 0

Annotation

After having unpacked the necessary information to read the file, we finally come to the pixel data itself. While PNGs can store raw RGB values, most of the time the pixel data is compressed to save space and make downloading faster. Unlike JPG, the method used for compressing pixels in PNG is "lossless," meaning the image we save is exactly what is decoded and displayed. The way this data is compressed is a perfect example of how layers of technology build on one another and, the closer you look, the onion-skin of technical history can reveal itself, even with something as seemingly benign as a file format.

The pixel data is compressed using the zlib software library, which is based on the DEFLATE algorithm. This in turn is a combination of two additional compression methods: LZ77, also used in zip files, and Huffman coding. The details of how zlib and DEFLATE work, and their underlying theory, are outside the scope of this document. Even official resources like the O'Reilly book PNG: The Definitive Guide by Greg Roelofs (a key author of the PNG format) suggest:

[A] more detailed explanation of the deflate algorithm and the zlib data format is beyond the scope of this book... Practically speaking, independent implementation of the deflate algorithm is both difficult and unnecessary.

In broad strokes, these compression methods look for repetition in the pixel data. If any repeated values are found, they can be represented by how far back the repeated data occurred and the the number of values that repeat. For example, with the text the dog loves their toy we see that the letters "the" appears twice. So instead of writing it all out, we could notate it like this: the dog loves [14,3 ← the]ir toy, where 14 is the how many characters we have to go back to find the matched string and 3 is how many characters to copy. This doesn't save us much space, but in a text the size of a book there will likely be many such repetitions. PNG does the same with pixel data, though it does so on the level of binary digits rather than separate RGB and row-filter values.

For this reason, the larger the image the better the compression works because it has more pixels in which to find (and compress) repetitions. A smaller image simply has less data to work with and fewer opportunities for compression. After the image size reaches about 512 bytes of pixel data, compression efficiency is approximately 10%. For more details and a great example, see this article in Towards Data Science.

The resulting values are then split into two Huffman trees; those trees are then further compressed into a final Huffman tree. It is this layering of separate technological processes (with Huffman coding dating back to the 1950s) that are most interesting here. The PNG format does not exist on its own and is instead a complicated merging of ideas and practices. We find the same thing when we scratch the surface of any technological system: layers of previous labor and choices, all the way down to metals mined from the earth and atoms interacting.

Index

44:5–7

Binary ←

1 1 0 0
1 1 0 1

Annotation

Aside from pixel values, there are two more pieces of info we can extract from this IDAT section, stored in the first three bits (read right-to-left) of the first byte of the compressed pixel data: 101.

An IDAT chunk can contain more than one compressed block, especially if the image is large. The first digit here is 1, meaning this is the last (and only) block in the current IDAT chunk. Note this does not mean this is the last IDAT chunk in the entire file, just the last compressed block here.

The next two bits (BTYPE) specify how the data is compressed. 01 means it is encoded with fixed Huffman codes.

Index

8230–8233

Binary

1 0 0 0
0 1 0 1
0 1 0 0
0 0 1 0
0 0 0 1
1 0 0 1
1 0 1 0
0 0 1 1

Annotation

At the end of the compressed block(s) of pixel data, we have four bytes of error correction. These bytes are calculated on the uncompressed pixel values and their per-row filter bytes (not on the compressed data). This is done using Adler-32, an error-check process that works similarly to the CRC32. Developed by Mark Adler in 1995, it was originally part of the zlib code library, which is used for compression of PNGs.

The decoder can compute the Adler-32 checksum for the pixels it decompressed and compare it with the value listed here. If they don't match, an error has occurred.

Index

8234–8237

Binary

0 1 0 0
0 1 0 1
0 1 0 1
1 1 0 0
0 0 0 1
0 0 0 1
1 1 1 0
0 1 1 0

Annotation

The last part of the IDAT block is another CRC32 error check, calculated on the compressed IDAT block including the I D A T label and the Adler-32 values above but not the length values before it starts.

The Adler-32 process checks that the pixel values have been compressed correctly; the CRC32 checks if that data has been sent without errors.

Index

8238–8241

Binary

0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 1 0
0 0 0 0
0 0 0 0
0 0 0 0

Annotation

The length of the next IDAT block, which is also 8192 bytes long, just like the previous IDAT.

Index

8242–8245

ASCII

I D A T

Annotation

I D A T chunk identifier, just like in the previous IDAT block.

Index

8246–16445

Binary

1 0 0 1
0 1 0 0
. . .
0 1 1 0
1 1 1 0

Annotation

Pixel data for the next chunk. This takes the same format as above, though we won't see the CMF / FLG bits here or in any later IDAT chunks. This is because the compression is done for the entire image, then it is split into multiple IDAT chunks. We only need that info at the start to understand how it was compressed; listing it again here would be an unnecessary repetition.

Index

16446–24649

Binary

0 1 0 0
1 0 0 1
. . .
1 1 0 0
1 1 0 0

Annotation

Pixel data for the next I D A T chunk. Once again, the section starts with the IDAT marker but there are no CM / FLG bits here.

Index

24650–28701

Binary

0 1 0 0
1 0 0 1
. . .
0 1 1 0
1 1 1 0

Annotation

Pixel data for the final I D A T chunk.

IEND

But it seems to me that the PNG story, like that of Linux, represents the best of the Internet: international cooperation, rapid development and the production of a Good Thing that is not only useful but also freely available for everyone to enjoy.

Greg Roelofs

Index

28702–28705

Binary

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 0

Annotation

The final chunk in every PNG file is IEND, which marks the end of the file. As with the chunks above, it is preceeded with the length of the chunk. The value for this section is all zeroes, which comes out to a length of zero. This is expected, since IEND cannot actually contain any data.

Index

28706–28709

ASCII

I E N D

Annotation

Chunk marker spelling out I E N D in ASCII. This is the only content allowed in this section.

Index

28710–28713

Hexadecimal

AE 42 60 82

Annotation

CRC32 of the IEND chunk. Like the signature at the start of the file, this should always be these same values since the only content of the IEND chunk are the letters I E N D.

References

Fires can't be made with dead embers.

James Baldwin

 

Colophon

Special thanks to the School of the Arts and University of Nevada, Reno, whose visiting artist program supported this work.

This website was built by Jeff Thompson and is part of a larger project, titled Opossum.png and released by Black Rock Press (BRP). It consists of a printed version of this PNG file and a printed version of opossum.png in a wooden storage box. The book has been hand bound with help from the following people at Black Rock Press: Director of BRP AB Gorham, BRP Redfield Fellow Kelsey Reiman, and student workers Aiman Murtaza, Clarissa Miller, and Bobby Lee. It was digitally printed on Mohawk Via Warm White. The endsheets were letterpress printed using a Vandercook Universal 1 at Black Rock Press on French Paper Company Fuse Green paper.

This website, the book, and all accompanying documents have been set in Cooper Hewitt, a typeface created by Pentagram and Chester Jenkins.

If you find errors with this annotated file or have suggestions of other materials to add, please contact Jeff Thompson.

To purchase a copy of the book, please visit Black Rock Press.

Revision 2J, 2021
Released under CC BY-NC 4.0
© Jeff Thompson