ImageMagick v6 Examples --
API & Scripting

Index
ImageMagick Examples Preface and Index
API and other IM usage methods
Security Issues
Hints for Better ImageMagick Shell/PHP Scripts
Why do you use multiple "convert" commands
Making IM faster (in general)
Compiling ImageMagick form Sources
The Command Line Interface (CLI) of ImageMgaick which this examples deals with is only one method by which you can use, modify and control images with the core library of ImageMagick functions (MagickCore). It is basically the 'shell' API interface. There are lots of other Application Programming Interfaces (API's) which you can use more directly from many programming languages, see ImageMagick APIs.

Here I look at ways of improving your IM scripting and programming, differences between Windows and Unix scripting, and look at basics of using IM from other API's and programming languages.

APIs and other IM usage methods

API's (Application Programming Interface) for actual image processing are in fact no faster than using the CLI commands (such as "convert" (which is itself represents a type of shell-API). The same 'core' library is used for all image processing in IM. So if you are doing a complex task such as image distortion, using an API over a the shell "convert" makes very little difference in terms of overall 'speed' of processing.

So why use an API over Command line?

A shell constantally 'forks' off many different commands (not just IM "convert" commands, though shells have some 'built-ins'), each of which has to be loaded, and initialised every time it is run.

Every IM command also has to re-initialise its configuration files, parse the command line arguments, re-read whatever images you are working with, and often save results back to disk. All of which takes time causing them to be slower.

That is all that extra steps take time and processing power, so if you do it a lot, and API can start to make sense.

API can also allow you to do other things a command line can't.

But for most things not involving large numbers of images, or general procesing of images in well defined ways, the command line is pretty well just as fast. You can however save lot ot time and re-processing by...

Of course in an API you also have different and faster techniques could also have been used for a special processing task that would make access to the image. And as we find and get time we often program such techniques into the core library. Image distortions and various FX expressions is one example of this.

Windows, and DOS

The examples on using Windows and DOS scripting using the CLI API, has been moved to Usage under Windows.

PHP (IM commands from "system()" functions)

PHP users have three ways of using ImageMagick, Because of the existence of IM Examples this later method (and the first we will look at next) has in recent years become the most common method of using IM from PHP.

Of course for some things it may not be the best method (see above), in which case the API interfaces is available, though may require a system administrator to make them available to your PHP environment.

PHP using Shell Commands

The best source of specific information on using this technique is the IM forum user Bonzo and his web site RubbleWebs.

Please note, PHP runs "convert" using a different environment, and probably even as a different user, to what you would get from the command line. As such what works on the command line, may take a little tweaking to get it to work from a PHP web driven script.

The following is the recommend procedure for initial tests of an ISP's command line IM interface, assuming you do not have direct command line 'shell' access on the remote system. That is you can only upload web files for execution.

So the first thing we need to do is try and find the "convert" command on the system, what version is installed, and the environment the PHP is running.

On a Linux Web Service, upload and access this PHP script from the ISP's web server... 

<?php
  header('Content-Type: text/plain');
  system("exec 2>&1; pwd");
  system("exec 2>&1; type convert");
  system("exec 2>&1; locate */convert");
  system("exec 2>&1; convert -version");
  system("exec 2>&1; convert -list type"); <!-- before IM v6.3.5-7 -->
  system("exec 2>&1; convert -list font");
  print("------ENVIRONMENT VARIABLES-------\n");
  system("exec 2>&1; env");
?>

This will run quite a number of commands to see what your environment is like.

The first "pwd" tells you the current directory in which the PHP script was run. This may or may not be the directory where the PHP script is located, and you may not be able to write in that directory form the PHP script.

The next two commands tells you if "convert" is available on the default provided command PATH using "type", and if so where is it. The "locate" command should find all "convert" commands that exists on the server (assuming it is a linux server), but may find other non-ImageMagick "convert" commands, files and directories. You will need to interpret the results.

The next three commands, assume "convert" is on the command PATH, and asks it to report its version number, and what fonts IM think it has access to. Which command reports what fonts depends on how old the installed IM version is.

If you only see errors, then the "convert" is not on the command line path, and your ISP provider did NOT initialise the web server "PATH" and "LD_LIBRARY_PATH" properly to include it. See output from the "env" command for what they did define.

If this is the case you will need to find out exactly where it is located and use something like the following PHP script. This will make your script less portable, as it is hard coded for that specific ISP.

For example suppose the "convert" command is in "/opt/php5extras/ImageMagick/bin", then you can set a variable to specify its location. This is often done as part of application configuration and installation process, for PHP scripts being used on different ISP hosts), 

<?php
  $im_path="/opt/php5extras/ImageMagick/bin"
  header('Content-Type: text/plain');
  system("exec 2>&1; $im_path/convert -version");
  system("exec 2>&1; $im_path/convert -list type");
  system("exec 2>&1; $im_path/convert -list font");
?>

If you get "ldd" library errors, the "LD_LIBRARY_PATH" is wrong, and the ISP has definitely fallen down on the job during its installation, and you need to report the error, and have them fix the web servers "LD_LIBRARY_PATH" environment variable setting, or re-install ImageMagick.

Rather than set the location of the convert command, you can also adjust the PATH environment variable with a line such as this at the top. However this method is often 'denied' by default by typical PHP system configuration... 

  putenv("PATH=" . $_ENV["PATH"] . ":/opt/php5extras/ImageMagick/bin");
  putenv("LD_LIBRARY_PATH=" . $_ENV["LD_LIBRARY_PATH"] .
                                   ":/opt/php5extras/ImageMagick/lib");

After that try some of the simpler examples from IM Examples and try to get them working. For example output the IM 'rose' image as a JPEG image file back to the web user... 

<?php
  header( 'Content-Type: image/jpeg' );
  passthru("convert rose:  jpg:-");
?>

If you need to set the convert command location you can use... 

<?php
  header( 'Content-Type: image/jpeg' );
  $convert="/opt/php5extras/ImageMagick/bin/convert"
  passthru("$convert rose:  jpg:-");
?>

or if the you have library problems you can try something like... 

<?php
  header( 'Content-Type: image/jpeg' );
  $convert="/opt/php5extras/ImageMagick/bin/convert";
  $libs="LD_LIBRARY_PATH=\'" .  $_ENV["LD_LIBRARY_PATH"] .
               ":/opt/php5extras/ImageMagick/bin/convert\'";
  system("$libs $convert rose:  jpg:-");
?>

If you still don't see anything look at my raw PHP Hints and Tips file for information on techniques of redirection error messages.


When you have that basic script working you can try one of the fonts listed from your PHP test scripts (modify the following to suit your PHP server).

For example on a Solaris Server I had available at this time, I noticed that the 'Utopia' font set was available so I was able to try to create a label with that font... 

<?php
  header('Content-Type: image/gif');
  passthru("convert -pointsize 72 -font Utopia-Italic label:'Font Test' gif:-");
?>

Example Shell to PHP conversion

Here we have a fairly typical ImageMagick command... 

  convert -background none -fill red -gravity center \
          -font Candice -size 140x92 caption:"A Rose by any Name" \
          \( rose: -negate -resize 200% \) +swap -composite    output.gif

When converting to PHP it will become something like... 

<?php
  header('Content-Type: image/gif');

  $color="red";
  $image="rose:";
  $scale="200%";
  $size="140x96";
  $string="A Rose by any Name";

  passthru( "convert -background none -fill '$color' -gravity center" .
            " -font Candice -size '$size' caption:'$string'" .
            " \\( '$image' -negate -resize '$scale' \\) +swap -composite" .
            " gif:-" );
?>

Note how I still split up the long command line of the "convert" command to make the image processing sequence easier to follow, and to edit later. This was done using PHP appended strings rather than the shell line continuation used in shell scripts.

Also note the extra space at the start of later lines. And doubling up the other backslashes that was present in the original command. Alternatively you can protect those options by using single quotes instead of backslashes.

I also used some PHP variables to allow easier adjusted of the PHP script image generated, to provide better control the results. However when I insert those options in the "convert" I used single quotes to protect them from further modification by the shell. But watch out for single quotes within those inserted strings!

You could make those options PHP input arguments, so you can generate an image for any input text passed to it from a web request.

You can also perform multiple shell commands from within the same system call string. In fact a single system call can contain a complete shell script if you want! So you can do shell loops and multiple commands (with cleanups) all in the one system call. Something not may people realise is possible.

Basically if you are careful, you can make good use of the mathematics provided by PHP, and the scripting abilities of the shell. All at the same time. Just watch the quotes.

For various examples of calling ImageMagick commands from PHP see Rubble Web, Writing IM code in PHP which describes about four different techniques.

Watch the extra quotes

Note that typically the IM commands in PHP are wrapped by an extra set of quotes (usually double quotes), as such care must be taken to allow for the use of these extra level of quoting. Remember when PHP executes a string....

PHP does its quotes, backslash and variable substitutions

Shell then splits up arguments and does its own variable and quote substitutions. It will also do any "2>&1" type file descriptor redirections if present.

ImageMagick gets an argument array, but will also do its own filename meta-character handling specifically for DOS (the dos environment doesn't handle meta-chars) and for arguments such as coder:*.gif[50x50] which the shell fails to expand due to coder: prefix or the [...] read modifier.

That is a LOT of argument parsing! Whcih can mean a lot of quoting and backslashing handling. Caution and fore-thought is required.

I recommend you at least read the PHP manuals on Program Execution Functions, which includes: PHP exec(), system(), and passthru(). also look at the Backtick Operator. Of particular importance, understand what exactly is returned (generally the last line only) and passed on to the calling client (everything else).

PHP Security

Remember... 

   On the net, the only users you can trust not to be potentially hostile
   are those who are  *activally*  hostile.
                                     -- Programming Perl - Camel Book, r3

You must throughly check all input arguments being passed from user to an IM command troughly. Make sure the argument is exactly what you expect. It is far better to be over restrictive that under restrictive when dealing with the World Wide Web.

Some common things to watch out for include For any sort of web programming work, an understanding of security and how hackers can use specially crafted arguemnts to subvert called commands, is vital. Not just for PHP, but for Shell, and ImageMagick.

IM requires particular care as it can for example read and convert a password file into an image to be returned. Again... It is far better to be overly restrictive, than open an unforseen security hole, when the web is involved.

Writing to the Filesystem

As mentioned above, and if you followed the above initial proceedure, you will know for certain, PHP generally runs as a different. more resctritive user on the server.

Because of this it will typicall NOT be able to write to the directory containing the script (or where ever it is actually running. For security reasons you generally do not want to write to that directory!

If you really want PHP to write files, have it save the image (or data) to an unique filename in "/tmp", and above all clean up afterward, on both normal exit, or on ANY error. It is amazing how quickly you can fill a disk with left over temporary files from an application that does not cleanup properly.

If the saved files (images) must be visible by the web server, make a special 'write by program' sub-directory, for those files.

How it should be done.

Most PHP applications actually avoid writing anything to the file system by using a database backend. That is cookies, tokens, user data, images, and so on are all written into a database, such as (in order of complexity and scale) SQLite, PostgresSQL, MySQL, and Oracle. It saves nothing in the filesystem at all. System Programmers will typically configure the PHP application with that information when the application is installed.

Images is typically reproduced by either the same, or separate PHP script that looks up the image 'blob' and outputs it to the client. Images may be sent as 'inline' images with the HTML itself (see, the "inline:" format, which has a demonstration of HTML inline images), or as a single 'all in one' multiple image, so the client HTML/JAVA only has one image reqest rather than 20 separate requests.

One final point. Some method of cleaning up old data should always be present. An user that has not logged in for 2 year, probably should have his data deleted.

Getting Error output

Try one of these methods... 

<?php
exec("/usr/local/bin/convert -version",$out,$returnval);
print_r($out[0]);
?>

or 

<?php
exec("/usr/local/bin/convert -list",$out,$returnval);
print_r($out);
?>

or use shell_exec as follows 

<?php
$IM_version=shell_exec("/usr/local/bin/convert -version");
echo $IM_version
?>

To include STDERR output... 

<?php
$array=array();
echo "<pre>";
exec("convert read_test.png write_test.png 2>&1", $array);
echo "<br>".print_r($array)."<br>";
echo "</pre>";
?>

The above comes from the IM Users forum discussion... How to show IM error info in php?.

See my own PHP Debugging Error Log notes. Which points to the PHP Manual on error Logging PHP Error Handling and Logging, especially look at the examples section.

More Secure ImageMagick Commands...

Idealy for security reasons, you would want to avoid using the shell to parse a single long string into separate command and arguments. It is better to do it yourself! This mean you provide the arguments to the command as an array of separate strings, instead of as an one single shell-parsed string.

By doing this you prevent the posibility of shell syntax errors, the extra quoting burden needed by the shell, and prevent the posiblity of some hacker breaking the shell command and runing there own command (very bad).

On the other hand you loose shell scripting, piping, and file re-direction, but that is typically not a great loss when you are already using PHP or some other wrapping language.

In PHP the only function I could find that will let me call command directly without a shell is the pcntl_exec() function. This basically avoids shell, and calls the command directly.

However it is a true 'execl()' system call, which replaces the current process with the command given. That is it does not do the 'fork()' and file descriptor linkages, needed to run it as a sub-process. As such pcntl_exec() is really after too low level for generate use, and implementing a 'no-shell' command can get get fairly complex.

I am very surprised a simpler, more secure 'avoid the shell' command call has not already been provided by the PHP interface. But then I am not a PHP programmer. Perl on the other hand provides a number of method of securly calling sub-commands and processes, which often makes it more preferable as a web interface than PHP.

Anyone with PHP security knowledge care to enlighten or provide pointers to more information?

PHP 'IMagick' API

To test if the PHP PECL Imagick module is actually working upload a simple test "image.jpg" image and this PHP script to the same web assessable directory. 

<?php
  $handle = imagick_readimage( getcwd() . "image.jpg" );
  if ( imagick_iserror( $handle ) ) {
    $reason      = imagick_failedreason( $handle ) ;
    $description = imagick_faileddescription( $handle ) ;

    print "Handle Read failed!<BR>\n";
    print "Reason: $reason<BR>\n";
    print "Description: $description<BR>\n";
    exit ;
  }
  header( "Content-type: " . imagick_getmimetype( $handle ) );
  print imagick_image2blob( $handle );
?>

A PHP IMagick Book is available online, and more examples of using IMagick can be found in Mikko's Blog.

The only problem with IMagick is that is has not been maintained and upgraded, so there may be a number of functions that does not work or are missing. Be sure you are using v3.x of IMagick and a current version of IM.

It does work and for most things it works well, but if you need to do the other things, then other PHP methods may be a better option.

PHP 'MagickWand'

You can check if the PHP MagickWand module is part of the PHP installation using... 

<?php
  if (extension_loaded('magickwand')) {
    echo "PHP MagickWand is available!\n";
  } else {
    echo "PHP MagickWand is NOT available!\n";
  }
?>

But to check that it is actually working properly, upload some test "image.png" and this script... 

<?php
  $image = NewMagickWand();
  if( MagickReadImage( $image, 'image.png' ) ) {
    header( 'Content-Type: image/jpeg' );
    MagickSetImageFormat( $image, 'JPEG' );
    MagickEchoImageBlob( $image );
  } else {
    echo "Error in MagickReadImage()";
    echo MagickGetExceptionString($image);
  }
?>

No guarantees with the above, though more feedback welcome. I do not generally program in PHP, but used the above for testing a SunONE-PHP5 test installation (with all three methods: command-line, magick, MagickWand).

Complex PHP scripts...

If you need to generate and output both HTML and IMAGES, consider designing your PHP script so that separate HTML requests or input options, generate the various parts you need on your web document, from either the same, or different PHP scripts.

That is a top level PHP script can output HTML with appropriate <IMG> tags, that call itself (or another PHP script) with appropriate options, to create or modify the images displayed on the first top level PHP script. This is in what a lot of photo album, and graphing PHP scripts do. All controlled by the GET, and PATH_INFO extensions to the URL calls. Note that you can not use POST within an IMG tag.

By doing things in this way you should be able to completely avoid the need to both generate, save, and clean-up, temporary images for PHP generated web pages. A solution that is full of problems, such as resource limitations and garbage collection, making it a very bad programming technique.

This technique looked at in both the ImageMagick Books, though the ImageMagick it actually uses is becomming a little dated.

Perl Magick Scripts

The PerlMagick API is a good way of conveting "convert" commands into a script that can also handle databases, large numbers of images, or more complex image processing, that is otherwise posible. The best help is to look at the PerlMagick 'demo' scripts, which is both in the source, and usually installed in the documentation area of PerlMagick. On my system that was in "/usr/share/doc/ImageMagick-perl-*/demo/". In this directly are a growing number of simple examples of reading, writing and processing various images. Also present is the script "demo.pl" that lists just about all common Image Processing options, and how you can use them.

When converting a command line "convert" command to perl there are a few things you need to remember.

To convert a command line into perl, you would basically do the exact same operations, in the exact same sequence. However as images are generally not deleted, and multiple image sequences are common, the use of parenthesis, and extra cloning operations in "convert" commands are usally not an issue.

The hardest part in converting scripts is usually mapping a command line option to a PerlMagick function call. The fastest way I found is to get the source code of IM and look at the file "wand/mogrify.c" and search for the specific command line option you are having trouble with.

For example for say the -threshold option search for "threshold" including the quotes. Their will be two matches, one for a quick syntax parse to make sure all the options are found, and the second with the actual internal calls for that option. Here you will find the name of the library function used, and that will usally directly map to the Perl function. In this case... BilevelImageChannel()

Security Warnings

When writing a script for public use, especially a web-based PHP script where ANYONE in the world could be running it, it is vitally important to check everything that could posibly have come from an unknown (or even a known) user. And I mean EVERYTHING, from arguments, filenames, URLs, and images too.

Until you verify some input argument, that argument it could contains letters, numbers, spaces, punctuation, or even 'null' and control characters. Untill you have throughly checked it, it should be treated as suspect and should not be used.

It does not matter that you are using some web controlled input form. A slightly knowledgeable person can easily call your PHP with his own arguments without using that input form at all. An don't believe they won't do it, robots are out there, reading input forms and creating there own 'hacked' arguments to try an break into random scripts.

Meta-characters in file names

As a security issue, you should especially watch out for, are filenames that contain spaces, quotes, punctuation, control-characters, or other meta-characters as both IM and Shells may try to expand them.

The problem is that a file called '*?@${&) .jpg' is actually a perfectly legal filename under UNIX, but a LOT of programs will have trouble handling it if that program (like both shell and IM) also do filename expansion.

Remember even if you prevent the shell from going 'glob' meta-characters expandsion, IM itself also does this expansion (for DOS usage). As such preventing all such characters (and producing an error), is probably a wise thing to do.

As a security measure it is often a good idea to error and abort if a filename has ANY unknown or unusual characters in it, anything that is say not letters, numbers, or in the expected suffix. Before passing such a filename to a shell command, or IM. It is better to be a LOT more restrictive and prevent things, than be permissive and allowing something bad through.

Hints for Better ImageMagick Shell/PHP Scripts

These were some basic script programming points I made about a contributed shell script that was sent to the IM mail list for others to use. I originally sent these to the author privately (and who will remain anonymous), for which he was grateful. They are not all IM specific, but should be applied anyway, as standard programming practice. Especially if you plan to have someone else, use, look at, and/or bug fix your program or script. It will in turn make your script more useful.

These things basically gives the user using your program more freedom to do what THEY want rather than what YOU think they want. Don't limit them or yourself by making assumptions on what the script will be used for.

PS: My primary expertise is in UNIX script writing, over lots of different architectures and 'flavors' of UNIX, LINUX, and other UNIX-like systems, with more than 25 years experience behind me. I should know what I am talking about with regard to the above.

Why do you use multiple "convert" commands

Willem on Wed, 25 Oct 2006 wrote...
I was wondering; sometimes I see in your examples you're invoking Convert more then once to obtain the desired result. In general, I would expect that invoking convert more then once isn't needed; it should all be possible in 1 invocation (but the command would be more complex then). Do you agree with this statement?

I agree totally.

Though before IM version 6 that was actually impossible, as IM at that time was not designed to do more than one or maybe two operations per command. However IMv6 should allow you to do all your processing in one single command. But sadly even that is not always possible.

I use multiple commands for a number possible reasons. Typically in the example pages, I do it so I can display the intermediate image result, so as to better demonstrate the intermediate processing stages that are involved. Later in the same example area I may repeat the process but using a single command, with perhaps a little more complexity.

As such in principle, yes a single command can do all image processing. You are most welcome to combine the image processing techniques all into a single command. I do this all the time myself.

The exception to this is in cases where I need to extract information and later insert that info into the next command. An example of this is the Fuzzy Trim technique which requires you to extract the results of a trim on a blurred copy of the image. This result is then used to crop the original image. I also did this in the update to Thumbnail Rounded Corners example, where I used IM itself to generate a draw command using an images size for the next command.

However there are proposals that will allow options to be generated directly from image that have been previously read into memory.

In scripts, such as the 'jigsaw' script (see Advanced Techniques, Jigsaw Pieces) I commonly end up using multiple commands for a different reason -- optional processing. This allows various input options provided by the user to select additional steps in the image processing sequence. So for optional processing I also use typically use separate commands for each stage of processing.

In such a case a temporary file is basically unavoidable. However I typically only need at most one or two temporary images, and each step processes the image back into the same or previous temporary filename, for the next optional processing step to continue with.

For example process image replacing the source image. 

  convert  /tmp/image1.png ..operations..  /tmp/image1.png

In this case a MPC file can speed up the reading of intermediate files to a near instant in the next processing step, as the image is simply dumped from memory onto disk, and then 'paged' back in by the next command. This avoids the need for IM to format and parse an image file format, though it does make the temporary file larger as it is simply uncompressed memory.

Another alternative I use to avoid temporary files is to pipeline the working image(s) from one shell command (if-then-else-fi or while loop) to another. This is known as Image Pipelines and is demonstrated in a number of examples. And example of this is given in MIFF Image Streaming, where multiple images are generated one after another into the same output pipeline, to be picked up by the next command to merge them all into the final image.

And finally you may need to change your processing style based on the results of previous processing steps. For example in image comparisons, I often need to discover some information for use in later processing steps, or to change how the image should be processed in later stages. Comparing a diagram or cartoon can require vary different comparision technique to real-life photo image.

If the use of multiple commands is becoming a problem, perhaps it is time to go to an API interface such as PerlMagick, where multiple image sequences can all be held in memory so as to avoid unnecessary disk IO.

Making IM Faster (in general)

There are many ways of making IM work faster. Here are the most important aspects to keep in mind. As you go down the list the speed up becomes smaller, or requires more complex changes to the IM installation.

Compiling ImageMagick form Sources

Building ImageMagick RPMs for linux from SRPMs

You do NOT need root to actually build the RPM's though you do need root to install RPMs.

I use this for generating and installing IM under Fedora Linux Systems, but it has also been reported to work for CentOS 5.4 (Enterprise Redhat) Linux Systems (See more specific IM on CentOS Notes). First get the latest source RPM release from Linux Source RPMs.

First make sure your machine has all the compilers and tools it needs. 

  sudo yum groupinstall "Development Tools"
  sudo yum install rpmdevtool libtool-ltdl-devel

The "sudo" is a program to run commands as root, if you are allowed, otherwise use a root shell and remove the "sudo" part from the above.

For Older systems like CentOS 5.5 it seems you also need these packages 

  sudo yum compat-libstdc++ gcc-c++ gcc-objc++ libstdc++ libstdc++-devel

Next you should also install development packages for the libraries IM also needs to build. The simple way to get the most common ones is to first instal the Development version of IM, even though we will build a new one to replace it later. 

  sudo yum install ImageMagick-devel

You should also ensure that the these packages and their dependencies (such as jpeg and png development libraries) are also installed:
freetype-devel ghostscript-devel libwmf-devel jasper-devel lcms-devel bzip2-devel librsvg2 librsvg2-devel liblpr-1 liblqr-1-devel libtool-ltdl-devel autotrace-devel
Some examples in "ImageMagick examples" also may use programs provided by these optional packages and libraries, but these are not needed for the built process.
gnuplot autotrace

Generally all these packages are optional, but if not installed, then the 'coders' and operators that make use of those libraries may not be built in automatically. For example the "liblqr" module is needed to enable the Liquid Rescale Operator.

Now download a SRPM (source RPM) package from which to build your binary RPMs.

OR build a SRPM from an existing TAR or SVN download using... 

  rm config.status config.log
  nice ./configure
  rm *.src.rpm
  make srpm

Note that once you have the SRPM you can build the actual RPM's to install. 

  nice rpmbuild --nodeps --rebuild   ImageMagick*.src.rpm

This will create a sub-directory "rpmbuild" in your home, in which it will extract the SRPM sources, and build the compiled package RPM version of the IM.

On older versions of Fedora and Redhat this was done in "/usr/src" which is generally restricted to root only. However you can make this directory owned or writable by you so you can still do it without needing full root access for the build.

Now get the just built RPMs from build directory. This only grabs the ImageMagick Core and PerlMagick packages, you may like to grab more than just these two, but that is up to you... 

  cp -p ~/rpmbuild/RPMS/*/ImageMagick-[6p]*.i[36]86.rpm .

Clean up and delete the build areas (including those that may have been created for you)... 

  rm -rf /var/tmp/rpm-tmp.*  ~/rpmbuild

Now you can install the RPM packages you built. You will need to be root for this, (see note about the "sudo" command above)... 

  sudo rpm -ihv --force --nodeps  ImageMagick-*.i[36]86.rpm

The "--nodeps" is typically needed due to some unusual dependencies that sometimes exists on Linux systems.

To upgrade an existing installation I generally do this (as root). 

  sudo rpm -Uhv --force --nodeps  ImageMagick-*.i[36]86.rpm

If you want to go further I recommend you look at the Advanced Unix Source Installation Guide from the IM web site.


To later remove IM, you can just remove the package, like this (again as root)... 

  sudo rpm -e --nodeps  ImageMagick\*


Sometimes I just want to completely clean and wipe out all traces of IM from the system. To do this I first use the previous command to remove the actual package from the system (a variation is shown below). I then run the following remove commands.

NOTE I make no guarantees about this, and I would check the commands thoroughly before hand to ensure they don't remove something that it shouldn't. If it missed anything, or it removed something it shouldn't, then please let me know so I can update it. 

  rpm -e --nodeps `rpm -q ImageMagick ImageMagick-perl`
  rpm -e --nodeps `rpm -q ImageMagick-devel`
  rm -rf /usr/lib/ImageMagick-*
  rm -rf /usr/lib/lib{Magick,Wand}*
  rm -rf /usr/share/ImageMagick-*
  rm -rf /usr/share/doc/ImageMagick-*
  rm -rf /usr/include/{ImageMagick,Magick++,magick,wand}
  rm -rf /usr/lib/perl5/site_perl/*/i386-linux-thread-multi/Image/Magick*
  rm -rf /usr/lib/perl5/site_perl/*/i386-linux-thread-multi/auto/Image/Magick*
  rm -rf /usr/share/man/man?/*Magick*
  rm -f /usr/lib/pkgconfig/ImageMagick.pc

Warning, other packages may need an IM installed, so if you remove it, I suggest that you immediately package update your computer system, so it will again install the original default (and usually quite old) version of ImageMagick that was supplied for your Linux system. This generally involves using a 'GUI Software Update" package or the command "yum upgrade".

Enjoy.

ImageMagick from Source on Ubuntu

To get all the development libraries for building ImageMagick use the following 

  sudo apt-get install imagemagick libmagick++-dev

A web page by "Shane" describes how to Install ImageMagick from Source on Ubuntu 8.04.

I have not tried this, but this installed IM into "/usr/local" directly using "make". It does not generate an installation 'DEB' package, which is not an ideal solution.

If anyone know how to create a 'DEB' package for Ubuntu, please let me know.

Perhaps using Intro into Debian Packaging

Compiling on MacOSX

The easiest way to install ImageMagick on MacOSX is to use MacPorts.

But the following are pointers to information on compiling for MacOSX. I don't know if it works or is going to be helpful as I have never used it. But see Install ImageMagick without Fink or MacPorts and Install ImageMagick in Snow Leopard.

The above was paraphrased from a Discsuion on IM User Forum.

Compiling HDRI versions of IM

For information of compiling a HDRI version of IM see Enabling HDRI in ImageMagick on the main IM website, also for Windows and Ubuntu Linux specific information see Fourier Transforms Announcement Discussion on the user forums.

Creating a Personal ImageMagick

You do not always have the luxury of having superuser access to the machine on which you are doing image work on, and often those that do have that access do not want to update their ImageMagick installation. Perhaps for package management issues, or compatibility problems.

If you have command line access (for example via SSH) all in not lost. You can install and use a personal version of ImageMagick.

The bad news is you will still need the system administrators to install the compilers and development packages (see above), but often these will already be present, so is not always a problem.

First decide in what sub-directory you want to install your version of IM. A dedicated directory is the best choice as it mean you only have to delete that whole directory to remove your installation. In my case I'll install into the "apps/im" sub-directory of my home. 

  export MAGICK_HOME=$HOME/apps/im

Now to install a personal version, download, unpack, and change directory into the ImageMagick Sources. Then configure it as a 'uninstalled' version. 

  rm config.status config.log
  nice ./configure --prefix=$MAGICK_HOME --disable-installed \
          --enable-shared --disable-static --without-modules --with-x \
          --without-perl --without-magick-plus-plus --disable-openmp \
          --with-wmf --with-gslib --with-rsvg --with-xml \
          CFLAGS=-Wextra \
          ;
  nice make clean
  nice make
  nice make install

It is the "--disable-installed" with the "--prefix" which is important in the above definition. The other parts disable the compilation of more optional aspects of your personal version ImageMagick. Modify them as you like.

Now to use your own installed version, instead of the normal system version you only need to set the following environment variables. 

  export MAGICK_HOME=$HOME/apps/im
  export PATH="$MAGICK_HOME/bin:$PATH"
  export LD_LIBRARY_PATH="$MAGICK_HOME/lib:$LD_LIBRARY_PATH"

Now if I type 

  convert -version

I can see the more up-to-date version of IM you just installed, by default.

Note that the variable "$MAGICK_HOME" is required to be set for an Imagemagick created with a "--disable-installed" option. The other two environment variables ensure that we use the personal version rather that any system version that may also be installed.


WARNING: do not mix the above variables. Either define all of them or do not have them defined in this way. The IM executable you use MUST also use the same libraries, coders, and configuration files that were built with those executable. Mixing the system and your personal version will likely cause segmentation and memory faults.


You can move the location of your personal IM without re-compiling, but you will need to not only modify the above environment variables, but also change (or remove) the hard coded paths to the "display" program used by the "show:" delegate in your personal installed version of the "delegate.xml" file. See Delegates for more information on this aspect of IM.


To make it easy for me to switching between the system installed and multiple personal versions of IM, I typically do not set the above variables at all. Instead I call a script that sets those variables before calling the specific version of IM.

For example I have a personal version of IM that was compiled with HDRI, which I only use for specific examples in ImageMagick Examples. I don't normally want to use this version, perfering the non-HDRI system installed version for most image work.

As such I installed a 'HDRI' version of IM in my personal area "$HOME/apps/im_hdri", and created a script I called "hdri" containing... 

#!/bin/sh
#
#   hdri imagemagick_command....
#
# Run the HDRI version of imagemagick (or other personal installed IM)
#
# Where is the HDRI version of IM stored
export MAGICK_HOME=$HOME/apps/im_hdri

# Set the other two environment variables
export PATH="$MAGICK_HOME/bin:$PATH"
export LD_LIBRARY_PATH="$MAGICK_HOME/lib:$LD_LIBRARY_PATH"

# Execute the HDRI version of the command
exec "$@"

Now if I type... 

  hdri convert -version
[IM Text]

I see that I ran my HDRI quality version of ImageMagick, but only when I need it. If I don't prefix "hdri" to the above, I then I would run the normal system version of IM.

WARNING: If your personal version of IM is not found by the script, it will silently revert to using the system version. The above 'version' check is an important test to make sure that I am actually using my personal version, and not the system version.

You can also check exactly which convert command the script is trying to execute using the 'which'. 

  hdri which convert

That is the script is flexiable enough that you don't actually need to run "convert" but can run any command, such as ImageMagick Shell Scripts, so that that script uses the HDRI convert instead of the normal system convert. 


  hdri  some_im_script   image.png   image_result_hdri.png

Created: 26 October 2006
Updated: 15 March 2011
Author: Anthony Thyssen, <Anthony.Thyssen@gmail.com>
Examples Generated with: [version image]
URL: https://legacy.imagemagick.org/Usage/api/