AlbumentationsX installs as albumentationsx and imports as albumentations

The distribution is albumentationsx, the import is albumentations

The quick start is where the naming split becomes unavoidable, and it is the first thing to check if you are migrating from the original package:

import albumentations as A

transform = A.Compose(
    [
        A.RandomCrop(width=256, height=256),
        A.HorizontalFlip(p=0.5),
        A.RandomBrightnessContrast(p=0.2),
    ]
)

The distribution published to PyPI is `albumentationsx`, and the packaging metadata repeats that as the project name. The import in every example is `albumentations`, unchanged. Both packages therefore claim one module name, and on a machine where the original distribution is still installed the resolution depends on which one lands on the path first. Nothing in the visible quick start warns about the collision, and the fix, if you hit it, is an environment decision rather than a code change. The transform API itself is unchanged: `A.Compose` takes a list, each entry carries its own probability, and the same interface is claimed for images, masks, bounding boxes and keypoints.

PyTorch has to be installed first, and no accelerator build is chosen for you

Installation is two ordered steps, and the order is not advisory:

# Install the PyTorch build for your platform first. For Linux CPU-only:
pip install "torch>=2.13.0" --index-url https://download.pytorch.org/whl/cpu

# Then install AlbumentationsX with OpenCV.
pip install "albumentationsx[headless]"

The library states plainly that it does not choose or install a PyTorch accelerator build, and points you at PyTorch's own installation selector for CUDA or macOS MPS. So the accelerator question is yours to answer before the install, and the Linux CPU case pins `torch>=2.13.0` against the dedicated CPU index rather than the default PyPI one. Python 3.10 or higher is the stated floor. OpenCV is the other half: if any variant is already present the documented command is `pip install -U albumentationsx`, and if not you pick a variant, with a headless build for servers and Docker described as the lighter package without GUI support.

Commercial status alone does not require a commercial license

Two licence options are offered, and the second sentence of the section is the one to read twice. The commercial option is alternative permissions for proprietary software under an agreement covering your team, products and deployments, obtained by requesting a quote or emailing the maintainer. The AGPL-3.0-only option is available at no charge, and the documentation states that the AGPL permits commercial use subject to its terms. It then draws the line explicitly: commercial, proprietary, internal or production status alone does not require a commercial licence. That sentence removes the most common misunderstanding about AGPL packages in a company setting, where teams assume any commercial use triggers a purchase. What it does not remove is the AGPL's own obligations, which are why the text links out to the AGPL itself, to a licence guide, and to a licensing history document.

An MIT-licensed 2.0.8 of the earlier package is vendored inside the AGPL distribution

The packaging metadata declares four licence files, and the fourth is the interesting one. Alongside `LICENSE`, `LICENSING.md` and `THIRD_PARTY_NOTICES.md`, the list includes `THIRD_PARTY_LICENSES/MIT-Albumentations-2.0.8.txt`. So the MIT terms for version 2.0.8 of the earlier package travel inside an AGPL-3.0-only distribution, which is the correct way to handle a relicensed ancestor: the permissive grant for the old code is preserved in the tree rather than discarded. It also explains why the repository carries both a `THIRD_PARTY_LICENSES/` directory and a `THIRD_PARTY_NOTICES.md` alongside its own licence, and it gives a compliance reviewer something concrete to check rather than a marketing page. Whether any given path in the current source descends from that vendored 2.0.8 is not something the visible material settles, and the distinction matters for anyone reasoning about obligations file by file.

Five licence documents, a legal/ directory, and a procurement section

Licence handling occupies more of this repository than it does in most comparable libraries, and the top-level entries show how many separate artefacts are involved: `LICENSE`, `LICENSE_POLICY.md`, `LICENSING.md`, `THIRD_PARTY_NOTICES.md`, the `THIRD_PARTY_LICENSES/` directory and a `legal/` directory, with `CLA.md` sitting alongside them. The licence files are declared in the packaging metadata rather than left implicit, so an installed wheel carries the same documents as the repository. The institutional angle is handled inside `LICENSING.md` as well, with a section for supplier questionnaires and purchasing documents that a procurement team can be pointed at instead of reconstructing from the AGPL text. So the licensing story is documented in five places, which is a maintenance cost as well as an asset: the risk is not that the terms are unclear, it is that they are stated often enough to drift.

One current maintainer, four emeritus core members, one paper author

The authors section names a single current maintainer, Vladimir I. Iglovikov, listed with a Kaggle Grandmaster badge, followed by four emeritus core team members: Mikhail Druzhinin as a Kaggle Expert, Alex Parinov and Alexander Buslaev as Kaggle Masters, and Eugene Khvedchenya as a Kaggle Grandmaster. The heading distinguishes current from emeritus rather than presenting a flat list, which is an honest way to signal that day-to-day ownership sits with one person. The citation request points at a single-author arXiv paper, `AlbumentationsX: One Augmentation Pipeline for Images and Related Annotations`, arXiv 2608.11123, with a DOI and the same author as the maintainer above. The citation note also states why it matters, that citations make the project's research impact visible to funders and help sustain maintenance, which is a candid way of framing a request tied to the project's funding rather than to citation counts as a metric.

Two releases forty-eight minutes apart, and a version written into pyproject.toml

The release cadence is tight and the version is not derived. Three of the most recent releases are 2.4.11 on 2026-09-28, then 2.4.12 and 2.4.13 on 2026-10-02, the second at 12:55 and the third at 13:43, so forty-eight minutes separate two patch releases on the same day. In the packaging metadata the version is a literal string, `2.4.13`, not a dynamic field, and the build backend is hatchling. Distribution runs along three channels at once: PyPI for the package itself, a `conda.recipe/` directory for conda, and a `uv.lock` at the root for uv-managed environments, alongside a `requirements-dev.txt` for development. The last push on the default branch is dated 2026-09-30, which is before the two releases published the following day, so the tag and the branch history are not in lockstep and a patch bump is the normal way a fix reaches users here.

Editorial conclusion

Use AlbumentationsX when you need one augmentation pipeline covering images, masks, bounding boxes and keypoints across 2D and volumetric data, and when AGPL-3.0-only suits your distribution model, since commercial status alone does not oblige you to buy anything. Before you upgrade from the original package, resolve the naming collision rather than assuming it is safe: the distribution is `albumentationsx` while the import stays `albumentations`, so two distributions can compete for one module name on the same machine. And read the licence files properly, because the MIT text for version 2.0.8 of the earlier package ships inside this one, which is a fact your own compliance review will want stated rather than discovered.

Frequently asked questions

Official sources

1. albumentations-team/AlbumentationsX on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases