There is something weird: after the audio-only iPods came the iPods with images, but there are no iPods for videos (yet). However, we already have video podcasts, but there are to my knowledge hardly any picture podcasts? Why did we skip that medium? The hardware is there, the content is there.

So let’s see how hard this would be. At first glance, you would need the pictures, in an RSS, optionally automagically transferred to the photo device:

RSS with pictures

I found a couple of initiatives for putting images in an RSS so that they can easily be retrieved/manipulated:

Flickr: RSS with image enclosures 

this is the most straightforward and obvious implementation: using the same enclosure tag that made podcasting so simple. The only thing is: they do not include the image size (length=) attribute, probably for performance reasons, but this breaks the validation of the feed

Yahoo!: Media RSS 

a more recent effort from Yahoo! to include media files and associated meta-data into RSS. More meta-data means better search accuracy. They use an extra namespace xmlns:media="" which is probably the most correct way of doing it, but makes it unfit for podcast use (no podcatcher client recognizes their media:content tag, so nothing is downloaded). They do support multiple enclosures per post item (e.g. a high-quality MPEG-4 video, a low-quality – but faster downloaded – WMV alternative and a JPG screen shot for the same footage). Pheed RSS 

another extension of RSS 2.0, now with a xmlns:photo="" namespace. Same remarks as above: no podcast recognition. They also use the Dublin Core namespace, which is probably a good idea. 

Andreas had a proposal for changing the RSS2.0 standard, allowing multiple enclosures per item. Better go with the Yahoo! route for that, I guess.

My conclusions: you need the enclosure tag for compatibility with existing applications. You need the length= attribute for conformance to the RSS specs. So I’d start with what Flickr does, entend it with the length (even it’s just an estimation based on image pixel size, I don’t think many applications verify the actual size). But you could combine this with the Yahoo! Media RSS namespace (a bit like using the embed tag within the object for embedded media players) in the same feed.
Feedburner no longer adds image URLs as enclosures to their feeds (too many user problems, Eric Lunt tells me). So you cannot use Feedburner for constructing the RSS feed. (I tried it with Blogger and SmartCast and indeed, no success). They do support Yahoo! Media RSS as output format. They actually use the combination I described above. So we’re one step away from the perfect image feed constructor: Feedburner (optionally) enables image (JPEG/GIF/PNG) attachments to be converted to enclosures (with their usual automatic length= detection).

Transfer to device

I tried to use a mixed enclosure/MediaRSS feed in the iPodder podcast client, and it works like a charm. All references images are downloaded and stored under [iPodder download folder][Feed name][filename]. Whcih means you only have to specify the [iPodder download folder] as e.g. iTunes’ ‘Image root folder’ and all pictures will be synchronized with the iPod photo. Each feed is a separate folder, and a separate album on the iPod. Super! I guess the Doppler podcast aggregator would work as good.


Whether the pictures are consulted on a iPod or other portable multimedia device, or online in an aggregator or Bloglines, people can dream up a load of neat applications.

  • Gadget freaks could subscribe to an Engadget GSM ‘photo-cast’ of the latest must-have mobile phones. 
  • Parents could create a ‘kidcast’ for pictures of their newborn so the relatives can be automatically updated
  • casting directors could use a ‘casting-cast’ to get updated on new faces …
  • A TV channel could subscribe to the RSS’es of the main news agencies.
  • Simple: a PHP script that takes the RSS and shows your 5 most recent pictures in the side menu of your blog