2 nifti stream and patch transforms #28
Conversation
…sforms for selecting patches (windowing)
|
Yes those changes are in progress. |
|
Example segmentation notebook added. |
|
Comparing this with PR #25 (addresses #9 the intensity transform), both agree that transforms should be callable: (1) (from PR #25) MONAI/monai/data/transforms/intensity_normalizer.py Lines 47 to 49 in 70e675d (2) (from this PR) MONAI/monai/data/transforms/dataset_transforms.py Lines 56 to 57 in d14431b but the format of data input to the callables is different. |
|
Hi @ericspod , Thanks for your hard work, glad to see you complete all the 3 tasks so quickly! |
Conflicts: examples/cardiac_segmentation.ipynb
| yield tuple(slice(s, s + p) for s, p in zip(position[::-1], patch_size)) | ||
|
|
||
|
|
||
| def iter_patch(arr, patch_size, start_pos=(), copy_back=True, pad_mode="wrap", **pad_opts): |
There was a problem hiding this comment.
I think this needs to be extended to support dense sampling grid (overlapping patches) so that it could be used for #39
There was a problem hiding this comment.
Yes I was thinking this too for other tasks.
This includes code for implementing Nifti file reading as a data stream and streams for selecting parts of images as random patches or gridwise patches (gridwise sampling or windowing). The notebook in examples illustrates their use.
The idea behind the Nifti file reading is to define a stream which accepts as input file names to load, caches what has been loaded, and yields the loaded files with their headers if needed. This doesn't do any transformations on the data or header except converting to a canonical ordering, if we should be doing specific thing to clean up the files or enforce an expectation of array dimensions we need to discuss what that would be, either as a change to
NiftiCacheReaderor by defining further transforms to modify the data coming from it. The header also isn't being transformed so we could define a further transform to do that.The transforms in patch_streams.py select out parts of input images, either selecting slices along a dimension in order, selecting random patches, or selecting patches in a grid. The idea is to implement these as transforms so they can be composed in a data stream. Most of the code is in separate utility functions which would be useful for other functions as they are for generic input. The transforms should work for data of arbitrary dimensions although they don't make any assumptions about which dimension is channel and should be altered, that's something the user would specify if we didn't want to build in assumptions.
One issue all these raise is that the input and outputs are all in tuple format. If we want to redefine all data streams types to use dict for IO we would have to modify these, although the change should be minimal. We may also want to define transform streams to pass along some data unmodified, eg. Nifti header dicts, this is another design discussion to have.