ImageMagick v6 Examples --
Common Image Formats

Index

ImageMagick Examples Preface and Index

A Brief Summary of Common Image File Formats

GIF Image File Format

• GIF Limited Color Table
• GIF Transparency Color
• GIF Boolean Transparency
• GIFs on a solid color background
• GIFs on a background pattern
• GIFs for non-specific backgrounds (transparency dithering)
• Non-ImageMagick GIF Processing

JPEG Image File Format

• JPEG compression
• JPEG transparency - NOT
• JPEG Color Distortion
• Reading JPEG images
• Writing JPEG images
• Non-ImageMagick JPEG Processing (A quick summery)
• Lossless JPEG Processing

PNG Image File Format

• PNG compression
• PNG, Web Browsers and Transparency
• PNGs with Virtual Canvas Offsets
• PNG Output Formats
• Non-ImageMagick PNG Processing

Image Profiles

• Changing Colorspace of an Image -- RGB <=> CMYK conversion
• IPTC Profiles

A Word about Vector Image Formats

DPX, Digital Picture Exchange Format

Other Image File Formats

TIFF,  NetPBM,  BMP,  MPEG, M2V and AVI,  Postscript (PS),  Encapulated PS (EPS),  PDF,  PSD,  WMF,  MacroMedia Flash (SWF) Webpage HTML Conversion

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

GIF

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, but it only understands boolean (on/off) transparency, consequently suffers from 'aliasing' or 'jaggies'. Thin plain text especially suffers when saved to a transparent GIF image. The only solution to this problem is to tie the GIF image to a specific background of the web page it is used on.

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

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

JPEG

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.

PNG

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 informations about images (which GIF does) but does save image offsets, and even negative offsets, though some browsers have problems when a negative offset is used.

MNG

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.

TIFF

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 warped and stretched, with a haphazard array of features and compression styles that no programs understands all of them.

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

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 older 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". 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 colors 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'

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'

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'

If you like to change the transparent color 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'

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 is 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 is '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

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

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 can not. The GIF image format can only save a single pure transparent color. In other words...

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

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

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

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

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

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.

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

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

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

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

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

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' my work better.

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

• Lets extract the underlay color to use, directly from the background image.
• Then use a 'gamma level' adjustment to lighten the background color slightly. This gives us a simple single control for adjustments.
• As we can't set the background color setting from an image we need to make a canvas from this color and 'underlay' it using Dst_Over.
• And 'fuzz' out the shape of the image.

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

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.

This is not a perfect solution (see the image to the right, displayed on this pages 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. Something that makes recycling image you find on the WWW a real problem. Specifically re-adding background transparency or the images mask, on a opaque image. 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

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

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 simular 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 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, whos 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 as well.
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 whos '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 a the image was a GIF animation, it was split up into separate images using +adjoin, using 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 "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 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... If you are interesting in lossless handling, see Non-IM JPEG Handling.

Normally this lossy nature of JPEG 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 ot 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.

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.

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

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 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 you special format 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 mjor problem that JPEG users faces is that

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. 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. 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 builtin "netscape:" image...

identify -format "Colors: %k" netscape:

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

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

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

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

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.

However using a lower quality with JP2 will again introduce the color distortions as well and a smaller image, just like the normal JPEG image file format does...

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

Reading JPEG Images

-size {width}x{height}

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 '*'

-strip

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 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, and 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. (See above for a method of testing for lossless compression with your installed jpeg library).

Also you MUST have 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 JPEG2000) 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.

  Example wanted

-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 EXIF header, also stored in the image.

Density is used strictly used for output devices (such as printers), which also includes monitors, allowing these devices and display the image scaled to real world sizes. For example ensuring the photo or page you scanned is displayed at the right size.

-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 which only contains 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 <glennrp@comcast.net> 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) 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. 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"

error.

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 summery)

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 simular programs such as "ExifTool", and "Exifer". Many JPEG to web photo-ablum 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 command 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.

Comments...

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

Thumbnails...

Brian Jackson <brian@brianjacksonphoto.com> 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...

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

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 <imagemagick07_AT_sfina.com> 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 preform this task for you. though 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 is 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.

My preference 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.

PNGs with Virtual Canvas Offsets

This format while allowing an image offset on a canvas, does NOT record the canvas size for that offset. 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 a different page or canvas size and offset, to the value stored in the image file format. (See Page Image Attribute).

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

NOTE: Before IM v6.1.7, when reading image the canvas size was just set to the actual image size, ignoring the PNG supplied offset. As such using "-flatten" with such an image (such as in the example above) would result in the PNG image being offset on a canvas that was too small to hold the image with that offset. That is the bottom and right edges of the image would be 'lost' as they fell outside the canvas. From IM v6.1.7, the canvas is now set to the page canvas of the image (if no -page setting is defined) so that if flattened no part of the image is lost.

PNG can save images that have a negative offset (unlike the GIF format), and IM will handle these appropriately, making the format good for storing intermediate Affine Transformations of the image.

Some browsers do not handle negative offsets very well, producing odd results. 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 fullly transparent color, IM assumes that it doesn't. This provides a way to force files to still be readable by Internet Explorer v6. Also "Photoshop CS" also still handles it.

Under Construction

If you are just wanting to limit the color channels to 8bit, you can
use a -depth 8 output setting.  IM will then automatically use a "png24:"
format.

If when reading an image you force IM to create a image color index table
(or palette) then IM will save that image using a "png8:" format...

    convert input.jpg  -type Palette  output.png

To force the use of an single 8bit greyscale channel use

    convert input.jpg  -type Scale  output.png
or  convert input.jpg  -type Grayscale  output.png

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

    convert input.jpg  -type GrayscaleMatte  output.png

And for a simple two color image...

    convert input.jpg  -type BiLevel  output.png

NOTE: -type is a input and ouput image 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	Trys 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 pattle 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
8BIM	Photoshop Meta-data profile. Including data on: Clip Paths... What else?
XMP	Adobe's Extensible Metadata Platform (XMP) (See adobe page)

How can you extract a specific profile, or part of a profile? As of IM v6.3.4, you can insert a arbatrary 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, and can decode the data added.

The Basics

First a quick word...

Color Management is for Wimps
Color management is for experts.
Messing with it generally makes things worse

So if the colors are right... 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 Summery...

• The "-profile" must be placed between the input and output file.
  This is actually standard IM Command Line Processing Practice.
• Use "+profile" with 'icm' to remove any icc-profile present.
• The first "-profile" then given, is the input profile.
• The second "-profile" given, is the output profile.

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.

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

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

While most operators within IM work correctly for images with CMYK and CMYKA color channels, some do not. This is being fixed as they are found. For example, blur now handles these type of images correctly, and at the time of writing (IM v6.3.3), rotates are also being updated. Report any CMYK operational failures to the IM Bugs Forum. Typically it is the black channel that breaks during some image processing operation.

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 ment 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 IPTCTEXT:iptcData.pro

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

You can add this profile to an image using

convert image.jpg +profile 8BIM -profile 8BIMTEXT:iptcData.pro \ iptc_image.jpg

That image can be converted into an EPS (Encapulated 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 otherwords. 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-formated Text and Graphics Input, and for SVG and user generated vector images see Drawing Images.

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

Non-IM Alternatives

If you really do need to do general convention between vector formats, the program VectorSection has been designed for this type of image processing, without actually rasterizing the images. That is is preserves the 'vector' formatting on the image during the conversion.

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 <Auto@hugemann.de> 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.

---

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 dpx_timecode.pl.

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 <seth.info_AT_dubieniec.co.uk>, from a long IM Forum Discussion on the DPX Format. he is currently developing DPX applications, so more DPX info is likely to be comming. Stay Tuned - 23 April 2007

Extra Notes...

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

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

---

Other Image File Formats

Under Construction

TIFF

  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 be