Moving augmentation away from datamodules

[anthonymlortiz]

Pre-processing and augmentation are slightly different. Pre-processing should be intrinsic to the dataset, however augmentation techniques are not. Augmentation should be decided by the user and TorchGeo should not make an opinion on it.

[adamjstewart]

I think it depends on whether your goal is experimentation or reproducibility. If you want to experiment with different augmentations, you can always subclass the datamodule and override the preprocess method to use different augmentations. But if you want reproducibility, I think it's important to store the augmentations used to train a model directly with the datamodule.

[calebrob6]

By reproducibility you mean for the results in our paper?

[calebrob6]

But anyway, some things that could (should IMO) happen in the datamodules:

• Some standardization in terms of the statistics we embed for preprocessing. Some datamodules (bigearthnet) do percentile-based min/max normalization, some do channel-wise standardization, others divide by a constant (min/max).
• Allow the train augmentations to be a parameter with a sensible default (rotation/flipping augmentation)
• Some standardization around the band subsetting.

[adamjstewart]

By reproducibility you mean for the results in our paper?

Our paper, or:

• results in other important papers
• state-of-the-art results
• model pre-training

Some standardization in terms of the statistics we embed for preprocessing. Some datamodules (bigearthnet) do percentile-based min/max normalization, some do channel-wise standardization, others divide by a constant (min/max).

I think it's fine for datamodules to use different transforms if those work better for that particular dataset.

[adamjstewart]

Note that #730 will allow users to pass transform=... as an argument to all DataModules. Not sure if that suffices here, or if we need to go a step further to skip the default transforms if a user-specified transform is provided.