available_transforms

available_transforms(rank=2)

Transform names the installed albumentations actually offers.

With rank=3, only those that can transform a volume. That list has to be found by trying rather than read from anywhere: albumentations supports volumes unevenly, and a transform that cannot raises from inside itself - GaussNoise comes back as KeyError: 'images'. albumentations 2.0.8 offers 118 transforms, and 91 of them took a volume where this was measured.

That second number is not portable and the first one is. 118 is a property of the installed albumentations; the volume count is the outcome of running each transform against a probe, and some of them fail it for reasons that have nothing to do with volumes. What the 27 refusals actually are, counted on albumentations 2.0.8 rather than reasoned about:

10   no volume support, which is the answer being asked for - `KeyError: 'images'`
 9   require three channels, where the probe has one
 8   require a target the probe does not supply: seven ask for metadata of their own
     (`FDA`, `HistogramMatching`, `Mosaic`, `OverlayElements`,
     `PixelDistributionAdaptation`, `RandomCropNearBBox`, `MaskDropout`) and
     `BBoxSafeRandomCrop` asks for bounding boxes

So 17 of the 27 are the probe’s limits rather than albumentations’, and only 10 are a real no. The size category used to be a fourth entry in that table and is gone: a refusal is now retried at a 1024x1024 probe, which is what Crop’s default crop box needs, and the four it was hiding - Crop, FrequencyMasking, TimeMasking, Superpixels - are listed. The three-channel nine are deliberately still refused; the comment above the probe says why.

The old count moved between runs, and the reason was the probe, not the platform. One CI matrix answered 87 on four Linux builds, both macOS builds and Windows with Python 3.10 and 88 on Windows with Python 3.13, which was recorded as that combination with no mechanism claimed. There is no platform axis: Superpixels samples n_segments, and at 8x8 whether the segmentation divides by zero depends on the draw - 4 of 60 attempts succeed. Eight consecutive listings in one process on one machine gave 87, 87, 87, 87, 87, 87, 88, 87.

Escalating removes that, because every refusal is retried where all four size-dependent transforms pass deterministically - Superpixels 40 times out of 40 at 1024x1024. Eight listings gave 91 eight times. The number is still not pinned: it is a property of the installed albumentations, and “stable on one machine” is not “portable”. The authoritative check is the one made when the pipeline is built, against the user’s own shape and parameters.

Empty when albumentations is missing, in which case name checking is skipped and the backend reports the problem later - better than refusing a spec the user cannot fix.

Parameters

Name	Type	Description	Default
rank	int	2 for images, 3 for volumes.	2

Returns

Name	Type	Description
	frozenset[str]	The names, as albumentations spells them, and only things a spec may actually
	frozenset[str]	name. Membership is decided by type - BasicTransform - so the composition
	frozenset[str]	classes (Compose, OneOf, Sequential and five more) and the two parameter
	frozenset[str]	dataclasses (BboxParams, KeypointParams) are absent. They were listed
	frozenset[str]	until 0.7.0a2, when the filter went by the shape of the name, and none of
	frozenset[str]	them was ever usable: an AugmentationStep is a flat name and a dict of
	frozenset[str]	parameters with no nesting, so naming one passed the check here and failed
	frozenset[str]	when the pipeline was built.

names = available_transforms() “HorizontalFlip” in names, “GaussNoise” in names (True, True) any(name in names for name in (“Compose”, “OneOf”, “BboxParams”)) False

At rank 3 the list is shorter, and it is found by trying rather than read from anywhere: support for volumes is uneven and a transform that cannot take one raises from inside the library.

volumes = available_transforms(rank=3) len(volumes) < len(names), “GaussNoise” in volumes (True, False)