ImageMagick isn’t focused on artistic effects, so I’ve had to port over some of my work from PetesPlugins to give Funhouse Photo a bit more flair. So far I’ve added distortion maps, erode and dilate operators, and scaling an image to the size of another image. I will eventually try and merge what I can into the main branch, but for now my current source code is up at http://funhousepicture.com/ImageMagick-6.3.5.tar.
The first hurdle is compiling the stock ImageMagick code base. You can either download the source as a tar, or grab it from subversion. I very strongly recommend you stick to Linux, I didn’t have much luck with either the Windows or OS X versions I attempted. The source didn’t contain the VisualMagick folder that I needed for Windows compilation, and once I’d found that in a special WIndows version of the source tree, it turned out that they don’t ship any workspace files, but instead require the compilation of a utility to produce the project files. Since this utility requires MFC, it won’t work with Visual Studio Express, so I had to abandon Windows.
My next shot was on OS X, and I was anticipating a smooth Unix ride. Unfortunately, getting the libjpeg, libtiff and libpng libraries set up quickly turned into yak-shaving. I was several levels of recursion deep (using fink to grab the dependent libraries failed to persuade configure to find their headers, building them myself on OS X turned out to need obscure hand-hacking of libpng’s make files, which required strange changes to the IM code, etc), that I decided to give up on building locally, and stick to building remotely on my server, despite the long turnaround time on compiler errors.
Building IM on my Red Hat Fedora Linux server was super smooth. I just grabbed the source, ran yum install libjpeg-devel, etc to install the libraries I needed, and I was building in no time.
The architecture is split up into several different layers. I’ll cover the changes I needed to make to put in the erode and dilate operators. The lowest level is the base magick directory, and effect.c holds most of the base effect methods. There’s two versions of each method, one of which applies to all color channels, and is a stub passing in an ‘all channels’ flag as the channel mask to the second workhorse processing function that does all the actual work.
Once you’ve got methods in there, you need to let the interface layers know. There’s a lot of different interfaces to the base processing layer, including scripting, C++, Perl and a direct GUI, but I’m mostly interested in the command-line tools. Here’s the places I found I needed to add references to any new function, to make it visible to convert:
- magick/methods.h : Not sure about this one, but adding the declaration here didn’t hurt.
- wand/convert.c : You need to add an if (LocalCompare(<command name>)… clause into the massive ConvertImageCommand() function here, to make sure the argument is accepted by convert. You don’t actually do any work here, apart from validating the arguments.
- wand/mogrify.c : The actual image processing for convert is handled by mogrify, which focuses on dealing with a single image. You’ll need to add another string compare here in MogrifyImage(), and actually call the image processing commands on a match.
There’s other interfaces to IM that also need to be notified of any new operators, but since I don’t use them, and couldn’t test any changes, I’ve not looked into how to do that. You also need to do things a bit differently if you’re adding a composite operation, or an image sequence command, but I’ll cover those in a future article. I’ll also be asking the IM folks to look over this all, since I’m new to the code base.
Funhouse Photo User Count: 401 total, 116 active. Another steady day of growth, with 30% of the users active. I also had a sweet review from JasMine olMO, "i love this!! this is like the best mood app out there"!