I know and very much like IrfanView. However, I have never come
across ImageMagick so I figure I would like to try it now.
ImageMagick is mostly command-line stuff. If you don't grok the
command-line, you might not like it. The default CMD.EXE shell on
Windows is absolutely horrible compared to the shells like bash, tcsh,
and zsh available on Unix-like systems. Fortunately, you can install
Cygwin and run bash on Windows, or you can boot from a Knoppix CD and
use bash there if you want to learn more about the command line.
At
http://www.imagemagick.org/script/binary-releases.php? there is a
choice of four Windoes versions:
Dynamic at 16-bits-pixel Static at 16-bits-pixel
Dynamic at 8-bits-pixel Static at 8-bits-pixel
I have no real idea what the difference is.
"Dynamic" and "static" refer to whether the executables rely on shared
libraries ("DLLs" in Windows-speak) or the executables have the
necessary libraries built in. Static executables are larger and usually
less memory-efficient. The 16-bpp version will handle images that have
16 bits/pixel. Most of the images you see only have 8 bits/pixel, but
16 is becoming more popular since some scanners will scan at that bit
depth and the greater dynamic range makes some editing tasks easier.
Video cards *still* only grok 8 bits R, 8 bits G, and 8 bits B though.
Furthermore the info on Imagemagick and WIndows to be found at
http://www.imagemagick.org/www/Install-windows.html refers to single
and multi threaded runtime support options. Er, what?
"Single thread" and "multi thread" are fairly standard programming
terms. A single-thread executable can only respond to one event at a
time, and may respond sluggishly to user input if the user puts in a lot
of input while the executable is performing CPU or I/O-intensive work.
A multi-thread executable has 2 or more "threads". Each thread can
perform work at the same time[0], which makes it possible for a
correctly written multi-thread program to accept user input with little
delay while it does CPU or I/O intensive work.
It's more difficult to write and debug a multi-threaded program than it
is to write and debug a single-threaded program. Lots of really useful
stuff (Firefox, OpenOffice, Gimp, etcetera) is multi-threaded because
the advantages outweigh the extra programming and debugging time needed.
Many small, short programs (grep, tr, sed, etcetera) are usually
single-threaded because A) they typically execute quickly B) multiple
threads wouldn't help them much.
Can someone kindly steer me through what choice(s) to make.
The 8-bit dynamically-linked version, unless you need to work with 16
bpp images. If you need to do that, use the 16-bit dynamic one. HTH,
[0] Not really, unless you have multiple CPUs. In all modern OSes, the
kernel divides up the available CPU time into timeslices, and assigns
each running process a set of timeslices based on process priority,
whether the process is sleeping or not, the phase of the moon, and some
semi-complex and clever math. Timeslices are short (~25-100
milliseconds, usually) though, so a modern computer can *appear* to be
doing lots of things at once, even though it's really doing thing X
for 1/20 of a second, doing thing Y for 1/20 of a second, doing thing Z
for 1/20 of a second, doing thing X... etcetera. If you have 2 or more
CPUs, 2 or more processes can run at the same time. This can be useful
for obvious reasons.
