Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Overview of pathology naming #3868

Closed
drbeh opened this issue Feb 28, 2022 · 7 comments
Closed

Overview of pathology naming #3868

drbeh opened this issue Feb 28, 2022 · 7 comments
Assignees

Comments

@drbeh
Copy link
Member

drbeh commented Feb 28, 2022

Create and overview of different pathology components and their naming structure.

@drbeh
Copy link
Member Author

drbeh commented Mar 14, 2022

MONAI Pathology-specific Components

Type Subtype Component Backend Transition Path
data datasets PatchWSIDataset - It can be extended to use any derivative of ImageReader class; however, some considerations are required to avoid unnecessary caching for backend libraries with intrinsic cache (like OpenSlide). Also reading a subregion can be generalized to include other image types and readers.
data datasets SmartCachePatchWSIDataset - With a generalized PatchWSIDataset, this can be removed.
data datasets MaskedInferenceWSIDataset - This can be generalized with a sampling on a low-resolution binary mask, which could work with any datasets and dataloader. It is based on the common concept of image level in digital pathology but that can be abstracted to create a uniform API.
data image_reader WSIReader OpenSlide, cucim.CuImage, TiffFile Already in MONAI Core
handlers ProbMapProducer numpy.ndarray It has room to improvements like multi-GPU support; however, making it generalizable to non-pathology images requires many changes and additional helper classes.
transforms spatial SplitOnGrid numpy.ndarray, torch.Tensor This SplitOnGrid and TileOnGrid have very much in common; however, merging them is not trivial since they have different implementations with different efficiencies. Also the combination make the API more complicated with so many options and situations to handle. Need further evaluation of combining approach. Otherwise, we should make the differences more clear and separate their functionalities as much as possible.
transforms spatial TileOnGrid numpy.ndarray
transforms color In pathology, color deals with stains, so we can have either transforms/color or transforms/stain; however, to make it fit to a broader biomedical imaging context, color might be a better choice. Also in case we add any transform that manipulate color profiles.
transforms color HEStainExtractor numpy.ndarray It is worth to explore the posiibility of having the same API as scikit-image or even moving this component there. Efficiency needs to be taken into account for this components.
transforms color StainNormalizer numpy.ndarray It can be generalized to any dimensional color image with three channel color
transforms utility CuCIM cuCIM transforms Already in MONAI Core
transforms utility RandCuCIM randomized cuCIM transforms Already in MONAI Core
metrics FROC LesionFROC numpy.ndarray, torch.Tensor Specific to 2D color images but there is no fundamental barrier to make it 3D
metrics FROC compute_fp_tp_probs numpy.ndarray, torch.Tensor Already in MONAI Core
metrics FROC compute_froc_curve_data numpy.ndarray, torch.Tensor Already in MONAI Core
metrics FROC compute_froc_score numpy.ndarray, torch.Tensor Already in MONAI Core
networks nets TorchVisionFCModel - Already in MONAI Core

@wyli
Copy link
Contributor

wyli commented Mar 22, 2022

Thanks for the summary, would be great to specify the proposed source code file location and namespaces. For example, for monai's LMDBDataset module, it is in

monai/data/dataset.py

and it is accessible via

from monai.data import LMDBDataset
from monai.data.dataset import LMDBDataset

do you envision any alternative submodule aliases for the same module? e.g. monai.data.wsi.PatchDataset and where to put the actual files, it seems monai/data/dataset.py is quite lengthy...? cc @ericspod

@ericspod
Copy link
Member

Adding more subdirectories is the way to go to organise and make explicit what components they have, so monai/data/wsi and monai/transforms/color and others make sense. Many of our existing transform files may do with reorganisation along thematic lines like this anyway so it won't be out of place.

@drbeh
Copy link
Member Author

drbeh commented Mar 23, 2022

@wyli @ericspod, I totally agree with you. monai/transforms/color sounds good to me but let me check on monai/data/wsi to see if there is a way to abstract away WSI part and make it patch-based datasets monai/data/patch. I will check and keep you posted.

@drbeh
Copy link
Member Author

drbeh commented Mar 23, 2022

@wyli @ericspod, on a separate note, since there are many interconnected changes, does it make sense to create a new branch for pathology (then merge it after changes are done)?

@drbeh
Copy link
Member Author

drbeh commented Mar 24, 2022

@wyli @ericspod, I totally agree with you. monai/transforms/color sounds good to me but let me check on monai/data/wsi to see if there is a way to abstract away WSI part and make it patch-based datasets monai/data/patch. I will check and keep you posted.

I evaluated the components and realized the specific needs of pathology datasets are more tied to the whole slide image rather than being patch based, so I think monai/data/wsi/datasets.py an appropriate place to host these datasets. Although patches can be used in radiology workflows too, here we are dealing with patches from images that cannot be loaded into memory. I will preparing a diagram of the pathology component structure to have a better overall view.

@drbeh
Copy link
Member Author

drbeh commented Mar 25, 2022

Refer to #4005 for more details.

@drbeh drbeh closed this as completed Mar 25, 2022
Repository owner moved this from Todo to Done in AI in Pathology🔬 Mar 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 💯 Complete
Development

No branches or pull requests

3 participants