Most images (as least for a photographer) start in a camera. Mine arbitrarily assigns 180 DPI to them. The "dot" part is easy, it's point or pixel. But what about "inches"? What "inches" are we talking about here? Obviously there is no answer to this question, and DPI is a meaningless number in this case.
Images from a scanner will have a meaningful DPI telling us something about the scanning (it's clear what the inch is here). That does not mean however that I want to display images from the scanner at that same DPI as was used to scan them. For example, if I'm scanning a 35mm color slide, I might have a DPI of 2400, but I'd sure want to display the resulting image much larger than original size!
Below are two (downloadable) images, 160x100 pixels. The first has a DPI of 48, the second, a DPI of 192.
If I look at the above two files in a hex editor, they are identical, except for the bytes which store the value of DPI (0x0030 vs 0x00c0) and the date information. All the rest, in particular the number of pixels and the actual image content, is identical. They are the same images, with a small difference in meta data.
In most browsers (eg. Firefox, Safari, Internet Explorer), these two images will look identical: one image pixel is one display pixel.
In most picture viewers (eg. Mac's Preview, Windows photo viewer, Windows office picture manager), they will look identical.
In the few picture editors I use (eg. GIMP, Paint.NET), they look identical.
But, as I understand it, some versions of PhotoShop will show both differently, and, as I just found out, C#'s WPF also takes the DPI parameter in consideration when showing an image. It wasn't intuitively obvious to me how to bypass the WPF behavior: there is no way to modify the DPI of an arbitrary image. I find that quite amazing as it's just a single number, it should be trivial to change at load time, before WPF does anything with the image.
So, in summary, the concept of DPI does make sense in some contexts. Perhaps upstream when the image comes from a scanner. Perhaps downstream when the DPI provides size information for printing. But most of the time, esp. for general viewing, it's irrelevant.
In my photo club, I would say it's the top source of confusion when discussing image processing. Probably because of PhotoShop (GIMP never made me aware of DPI, altho it does know about it).
For my viewer, I finally found an approach that is reasonably elegant, but it took me a while to figure it out. That was the only major irritant I stumbled on as I learned C#/WPF. Except for that, I hadn't had so much fun programming as when I learned Java in the late 1990s. Writing a Windows app is so much easier with C#/WPF than with the Win32/GDI interface I had previously used.
Here's what the above two images looked like in the picture viewer I've been working on to learn WPF, with the default DPI handling of WPF.
And here's what I want to see for both images (160x100 pixels on screen), what it looks like once WPF has been convinced to ignore the image's DPI.
2015-July update: I've started working on a similar project (again, to learn) in JavaFX and in Python/wxPython, and this DPI problem does not arise in either environment. Both ignore the image's DPI.
Further reading: The myth of DPI (well worth it).
Home. Email: 
(français, English, Deutsch).