Acquisition time

556 views
Skip to first unread message

Chris Gorgolewski

unread,
Mar 30, 2017, 6:39:35 PM3/30/17
to bids-discussion
Hi,

I would like to propose a new field for BOLD fields:

AcquisitionTime: Time it takes to acquire data from all slices in seconds. Unless this was a sparse acquisition sequence this should be the same as RepetitionTime. This field is an alternative way to describe sparse sequences if SliceTiming cannot be used.

Let me know what do you think.

Best,
Chris

RORDEN, CHRIS

unread,
Mar 30, 2017, 6:58:35 PM3/30/17
to bids-di...@googlegroups.com
Chris

I would be careful how you define this: is it the beginning of the first slice to the beginning of the last slice, or the beginning of the first slice until the completion of readout of the last slice? (fence post problem) For SPM’s slice timing it assumes the former definition, which is always LESS than the TR. To quote SPM’s notes "Enter the TA (in seconds). It is usually calculated as TR-(TR/nslices)” I would be wary of using a definition that differs from SPM’s. You can work out either by looking at the “SliceTiming” array in the current BIDS standard (SPM’s version is largest minus smallest value in this array, to compute the latter you add the difference between the n and n-1 value).

Chris Rorden

Xiangrui Li

unread,
Mar 30, 2017, 7:41:32 PM3/30/17
to bids-di...@googlegroups.com
That can be a useful field if the slice timing is not available. But I would suggest to use a different name, since AcquisitionTime is a dicom field indicating the acquisition time in format of HHMMSS, and may have a fraction for seconds. If I remember correctly, BIDS uses AcquisitionDateTime which combines both dicom AcquisitionDate and AcquisitionTime.
 
The other way to store this information is to store the duration which was not used for acquisition. Siemens has a field in CSA header called DelayInTR. I have no idea how GE/Philips store this, or if they store this at all.
_____________

Xiangrui Li, Ph.D.

Center for Cognitive and Behavioral Brain Imaging

The Ohio State University

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To post to this group, send email to bids-di...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bids-discussion/CAAQzouMs%3DigzMZAY8BPzvy16bHM3Nek-HdZ34%3DZBKrMQFiqCqw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Auer, Tibor

unread,
Mar 31, 2017, 8:57:38 AM3/31/17
to bids-di...@googlegroups.com
Hi,

One of the issue is that TA is rarely the same as TR even in case of a non-sparse acquisition. First, slices acquisitions are not evenly distributed (at least for Siemens), because there is smallest unit of time (for Siemens it is 25ms, I think). Second, there are introductory and closing processes before the first and after the last slice, which also takes time.

Vale,
Tibor

Auer, Tibor (Ph '99)
--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To post to this group, send email to bids-di...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bids-discussion/2223AED5-DDB3-4F92-BE52-DA574C49E916%40mailbox.sc.edu.

Thomas Nichols

unread,
Apr 1, 2017, 12:04:55 PM4/1/17
to BIDS Discussion
Echoing Xiangrui’s concern, I fear this will be confused with a time of day, MMDDYY HHMMSS, of the acquisition start.   An alternative is “AcquisitionDuration”, but as “Acquisition” typically is understood as the whole “session” duration, so I think this is also problematic.  We can do VolumeAcquisitionTime, but then *that* is plagued by *when* *exactly* does an acquisition start and stop?  Instant of first excitation and then to end of read out of last slice?  But what about:

SparseRepetitionTime; Time taken to acquire all slices in seconds, computed as delay between successive slice acquisitions (excitation to excitation) multiplied by the number of slices. Unless this was a sparse acquisition sequence this should be the same as RepetitionTime. 

On this part: "This field is an alternative way to describe sparse sequences if SliceTiming cannot be used.” why do sparse acquisitions rule out SliceTiming?  

-Tom


--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To post to this group, send email to bids-di...@googlegroups.com.

Satrajit Ghosh

unread,
Apr 1, 2017, 3:28:28 PM4/1/17
to bids-di...@googlegroups.com
hi tom,
 
On this part: "This field is an alternative way to describe sparse sequences if SliceTiming cannot be used.” why do sparse acquisitions rule out SliceTiming?  

this is because a number of the SMS sequences run on Siemens Trio encode slice timing information incorrectly. we have not checked on the prisma yet, but will report back.

i would be ok with reusing the csaheader term: DelayInTR, which is what we are using currently to help calculate the acquisition time.

cheers,

satra
On 30 Mar 2017, at 23:39, Chris Gorgolewski <krzysztof.gorgolewski@gmail.com> wrote:

Hi,

I would like to propose a new field for BOLD fields:

AcquisitionTime: Time it takes to acquire data from all slices in seconds. Unless this was a sparse acquisition sequence this should be the same as RepetitionTime. This field is an alternative way to describe sparse sequences if SliceTiming cannot be used.

Let me know what do you think.

Best,
Chris

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bids-discussion/3DA2A298-E802-4451-B656-7619EF665692%40gmail.com.

Xiangrui Li

unread,
Apr 1, 2017, 4:04:08 PM4/1/17
to bids-di...@googlegroups.com
The problem of timing recorded in SMS dicom is likely a sequence issue, irrelevant to Siemens models. It is fixed in the latest release.
 
By the way, I misremembered the term for the delay in TR. The full name in CSA header is lDelayTimeInTR. It appears only in CSA header only it is nonzero, a general treatment for items in CSA header.
_____________

Xiangrui Li, Ph.D.

Center for Cognitive and Behavioral Brain Imaging

The Ohio State University

 
Date: 2017-04-01 15:28
Subject: Re: [bids-discussion] Acquisition time
To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To post to this group, send email to bids-di...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bids-discussion/CA%2BA4wOmkGqeeqQh2HbWZ8Kby%2BcXBx0QQP5CmOYDAekqQszu9Qw%40mail.gmail.com.

Chris Gorgolewski

unread,
Apr 1, 2017, 11:27:38 PM4/1/17
to bids-discussion
Thank you for all the input. What about the following:

DelayTime: Time (in seconds) between the end of acquisition of all data for one volume and the beginning of the acquisition of data for the following volume. If the field is not present it is assumed to be set to zero. This field is compulsory for sparse sequences that do not have the SliceTiming field set to allowed for accurate calculation of "acquisition time".

Best,
Chris

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bids-discussion/2017040116040420851523%40osu.edu.

Auer, Tibor

unread,
Apr 3, 2017, 9:15:41 AM4/3/17
to bids-di...@googlegroups.com

I wonder whether we want to make explicit that we speak about delay “by design” (sparse acquisition) and not “by implementation” (delay usually present due to technical reasons).

It is also question how relevant the latter can be, i.e. whether it should be captured. Let me describe a use case:

For whatever reason, I need TR 1.5s, which allows, say 20 slices. On the other hand, 20 slices could be acquired within 1.45s, but I need TR = 1.5s. So, there is a 50ms gap. I wonder whether in this case slices are acquired within 1.45s leaving 50ms DelayTime (“by implementation”), or the slice acquisition is evenly distributed across the 1.5s (virtually no DelayTime), what is captured in lDelayTimeInTR DICOM field; and whether all this matter at all.

 

Vale,

Tibor

 

Auer, Tibor (Ph '99)

 

From: bids-di...@googlegroups.com [mailto:bids-di...@googlegroups.com] On Behalf Of Chris Gorgolewski
Sent: 02 April 2017 04:27
To: bids-discussion <bids-di...@googlegroups.com>
Subject: Re: Re: [bids-discussion] Acquisition time

 

Thank you for all the input. What about the following:

 

DelayTime: Time (in seconds) between the end of acquisition of all data for one volume and the beginning of the acquisition of data for the following volume. If the field is not present it is assumed to be set to zero. This field is compulsory for sparse sequences that do not have the SliceTiming field set to allowed for accurate calculation of "acquisition time".

 

Best,

Chris

On Sat, Apr 1, 2017 at 1:04 PM, Xiangrui Li <li....@osu.edu> wrote:

The problem of timing recorded in SMS dicom is likely a sequence issue, irrelevant to Siemens models. It is fixed in the latest release.

 

By the way, I misremembered the term for the delay in TR. The full name in CSA header is lDelayTimeInTR. It appears only in CSA header only it is nonzero, a general treatment for items in CSA header.

_____________

Xiangrui Li, Ph.D.

Center for Cognitive and Behavioral Brain Imaging

The Ohio State University

 

Date: 2017-04-01 15:28

Subject: Re: [bids-discussion] Acquisition time

hi tom,

 

On this part: "This field is an alternative way to describe sparse sequences if SliceTiming cannot be used.” why do sparse acquisitions rule out SliceTiming?  

 

this is because a number of the SMS sequences run on Siemens Trio encode slice timing information incorrectly. we have not checked on the prisma yet, but will report back.

 

i would be ok with reusing the csaheader term: DelayInTR, which is what we are using currently to help calculate the acquisition time.

 

cheers,

 

satra

On 30 Mar 2017, at 23:39, Chris Gorgolewski <krzysztof....@gmail.com> wrote:

 

Hi,

 

I would like to propose a new field for BOLD fields:

 

AcquisitionTime: Time it takes to acquire data from all slices in seconds. Unless this was a sparse acquisition sequence this should be the same as RepetitionTime. This field is an alternative way to describe sparse sequences if SliceTiming cannot be used.

 

Let me know what do you think.

 

Best,

Chris

 

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To post to this group, send email to bids-di...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To post to this group, send email to bids-di...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To post to this group, send email to bids-di...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To post to this group, send email to bids-di...@googlegroups.com.

 

--

You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To post to this group, send email to bids-di...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bids-discussion/CAAQzouO2s77YgTFKwXpH16Q6UAKm37V1KfjRYA6q8YEpY3VU0A%40mail.gmail.com.

Chris Gorgolewski

unread,
Apr 3, 2017, 11:54:44 AM4/3/17
to bids-discussion
I have to say I am a bit put off by the vagueness of the "by design"/"by implementation" terms. How likely/common is the situation you described? Are we splitting hairs?

Best,
Chris

Subject: Re: [bids-discussion] Acquisition time

hi tom,

 

On this part: "This field is an alternative way to describe sparse sequences if SliceTiming cannot be used.” why do sparse acquisitions rule out SliceTiming?  

 

this is because a number of the SMS sequences run on Siemens Trio encode slice timing information incorrectly. we have not checked on the prisma yet, but will report back.

 

i would be ok with reusing the csaheader term: DelayInTR, which is what we are using currently to help calculate the acquisition time.

 

cheers,

 

satra

On 30 Mar 2017, at 23:39, Chris Gorgolewski <krzysztof.gorgolewski@gmail.com> wrote:

 

Hi,

 

I would like to propose a new field for BOLD fields:

 

AcquisitionTime: Time it takes to acquire data from all slices in seconds. Unless this was a sparse acquisition sequence this should be the same as RepetitionTime. This field is an alternative way to describe sparse sequences if SliceTiming cannot be used.

 

Let me know what do you think.

 

Best,

Chris

 

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/msgid/bids-discussion/012001d2ac7c%2462a6b3a0%2427f41ae0%24%40gmail.com.

Vince Calhoun

unread,
Apr 3, 2017, 11:58:08 AM4/3/17
to bids-di...@googlegroups.com

I think the point is that the spacing is not typically even for standard acquisitions either (this is quite common) though the time differences are relatively small and may not be worth worrying about?

 

From: bids-di...@googlegroups.com [mailto:bids-di...@googlegroups.com] On Behalf Of Chris Gorgolewski
Sent: Monday, April 3, 2017 9:54 AM
To: bids-discussion <bids-di...@googlegroups.com>
Subject: Re: Re: [bids-discussion] Acquisition time

 

I have to say I am a bit put off by the vagueness of the "by design"/"by implementation" terms. How likely/common is the situation you described? Are we splitting hairs?

 

Best,

Chris

 

Subject: Re: [bids-discussion] Acquisition time

hi tom,

 

On this part: "This field is an alternative way to describe sparse sequences if SliceTiming cannot be used.” why do sparse acquisitions rule out SliceTiming?  

 

this is because a number of the SMS sequences run on Siemens Trio encode slice timing information incorrectly. we have not checked on the prisma yet, but will report back.

 

i would be ok with reusing the csaheader term: DelayInTR, which is what we are using currently to help calculate the acquisition time.

 

cheers,

 

satra

On 30 Mar 2017, at 23:39, Chris Gorgolewski <krzysztof....@gmail.com> wrote:

 

Hi,

 

I would like to propose a new field for BOLD fields:

 

AcquisitionTime: Time it takes to acquire data from all slices in seconds. Unless this was a sparse acquisition sequence this should be the same as RepetitionTime. This field is an alternative way to describe sparse sequences if SliceTiming cannot be used.

 

Let me know what do you think.

 

Best,

Chris

 

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To post to this group, send email to bids-di...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To post to this group, send email to bids-di...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To post to this group, send email to bids-di...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To post to this group, send email to bids-di...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To post to this group, send email to bids-di...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To post to this group, send email to bids-di...@googlegroups.com.


For more options, visit https://groups.google.com/d/optout.

 

--

You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To post to this group, send email to bids-di...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bids-discussion/CAAQzouPo5AiHJwP_BW65xxmRNbqvqXojGg%3D5R3yjuhFqrbV5DA%40mail.gmail.com.

Auer, Tibor

unread,
Apr 3, 2017, 12:53:39 PM4/3/17
to bids-di...@googlegroups.com

For me it is also about how specific the definition is. Strictly speaking, DelayTime –as it is defined – should also capture the small time differences also present in standard sequence, even if it is not relevant.

Vale,

Tibor

 

Auer, Tibor (Ph '99)

 

Li, Xiangrui

unread,
Apr 3, 2017, 1:16:25 PM4/3/17
to bids-di...@googlegroups.com
Based on limited test on Siemens, the slice acquisition (observed from MosaicRefAcqTimes) is evenly distributed across the whole TR (except for the 2.5 ms granulation). The lDelayTimeInTR exists only when a user provides a nonzero delay in the exam card. So there is no worry for this in my opinion.

-Xiangrui

From: bids-di...@googlegroups.com [bids-di...@googlegroups.com] on behalf of Auer, Tibor [tibor...@gmail.com]
Sent: Monday, April 03, 2017 9:15 AM

To: bids-di...@googlegroups.com
Subject: RE: Re: [bids-discussion] Acquisition time

Daniel Handwerker

unread,
Apr 3, 2017, 1:19:07 PM4/3/17
to bids-di...@googlegroups.com

I’m coming in to this discussion midway, but this seems to be getting overly complex. If I’m understanding the underlying issue correctly, there are more and more pulse sequences, like SMS and clustered acquisitions, that would benefit from timing detail beyond repetition time. Focusing on timing rather than sequence types would keep the specifications cleaner and more flexible.

 

To deal with this, one just needs to know the acquisition times for every slice, which should already be stored in DICOM headers (though the header location under which it is stored varies by vendor sequence and some research sequences mess this field up). Such a parameter could be called SliceAquisitionTimes and would be a vector with a number for each slice that notes the start of each slice acquisition. SMS and 3D sequences would have multiple slices with the same times. If this field is empty, then it is assumed that this is a 2D sequence where the slices are evenly distributed across RepetitionTime.

 

If you want to make this slightly more complex and flexible, you could add SliceAcquisitionDuration which could be a single value, if it’s constant for all slices, or a different value for each slice. The benefit of this parameter would be that these would allow for a very wide array of current and future acquisition schemes and help distinguish 2D from 3D sequences. The weakness is that I’m not sure if this information is obviously stored anywhere in DICOM headers.

 

Best

 

Dan Handwerker

JB Poline

unread,
Apr 3, 2017, 1:20:39 PM4/3/17
to The Brain Imaging Data Structure (BIDS) discussion
I agreee with this: sounds like we should have a general way of dealing with this if possible.
cheers
JB

Subject: Re: [bids-discussion] Acquisition time

hi tom,

 

On this part: "This field is an alternative way to describe sparse sequences if SliceTiming cannot be used.” why do sparse acquisitions rule out SliceTiming?  

 

this is because a number of the SMS sequences run on Siemens Trio encode slice timing information incorrectly. we have not checked on the prisma yet, but will report back.

 

i would be ok with reusing the csaheader term: DelayInTR, which is what we are using currently to help calculate the acquisition time.

 

cheers,

 

satra

On 30 Mar 2017, at 23:39, Chris Gorgolewski <krzysztof.gorgolewski@gmail.com> wrote:

 

Hi,

 

I would like to propose a new field for BOLD fields:

 

AcquisitionTime: Time it takes to acquire data from all slices in seconds. Unless this was a sparse acquisition sequence this should be the same as RepetitionTime. This field is an alternative way to describe sparse sequences if SliceTiming cannot be used.

 

Let me know what do you think.

 

Best,

Chris

 

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.


For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bids-discussion/01cc01d2ac9a%24d588d060%24809a7120%24%40gmail.com.

Auer, Tibor

unread,
Apr 3, 2017, 1:26:11 PM4/3/17
to bids-di...@googlegroups.com

So how about this to capture lDelayTimeInTR, because I think that is the intention rather than to capture variation in implementation:

 

DelayTime: User specified time (in seconds) to delay the acquisition of data for the following volume. If the field is not present it is assumed to be set to zero.

 

Vale,

Tibor

 

Auer, Tibor (Ph '99)

 

From: bids-di...@googlegroups.com [mailto:bids-di...@googlegroups.com] On Behalf Of JB Poline
Sent: 03 April 2017 18:20
To: The Brain Imaging Data Structure (BIDS) discussion <bids-di...@googlegroups.com>
Subject: Re: Re: [bids-discussion] Acquisition time

 

I agreee with this: sounds like we should have a general way of dealing with this if possible.

cheers

JB

 

Subject: Re: [bids-discussion] Acquisition time

hi tom,

 

On this part: "This field is an alternative way to describe sparse sequences if SliceTiming cannot be used.” why do sparse acquisitions rule out SliceTiming?  

 

this is because a number of the SMS sequences run on Siemens Trio encode slice timing information incorrectly. we have not checked on the prisma yet, but will report back.

 

i would be ok with reusing the csaheader term: DelayInTR, which is what we are using currently to help calculate the acquisition time.

 

cheers,

 

satra

On 30 Mar 2017, at 23:39, Chris Gorgolewski <krzysztof....@gmail.com> wrote:

 

Hi,

 

I would like to propose a new field for BOLD fields:

 

AcquisitionTime: Time it takes to acquire data from all slices in seconds. Unless this was a sparse acquisition sequence this should be the same as RepetitionTime. This field is an alternative way to describe sparse sequences if SliceTiming cannot be used.

 

Let me know what do you think.

 

Best,

Chris

 

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To post to this group, send email to bids-di...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To post to this group, send email to bids-di...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To post to this group, send email to bids-di...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To post to this group, send email to bids-di...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To post to this group, send email to bids-di...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To post to this group, send email to bids-di...@googlegroups.com.


For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To post to this group, send email to bids-di...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To post to this group, send email to bids-di...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To post to this group, send email to bids-di...@googlegroups.com.

 

--

You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To post to this group, send email to bids-di...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bids-discussion/CALMaa81SPNgCHPC7b0vidL%2BoBfEcrMPs%3D6PW-FN0S7wbAGhM-g%40mail.gmail.com.

Chris Gorgolewski

unread,
Apr 3, 2017, 1:54:06 PM4/3/17
to bids-discussion
On Mon, Apr 3, 2017 at 10:19 AM, Daniel Handwerker <dan.han...@gmail.com> wrote:

I’m coming in to this discussion midway, but this seems to be getting overly complex. If I’m understanding the underlying issue correctly, there are more and more pulse sequences, like SMS and clustered acquisitions, that would benefit from timing detail beyond repetition time. Focusing on timing rather than sequence types would keep the specifications cleaner and more flexible.

The problem is that currently we need to know the slice timing to figure out acqusition time for sparse sequences. However in some situations it is very hard (or impossible) to accuratelly figure out slice timing for some sequences (as Satra pointed out).
 

To deal with this, one just needs to know the acquisition times for every slice, which should already be stored in DICOM headers (though the header location under which it is stored varies by vendor sequence and some research sequences mess this field up). Such a parameter could be called SliceAquisitionTimes and would be a vector with a number for each slice that notes the start of each slice acquisition. SMS and 3D sequences would have multiple slices with the same times. If this field is empty, then it is assumed that this is a 2D sequence where the slices are evenly distributed across RepetitionTime.

This is already part of the spec - see SliceTiming.
  

If you want to make this slightly more complex and flexible, you could add SliceAcquisitionDuration which could be a single value, if it’s constant for all slices, or a different value for each slice. The benefit of this parameter would be that these would allow for a very wide array of current and future acquisition schemes and help distinguish 2D from 3D sequences. The weakness is that I’m not sure if this information is obviously stored anywhere in DICOM headers.

This solulution would require getting the MultibandAccelerationFactor field right as well making this a bit more complex. Specifying delay seems more straightforward.

Best,
Chris

 

Best

 

Dan Handwerker

 

From: <bids-discussion@googlegroups.com> on behalf of "Auer, Tibor" <tibor...@gmail.com>
Reply-To: <bids-discussion@googlegroups.com>
Date: Monday, April 3, 2017 at 12:53 PM

Subject: Re: [bids-discussion] Acquisition time

hi tom,

 

On this part: "This field is an alternative way to describe sparse sequences if SliceTiming cannot be used.” why do sparse acquisitions rule out SliceTiming?  

 

this is because a number of the SMS sequences run on Siemens Trio encode slice timing information incorrectly. we have not checked on the prisma yet, but will report back.

 

i would be ok with reusing the csaheader term: DelayInTR, which is what we are using currently to help calculate the acquisition time.

 

cheers,

 

satra

On 30 Mar 2017, at 23:39, Chris Gorgolewski <krzysztof.gorgolewski@gmail.com> wrote:

 

Hi,

 

I would like to propose a new field for BOLD fields:

 

AcquisitionTime: Time it takes to acquire data from all slices in seconds. Unless this was a sparse acquisition sequence this should be the same as RepetitionTime. This field is an alternative way to describe sparse sequences if SliceTiming cannot be used.

 

Let me know what do you think.

 

Best,

Chris

 

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.


For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bids-discussion/44B942AE-27F5-40CE-AC1B-CDF3BDEE8AA6%40gmail.com.

Chris Gorgolewski

unread,
Apr 3, 2017, 2:04:25 PM4/3/17
to bids-discussion
This seems like a nice compromise. I updated the spec draft.

DelayTime: User specified time (in seconds) to delay the acquisition of data for the following volume. If the field is not present it is assumed to be set to zero. Corresponds to Siemens CSA header field lDelayTimeInTR. This field is compulsory for sparse sequences that do not have the SliceTiming field set to allowed for accurate calculation of  "acquisition time".

Best,
Chris

Subject: Re: [bids-discussion] Acquisition time

hi tom,

 

On this part: "This field is an alternative way to describe sparse sequences if SliceTiming cannot be used.” why do sparse acquisitions rule out SliceTiming?  

 

this is because a number of the SMS sequences run on Siemens Trio encode slice timing information incorrectly. we have not checked on the prisma yet, but will report back.

 

i would be ok with reusing the csaheader term: DelayInTR, which is what we are using currently to help calculate the acquisition time.

 

cheers,

 

satra

On 30 Mar 2017, at 23:39, Chris Gorgolewski <krzysztof.gorgolewski@gmail.com> wrote:

 

Hi,

 

I would like to propose a new field for BOLD fields:

 

AcquisitionTime: Time it takes to acquire data from all slices in seconds. Unless this was a sparse acquisition sequence this should be the same as RepetitionTime. This field is an alternative way to describe sparse sequences if SliceTiming cannot be used.

 

Let me know what do you think.

 

Best,

Chris

 

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.


For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "bids-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussion+unsubscribe@googlegroups.com.
To post to this group, send email to bids-discussion@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bids-discussion/01f701d2ac9f%24615bcf30%2424136d90%24%40gmail.com.
Reply all
Reply to author
Forward
0 new messages