Bunch of multiframe fixes #1340
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1340 +/- ##
==========================================
+ Coverage 95.34% 95.35% +0.01%
==========================================
Files 207 207
Lines 29081 29238 +157
Branches 4863 4905 +42
==========================================
+ Hits 27728 27881 +153
- Misses 923 925 +2
- Partials 430 432 +2 ☔ View full report in Codecov by Sentry. |
effigies
reviewed
Jul 25, 2024
There was a problem hiding this comment.
Reading DICOM code is pretty abstract for me, so folks more familiar are welcome to provide a more detailed review. Otherwise, the logic here looks reasonable.
A few comments. And would you mind adding a changelog blurb, since you know best what's significant here? Can just start a new section, e.g.:
Upcoming release (To be determined)
===================================
New features
------------
Enhancements
------------
Bug fixes
---------
Documentation
-------------
Maintenance
-----------
API changes and deprecations
----------------------------
|
Addressing the type-check failure in #1341. If that gets merged before this, I'll fix up the conflict. |
effigies
approved these changes
Jul 25, 2024
Can't just use number of frame indices to determine shape of data, as the actual frames could still be split into different files. Also can't assume a multiframe file is more than a single slice.
Corrects issue where order of slice indices was assumed to match the order needed to move along the direction of the slice normal, which resulted in slice orientation flips. Ignores indices that don't evenly divide data, and at the end will try to combine those indices (if needed) into a single tuple index.
Explicitly use `InStackPositionNumber` to identify the slice dim, produce correct output for 2D + time data.
Not sure if this ever actually happens in real multiframe data, but it does in non-multiframe and I can imagine if a DimensionIndexSequence element refrences a per-frame AcquisitionTime then this could happen.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This fixes a bunch of issues with multiframe DICOM.
Instead of assuming the slice index is correct for ordering slices along the normal direction, I compute the slice location from the ImagePositionPatient for each frame and use that. This avoids slice orientation flips. I also use the ImagePositionPatient value with the minimum slice location as the
image_positionproperty, instead of just using the one from the first frame.Any DimensionIndexValues that don't help to sort the data are ignored, and at the end (if needed) we try combine these into a single tuple index. This approach allows the code to work with a number of real world data sets that previously caused errors.