AlbumentationsX: One Pipeline for Images, Masks, Boxes and Keypoints, Under AGPL-3.0-only
Image augmentation for computer vision. AGPL-3.0-only or commercial licensing.
At a glance
- What is it?
- AlbumentationsX is a Python image augmentation library that targets every annotation type in a single Compose call. The README frames it as high-performance and feature-rich; the licensing page frames it as AGPL-3.0-only unless you buy a commercial agreement. The interesting question is which of those two framings decides your adoption.
- Who is it for?
- Adopt AlbumentationsX if your training code is Python, your annotations are boxes, masks or keypoints, and AGPL-3.0-only is compatible with how you ship. Do not adopt it if you distribute a closed-source product and cannot or will not enter a commercial agreement, because the licence, not the API, is the deciding factor.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem AlbumentationsX solves: one augmentation call for every annotation type
Most augmentation code starts simple and then splits. You augment an image, and then you separately have to move the bounding boxes, resample the segmentation mask, and shift the keypoint coordinates by the same geometric transform. Get the box logic slightly wrong and you train a detector on labels that no longer match the pixels, which is a silent failure rather than a crash. AlbumentationsX exists to keep that in one place. The README describes a "Simple, Unified API" and "One consistent interface for all data types - RGB/grayscale/multispectral images, masks, bounding boxes, and keypoints." The Compose object takes a list of transforms, and the library is responsible for applying the geometric part consistently across targets. The audience is anyone training detection, instance segmentation, semantic segmentation, or keypoint models in Python, plus the medical imaging and 3D cases named in the repository topics. If you only classify images, you need far less than this library offers.
How the pipeline is structured: Compose, probability, and shared geometry
The README's quick start is the whole architecture in miniature. You build an A.Compose with a list of transform instances, each carrying its own p argument, and you call it on your data. In the example, A.RandomCrop(width=256, height=256) has no p, A.HorizontalFlip(p=0.5), and A.RandomBrightnessContrast(p=0.2). That split is the design: a spatial transform changes geometry and therefore has to be reflected in masks, boxes and keypoints, while a pixel-level transform like brightness only touches the image array. The README's table of contents separates transforms into pixel-level, spatial-level, and 3D groups, which matches that distinction. The library also advertises 70+ augmentations through a supported-targets-by-transform reference page, and that page is the document that actually matters in practice, because it tells you which transforms are valid for which annotation type. The README claims the library is "Consistently benchmarked as the fastest augmentation library" and links its own benchmark pages. That is a project-hosted claim with a project-hosted methodology; treat it as a pointer to read, not as a result you can rely on, and note that the README says the numbers are shown further down in a section the supplied text truncates.
Installing AlbumentationsX: PyTorch first, then the headless extra
The README is explicit that the framework install comes first. For Linux CPU-only it gives: pip install "torch>=2.13.0" --index-url https://download.pytorch.org/whl/cpu, followed by pip install "albumentationsx[headless]". The headless extra is the OpenCV build without GUI dependencies, which is what you want on a server or in a container. The README also states the library requires Python 3.10 or higher, and mentions CPU, CUDA, and MPS environments for the PyTorch step. Note the package name on PyPI is albumentationsx, not albumentations, so a requirements file that pins the old name will not pick this up. The import name in the quick start is import albumentations as A, which is worth flagging to anyone reviewing a diff: the distribution and the module do not share a name, so a grep for "albumentationsx" in your source will not find your usage. There is no configuration file or environment variable documented in the supplied material; the transform list in Compose is the configuration.
The licence is the real adoption decision, not the API
AlbumentationsX is AGPL-3.0-only, and the README offers a commercial licence as the alternative. The README states that "Commercial, proprietary, internal, or production status alone does not require a commercial license," which is a narrower trigger than many teams assume when they see AGPL. It points to the AGPL text and to a LICENSING.md file for the applicable terms, and to albumentations.ai/docs/license/ for a licence guide. The honest reading is that the trigger is distribution and network-service obligations under the AGPL, not the mere fact that your company makes money. This is exactly the kind of question to put to your own counsel rather than to a review, and the README itself defers to the licence text and the licensing history document. What is unambiguous from the material: the no-charge option is AGPL-3.0-only, and the alternative permissions come through an agreement requested via the pricing page. If your legal position cannot tolerate AGPL, the pricing page is not a footnote, it is step one of your evaluation.
Where AlbumentationsX is the wrong tool
Three cases stand out. First, closed-source distribution without a commercial agreement: the licence is the blocker regardless of how good the transforms are, and no amount of API quality changes that. Second, non-Python pipelines. The README's integration story is PyTorch, TensorFlow and "other frameworks," but the library is Python and the install instructions are pip; a C++ inference or preprocessing path gets nothing here. Third, classification-only work. If your labels are a single class index per image, the multi-target machinery is overhead you are paying for and not using, and a smaller augmentation helper will do. There is also a versioning caveat visible in the release list: 2.4.6, 2.4.7 and 2.4.9 landed within four days of each other in September 2026. That cadence is normal for a maintained library, but it means pinning a version is the difference between reproducible training runs and runs you cannot reproduce. The supplied material does not describe a deprecation policy or an LTS line, so that is something to establish from the changelog before you depend on it.
The alternative to weigh: torchvision.transforms.v2 versus a unified pipeline
The obvious comparison for a PyTorch team is torchvision's transforms.v2, which also augments images together with boxes and masks. The difference in approach is scope and dependency. torchvision is part of the PyTorch project, so it arrives with the framework you already installed, carries a BSD-style licence rather than AGPL, and its transform set is deliberately smaller and tied to PyTorch tensors. AlbumentationsX is framework-adjacent rather than framework-owned, ships its own OpenCV-based implementation, and the README positions the breadth of the transform library (70+ augmentations across pixel-level, spatial-level and 3D groups) as the reason to choose it. If your augmentation needs are modest and your licence review is expensive, torchvision.transforms.v2 removes a whole category of work. If you need transforms that torchvision does not provide, or you want the same pipeline to serve TensorFlow code, the trade flips. Neither choice is about raw speed alone, and the README's benchmark link is a project claim you should verify against your own data loading, which is usually the actual bottleneck.
Maintenance cost: release cadence, citation, and the upgrade you did not plan
The material supports a few concrete observations. Releases are frequent: 2.4.6 on 2026-09-07, 2.4.7 and 2.4.9 on 2026-09-10, with the repository's last push timestamped the same day as 2.4.9. The README asks users to cite an arXiv paper, "AlbumentationsX: One Augmentation Pipeline for Images and Related Annotations," and states plainly that citations make research impact visible to funders and help sustain maintenance. That is a maintenance model worth understanding before you build on it: the project is asking for citation and offering commercial licences, which together suggest funding comes from a mix of academic visibility and paid agreements rather than from a foundation. Practically, that means your upgrade cost is the cost of tracking a fast-moving library, and your continuity risk is tied to whether that funding mix holds. The supplied material does not include a support policy, a security contact, or a deprecation schedule, so those are gaps to check rather than assume. On the licence side, the README points to LICENSING.md and a licence guide for the terms; read those at the commit the README pins, since licence text can change between revisions.
Editorial conclusion
Adopt AlbumentationsX if your training code is Python, your annotations are boxes, masks or keypoints, and AGPL-3.0-only is compatible with how you ship. Do not adopt it if you distribute a closed-source product and cannot or will not enter a commercial agreement, because the licence, not the API, is the deciding factor. Before you commit, read LICENSING.md at the pinned commit the README links, confirm the Python 3.10 floor against your runtime, and check that the transforms you need appear in the supported-targets-by-transform reference rather than assuming the full list covers your annotation type.
Community notes