Brief History of Images in Software

READ ALSO: Image Variants in Web Applications

READ ALSO: Images in Web Applications

Today the acronym JPEG is so popular to be rightfully considered a synonym to the same term image. Yet there was a time—and not even that many years ago—in which computer science progressed without it.

Let’s start with a brief history of images in the computers.

The World Before JPEG

Short for Joint Photographic Experts Group, the committee that developed the standard, JPEG solved a very specific problem of the late 1980s: photographic images were huge—at least for the computing and storage standards of the time—and there was no widely accepted standard for compressing them.

Before JPEG, there were already image formats, but they served different purposes. GIF, introduced by CompuServe in 1987, was designed around relatively simple graphics and was limited to 256 colors. TIFF, introduced by Aldus in 1986, could represent high-quality images, but it was essentially the raw pixel matrix multiplied by the color channel depth. Not to mention that the format describes a container of multiple images lossless or even lossy (using typically the LZW compression scheme). In the worst case the size was huge even for today standards; in best case it was barely acceptable for the standards of the time but not certainly for consumer applications.

By the way, LZW (Lempel–Ziv–Welch) is a lossless compression algorithm based on a simple idea: instead of storing repeated sequences of data over and over, LZW builds a dictionary of sequences and replaces them with short codes.

The problem that JPEG solved was enabling software applications to deal with real-world, continuous-tone images—essentially, photographs. A continuous-tone image is an image where colors or brightness change gradually, rather than being made mostly from a small set of discrete colors.

The ITU (International Telecommunication Union), a specialized agency of the United Nations, approved the JPEG standard back in 1992 paving the way for subsequent ISO/IEC standardization. It took a few more years, though, for it to propagate into common use by software applications. That mostly meant waiting for language and platform-specific libraries (C, C++, Pascal) to enable reading and saving files.

In the mid-1990s, I was personally involved in a startup willing to promote digital images—we built a consumer product called PcPhoto building albums out of scanned negative and printed photos. Later on, the same startup built a web platform that today will be the same as Flickr or iStockPhoto except that in 1996 nobody was really believing in the power of digital images. Consider the digital cameras became common in shops only around the millennium. The enterprise platform (named PROTO) was the last gasp of the startup before dying of lack of money.

Interesting is that that startup was building all of that without JPEG. I remember we integrated JPEG in the platform in the last release of 1997. We did that using Kodak libraries and just Kodak photo CD of the time were the only common source of JPEG images. Without JPEG, the startup I worked for licensed a proprietary fractal compression library capable of storing up to 30 images (nearly 640×480) in a floppy disk of 1.4MB. That fractal compression library—now vanished—produced FIF files, very quick to decompress but requiring dedicated hardware to compress in a decent amount of time.

Compared to FIF, the new JPEG standard was initially producing files bigger in size but overall slightly better in quality. I presented and argued FIF vs JPEG many times in those years. The truth is that FIF was better for those images naturally lending to be “fractalized” by the algorithm. JPEG offered a better trade-off (but I wasn’t allowed to say that…) and time showed it.

The JPEG Compression

JPEG is based on the Discrete Cosine Transform (DCT). Simply put, the image is divided into small blocks, typically 8×8. Then the DCT converts each block from pixel values into a set of frequency coefficients. Most of the visual information is concentrated in the lower-frequency coefficients, while higher-frequency coefficients represent fine details and rapid changes. So far so good. The trick is that then the algorithm quantizes these coefficients, deliberately reducing precision—especially for the higher frequencies. Note that quantization means reducing a number to one of a limited set of allowed values.

As a result, many small or high-frequency coefficients become zero. More in general, after quantization, you have lots of zeros and repeated/small values. which creates statistical patterns that can be represented very compactly. For example, instead of storing, say, 12, 0, 0, 0, 0, 0, 3, 0, 0, 0, …, you can encode the long runs of zeros much more efficiently. In particular, JPEG uses techniques such as run-length encoding followed by Huffman coding to exploit these patterns.

Clearly, quantization is the source of information loss. In short:

1. DCT changes the representation of the information
2. Quantization throws away some information
3. Entropy coding compresses (without loss) what remains

The impact of quantization was far higher for the smaller images of the early days of digital cameras. Today, with a smartphone capable of creating on the fly 4000×3000 pictures, quantization is probably undetectable by the human eye. And JPEG is just the standard serialization format for any image—regardless of its lossy nature.

JPEG and the Web

JPEG didn’t arrive because of the Web. But the Web arrived just as JPEG had become mature enough to make photographic images practical to transmit. A mere coincidence, but an enormously consequential one. Let’s review the timeline:

• 1991: CERN releases the Web software for external use; the first web site (and related server infrastructure) appears in December at Stanford.
• 1992: The JPEG standard is formalized after years of work on efficient compression of photographic images. Meanwhile, dozens of other sites appear surfed using rudimentary browsers. All of it takes place within research and academic communities.
• 1993: The National Center for Supercomputing Applications (NCSA) releases the first version of Mosaic—close to our definition of a web browser. Noticeably, the main developer is Marc Andreessen which will later co-found Netscape—the source of inspiration for Internet Explorer, Firefox and Chrome.

Finally, in April 1993, CERN made the Web software freely available, removing all licensing barriers. This simple action opened the floodgates, unleashing the Web as we know it today.

JPEG was particularly well suited to what the Web was beginning to carry. Its ability to compress photographic images made it an ideal format for transmitting photographs efficiently—for example, allowing museums to offer online previews of their collections. Interestingly, early Mosaic favored the GIF format for images rather than JPEG. JPEG support came shortly afterward. By 1994, Netscape—the browser that followed Mosaic—supported JPEG.

Using JPEG in Software

In the 1990s, using JPEG was no picnic. Consider that the libjpeg “official” library to read/write JPEG images was explicitly distributed with a disclaimer that it came with no warranty. Its historical license literally said, “We don’t promise that this software works.”

So, the sentence “There’s this JPEG format” did not carry the same meaning as “This JPEG is a practical production format for a consumer imaging system.” Images could be converted to JPEG manually from other formats using products like Photoshop or PhotoStyler (they were competitors till when Adobe bought and discontinued the latter) or created as illustrations and saved as JPEG. One more possibility was scanning printed photos to images as JPEG.

The Recent Years

JPEG had largely cleared the ground by the turn of the millennium. Digital cameras then made it straightforward for everyone to produce real-world images in a format that naturally fit the Web. The problem shifted: it was no longer simply how to put photographs online, but how to make images more versatile, expressive and efficient.

PNG was one of the first answers to that new challenge. Created in the mid-1990s, it brought lossless compression and, crucially, proper alpha transparency to the Web—making it possible to place an image cleanly over any background rather than being confined to a rectangular photograph. Standardized in 2001, SVG took the idea further by moving beyond pixels altogether, representing graphics as scalable shapes. Later formats such as WebP and AVIF continued the same evolution: better compression, higher color depth, transparency and little animation while remaining suitable for delivery over the Web.

The Arc of Time

The history of Web image formats is therefore not simply a succession of replacements centered around the emergence of JPEG. Each new format reflects a change in what we wanted images on the Web to do.

In the early days, it was mostly about compression: how to get pictures onto computers and, eventually, how to get photographs onto the Web without making the files impossibly large. But the story is not simply a quest for better compression. It is a progression from getting pictures onto computers, to getting photographs onto the Web, to making images composable and increasingly expressive—and ultimately making the Web’s visual language richer, more capable, and more efficient.