[BUG] Inconsistent definition of AcquisitionDuration

[effigies]

The current definition of AcquistionDuration is

Duration (in seconds) of volume acquisition. Corresponds to DICOM Tag 0018, 9073 Acquisition Duration. This field is mutually exclusive with "RepetitionTime".

The definition of DICOM tag 0018, 9073 is:

The time in seconds needed to run the prescribed pulse sequence.

They also helpfully provide a graphic to clarify the definition:

So this is the duration of the full scan, which only overlaps for single-volume acquisitions. Our definition more closely aligns with
FrameAcqusitionDuration 0018,9220:

The actual amount of time [in milliseconds] that was used to acquire data for this frame.

---

I propose the following (re)definitions:

AcquisitionDuration: Duration, in seconds, of scan acquisition, including all volumes for multi-volume scans. Corresponds to DICOM Tag 0018, 9073 Acquisition Duration.
FrameAcquisitionDuration: Duration, in seconds, of volume acquisition. Corresponds to DICOM Tag 0018,9220 Frame Acquisition Duration.

This change needs to be communicated somehow. While upstream tools are going to refer to DICOM, downstream tools may only refer to BIDS. Any suggestions for wording?

[Lestropie]

Even the DICOM definitions might not be ideal:

• "Time in seconds needed to run the prescribed pulse sequence" is very MR-centric
• "The time in seconds needed to complete the acquisition of data" (found from same DICOM tag but for CT) might be misconstrued as commencing on the first TR where data corresponding to the output DICOM series are "acquired", ie. excluding establishing steady-state / calibration volumes

I wonder if there's something in the realm of "the time required to execute the program responsible for image data acquisition"; that would exclude sequence-agnostic features like patient prep / re-shimming, but rightly include things like establishing magnetisation steady-state.

[effigies]

Short term fix is to add selectors to only apply the mutex for BOLD images:

bids-specification/src/schema/rules/checks/func.yaml

Lines 95 to 106 in 5fc3528

	RepetitionTimeAcquisitionDurationMutex:
	issue:
	code: REPETITION_TIME_AND_ACQUISITION_DURATION_MUTUALLY_EXCLUSIVE
	message: |
	The fields 'RepetitionTime' and 'AcquisitionDuration' for this file are mutually exclusive.
	To specify acquisition duration, use 'SliceTiming' or 'DelayTime'
	(RepetitionTime - AcquisitionDuration).
	level: error
	selectors:
	- type(sidecar.AcquisitionDuration) != "null"
	checks:
	- type(sidecar.RepetitionTime) == "null"

[effigies]

Even the DICOM definitions might not be ideal:

• "Time in seconds needed to run the prescribed pulse sequence" is very MR-centric

• "The time in seconds needed to complete the acquisition of data" (found from same DICOM tag but for CT) might be misconstrued as commencing on the first TR where data corresponding to the output DICOM series are "acquired", ie. excluding establishing steady-state / calibration volumes

I wonder if there's something in the realm of "the time required to execute the program responsible for image data acquisition"; that would exclude sequence-agnostic features like patient prep / re-shimming, but rightly include things like establishing magnetisation steady-state.

After a couple months, I'm still undermotivated to come up with a sentence that satisfies multiple modalities. We can use AcquisitionDuration__mri and AcquisitionDuration__ct to distinguish between two different interpretations of the same concept. As long as we point back to the DICOM tag and show the right text for MRI and CT, I think the situation is unambiguous.