- Index
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...
- 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, 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.
- 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 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.
- 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
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]](hand_point.gif)
|
|
|
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]](hand_white.gif)
|
|
|
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]](hand_flatten.gif)
|
|
|
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]](hand_wheat.gif)
|
|
|
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]](circle.png)
![[IM Output]](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
|
|
![[IM Output]](circle.gif)
![[IM Output]](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 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]](circle_threshold.gif)
![[IM Output]](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
| |
![[IM Output]](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
| |
![[IM Output]](a.gif)
![[IM Output]](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
|
|
![[IM Output]](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
|
|
![[IM Output]](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.
convert bg.gif -scale 1x1\! -depth 8 txt:-
|
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' may
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.
![[IM Output]](a_bg_final.gif)
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]](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").
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]](a_ordered_2x2.gif)
![[IM Output]](a_ordered_3x3.gif)
![[IM Output]](a_ordered_4x4.gif)
![[IM Output]](a_halftone_2.gif)
![[IM Output]](a_halftone_4.gif)
![[IM Output]](a_halftone_6.gif)
![[IM Output]](a_halftone_8.gif)
![[IM Output]](a_random_5x95.gif)
![[IM Output]](a_random_5x60.gif)
![[IM Output]](a_random_50x95.gif)
![[IM Output]](a_random_45x55.gif)
![[IM Output]](a_random_50x50.gif)
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]](jpg_lossy.gif)
![[IM Output]](jpg_lossy.jpg)
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]](jpg_lossy_100.jpg)
![[IM Output]](jpg_lossy_80.jpg)
![[IM Output]](jpg_lossy_50.jpg)
![[IM Output]](jpg_lossy_20.jpg)
![[IM Output]](jpg_lossy_5.jpg)
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 }'
|
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.
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]](a_flatten.jpg)
![[IM Output]](a_border.jpg)
![[IM Output]](a_frame.jpg)
![[IM Output]](a_undertile.jpg)
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:
| |
|
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. 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" -
| |
|
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 '*'
- -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 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 <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, 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"
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 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.
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 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
|
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...
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 <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 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]](test.jpg)
|
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]](test_silver.png)
|
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]](test_silver.jpg)
|
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]](png_offset_flattened.jpg)
|
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]](png_size_flattened.jpg)
|
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...
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...
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
|
WARNING:
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" \
output_image.jpg
|
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
|
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 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 (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 <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. 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"
"-compress rle"
any thing else
| '/RunLengthDecode'
|
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...
#!/usr/bin/perl
# Script pdf-combiner.pl
use strict;
use warnings;
use PDF::Reuse;
prFile('combo.pdf'); # Output.
for (qw/a b c d/) # Inputs.
{
prImage("result_$_.pdf");
prPage();
}
prEnd();
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...
#!/bin/bash
for x in ./*.jpeg
do
echo $x to ${x}.pdf
convert $x -quality 75 ${x}.pdf
done
echo Merging...
java tool.pdf.Merge *.pdf
Another user on IM Discussion Forums
also suggested using PDFjam
to merge multiple PDF pages together.
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 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 http://www.imagemagick.org
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:
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
efficient.
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
using...
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
Alternatives...
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 mjpeg.sf.net
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...
http://www.mathematik.uni-ulm.de/~lehn/particle.avi
http://www.mathematik.uni-ulm.de/~lehn/temperature.avi
Dean S. Messing uses transcode...
find . -type f -name '*.png' | sort > filelist
transcode -x imlist,null\
--use_rgb\
-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 file.mov -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 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 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
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
PSD
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".
WMF
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
input.rgb
![[IM Output]](hand_point.txt.gif)
![[IM Output]](hand_white.txt.gif)
![[IM Output]](hand_flatten.txt.gif)
![[IM Output]](hand_wheat.txt.gif)
![[IM Text]](bg_color_avg.txt.gif)
![[IM Output]](a_bg.gif)
![[IM Output]](a_bg_trans.gif)
![[IM Output]](a_bg_overfuzz.gif)
![[IM Output]](a_bg_none.gif)
![[IM Output]](a_bg_trans_2.gif)
![[IM Text]](jpg_ls_lossy.txt.gif)
![[IM Output]](a.jpg)
![[IM Text]](jpg_colors_none.txt.gif)
![[IM Text]](jpg_colors_def.txt.gif)
![[IM Text]](jpg_colors_100.txt.gif)
![[IM Text]](jpg_colors_lless.txt.gif)
![[IM Text]](jp2_colors_lless.txt.gif)
![[IM Text]](jp2_colors_50.txt.gif)
![[IM Text]](iptcData.pro.gif)
![[version image]](version.gif)
