OSCDDataModule initialises with batch_size 1, ignoring the configured batch_size about torchgeo HOT 4 CLOSED

There are two questions here:

Why do some data modules pass batch size to the data loader while some pass batch size to NRandomCrop?

This is by design. Many datasets such as GID-15 contain very large image scenes (7k x 7k px). These are too large to pass directly to a model and must first be cropped. If the user desires a batch size of 64 and a patch size of 64, instead of loading 64 of these images (may exceed memory) and cropping each to a small image (64 x 64 px), we load a single image and crop it to 64 random subsets. This was done during The Great Data Module Refactor of 2023 (#992). I don't particularly love this solution, but the alternative was for us to add more parameters/complexity.

Why do OSCD and LEVIR-CD+ specifically do this?

This I'm not sure about. These images aren't honestly that big. We could probably use the normal scheme. I would be open to reviewing which datasets use RandomNCrop and trying to phase it out or replace it with something better. This is also something we plan to upstream to Kornia eventually.

from torchgeo.

Can we close this issue, or do we want to take action on these data modules for small-ish images?

from torchgeo.

Thanks for taking the time to explain the reasoning - this will be useful for anyone else digging into these two datasets.

I think we can close this, and as you suggest creating an issue to review the use of RandomNCrop - I half remember that there is now a more systematic approach possible?

from torchgeo.

I'm unaware of a more systematic approach.

from torchgeo.