Legacy ImageMagick Discussions Archive

Hi,
I am trying test ImageMagick batch tool I investigated IrfanView for our heavy traffic site.
All I want to use is the convert.exe to batch process 1-100 files in various user upload folders.

I am confused by seeing 7 possible binary installations of the batch tool for WINDOWS.

ImageMagick-6.7.1-0-Q16-windows-dll.exe - Win32 dynamic at 16 bits-per-pixel
ImageMagick-6.7.1-0-Q16-windows-static.exe - Win32 static at 16 bits-per-pixel
ImageMagick-6.7.1-0-Q8-windows-dll.exe - Win32 dynamic at 8 bits-per-pixel
ImageMagick-6.7.1-0-Q8-windows-static.exe - Win32 static at 8 bits-per-pixel
ImageMagick-6.7.1-0-Q16-windows-x64-dll.exe - Win64 dynamic at 16 bits-per-pixel
ImageMagick-6.7.1-0-Q16-windows-x64-static.exe - Win64 static at 16 bits-per-pixel
ImageMagick-6.7.1-Q16-windows.zip - Portable Win32 static at 16 bits-per-pixe

I want to test batch processing on my win 7 laptop + deploy the solution to run on win server 2008

Q1) Will I go for dynamic or static binaries and what are the differences?
Q2) Will I go for 64 bit or 32 bit?
Q3) How about 8bit vs 16bit? I know the memory req is an issue. What else?

Could anyone please suggest me which one should I install?
Also what steps are required so that I can install and run the convert.exe from shell?

Thanks for helping

static/dynamic how are extra libraries used. Are they built into the 'huge static binary' or are they separatealy installed packages/files. Are the image coders loaded as needed, or also part of the huge binary?

32 or 64bit 64 bit means larger integers. It should match the libraries used on your machine. You can not call a 64bit library from a 32bit binary or vias versa, as the integer arguments of the functional calls do not match (segmentation fault)!
So that depends on the machine you use! 64bit is typically faster due to speed of data transfer, or when dealing with large ineteger numbers.

Q8 or Q16 Q8 has a smaller memory foot print, as image values are saved in memory as 8 bit values, just like most image file formats. For basic composition, image format conversion, simple 'once off resize', or drawing on images, then Q8 is 'good enough'.

Q16 double the memory foot print as color values are saved in 16 bit values (higher precision). But if you plan on doing heavy image processing involving many levels of operations, such as 'color space changed (even just sRGB to/from RGB), resize, distortions, blurring, shadows, etc etc all to the same image, in the same command (which is recommended for the same reason), then having 16bit is better as it will preserves the lower precision of the images between processing steps. You can also then save in 16bit file formats (PNG, MIFF, PbmPlus) between commands, even if the final save is back to a 8bit image file format like ICO and JPEG. (This is the default for this reason)

The next level you did not mention is Q16 HDRI, that takes precision to 32 bit floating point values which allows you to deal with image values that become very small or very large without the rounding and clipping effects of images. You can even deal with negative values, especially in some colorspaces. Essentually it is used to prevent image data loss when proceing images in extremes such as when using HDRI images, Fourier Transforms, or just high levels of compression, expansion you may get in mathematical processing of raw data.

That is it in a nut shell. Q16 is good middle ground for most operations involving distortions and multi-iamge compositions and image processing effects. Q8 if memory is tight but you are only doing simple operations, HDRI is you are doing extreme operations.

A few comments from a Windows user on this:

1) I have always wondered about the possible advantages of static linking. I would expect such a version of IM to take longer to load, but being slightly faster when doing the real work, because there is no overhead for dynamic linking. So what are those staticly linked packages are really intended for?

2) I thing you can possibly install the 32 bit version of IM on a 64-bit machine, although I haven't tried that with IM specifically. Generally speaking, you can run 32 bit programs on 32 bit machines without much problem. They might be somewhat slower though. However, if there is a 64 bit version of the program available, such as for IM, there generally in no reason to install the 32 bit version. I did this however with Ghostscript, because a friend of mine warned me of the newer 64 bit versions.

3) When you call "convert -version" under Windows, IM gives no information about whether it was compiled for 32 bit or 64 bit. So someone might erroneously run a 32 bit version on a 64 bit machine. I think information on this should be added to future versions, especially when even more versions (such as HDR) come into play.