-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Update ['pixdim'] after Spacing transform in meta dict. #8269
base: dev
Are you sure you want to change the base?
Changes from all commits
cdb8391
8cc6175
501bc45
c5ebb0d
1aabdae
fe05f59
14b4942
3935ff5
464a99d
b73e733
89d71ac
c593d01
6f217d1
2d703c4
b6dd460
a34a656
e4e089f
8b7463d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||
---|---|---|---|---|
|
@@ -24,11 +24,13 @@ | |||
import numpy as np | ||||
import torch | ||||
|
||||
import monai.transforms as transforms | ||||
from monai.config import DtypeLike, KeysCollection, SequenceStr | ||||
from monai.config.type_definitions import NdarrayOrTensor | ||||
from monai.data.box_utils import BoxMode, StandardMode | ||||
from monai.data.meta_obj import get_track_meta | ||||
from monai.data.meta_tensor import MetaTensor | ||||
from monai.data.utils import is_supported_format | ||||
from monai.networks.layers.simplelayers import GaussianFilter | ||||
from monai.transforms.croppad.array import CenterSpatialCrop | ||||
from monai.transforms.inverse import InvertibleTransform | ||||
|
@@ -520,6 +522,11 @@ def __call__(self, data: Mapping[Hashable, torch.Tensor], lazy: bool | None = No | |||
output_spatial_shape=output_shape_k if should_match else None, | ||||
lazy=lazy_, | ||||
) | ||||
if isinstance(d[key], MetaTensor) and f"{key}_meta_dict" in d: | ||||
if "filename_or_obj" in d[key].meta and is_supported_format( | ||||
d[key].meta["filename_or_obj"], ["nii", "nii.gz"] | ||||
): | ||||
d = transforms.sync_meta_info(key, d) | ||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. May I ask why we need this sync here seems it already been done in the MONAI/monai/transforms/transform.py Line 426 in 996e876
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thank you for your question. In |
||||
if output_shape_k is None: | ||||
output_shape_k = d[key].peek_pending_shape() if isinstance(d[key], MetaTensor) else d[key].shape[1:] | ||||
return d | ||||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this may need to be more generalized. There are options in LoadImaged to change the default naming convention between a key and the meta_dict for that key.
meta_keys
andmeta_key_postfix
can change this behaviour. I don't know how well changing those from their defaults is supported, however.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@atbenmurray Thank you for your suggestion. We plan to implement checking all dictionary keys that start with
{key}_
to support custom settings ofmeta_keys
andmeta_key_postfix
. This ensures that no matter how users configure the naming conventions in LoadImaged, we can correctly synchronize metadata from the MetaTensor to the corresponding meta dictionary.During implementation, we discovered that
sync_meta_info()
doesn't properly synchronize meta dictionaries with custom postfixes, and it creates a new key using the default postfix.For example, if the original key is 'image' and the postfix is changed to 'dict', there would be two keys: 'image' and 'image_dict'. However, after executing
sync_meta_info()
, a third key 'image_meta_dict' is created, using the default postfix.In our implementation, we've worked around this by directly updating the existing meta dictionaries, which avoids the creation of additional keys. Would you consider this behavior something that should be addressed in a separate issue, or is our current approach sufficient? We'd appreciate your thoughts on this.
cc @slicepaste @IamTingTing