💾 Archived View for dioskouroi.xyz › thread › 29408341 captured on 2021-12-04 at 18:04:22. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2021-12-03)

🚧 View Differences

-=-=-=-=-=-=-

ImageMagick: CLI for Image Editing

Author: ijidak

Score: 159

Comments: 95

Date: 2021-12-01 19:53:42

Web Link

________________________________________________________________________________

coldpie wrote at 2021-12-01 20:39:56:

I always found it fascinating the grade-A executable names which imagemagick was able to claim in the global namespace:

imagemagick /usr/bin/animate
    imagemagick /usr/bin/compare
    imagemagick /usr/bin/composite
    imagemagick /usr/bin/conjure
    imagemagick /usr/bin/convert
    imagemagick /usr/bin/display
    imagemagick /usr/bin/identify
    imagemagick /usr/bin/import
    imagemagick /usr/bin/mogrify
    imagemagick /usr/bin/montage
    imagemagick /usr/bin/stream

nauticacom wrote at 2021-12-01 21:11:57:

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

noobermin wrote at 2021-12-01 23:54:15:

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.

zamadatix wrote at 2021-12-02 02:42:36:

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.

alerighi wrote at 2021-12-01 20:42:53:

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

ReaLNero wrote at 2021-12-01 20:44:08:

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.

majkinetor wrote at 2021-12-01 22:02:55:

Sounds like you want PowerShell style naming :)

ReaLNero wrote at 2021-12-01 23:51:04:

With good autocomplete, I wouldn't mind it!

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.

noobermin wrote at 2021-12-01 23:55:26:

This sentiment directly contradicts your post above...

ReaLNero wrote at 2021-12-02 18:54:26:

I'm making a distinction between mnemonic names (du = disk usage) and just vague names (convert = ???).

enobrev wrote at 2021-12-01 20:41:46:

This is something I always preferred about the graphicsmagick fork, was the `gm` base command.

pxc wrote at 2021-12-02 04:31:16:

I came here to say the same thing

pavlov wrote at 2021-12-01 22:42:17:

No self-respecting Unix tool would use such long names, so that's why they were free. "compare" vs "cmp", etc.

Gigachad wrote at 2021-12-01 23:01:49:

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"

pavlov wrote at 2021-12-02 00:40:06:

I was trying to make a joke about the infamous naming practices of Unix, an operating system with a call named “creat”.

saghm wrote at 2021-12-02 04:24:19:

My favorite is "ioctl", which is especially delightful when pronounced phoenetically

noobermin wrote at 2021-12-01 23:59:51:

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.

ajkjk wrote at 2021-12-02 00:16:53:

A regrettable state that will hopefully be fixed someday.

contingencies wrote at 2021-12-02 01:24:04:

_Spell create with an 'e'._ - Ken Thompson (referring to design regrets on the UNIX creat(2) system call and the fallacy of premature optimization)

.. via

https://github.com/globalcitizen/taoup

HeckFeck wrote at 2021-12-01 21:34:36:

If executable names were traded like internet domains, imagine what they'd be worth now.

technobabbler wrote at 2021-12-01 22:18:08:

I tried to convert those units but all I got was an imagemagick error

Meph504 wrote at 2021-12-01 21:15:28:

Image magick has been around for a pretty long time, and was doing image processing on linux before most had considered it.

Maursault wrote at 2021-12-01 22:57:47:

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.

pstuart wrote at 2021-12-01 23:17:36:

Your point would have been much better if you had stopped after the first sentence.

Meph504 wrote at 2021-12-03 04:26:11:

Im really not sure what you are getting at?

I didn't say it was developed on/for Linux.

But because it was a mature product and added to Linux very early on, this is why it was able to get the names that it did.

so maybe you can share what it is you are responding to?

wnevets wrote at 2021-12-01 20:50:33:

the latest versions recommend that you use magick convert instead of just convert. I'm assuming because the globals are going away.

banana_giraffe wrote at 2021-12-01 21:15:41:

"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.

saghm wrote at 2021-12-02 04:22:58:

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".

rambojazz wrote at 2021-12-02 08:42:35:

That's exactly my same thought every time I need to use one of those!

herpderperator wrote at 2021-12-01 21:40:22:

This looks like useful output, what distro and command did you use to list this?

coldpie wrote at 2021-12-01 22:15:48:

Arch Linux.

    $ pacman -Ql imagemagick | grep bin
    imagemagick /usr/bin/
    imagemagick /usr/bin/Magick++-config
    imagemagick /usr/bin/MagickCore-config
    imagemagick /usr/bin/MagickWand-config
    imagemagick /usr/bin/animate
    imagemagick /usr/bin/compare
    ....

You may also enjoy:

    $ pacman -Qo /usr/bin/{display,convert}
    /usr/bin/display is owned by imagemagick 7.1.0.16-1
    /usr/bin/convert is owned by imagemagick 7.1.0.16-1

7kay wrote at 2021-12-01 23:37:37:

For reference (mostly for me as I need this from time to time), you can do the same on dpkg-based distros with

      $ dpkg -L imagemagick-6.q16 | grep bin
     /usr/bin
     /usr/bin/animate-im6.q16
     /usr/bin/compare-im6.q16
     /usr/bin/composite-im6.q16
     /usr/bin/conjure-im6.q16
     /usr/bin/convert-im6.q16
     /usr/bin/display-im6.q16
     /usr/bin/identify-im6.q16
     /usr/bin/import-im6.q16
     /usr/bin/mogrify-im6.q16
     /usr/bin/montage-im6.q16
     /usr/bin/stream-im6.q16

Similarly, you get

      $ dpkg-query -S /usr/bin/convert-im6.q16 
     imagemagick-6.q16: /usr/bin/convert-im6.q16

This does not work for the canonical executables though as they are just symlinks to /etc/alternatives/foobar

pxc wrote at 2021-12-02 08:53:20:

> This does not work for the canonical executables though as they are just symlinks to /etc/alternatives/foobar

you can use realpath for this

        dpkg -S $(realpath /usr/bin/convert)

and you can ignore the path to it entirely with

        dpkg -S $(realpath $(which convert))

rdfi wrote at 2021-12-01 23:25:10:

Is there an easy way to get that list for a package?

wingmanjd wrote at 2021-12-01 20:06:52:

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.

mch82 wrote at 2021-12-01 20:40:21:

Thanks for sharing this tip! Are there any guides you recommend?

Edit: Here’s one guide for the legacy Imagemagick (may not work for the latest release),

https://legacy.imagemagick.org/Usage/compare/

I’m trying to encourage my front end developers to use visual diffs to validate rendering rather than use Protractor to test HTML/CSS.

I’ve known about BackstopJS,

https://garris.github.io/BackstopJS/

and am on the lookout for alternatives.

bkyan wrote at 2021-12-02 00:10:17:

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.

majkinetor wrote at 2021-12-01 22:05:09:

Perceptual diff is another tool doing this:

http://pdiff.sourceforge.net

bkyan wrote at 2021-12-01 23:21:30:

I would recommend generating an animated .webp for the diff output, which ImageMagick supports. Animated GIFs have color resolution limits.

technobabbler wrote at 2021-12-01 22:20:01:

For the lazy geeks out there, the service diffy does this easily and for cheap:

https://diffy.website/

dkuder wrote at 2021-12-01 20:46:32:

There are 634 CVE Records that match your search.

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=imagemagick

There have been a number of zero days.

My entire interaction with Imagemagick has been removing it. Often with great difficulty because there is some odd dependency.

chucky_z wrote at 2021-12-01 21:22:18:

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.

bjackman wrote at 2021-12-01 22:28:11:

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.

[1] Random search result that appears to corroborate my claim:

https://blog.aquasec.com/container-isolation

zamadatix wrote at 2021-12-02 03:03:02:

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.

knicknic wrote at 2021-12-02 08:22:21:

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.

julik wrote at 2021-12-02 11:53:12:

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).

jmull wrote at 2021-12-01 22:13:50:

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.)

?

pmarreck wrote at 2021-12-01 21:26:41:

> My entire interaction with Imagemagick has been removing it.

Same. I've successfully moved all my image manipulation requirements to libVIPS. Far more performant and with a ton less memory usage.

istjohn wrote at 2021-12-01 20:58:31:

I suppose it's probably a good idea to wrap it in a microservice in production.

notreallyserio wrote at 2021-12-01 21:07:08:

Airgapped computer, it's the only way to be sure.

xbryanx wrote at 2021-12-01 21:24:33:

Printer output?

eatbitseveryday wrote at 2021-12-01 20:20:48:

Don't forget GraphicsMagick!

http://www.graphicsmagick.org/

john-tells-all wrote at 2021-12-01 22:32:28:

GraphicsMagick is purportedly much better code and faster... but people still reach for ImageMagick for some reason. Either one is a wonderful, powerful tool!

walrus01 wrote at 2021-12-01 20:26:27:

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.

https://imagemagick.org/script/mogrify.php

TylerE wrote at 2021-12-02 06:16:50:

It's very handy for stuff like manipulating image uploads.

thesuitonym wrote at 2021-12-01 20:26:16:

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.

petercooper wrote at 2021-12-01 20:45:26:

Ditto for ffmpeg when you move into the audio or video realms.

kaladin-jasnah wrote at 2021-12-01 21:13:09:

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.

anthk wrote at 2021-12-02 03:33:51:

ffmpeg for video/audio, sox for audio fx.

laurent123456 wrote at 2021-12-01 21:46:18:

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...

busymom0 wrote at 2021-12-01 21:22:24:

ImageMagick, ffmpeg, exiftool and YouTube-dl are 4 of the most useful tools via command line.

naikrovek wrote at 2021-12-01 21:47:50:

youtube-dl seems to be abandoned, now. yt-dlp (an actively developed fork of youtube-dl) seems to be it's accepted replacement, I think.

fyi

busymom0 wrote at 2021-12-01 22:03:23:

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.

code_biologist wrote at 2021-12-02 00:11:41:

Thank you for the heads up! Been sad to see the site list that youtube-dl works on slowly degrade and shrink.

EamonnMR wrote at 2021-12-01 21:17:42:

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.

jackvalentine wrote at 2021-12-02 04:20:30:

Was this on a public forum you can link?

EamonnMR wrote at 2021-12-03 04:15:35:

Discussion (with script) here:

https://github.com/ImageMagick/ImageMagick/discussions/3124

The resulting PDFs are here:

https://archive.org/details/@eamonnmr

timonoko wrote at 2021-12-02 13:42:44:

I do book scanning a lot. Somebody might

find these simple scripts useful:

https://github.com/timonoko/BookScanner

pull_my_finger wrote at 2021-12-01 20:38:51:

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.

SavantIdiot wrote at 2021-12-01 20:41:08:

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.

binarymax wrote at 2021-12-01 22:10:15:

Always my goto for any batch image manipulation. The documented examples are varied and helpful, but it takes a little while to get used to.

Here's one use of it in the wild, which batch takes a path of GAN output files, each with a grid of thumbnails, and splits them into individual images. Gloriously easy.

https://github.com/binarymax/matchbox-twelvy/blob/master/dcg...

ComputerGuru wrote at 2021-12-01 23:48:09:

See also vips and libvips, presenting a much cleaner library interface and faster processing:

https://www.libvips.org/

skunkworker wrote at 2021-12-02 04:12:37:

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.

jaxomlotus wrote at 2021-12-02 00:15:38:

echoing this. I've been playing with this library and it's great!

sandreas wrote at 2021-12-02 06:35:24:

If you wanna convert images for web, I use tools like:

svgo (SVG Optimization)
  colorist / avifenc (AVIF)
  cwebp (webp)
  convert (ImageMagick, everything else)

because ImageMagick is able to convert MOST of thse, but not every format.

https://github.com/svg/svgo

https://github.com/joedrago/colorist

https://developers.google.com/speed/webp/docs/cwebp

https://imagemagick.org/

pmarreck wrote at 2021-12-01 21:20:55:

If you ever need something actually performant or that uses far less memory, have a look at libVIPS

jandrese wrote at 2021-12-01 21:37:24:

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.

pmarreck wrote at 2021-12-02 03:04:14:

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

undoware wrote at 2021-12-01 23:59:21:

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`

anthk wrote at 2021-12-02 03:41:04:

The next ones will be mplayer, XFig, XPDF, nmh, TKGate for electronic boards, Links and Bochs. Back to 2002 again.

undoware wrote at 2021-12-02 18:37:52:

my default browser is.... [sunglasses emoji] Arena

anthk wrote at 2021-12-03 04:02:48:

Well, a lot of people use links -g and Netsurf daily :p.

HN works on texts, lots of blogs are plain text, and ofc you have

http://68k.news

,

https://lite.cnn.io

and

https://text.npr.org

.

skrowl wrote at 2021-12-01 20:04:14:

This appears to just go to the the script page of imagemagick.org. Is there something new or something else we should be looking at here?

eatbitseveryday wrote at 2021-12-01 20:17:31:

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).

[1]

https://news.ycombinator.com/item?id=29405159

torstenvl wrote at 2021-12-01 20:12:36:

For each thing "everyone knows," there are tons of people learning about it for the first time _right now_.

https://xkcd.com/1053/

petercooper wrote at 2021-12-01 20:46:32:

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.

dragonwriter wrote at 2021-12-01 21:02:38:

> 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.

MrDresden wrote at 2021-12-01 21:59:42:

I'm a dev with 11 years in the field and I've never touched AWS. It is on the _todo_ list though, so I'll get to it eventually.

It can be easy to forget how vast this field truly is.

fknorangesite wrote at 2021-12-01 20:55:12:

People just keep being born.

incanus77 wrote at 2021-12-01 21:39:02:

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.

khuey wrote at 2021-12-01 21:02:57:

https://xkcd.com/2347/

ninju wrote at 2021-12-01 22:24:23:

Reminds me of the tz database is maintained by one person

https://onezero.medium.com/the-largely-untold-story-of-how-o...

mkaic wrote at 2021-12-01 21:20:16:

wow, I thought the comic was already pretty applicable, and then I read the alt-text!

anthk wrote at 2021-12-01 20:51:31:

convert *.png output.pdf

Magic, indeed.

fnord77 wrote at 2021-12-01 22:10:53:

[1999]