This document explains how augmentation is organized in the current GloViTa runtime, how policy selection works from the CLI, and how to add new shared or dataset-specific policies.
Augmentation is split into three layers on purpose:
- user-facing override surface in configs/augmentation.py
- dataset-specific defaults in configs/data.py
- implementation code in src/glovita/augmentation/policies
Why this split exists:
- users should be able to inspect defaults in config classes
- implementation details should live next to augmentation code, not in config
- dataset defaults should be easy to find without reading registry logic
Important files:
- ../../src/glovita/configs/augmentation.py: user-facing augmentation override block
- ../../src/glovita/configs/data.py: per-dataset default
train_policyandtest_policy - ../../src/glovita/augmentation/policies/registry.py: resolves policy names to builders
- ../../src/glovita/augmentation/policies/two_dim/defaults.py: shared 2D policies
- ../../src/glovita/augmentation/policies/three_dim/defaults.py: shared 3D policies
- ../../src/glovita/augmentation/policies/dataset_specific: dataset-specific policy modules
The augmentation config block is:
data.augmentation
Key fields:
train_policytest_policyimage_sizeresize_sizecrop_sizecutout_sizepatch_sizemeanstdtrain_kwargstest_kwargs
Runtime behavior:
- dataset config provides default train/test policy names
- encoder preprocessing may fill in unset size/normalization fields
- explicit augmentation values always override encoder-derived defaults
Defined in two_dim/defaults.py:
default_2d_1default_2d_2default_2d_3default_2d_4default_2d_5default_2d_randaugment
The intent is progressive strength:
default_2d_1: close to evaluation-style preprocessingdefault_2d_2: mild geometric augmentationdefault_2d_3: moderate geometry + colordefault_2d_4: stronger and broader perturbationsdefault_2d_5: the most aggressive shared 2D default
shared_default_2d
Defined in three_dim/defaults.py:
default_3d_1default_3d_2default_3d_3default_3d_4default_nnunetdefault_nnunet_DA5
shared_default_3d
Dataset defaults live in configs/data.py, not in the augmentation registry.
Examples:
Cifar10Configtrain_policy="randaugment"test_policy="default"
ImagenetConfigtrain_policy="randaugment_448"test_policy="default_448"
ChestXRay14Configtrain_policy="default_2d_2"test_policy="shared_default_2d"
This is intentional. A user should be able to inspect dataset defaults without reading augmentation implementation code.
At runtime, the path is:
- dataset config provides default policy names
- CLI may override them via
data.augmentation.* - the augmentation registry validates and resolves the names
- dataset factory merges:
- policy defaults
- encoder preprocessing defaults
- explicit augmentation overrides
That merge happens in:
glovita_train \
--data.dataset chestxray14 \
--data.data_root_dir /data/ChestXray14 \
--data.augmentation.train_policy default_2d_4glovita_train \
--data.dataset imagenet \
--data.data_root_dir /data/ILSVRC \
--data.augmentation.train_policy randaugment_224 \
--data.augmentation.test_policy default_224 \
--data.augmentation.image_size 224 \
--data.augmentation.resize_size 256glovita_train \
--data.dataset cifar10 \
--data.data_root_dir ./data \
--data.augmentation.train_kwargs.cutout_size 12Use train_kwargs and test_kwargs only for genuinely policy-specific values
that are not worth promoting into the shared schema.
To add a dataset-specific policy module:
- Create or update:
src/glovita/augmentation/policies/dataset_specific/<dataset>.py
- Export:
SPATIAL_DIMTRAIN_POLICIESTEST_POLICIES
- Set dataset defaults in the matching config class in:
The registry does not own dataset defaults. It only resolves available policy names and builders.
For a new shared 2D or 3D policy:
- Add the builder to:
- Export it in:
TRAIN_POLICIES- or
TEST_POLICIES
- Add the policy name to the type alias in:
That last step matters because policy names are part of the typed user-facing config surface.