Hi,
I’m reading a Nifti File and writing it back without applying any other filter:
using ReaderType = itk::ImageFileReader;
using WriterType = itk::ImageFileWriter< ImageType >;
This modifies [qs]form_code from ALIGNED_ANAT to SCANNER_ANAT and the matrix
to:
What is the reason for this modification?
Regards,
dzenanz
April 23, 2021, 1:39pm
2
Loss of precision. See these:
Hi everyone,
I’m having discrepancies between the orientation matrix read from DICOMs or from a Nifti generated from the same DICOM series. I’d like to understand what is going on.
I have a DICOM series that I read in the normal way using the ImageSeriesReader:
itkreader = sitk.ImageSeriesReader()
dicom_names = itkreader.GetGDCMSeriesFileNames(r"C:\tmp\DICOM_series")
itkreader.SetFileNames(dicom_names)
itkImage = itkreader.Execute()
Then, I save this image as Nifti and MHD using a ImageFileW…
opened 07:55AM - 27 Jun 19 UTC
type:Bug
status:Backlog
area:IO
<!-- The text within this markup is a comment, and is intended to provide
guide… lines to open an issue for the ITK repository. This text will not
be part of the issue. -->
<!-- Before submitting an issue, please check that your issue has not been
already filed. -->
### Description
Placeholder for possibly a longer bug report. But at least store the information for reproducing the issue.
### Steps to Reproduce
So basically the steps are:
1. cp gdcm/Testing/Data/\*SIEM\*FileSeq* /tmp/dir/
2. gdcmanon --dumb --replace 0020,0037="0.9997586873\0.02191020543\0.001584328775\0.02196741222\\-0.9971551496\\-0.0721043717" /tmp/dir /tmp/dir2
3. bin/DicomSeriesReadImageWrite2 /tmp/dir2 foo.nii
4. bin/ImageReadWrite foo.nii nii.dcm
<!--
1. [First Step]
2. [Second Step]
3. [and so on...]
Provide a minimal, complete, compilable, and verifiable example (commonly
abbreviated as MWE, Minimal Working Example, or sometimes referred to as SSEE,
Short, Self Contained, Correct (Compilable) Example, SSCCE) or code snippet,
either through a GitHub gist (https://gist.github.com/) or providing your own
files (including your source code, `CMakeLists.txt` file if applicable, and your
data) reproducing the issue or showing an incorrect result. -->
### Expected behavior
Minimal approximation of the matrix orientation in between the different representations.
```
$ gdcmdump nii.dcm | grep Orie
(0020,0037) ?? (DS) [.999758687284262\.021910205429893\.001584328774992\.021967412220091\-.99715514960414\-.07210437170029 ] # 102,6 Image Orientation (Patient)
```
This goal is achievable since the MetaImage seems to be giving proper results:
1. bin/DicomSeriesReadImageWrite2 /tmp/dir2 foo.mha
2. bin/ImageReadWrite foo.mha mha.dcm
Leads to:
```
$ gdcmdump mha.dcm | grep Orie
(0020,0037) ?? (DS) [.999758687284262\.021910205429893\.001584328774992\.021967412220091\-.99715514960414\-.07210437170029 ] # 102,6 Image Orientation (Patient)
```
### Actual behavior
Leads to:
```
$ gdcmdump nii.dcm | grep Orie
(0020,0037) ?? (DS) [.9997590014762\.021938811333211\7.921645009e-4\.021938811254904\-.99715514907211\-.07211308646627 ] # 98,6 Image Orientation (Patient)
```
### Reproducibility
### Versions
<!-- If a tagged version, you can get this information by inspecting the
`ITK_VERSION_MAJOR` `ITK_VERSION_MINOR` and `ITK_VERSION_PATCH` variable
values in the `ITKConfig.cmake` file.
If the commit number is required, run `$ git rev-parse --short HEAD`. -->
```
$ git rev-parse --short=12 HEAD
b089be7fdd16
```
### Environment
<!-- Which your OS, CMake, and compiler versions are, or your Python and
installed package versions are. -->
Linux, but I am guessing this will be irrelevant.
### Additional Information
<!-- Any additional information, configuration or data that might be necessary
to reproduce the issue. -->
```
$ git diff
diff --git a/Examples/IO/DicomSeriesReadImageWrite2.cxx b/Examples/IO/DicomSeriesReadImageWrite2.cxx
index be15736..d435c10 100644
--- a/Examples/IO/DicomSeriesReadImageWrite2.cxx
+++ b/Examples/IO/DicomSeriesReadImageWrite2.cxx
@@ -74,7 +74,7 @@ int main( int argc, char* argv[] )
// Software Guide : EndLatex
// Software Guide : BeginCodeSnippet
- using PixelType = signed short;
+ using PixelType = unsigned short;
constexpr unsigned int Dimension = 3;
using ImageType = itk::Image< PixelType, Dimension >;
diff --git a/Examples/IO/ImageReadWrite.cxx b/Examples/IO/ImageReadWrite.cxx
index 0ccc48a..1eb8e71 100644
--- a/Examples/IO/ImageReadWrite.cxx
+++ b/Examples/IO/ImageReadWrite.cxx
@@ -85,8 +85,8 @@ int main( int argc, char ** argv )
// Software Guide : EndLatex
// Software Guide : BeginCodeSnippet
- using PixelType = short;
- constexpr unsigned int Dimension = 2;
+ using PixelType = unsigned short;
+ constexpr unsigned int Dimension = 3;
using ImageType = itk::Image< PixelType, Dimension >;
// Software Guide : EndCodeSnippet
```
<!-- **Note**: Use issues for their purpose; issues are not for code help. Need
help? Ask your question at ITK discourse (https://discourse.itk.org/). -->
When writing a Nifti image, NiftiImageIO seems to silently orthogonalize the IJK to LPS matrix that is written to the file .
Is this normalization really necessary? Can nifti store images with non-orthogonal axes?
(I’ve tried to decode this from nifti’s documentation, but I’ve found image orientation definition extremely complicated, with lots of ambiguities and redundancy. I hope that there is someone here who knows nifti format well.)
lassoan
April 24, 2021, 6:09pm
3
The difference to the problem described by RaC in the first answer is that I’m reading a Nifti file which should already be limited in precision, so it’s not a precision but a orthogonalization problem. My input Nifti was created with Matlab which seems to be more relaxed wrt orthogonality.
And yes: I’m working in the neuroimaging field.