Tag Archives: JPEG

The GIF row


Illustration of different types of the Graphic...
Illustration of different types of the Graphics Interchange Format (GIF). (Photo credit: Wikipedia)

As you may have seen the inventor of the GIF- graphics interchange format – Steve Wilhite, has said that it should be pronounced “jif” and not “gif” (with a hard-g).

More to the point – unless you are using the animated format – you should not be using a GIF at all. Either (for photographs) use a JPEG or (for line drawings or ant graphic with 256 or less distinct colours) use a PNG.

JPEGs and PNGs, when used properly, give better quality renditions from smaller files and are essentially universally supported in browsers these days.

(If you want to know more then I recommend PNG: The Definitive Guide – nominally it is out of print but you can pick up a second-hand copy on Amazon for pennies. You can also look for Image::Pngslimmer on CPAN if you are a Perl hacker – I wrote that!)

Betamax versus VHS in your browser


Everyone knows the story, even if, unlike me, they are not old enough to remember it: the video format VHS overcame the superior Betamax format to dominate the Mitt Romney laughing GIFhome video market in the 80s and 90s.

Of course, the claims that Beta was superior are rather tendentious but the fact that video producers stuck with a Beta format for their own tapes long after the rest of us switched to a VHS monoculture must say something.

Now, inside your browser, the same thing has happened. As is noted in today’s Guardian, the 1987-vintage GIF format refuses to die. These days you see far fewer static GIFs than even a few years ago (though they are still out there in large numbers) – JPEG and PNG dominate. But you’ll have to look very hard for an MNG (the ‘official’ PNG analogue of the animated GIF) or even APNGs, the unofficial but more widely used attempt to animate PNGs.

A few years ago I wrote a Perl PNG module – Image::Pngslimmer – which replicated many of the functions of the C libpng library, so I could use some of that in CGI code without having to switch from Perl to C and back again. Then – this was 2006 or so – PNG support was quite weak in browsers and GIFs were far more plentiful.

PNG is a superior format to GIF (especially for line drawings and similar – for general photographs JPEG is the superior choice, unless you truly demand a lossless format) and it is a good thing that it has edged GIF out in many places. But it seems we will be stuck with GIFs for many years yet.

More people getting it wrong about graphics formats


I subscribe to the Code Project mailing list. So every day I get an email with some links. Some stories are good (I started this blog in response to one). Some are very poor: I highlighted an earlier one about graphics formats like that.

And today I am going to do the same thing. Admittedly this one is not quite so poor. But it is still fundamentally wrong when it says

Portable Network Graphics
Image via Wikipedia

PNG is a lossless format. It is not. It may be lossless, and most PNGs out there are likely to be lossless, but stating that it is lossless a priori is just WRONG.

PNGs may be lossy – particularly if colour quantization is applied.

Furthermore PNGs are not magic machines that defy the third law of thermodynamics. If you have a lossy graphic – eg if your camera only produces compressed JPEGs then storing it as a PNG will not magic away the losses.

Horses for courses people: or, as we say in the trade, it’s a heuristic not an algorithm. There is not likely to be any simple answer to your question “what is the best format to use”: though in most cases JPEGs are the right format for (online) presentations of real world objects and PNGs are likely the best options for line drawings online (though maybe you will want to use SVG for that if they are generated programmatically).

Some advice you should ignore


I have an interest in graphic formats – I wrote the perl package Image::Pngslimmer a while back when I was hacking some perl database code that delivered (via Ajax) graphs and photographs.

I built the whole website for fun and learning purposes and so therefore used PNG graphics when JPEGs would have (for the photographs at least) been more appropriate.

So, therefore an article that begins:

Virtually every developer will use bitmaps at times in their programming. Or if not in their programming, then in a website, blog, or family photos. Yet many of us don’t know the trade-offs between a GIF, JPEG, or PNG file – and there are some major differences there. This is a short post on the basics which will be sufficient for most, and a good start for the rest. Most of this I learned as a game developer (inc. Enemy Nations) where you do need a deep understanding of graphics.

has my attention.

But what a load of rubbish it turns out to be. The author plainly doesn’t know what the “trade-offs” are either as he states:

PNG – 32-bit (or less), lossless compression, small file sizes – what’s not to like. Older versions of some browsers (like Internet Explorer) would display the transparent pixels with an off-white color but the newer versions handle it properly. Use this (in 32-bit mode using 8 bits for transparency) for everything.

…and…

JPEG – 24-bit only (i.e. no transparency), lossy (can be lossless but compressions drops a lot), small file sizes. There is no reason to use this format unless you have significant numbers of people using old browsers. It’s not a bad format, but it is inferior to PNG with no advantages.

This is seriously bad advice and it is also technically wrong.

First, PNG is not a lossless format. Many PNGs are indeed lossless, but they do not have to be.  A substantial part of the  code in the Image::Pngslimmer package is about using the median cut algorithm to produce a lossy PNG out of a lossless one by producing a best match set of colours for the image and then converting pixels to the colour in the set which is closest to them in RGB space (the median cut algorithm ensures that there are more members of the set in the bits of RGB space where there are more colours in the original image).

Second, JPEG remains by far the best way of representing photographs in the real world internet, where the trade-off between size and quality is important.  Look closely at the colour boundaries in a JPEG, especially a highly compressed one, and you can see how the edges are blurred and colours cross the boundaries – that is an artefact of the compression and indeed represents a loss (once compressed in this way the quality of the original image cannot be recovered). But it is also a highly efficient algorithm and can produce much smaller image files than the lossless PNG equivalent without any noticeable dimunition in quality for the average viewer.

As a parallel think of MP3s and FLACs for audio. Like FLACs, PNGs (can be) lossless and compressed – so delivering a much smaller file than the source WAV or similar file. But MP3s can be much smaller again without any noticeable dimunition in quality for most people on most equipment.

Yes, more and more people are connecting at 25Mb/s, but then more and more people are also connecting using GPRS, EDGE and low bandwidth 3G connections. Size still matters.

PNG is absolutely superior for representing line drawings (including artefacts such as graphs) as no one wants to see the lines start to fuzz. But that is a pretty limited subset of images on the internet.

So here is some proper advice: use JPEGs (at about 85% compression) for almost all photographs you want to put on the internet. If you have a line drawing or similar, prefer PNGs. If you have a truly lossless image (remember someone may have compressed it before it gets to you) and you need to keep it that way, then use the PNG format: but expect your file size to be very large.