Datamodule cleanup #657
Datamodule cleanup #657
Conversation
github-actions
bot
added
datamodules
|
|
||
| sample["image"] = sample["image"].float() | ||
| def remove_bbox(self, sample: Dict[str, Any]) -> Dict[str, Any]: |
There was a problem hiding this comment.
Removing the "bbox" key is required for using the samples in the lightning trainer, however we need the "bbox" for predictions so I decoupled this logic from preprocess.
There was a problem hiding this comment.
Do you remember why we had to remove bbox again? I feel like there was an option to keep it if we did something else differently...
There was a problem hiding this comment.
I'm suspicious that it has something to do with collation, but the trainers/test definitely break if you don't remove it.
torchgeo/datamodules/eurosat.py
Outdated
| @@ -9,7 +9,7 @@ | |||
| import pytorch_lightning as pl | |||
| import torch | |||
| from torch.utils.data import DataLoader | |||
| from torchvision.transforms import Compose, Normalize | |||
There was a problem hiding this comment.
Removed Normalize as it is more explicit to subtract band means then divide by band stdevs.
There was a problem hiding this comment.
Not sure if I agree with this. I think the Normalize transform is more explicit since it tells you why you're doing it, not just what you're doing.
There was a problem hiding this comment.
True, I was thinking of it as, "there are many ways to 'normalize' something where Normalize happens to apply channel wise standardization". I don't have a strong opinion here.
There was a problem hiding this comment.
I don't have a strong preference here either. I tend to use builtin library functions where possible since I trust them more than I trust my own coding, but this one is obviously very simple. I think the biggest advantage of using Normalize is that it does the .reshape(-1, 1, 1) here for you, so that's one less thing to worry about. It also uses .view(-1, 1, 1) which I think is more efficient. It also accepts a list, so you don't need to convert it to a tensor yourself. Personally I'm gonna vote for using Normalize to keep the code as simple as possible.
| @@ -24,7 +23,6 @@ def __init__( | |||
| self, | |||
| root_dir: str, | |||
| labels: Sequence[str] = USAVars.ALL_LABELS, | |||
| transforms: Optional[Callable[[Dict[str, Tensor]], Dict[str, Tensor]]] = None, | |||
There was a problem hiding this comment.
We don't allow transforms to be passed in to any other DataModules
There was a problem hiding this comment.
This is what we call a slippery slope: #498 (comment)
Also see #596
There was a problem hiding this comment.
Haha yeah I know; I can't make up my mind here. If we have this Optional[Callable] as an argument, then we can't (easily) initialize a class instance from a configuration file. This will make general-purpose scripts like predict.py more difficult to write. On the other hand, our datamodules aren't very useful for experimentation as-is, because good train-time augmentations are a very important.
There was a problem hiding this comment.
Can't we have a set of default transforms associated with each datamodule? Then users can override them in Python if they need to via this optional callable (experimentation) but we'll still have config files without customization that default to the optimal known transforms (reproduction).
There was a problem hiding this comment.
Yeah I think that's the best of both worlds. I don't think an "optimal" known transform exists across these datasets -- but a sane default implemented consistently would be a good step. Further, as long as these are optional train transforms, instantiating the DataModule without them shouldn't have any effect on using the DataModule for pre-processing purposes.
| preprocessed sample | ||
| """ | ||
| sample["image"] = sample["image"].float() | ||
| sample["image"] /= 255.0 |
There was a problem hiding this comment.
It seems like we're somewhat arbitrarily deciding whether to normalize to [0, 1] or [-1, 1]. Not sure if there is any advantage to one or the other.
There was a problem hiding this comment.
I wouldn't mind arbitrarily being consistent and doing [0,1] normalization for everything.
There was a problem hiding this comment.
I'm not sure if this needs to be solved in this PR, just something to think about. We should probably try both and see if it makes any difference. It may be different on a case-by-case basis.
|
Okay, so I'm going to switch to using Normalize consistently then leave further changes for another PR |
There was a problem hiding this comment.
Technically, a lot of these changes (transforms -> preprocess) are API changes that should be documented with .. versionchanged:: 0.3 but I doubt too many people are calling these directly or overriding them so I won't ask for documentation of these changes.
Inria adds an augmentations parameter. Do we want to remove this now for consistency or keep it and think about how to handle this later? Inria was added in this release so its API hasn't been public so we can remove it without documenting the change if we do it now.
I think remove it |
* Cleaning up preprocessing methods across DataModules * Decoupled deleting the bbox with the other transforms in the GeoDataset DataModules * Cleaning up how channel standardization is done * Changing default conf for ETCI2021 and fixing So2Sat * Forgot to update the indices. * Change to use Normalize * Remove default augs
Cleaning up how preprocessing in the datamodules works in preparation for writing a prediction utility.
Now, each DataModule has a
preprocess(self, sample)method that performs the image preprocessing and doesn't break if there isn't a "mask" or "label" key in the sample. This is important aspredict.pyneeds to be able to apply the same image pre-processing that a trained model checkpoint used while training, however the new data that the model is being run over will definitely not have any "mask" or "label" parts.I also took this opportunity to clean up a few things throughout the DataModules -- I'll go through and explain these changes inline with comments.