You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Every DICOM file that has NumberOfFrames should also have FrameIncrementPointer. That is how a DICOM reader can tell whether the frames are cine, slices, pages, etc.
However, I have seen NumberOfFrames used with SOP classes that do not permit multi-frame files (such as the legacy CT Storage and Secondary Capture Storage SOP classes). In such cases, the FrameIncrementPointer is missing.
Currently, when vtkDICOMReader encounters a file with NumberOfFrames but without FrameIncrementPointer (or with a FrameIncrementPointer that points to an unknown element), the frames are treated as a vector dimension and each frame becomes a voxel vector component. In order to better handle these malformed multi-frame files, vtkDICOMReader should instead read them as multi-slice, using the following heuristics:
If SpacingBetweenSlices is present, it should be used as the slice spacing
if SpacingBetweenSlices is absent, but SliceThickness is present, then SliceThickness should be used as the slice spacing
if both SpacingBetweenSlices and SliceThickness are absent, then the data should read as a temporal series
Also,
if ImageOrientationPatient is present, the slice orientation shall be as described in the NM Reconstruction Module
The text was updated successfully, but these errors were encountered:
Every DICOM file that has NumberOfFrames should also have FrameIncrementPointer. That is how a DICOM reader can tell whether the frames are cine, slices, pages, etc.
However, I have seen NumberOfFrames used with SOP classes that do not permit multi-frame files (such as the legacy CT Storage and Secondary Capture Storage SOP classes). In such cases, the FrameIncrementPointer is missing.
Currently, when vtkDICOMReader encounters a file with NumberOfFrames but without FrameIncrementPointer (or with a FrameIncrementPointer that points to an unknown element), the frames are treated as a vector dimension and each frame becomes a voxel vector component. In order to better handle these malformed multi-frame files, vtkDICOMReader should instead read them as multi-slice, using the following heuristics:
Also,
The text was updated successfully, but these errors were encountered: