Feature/add image types #48
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi ISMRMRD/MRD community, we would like to hear your inputs about adding an ImageType to describe variations of reconstructed images used in MRI. Mentioning members who have been at the meeting but open to others @hansenms @naegelejd @johnstairs @rajramasawmy @ahsanjav
Currently, the MRD format has
ImageTypefield specified as below to serve as the reconstructed image description. However, it is also crucial to save the reconstruction process intermediate values in the image field to associate with reconstructed images #45This suggestion is to add RGBA, bitmaps, and other maps listed below to represent interpretation maps derived from reconstructed images. We would like to hear thoughts and ideas on what to add as a choice of
ImageTypefor each use cases, such as g-factor map for accelerated imaging.Our current idea is below where RGB was originally in ISMRMRD format and this adds an alpha value to the channel dimension for overlay purpose, or there might be a reason to remove when transitioning from ISMRMRD to MRD?
We also considered other options to achieve the similar goal.
ImageMetafield. This can add ambiguity and inconsistent notation, hence we chose enumerator to make an explicit labeling.ImageTypeto separate data types (e.g. real, complex) and interpretation (T1 maps, etc.). However, the generic type ofImageData<T>already specifies the data type. We could also refine the existing list to only describe the semantic meaning of the images.