Better handling of multi-frame with no FrameIncrementPointer

[dgobbi]

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

[dgobbi]

For reference, FrameIncrementPointer can take these values: SC http://dicom.nema.org/MEDICAL/dicom/current/output/chtml/part03/sect_C.8.6.4.html NM http://dicom.nema.org/MEDICAL/dicom/current/output/chtml/part03/sect_C.8.4.8.html Cine http://dicom.nema.org/MEDICAL/dicom/current/output/chtml/part03/sect_C.7.6.5.html

Or it can be (5200,9230) PerFrameFunctionGroupsSequence if that sequence is present.