Forgot your password?
typodupeerror

The Definitive Guide to ImageMagick 173

Posted by samzenpus
from the worth-a-thousand-words dept.
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.
This discussion has been archived. No new comments can be posted.

The Definitive Guide to ImageMagick

Comments Filter:
  • by Anonymous Coward on Monday March 13, 2006 @01:51PM (#14909013)
    Just create an action which does what you want, then you can export an "EXE" which takes as command line argument the file you want to process, and optionally, the output. Works like a charm.
    • by Anonymous Coward on Monday March 13, 2006 @01:59PM (#14909089)
      Oh, yes, that's much easier than
      for img in `ls *.jpg`
      do
        convert -sample 25%x25% $img thumb-$img
      done
      And the million other things you can do from the command line without making task-specific exes.

      • by pclminion (145572) on Monday March 13, 2006 @02:21PM (#14909283)
        for img in `ls *.jpg`

        Am I the only person who laughed out loud?

        • only after you pointed it out. I kind of scanned over it and missed it the the first time ;) .
          Yeah, that was a rookie move.
        • by foxtrot (14140) on Monday March 13, 2006 @03:14PM (#14909788)
          Am I the only person who laughed out loud?

          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
        • for img in `ls *.jpg`


          Am I the only person who laughed out loud?

          Given the syntaxtical bedlam that is shell scripting, most who got the "joke" are long past the point of amusement.
      • You know, I don't know what the problem is but whenever I try to do a large batch (20 or so images) with ImageMagick inside a loop it hangs my machine. It only started happening when I upgraded to a 7MP camera and the images (not at full resolution either!) were in the 4.5MB range.

        Now I have to break the images up into batches of 5 and run the script each time for those. Bleh.
        • if you're using windows, and are taking directly from the camera or memory card, it's a bug in the Mass storage class driver.

          The MSC driver can hard lock (requireng removal of the USB device).

          If the problem happens no matter where you locate the images (local hd) then it've got no clue what your problem is. but from the sounds of it you've been using IM to parse pics from your cmaera directly to some local folder, likely the new camaera has faster memory that causes the MSC lock up issue (it does not happen
        • I've got no problem with 85MB files (14MPix 16b tiffs). But when I do my 6x6 and 4x5 stuff I have to let it run all night (768MB RAM, Athlon 2600+, Linux 2.6).
    • Command-line control implies a bit more than creation of a canned .exe file. OK, let's say I need to automate the creation of graphical "Tabs" for a web layout. They have to contain text (determined at runtime from, say, a database), blended and drop-shadowed. Can I do this using the technique you mentioned? Nope. I can do it in imagemagick though.
      • Well, you have to do the detail-work on your own, but ImageMagick has an option to add text to an image using the font of your choice. Someone correct me if I'm wrong, but there isn't a drop-shadow option, and I'm not sure what you mean by blend.

        Personally, I'm having a bitch of a time trying to extract a portion of an image into a separate file w/ ImageMagick (and have the target image actually cropped). At this point, I don't think it can be done. Which is why I wish Gimp had a client-server interface f

        • $ convert -crop widthxheight+xoffset+yoffset filename1 filename2

          If you want to overwrite the original then use the more dangerous

          $ mogrify -crop widthxheight+xoffset+yoffset filename

          This book sounds as though it is very necessary.
    • On Windows, maybe. But what about Linux? And what are the license restrictions for including the exported EXE with other applications?
    • by tpgp (48001) on Monday March 13, 2006 @02:10PM (#14909195) Homepage
      Just create an action which does what you want, then you can export an "EXE" which takes as command line argument the file you want to process, and optionally, the output. Works like a charm.

      Maybe the author should have said 'useful commmand line processing' or similar.

      1) Exes are not very useful for osx or linux users.

      2) You need a copy of photoshop for every server you wish to run your exported exe on.

      3) You have to create a different 'exe' for each action.

      Photoshop is not even slightly useful for the sort of areas that imagemagick excels in.
      • by Anonymous Coward
        As a long-time Photoshop user, I completely agree - exporting Actions as an .exe is useful in only a limited way.

        And I don't think Adobe would disagree with you. For large-scale image processing (including the ability to alter a Photoshop text layer dynamically), there is the Adobe Graphics Server (see http://www.adobe.com/products/server/graphics/main .html [adobe.com]).

        It isn't cheap ($7500 per CPU, with a 2-CPU minimum I think). And it is only supported on Windows Server versions and Solaris. But it's the only produ
    • by base_chakra (230686) on Monday March 13, 2006 @02:13PM (#14909212)
      Just create an action which does what you want, then you can export an "EXE" which takes as command line argument the file you want to process, and optionally, the output. Works like a charm.

      I've batch-processed sets comprising about 2,500–4,000 images (greyscale GIFs) both with command-line tools and with Photoshop CS. On each occasion, Photoshop took several hours longer than the specialized CLI apps to complete the jobs. The difference is even more dramatic when executing Photoshop Actions from within Photoshop, since the screen updates further increase processing time (an effect only slightly mitigated by hiding subwindows).
    • Yes its true - you can script things with javascript in photoshop and it is every bit as impressive as imagemagik.
      • No it's not. You have to reach into Photoshop with 'javascript' in order to get any use of it at all. With imagemagick the whole toolset is a collection of standalone executables, which you can write scripts for in any imaginable scripting language.

        It's a significant difference.

        Further, I can download and build imagemagick from source on any of the various machines I have in my posession that I run NetBSD on. The Adobe product is binary only for two fairly limiting platforms.
    • A friend of mine uses Photoshop "batch" processing, and he is always cursing it. It is very slow, image DPIs are frequently messed up, and if the entire process frequently implodes if he puts any other load on the system. I showed him how to do the same thing in ImageMagick in only five minutes with flawless results. He said it was "too difficult". It takes him about a week to get a camera load of images up on the web. It takes me an hour, with 55 minutes of that hour being typing in the captions. Sigh.
    • Uh, like on Solaris in a web application enviornment where you are getting 1000 imageing requests a second? No way, in that scenario ImageMagick is one of the only tools that really wins. Sir, with respecet I say you are not tuned into what ImageMagick is really for!
  • by tetrahedrassface (675645) on Monday March 13, 2006 @01:58PM (#14909084) Journal
    Imagemagick is good stuff, ive used it for a while now. Although I didn't buy a book to learn how, i just went here, for some great samples of uses:
    http://www.cit.gu.edu.au/~anthony/graphics/imagick 6/ [gu.edu.au]
    PIL isn't too shabby either http://www.pythonware.com/library/pil/handbook/ind ex.htm [pythonware.com]
    Powerful stuff, maybe the book is not that great i don't know, but imagemagick and PIL are!
    • Antony's examples are great, you can learn a lot about image processing. I do wish it at more of the "artistic filters" that photo shop and other have. (I'm pretty sure they are possible w/ the tools, they are just heavy in the fx commands.
  • by digitaldc (879047) * on Monday March 13, 2006 @01:59PM (#14909090)
    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.

    Haha, that was funny...well if you need to see what it actually does, their examples site [imagemagick.org] has some better images.
  • GraphicConverter (Score:3, Informative)

    by andyring (100627) on Monday March 13, 2006 @02:01PM (#14909108) Homepage
    GraphicConverter on the Mac has some fairly powerful built-in scripting/workflows you can specify for a whole bunch of photos at once. And, it's shareware too. Such as I've used it to all at one time for 100+ photos, perform an "auto levels", reduce the file size so they're easier to e-mail, and create a basic thumbnail Web-ready batch. You can do probably 100 or more tasks this way.
    • Free Software > shareware.

      Also, ImageMagick is more useful for integration with Unix-style shell scripts (as opposed to Automator actions or Applescript, which I suspect GraphicConverter would support instead).
    • GraphicConverter on the Mac has some fairly powerful built-in scripting/workflows you can specify for a whole bunch of photos at once.

      Not even remotely like imagemagick - why don't you just download the os x [finkproject.org] native port?

      And, it's shareware too.

      From the GraphicConverter website [lemkesoft.de]:

      The shareware fee is $30.

      I don't even know what shareware means anymore - $30?

      Such as I've used it to all at one time for 100+ photos, perform an "auto levels", reduce the file size so they're easier to e-mail, and create a basic t

      • $30, for a very useful and professional app is good. Did you expect it to be $5 or something?

        Hell, I've been using GC for almost a decade as my default image viewer on the Mac, well worth such a small cost.
  • by tcopeland (32225) * <(tom) (at) (thomasleecopeland.com)> on Monday March 13, 2006 @02:05PM (#14909151) Homepage
    I did some nice charts [blogs.com] for the indi [getindi.com] admin pages; worked out really nicely thanks to Gruff + RMagick.

    I did have a spot of trouble getting the fonts working at first, but once that was fixed, it was easy to create some nice charts with very little code.
  • Wikipedia uses it (Score:5, Informative)

    by interiot (50685) on Monday March 13, 2006 @02:19PM (#14909259) Homepage
    For what it's worth, Wikipedia uses ImageMagick to automatically resize png/jpeg/gif images for articles (eg. photos uploaded at 1920x1080 can be displayed at 300x169 in an article). So it's good enough to run on a high-traffic website (and is pretty flexible for ad-hoc command-line use too).
    • Re:Wikipedia uses it (Score:4, Informative)

      by theurge14 (820596) * on Monday March 13, 2006 @04:50PM (#14910594)
      Just to clarify, ImageMagick is not called everytime someone views that smaller thumbnail everytime they view the Wikipedia article, ImageMagick is called upon only when the orginal article was edited, the output is saved by MediaWiki as a totally new image into an images folder. From then on, it's a straight HTML img tag.

      I just wanted to make sure people didn't think ImageMagick is being called upon the MediaWiki software every time the image got a page hit.
  • by PeeAitchPee (712652) on Monday March 13, 2006 @02:20PM (#14909265)
    ImageMagick's function library is also accessible through a variety of APIs for your favorite language [imagemagick.org] -- scripting or otherwise. If you haven't used it, try it . . . it's GPL and it Rawks (with a capital "r"). ;-)
    • ImageMagick's function library is also accessible through a variety of APIs for your favorite language -- scripting or otherwise. If you haven't used it, try it . . . it's GPL and it Rawks (with a capital "r"). ;-)

      While I use (and love) ImageMagick, it's worth noting that Photoshop has similar (but not totally analogous) capabilites:

      http://partners.adobe.com/public/developer/en/phot oshop/sdk/PhotoshopScriptingGuide.pdf [adobe.com]

      Unfortunately, Photoshop's scripting host only supports JavaScript, VBScript, and AppleSc
    • ImageMagick's function library is also accessible through a variety of APIs for your favorite language
      My favorite language (OCaml) is not there :( (although there appears to be Ocaml APIs developped elsewhere)
    • Actually, it's not GPL -- ImageMagick can be used in commercial products as well, more like the LGPL (but it's not that either, it's its own license).
      • While it's true that ImageMagick isn't licensed under the GPL, I hope nobody comes away thinking that licensing under the GPL precludes commercial distribution or incorporation into a commercial program. That's never been the case.

        Being licensed under the GNU General Public License doesn't preclude use in commercial software. In fact, many GPL-covered programs are commercially distributed and some even have remarkably lucrative consultancies developing them (such as GCC).

        Furthermore, one can build on GPL-
  • Flickr Hacks (Score:4, Interesting)

    by jbum (121617) on Monday March 13, 2006 @02:33PM (#14909389)
    My book, Flickr Hacks [amazon.com], contains a number of examples of using ImageMagick (via the Perl API) with Flickr. This is one area where it really shines. I used ImageMagick to create these mosaic posters [krazydad.com], the Flickr Colr Pickr [krazydad.com] and other cool things.
  • I have been an imageMajick user for some years now I while I find it great for simple tasks and great for batch conversions it is no Photoshop. I think there is room for both. For simple image conversion or batch processing I use an Apple Automator action to call a do shell script. For others I drop into the terminal. For retouching or other tasks, it is Photoshop only.

    • by temojen (678985)
      Horses for Courses. When you need to touch up one image, use Photoshop. When you need to dust-bust hundreds of images, use CinePaint. When you need to rotate, scale, composite, and convert hundreds or thousands of images, use ImageMagick (via PerlMagick or your favourite scripting language).

      Similarly, excel is not a database management system, and Abiword is not a desktop publishing suite.
      • That is pretty much what I do. I use Photoshop for stuff that needs Photoshop. Most other is handled as you say by my favorite scripting language using ImageMagick The only other program I use for bitmapped graphic is the swiss army knife program GraphicConverter. It handles just about every graphic format made for every computer ever made. If I ever need to move a Commodore64 graphic file to Pison or Sun Rastersystem it will do it.....I don't know why I would ;-)

        At the time I don't have UNIX installed on m
    • It can do many things that you don't see here. It's up to someone to create an application that uses the power of imagemagick. The best I've seen so far is a web based image editor http://blibs.com/ [blibs.com]
  • check out netpbm too (Score:3, Informative)

    by resfilter (960880) on Monday March 13, 2006 @02:43PM (#14909509)
    those interested in command line image processing, should check out netpbm [sourceforge.net] too. it's really neat

    instead of a single image processing program, netpbm is a massive collection of programs all using a small set of proprietery formats (they are all compatible with each other). you use pipes for communication between them, giving you some more flexibility.

    for example:

    pngtopnm foo.png | pnmscale -xsize=600 ysize=400 | pnmtojpeg > foo.jpg

    the other advantage is, their proprietery formats were designed to be easy to use, so coding your own netpbm programs is much easier than rewriting imagemagick for a specific task.
    • by Tet (2721)
      those interested in command line image processing, should check out netpbm too.

      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

      • Wrong wrong wroooong, I'm afraid! ImageMagick is very much in the Unix league! It is not a monolithic application, it's a monolithic library. ImageMagick itself is spread across multiple programs (convert, identify, composite, montage, compare, display, animate, import, conjure) that do different kind of things. Heck, people should look at convert and identify alone as a good example of The Unix Way!

        And last I checked you don't need to recompile any apps to do unusual things with the graphics data, you

    • I wish that GIMP could be operated from the command line. At least currently, it is heavily tied to X for stuff like font rendering.

      Which is kinda irritating, because I can think of a lot of times where I know exactly how to do something with GIMP, but just wish that I had an easy-to-use-as-a-backend system that could do the same thing.
  • ImageMagick is great, but if you work with less common formats or even those such as Maya's IFF, it doesn't help much (which is odd seeing as how Maya even installs ImageMagick's convert command renamed as imconvert).

    There is another program called Nconvert that will handle pretty much any format you throw at it (about 400 in and 40 out). It can do much of what can be done with ImageMagick too, and is available for more than a dozen operating systems.

    Unfortunately it's only free for non-commercial use, and
  • by Goo.cc (687626) on Monday March 13, 2006 @02:53PM (#14909594)

    "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."

    From http://www.imagemagick.com/www/binary-releases.htm l [imagemagick.com] :

    "The Windows version of ImageMagick is self-installing. Simply click on the appropriate version below and it will launch itself and ask you a few installation questions. Versions with Q8 in the name are 8 bits-per-pixel component, whereas, Q16 in the filename are 16 bits-per-pixel component. A Q16 version permits you to read or write 16-bit images without losing precision but requires twice as much resources as the Q8 version. Versions with dynamic in the filename include ImageMagick libraries as dynamic link libraries. If you are not sure which version is appropriate, choose ImageMagick-6.2.6-3-Q16-windows-dll.exe."

    I know that its not a readme file but the website seems pretty explainatory. You are right about the FTP site, however.

  • Batch processing (Score:3, Informative)

    by AaronW (33736) on Monday March 13, 2006 @03:06PM (#14909715) Homepage
    For doing batch processing of photos I have been using Bibble Pro [bibblelabs.com] for Linux lately. I like it since it has good support for the raw format of my SLR and has a lot of batch processing features. For example, it's easy to select a group of 50 photos and adjust the white balance, or use the one click lens distortion fix on all my photos. Best of all, it runs under Linux. It gives me the best of both worlds. It gives me batch processing as well as the ability to individually make changes to each picture. I.e. I can bring out the shadows in a group of pictures, then straighten a couple of them if the camera was crooked and crop them as needed. It also does everything at 16 bits per color.

    Now, granted, it does not run on the command line, but it easily lets me select a source and target directory to batch process as well as letting me select individual pictures. I can't really compare it with ImageMagick since I haven't used it directly.

    -Aaron
  • NetPBM (Score:3, Informative)

    by Azul (12241) on Monday March 13, 2006 @03:13PM (#14909784) Homepage
    Hmm, I tend to find the approach of NetPBM [sourceforge.net] easier to work with: having lots of separate utilities each doing a single simple thing and making it easy to use them together by piping the output of one to the next. Besides, reading/writing PBM files is trivial so you can very easily use these tools from your programs (by piping your image through them) or you can very easily create new filters that integrate well with the rest. I recommend you check out NetPBM.

    If you need automatic processing of many images (the sort of thing ImageMagick is being praised for), I recommend you check it out.
    • We use ImageMagick to convert multi-page TIFFs that our customers send to us into our internal layout (i.e. correct size, depth, etc.). I'd like to try netpbm, but it doesn't seem to widely support multipage images:

      $ tifftopnm < foo.tif | pamscale -xyfit 640 480 > bar.tif
      tifftopnm: writing PBM file
      pamscale: promoting from PBM to PGM
      tifftopnm: writing PBM file
      $ identify foo.tif
      foo.tif[0] TIFF 995x1375 995x1375+0+0 DirectClass 2e+02kb
      foo.tif[1] TIFF 950x1375 950x1375+0+0 DirectClass 2e+02kb
      foo.tif[2]

      • Note that your bar.tif file in your example is in PNM format (not TIFF, which is probably what you expect, seeing that you're using bar.tif rather than bar.pnm). PNM files can include multiple images. You probably want this:

        tifftopnm <foo.tif | pnmscale -xyfit 640 480 | pnmtotiff > bar.tif

        According to the tifftopnm [sourceforge.net] and pnmtotiff [sourceforge.net] man pages, support for reading/writing multi-image TIF/PNM files was added in version 10.27 from March 2005. So either identify is not recognizing that your PNM file or you
        • PNM files can include multiple images.

          Yeah, but the p{a,n}m* tools don't seem to always process them.

          tifftopnm <foo.tif | pnmscale -xyfit 640 480 | pnmtotiff > bar.tif

          Unfortunately, neither pnmscale nor pamscal seem to do the trick (but identify would recognize the results if they did):

          $ tifftopnm < foo.tif | identify -
          tifftopnm: writing PBM file
          tifftopnm: writing PBM file
          tifftopnm: writing PBM file
          tifftopnm: writing PBM file
          tifftopnm: writing PBM file
          tifftopnm: writing PBM file
          tifftopnm:

    • having lots of separate utilities each doing a single simple thing

      I've heard this a few time, but never really got the big difference between accessing the utils as "./foobar img.png" vs "./foo --bar img.png", seems like a cosmetic distinction.

      One thing I really like about IM is that I don't have to even care about the input format, so when the users upload their random collection of gifs, jpegs, tiffs, 30 meg bmps and picts, I can just give the whole indiscriminate mess to IM and get back a set of nice, s

      • by Azul (12241)

        One thing I really like about IM is that I don't have to even care about the input format, so when the users upload their random collection of gifs, jpegs, tiffs, 30 meg bmps and picts, I can just give the whole indiscriminate mess to IM and get back a set of nice, shiny, sized and formatted pngs.

        I just want to point out that's something to like about NetPBM as well. You'd use anytopnm [sourceforge.net].

  • Irfanview [irfanview.com] is good for batch conversions, I used it all last summer to resize and greyscale hundreds of photographseach week. At 1.24mb for the whole program folder, and the ability to read almost any type of image file and use photoshop filters I haven't found anything better for quick edits.
  • My company uses image magick to resize and add watermarks to tens of thousands of website classified images. We created several wrapper methods to access it in our app.

    Poor Example:
    myImage1 = imageMagickResize(thisImage.jpg,destImage.jpg,300, 200);

    AFAIK it is more extensive than alot of the native image manipulation libs that come with certain languages (java?). Comparing imageMagick to photoshop or other apps is apples to oranges. We have this running on headless FreeBSD and CentOS boxes with no X. Can't
  • What I've really wanted, but not yet found, is some way to programmatically (or from command line) take a series of JPGs (1,000 to 50,000) and create a movie out of them. I've got Quicktime Pro, but it doesn't have command line ways of doing this (and it bogs down horribly when manually loading an image series and saving out a movie).

    I do use ImageMagick (actually GraphicsMagick I think) to watermark/timestamp each of the JPGs before I make the movie, but surely there's a way to fully automate what I'm doi
  • by mi (197448) on Tuesday March 14, 2006 @12:01AM (#14913297) Homepage
    ImageMagick's API is notoriously unstable and new releases don't even bother with backwards compatibility. Once in a while, even the command line options change between releases breaking existing scripts (such as ImageIndex [edwinh.org], for example).

    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].

    • Thank you !

      I didn't know that this existed and I've been bitten by IM changes of API too many times already. Actually about 10% of my configure script is dealing with IM API changes and is the part that is most regularly breaking...
    • ImageMagick's API is notoriously unstable and new releases don't even bother with backwards compatibility.

      Yeah, it sure is a shame that those old versions stop working the second they release the new ones.

It is surely a great calamity for a human being to have no obsessions. - Robert Bly

Working...