Installer graphicsmagick avec Homebrew, apk, chocolatey, apt, Nix, pacman, dnf, MacPorts, scoop, zypper

Liens du projet

• Page d'accueil
• Dépôt
• Docs amont
• Page du gestionnaire de paquets

Commandes et alias

• GraphicsMagick++-config
• GraphicsMagick-config
• GraphicsMagickWand-config
• gm

Historique du projet

The project was created on November 19, 2002 as a fork of ImageMagick shortly before the ImageMagick 5.5.2 release. The GraphicsMagick project described its objectives as open development, developer participation, reduced source churn, a preserved stable API, efficient code, improved memory use, a reliable release process, and an accurate ChangeLog.

Early releases renamed the installed libraries, headers, configuration scripts, and Perl namespace from ImageMagick names to GraphicsMagick names, while consolidating user-facing utilities behind the `gm` command. That namespace split made it possible for systems to package GraphicsMagick alongside other image tools without pretending it was only a drop-in binary clone.

GraphicsMagick's FAQ frames the fork as a stability and compatibility project: command syntax and APIs remained upward compatible with ImageMagick 5.5.2, while GraphicsMagick stopped importing later ImageMagick source after licensing and project-direction changes. This makes the package historically important as both a technical fork and a packaging-policy fork.

Historique d'adoption

GraphicsMagick became attractive to Unix package maintainers because it retained a permissive MIT-style license, exposed command-line tools and C/C++ APIs, and kept dependencies comparatively restrained. Its own FAQ calls out smaller installation footprint and fewer external libraries than ImageMagick on some systems, which is exactly the kind of difference distribution maintainers notice.

The package spread through mainstream operating-system package sets as a stable image conversion dependency for scripts, build systems, and web backends. Homebrew, Debian, Fedora, MacPorts, Nix, Arch, Alpine, Chocolatey, Scoop, and other package managers all carry it under recognizable GraphicsMagick naming.

The project also invested in performance work useful to batch processing: release notes describe OpenMP acceleration, multi-core CPU work, faster image I/O, and optimizations for large images. Those choices helped GraphicsMagick retain relevance in server-side conversion pipelines where reproducibility and throughput matter more than a broad UI surface.

Modes d'utilisation

The common package-manager use case is installing the `gm` CLI and invoking subcommands such as `gm convert`, `gm identify`, `gm mogrify`, `gm montage`, `gm composite`, and `gm display`. Existing ImageMagick 5-era scripts often require only the `gm` prefix or compatibility links, while new scripts can rely on the explicit GraphicsMagick command namespace.

GraphicsMagick is also used as a library dependency through GraphicsMagick, GraphicsMagick++, and GraphicsMagickWand configuration scripts. Build systems use those scripts or pkg-config metadata to compile software that reads, writes, transforms, or inspects images.

Configuration lives in `.mgk` files such as colors, delegates, log, modules, and type definitions. That matters to packagers because delegate programs and codec support vary by platform and build options.

Pourquoi les passionnés de paquets s'y intéressent

GraphicsMagick is a classic fork that package maintainers can explain in one sentence: ImageMagick lineage, steadier API, smaller dependency appetite, and the `gm` command. That clarity made it easy to expose as an alternative dependency in ports trees and Linux distributions.

It is also a useful example of why package history is not only version numbers. Licensing, trademarks, API stability, dependency count, and command naming all shaped the package's identity as much as image-processing features did.

For Homebrew-style users, GraphicsMagick is the kind of formula installed indirectly by image workflows and directly by people who prefer predictable CLI behavior for scripted conversion jobs.

Chronologie

• 1992: ImageMagick development began at E. I. du Pont de Nemours and Company, according to the GraphicsMagick FAQ.
• 1999: ImageMagick Studio LLC forked ImageMagick, according to the GraphicsMagick FAQ.
• 2002: GraphicsMagick was created as a fork shortly before ImageMagick 5.5.2.
• 2003: GraphicsMagick 1.0 was released, with renamed libraries and utilities consolidated under `gm`.
• 2004: GraphicsMagick 1.1 followed with additional platform and stability work.
• 2008: GraphicsMagick 1.3 established a long-lived release line.

Related projects

• ImageMagick is the direct ancestor and the project GraphicsMagick is most often compared with.
• Ghostscript, FreeType, libpng, libtiff, libjpeg, WebP, and other delegate libraries shape which formats a GraphicsMagick build can handle.
• Graphviz is unrelated technically but often appears nearby in package graphs because both are long-lived Unix graphics tools with CLI-first workflows.

Sources

• https://foss.heptapod.net/graphicsmagick/graphicsmagick
• https://graphicsmagick.sourceforge.io/FAQ.html
• https://graphicsmagick.sourceforge.io/NEWS.html
• https://graphicsmagick.sourceforge.io/README.html