About the Speed and Compression Effectiveness of ImageMagick Processing

[urain39]

ImageMagick version

7.1.1-31

Operating system, version and so on

Android 7.1.2 (Termux)

Description

Why is ImageMagick much slower than ffmpeg in processing (scaling, changing color space) images? The output file size also increases by around 10% to 30%.

When converting the same image to YUV420 format, ImageMagick, at its default quality of 92, produces files that are at least 10% larger than FFmpeg's lossless quality (calculated as quality 94 with identify -verbose), and the processing time is almost twice as long.

I used the compare tool to compare the two converted images. Close to half or maybe even more than half of the pixels are somewhat different. However, visually or using a comparison method with a certain tolerance (15%), except for a few pixels, they are basically identical.

Here is ImageMagick options:

    convert \
      -colorspace "YUV" \
      -depth "8" \
      -interlace "none" \
      -limit memory "${memory}K" \
      -limit thread "${thread}" \
      -quality "$quality" \
      -resize "$resize_" \
      -sampling-factor "2x2,1x1,1x1" \
      -- "$file_" "$temp_dir/$file__"

The output format is jpg. Here, the value of $quality is mostly 0, for jpg, it equals 92.

And ffmpeg options:

    ffmpeg \
      -i "$file_" \
      -preset placebo \
      -q:v 0 \
      -vf "format=yuv420p,scale='$resize_':-1" \
      "$temp_dir/$file__"

[snibgo]

Why are you using the old v6 syntax for IM? Why not use the v7 syntax?

Limiting memory and threads will decrease performance.

Are you comparing like with like? Perhaps your IM calculates in floating-point, and ffmpeg uses integer?

Comparing the outputs from each gives no useful information. Instead, you might compare both outputs to a ground truth, which would tell you which output is more correct.

If you are only resizing jpegs, you may find that a specialist jpeg program is faster than either IM or ffmpeg.

[urain39]

Thank you for your reply.

Why are you using the old v6 syntax for IM? Why not use the v7 syntax?

I opted for compatibility with v6 in the script. In most cases, using v6 syntax under v7 doesn't pose significant issues.

Limiting memory and threads will decrease performance.

Yes, but that's not the critical issue. In my task, these limitations are within reasonable bounds.

Are you comparing like with like? Perhaps your IM calculates in floating-point, and ffmpeg uses integer?

Sorry, I'm not very knowledgeable about this. If that's the case, is there a way to optimize it? Or to make IM compatible with integer mode?

Comparing the outputs from each gives no useful information. Instead, you might compare both outputs to a ground truth, which would tell you which output is more correct.

Well, correctness is important too. But having options to sacrifice some correctness for faster conversion would be beneficial...

If you are only resizing jpegs, you may find that a specialist jpeg program is faster than either IM or ffmpeg.

Perhaps. Can you recommend some?

Thank you for your reply again.

[snibgo]

Commands can be written that will work identically in v6 or v7 syntax. Writing them to work only in v6 seems a strange choice.

IM can be built to do the calculations in integer or floating-point. If building with ./configure bash script, the --enable-hdri option uses floating-point.

IM has multiple methods for resampling images, including -resize, -scale and -sample, in order of decreasing quality and increasing speed.

I rarely resize jpegs, and never for serious work. Jpeg is a useful output-only format, and a terrible format for inputs to any image processing.

[urain39]

Okay. Also, I just noticed that these comments are highlighted in the NEWS section of the README:

If these options are prohibitive, you can reduce the quality of the image results. The default build is Q16 HDRI. If you disable HDRI, you use half the memory and instead of predominantly floating point operations, you use the typically more efficient integer operations. The tradeoff is reduced precision and you cannot process out of range pixel values (e.g. negative). If you build the Q8 non-HDRI version of ImageMagick, you again reduce the memory requirements in half-- and once again there is a tradeoff, even less precision and no out of range pixel values. For a Q8 non-HDRI build of ImageMagick, use these configure script options: --with-quantum-depth=8 --disable-hdri.

My bad for not checking the README for a long time.