Those all do well-defined, well-understood things; they could be replaced relatively easily, and subjectively they "feel" pretty solid. ImageMagick is a complex thing full of subjectively flaky perl and it's not at all clear which things are and aren't supported by it. I'm a lot more worried about ImageMagick breaking than any of the things you list.
I have that issue that it's an overkill for just resizing images (which is what we're using it for; previously it might have had more uses, but now is reduced to this). Also, it gets patched for security often. Like, really often. Maybe more often than it feels comfortable to update.
Then, there are major incompatibilities between versions 6.9.x (which is what is even in the latest Fedora, likely other distros as well) and 7.x (which is probably what's sane to use in this day and age). Which means that to use 7.x, you're likely to have to roll your own and tuck it in its own LD_LIBRARY_PATH. That hurts.
The cherry on top in my particular case is PerlMagick. It's not installable in any way other than with the ImageMagick itself. You cannot have just Perl modules, which you "perl Makefile.PL && make && make install".
When you see separate packages for ImageMagick and PerlMagick in your distro, it means that the maintainer has compiled the whole ImageMagick, then torn it apart. A corollary to that is that PerlMagick is tied to binaries it came with real tight, and updating one means updating the other most of the time.
Then again, it's very likely that you use some other bindings to ImageMagick and my pain is not like your pain.
I agree using imagemagick to resize images is ridiculous overkill, that's using something like 0.01% of what it's capable of...
But then again we also use groupware/chat programs these days that occupy more RAM on the workstation OS than the entire amount of physical RAM in all of the BSD/Linux servers of a mid-sized ISP 18 years ago.
Isn't it super easy to resize images? I wrote a program to resize images after watching a computerphile video on the subject and it took like ten to twenty minutes to get something that seems functionally identical to "real" resizing. If you can read your image as a two dimensional array of bytes you can resize easily enough.
The power of ImageMagick is when you need to support multiple formats. Resizing BMP is easy, the hard part is supporting the various ways that data is encoded.
Not the parent poster, but it does a lot and is a regular source of potential security issues, and there's always a worry you haven't turned off everything you don't need etc. So if I process external inputs and don't really need ImageMagick, I prefer using more limited pieces.
Yeah, the frequency with which they have to make security patches is telling a lot about the overall code quality.
One might argue that it's because it's more popular than other similar projects, but it doesn't happen as often with, say, Pillow. And I don't quite remember PIL/Pillow having holes as big as ImageMagick.
Also, try actually programming against it. Whatever language you choose, it's going to feel clunky and alien. It feels alien in C. It feels alien in Perl. Even in PHP, the match made in hell, it feels thoroughly un-idiomatic. I'm not even surprised they have to patch it up now and then.
Parsing complex untrusted inputs in a language that isn't memory safe is the center of the unholy venn diagram. It's very hard to do a good job under those conditions.
While "rewrite it in Rust" is a cliche, I think ImageMagick is a good candidate!
Replying to sibling comment: It's only overkill if you know in advance you only need one specific kind of input file format. If you need to process many (or arbitrary) image formats with excellent compatibility, then ImageMagick is a godsend.
ImageMagick always seemed to be a bit shaky to me. I usually prefer to use netpbm when I can because each utility is so tiny that it just feels better.
Both projects are moving fairly fast, and regularly adding new features that are not shared.
The last time I made heavy use of ImageMagick/GraphicsMagick, I was suprised how often I would find a feature present in one and not the other (often things like drawing gradients).
And it's not like one has a superset of the other's features: I once painted myself into a corner and created a project that depended on both ImageMagick and GraphicsMagick.
There probably still exist some weird edge cases introduced by imagemagick that the developer(s) behind graphicsmagick haven't accounted for.
That is, should graphicsmagick account for quirks introduced by imagemagick? If it's meant to truly be a drop-in replacement versus one with some strings attached, I would say the answer is yes. Otherwise, you can't easily just drop it into a system and let it run.
Systems built with libraries around long enough as imagemagick likely have all sorts of workarounds built in over the years for that kind of behavior and any deviation from imagemagick might break things more than one expects. We've all been bitten by libraries that claim backwards compatibility with previous versions, only to find out there's breaking changes in some non-trivial use cases the library devs didn't consider. Add those complications on top of switching to a library that is supposed to be a drop in replacement and it can get pretty messy for what seemed like a trivial task.
consider: most state-run web apps that need an image upload for personal ID images, or anything else. Ugh, this happens frequently for me and just frustrates me to no end.
EDIT: I suppose this is why you're saying ImageMagick is king right now.
Never heard of it either, but the homepage provides some info:
> GraphicsMagick is originally derived from ImageMagick 5.5.2 as of November 2002 but has been completely independent of the ImageMagick project since then.
"Honey, can we upload some new photos to my website?"
[ tech spouse takes a look at the image set ... rotated, various sizes, even different formats ... reaches for convert(1) and wonders why non-tech spouse can't do this easily ]
