I've recently implemented a neat abstraction in Graphic-Forms. For quite a while now, it has been possible to load image files from disk so that they may be displayed. Until recently, I required the use of ImageMagick to handle the file loading task. It's a very nice library, and I have a small binding implemented for the MagickCore API which is the low-level C-based API. But it's also heavyweight -- your process ends up loading quite a large number of DLLs due to interdependencies in their code, and what's possibly worse is that you pretty much have to do a 'real' install because their code expects certain registry entries and directory structures to exist.
What I've done is to create a simple plugin mechanism, the key aspect of which is implementation of a bit of code in each plugin to translate from library-specific representation of image formats to the Graphic-Forms IMAGE-DATA class. The latter is then what the main library code consumes for image creation and attribute querying. When an image file is to be loaded, each registered plugin is given a chance and the first to succeed wins.
Based on that mechanism, I've now implemented an ImageMagick plugin that you can use if you need to handle more formats besides BMP and ICO. Or if those two formats are all you need, you can load the 'default' plugin which has Lisp code that understands those two formats directly. You can implement additional plugins in application code if you want to use some other graphics library; I plan to document how to do this in the next release.
By the way, another benefit of this strategy is that you can write pixel processing code in terms of IMAGE-DATA or in terms of the external library of your choice, and then create IMAGE instances using IMAGE-DATA as input to display the result.