0

I'm doing a project doing simple image processing and comparison through the use of ImageMagick

Right now, to execute my commands I'm using the python subprocess module as such:

color_space = ...
evaluate_sequence = ...
output_file_name = ...

convert_cmd = ["magick", "convert", "-colorspace", color_space.name] + queue + \
            ["-evaluate-sequence", evaluate_sequence.name, output_file_name]

subprocess.call(convert_cmd)

I recently learned there are Python wrappers for ImageMagick. In particular, I was looking into MagickWand.

Is there a large benefit of refactoring my code to not use the subprocess module in terms of performance, security, etc?

I think the subprocess call is more readable/simple than if I used something like MagickWand, but if there are other benefits I want to switch.

1 Answers1

2

Should the use of subprocess.Popen and subprocess.call be avoided if possible?

Not worth it. The code you shared is a straight forward task that you already templated in python in a clear & readable way. Why complicate your solution with additional dependencies and complexity for a single quick task. Also convert utility works for you today, but there may be another external utility tomorrow.

Is there a large benefit of refactoring my code to not use the subprocess module in terms of performance, security, etc?

I would argue that it's only the smallest benefit to performance via NOT invoking a system call, but including a C-API wrapper module that dynamically loads shared libraries would also be about the same. Plus, depending on delegations, it's possible that ImageMagick itself would invoke a system call.

For security, either way, your application is still responsible to sanitize variables. I would also suggest...

  • Reading up on Security Policies with IM
  • Ensure that the subprocess.call can not be access by external resources. (i.e. If solution is on a web-server, move tasks to a remote queue worker)
  • Improve error & warning handling. They are more common then you think!

Arguments FOR switching over

Common justifications that I can think of...

  • Reduce I/O because the image data is already in python memory.
  • Tasks are dynamic based on an algorithm (like meme generators).
  • Common pixel iterators
  • OCR/CV preprocessors

Again, you really don't have an argument to justify switching over. At least not today.

emcconville
  • 23,800
  • 4
  • 50
  • 66