Allow segmentations of images without a frame of reference UID #183
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.
Addresses #159
Following the discussion and extremely useful input from @fedorov and @dclunie on #159 this PR generalizes the
Segmentation
class to allow it to encode segmentations of source images that do not have frame of reference UIDs, such as projection radiography images.There were two major changes required to make this possible.
(1) Prevent the inclusion of
PixelMeasuresSequence
,PlanePositionSequence
/PlanePositionSlideSequence
andPlaneOrientationSequence
when the source images have no frame of reference within which these values could be defined.(2) Alter the dimension indexing mechanism in the case of no frame of reference.
The chosen approach for (2) is to allow only input series or multiframe images with a single instance/frame, and use a single dimension index value: Segment Number. This is a little limited but I imagine will cover the vast majority of use cases. Generalizing beyond this in the future (using mechanisms suggested by @dclunie in #159) may be possible but would dramatically increase complexity. Note that it does allow multiple segments of the (single) input image.
I have tested this with the test file kindly provided by @KarolBorkowski (who originally opened #159) and run the output through dciodvfy. This seems to work fine, apart from some compliance issues with the original file (notably I had to change the PatientSex in the source image file from 'U' to 'O', since 'U' is not a defined value for this attribute and highdicom raises an error as a result). I also tested on a CR image from the pydicom testfiles and that also seems to be working fine.
Any feedback from @KarolBorkowski would also be gratefully received.