> Someday ImageMagick will finally break for good and we'll have a long period of scrambling as we try to reassemble civilization from the rubble.
EDIT: don't forget to always hover over the image. Half of XKCD's fun comes from those tidbits.
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.
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.
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.
> GraphicsMagick is originally derived from ImageMagick 5.5.2 as of November 2002 but has been completely independent of the ImageMagick project since then.
More info on the reason for the fork (at the time)
That's leaving a pretty big loophole there and in the case of SQLite you'll need that. To re-create something that solid will take a lot of effort.
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.
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.
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.
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)
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.
While "rewrite it in Rust" is a cliche, I think ImageMagick is a good candidate!
[ 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 ]
[0]: https://gist.github.com/ldd/9b576bb6f0ac99a0a7895eaf1aae7802
Netpbm also does this; you can use the "pamdice" program (together with "pngtopnm" and "pnmtopng" to decode and encode PNG). However, pamdice requires creating intermediate files, while ff-dice doesn't require that.
So, you have two more things to try if ImageMagick won't work.
Ironically, trying to good for `ff-dice` or `pngff` sends me back to this thread!
(Although there are a lot of files, you will only need to compile the files that you need, and you can delete the files that you don't need.)
Props to ffprobe too - that’s part of our file upload + identification + sanitation process.
In summary:
H.264 has the widest adoption of all modern video formats.
H.265 is Microsoft + Apple.
WebM is Google and Firefox.
H.266 came out a few weeks ago.
Additionally, if you have user CSS in your browser, you can force it to display the title text even in the official xkcd web pages (CSS has a command to display the text of HTML attributes).