Tom Arah weighs up whether Microsoft’s new HD Photo format is good news or bad.

You might think that Microsoft’s recent announcement of its new continuous tone bitmap format, Windows Media Photo – since renamed HD Photo - would be greeted with universal acclaim...
After all, JPEG is such a central workhorse that a new improved “JPEG-killer” must surely be good news. In fact my initial reaction, along with that of the majority of professional designers, was a combination of shock, horror and anger.
To understand why, it’s necessary to look back at the history of bitmap formats to appreciate just what an important role JPEG plays. Back at the dawn of personal computing (around 25 years ago) Microsoft started its rise to power by developing the MS-DOS operating system for IBM PCs. MS-DOS provided an amazingly crude character-based interface but, spurred on by the Apple Mac, Microsoft developed its own graphical user interface, Windows, which needed a graphics file format to manage the display of onscreen pixels. Microsoft’s solution, used internally by Windows’ Graphics Device Interface (GDI), was the BMP (Windows Bitmap) format. To compress the file size of stored BMPs a simple system of RLE (Run Length Encoding) was employed which consolidated runs rather than representing each and every pixel (for example 8B4W rather than BBBBBBBBWWWW) – a system that was particularly effective for the first computer graphics composed of solid blocks of colour.
For the earliest monochrome screens a simple on-off grid, the eponymous 1-bit “bitmap”, was all that was needed to control the display but by varying RGB phosphor intensities in the same way as a TV does, a new world of colour was opened up. By increasing “bit-depth”, that is storing more than one bit of information per pixel, it was possible to extend the number of colours stored in a graphic so that 4-bits could handle 16 colours (2^4) while 8-bits (2^8) could handle 256. Being able to handle 256 colours extends the creative options greatly – enabling gradients and drop shadows for example as well as flat areas of solid colour - but with fewer runs for RLE to work with the resulting BMP file size increases dramatically. The solution was to turn to more advanced file formats based on more advanced compression, most obviously the LZW (Lempel-Ziv-Welch) algorithm which looks not just for runs but for repeat strings (think words rather than characters). LZW compression was the secret behind the success of the most notable third-party image formats GIF (Graphics Interchange Format) and the must useful because smallest flavour of the flexible TIFF (Tagged Image File Format).

Early computer graphics dealt with indexed bitmaps based on solid areas of colour

The advent of 256 colours was an important staging post but the move towards higher bit-depths was inevitable. And by moving to storing 8-bits, and so one of 256 possible values, for each of the three - Red, Green and Blue - components of each pixel, colour values could now be encoded directly rather than via an indexed palette. More significant for the end user was the fact that the resulting 24-bit images could now handle up to 16 million colours (256x256x256): continuous tone images. Photographs had arrived on the computer.
However the move to 24-bit encoding and continuous tones led to a serious problem. In a photographic image the colour of each pixel is likely to vary pretty much randomly from its neighbours which gives nothing for RLE or LZW compression to work with. From Microsoft’s programming perspective this was of little concern – a locally stored, display resolution, 24-bit BMP might be profligate in terms of disk space but it shifted data quickly and was adequate if all you cared about was the odd splash screen. From the design perspective however, the spread of desktop scanners made digitized photographs common currency and, when you needed to be able to store and transfer multiple, high-resolution 24-bit images, file size became a massive issue especially when storage and later bandwidth were both limited and expensive.
The white knight that rode in to rescue the day was the Joint Photographic Experts Group (JPEG). The JPEG compression scheme that this committee of interested parties developed back in 1990 was revolutionary. It converts the 24-bits of RGB data to a different colour space called YCbCr (where Y handles luminance and the Cb and Cr channels handle colour) then downsamples the Cb and Cr components (usually by a factor of 2 both horizontally and vertically) as the eye is far more attuned to variation in brightness than colour. It then breaks each channel into 8x8 pixel tiles and applies a Discrete Cosine Transform (DCT) to convert it into a “frequency space”. As the eye is not particularly good at distinguishing the exact strength of high frequency brightness variation this opens up scope for quantizing the results and this stage can be more or less aggressive trading-off file size against end quality.
The high compression ratio enabled by JPEG’s “lossy” approach (meaning the process isn’t fully reversible to restore the original pixel values), the control over the level of compression that the quantization stage provides and the practical limitations of human vision are the secret of JPEG’s success. Typically they mean that JPEG can achieve 10:1 to 20:1 compression without visible loss, up to 50:1 compression if moderate defects – seen as blocky artifacts – are acceptable and up to 100:1 if all you want is a recognizable but low-quality representation.