Thankfully as of v7 these are all bundled under a single "magick" command (with symlinks for compatibility). Hopefully in the future these can be removed
tbf this sounds like a problem that doesn't need to be fixed... Ironically this would introduce problems where many scripts sort of assume the binaries have the names they have.
Scripts written for version 6 or older are probably going to have problems with version 8 or later anyways as that's what the major version number is there to represent.
import is the most fun, when you forgot the `#!/usr/bin/env python` at the start of the script and of course the first instruction is import and you get an ImageMagik error
They are pretty common verbs, but they give 0 context to the user on what they do. I don't think these names are in any demand -- there's always a better name than "import" for your command line utility.
I was honestly thinking of stuff like `du` (disk usage), `cp`, `mv`, and the like. Like I sort of mnemonically remember them, compared to mentally mapping `convert` -> imagemagick.
Image magick isn't something you use frequently and quickly like changing directories or moving a file. A longer more descriptive name is better here. Also easier to speak. Telling someone to write "compare" is easier than "C-M-P"
The reason the common commands were short was because typing on the keys for old terminals was a pain in general, and thus they are short for historical reasons. It is however an accident of history that them being shorter now makes it more convenient...if you have the names memorized.
ImageMagick was developed by John Cristy at DuPont in 1987 and release in 1990. Your statement is not only false, even it it wasn't, mentioning Linux in relation to ImageMagick is a non-sequitor. Maybe you should try other things.
To be quite clear, in the context of ImageMagick, claiming early Linux image processing with ImageMagick is irrelevant, also, not exactly true. What much does alleged Linux inclusion of any application (/usr/local/*) whatsoever have to do with that application? You're apparently promoting Linux by claiming it's a feat few had considered, or otherwise saying "I am cool," which is fine I guess and I don't doubt it, but also irrelevant.
As I pointed out, ImageMagick was developed in 1987, and I should have gone on to specify that most digital image manipulation techniques were developed in the 1960's. So assuming your Yggdrasil installation was processing images with it in early 1993, that it was "before most had considered it" is hardly knowable. I'm reading it similarly to saying your Chevy wipers were wiping your windshield before most had considered it when modern wipers were invented 50 years ago and all the techniques for doing so were worked out around the turn of the century. Chevy's are great and all, but there are other things.
> claiming early Linux image processing with ImageMagick is irrelevant
It is at relevant, because this is about why imageMagick has such prime namespace on linux.
I don't have any idea why you are going in these seeming random directions, I'm not promoting linux, or whatever else your going on about.
This is my original statement
> Image magick has been around for a pretty long time, and was doing image processing on linux before most had considered it.
Surely we can both agree part below is a fair and accurate statement
> Image magick has been around for a pretty long time
This next part, is the part that seemingly needs clarification
> and was doing image processing on linux before most had considered it.
When imagemagick was added to linux in the mid 90s (near ImageMagick 4) not a lot of people were doing image processing in the OS. and being that it was the first mature image processor added to the distro, it is why it has the namespaces it does.
I'm not sure how you are either not getting that clarifier of "on linux" and seem to be trying to debate something about the history of image processing itself?
To be very clear, and to hopefully prevent this continued necro'ing of this post, I was not, talking about this history of image processing, but the specific linux namespace that imagemagick has, and why it has it.
Any other points of debate about this are irrelevant.
Thank you for explaining. I think I see now your observation is that ImageMagick was doing image processing on Linux before most had considered doing image processing on Linux. If so, then I am forced to concede this point. Although I think it is still fair to say, with a market share even now only barely breaching 2%, that most, in fact nearly all, have not considered doing anything at all on Linux since inception and likely not even five or ten years from now. This means those intrepid Linux+ImageMagick users processing images in the mid-1990's are that much more notable as those lucky few doing stuff with Linux before most had considered it, but also that those getting directory listings in Linux right this moment are also somewhat intrepid because most, maybe as much as 97.1%, had never considered even doing anything like that on Linux. I wonder what else most have not even considered doing on Linux. I expect nearly everything.
"convert" always gave me trouble on Windows with some existing tools that used Windows' built in "convert" tool. It was an edge case, but always entertaining when the tool needed to convert a filesystem or some tool I wrote wanted to convert an image, and got the wrong executable.
I totally agree and also had found it fascinating, except for...mogrify? I don't think I've ever heard that word before, and I don't even know what it could mean based on the only related word I can think of, "transmogrify".
At my $OLDJOB, I used ImageMagick to compare snapshots during some automated front-end testing on our public Drupal site. It would compare the running test to previously accepted images, highlighting pixel diffs in red. It would also generate a 4 frame animated gif with of the original, highlit changes, the running test version, and back to the highlit changes (so it could loop for better comparison).
Imagemagick saved enormous amounts of time for us as we made CSS and other module upgrades.
A note of caution if you're planning to use Puppeteer for screenshots -- One oddity I've experienced with Puppeteer, is that there are sometimes very small height differences between headless and non-headless modes when generating screenshots. I suspect the root cause is that they are rounding sub-pixels differently, in certain scenarios. So, I typically run Puppeteer locally with { headless: false } to try to get a pixel-perfect match to the regular desktop Chrome experience.
Imagemagick is one of the few bits of software where the functionality is worth the risk. Simply find a way to remove any network access and use it. I used to run it in a docker container with (almost) all capabilities dropped but with a directory mapped into it to run.
Not sure if this is common knowledge (??) but I feel I should note here: in my job we absolutely do not consider containers to be a security boundary[1]. On the other hand I still tend to use them for isolation on my personal boxen, because they at least reduce the blast radius of bugs or shitty packaging.
The article's sources disagree with the article. Its link to Microsoft's definition of a security boundary explicitly includes containers as a security boundary twice in the tables and offers bounties if you can break out of that security boundary. Its link and quote from Google say it's not a _strong_ security boundary yet the article claims Google said it wasn't a security boundary at all. The Red Hat link doesn't say anything about security boundaries whatsoever but it does say containers aren't perfect protection yet they do provide some protection. The Netflix link also explicitly says containers are a security boundary multiple times and they use additional protections to strengthen that boundary. At this point I'm doing following citations but you get the point.
If the security folks at your job truly doesn't consider containers security boundaries then they are wrong. What seems more likely is they don't consider containers alone a _good enough_ security boundary. And that's fine, some places consider separate processes with different rights good enough security boundaries. Others consider two boxes that are able to interact with each other not a good enough security boundary. It doesn't change that things that weren't secure enough for the use case are still security boundaries.
One way to make it safer is to run inside webassembly. I needed an easy way to modify photoshop files and allow give those commands to other users. So you may want to check out https://knicknic.github.io/imagemagick/ it’s Imagemagick in a progressive web app that allows you to share commands.
I always find it remarkable how people bash on IM without proposing alternatives. Should we all write our own libpng, libtiff, skia, cairo? Even libvips uses some imagemagick facilities for some of its functionality (file format support is just not there). While yes, processing images is complex and some formats are nearly Turing-complete (or outright turing-complete like the container/MP4 derivatives) saying "This software contains vulnerabilities therefore we are going to remove it" is an attitude we could have less of. If you replace your local imagemagick with some cloud service - don't you worry, in addition to your cloud bill growing the cloud service _also_ has to deal with IM vulnerabilities, containerization, sandboxing and all the other good stuff. And is lilely saving money by not going all the way on the above (if I had a dollar for every time a vulnerability could be injected into a service where images can be uploaded and the image renderer starts going out to the internet to embed something into a PNG).
I guess this means you should not use imagemagick in any process where the files (or other input) aren't trusted.
So you could use it in some typical dev workflows (or other business workflows) that are purely internal and maybe in certain non-internal processes where the inputs are strictly limited to trusted ones. But not, e.g., in services/apps that could process untrusted inputs.
(Seems like there are a number of leaks too, but since it's process-oriented, those probably won't be that hard to live with. They might be hard to notice normally.)
GraphicsMagick is purportedly much better code and faster... but people still reach for ImageMagick for some reason. Either one is a wonderful, powerful tool!
I don't know about using a CLI to edit images, but one of the best thing of having imagemagick installed on my workstation (it's an absolute essential) is the 'mogrify' CLI tool to batch resize, manipulate or change formats of a whole directory full of images.
ImageMagick is an incredible bit of kit. It really is a piece of magic that surrounds us daily, that most people don't ever think about, but is easy to use, and insanely powerful.
ffmpeg, the command line tool, is wonderful, until you try its library libav* (not to be confused with the ffmpeg fork). The library is… a bit short of wonderful, at least in my experience. Namely: there is basically zero official documentation for it.
Indeed there's a lot of very useful tools in there, with plenty of options to create custom workflow. I used `compare` with the fuzz option for instance to create a simple camera motion detection: https://github.com/laurent22/pmcctv/blob/e0930a0f7f51c319f66...
You are correct. I switched to yt-dlp just couple days ago (didn’t remember the name when I was typing the comment). YouTube-dl had started having issues where the download speed was super slow and restarting the download also didn’t work. Yt-dlp fixed it.
I did a project where I scanned a bunch of old media. The scans where so high quality that it was impractical to make a PDF for people to use. The Imagemagick community helped out with the right incantation to make everything just kinda work. One of the rare cases where a project's maintainers will just help you use it. I was wowed.
Are there any [e]books focusing on ImageMagick? I use it a good deal, but it's one of those things where you _know_ you're under-utilizing it, and I'd like to take a deep dive with examples and sage wisdom attached.
Totally agree with this. The documentation is very mid-1990's, and every now and then I'll see a fork to it doing something bonkers that I didn't know was in there.
I also echo this, I would go for VIPS first unless there are certain things that imagemagic can do that VIPS can't. You'll cut down on your memory usage significantly (like 500mb down to 20mb) and also use much less CPU.
This is really interesting. In the past I've used netpbm for this kind of work, but it has been on life support for at least a decade now. I never used ImageMagick very much because each time I tried I found a new and exciting crash bug somewhere in the path, plus it tended to be much slower.
Most people have probably moved onto just using someone else to host and manipulate their images, but for business reasons, one of my apps stores its images (and all the cached sizes) in the DB (single source of truth is also nice) so switching to libVIPS enabled me to reduce the amount of compute resources I pay for
seeing ImageMagick, of all hoary tools, trending on HN reminds me that I'm so old that the kids are relishing as classics the tools I regard as outdated.
This is expectable in music, but in tooling?
And with Image-frigging-Magick ?
Damn.
Looking forward to the front-page HN-trended article on `sendmail`
Likely this came about from a reader of a recent post also on the front page [1] where image scaling is mentioned for website loading performance.
> There's a million ways to skin the cat of image resizing, whether you're using photoshop, gimp or a command line utility. We like to use imagemagick when ever possible.
I notice this pattern. Someone posts, readers look at the article / content and the comments, then find something else interesting, and that thing then becomes another submission to HN (either because it is indeed interesting on its own, or to gain points due to relevancy of surrounding material on the front page, or both).
It's definitely a point worth remembering. I sometimes think about AWS's one year free tier offerings and think.. WTF doesn't have an AWS account and would still be signing up in 2021? In reality it's probably a lot of people.
> I sometimes think about AWS's one year free tier offerings and think.. WTF doesn't have an AWS account and would still be signing up in 2021?
AWS free tier offerings are per account; a person (or organization) can have lots of AWS accounts. The people signing up for a new one today may well be people that already have one.
Such a good suite of utilities. When I first got on campus UNIX in '95, I pretty quickly found this and tried in vain to get it running on various versions of IRIX, Solaris, AIX, and whatnot. Wasn't until I got Linux going that I could actually use it.
