[ENH] Update AcquisitionDuration definition to match DICOM, define FrameAcquisitionDuration for sparse sequences #1974
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 PR brings the AcquisitionDuration definition in line with DICOM and separates it from checks for sparse sequence descriptions. We already narrowed the AcquisitionDuration mutual exclusion rules to only apply to BOLD and ASL data.
This defines
FrameAcquisitionDuration
, which corresponds to DICOM tag 0018, 9220.@neurolabusc I wonder if this tag is used in any of your QA datasets yet?
@Lestropie Are you okay with deferring a CT-applicable definition to when CT data is accepted in BIDS? As noted in #1906 (comment), we do have mechanisms in the schema to provide multiple definitions for terms that are used in multiple contexts.
Closes #1906.
I would also like to relax the mutual exclusion constraints that are indicated in Task Imaging Data - Timing Parameters:
Given that
RepetitionTime
,SliceTiming
andFrameAcquisitionDuration
could all be present in the DICOM metadata, I think a better check would be for consistency among these, instead of enforcing mutual exclusion.DelayTime
andVolumeTiming
cannot be derived from DICOM tags (I don't think), so I would be okay with continuing to validate mutual exclusion or to validate consistency.RepetitionTime
andVolumeTiming
need to remain mutually exclusive, as they are distinct ways of declaring the onsets of each volume.I am happy to enact this change in this PR or another, if people agree that it's worth doing.