IkiWiki::Plugin::img appends [$pagenumber] to the filename to deal with multipage documents such as PDFs. However, Image::Magick doesn't seem to like page selection for filenames containing a colon. This is also the case for imagemagick binaries:

$ identify 'screenshot_2015-06-06_18:37:53.png'
screenshot_2015-06-06_18:37:53.png PNG 453x122 453x122+0+0 8-bit sRGB 11.2KB 0.000u 0:00.000
$ identify 'screenshot_2015-06-06_18:37:53.png[0]'
identify: no decode delegate for this image format `37' @ error/constitute.c/ReadImage/501.
$ mv 'screenshot_2015-06-06_18:37:53.png' 'screenshot_2015-06-06_18-37-53.png'
$ identify 'screenshot_2015-06-06_18-37-53.png[0]'
screenshot_2015-06-06_18-37-53.png[0]=>screenshot_2015-06-06_18-37-53.png PNG 453x122 453x122+0+0 8-bit sRGB 11.2KB 0.000u 0:00.000

This might be an imagemagick bug, but it's also possible that colons are interpreted somehow.

Yes they are: ImageMagick has syntax to force the file to be interpreted as a particular format, like gif:foobar.img to read foobar.img as a GIF, or to use unusual I/O patterns, like fd:5. --smcv

Anyway, to render such images properly in ikiwiki I had to remove the colons. An easy fix is to remove ‘:’ from wiki_file_chars, but this can break existing installations.

I think we should remove : from the default wiki_file_chars either as soon as we have a way to handle backwards compatibility, or in ikiwiki 4; but you're right that it's a compat problem, so we can't just do that as a solution. --s

A better solution would be to make IkiWiki::Plugin::img croak on such image filenames (which anyway are currently not rendered, but Image::Magick's error message is quite cryptic).

Better still would be to fix the bug by escaping the filename so ImageMagick treats it as just a filename. It seems the way to do that is to call Read(":hello:world.png") instead of Read("hello:world.png"), which I have now done. --s