Hacker News Reader

Comment by jjcm | Hacker News Reader

As someone who's just now building imagemagick into a system I'm working on as a major dependency, what issues have you had with it?

View on HN

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.

Yep, a big bundle of hard to compile code written in an unsafe language.

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.

RAM usage is your concern? Then using ImageMagick to resize an animated gif is going to get you very quickly acquainted with policy.xml

It doesn’t use intermediate disk store for frames AFAIK so you’d better have enough RAM.

In fact, you’d better just resize with ffmpeg and then convert to gif there.

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.

If you only want bilinear and nearest-neighbor, yes.

Lanczos is much less easy to write, and is even harder to make it run fast.

And there are things like subpixel positioning (it is way too easy to make resizer that shift image by 0.5 pixel)

Add on top of that correct gamma and color space handling...

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!

I think it's a thing! https://github.com/imazen/imageflow

Can it easily sprout bindings to other languages, especially given Rust’s ABI stability guarantees which are as firm as melted icecream?

Its README addresses that. TL;DR: it exposes a C-API and offers bindings based on that, like pretty much any language allowing bindings would.

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.

Netpbm seems to have terrible support for modern image formats. Unless I'm missing something, I can't imagine using it to handle user-supplied images.

Reply on news.ycombinator.com