Thanks for the info, Bob. This is super helpful.
On Thu, Mar 11, 2010 at 10:34 PM, Bob Friesenhahn <
> Something which is vital to know for JPEG is that the JPEG decoder can
> return a smaller size (subresolution) of the image to GraphicsMagick. That
> saves a lot of time. This support is triggered by using the -size option
> prior to the input file name with a geometry argument which is at least the
> size that you need. You will want to specify a size at least double the
> final size so that antialiasing works well.
I had tried the -size option earlier with no improvements, but now that
you've mentioned this I found that I had it placed *after* the input file.
For my testing, I have 100 files I have been resizing. Without -size, this
was taking 31 seconds. After adding the -size option, the speed improved to
10 seconds. Faster, indeed!
Also, a -thumbnail option was added which works like -resize but takes steps
> to make resizing to much smaller sizes a lot faster. It does that by using
> the 'sample' algorithm followed by the 'resize' algorithm using the box
> filter. But since it knows the image size and the ratios, it does this
> So use something like
> gm convert -size 340x270 input.jpg -thumbnail "170x135^" \
> -gravity Center -crop "170x135+0+0" -quality 90 -type TrueColor \
> -interlace None output.jpg
I replaced -resize with -thumbnail as you suggest in the options above, but
in this case the speed dropped. The same set of 100 images took 14 seconds
to process when using -thumbnail.
> Lastly, if you are batch processing a whole lot of files in a directory
> tree, you may want to use 'mogrify' instead since it is able to execute the
> same commands on a large set of files without starting a new process for
> each one.
Looking at the directory options, I don't think this is going to be helpful
for my case. The file layout I have is one full-size image and a number of
derivative sizes per directory. For example, in a single directory we have
files something like: 12345_full.jpg, 12345_small.jpg, 12345_medium.jpg, and
12345_large.jpg. The new sizes I am batch processing will be derivatives of
the *_full.jpg size but must live in the same directory. Also, these are
new files, and not resizing a file in place of the original. Correct me if
I'm wrong here.
I am glad that you brought this up, however, because we have an upcoming
project that *will* touch files in place. Mogrify will probably come in use
Senior Software Engineer