ImageMagick v6 Examples --
Common Image Formats

ImageMagick Examples Preface and Index
A Brief Summary of Common Image File Formats
GIF Image File Format
JPEG Image File Format
PNG Image File Format
Image Profiles
A Word about Vector Image Formats
Other Image File Formats
TIFF, NetPBM, BMP, RAW Digital Image (CRW,CR2,NEF,X3F,etc), MPEG, M2V and AVI, DPX, Digital Picture Exchange Format, Postscript (PS), Encapsulated PS (EPS), PDF, PSD, WMF, MacroMedia Flash (SWF), Webpage HTML Conversion PCL Printing Format

Many of the image file formats have particularities which you need to keep in mind when using that format. This page deals with these special needs, and ways to improve results in those formats.

A Brief Summary of Common Image File Formats

For a introduction to reading and writing image formats see Image File Formats. While a list of all the ImageMagick file formats are given on the IM Image Formats Page.

Here is a very quick summary of the most common 'normal' image file formats, as well as their general advantages and disadvantages...
This format is extremely common, and has been around for so long that all image handling programs understand it. But only uses a limited number of colors (a 256 color table) and only saves using 8 bit quality. However its built-in run-length encoding allows it to save images with only a few colors very efficiently.

While the format has transparency, it only understands Boolean (on/off) transparency and so consequently suffers from 'aliasing' or 'jaggies'. Plain text with thin lines suffers badly when saved as a transparent GIF image. The only solution to this problem is to tie the GIF image to a specific background of the web page in which it is used.

The GIF format can save multiple images to form an animation sequence, and for this purpose also saves the image canvas size and offset (page) information. Note however that negative offsets are not supported, and attempts to do so resets that offset to zero.

Its best used for small images of cartoons, line drawings, and small icons, all of which have limited colors, and will allow it to compress well. Its use however should be avoided when a newer format like PNG is available.

Does not handle transparency at all. The image is equivalent to using "+matte" operation to remove the alpha channel, so any background transparency commonly becomes black depending on the image processing used to generate the image.

This format is also 'lossy', producing edge effects on sharp lines and borders and thus should not be used for any intermediate image processing, or storage of image originals (unless they were already in this format).

It is well suited to long term storage of real life photographs, but avoid it if you plan to further process the image, or the image contains large areas of solid colors.

This format is intended to eventually replace older formats like GIF and TIFF. It is a modern format capable of handling 16 bit quality with four color channels allowing the full use of semi-transparent colors. It also includes a huge number of lossless image compression options.

Its biggest disadvantage is that it is still relatively new, such that the Microsoft IE (v6) web browser does not automatically handle it correctly. However a fix is available for this problem.

The format does not save canvas size information (where GIF does), but it does save the canvas offsets and even negative offsets (which GIF does not), though some web browsers have problems when a negative offset is used, so this is not recommended for a final image to be displayed in a browser.

For saving intermediate 'layered' images, the ability to save negative offsets can be very important and is often much more important than its not saving canvas size information.

This is the multi-image format for PNG, and allows animations to movie quality levels and speed.

A simple example of using MNG is wanted, so if you have one mail me.

This is the Image interchange format that was developed to transfer high quality images between programs before any serious image formats were available. Unfortunately, because of this beginning, the format has been modified with a haphazard array of features and compression styles and no programs understands them all.

The format is now pretty well only use by "Photoshop" on windows platforms, and this is the only source that provides any sort of standard reference for the TIFF image format.

TIFF files can handle multiple images, though few applications other than IM handle multiple image TIFFs.

Generally, unless the internal format of the TIFF image is kept relatively basic, there is no guarantee that a TIFF file generated by one program will be usable by another program, including IM or even "Photoshop" itself. As such I do not recommend this format period! I suggest you use some other format than TIFF (or JPEG), especially for long term storing of images.

The few notes I have on this format and its problems are provided in the Miscellaneous Formats, TIFF section below. These usage notes were found in the IM mailing lists and forums, as I myself don't use or need to use TIFF.

Video Formats
Other movie quality animation formats generally based on using lossy compression to reduce the size (and quality) of the movie. Both formats are in a constant state of flux, improvements and security limiting features, making any form of processing difficult.

At last count there was more than 200 video format 'codecs' that are in general use for one purpose or another.

Because of this IM does not directly handle this format, instead it relies on other software packages, to handling the processing of the individual frames into and out of the animations. These 'delegate' programs include "mpeg2decode", "mpeg2encode", and "mplayer".

See MPEG, M2V, and AVI below).

GIF Image File Format

The GIF format is a very widely known image file format, as it has been around for a very very very long time (from the late 1980's). It is often picked for images which are to be displayed on web pages that involve transparency or image animation. It is also about the only format absolutely universally understood by all web browsers.

Unfortunately it is not a very good format for anything but line drawings, figures, diagrams, and cartoons. That is because it is limited to a maximum of 256 colors, one of which is usually flagged as being transparent.

Flagging one specific color in the image as transparent has some drawbacks. If the color to use as transparent is badly chosen, it can result in other parts of the image being transparent when that was not intended. Care must be taken to ensure that does not happen.

Further more, the transparency ability is 'Boolean', which basically means it is either fully on, or fully off. Semi-transparent colors are just not possible, and if present need to be made either transparent or opaque. That means the format can not provide any form of anti-aliasing of edges of an image, usually resulting in a bad case of the 'jaggies'. (See Anti-Aliasing)

Because the "GIF" image formats color limitations causes so many problems, especially from a high quality image processing package like ImageMagick, I would like to say up front...

Avoid GIF format, if at all possible.
If you must use it, do so only as the final step.

Finally for a long time the compression algorithm used by GIF was patented. Consequently it was not available for use by many image processing programs, such as ImageMagick. Thus very old IM programs will output GIF format images un-compressed, and thus using more disk space than it should. You can fix this using a GIF batch compression program such as "Gifsicle" or "InterGIF". However as the patent expired completely in mid-2004, the current release of IM has the GIF image compression re-enabled again.

The image compression is also rather simple, and works best on images with large areas of solid, unchanging colors. Or on simple repeated patterns of the same set of colors, such as you get using Ordered Dithering (not the default dither in IM).

Finally GIF images can save multiple images in the one file. And this is used to generate GIF Animations as understood by pretty well all web browsers, since the technique was first introduction by early versions of the very old Netscape browser.

In Summary The GIF image file format with its limited color table, Boolean transparency, and simplistic compression (if enabled), makes it ideal for small images, such as thumbnails, and especially "cartoon-like" icons, logos, and symbols images with large areas of solid colors. Its animation abilities also make it an ideal method of generating flashy attention grabbing logos and advertisements you see all over the World Wide Web.

For anything else its limitations make it a poor image file format and you may be better moving to JPEG, PNG, or a video image format for your needs.

GIF Limited Color Table

FUTURE: color reduction examples -- reference basic color dithering
Ensuring that a specific color is present in the final GIF image
Map color tables to color reduce.
See Color Quantization.
See Advanced 3-D Bullet Scripting for an example of generating multiple images over a range of colors. This technique can also be used to auto-convert your image into multiple images for many different backgrounds colors and patterns.

GIF Transparency Color

For example here we use identify to extract the transparent color, and the color table a particular GIF image file used to represent transparency. The perl script extracts just the specific fields of interest (which can be multi-line).

  identify -verbose hand_point.gif |\
      perl -0777 -ne 's/^  //gm; \
            print $& while /^(Colors|Alpha|Colormap):.*?(?=^\S)/gms'
[IM Output]
[IM Output]

As you can see, a transparent grey color ('#CCCCCC00') was used for this image and this color has its own separate entry in the color table.

You can also see that even though this image only uses 6 colors, the color table used is for 8 colors. The GIF file format can only use a color table that is a power of 2 in size. That is the color table is always 2, 4, 8, 16, 32, 64, 128 or 256 color entries in size. As such the last two color table entries are not used.

As of IM version 6.2.9-2 (and in some older versions), IM will preserve this color value when it reads, processes and writes a GIF image.

  convert hand_point.gif    -fill white -opaque wheat   hand_white.gif
  identify -verbose hand_white.gif |\
      perl -0777 -ne 's/^  //gm; \
            print $& while /^(Colors|Alpha|Colormap):.*?(?=^\S)/gms'
[IM Output]
[IM Output]

As you can see even though the image was modified (all 'wheat' color pixels were replaced with a 'white' color) the transparent color used was preserved

However if the final image has no transparency, the transparency color entry ('Alpha:') in the color table is completely removed.

  convert hand_point.gif   -background white -flatten    hand_flatten.gif
  identify -verbose hand_flatten.gif |\
      perl -0777 -ne 's/^  //gm; \
            print $& while /^(Colors|Alpha|Colormap):.*?(?=^\S)/gms'
[IM Output]
[IM Output]

If you like to change the transparent color that the GIF file format is using, you can use the "-transparent-color" output setting (added IM v6.2.9-2). For example...

  convert hand_point.gif -transparent-color wheat  hand_wheat.gif
  identify -verbose hand_wheat.gif |\
      perl -0777 -ne 's/^  //gm; \
            print $& while /^(Colors|Alpha|Colormap):.*?(?=^\S)/gms'
[IM Output]
[IM Output]

As you can see even though the result is not visibly different from the original, the transparent color was changed to a fully-transparent version of the 'wheat' color.

If you look closely you will also see that the image now has two 'wheat' or '#F5DEB3' colors in its color table. That is, one transparent wheat and one opaque wheat. As of IM version 6.2.9-2, this presents no problem. Though only one transparent color can be defined by the GIF image file format.

Why would you do that? Because some very old web browsers and graphic programs do not understand GIF transparency. So this option lets you set what color the transparent areas should be in that situation.

Typical choices for the transparent color are 'white' for modern browsers, OR more typically 'grey75' ('#BFBFBF'), which was the original "mosaic" web browser page color. This color is nestled between the colors 'grey' ('#BEBEBE'), and 'silver' ('#C0C0C0'), showing just how popular that area of the gray-scale color range is.

FUTURE: add link to color selection.

Before IM v6.2.9-2, and the creation of the "-transparent-color" output setting, IM would typically save the transparency of an image as the special color 'none' (fully-transparent black), which is not particularly nice when transparency fails.

Note that setting "-transparent-color" does NOT add any transparency to a GIF image, nor does it convert the specified color to become transparent. All the option does is specify what color should be used in the color table for the color index representing the transparent colors in a GIF image.

If you want to change a specific (exact) color to become transparent, then use the "-transparent" color replacement operator. (See Replacing Specific Colors).

GIF Boolean Transparency

Because the GIF format does NOT understand semi-transparent colors, and as ImageMagick by default generates semi-transparent color as part of its normal Anti-Aliasing Methods, when you save a image to this format it will often come out horrible looking.

For example, here I draw a simple black circle on a transparent background. Also I will generate an enlarged view of the edge of the images, to make it clear what is happening.

First I will output using the PNG format...

  convert -size 60x60 xc:none -fill white -stroke black \
          -draw 'circle 30,30 5,20' circle.png
  convert circle.png -crop 10x10+40+3 +repage  -scale 600%  circle_mag.png
[IM Output] [IM Output]

As you can see the edge of the circle on the left drawn (in PNG format) as a very clean looking (though slightly fuzzy) edge to the image. You can see the semi-transparent pixels in its enlargement.

Now lets output the same image using the "GIF" image format...

  convert -size 60x60 xc:none -fill white -stroke black \
          -draw 'circle 30,30 5,20' circle.gif
  convert circle.gif -crop 10x10+40+3 +repage  -scale 600%  circle_mag.gif
[IM Output] [IM Output]

The result is that the circle has a very sharp stair case effects along the outside edge of the circle, while the inside remains properly anti-aliased.

Basically while PNG format can save semi-transparency pixel information, GIF cannot. The GIF image format can only save a single pure transparent color. In other words...

GIF format has a on/off or Boolean transparency

If you look more closely at the resulting GIF, you will find that the semi-transparent pixels could have either become fully-transparent or full-opaque.

What ImageMagick actually does with semi-transparent pixels depends on just what version of IM you are using. It was for a long time not properly defined and what a version did, often depended on the last 'bug fix' that was applied due to bug reports from users.

As of v6.2.9-6 ImageMagick should by default threshold the image at a 50% level for both GIF and XPM image formats. This has become the accepted standard as used by image handlers, while still allowing you to set your own methods of dealing with the transparency problems of the GIF file format.

Because of the GIF limitations, IM performs the following set of operations before saving to the GIF file format...
    -channel A -threshold 50%
    if (fully-)transparent pixels are present it then...
      -quantize transparent -colors 255
    otherwise if no transparent pixels present...
      -colors 256
The -colors quantization process automatically does nothing if less that that many colors are present in the image. Nor will it do anything if the image has a valid colormap (as assigned by "+/-map").

It also does not attempt to use a common color map for multi-image GIF files. As such if the colors are very different from one frame to the next, a local color table may be added to each individual image saved into the GIF file format.

Also the settings used in the above are not permanent just temporary for the image being saved. That is if you used "-write image.gif" the settings used during the process do not effect later operations.

You may like to do the thresholding yourself, and this is recommended if you are not certain of what version of IM (especially older versions) you are using.

  convert -size 60x60 xc:none -fill white -stroke black \
          -draw 'circle 30,30 5,20' \
          -channel A -threshold 50%  circle_threshold.gif
  convert circle_threshold.gif -crop 10x10+40+3 +repage \
          -scale 600%   circle_threshold_mag.gif
[IM Output] [IM Output]

The above example performs the same "-threshold 50%" on the alpha channel that IM now does automatically, that is if a pixel is more than 50% transparent, it will be made fully-transparent (using the color given by the "-transparent-color" setting if defined.

However you now have control of the threshold level as you like.

Thresholding the alpha channel at 50% works well for most types of images. Especially those with a simple edge, but the technique breaks down rather badly, when you need to deal with large areas of semi-transparent pixels. This is what the most of the following examples for GIF handling will look at.

For example suppose we want to save a image with a large fuzzy semi-transparent shadow such as this image (in PNG format)...

  convert -size 70x60 xc:none -font Candice -pointsize 50 \
          -fill black -annotate +10+45 'A' -channel RGBA  -blur 0x5 \
          -fill white -stroke black -draw "text 5,40 'A'"   a.png
[IM Output]

If you just convert this letter directly to GIF format or even use a "-threshold" operation to control the Boolean transparency, you will be sorely disappointed.

  convert a.png  a.gif
  convert a.png -channel A -threshold 75%   a_threshold.gif
[IM Output] [IM Output]

The first image is a normal save to GIF format, which as you can see thresholded the semi-transparent pixels at '50%', the second image was thresholded at '75%' allowing more semi-transparent pixels to become fully-opaque (or visible).

If you just want to remove all the semi-transparent pixels (EG the shadow) you could try something like a "-threshold 15%", to remove just about all semi-transparent pixels.

  convert a.png -channel A -threshold 15%   a_no_shadow.gif
[IM Output]

Most other solutions to the GIF Boolean transparency problem is to inextricably tie the image to the background color of the web page on which it lives. Methods for doing this are complex and tricky, and this is what we will now look at.

GIFs on a solid color background

What we would really like to to somehow preserve the shading of the semi-transparent and anti-aliased pixels, and still display it nicely on the WWW. To do this we have to be a little tricky.

The typical solution is to match the image to the background on which you are going to display the image on. This is simple to do, just overlay the image onto a background of the appropriate color, before you save it to the GIF format. This removes the need for any form of transparency and the whole thing becomes a non-issue. Of course the limited number of colors is still an issue, but often not a big problem.

  convert a.png -background LightSteelBlue -flatten  a_overlay.gif
[IM Output]

See just about perfect!

Of course for this method to work correctly you need to know what exactly the background color the image will be used on. Also after we are finished the image will not be much good on any other background. A big sacrifice to make.

GIFs on a background pattern

But what if you are using some pattern for a background, instead of a simple solid color?

You could try positioning the overlay onto a copy of the background pattern so that the pattern in the resulting image matches the pattern of the web page. However that would require a lot of trial and error to get the background in the image to match up with the web page. Also you could only guarantee it to work for a particular browser, and then only that specific version of the browser. Not a good idea for a web page, so don't even bother to try. I certainly won't.

Instead of trying to do a perfect match-up with the background pattern, lets just overlay it onto a color that at least matches the background we intend to use.

For example lets overlay our image onto a 'typical' bubble like background pattern. But first we need to know the average color of this background. A simple way to find this color is to just scale the image down to a single pixel, then read the resulting color.

  convert bg.gif -scale 1x1\! -depth 8 txt:-
   [IM Text]

See IM Pixel Enumeration Text Format for more information on the special "txt:" output format used.

Now lets set the background transparency of the image using "-flatten".

  convert a.png  -background '#BABBD7' -flatten  a_bg.gif
[IM Output]
I have setup the web page to overlay our image on that background, even though that background is NOT part of the image itself.

Though the background color used matched the general color of the background pattern, it still has a very obvious rectangle of solid color, devoid of the the background pattern, around it.

One practical solution is to declare the color we overlay, as the "-transparent" color in the GIF output. By doing this we remove the 'squareness' of the image. Also adding a small fuzz factor improves the result and adjusts the amount of space the transparent color uses, in the same way threshold did above.

  convert a.png  -background '#CACCE2' -flatten \
          -fuzz 10%   -transparent '#CACCE2'   a_bg_trans.gif
[IM Output]

In essence we are using the transparency to set a basic outline shape to the image, rather than a true transparency. By using a color for the overlay and GIF transparency so that it matches the background pattern means it is no longer clear exactly where the image stops, and the background pattern starts.

Note that while actual average color for the background image is '#B9BBD6', but I purposely used a much lighter background color, '#CACCE2'. That was because the shadow itself will darken the background. The result is that the actual border between the image and the background (as determined by the fuzz factor) became almost seamless.

Be cautious however with the "-fuzz" setting, as too much and you can end up with more than just the outside of your image becoming transparent!

  convert a.png  -background '#CACCE2' -flatten \
          -fuzz 20%  -transparent '#CACCE2'   a_bg_overfuzz.gif
[IM Output]

It will also fail if you used a color close to the background colour within the image itself. As such this technique is not recommended for general images, but only in specific cases.

To solve this problem we use a 'matte floodfill' to set the areas we want transparent.

  convert a.png  -background '#CACCE2' -flatten \
          -fuzz 20%  -draw 'fill none  matte 0,0 floodfill' a_bg_none.gif
[IM Output]

Lets complete the job by telling IM to use our original background color as the transparent color in the GIF images color table.

  convert a.png  -background '#CACCE2' -flatten \
          -fuzz 20%  -draw 'fill none  matte 0,0 floodfill' \
          -transparent-color '#B9BBD6'    a_bg_trans_2.gif
[IM Output]

Now as long as the borders of our image do not 'leak' we can use similar colors inside the image as our background, and not have them turn transparent on us, due to 'over fuzzing'.

Of course if our image has 'holes' in it, then those holes will also have to be taken care of too. In which case the previous 'fuzzed transparency' may work better.

As a final example. Lets combine all the techniques together and automate a few final problems... and here is the result.

  convert a.png \
          \( bg.gif -resize 1x1 -gamma 2.0 +clone +swap +matte -fx v \) \
          -compose Dst_Over -composite \
          -fuzz 15%  -draw 'fill none  matte 0,0 floodfill' \
          -transparent-color dodgerblue   a_bg_final.gif
[IM Output]

Did say handling a GIF transparency color is easy! NOT!

At least you now have two simple numbers you can adjust until you get exactly what you want for a given background color. The rest of the IM command's complexity can be just left alone, or scripted of ease of use.

[IM Output] This is not a perfect solution (see the image to the right, displayed on this pages normal background color), but for a images with only a VERY small amount of edge smoothing (or anti-aliasing), you would be hard pressed to even notice any sort of problem. In fact this method is actually very commonly used on the world wide web to smooth the edges of GIF images with transparency, for use on specific backgrounds.

Just remember that a image transformed in this way is designed for a specific background color. Also it will not handle any 'holes' in the image.

Worse still, converting an existing image to a different background when you don't have the source of the image, is a very difficult problem. This is something that makes recycling images that you find on the WWW a real problem. Specifically re-adding background transparency or the restoring the image's mask on a opaque image is difficult. This is looked at in the IM Examples section on Re-adding Transparency to an Image.

GIFs for non-specific backgrounds (or Dithering the Transparency)

FUTURE: This will move into a more generalise (non-GIF specific), alpha
dithering section.
The biggest problem with the above is that it would only work if you happened to know exactly what color the background, or background pattern your image will be used on. If you don't know all is not lost.

As you saw above, threshold does not work well for a image with a very large area of transparency, such as a fuzzy shadow. But another technique known as dithering can, and does NOT require knowledge of the background it will be used on.

Basically dithering limits the transparency to on/off values, creating an effect of semi-transparency over a larger area using a pattern if pixels. In other words it fakes semi-transparency.

This method was exampled in what is now known as the "Opossum Examples". Unfortunately these examples did not actually give the commands that were used to generate the example. For completeness I will attempt to demo them again here.

The "-monochrome" operator converts all colors in an image into a pure black and white "Floyd-Steinberg error correction dither". However as it converts a grey scale image into just pure back and white colors we will need to extract an alpha channel mask from the image, dither that, and return it back into the image. A procedure which is not so difficult with the new IM version 6 options.

  convert a.png \( +clone -fx a +matte -monochrome \) \
          -compose CopyOpacity -composite   a_dither.gif
[IM Output]

In a similar way, there are a couple of other dither operators which can be limited to just the alpha channel using the "-channel" setting (unlike "-monochrome").

  convert a.png -channel A -ordered-dither   o2x2   a_ordered_2x2.gif
  convert a.png -channel A -ordered-dither   o3x3   a_ordered_3x3.gif
  convert a.png -channel A -ordered-dither   o4x4   a_ordered_4x4.gif

  convert a.png -channel A -ordered-dither  checks  a_halftone_2.gif
  convert a.png -channel A -ordered-dither  h4x4a   a_halftone_4.gif
  convert a.png -channel A -ordered-dither  h6x6a   a_halftone_6.gif
  convert a.png -channel A -ordered-dither  h8x8a   a_halftone_8.gif

  convert a.png -channel A -random-threshold  5x95% a_random_5x95.gif
  convert a.png -channel A -random-threshold  5x70% a_random_5x60.gif
  convert a.png -channel A -random-threshold 50x95% a_random_50x95.gif
  convert a.png -channel A -random-threshold 45x55% a_random_45x55.gif
  convert a.png -channel A -random-threshold 50x50% a_random_50x50.gif
[IM Output] [IM Output] [IM Output]
[IM Output] [IM Output] [IM Output] [IM Output]
[IM Output] [IM Output] [IM Output] [IM Output] [IM Output]

As you can see "-ordered-dither" produces a pattern of transparent and opaque colors to represent the overall transparency. This however produces a very noticeable regular pattern. However if you use a shadow color that is similar too but darker than the normal background then you can make this pattern almost completely invisible.

The 'checks' pattern is of particular interest as it is a 3 level pattern that is very clean, and neat.

The "-ordered-dither" was extended in IM v6.2.8-6 with new proper 'half-tone' dither patterns. The operator was then completely revised for IM v6.3.0 with named dither patterns (use "-list threshold" to see the full list). You can even generate your own dithering pattern to generate other special effects (such as speed). See Ordered Dithering Examples and the Ordered Dither Upgrade notes for more details.

Before this redevelopment, arguments could only consist of the geometry strings '2x2', '3x3' and '4x4'. Anything else was then treated as being a "-random-threshold" argument, usually with disastrous results. Caution is required when using older versions of this option.

The "-random-threshold" on the other hand produces a highly variable randomized dither that is different each time it is run. The purely random nature of the this dither algorithm however tends to produce large 'clumps' of pixels, rather than the smoother, algorithmic placed dithering generated by the "Floyd-Steinberg" "-monochrome" operator.

The big advantage of "-random-threshold" however is the limit controls it provides. By making the parameters very restrictive (for example as '50x50%') you would convert -random-threshold" into a simple "-threshold" operator. By being only a little less restrictive you can randomize just the very edge of the threshold limit, (for example using '45x55%').

The "-random-threshold" argument 'PxQ', where P is the min threshold and Q is the max (the '%' symbol is required). So "5x95%" says anything below is 5% of MaxRGB is set to 0, anything above 95% is set to MaxRGB otherwise we choose a random value between 5% and 95% of MaxRGB, as the threshold level to use for that pixel. A argument of "5x95%" value is probably the best value to use in most situations.

You can improve the final look by using a darker mid-tone color (like a dark grey) instead of black for the shadow color. By doing this the color will tend to blur into the background more making the dither less pronounced that what is shown above.

If you do know approximately what the background color is, you can even use a darker color of that shade to make the shadow bend in better without restricting yourself to the specific background shade. Sort of mix the two methods a little to improve the overall result.

Basically The more work you put into what you want to do, the better the result will be.

FUTURE: dither example with a dither color matching the light blue background
of this web page.

Non-ImageMagick GIF Processing

giftrans Lists all the attributes and color table of GIF image. It can also set a specific color index as the transparent color without modifying the images color table ordering, or merging color indexes holding the same color (not a recommended situation).

The IM "identify" command I have found to do a better job of listing image attributes, including the 'loop repeat limit' in the "Mosaic Application Extension" used in image animations.

See also the "gif2anim" script (below), which internally can use either the output from "giftrans" or IM "identify" to re-create IM "convert" settings.

GIFsicle This is a general-purpose image optimizer program, whose original purpose was to re-add compression to GIF images at a time when that algorithm was still under copyright.

The program can also be used to add comments, create GIF animations and also optimise such animations in the same way that the IM "-deconstruct" operator does, though with further transparency optimizations such as LZW Compression Optimization.

InterGIF A similar program to GIFsicle, designed for processing animated GIFs. However it only provides Transparency Compression Optimization. Other features however may be useful however. Mail me your views.

gif2anim My own shell script which takes a GIF animation file, and extracts all the individual frame images, as well as a ".anim" file containing all the IM "convert settings needed to rebuild the animation from the extracted frame images.

anim2gif The reverse of the above script, which takes a ".anim" file containing all the IM "convert settings and rebuilding a GIF animation image.

This script is very useful for studying, editing, adjusting and merging GIF animation files. For basic usage see Animation Sequence Information. Also see Appending Animations (time synced) for a practical example of its use.

GIF Image Offset handling

While the GIF format saves images with offsets as part of its image animation handling, it will not save a negative offset. Any attempt to save a negative offset to a GIF image will result in the offset being reset to zero. This can be a real pain when designing GIF image animations.

If Internet Explorer web browser is given an GIF image whose 'page offset' places the image somewhere outside the 'page canvas size', it will ignore the page size and offset and display it as if it has no such offset.

The ancient Mozilla web browser on the other hand will just display the image canvas, and apply the offsets to the image. This can result in an empty canvas being display with no image data present, which while correct, can be annoying.

Both will display the image using the page canvas size, with the appropriate page offset if the image is wholly contained on that page canvas.

Related GIF Output formats

GIF87: Output the image in the older GIF 87a format.

If the "Mozilla" web browser sees this older format it will completely ignore the page geometry of the image, and will not use a larger 'page' frame, or use image offsets with the image.

IM version 6.0.4 and earlier would normally produce a GIF89a format. But if the image was a GIF animation, and was split up into separate images using +adjoin, Im would use the GIF87a, resulting in inconsistent results when displayed in web browsers.

IM after v6.0.4 will always produce a GIF 89a image format file, unless the user specifically asks for the older "GIF87:" output format.

JPEG Image File Format

This format is about as common as the GIF format above. But where GIF is designed with small simple "cartoon-like" images in mind, JPEG is designed for large real life images with lots of different colors, and shades of colors, such as photographs.

A key feature of the JPEG file format is its compression, which reduces image size while keeping the image acceptable to the human eye. This is a very complex process and beyond the scope of this discussion. For more information about this process and its effects see Jpeg Compression Introduction.

Unfortunately, to compress images well, the algorithm intentionally loses information. What is saved is NOT the same image as what is in memory; the color of a particular pixel or area of an image will generally will NOT be exactly the same color that was saved. This is particularly true near the edges of objects within the image.

Now for a quick word of warning...
IM is a general raster image processor, for modifying images.
It will not do lossless JPEG modifications.
If you are interesting in lossless handling, see Non-IM JPEG Handling.

Normally this lossy nature of JPEG is not very noticeable. However it can become noticeable when you either load and save a JPEG image multiple times or use a very low quality with a diagram showing sharp color changes.

However as long as you don't load or re-use JPEG images over and over (preserve and apply operations from the original source), it is still a good file format even image types it is not particularly good at handling.

As an example of this lossy JPEG nature, here I generate a simple image of two gradients appended together. While the gradients provide a smooth color change that JPEG handles very well, the sharp color change between the two gradients are not handled well.

  convert -size 5x10  gradient: gradient:blue-navy  +append jpg_lossy.gif
  convert jpg_lossy.gif                  jpg_lossy.jpg
[IM Output] ==> [IM Output]

The first image is a magnified view of the undistorted GIF format version of the image. It only contains 20 colors, so in this case the GIF format can handle the image perfectly. On the other hand the second JPEG version of the image shows clear color distortions that the JPEG compression added to the saved image

The distortions are greatest in the blue color channel, which is not surprising as blue is not resolved well by the human eye. That is the human eye tends to 'spread out' blue colors naturally, so the JPEG algorithm takes advantage of this. In fact with out the magnification used above you would be hard pressed to see the effect.

Lets have a look at the effect of quality on the image.

  convert jpg_lossy.gif   -quality 100%  jpg_lossy_100.jpg
  convert jpg_lossy.gif   -quality  80%  jpg_lossy_80.jpg
  convert jpg_lossy.gif   -quality  50%  jpg_lossy_50.jpg
  convert jpg_lossy.gif   -quality  20%  jpg_lossy_20.jpg
  convert jpg_lossy.gif   -quality   5%  jpg_lossy_5.jpg
[IM Output] [IM Output] [IM Output] [IM Output] [IM Output]

If you look closely at first image in the above, which we saved the test image at '100%' or maximum quality, there is still some slight color distortion. It is very hard to see, but it is present.

On the other hand using a progressively lower "-quality" setting for the JPEG image just makes this color distortion even larger. Not only that it sets up a sort of 'shadowing' of the edges producing 'waves' of color changes spreading out from the sharp edges.

However the reason for using compression is that the size of the resulting image is very dramatically smaller, at least initially...

  ls -lS jpg_lossy* | awk '{ print $5, $8 }'
[IM Text]

Note that the GIF image in this case is very small, as large 'blocks' of color compresses extremely will in GIF. As the JPEG quality gets lower, the size of the image also gets smaller. The default quality setting, when no JPEG quality is set, either by the user, or from the source image format file, is about 85%, which is very reasonable.

However using a lower quality setting than '50%' does do not get much smaller in terms of file size savings, only a much more progressively degraded image.

In summary...
JPEG losses information degrading images when saved.
Use some other format for intermediate images during processing.
Only use JPEG format, for the final image, not for further processing.

JPEG is also not good for artificial images with sharp color changes, such as line drawings, diagrams, or cartoon-like icons, text, and symbols. Such images with a low number of colors are better saved using a palette image format, such as GIF, or PNG8.

NOTICE: A new JPEG image format, Jpeg2000, is becoming available which does allow lossless JPEG compression. However this requires the 'JasPer' library to also be installed. To use this special format, you also need to use a "-compress jpeg2000" option or save to a JP2 file format, so IM will call the right library.

JPEG transparency - NOT

Other than compression, the other major problem that JPEG users faces is that
JPEG does not save transparency

Thus while you can overlay images onto a background color or pattern and save to JPEG, you cannot give a JPEG image a free-form border or with see-through holes.

As JPEG was designed to save real world images, and not parts of images, as such transparency was not an issue it was concerned about, when the format was created. Consequently the designers never worried about including an alpha channel, or other transparency information in the file format.

For example let take the PNG with transparency we used above and convert it directly to JPEG.

  convert  a.png  a.jpg
[IM Output] ==> [IM Output]
As you can see all transparent parts just became black. But depending on the image source (especially GIF images) the transparent areas could have just as easily become some other random, or other inappropriate color.

If this could be a problem the best idea is to have IM replace the transparency with a better color by using either a "-flatten", "-border" or, "-frame" operator to compose the image over a solid color background. Or tile an image underneath.

  convert a.png -background  skyblue -flatten         a_flatten.jpg
  convert a.png -bordercolor skyblue -border 5x5      a_border.jpg
  convert a.png -bordercolor skyblue -frame  5x5+2+2  a_frame.jpg
  composite -compose Dst_Over -tile pattern:checkerboard \
                                               a.png  a_undertile.jpg
[IM Output] [IM Output] [IM Output] [IM Output]
For more information on these techniques, see Flattening Image Layers, Adding a Border, Framing Images and lastly Alpha Composition for a more generic look at the DstOver, under-laying method.

JPEG Color Distortion (testing)

As mentioned above, the compression algorithm JPEG used is lossy. That image will be modified to allow it to compress better, reducing file space, hopefully.

Exactly how much color distortion occurs depends on the quality settings use. For example let us look at how many colors are in the IM built-in "netscape:" image...

  identify -format "Colors: %k" netscape:
[IM Text]
As you can see this image by default has 216 colors in a large rectangular array. This type of image is NOT a very good image for saving to JPEG format, which makes it ideal for our purposes.

So lets look at the number of colors a JPEG image save of this image produces...

  convert netscape: JPG:- |\
     identify -format "Colors: %k\nFile Size: %b" -
[IM Text]
That is, by default, the saved JPEG file has almost 9 times as many colors! Though the result would still look like the original image, the edges of the rectangular area will have had colors added to nearby.

Saving at the highest quality setting will not save the image without any color distortion...

  convert netscape: -quality 100 JPG:- |\
     identify -format "Colors: %k\nFile Size: %b" -
[IM Text]
As you can see a very high quality setting will only add a few extra colors but the image will still have a slight (minimal) color distorted. You can also see that the filesize is larger, as very little compression can be achieved.

Now let us try "Lossless"...

  convert netscape: -quality 100 -compress Lossless JPG:- |\
     identify -format "Colors: %k\nFile Size: %b" -
[IM Text]
Still a color distortion! Obviously my JPEG library is NOT patched for lossless encoding. However remember only another patched library can read such a lossless JPG image.

Alternatively I recommend compiling you IM to use the JasPer library and the newer JP2 image file format.

  convert netscape: JP2:- |\
     identify -format "Colors: %k\nFile Size: %b" -
[IM Text]
As you can see the Jpeg2000 format switched to other non-lossy methods of image compression, but does not color distort the image, by default. It also performs some very high compression methods on the image.

However using a lower quality with the new JP2 format will again introduce the color distortions, so as to generate a smaller image, just like the normal JPEG image file format...

  convert netscape: -quality 50% JP2:- |\
     identify -format "Colors: %k\nFile Size: %b" -
[IM Text]

Reading JPEG Images

-size {width}x{height}
This is a setting hint to the JPEG image library to only read enough of a JPEG image file to an image that is this size of larger. In the image stored on a disk is huge, this can save a lot of memory space. It also can dramatically increase the image processing speed as IM does not then have to deal with very large images itself.

Generally this setting is used when you are going to resize the JPEG image immediately after reading the image (usually with "-thumbnail" to also strip profiles as well.

    convert -size 64x64  jpeg_large.jpg  jpeg_size_hint.jpg
    convert -size 64x64  jpeg_large.jpg  -thumbnail 64x64  jpeg_thumbnail.jpg

WARNING: as this option is often set to generate canvases, it is essential you reset it with a "+size" setting to turn it off, before reading a JPEG image at its full size. If you don't your JPEG image will probably be much smaller than expected.

+profile '*'
JPEG images as saved by digital cameras, scanning software and other image processing software like "photoshop" will often add large profiles of "program comments" to JPEG images. Either of these options will remove those profiles from a image, after that image read in.

The "+profile" operator will remove all color profiles from an image, while "-strip" will remove all profiles and meta-data that the image may have.

Also note that "-thumbnail" is a "-resize" option that will also so a "-strip" at the same time. See also Creating Thumbnails.

-type TrueColorMatte
As JPEG does not save any form of transparency, when it is read in it will always be fully-opaque, and have not 'alpha' or 'matte' channel in memory. This setting will force any JPEG image read in after the option to have a fully-opaque 'matte' channel to be added to the image in memory.

The better way to do this however is to use a "-matte" after reading the image, as it will have less impact on the reading and writing of other image formats.

See Image Type when Reading and Writing for more information.

Writing JPEG Images

-quality {percent}
Probably the more important option when saving JPEG images, as this controls just how much the image is compressed when save it to disk. The value is not a size percentage, just a quality value. The lower the value the smaller the image and the more image information is lost, producing more artifacts, and degrading the image.

    FUTURE: VERY low quality example of a photo

NOTE: a quality setting of '100%' is not guaranteed to save an image without any loss of quality, just a minimal amount of loss. (See the next option)

NOTE: You can not determine a quality to get a specific filesize, except by trying it. The best way is to say try a "-quality" of 75% and see the result if to large reduce by 10%, if two small increase. Then do a binary search to find the quality that best matches what file size you want. Shouldn't take more than 5 to 6 tries to figure it out.

-compress LossLess
While a "-quality" setting of '100%' can still produce slightly different colors (it is still 'lossy'), the "-compress LossLess" option will ask the JPEG library to save the image without any loss of data. As such re-reading the image will restore should be exactly as it was saved.

WARNING this will only work if your JPEG library has been patched for 'LossLess JPEG' encoding, but the use of the JP2 file format has replaced this so this option rarely has any real effect anymore.

Also you MUST also set "-quality 100%" for this to work.

While intuitively you would think that saving with 'LossLess' will automatically mean using a 100% quality, this is not the case. This is the result of tacking on an unusual patch for the JPEG image writing, which is a lossy format by definition.

Of course the file generated will probably much be larger than a normal JPEG image. Also you will end up with a lossless compressed JPEG which you won't be able to read anywhere except with a similarly 'patched' JPEG library.

As such 'lossless JPEG' is NOT recommended and some other format (like PNG or JP2) should be used instead.

-interlace Line
Use a 'Progressive JPEG' style that allows you to see large jpeg images while it is still being loaded. Also see the non-IM solution for re-encoding a existing JPEG without further loss, below.

-sampling-factor {horizontal}x{vertical}
Adjust the sampling factor used by JPEG library for chroma down sampling. This can be set to '2x1' for creating MPEG-2 animation files.

"2x2, 1x1, 1x1" is IM's standard subsampling method and corresponds to 4:2:0, see Wikipedia, Chroma SubSampling.

-density {Xdpi}x{Ydpi}
While density has no effect on the output pixel size of the the resulting image. The above setting however is stored in the JFIF header of the JPEG image file format. Unfortunately some programs like Photoshop will ignore this setting if a density is also present in a special photoshop specific profile ('8BIM') stored in the image.

Density is used strictly used for output devices (such as printers), which also includes monitors, allowing these devices to display the image scaled to real world sizes. For example ensuring the photo or page you scanned is displayed at the right size. For more information about density see and Image Density Meta-data and Resample Resizing.

-define jpeg:preserve-settings
Set the "-quality" setting to the same setting that was found when reading the JPEG image. This however may not produce the same file size on the disk, and you will still have a further loss of image quality due to reading and re-saving an JPEG image.

This also resets the "-sampling-factor" being used by the JPEG library to its internal defaults.

-define jpeg:optimize-coding=false
Unset the JPEG optimize flag to the JPEG library.

-type TrueColor
IM will automatically use a gray-scale internal format for images that only contain greyscale values. This setting will override this behaviour and force IM to always produce a color JPEG image rather than gray-scale.

See Image Type when Reading and Writing for more information.

Special thanks to Glenn Randers-Pehrson <> for most of the above information on JPEG formats.

JPEG Quality vs File Size

The final file size of a JPEG file for a given quality is indeterminate. Even the same source picture with the same quality, but with different versions of IM, JPEG library, or other image processing programs, you can get very wide differences in file size, and observed quality. You may as well treat the quality setting as a 'guess' as to how compressed or visual quality you like the result to be.

You can't ask IM to generate an image at a particular file size. It is a practical impossibility to pre-determine the final result. What you can do is use trial and error to find a quality setting that produces desired file size, but that would be both time consuming and inappropriate.

The best idea is to find a single quality setting that produces an average file size of 100KB for a reasonable selection of your images. Even then images with not much detail in may come out at only 50k. While images with lots of intricate detail may come out at 150k, both will look acceptable.

By your fixed file size method, the simple image might come out at quality 90%, but contain 50k of unnecessary data, whereas the complicated image would have to drop to quality 30% and be exhibiting JPEG artifacts (or to put it less technically, it would look rubbish) due to a shortage of data for the detail present. (NOTE: I made those numbers up, but the principle is correct) The above was contributed by, Chris L.

For a practical guide to the JPEG compression and quality, see Optimization of JPEG compression settings.

Also see JPEG Compression, Quality and File Size for a look at the JPEG internal details.

Photoshop Tip: Photoshop will add about 4 Kbytes of extra information to JPEG images to hold previews and color management info (profile '8BIM'). If you do not want that information, use the ’Save for Web’ function. This tip was found in a paper on JPEG compression by Gernot Hoffmann.

Related JPEG Output Formats

JPEG2000: The latest JPEG format with new additions.

This format requires the 'JasPer jp2' library to be installed or you get a
"no encode delegate for this image format"

This format uses wavelet compression to compress images instead of the standard JPEG DCT method. This gives you much better compression ratios for the same image quality. Thus reducing disk space even more.

If you don't know then you have not patched the JPEG library you probably do not have JPEG2000.

Unfortunately it hasn't been widely adopted yet, so you can't use it for external purposes, at least until web browsers and other image viewers and editors also start making use of the format.

Any images saved with this format are only readable by users with this library, and it will probably be a long time before a good percentage of uses use this library. Particularly windows users as Microsoft will probably not include it unless enough people demand it.

Quicktime Tip: Quicktime uses jp2 format but it must be output at "-depth 8".

Non-ImageMagick JPEG Processing (A quick summary)

jpegtrans Standard tool that is installed with the JPEG library. This allows you to apply various transforms to JPEG format images without decoding and re-encoding the image data, thus causing it to degrade. (see below)

jpegtrans A newer version of the previous "jpegtran" program, though many of these (such as lossless cropping) has now been built into the distributed library version (above).

jhead A more user-friendly lossless JPEG handler, especially with regards to the EXIF digital camera profile. That the handling of comments, date adjustments, thumbnail extraction, deletion or replacement, profile stripping, etc. It also attempts to ensure that other profiles are not trashed, which is something that "jpegtran" tends to do.

There are also other similar programs such as "ExifTool", and "Exifer". Many JPEG to web photo-album programs also does this.

As you can see most of these programs are designed to process JPEG image meta-data without re-processing the JPEG compressed image. (see next)

Lossless JPEG Processing

As re-writing a JPEG image results in a degrading of image quality (unless lossless compression is used) the JPEG image library provides a number of special programs that can manipulate the image, without loss of quality.

These commands will also be generally a lot faster than IM equivalents, as they do not have to do as much processing of the image.

These command include "rdjpgcom", "wrjpgcom", and the most important one "jpegtran" which allows you to flip, crop and insert image data rounded into 8x8 pixel blocks, without loosing image quality.

However these commands are NOT recommended for general use as they also tend to delete any extra profiles from the JPEG image files.

The better program to use is the "jhead" program, as it makes use of the above lower level programs, but preserves any profile or other information that is also present in the image.


If you are creating Montage Thumbnail Web Index Pages of your JPEG photos, and like to use the comments you add to the JPEG files, using the above programs, use a "-label '%c'" to tell montage to use the 'comment' field, before reading filename on the "montage" command line.

You can also use that comment in a Complex Polaroid Transformation, or a Polaroid Montage or some type of image Annotation.

The "jhead" program be used to add or modify comments in JPEG image files. However I found using the "edit comments" ("-ce") option to not a good way to do that as it adds an extra newline to the end of the comment. This extra newline stuffs up the use of commands ('%c' label formatting escape) in IM.

The better way is to use "comment input" ("-ci") to feeding in a comment (without newlines at the end), or the "comment literal" ("-cl") options to be a much better way...

   jhead -cl 'Photo of some stuff, by Joe Citizen'  image_of_stuff.jpg


Brian Jackson <> also reports that most digital cameras (his is a Cannon 1D) embed a thumbnail somewhere between 12kb-25kb in size (160x120 pixels), in the JPEG image they produce.

IM can extract these thumbnails using...

     convert  image.jpg   thumbnail:thumb.jpg

However the program "jhead" can also extract these thumbnails too...

    mkdir thumbs
    jhead -st "thumbs/&i" *jpg

This is super fast compared to IM as it does not edit the image, just transfer existing data. However the quality of the thumbnail is not nearly as good, as thumbnails IM can generate from the real image, and also may not be rotated right, and they definitely will not be the size you want.

Mixed JPEG Quality...

Wolfgang Hugemann wanted the edges of a JPEG image to not be compressed at all, as it stuffs up photo handling. See this site. The solution provided by Yuval Levy <> solution was to use "jpegtran" to insert a low quality JPG, into a high quality JPEG...

The solution:
* produce two versions of the same image with ImageMagick, one at
  the high quality 100 and the other at low quality 60 (for size reduction).
* use jpegtran to crop the q60, shaving off 8 pixels on each side
* use jpegtran to merge the q60 on top of the q100
* use jpegtran to merge to a stripe
This is untested... Use at own risk, and let me know how well it works.

Other Tools...

If you want more detailed editing of the profiles stored in JPEG image files, than what "jhead" provides, have a look at more EXIF-centric applications of the perl based, "ExifTool", an alternative compiled version "ExifTool", and a Windows GUI "Exifer", just to name a few.

PNG Image File Format

This is one of the newest and most modern image formats, supporting 32 bit colors including alpha channel transparency, but can also be optimised to a GIF like 8 bit index color scheme (256 color limit).

As such it makes a excellent intermediate format for image processing without loss of image information.

PNG compression

When used with PNG output, quality is regarded as two decimal figures. The first digit (tens) is the zlib compression level, 1-9. The second digit is the PNG filtering type: 0 is none, 1 is "sub", 2 is "up", 3 is "average", 4 is "Paeth", and 5 is "adaptive".

If your image has 256 or fewer colors, a high compression with a "none" filter is generally best (EG -quality 90). If the image is a natural image (a photo), then use "adaptive" filtering with -quality 95.

If the first digit is zero (or missing), then zlib uses the Huffman_only compression strategy which is very fast and works fairly well on photos, so if you want fast compression of photos, try -quality 01 (i.e., "sub" filter and "Huffman_only" compression).

If you have an ImageMagick image with binary (on/off) transparency, the PNG encoder will write it in an efficient manner, using the tRNS chunk instead of a full alpha channel. But if any opacity value other than 0 or MaxRGB is present, it'll write a PNG with an alpha channel. You can force this behavior by using the "-type TruecolorMatte" image reading setting, or you can save the image using the "PNG32:" format file.

An external program "pngcrush" or the newer version "OptiPNG" will attempt to re-compress a specific PNG for the best possible compression available, and is recommended for images that you plan to place on a web site. Another "pngnq" will color quantize it to a 256 color, 8bit PNG, though it is not known if this support semi-transparent colors in that format.

You can improve the compression algorithm results, and thus the final size of your PNG image by using a smaller number of colors.

  convert image.jpg -thumbnail 200x90 -colors 256 \
          -quality 90 -depth 8  thumbnail.png

This however is only recommended for small thumbnail images, and only as a final step as it is a 'lossy' operation.

Another external program "pngquant" will also perform this task for you. Although whether it does a better job is a matter of conjecture. If anyone compares IM and "pngquant" please let me know the results.

    convert  image.jpg -thumbnail 200x90  png:- | pngquant 256 > image.png

PNG, Web Browsers and Transparency

The Microsoft Internet Explorer (before IE version 7) does not correctly display PNG when any sort of transparency is involved. Now while this is the most well known browser not to fully support PNG, it isn't the only one. The PNG transparency test and Another PNG test pages will let you test your browser. They also list the browsers and versions that produce the results displayed.

However as IE (at least at time of writing) is probably the most common browser, you can add to your web page a number of work-arounds to the problem. For information on this look at my WWW Laboratory Page PNG with Transparency and IE, where I test and demonstrate the the "PNG in IE" solution I am using.

Other solutions are to convert the PNG to either JPEG (with the right colored background), or GIF formats. These methods are discussed thoroughly for GIF Images on Backgrounds.

Another solution is to set the color of all fully-transparent colors in a image before saving it to PNG. PNG will save that fully-transparent color, but be warned that just about any other IM operation will reset fully-transparent back to fully-transparent black (as transparent color is not suppose to matter at that is the way image mathematics work).

For example the standard IM examples test image uses full transparent black for any pixel that is fully-transparent. We can verify this by either turning off the alpha channel, or saving it a JPEG...

  convert test.png test.jpg
[IM Text]
Now lets save this with the fully-transparent black set to a fully-transparent 'silver' color instead...

  convert test.png -fill '#C0C0C000' -opaque none  test_silver.png
[IM Text]
Note that the image should still look correct if transparency (or the special JAVA script on the page) is working on your browser. But if we turn of the alpha channel we can see that the PNG image really does use a 'silver' color for the fully-transparent pixels.

  convert test_silver.png test_silver.jpg
[IM Text]
Note however that this does NOT fix semi-transparent pixels, and these will still have their normal (non-transparent) colors without mixing that color with either the page background, or the color used for fully-transparency.

Also as semi-transparency is no longer involved, borders can look jagged (aliased), as well as 'halo' effects, along lighter colored edges. For example look at the edges of the black circle for 'jaggies' and the white circle for 'haloing'. However using a gray replacement color should make this not as bad as using either a very dark or very light 'transparent color'.

Just remember that just about IM image processing operation will again convert any fully-transparent color that is present in an image back into fully-transparent black.

FUTURE: the PNG coder may be modified to use the color defined by "-transparent-color" to automatically set fully-transparent pixels to that color rather than black. However this will only work for PNG output and possibly (though unlikely) may have affects on programs and scripts that read such images.

My preference for PNG display problems in browsers is for Microsoft to fix IE, and it seems that version 7 (about to be released) will finally have a fully working PNG transparency handling, in all situations.

PNG and the Virtual Canvas

While normally PNG will NOT save virtual canvas size information, it does save virtual canvas offset information, and if present, IM will try to generate a 'canvas size' that is appropriate for that offset and image size. This can be important to remember for some image operators such as "-crop", "-trim" and "-flatten", etc., which make use of the images canvas or page size as part of its operation or results.

Of course you can use the "-page" setting and "-repage" operator, to set or remove the virtual canvas size and offset. (See Page Image Attribute). For example, the second IM "convert" sees the offset that is present in this PNG image, and defines a canvas that is large enough to ensure the image is visible within the virtual canvas bounds (Added to IM v6.1.7)...

  convert rose: -repage 0x0+40+30 png:- |\
      convert - -background LightBlue -flatten  png_offset_flattened.jpg
[IM Output]

However, even though the PNG format will not normally save canvas size information, IM does add some virtual canvas size meta-data to PNG images. This data however will only be usable by IM commands, and is generally ignored by other PNG image format readers.

For example the second "convert" command does see some virtual canvas size information...

  convert rose: -repage 100x100+10+10 png:- |\
      convert - -background LightBlue -flatten  png_size_flattened.jpg
[IM Output]

If the PNG is processed by some non-IM program this canvas size meta-data will probably be lost. Remember canvas size information is not normally part of the PNG image file format.

The other thing to note is that the 'offset' information can have a negative offset (unlike the GIF format), and IM will handle these appropriately, making the format good for storing intermediate Layer Images.

Some web browsers do not handle negative offsets very well, producing odd results (on version of firefox had this problem). Best to avoid a negative offset in the final images.

PNG Output Formats

PNG8: The PNG equivalent to GIF, including Boolean transparency and a 256 color table.
PNG24: 8 bit RGB channels without an alpha channel (a bit like JPEG)
PNG32: Force a full RGBA image format with semi-transparency channels.

IM will use the most economical style given above, if a plain PNG is given.

PNG8 was defined by PhotoShop, not the PNG group. And while it can handle multiple semi-transparent colors, as well as a fully-transparent color, IM assumes that it doesn't. This provides a way to force files to still be readable by Internet Explorer v6. The "Photoshop CS" program can read it.

You can force IM to create a image color index table (or palette) then IM will save that image using a "PNG8:" format...

  convert {input_image}  -type Palette  indexed.png

To force the use of an single 8 bit greyscale channel, but not a palette indexed image use...

  convert {input_image}  -type GrayScale -depth 8  gray.png

You can (added IM v6.3.5-9) also output greyscale with a transparency channel.

  convert {input_image}  -type GrayscaleMatte  gray_with_transparency.png

And for a simple two color image...

  convert {input_image}  -type BiLevel  bitmap.png

For more information see Image Type I/O Setting.

Non-ImageMagick PNG Processing

There are quite a number of helper applications for PNG, that could be useful adjuncts for generating a final PNG image file.

pngtrans PNG information stored with an image

pngcrush Tries to find the best compression of a PNG by attempting to compress the image using all logical PNG compression available, before making a final choice, for each individual image. This of course can take some time on each image.

OptiPNG A newer PNG compression optimizer.

pngquant Lossy PNG optimizer, reducing a PNG image down to an 8 bit color palette with dithering. It will build indexed-color PNG's with alpha transparency colors conveyed in the tRNS chunk.

pngnq A newer lossy PNG quantizer, to generate 8 bit color table PNG images. Also forces the use of a color palette.

pngout A Windows platform PNG optimizer (with optional GUI) that uses a ZIP compressor that is optimized for space rather than speed (also on the page linked above). "pngout" also includes options to force the PNG into pure 8bit palette mode, which is something IM does not do.

Most of these are to improve the final size of the image file, either using a lossy OR non-lossy technique. IM could also probably do some thing the lossy color quantization techniques, though currently it can not handle semi-transparency in a 8 bit color palette type of PNG image.

Image Profiles

Handling profiles photo quality images is important, However from what I can tell this is a very magical art, and not simple matter.

Not all formats use profiles, but most modern formats do. This includes JPEG, PNG, TIFF, and (as of IM v6.3.4-1) GIF.

To list what profiles are present in an image use...

  identify -verbose image.tif | grep 'Profile-.*bytes'

Common Profiles (and pointer to info I have on them) include...
EXIF Digital Camera Meta-Data
ICC Image Color Space Profile
ICM Microsoft Color Management (like ICC)
IPTC Image and Author Info
8BIMPhotoshop Meta-data profile. Including data on: Clip Paths... What else?
XMPAdobe's Extensible Metadata Platform (XMP) (See adobe page)
You can extract these common profiles using some special output formats that IM provides for this purpose. For example...

  convert -size 64x64 image.jpg  iptc:profile.iptc
  convert -size 64x64 image.jpg  xmp:profile.xmp

The "-size" argument in the above is used as a 'hint' to the JPEG library to reduce the amount of actual image data it reads into memory and then save a lot of processing of the data you don't actually intend to use.

You can also insert or re-insert a arbitrary profile as a 'blob' or binary string containing whatever information you like.

  -profile 'profile_name:data_file'

That is the file "data_file" is added 'as is' to the image as the profile profile_name. IM or any other application will ignore such profiles, unless it specifically knows about it.

The Basics

First a quick word...
Color Management is for Wimps -- Don't Play with them
Messing with profiles generally makes things worse
So if the colors look good... Leave it alone.

The user fhoech in IM Forums, has quite a number of times posted the following basic introduction in using color profiles to change the color space used by images.

RGB and CMYK are not colorspaces, they are color systems (which IM controls using the "-colorspace" operator). There is no single RGB or CMYK colorspace, but a literally infinite amount of different colorspaces are possible in each color system.

You need ICC (or ICM) profiles which accurately characterize the colors in your images. Normally, the ICC profile that describes an image should be embedded in the image itself, otherwise, you have to use a 'best guess' attempt which is only a workaround: Open the image in an ICC-capable image editor and assign different ICC profiles (do not convert!) until you find one that looks ok with your image (your monitor must be calibrated so you actually get a good preview of the colors). Then, save the image with the profile embedded.

As to why you need two profiles: The source profile describes the colors in your image as they are now. The destination profile describes the colors in the output image after conversion.

Also, you should take great care when converting to a given destination profile: If, for example, you use a profile that describes offset printing on uncoated stock but intend to use the images for printing on coated paper, you will of course not get any good results. The output profile needs to be an accurate representation of your intended output condition.

When converting from a subtractive into a additive color-space (or visa-versa) without using the correct profile (for both steps of conversion) you won't get 'correct' colors or brightness in most cases, although you may be lucky and hit the mark 'by accident'.

Changing Colorspace via Profiles

While you can just simple convert color spaces directly like this...

  convert cmyk_image.jpg -colorspace rgb rgb_image.jpg

The best solution for converting CMYK to RGB JPEG is to use color profiles with the "-profile" operator.

Raf Lenaerts pointed out the following rules in using the "-profile" operator within ImageMagick...
If there is no embedded profile then the first "-profile" is the input profile. A second "-profile" then defines the output profile.

If there is an embedded profile then a single of "-profile" operator will immediately define the output profile.

In summary...

As such to use profiles for ALL images, you will need three "-profile" options: remove, input, and output profile options.

For Example, If the input image already has a color profile then only one is needed.

  convert rgb_image.jpg -profile USCoat.icm cmyk_image.jpg

But if the image doesn't (or you know it is a RGB image, without a existing profile), you can use...

    convert rgb_image.jpg +profile icm \
            -profile sRGB.icc  -profile USCoat.icm cmyk_image.jpg

This sets the resulting image to a CMYK USCoat.icm profile. Another CMYK profile is the SWOP.icm profile.

For the reverse (image already has a profile) use...

    convert cmyk_image.jpg -profile sRGB.icc rgb_image.jpg


If the original image already contains a profile, for example a CMYK profile, then given two profile conversions is a bad idea.

For example

    convert cmyk_image.jpg -profile "CMYK.icc" -profile "RGB.icc" \

Will result in a CMYK -> CMYK -> RGB conversion. But as CMYK is not symmetric, the the extra conversion step can result in a disastrous color conversion. (See the IM Forum discussion Question on ICC profile conversion behaviour)

Color Profile Modification

The images you want to convert should all have ICC profiles embedded. As such to convert your images with same a CMYK ICC profile...

  convert rgb_image.jpg -profile CMYK_PROFILE cmyk_image.jpg

This will convert using perceptive intent, the default (see Color Space Conversion for an detailed explanation on rendering intents). Because the results via perceptive intent can differ greatly depending on the software that was used to create the ICC profiles, you can use "-black-point-compensation" along with "-intent relative" to get a result that is somewhat nearer to what one might expect:

  convert rgb_image.jpg  -intent relative -black-point-compensation \
          -profile CMYK_PROFILE     cmyk_image.jpg

The "-black-point-compensation" option was added to IM v6.2.7-0.

EXIF InterColorProfile

On top of the above Color Profile handling, many Digital Cameras, save color profile information in the EXIF profile attribute 'InterColorProfile'. This attribute is meant to be "assumed in the event of no colour profile being embedded", according to the document, "Colour Management and Adobe PhotoShop 7".

IPTC Profiles

The IPTC profile is used in images to store identification attributes of the image, such as caption, credit, author, keywords, etc.

If you want to add a IPTC profile to an image, you need a single -profile:

  convert image.jpg -profile iptc iptc_image.jpg

If an image contains a profile you can save it with this, so you can add that profile to other similar images:

  convert iptc_image.jpg iptcData.iptc

Or you can extract a text version of the profile that you can edit

    convert iptc_image.jpg

Here for example is a profile contributed by fcaserio in the IM Forums.
[IM Text]

You can add this profile to an image using

  convert image.jpg +profile 8BIM -profile \

That image can be converted into an EPS (Encapsulated Postscript) with a TIFF preview (EPT), that also contains the IPTC profile. (Thanks Tee Tanne).

  convert itpc_image.jpg  EPT:image.eps

XMP Profiles

Extract a XMP profile from a TIF image...

  convert picture.tif metadata.xmp

A word about Vector Image formats

Their is more than one style of image storage in the world...
Raster images which are stored and processed using arrays of colored pixels. Raster image formats include GIF, PNG, JPEG, TIFF, and so on. Images can consist of multiple arrays (channels) representing different colors, and can have multiple layers, or frames (depending on usage) in the one image file.

Vector images are defined in terms of lines, thicknesses, tiles, gradients, and objects. Formats include SVG, Postscript, PDF, FIG, DXF, WMF, and even TTF fonts. It allows images to be resized, and even greatly enlarged without loss of quality. Also while editing such formats, you may be able to move whole objects around without destroying what is underneath.

Fractal images are a special rare case, used to achieve extreme compression of complex images, such as old paintings. However the only usage is in a very expensive commercial product. Outside that usage it is also used for complex mathematical objects such as Mandelbrot and Julia sets, and in generating randomized splashes of color in screen savers (IFS). Other than those spacial cases is very rarely seen.

Why is this important? Because IM is a 'raster image processor', and while it can read or write images stored in one of the vector formats it does so by converting the image to and from a internal raster image.

Consequently if you are trying to convert a image from a vector format, to another vector format, IM will essentially rasterize this image at the currently defined resolution or density which will hopefully (but unlikely) be suitable for the output device you intend to use it on.

In other words, any output from IM will never be a true vector format. While it can convert its internal raster format into a vector format file, the result is only a superficial vector image wrapper around an image in raster format. And unless the raster image is defined properly (at the right resolution) for the output device, the result will not be particularly good.

Unfortunately new uses to IM do not know anything about this. They see IM as a converter that can convert say PDF to Postscript, producing images with 'blocky' aliasing effects, 'washed out' colors, or blurry images that just do not look good at all, on the intended output device.

Which brings use to what I am trying to say...

Avoid using ImageMagick for 'Vector Image' to 'Vector Image' conversions
EG: converting between formats like: PDF, PS, SVG

In other words, use the right tool for the right job. And for this situation, ImageMagick is not the right tool.

That is not to say IM can't be used to do such a conversion. After all most printers and monitors actually rasterize the image themselves for the actual printing onto a sheet of paper. The difference is that the printer knows what resolution it needs for the hardware it is using. ImageMagick does not.

For examples of converting vector images to rasters (and improving such conversions), see the example Postscript/PDF pre-formatted Text and Graphics Input, and for SVG and user generated vector images see SVG Image Handling.

You may also find the information on Font Size, Resolution and Pointsize useful, particularly with regard to the effect of "-density" on drawn text fonts.

Non-IM Alternatives

If you really do need to do general convention between vector formats, the program UniConvertor, Sk1 Project (usually available as a standard linux package) and the VectorSection can be used to convert vector-to-vector without actually rasterizing the images.

For general conversion of Postscript to other vector formats, look at "pstoedit", which is typically available in your systems extra package repositories. Also look at "epstopdf" which is part of the Comprehensive TeX Network (CTAN). TeX and LaTeX are UNIX documentation (book and scientific article) text processing system. It has lots of tools to do with Postscript and PDF formats.

For SVG to PDF conversion, Wolfgang Hugemann <> suggests that the easiest vector to vector conversion was to display the SVG in a browser (Firefox) and the print it using a PDF printer driver. Though the "Uniconvertor" could be used too.

Other Image File Formats

There are of course a huge number of other image file formats that IM can use and understand, however using many of these less 'common' formats are specialized for some specific purpose, and often require some tweaking or other options to get them to perform the way you want them to perform.

I do not recommend these file formats, and generally I myself don't used them. However I do try to log various notes, techniques, and options that have been reported on the IM mail list, or IM forum, so others may also use the information gleaned.

Many of the notes are in a raw, unprocessed form, and I am willing to accept further contributions, ore re-writes to the notes below.

Postscript (PS, EPS) and Adobe PDF

For basic handling see Postscript Text Handling and the warning about Vector Image formats.

The major problem with Postscript and its related formats (like PDF) is that it is a complex page formatting language. That is the format is a program and not really an image format! That means IM is forced to rely on another external program (or delegate) to 'run' the program and return the generated image.

Encapsulated Postscript (EPS)

Encapsulated Postscript is actually exactly the same as normal postscript (a vector image format) except it is a single page image, and a "Bounding Box' entry is present to define the exact area the image covers.

The format was designed to to allow other programs to move and scale the image when inserting the postscript it defines into other postscript documents.

IM handles it in basically the same way as postscript. (See above).

  convert image.jpg -compress none eps2:image.eps
Use "EPS2:" or "EPS3:" to create JPEG compressed EPS files: Note: Adding profiles to EPS images are on the 'to do' list but is currently not supported.

Postscript/PDF Input

As this format is a vector image format it is effected by settings such as "-page", and "-density". Examples of reading Postscript (which is the same for EPS and PDF format) are provided in Postscript Formatted Text, and you should read this first.

However the reading of these formats is very complicated, as they are full computer languages designed specifically to generate a printed page on high quality laser printers. This is well beyond the scope of ImageMagick, and so it relies on a specialized delegate program known as "ghostscript" to read, and convert Postscript and PDF pages to a raster image.

One point. As IM uses Ghostscript to rasterize a postscript file at a specific resolution, any raster images that are in the postscript file will often be blurred, or distorted, unless the exact density for that raster image is known. This also assumes that the postscript program itself does not rotate or otherwise manipulate the raster image.

In fact, multiple delegates are present and selected by IM depending on the situation. For example the 'ps:color' (using the 'bmpsep8' ghostscript device) verses 'ps:alpha' (using 'pngalpha') is selected depending on if "-colorspace RGBA" had been set or not.

The 'ps:color' delegate is used rather than 'ps:alpha' by default because the 'pngalpha' ghostscript device only supports a one page/one image and PDF's generally are multi-page. Use "-colorspace RGBA" before reading the image to select the 'pngalpha' delegate method.

Special PDF Reading options
Special options for PDF handling...
-units PixelsPerInch
Should be set when handling PDF documents (reading or creation of). I am not sure what this does but reports indicate it should be set for correct working.

-define pdf:use-cropbox=true
Use a 'cropbox rather than the default 'mediabox' as per Adobe generated PDF files. (Basically adds a "-dUseCropBox" to the ghostscript conversion from PDF images.

NOTE: This works if your PDF only has one page, but if it is a multiple paged PDF, it won't crop correctly.

-define pdf:use-trimbox=true
Use a 'trimbox rather than the default 'mediabox' as per Adobe generated PDF files.

Modifying the Input Delegate
Modifying the system delegate is dangerous and a mistake could render IM unable to read postscript/PDF files. You also may need administration privileges, as you cannot replace a system defined delegate with a personal delegate, due to security ('hacker') measures.

See Delegates and Coders for Image Formats for more info on the delegate XML syntax and meaning, and creating personal input/output delegates.

On the forum topic Convert EPS to JPG Unreliable, it was suggested that you edit your system "delegates.xml" and replace "-sDEVICE=bmpsep8" to "-sDEVICE=bmp16". Other users have found that changing this to "-sDEVICE=pnmraw", also works better. I have not tried this myself, so can provide no guarantees about this, or what versions of Ghostscript this applies to. If you have any further info, please let me know.

If you have a CMYK postscript or PDF file then the page Blog of John details how you can modify the delegate entry (Add a "-dUseCIEColor" ghostscript option) so ghostscript convert handles this this of postscript.

Postscript/PDF Output Alternatives
If you are more interested in the actual images that are contained within a PDF document you can have a look at the "pdfimages" program, which is part of either the "poppler-utils" or the "xpdf-utils" software packages. These software packages also contain many other tools that you can find useful for PDF processing.

Perhaps someone would like to write a delegate program for ImageMagick using these packages?

ASIDE: If you want the actual text rather than the images the program "pdftohtml" has an XML output that Ross Presser reports is "pretty good at reassembling paragraphs.". However you can also use the ghostscript program "ps2ascii" or "pstotext".

Also the "pdftk" program can 'uncompress' a PDF so it can be edited directly, and to 'repair' corrupt PDF's.

Postscript/PDF Output Options

The following settings are known to effect the output of Postscript, Encapsulated Postscript, and PDF image formats: "-page", "-gravity", "-compress", "-density",

By default no compression is used on PDF image output, so PDF files can often be a lot bigger than necessary. The following table equated the IM compression modes with the resulting Postscript compression mode used.

PS/PDF Compression Meanings
Compression image '/Filter [ ... ]' setting
"-compress none" '/ASCII85Decode'
"-compress zip" '/FlateDecode'
"-compress jpeg" '/DCTDecode'
"-compress lzw" '/LZWDecode'
"-alpha off -monochrome -compress fax '/CCITTFaxDecode'
"-compress rle"
    any thing else

Recommended compressions for PDF is Zip (Deflate Compression) or Group4 (Fax) compression.

  convert image.gif -alpha off -monochrome -compress Zip -quality 100 \
          -units PixelsPerInch -density 600  image_deflate.pdf

  convert image.gif -alpha off -monochrome -compress Group4 -quality 100 \
          -units PixelsPerInch -density 600  image_group4.pdf

These two commands produce must smaller PDF files than a direct conversion, of a black an white page. However which is smaller depends on the image and is impossible to determine without trying and testing the resulting size.

Postscript/PDF Output Alternatives

Remember that PDF is a vector image (document) format, and IM is a raster image processor. This means that any PDF document IM creates will basically consist of a single raster image per page.

The images output in the PDF document will be fixed at a specific resolution (or pixel density), which can cause pixel distortion issues when viewed or printed at some other resolution. Also for text documents, using a raster image is wasteful, as plain text with fonts and formatting meta-data will always be a lot smaller and render better than a scanned raster image of the text.

Because of this, other PDF creation programs may be better suited to your needs. This will let you keep images as images, and text and text, allowing you position the text and images together in a nicer more logical way, as well as insert text, and overlay arrows or connecting lines, in a more logical fashion.

For example I suggest you look at the support programs provided by the TeX and LaTeX system. See Comprehensive TeX Network (CTAN).

Another tool set is Multivalent Document Tools.

Of course such programs are harder to automate, however I have in the past use the simple FIG vector graphic file format (see Xfig) to generate Postscript and PDF documents with text and auto placed graphics in a automatic way.

Multi-paged PDFs...

You can use perl to combine multiple PDF files, without resorting to a IM, and its rasterization problem...
#  Script
use strict;
use warnings;
use PDF::Reuse;

prFile('combo.pdf'); # Output.
for (qw/a b c d/) # Inputs.

You can also use a JAVA toolkit to merge IM generated images into a PDF producing a better PDF than a simpler one that IM will generate...

for x in ./*.jpeg
    echo $x to ${x}.pdf
    convert $x -quality 75 ${x}.pdf

echo Merging...
java tool.pdf.Merge *.pdf

Another user on IM Discussion Forums also suggested using PDFjam to merge multiple PDF pages together.


The TIFF format is the propriety format for PhotoShop. However it is so bloated with features, and has been modified by just about every application that has cared to use it, that no program, not even photoshop can handle ALL its variations. Photoshop however has the best chance at reading it. I would steer clear of the TIFF image file format unless you are specifically working with photoshop, or the application accepts no other, better defined, image file format. I don't use the TIFF image file format, or Photoshop. If you use this format with IM extensively, perhaps you would like to submit your findings to me, to include here. That way you can help your fellow TIFF users. Typical conversion problem JPEG to TIFF... convert image.jpg image.tif Error: "JPEG compression support not configured" This message comes from the TIFF library when it has not been build with JPEG support enabled. As you just read in a JPEG image, IM sets the "-compression" setting to use the JPEG compression 'jpegcompression', rather than something your TIFF library can understand. You can get around this problem by changing the setting to use a different compression algorithm: convert image.jpg -compress zip image.tif convert image.jpg -compress lzw image.tif convert image.jpg +compress image.tif WARNING: -compress Group4 with a TIFF works, but ONLY if you remove all transparent and semi-transparent pixels from the image. Typically you can make sure this is done the same way as JPEG images above, using -background {color} -flatten just before the final save. Save a TIFF file format with only one row pre strip, use this option: -define tiff:rows-per-strip=1. To save more rows per stripe increase the number -define tiff:rows-per-strip=8 You can also specify the 'endian' ordering for binary integers in the format -endian MSB -endian LSB For smaller TIFF images (other than by compression, you can also try to use options and settings like -depth 8 to reduce the color quality or +matte to remove the alpha or transparency channel from the image. IM will save a greyscale image as a greyscale TIFF, if no non-grayscale colors are present. You can force it to save as non-greyscale with -depth 8 -type TrueColor As of IM 6.2.6-5... Single/double precision for read/write of raw TIFF and MIFF file formats... For single precision set... -depth 32 -define quantum:format=floating-point For double precision set... -depth 64 -define quantum:format=floating-point Or a more unusual 14 bit TIFF image... convert logo: -sharpen 0x1 -depth 14 logo.tif tiffinfo logo.tif Image Width: 640 Image Length: 480 Resolution: 72, 72 (unitless) Bits/Sample: 14 Compression Scheme: LZW Photometric Interpretation: RGB color FillOrder: msb-to-lsb Orientation: row 0 top, col 0 lhs Samples/Pixel: 3 Rows/Strip: 2 Planar Configuration: single image plane DocumentName: logo.tif Software: ImageMagick 6.2.8 07/27/06 Q16 IM also understand writing 12 bit TIFF files... To convert 16-bit TIFF images to 12-bit: convert image.tif -depth 12 image-12.tif Whether a specific software package can read a TIFF, all you can do is try it and see. That is the problem with this format. * Windows Picture and Fax Viewer, Windows Explorer These can can only display TIFFs that have certain Photometric Interpretation values, such as RGB. IM Options... -compress LZW -type TrueColor Added IM 6.3.2-10 toggle the photometric interpretation -define quantum:polarity=min-is-black -define quantum:polarity=min-is-white Multi-Page TIFF If you want to split a multi-page tiff into separate pages, IM may have problems as it will still use up a lot of memory to hold previous pages even if you use a command like... convert "a.tif[i]" b%03d.tif The better solution may be the non-IM "tiffsplit" program. Clip Paths. The TIFF format can have a bitmap mask in the form of a clip path. You can mask your image with that path using... convert image_clip.tif -clip image_masked.png The mask itself is in a SVG path specification, which you can extract separately using... identify -format '%[8BIM:1999,2998:#1]' image_clip.tif Extra TIFF image file format notes.... Photoshop ignores the image density specified in (at least) G4 compressed B&W TIFF files, and displays them instead with 50% less width. This is bizarre, as far as I am concerned, even though FAX machine typically have greater resolution vertically than horizontally, Photoshop should not _assume_ that a random TIFF file of that nature that it opens was incorrectly coded. -- Glenn Linderman, 8 Sep 2007 Photoshop saves an extra copy of the images resolution into a separate profile in TIFF and JPEG images, which IM will NOT touch. Thus if you change the resolution of an image with IM, you probably should also strip the profiles from the image before loading it back into photoshop. The resolution is in "tag id 1005 (RID_RESOLUTION).".

Specifically for JPEG: RID_RESOLUTION overwrites EXIF-Resolution overwrites JPEG-Resolution. While for TIFF: RID_RESOLUTION overwrites TIFF-Resolution -- Thomas.Freitag

NetPBM or PbmPlus: PBM PGM PPM PNM PAM These formats are part of the "NetPbm" or PbmPlus image manipulation filters (unix command line). These image formats (PBM, PGM, PPM, PNM) typically saves one image per file, however IM, and some NetPBM utilities will read and write files with multiple images. The PNM file format is actually especially important to ImageMagick as it is the communication format used during the conversion of Postscript and PDF images via the "ghostscript" delegate. You can select between the plain text (P1-3) and binary (P4-6) formats by using the -compress setting. For example --- a plain text PGM (P2) image compress pattern:fishscales -compress None plain.pgm Or a binary PGM (P5) image (use default compression) compress pattern:fishscales +compress binary.pgm You can control the quality (or max-value) for the output data using the "-depth" setting. However a finer control then a power-of-2 is currently not possible, though a future proposal has also been suggested. Multiple images are possible too, by simply concatenating single images together to form a multi-image file. I believe you can include optional white space (newline characters) and '#' comments between the images as well. However no formal description for this multi-image style is known to me. The NetPbm image processing suite is a long time rival of ImageMagick for command-line image processing, but uses a completely different (more low level) philosophy, for image handling and processing. This makes it more difficult to use outside of shell scripts. However both packages can co-exist, and I have been known to use a NetPBM implementation for some things, instead of ImageMagick. Often when using a specific low level image processing where NetPBM may have more specific options. For example NetPBM does have a "Floyd-Stienbreg Error Correction Dither" (in "pnmquant" and "pnmremap" commands), where IM currently only provides a "Hilbert Curve Error Correction Dither". However IM provides it automatically by default where NetPBM does not. BMP The Windows desktop icon image format BMP (short for bit-mapped) is a very unfriendly image format and should probably be avoided if possible. ImageMagick supports 8, 24, and 32-bit BMP images. Add -colors 256 to the end your command line (before the output image filename) to create a 8 bit colormapped BMP image rather than a 24 bit BMP format. Extra colors can be added to images after performing operations like rotates, and resize. See Color Quantization for more info on -color. The presence of any transparency controls whether it uses a 24 (RGB) or 32 bit (RGBA) format BMP image. You can use "+matte" to turn off transparency in an image. If all colors are gray-scale a 'directcolor' greyscale image is generated. I think -type truecolor will stop this behaviour. If you have an older program cannot read the default BMP4 images written by ImageMagick, (for example a Windows Background Image), you can enforce the generation of a BMP3 format image using... convert image BMP3:image.bmp This format should have no transparency and should be a 'printable image', whatever that means. In other words 'Windows' compatible. However, if a PNG input file was used and it contains a gAMA and cHRM chunk (gamma and chromaticity information) either of which forces "convert" to write a BMP4. To get a BMP3 you need to get rid of that information. One way may be to pipeline the image though a minimal 'image data only' image file format like PPM and then re-save as BMP3. Messy, but it should work. convert image.png ppm:- | convert - BMP3:image.bpm IM can not produce BMP's at depth levels other than 8. However you can use NetPBM image processing set to do the final conversion to other depth levels (This needs at least a Q16 version of IM)... convert image +matte -colors 16 ppm:- |\ pnmdepth 4 | ppm2bmp > image.bmp Format limitations.... The header for a BMP2: format only allows the description of the width, height and bit depth (bits per pixel) of an image. The bit depth can be one of 1, 4, 8 or 24. For comparison, the bmp3: format allows bit depths of 0, 1, 4, 8 ,16, 24 and 32 and has extra fields which specify x and y resolution (in pixels per metre) and compression of the image data.

RAW Camera Image Formats (CRW,CR2,NEF,X3F,etc.)

Most digital cameras, with the exception of the Sigma Foveon sensor and some Sony cameras, convert the image produced by the lens into digital data by using millions of sensors which detect the brightness of one specific colour, Red, Green or Blue. In order for the camera to respond to colour in approximately the same way that the human eye does, there are twice as many green sensors as there are of red or blue because our eye is much more sensitive to green light. The sensors are arranged in what is called a Bayer array. For a description and diagrams of this arrangement see, for example, Understanding Digital Camera Sensors.

The conversion of the data from a Bayer array into the more familiar RGB pixels requires a process called demosaicing. Once this operation has been done we still do not have an image worth displaying. Even with the extra green pixels, the camera's sensor still does not perceive colour the way we do. If you take a piece of white paper and look at it in bright sunlight and then go indoors and look at it under a fluorescent light, it will look white under both conditions. But if you photograph the sheet of paper under those same conditions using default camera settings, the paper will show slightly different colours when displayed on a screen. The reason is that although the back of our retinas will "see" the same light reflected off the paper as does the camera, our brain will interpret that light for us and we will perceive the paper as white. The camera simply measures the amount of red, green and blue light reflecting off the paper and under a fluorescent light there will be more blue light than there is under sunlight so the paper in that image will look bluer than the one taken in sunlight. To produce images which both show a white sheet of paper requires that they be "white balanced", also referred to as gray balanced or colour balanced. For more about white balancing see Understanding White Balance

There are still other aspects of the raw file which must be done, such as setting a correct gamma, but without going into further detail it is clear that the raw file needs a lot of processing before it can become an image that we can view on a monitor.

Camera raw files are often referred to as digital negatives. If you take a photo and have the camera generate a JPG image, it will have done the demosaicing and all the other adjustments. But if, for example, you forgot to set the correct white balance in the camera before taking the photo, you can't really do much with the JPG to correct the situation because so much information about the original image has been lost. If, on the other hand, you had produced a raw file from the camera instead of a JPG, during the conversion from raw you can choose a particular white balance setting along with other parameters and if the resulting image doesn't look right you can go back, change the settings and convert it again until it does look right. This is similar to the ability to produce more prints from film negatives. Without the film negative you wouldn't be able to get an 8x10 blowup of one of the 4x6 snapshots you get when the film was first developed.

While ImageMagick can handle a large variety of different formats, it does not 'know' how to convert raw camera files, so IM uses the "dcraw" program as a delegate program to convert the raw file into a format that it does understand, either a TIFF (with the '-T' flag) or PNM. Note that it is designed for raw camera images, and not those from, for example, a scanner. The "dcraw" program can handle a large number of different raw formats including those from cameras manufactured by Canon, Fuji, Kodak, Nikon and Sony.

You can determine whether "dcraw" will recognize your raw files by asking it to identify a sample. For example the command:

  dcraw -i CRW_9641.CRW
Which returns...
CRW_9641.CRW is a Canon EOS 10D image.
When IM calls dcraw to do a conversion, using the delegate command lookup files, it specifies two flags which affect image processing:

  dcraw -w -4 -O output_file input_file

The '-w' flag means that dcraw will use the white balance information in the raw file if it can be found. If the info can't be found, dcraw will use an average of the whole image as a basis for white balancing.

The '-4' flag means that dcraw will only de-mosaic and white balance the raw photo and output the result as a 16-bit linear image (48 bits per pixel), suitable for the default Q16 version of IM.

Because '-w' and '-4' are the only two image processing flags specified, there are some defaults that dcraw will use. The output colour space will be sRGB and no ICC profiling is done (on my system, dcraw was compiled without the LCMS library so it can't do profiling).

The fact that the '-4' flag is set means that many processing steps have been omitted, including levels adjustment and gamma correction, and so the resulting image will look dark. The intention is that the user is going to process the image with an image editor such as "Photoshop" or "Paint Shop Pro" or even "ImageMagick" and do their own adjustment of the levels, gamma and so on. In this case, the image should be output to a format that supports 16 bits per colour. (For example TIFF).

Note that just because dcraw produces a 16-bit file doesn't mean that all 16 bits contain useful data. For example, a raw image from a Canon 10D digital SLR has 10 bits per colour. More recent cameras by Canon and other manufacturers have 14 bits per colour.

If you want your raw photos converted completely you will have to remove the '-4' flag so that dcraw does the de-mosaicing, white balance, brightness and gamma correction and so on. In this case dcraw outputs an 8-bit file (24 bits per pixel). If you are going to do further processing of this image it would be best to output it as a PNG and avoid the JPEG compression artifacts. The JPEG format should only be used as a final step for actual use. In fact, it is always a good idea to use a lossless format such as PNG (or IM internal format MIFF) for intermediate steps in image processing.

A special DCRaw Delegate can be added which will let you control how you read the 'raw' camera image formats.

For further information look on the DCRaw WebSite, and also the DCRaw Tutorial Website which has some information about many of dcraw's optional flags and including histograms of raw images using various flags.

The above notes were first extracted from a IM Forum Topic Converting RAW images, by jhfry, with major re-writes by by el_supremo.

MPEG, M2V and AVI Movies

  IM is not very efficient at creating movies.  It will do the job though
  requires the external program "mpeg2encode" to do much of the dirty work.

  The problem is that IM is not designed to handle video, but static images or
  small sequences of images.  That is not to say it can't do it, but that is
  not its goal.  In particular it generally reads in all images into memory
  and process them from there.  For a large or long video this is not very

  For processing on a small sequence of frames however it really can't be
  beat.  In fact just about every Linux Video manipulation program uses
  ImageMagick to generate titles, fancy scene changes, and other effects to
  complete the post-processing development of a larger video development.  The
  process however is kept to small video sequences.

  However lets have a look at what IM can do.

  Frames to Video

  There are some reports that unless the images are the right aspect ratio is
  correct this will fail on older mpeg players,  use the MPEG II extension
  (m2v:) instead.

  Also use m2v to avoid heavy compression pixelization that can occur

      convert *.jpg glacier.mpg

  EG instead use...

      convert *.jpg m2v:glacier.mpg

  Note you may need lots of temporary space to do a large animations
  You can specify a different directory from the normal /tmp using...

      setenv MAGICK_TMPDIR /data
      convert -limit memory 0 -limit map 0 *.jpg image.m2v


  To converting PNG images to MPEG2 Video streams, instead of MNG Multi
  PNG-files, use the following delegation...

       png2yuv -j file%08d.png -I p -f 25 -b 1 | \
         mpeg2enc -f 3 -q 3 -b 5000 -o out.m2v

  For more info see

  IM forums reported decent results with a open source project called
  "ffmpeg", which seems to be a fairly standard linux package install.

     ffmpeg -f image2 -vcodec mjpeg -y -i %d.jpg anim.mpg

  Extracting an MVG with a transparent background
      convert -background none -size 320x240 sample.mvg out.png

  Michael Lenh wrote...
  I finally was able to create a very sexy video using mplayer

    mencoder "mf://data/p*.png" -mf fps=40 -o particle.avi -ovc lavc

  You can see the results at...

  Dean S. Messing uses transcode...

     find . -type f -name '*.png' | sort > filelist
     transcode -x imlist,null\
            -y raw,null\
            -f 60\
            -i filelist\
            -g 4096x2160 \
            -j 540,1024,540,1024\
            -o video.avi\
            -H 0

   You can leave out -j  (clip window) if you want. -g is output size.

   Wolfgang Hugemann suggests a new alternative known as 'VirtualDub' under
   Windows Vista, which will let you run a video, or convert directly from
   a folder of image frames.

   Video to Frames

   Both "mplayer" and "mencode" are more efficient at converting video into a
   series of frames than IM is.  On top of this is can handle just about any
   video (and audio) codec available.

   For example to grab 5 frames from 1 1/2 minutes into a video, scaled to
   320x240, you can use...

      mplayer -vf scale=320x240 -ss 01:30 -ao null \
              -vo png:z=3 -frames 5

   Other alternatives include the "ffmpeg" open source library, though that is
   also part of the "mplayer" handling.

DPX, Digital Picture Exchange Format

This format is used in Motion Picture and Effects industry that makes particular use of the extensive header information and the format's flexibility in being able to handle high dynamic range and logarithmic colour values at a variety of bit depths using RGB or YCbCr pixel descriptions. It is based on, but largely supersedes, Kodak's Cineon format that has more a more film specific header.

One example of it's use would be when scanning film for use in post production. Each frame would be stored as an individual .dpx file ranging from 2k (2048 pixels wide) to 8k (8192 pixels wide - for IMAX frames) at anything between 8 to 64 bits per colour component. A sequence of these might then be processed using compositing software, altering the colour or adding visual effects. Once complete they might then be recorded digitally to tape or projected back on to film.

The colour values for each pixel are often stored logarithmically (particularly if the sequence is destined to be transferred back on to film) which more naturally reflects the density of how colour information is stored in the emulsion on the original film. When viewed without alteration logarithmic files appear to have very low contrast, and so require a 'look up table' to translate the logarithmic image to something that resembles what you might see if the image was transferred back to film and projected in a cinema. Apart from making the image linear (like most typical computer images) and adjusting the gamma level this table sets where the black and white point lies.

For a 10 bit logarithmic image where each colour component value ranges from 0 to 1023 the black and white points are normally set at 95 for black and 685 for white. What this means is that the logarithmic file stores colour values that are lighter than what the linear version will display as pure white and darker than what it will display as pure black. This extra information therefore remains available for an effects artists who might wish to alter the brightness of the image after it has been stored as a dpx file.

As an example, had this information been lost, reducing the brightness of an image uniformly would result in highlights becoming darker, whereas with this extra information the highlights instead reduce in size and start showing details that were previously too bright to be seen. The latter is far closer to what happens in the real world.

The header can contain Film and/or Television specific data related to a production. For example the television header can contain a SMPTE time code so that shots exported as a dpx sequence from a production's edit can be easily replaced once any effects have been added. The film header holds information about the reel of film the frames originated from and various camera settings that were used while filming. All these details will then stay with the images as they are passed between post-production companies.

Adding a time code to DPX files

You can add a time code to any dpx file using the following:

  convert -define dpx:television.time.code=10000215 \
          originalFile.00001.dpx    alteredFile.00001.dpx

Carrying out this command for each of several thousand files that form a sequence from a film or animation would clearly take a very long time. A simple script can be used with ImageMagick to automatically increment the time code for each frame in a sequence.

For example see the Perl Script

A copy of the above was added to the main IM documentation at Introduction to Motion Picture Formats.

The above is courtesy of Seth Dubieniec <>, from a long IM Forum Discussion on the DPX Format. He is currently developing DPX applications, so more DPX info is likely to be coming.

Extra Notes (unformatted)...

Adding  -depth 10  causes IM to output a  10 bit DPX file.
-- James Fancher

If you want to set the gamma, for example, in the output DPX image...
     -define dpx:television.gamma=1.7

The colorspace of the DPX image is defined by the image element descriptor and
transfer-characteristic. If the transfer characteristic is
PrintingDensityColorimetric we set the colorspace to LogColorspace. Only if
the colorspace is Log do we apply the gamma and black/white points to convert
to the RGB colorspace. Its possible the program you are using is not
conforming to the SMPTE standard or ImageMagick is not interpreting the
standard correctly. Post a URL to your two DPX images and we will download and
try to determine if ImageMagick has a bug or if the program you are using is

The following will work with ImageMagick 6.3.8-3

  convert -colorspace log AfterEffectsFile.dpx -set gamma 0.5 \
          -set reference-black 95 -set reference-white 685 image.jpg

Alternatively, take a look at the SMTPE documentation
-- Cristy


A PSD image file is the Photoshop Working image file format, just as XCF is the GIMP working file format, and MIFF is ImageMagick's own working file format.

They usually contain multi-images, with first image being a all-in-one merger of the current working image. That makes it useful for seeing the working image as it currently stands and is typically used for 'thumbnailing'.

All the other images in the multi-image file format are the images that are used to generate that first combined image. That is the individual working layer images, the user was working on at the time it was saved.

So if you just want the 'final' image I suggest you append a " '[0]' " to the input filename to junk the working images, and just use the all-in-one first image.

However if you plan to work with the individual layer images then use " '[1--1]' " to skip the first image. If no extra layer images are found than the first image will be returned instead. I do NOT recommend using "-delete 0" as that will return no images at all if no layer images follow that first image.

Extra notes... If you can provide more information or like to submit a summary of using IM for this format, then please do...

   For PSD with a CMYK image you may need to get IM to use the
   right provide when converting (make sure you IM was installed with the LCMS
   delegate library) ....

     convert Test_CMYK.psd -strip -profile USWebCoatedSWOP.icc \
             -profile sRGB.icc Test_RGB.png

   See Profiles above for more info.

   If a PSD image contain a 'preview' image.  This image is returned as the
   last image of a two image read.

   To ensure IM never reads the last image use...
       convert test.psd[0--2] -flatten test.jpg
   That is read all images, except the last. But always read the first.
   This can not be done after the read using a "-delete".


Another vector format often used for scalable clipart used by the Microsoft Office set of programs. The input can be scaled changing the "-density" before reading the image.

See also Vector Image Formats.

Flash Animations (SWF)

Flash animations are currently not supported by IM.

But just for completeness Scott Bicknell reports that the SWF Tool utility "swfextract" It can extract jpeg or png frames from a flash animation.

Wolfgang Hugemann also thinks the Windows freeware tool "IrfanView" may be able to do this as well.

Sounds like a good delegate candidate to me.

Webpage Conversion to Image (HTML)

If IM loads a HTML it will look for a html2ps to convert the html to postscript which it can then render as an image. This does not work very well, but does work.

Using a full web browser is a much better method as it is designed to do the task in the best possible way. The simplest method to use a browser is to just load the page in a browser and then take a screen shot of it. This gets a perfect image of the page but limited to the window size of the browser.

Another variation is to have the browser output the page as postscript rather than have IM convert it. This should page the website into smaller pages quite nicely.

Under LINUX you can to start a virtual X windows Display server that is large enough to run a browser that shows the whole web site. This can be a VERY tall display. The browser is then run in it and set to fill the entire display. The web site is loaded and again grabs a screen shot. I have seen a script that can even automate that whole complex process. However you can end up with a VERY long image. It is also difficult to know just how big to make the display.

Basically it is NOT easy and the best solutions only use IM for the final image processing, not the html to image generation.

PCL Printing Format

IM PCL is version 6 PCL by default.

For version 5 you need to convert your image to black and white.

For example...

  convert image.png -monochrome image.pcl

Raw RGB Output

Image generated using Code...

   float red = 1.0f;
   fwrite (&red, sizeof(float), 1, file);
for each of red green and blue

Reading Options....

   -size 200x100
   -depth 32
   -define quantum:format=floating-point
   -define quantum:scale=65536.0
   -endian lsb

Created: 9 December 2003
Updated: 3 September 2008
Author: Anthony Thyssen, <>
Examples Generated with: [version image]