Images.jl is now a front door to a family of Julia packages, not one package

An umbrella package over a set of sibling packages

Images.jl is an open-source image processing library for Julia, and that description is now the older half of the story. The README says Images.jl is increasingly becoming an umbrella package that exports a set of packages which are useful for common image processing tasks.

The word increasingly is doing real work there. It means the package you install is increasingly a facade rather than an implementation, and the actual functionality lives in packages that are released on their own schedules. If you rely on a function from Images.jl, the version that function comes from is not necessarily the version of Images.jl you have installed.

That is the single most important thing to understand before choosing this library, and it is easy to miss because the package name and the ecosystem name are the same. When you write `using Images`, you are loading a re-export surface over code that lives in several other repositories.

The umbrella arrangement buys you a coherent set of packages without a resolver run, and it costs you the ability to reason about a single version number. For a research script that pulls in images once, the trade is clearly good. For a service with a pinned dependency set, it is a decision you should make deliberately.

The code is spread across five GitHub organisations

The README points out that most of the packages are hosted at JuliaImages, JuliaArrays, JuliaIO, JuliaGraphics and JuliaMath, five separate organisations, and it links to a list of packages useful for common image processing tasks.

This tells you how the ecosystem is decomposed, and the names are a decent guide to the responsibilities. JuliaImages holds the image-specific packages. JuliaArrays holds the array types the image packages sit on. JuliaIO holds the file format readers and writers. JuliaGraphics holds the rendering and display side. JuliaMath holds the numeric and mathematical pieces.

The practical consequence for a user is where you file a bug. If an image loading routine misbehaves, the fix may belong in a JuliaIO package rather than in Images.jl, and the README is explicit about the channels for the umbrella package itself: issues are reserved to bug reports and feature tracking, while questions and discussions belong in the discussions area.

For a team maintaining a fork, the split is also the shape of the upgrade work. You are not tracking one repository, you are tracking a set of them that Images.jl pulls in and re-exports.

Installing it and getting the first pixels back

The README does not contain an install command, and that is worth saying plainly rather than papering over: the package is a Julia package, and the documentation site is where the getting started path lives.

The entry points are juliaimages.org, which carries both a stable build at juliaimages.org/stable and a development build at juliaimages.org/latest, and the package list at juliaimages.org/latest/pkgs/, which is the catalogue of the individual packages that make up the umbrella. The documentation repository is a separate place, juliaimages.github.io, and that is where documentation questions go.

What the README does specify is the version constraint you need to satisfy: Julia >= v1.6, with the recommendation to use the latest stable release, and the caveat that the guarantee covers only the newest Images version.

The first thing to do after loading the package is therefore not an image operation but a check of what you actually got, because the umbrella model means the version numbers of the sibling packages are the ones that matter. The repository ships NEWS.md for the release history and upgrading_tips.md for the version-to-version differences, and those two files together tell you which sibling package versions a given Images release expects, and what changed in the API when you move between them.

Do that reading before writing the first line of image code, because the failure mode of an umbrella package is a method that resolves to a sibling package version you did not expect, and the fix is a pin rather than a code change.

Getting help and asking questions without wasting a maintainer's time

The README is unusually specific about where to ask things, and the reason is visible in the three-way split it defines.

Questions and discussions about the JuliaImages ecosystem go in the discussions area of the Images.jl repository. Issues are reserved for bug reports and feature tracking. And any question about the documentation is considered an issue, so documentation questions belong in the documentation repository, which is juliaimages.github.io.

That last rule is unusual enough to trip up a newcomer, and it reflects the split between the code repository and the site that publishes it. The site has stable and dev documentation builds, at juliaimages.org/stable and juliaimages.org/latest, so the dev version is where unreleased changes appear first.

Alongside the repository channels there are the wider Julia community venues, with Slack, Zulip and Discourse all listed, each with an invite or entry point. The README frames the community as welcoming and supportive and made up of volunteer developers, and it points contributors at CONTRIBUTING.md for how to get started. All participants are expected to abide by the Julia Community Standards.

The badge set in the README header gives the same picture from the other side: unit test status from GitHub Actions, a codecov badge on the master branch, the package evaluation report badge, and separate stable and dev documentation badges. A package evaluation badge that reports a bad result is a project willing to publish the report rather than hide it.

The Julia version support window is narrower than it looks

This is where the README gets specific, and the detail is worth reading twice.

The codebase and dependency of the Images toolbox is deliberately maintained to support all Julia minor versions since the latest long-term-support LTS Julia version, so you can expect it to work on Julia >= v1.6. But the README immediately adds two qualifications. This is only true for the latest Images version, and currently the project does not have an Images LTS version. And for the best experience the recommendation is to use the latest stable Julia version even if it is not an LTS version.

So the compatibility promise attaches to the newest release, not to a maintained long-term-support branch of the package itself. If your production environment is pinned to an LTS Julia, the advice is to run the latest Julia release rather than the LTS one.

There is one historical anchor. Images v0.23 is the last minor version compatible with Julia 1.0, and it will still be under maintenance, but only with minimal efforts from the community, with no forward compatibility guarantee. The README warns that the APIs and behaviours of v0.23 are quite different from those of the latest version.

That last sentence is the reason the repository ships upgrading_tips.md as a top-level file. A version-to-version upgrade guide is a deliberate commitment, and it is worth reading before you pin anything.

Where the umbrella design bites, and what to do about it

There are three practical consequences of the structure, and none of them are reasons to avoid the package, but all of them are reasons to check something.

The first is version pinning. If a downstream package depends on Images.jl and you want reproducible builds, pin the umbrella package and let the resolver lock the sibling packages. The alternative, depending on sibling packages directly, gives you tighter control but loses the facade and means you have to know which package owns which function.

The second is where a bug lives. When something misbehaves in the image loading path, the fix may be in a JuliaIO package with its own release cycle, and upgrading the umbrella package may not be what pulls the fix in. Reading NEWS.md at the repository root is the way to see which sibling versions a given Images release sits on.

The third is the licence. The project metadata records the licence as one GitHub cannot classify, pointing to the LICENSE file, and the repository root carries a LICENSE.md. A custom licence deserves an actual read rather than an assumption, particularly for a dependency that will sit inside a commercial product.

The alternative to the umbrella approach is the one Images.jl started with: pick the individual packages you need, depend on those directly, and manage the versions yourself. That is more work up front and more control afterwards. The umbrella package is the better default when you want a working stack quickly, and the wrong default when you need to know exactly which code is in the process.

The lineage, and who is behind it

The package has history that predates its current organisation, and the README is candid about it.

Elements of this package descend from image.jl that once lived in Julia's extras/ directory. That file had several authors, of which the primary were Jeff Bezanson, Stefan Kroboth, Tim Holy, Mike Nolta and Stefan Karpinski, and the README notes that this repository has been quite heavily reworked since, pointing to the contributors tab and to the other repositories at JuliaImages and elsewhere.

That is useful context for anyone choosing between the Julia image options, because it explains the design lineage. The pieces came out of Julia's own standard library and were then split into a package collection, which is the same shape the ecosystem has since taken more widely, with generic code pushed down into specialised packages and a facade left at the top.

For the user, the practical content of this section is a sense of continuity. Images.jl is not a new project riding a trend, it is a decade-old piece of Julia infrastructure reorganised around an umbrella model, and the release history reflects a package that is still shipping but at a measured pace. The listed releases are v0.26.2 on 2025-01-21, v0.26.1 on 2024-04-06 and v0.26.0 on 2023-07-23, and the last push to the repository was on 2026-05-01.

A dependency that is still being worked on, but whose releases come roughly once a year, is the kind of thing you pin deliberately and check periodically rather than track automatically.

Editorial conclusion

Images.jl fits a Julia user who wants a working image stack in one dependency and is willing to track the umbrella package as it moves functionality into sibling packages. It does not fit a team that needs a stable API across years, because the README states there is no Images LTS version and that the compatibility promise covers only the latest release. Before adopting it, read LICENSE.md, because the project metadata records the licence as one GitHub cannot classify, and check upgrading_tips.md, which the repository ships precisely because APIs change between versions.

Frequently asked questions

Official sources

1. Issues
2. JuliaImages/Images.jl on GitHub
3. Project website
4. README
5. Releases