Howdy, PNG! | Weblog

2023-01-18 04:01:00

By David Buchanan, 16^th of January 2023

PNG is my favorite file format of all time. Model 1.0 of the specification was released in 1996 (earlier than I used to be born!) and the format stays broadly used to this present day. I believe the principle causes it caught round for thus lengthy are:

It is “Ok” at lossless picture compression.
It builds on current applied sciences (zlib/DEFLATE compression).
It is easy to implement (helped by the above level).
It helps quite a lot of modes and bit-depths, together with “true colour” (24-bit RGB) and transparency.
It is not patented.

There are different similarly-old and similarly-ubiquitous codecs (cough ZIP cough) which are disgusting to cope with resulting from legacy cruft, ad-hoc extensions, spec ambiguities, and mutually incompatible implementations. On the entire, PNG just isn’t like that in any respect, and it is largely resulting from its well-thought-out design and cautious updates through the years.

I am writing this text to fulfil my function as a PNG evangelist, spreading the enjoyment of good-enough lossless picture compression to each nook of the web. Related articles exist already, however this one is mine.

I will be referencing the Working Draft of the PNG Specification (Third Edition) launched in October 2022 (!), however each characteristic I point out right here ought to nonetheless be current within the 1.0 spec. I am going to goal to replace this text as soon as the Third Version releases formally.

Writing a PNG File

I believe the easiest way to familiarize yourself with a file format is to jot down code for studying or writing it. On this occasion we will write a PNG, as a result of we are able to select to concentrate on the best subset of PNG options.

A minimum-viable PNG file has the next construction:

PNG signature || "IHDR" chunk || "IDAT" chunk || "IEND" chunk

The PNG signature (aka “magic bytes”) is defined as:

"89 50 4E 47 0D 0A 1A 0A" (hexadecimal bytes)

Or, expressed as a Python bytes literal:

These magic bytes have to be current firstly of each PNG file, permitting applications to simply detect the presence of a PNG.

PNG Chunks

After the signature, the remainder of the PNG is only a sequence of Chunks. They every have the identical total structure:

Size      - A 31-bit unsigned integer (the variety of bytes within the Chunk Information subject)
Chunk Sort  - 4 bytes of ASCII higher or lower-case characters
Chunk Information  - "Size" bytes of uncooked knowledge
CRC         - A CRC-32 checksum of the Chunk Sort + Chunk Information

PNG makes use of Network Byte Order (aka “big-endian”) to encode integers as bytes. “31-bit” just isn’t a typo – PNG defines a “PNG 4 byte integer”, which is proscribed
to the vary 0 to 2³¹-1, to defend in opposition to the existence of C programmers.

If you happen to’re not acquainted with these ideas, don’t be concerned – Python will deal with all of the encoding for us.

The Chunk Sort, in our occasion, can be considered one of IHDR, IDAT, or IEND (extra on these later).

The CRC subject is a CRC-32 checksum. The spec offers a terse mathematical definition, however we are able to ignore all these particulars and use a library to deal with it for us.

The which means of information inside a bit is determined by the chunk’s kind, and probably, context from prior chunks.

Placing all that collectively, here‘s a Python script that generates a vaguely PNG-shaped file:

import zlib

# https://www.w3.org/TR/2022/WD-png-3-20221025/#5PNG-file-signature
PNG_SIGNATURE = b'x89PNGrnx1an'

# https://www.w3.org/TR/2022/WD-png-3-20221025/#5Chunk-layout
def write_png_chunk(stream, chunk_type, chunk_data):
    # https://www.w3.org/TR/2022/WD-png-3-20221025/#dfn-png-four-byte-unsigned-integer
    chunk_length = len(chunk_data)
    if chunk_length > 2**31 - 1:  # That is unlikely to ever occur!
    	elevate ValueError("This chunk has an excessive amount of chonk!")
    
    # https://www.w3.org/TR/2022/WD-png-3-20221025/#5CRC-algorithm
    # Fortuitously, zlib's CRC32 implementation is suitable with PNG's spec:
    crc = zlib.crc32(chunk_type + chunk_data)

    stream.write(chunk_length.to_bytes(4, "massive"))
    stream.write(chunk_type)
    stream.write(chunk_data)
    stream.write(crc.to_bytes(4, "massive"))


if __name__ == "__main__":
    """
    This isn't going to lead to a legitimate PNG file, but it surely's a begin
    """

    ihdr = b"" * 13  # TODO: populate actual values!
    idat = b""  # ditto

    with open("samples/out_0.png", "wb") as f: # open file for writing
    	f.write(PNG_SIGNATURE)
    	write_png_chunk(f, b"IHDR", ihdr)
    	write_png_chunk(f, b"IDAT", idat)
    	write_png_chunk(f, b"IEND", b"")

The write_png_chunk() perform is full and absolutely purposeful. Nevertheless,
we have no actual knowledge to place within the chunks but, so the script’s output just isn’t a legitimate PNG.

Working the unix file software in opposition to it offers the next output:

$ file samples/out_0.png 
samples/out_0.png: PNG picture knowledge, 0 x 0, 0-bit grayscale, non-interlaced

It accurately recognises a PNG file (as a result of magic bytes), and the remainder of the abstract corresponds to the 13 zeroes I packed into the IHDR chunk as a placeholder. Since we’ve not populated the chunks with any significant knowledge but, picture viewers will refuse to load it and provides an error (there’s nothing to load!).

Picture Enter

Earlier than we proceed, we will want some precise picture knowledge to place inside our PNG. This is an instance picture
I got here up with:

Funnily sufficient, it is already a PNG file, however we do not have a approach to learn PNGs but – how can we get the pixel knowledge into our script? One easy technique is to transform it right into a uncooked bitmap, which is one thing ImageMagick might help us with. I used the next command:

$ convert ./samples/hello_png_original.png ./samples/hello_png.rgb

hello_png.rgb now comprises the uncooked uncompressed RGB pixel knowledge, which we are able to trivially learn as-is from Python. For each pixel in each row, it shops a 3-byte worth akin to the color of that pixel. Every byte is within the vary 0-255, akin to the brightness of every RGB sub-pixel respectively. To be pedantic, these values symbolize coordinates within the sRGB colourspace, however that element just isn’t strictly obligatory to grasp.

This .rgb file is not a “actual” picture file format, and we have to keep in mind sure properties to have the ability to make sense of it. Firstly we have to know the width and peak (on this case 320×180), the pixel format (24-bit RGB, as described above), and the colourspace (sRGB). The PNG file that we generate will include all this metadata in its headers, however for the reason that enter file does not include them, we’ll hardcode the values in our Python script.

The IHDR (Picture Header) Chunk

The IHDR Chunk comprises an important metadata in a PNG – and in our simplified case, all the metadata
of the PNG. It encodes the width and peak of the picture, the pixel format, and a few different particulars:

Identify                Dimension

Width               4 bytes
Peak              4 bytes
Bit depth           1 byte
Color kind         1 byte
Compression technique  1 byte
Filter technique       1 byte
Interlace technique    1 byte

There is not a lot to say about it, however here is the relevant section of the spec.

I discussed earlier that our RGB values are within the sRGB colourspace. PNG has methods to sign this info explicitly (by means of “Ancilliary Chunks”), however in observe, sRGB is assumed to be the default, so for our minimum-viable PNG implementation we are able to simply depart it out. Color areas are a fancy subject, and if you wish to study extra I like to recommend watching this speak as an introduction: Guy Davidson – Everything you know about colour is wrong

The IDAT (Picture Information) Chunk

The IDAT chunk comprises the picture knowledge itself, after it has been Filtered after which Compressed (to be defined shortly).

The information could be break up over a number of consecutive IDAT chunks, however for our functions, it might simply go in a single massive chunk.

The IEND (Picture Trailer) Chunk

This chunk has size 0, and marks the top of the PNG file. Be aware {that a} zero-length chunk should nonetheless have all the identical fields as every other chunk, together with the CRC.

Filtering

The thought of filtering is to make the picture knowledge extra readily compressible.

It’s possible you’ll recall that the IHDR chunk has a “Filter technique” subject. The one specified filter technique is technique 0, known as “adaptive filtering” (the others are reserved for future revisions of the PNG format).

In Adaptive Filtering, every row of pixels is prefixed by a single byte that describes the Filter Sort used for that specific row. There are 5 attainable Filter Varieties, however for now, we’re solely going to care about kind 0, which suggests “None”.

If we had a tiny 3×2 pixel picture comprised of all-white pixels, the filtered picture knowledge would look one thing like this: (byte values expressed in decimal)

0   255 255 255  255 255 255  255 255 255
0   255 255 255  255 255 255  255 255 255

I’ve added whitespace and a newline to make it extra legible. The 2 zeroes firstly of every row encode the filter kind, and the “255 255 255″s every encode a white RGB pixel (with every sub-pixel at most brightness).

That is the best attainable means of “filtering” PNG picture knowledge. After all, it does not do something particularly helpful since we’re solely utilizing the “None” filter, but it surely’s nonetheless a requirement to have a legitimate PNG file. I’ve applied it in Python like so:

# That is all of the code required to learn subpixel values from an ".rgb" file.
# subpixel 0=R, 1=G, 2=B
def read_rgb_subpixel(rgb_data, width, x, y, subpixel):
    return rgb_data[3 * ((width * y) + x) + subpixel]

# Be aware: This perform assumes RGB pixel format!
# Be aware: This perform could possibly be written extra concisely by merely concatenating
# slices of rgb_data, however I need to use approachable syntax and preserve issues
# abstracted neatly.
def apply_png_filters(rgb_data, width, peak):
    # we'll work with an array of ints, and convert to bytes on the finish
    filtered = []
    for y in vary(peak):
    	filtered.append(0) # All the time filter kind 0 (none!)
    	for x in vary(width):
    		filtered += [
    			read_rgb_subpixel(rgb_data, width, x, y, 0), # R
    			read_rgb_subpixel(rgb_data, width, x, y, 1), # G
    			read_rgb_subpixel(rgb_data, width, x, y, 2)  # B
    		]
    return bytes(filtered)

Compression

As soon as the picture knowledge has been filtered, it must be compressed. It’s possible you’ll recall that the IHDR chunk has a “Compression technique” subject. The one compression technique specified is technique 0 – an analogous state of affairs to the Filter Technique subject. Technique 0 corresponds to DEFLATE-compressed knowledge saved within the “zlib” format. The zlib format provides a small header and a checksum (adler32), however the particulars of this are exterior the scope of this text – we’re simply going to make use of the zlib library (a part of the Python customary library) to deal with it for us.

If you happen to do need to perceive the intricacies of zlib and DEFLATE, try this article.

Implementing this in Python is useless easy:

idat = zlib.compress(filtered, stage=9) # stage 9 is most compression!

As famous, stage 9 is the utmost compression stage provided by the zlib library (and in addition the slowest). Different instruments corresponding to zopfli can supply even higher compression ratios, whereas nonetheless conforming to the zlib format.

Placing all of it Collectively

This is what our minimum-viable PNG author seems like in full:

import zlib

# https://www.w3.org/TR/2022/WD-png-3-20221025/#5PNG-file-signature
PNG_SIGNATURE = b'x89PNGrnx1an'

# https://www.w3.org/TR/2022/WD-png-3-20221025/#dfn-png-four-byte-unsigned-integer
# Helper perform to pack an int right into a "PNG 4-byte unsigned integer"
def encode_png_uint31(worth):
    if worth > 2**31 - 1:  # That is unlikely to ever occur!
    	elevate ValueError("Too massive!")
    return worth.to_bytes(4, "massive")

# https://www.w3.org/TR/2022/WD-png-3-20221025/#5Chunk-layout
def write_png_chunk(stream, chunk_type, chunk_data):
    # https://www.w3.org/TR/2022/WD-png-3-20221025/#5CRC-algorithm
    # Fortuitously, zlib's CRC32 implementation is suitable with PNG's spec:
    crc = zlib.crc32(chunk_type + chunk_data)

    stream.write(encode_png_uint31(len(chunk_data)))
    stream.write(chunk_type)
    stream.write(chunk_data)
    stream.write(crc.to_bytes(4, "massive"))

def encode_png_ihdr(
    	width,
    	peak,
    	bit_depth=8,           # bits per pattern
    	colour_type=2,         # 2 = "Truecolour" (RGB)
    	compression_method=0,  # 0 = zlib/DEFLATE (solely specified worth)
    	filter_method=0,       # 0 = "adaptive filtering" (solely specified worth)
    	interlace_method=0):   # 0 = no interlacing (1 = Adam7 interlacing)

    ihdr = b""
    ihdr += encode_png_uint31(width)
    ihdr += encode_png_uint31(peak)
    ihdr += bytes([
    	bit_depth,
    	colour_type,
    	compression_method,
    	filter_method,
    	interlace_method
    ])

    return ihdr

# That is all of the code required to learn subpixel values from an ".rgb" file.
# subpixel 0=R, 1=G, 2=B
def read_rgb_subpixel(rgb_data, width, x, y, subpixel):
    return rgb_data[3 * ((width * y) + x) + subpixel]

# Be aware: This perform assumes RGB pixel format!
# Be aware: This perform could possibly be written extra concisely by merely concatenating
# slices of rgb_data, however I need to use approachable syntax and preserve issues
# abstracted neatly.
def apply_png_filters(rgb_data, width, peak):
    # we'll work with an array of ints, and convert to bytes on the finish
    filtered = []
    for y in vary(peak):
    	filtered.append(0) # All the time filter kind 0 (none!)
    	for x in vary(width):
    		filtered += [
    			read_rgb_subpixel(rgb_data, width, x, y, 0), # R
    			read_rgb_subpixel(rgb_data, width, x, y, 1), # G
    			read_rgb_subpixel(rgb_data, width, x, y, 2)  # B
    		]
    return bytes(filtered)


if __name__ == "__main__":
    # These values are hardcoded as a result of the .rgb "format" has no metadata
    INPUT_WIDTH = 320
    INPUT_HEIGHT = 180
    # learn whole file as bytes
    input_rgb_data = open("./samples/hello_png.rgb", "rb").learn()

    ihdr = encode_png_ihdr(INPUT_WIDTH, INPUT_HEIGHT)

    filtered = apply_png_filters(input_rgb_data, INPUT_WIDTH, INPUT_HEIGHT)

    # Apply zlib compression
    idat = zlib.compress(filtered, stage=9) # stage 9 is most compression!

    with open("samples/out_1.png", "wb") as f: # open file for writing
    	f.write(PNG_SIGNATURE)
    	write_png_chunk(f, b"IHDR", ihdr)
    	write_png_chunk(f, b"IDAT", idat)
    	write_png_chunk(f, b"IEND", b"")

That is solely 87 traces of liberally commented and spaced-out Python code. If we run it, we get this output:

It is… precisely the identical because the one I confirmed earlier, which suggests it labored! We made a PNG from scratch! (Effectively, not fairly from scratch – we used zlib as a dependency).

Verifying it utilizing the pngcheck utility leads to the next:

$ pngcheck ./samples/out_1.png 
OK: ./samples/out_1.png (320x180, 24-bit RGB, non-interlaced, 15.6%).

Appears good! Now let’s take a look at some file sizes:

hello_png_original.png       128286 bytes
hello_png.rgb                172800 bytes
out_1.png                    145787 bytes

We began off with a 128286-byte PNG file, exported from GIMP utilizing the default settings.

We transformed it to a uncooked RGB bitmap utilizing ImageMagick, leading to 172800 bytes of information. Taking this because the “authentic” picture dimension, which means GIMP’s PNG encoder was in a position to compress it to 74% of its authentic dimension.

Our personal PNG encoder solely managed to compress it all the way down to 145787 bytes, which is 84% of the unique dimension. How did we find yourself 10% worse?

It is as a result of we cheaped out on our Filtering implementation. GIMP’s encoder chooses a filter kind for every row adaptively, most likely based mostly on heuristics (I have never bothered wanting on the specifics). If we applied the opposite filter sorts, and used heuristics to select between them, we would most likely get the identical or higher outcomes as GIMP. That is an train left to the reader – or possibly a future weblog publish from me!

As a fast instance, Adaptive Filter type 2 subtracts the byte values of the pixel above from these of the “present” pixel. If one row was equivalent (or comparable) to the row above it, the filtered model of that row would compress very effectively (as a result of it might be all or largely zeroes).

Full supply code and instance information can be found on my Git repo: https://github.com/DavidBuchanan314/hello_png

Issues I Did not Point out

Issues I did not point out on this article, which you should still need to know, embrace:

Help for different bit-depths.
Listed color (i.e. utilizing a palette)
Additional metadata, and other chunk types.
Interlacing.
The opposite filter sorts.
APNG.

…and possibly a couple of different issues I forgot. I’d replace this record after I keep in mind them.

PNG Debugging Ideas

If you happen to’re attempting to generate or parse your personal PNGs and operating into opaque errors, listed below are a few ideas.

Strive utilizing ImageMagick to transform the PNG into one other format (the vacation spot format does not matter). That is helpful as a result of it offers particular errors about what went flawed. For instance, if I attempt to convert the preliminary out_0.png picture we generated (which had the fundamental file construction however no knowledge), we get this:

$ convert samples/out_0.png /tmp/bla.png
convert: inadequate picture knowledge in file `samples/out_0.png' @ error/png.c/ReadPNGImage/4270.

This error is smart, as a result of IDAT was empty. You possibly can most likely observe down the precise line of png.c should you wished much more particulars.

My subsequent tip is to strive utilizing a sophisticated hex-editor like ImHex to examine the file. ImHex helps a “pattern” for PNG, which successfully offers you byte-level syntax highlighting, in addition to letting you view the parsed buildings of the file.

Associated Supplies and PNG Tips

I lately made a PNG/MD5 hashquine which various people wrote about and discussed, together with myself (I do plan on writing a correct weblog publish on it, ultimately).

I additionally found a bug in Apple’s PNG decoder, resulting from a poorly thought-out proprietary extension they made to the format. They’ve since mounted that occasion of the bug, though it is nonetheless attainable to set off it utilizing a barely totally different strategy. There was additionally associated discussion and articles.

I made a proposal for a backwards-compatible extension to the PNG file format that allows the PNG decoding course of to be parallelised. Others have made comparable proposals, and it’s likely that some variation will make it right into a future model of the official PNG specification.

I discovered an edge-case in Twitter’s picture add pipeline that enables PNG/ZIP polyglot information to be hosted on their CDN. Related article. I abused the identical trick to add web-streamable 4K 60fps video (a characteristic Twitter is but to formally help!).

PNG additionally helps “Adam7” interlacing, which I abused to create a crude type of animated PNG (with out utilizing APNG, heh). Related discussion.

Possibly now you consider me after I say it is my favorite file format?

Source Link