The Definitive Guide to ImageMagick 173
Michael J. Ross writes "To modify a digital image, most computer users turn to a GUI-based image processing application, such as Photoshop. However, while Photoshop and many other similar programs can process multiple images in batch mode, they still require manual usage, and thus typically are unable to process images via a command line or within a second application. Those capabilities call for a programmatic digital image manipulation tool such as ImageMagick, which is explored in a relatively new book, The Definitive Guide to ImageMagick." Read the rest of Michael's review.
| The Definitive Guide to ImageMagick | |
| author | Michael Still |
| pages | 335 |
| publisher | Apress |
| rating | 7 |
| reviewer | Michael J. Ross |
| ISBN | 1590595904 |
| summary | An introduction to using ImageMagick for digital image manipulation. |
The author of this title is Michael Still, a programmer who gained experience with ImageMagick during his eight years of working on imaging applications, as well as writing articles on ImageMagick for IBM DeveloperWorks. Apress maintains a Web page for the title, where a visitor can purchase the electronic version of the book, read its table of contents, or download its source code or a sample chapter (Chapter 4 — Using Other ImageMagick Tools) in PDF format. They also have a link where readers can submit errata — and apparently be the first to do so, as there are no existing errata listed on the Web page.
The book's 335 pages are organized into a dozen chapters, following an introduction and a few other standard sections, including a forward written by ImageMagick's principal architect, Christy, who briefly explains the product's 20 years of history, development, and lack of decent documentation. That is where this book is intended to fill the gap, and Christy notes that most future questions about ImageMagick will be answered by pointing people to this book, as is also noted on ImageMagick's homepage.
The first chapter of the book explains how to install and configure ImageMagick, for several Linux distros, as well as Microsoft Windows — using the precompiled versions, or by compiling from ImageMagick's source code. The chapter is wrapped up with a brief description of ImageMagick's online help, debug output, verbose output, and version information. The next ten chapters fall into two categories: ImageMagick usage as a standalone, and from within other applications. The first category of chapters covers basic image manipulation, compression, other metadata, ImageMagick tools, artistic transformations, other image transformations, and drawing commands. The second category discusses how to utilize ImageMagick from within programs written in Perl, C, Ruby, and PHP. The 12th and final chapter is quite brief, and describes where to find online help (Web sites, blogs, mailing lists, and forums) and where to report any apparent bug in ImageMagick.
For Windows users, the first chapter may begin badly, as the author fails to explain which precompiled version the reader should select if they wish to install ImageMagick on a Windows PC. For each version, there are four flavors to choose from. But which one is right for the reader? "static" vs. "dll?" "Q16" vs. "Q8?" What are the differences? The ImageMagick Web site and FTP file listings appear to have no README file or installation help file to explain which flavor you should download. The book should provide some assistance here, but does not. The former topic, static versus DLL, is mentioned only in reference to compiling ImageMagick from source — information which the reader will probably never see, should they choose to install the precompiled binaries and get started on ImageMagick as quickly as possible.
The latter topic is not covered at all — not even in the index, where a "quantum depth" entry would be useful. For those readers who are interested, "Q8" indicates 8 bits-per-pixel components, and "Q16" means 16 bits-per-pixel. The latter allows one to read or write 16-bit images without losing precision, but requires twice as much resources as Q8. Apparently Q16 is the best choice for medical or scientific images, or those with limited contrast. Otherwise, Q8 should be sufficient, and offers greater performance.
The material most likely to be read, referenced, and valued in this book, is the chapters devoted to explaining how to use ImageMagick for resizing, compressing, transforming, and drawing digital images. Most of these first-category chapters begin with a concise summary of the theory put into practice throughout the rest of the respective chapter — a wise inclusion in each case, since even the most experienced computer programmers and other users have had no instruction or experience in image theory. All of these chapters do a competent job of explaining what each ImageMagick command is used for, and then illustrating it with a straightforward example.
The most glaring deficiency in these chapters, and the book as a whole, is that far too many of the book's figures (digital images, naturally) fail to reflect what is intended to be conveyed by each figure. This is primarily because they are all in black-and-white, and in many cases do not offer the size and resolution necessary. In other words, there are many cases where the "before" and "after" images look almost identical. In the cases of color manipulation, most of those black-and-white images are of little value — occasionally laughably so.
The second-category chapters, covering ImageMagick usage with Perl, C, Ruby, and PHP, proved disappointing, primarily due to their narrow focus, and lack of tips, recommendations, and coverage of the APIs' capabilities. The details are presented in the form of a single example for each language. For instance, the Perl chapter devotes too many pages to source code listings of a Perl program written by the author, that few readers would probably download from the publisher's Web site, much less read.
Nonetheless, this book should be useful to any programmer interested in making the most of ImageMagick's capabilities, and that is not just because it is the only ImageMagick book on the market. Michael Still certainly had his work cut out for him when he agreed to document the bulk of what ImageMagick can do. It is unfortunate that the color images that he created for the book cannot be seen by the reader, and that the Windows binary versions and ImageMagick APIs, were given short shrift. We can hope that future editions of this book will be significantly strengthened, such as including color and higher resolution images where needed — even if it requires grouping them together within the book, if that reduces production costs.
Lastly, it should be mentioned that, as a smaller technical publisher, Apress is not resting on its laurels, and is not only scheduled to release an impressive variety of programming books this year, but their customer support — at least in my experience — was outstanding, as there was a problem with the shipping of this title, and they bent over backwards to make it right.
Michael J. Ross is a freelance writer, computer consultant, and the editor of the free newsletter of PristinePlanet.com."
You can purchase The Definitive Guide to ImageMagick from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
yes, you can command line photoshop (Score:4, Interesting)
Re:Manual vs. Automatic (Score:3, Interesting)
In my senior year of college, we came up with a project to create an online photo storage and editing site much like Yahoo's Flickr. This site allowed users to crop photos, transform pictures to black and white, and adjust contrast amongst other things. We used ImageMagick to do all this, shooting in actions from the command line.
Re:yes, you can command line photoshop (Score:0, Interesting)
Flickr Hacks (Score:4, Interesting)
Re:yes, you can command line photoshop (Score:5, Interesting)
Probably not, but I think it's kinda silly. If you're on a machine where you're worried about spawning off one more process, I feel sorry for you.
Remember, there's More Than One Way To Do It. That's kinda the beauty of Unix. I do like that 'for i in *.jpg' takes a lot fewer keystrokes, mind, but just because it uses fewer keystrokes and doesn't exec ls doesn't make it the Only Right Way.
Indeed, for some things, it may not be the Right Way at all. Ferinstance:
for i in `ls fullsize`
do
convert -scale 800x800 fullsize/$i $i
convert -scale 150x150 fullsize/$i thumbnails/$i
done
It's cheaper to exec ls here than it is to crunch $i each time to strip 'fullsize/' off the front. If you really wanted to streamline it (and if you're that worried about it, why the heck are you writing a shell script?) you could throw $PWD at a temporary variable, cd into fullsize, run your converts, but why bother with the extra typing or lines of code when this runs correctly, makes sense, and is only exec'ing the ls once?
But really what it boils down to, to me, is if exec'ing ls once instead of using the shell builtin * is causing problems on your system, you've got bigger problems than your shellscript-fu.
-F
Re:I am a photographer... (Score:3, Interesting)
6x6 and 4x5 give tonality identical to digital with any film and you can enlarge much more while still seeing increasing detail. They're much more bothersome to scan though (no batch scan).
Re:check out netpbm too (Score:3, Interesting)
I couldn't agree more. For a start, a single monolithic app like ImageMagick is just not the Unix way. It means that to add functionality, you need to recompile the application. With netpbm, if you want a new feature, you just write a filter and stick it in the pipeline. Much easier, and much more flexible. In the past, my only gripe was that netpbm (and pbmplus before it) was unable to handle transparency in image. Fortunately, that's no longer the case, and recent versions are able to do so. Plus, with my (admittedly not very scientific) tests, netpbm comes out slightly faster for the tasks I perform anyway (mostly cropping and scaling). I can highly recommend netpbm.
Re:Manual vs. Automatic (Score:4, Interesting)
The original developer had his "submit image here" web page load the image into some Windows "object" format, and then do a bunch of tests, like 'reject if is it > 500 pixels wide' and 'warn if color depth > 2' and 'reject if not .BMP format'. But this is horrible for the users -- they may not have the image in the required format, and some won't have the knowledge to get it into the format we require.
I told him to just inline imagemagick's convert function, and output the exact format he requires. The sanitization is now very simple: if imagemagick can read it and successfully convert it to the desired format, it's good. That means we don't even have to tell our users to use .BMP or .GIF or .whatever -- if they can get us an image in a format recognized by imagemagick, we can use it. We've published guidelines that say "if you make your image conform to such-and-such attributes, our output will be as good as we can possibly make it." We're not promising an image that is horribly tortured by Imagemagick will print as well as they desire, but at least our app won't crash if they try to feed us garbage, or try to blow us up with a 10MB .TIFF or .WMF.
Two words: UNSTABLE API (Score:3, Interesting)
If you wish to write your own programs using a powerful image-processing library, you will, most likely, prefer the fork of ImageMagick called GraphicsMagick [graphicsmagick.org].