[Magick-bugs] Various bugs and complaints

Mario Rosso mario.rosso at shiftmail.com
Tue Jul 7 03:15:36 PDT 2009


Hello imagemagick team & users,

(imagemagick version = 6.4.5 from ubuntu jaunty)

I am mad at imagemagick because I just spent at least 3 hours trying for 
the N-th time in my life to understand how imagemagick works, and I 
failed. This app just feels brain damaged or buggy as hell!

Firstly my complaint is on the manual, and then I have an working (or 
nonworking) example for you.

The manual is almost impossible to understand because 1) it never 
defines the terms it is using and 2) the description for many options is 
simply too short to understand what they do.
   Read -resize: 
http://www.imagemagick.org/script/command-line-options.php#resize
this option would have required no explanation at all once the meaning 
of "size" was known. The problem is that the meaning of size is the only 
thing you won't find in the manual. Is it the size in millimeters, the 
size in inches, the size in pixels...??
   Read -resample: 
http://www.imagemagick.org/script/command-line-options.php#resample
I admit this entry was almost clear, except that imagemagick doesn't 
work like that. If it worked as the manual says, rendering on the *same* 
device using "-resample 200" i should obtain a larger rendered image (in 
millimeters) (because there are more pixels on the same device) than 
with "-resample 100", or at least equal size (in case you carry on 
density information), while in fact 200 results in a *smaller* image 
than 100. If you want to try, take my example below here, remove the 
-density and -resize options, add a -resample and see.
   Read -extent: 
http://www.imagemagick.org/script/command-line-options.php#extent
Oh ok, so what is the difference to resize?
   Read -geometry: 
http://www.imagemagick.org/script/command-line-options.php#geometry
Oh great! now we have ANOTHER option that specifies the size. Now what 
is the difference to "-extent" and "-resize"?
   Read -page: 
http://www.imagemagick.org/script/command-line-options.php#page
In what the h*ll of measurement unit are the width and height that are 
specified in this table? I had to google for various minutes to 
understand that you implicitly intend the width/height size of the page 
in pixels, but with an implicit dpi of 72! How is the user supposed to 
figure this out!?!?

Apart from these problems, the manual really needs a section where the 
terms are defined. After reading the manual for a lot of time ('cause I 
already had tried hard in the past) it seems to me that you use the 
following definitions:
   size = size in pixels
   dimensions = same as size
   resolution = resolution in dpi
   rendered size = size in millimeters/inches
well then... *please write it*! For most of us "resolution" means 
pixel-size and "size" means size in millimeters, and what you call 
"resolution" we call it "dpi", so the manual becomes almost undecipherable.

And now it's example time.
I have a few photographs made by a Canon SX100 in one directory (Linux). 
The photograps are jpg, 3264x2448 pixels and at 180dpi.
I wanted to rotate them 90 deg, resize them to 50% pixels, fit them to 
A4 pages and put them into a PDF.

After hours of trial and errors (the manual has been pratically useless 
if not misleading), this is the command that turned out to do what I 
wanted:

   convert IMG_156[123].JPG -density 72 -resize 50% -rotate 90 -adjoin 
-compress jpeg -quality 90 -page A4 june.pdf

Now... why does it work? It is very unclear.

Firstly, the -density option: if you have an image with horizontal size 
2448 pixels and density 180 and you re-set it to density 72, the size 
should enlarge, ok, but not of the correct amount to fit onto an A4 
page: 2448/180*72=979.2 pixels while A4 has a width of 595 pixels at 
72dpi so it should come out too large and be cropped, while 72 is 
*exactly* the DPI that fits the image to the A4 page for me. Please note 
that I am positive that the density of 180 is read by convert because 
writing "-density 180" produces the same rendered size as skipping the 
option. (To check the rendered size reliably open the pdf with 
KGhostView or do a print preview from KPDF because the standard view of 
kpdf is too good to you and tries to enlarge images to fit the page, but 
then when you print it it's not what you get)

Now the -resize option: it does not appear to alter the rendered size 
(in millimeters)... did you guess that from the manual? No, huh? Well 
ok, good to know, so I guess it must work by adapting the density in a 
manner inversely proportional to the resize factor. Well, NO! Actually 
it doesn't do that, because if it did do that, moving the -density 
option to after the -resize option would result in a dramatically 
different output, while if you try by yourself you will see that moving 
the density option anywhere on the command line does not alter the output.

Extent option: I have tried to put "-extent 595x842" towards the end of 
the command line, with -density 72 placed just before it, thinking that 
it should have been perfect for setting the rendered size of the image 
exactly to fit the A4 page (except the pixelsize of the image being 
maybe too low for my purposes), but it did not work. The image becomes 
too big and it is cropped on the boundaries of the A4 page. Why is that?

And then I feel there is real need for one more option in convert: a 
"-rendersize <size_in_mm/inches>" which acts on the density value only, 
and sets it so that the rendered size of the image turns out to be what 
you specified. So this is a feature request.

Thanks for your time. I know it's a free app and I can have my money back.

Mario Rosso


More information about the Magick-bugs mailing list