Cheasapeake test set image and label size are 2x bigger

[recursix]

Description

the dataloader from the test set of Cheasapeak returns images 2x bigger.

Most likely due to test_transforms from the setup function which has a different configuration than e.g. the validation set. It uses pad_to(self.original_patch_size... instead of center_crop(self.patch_size)

Steps to reproduce

   def convert_test():
    states = ["de", "md", "va", "wv", "pa", "ny"]

    dm = ChesapeakeCVPRDataModule(
        root_dir=SRC_DATASET_DIR,
        train_splits=[f"{state}-train" for state in states],
        val_splits=[f"{state}-val" for state in states],
        test_splits=[f"{state}-test" for state in states],
        patches_per_tile=500,
        patch_size=256,
        batch_size=1,
        num_workers=0,
        class_set=7,
    )
    dm.prepare_data()
    dm.setup()

    test_dl = dm.test_dataloader()

    for sample in test_dl:
        image = np.array(sample["image"])[0]
        print(image.shape)  # this value is 512,512 and should be 256,256

Version

0.2.0

[adamjstewart]

@calebrob6 can you look into this?

[calebrob6]

Yep, this is what happens, although I made this happen on purpose. The images from the test_dataloader look like this:

where the size of the nodata padded area varies. I did this because I wanted the test set metrics to be evaluated over all pixels in the test set (which wouldn't happen with the center cropping).

The reason this is even an issue in the first place is because of #409. In short:

• By design a dataset must have a single CRS specified although the tiles that make up the dataset can be in different CRSs. For example, I say the ChesapeakeCVPR dataset is EPSG:3857, however all of the tiles themselves are in different UTM CRSs.
• When you sample from a dataset the sampler will generate BoundingBox that are in terms of the dataset CRS. We will warp and resample the appropriate data from the underlying tiles to be pixel aligned in terms of the dataset CRS / resolution.
• For datasets like ChesapeakeCVPR this doesn't make sense as everything is already pixel-aligned. We don't have a good way to deal with this.
  • As a hack, in the ChesapeakeCVPR case I instead reproject the BoundingBoxes which is cheaper than reprojecting the data. This causes the data returned by ChesapeakeCVPR to be different number of pixels, even though the BoundingBoxes generated by the sampler are the same size.

[adamjstewart]

Is this fixed by #992? With this PR, we load all images to be 2x patch_size, then we center crop to patch_size for all train/val/test splits.