We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Description of be the bug The SliceTiming computation in version 0.3.8 of brkraw seems to give a wrong result.
In /lib/reference.py the formulation is:
/lib/reference.py
SliceTiming = dict(TR = 'VisuAcqRepetitionTime', Num_of_Slice = 'VisuCoreFrameCount', Order = 'ACQ_obj_order', Equation = 'np.linspace(0, TR/1000, Num_of_Slice + 1)[Order]'),
For example, I have a fMRI with 3600 volumes, a TR of 0.5 s, each volume is 64 x 64 x 9, with volume acquisition over the 9 slices.
The bruker parameters are
for visu_pars:
VisuCoreFrameCount : 32400 VisuAcqRepetitionTime : 500
for acqp:
NR : 3600 ACQ_obj_order : [0, 2, 4, 6, 8, 1, 3, 5, 7]
applying print_bids to the recording gives:
print_bids
[0.0, 3.08641975308642e-05, 6.17283950617284e-05, 9.25925925925926e-05, 0.0001234567901234568, 1.54320987654321e-05, 4.62962962962963e-05, 7.716049382716049e-05, 0.0001080246913580247]
It seems that you divide the TR by the total number of acquisitions ($32400 = 3600 \times 9$) and not the number of acquisition for one volume.
Do you agree with that or do I am wrong ?
The text was updated successfully, but these errors were encountered:
You're correct @gjpcbecq, the slice timing definition should be the timing of a slice acquisition within a TR.
Sorry, something went wrong.
Thank you for your input, this will be corrected on next update
dvm-shlee
No branches or pull requests
Description of be the bug
The SliceTiming computation in version 0.3.8 of brkraw seems to give a wrong result.
In
/lib/reference.py
the formulation is:For example, I have a fMRI with 3600 volumes, a TR of 0.5 s, each volume is 64 x 64 x 9, with volume acquisition over the 9 slices.
The bruker parameters are
for visu_pars:
for acqp:
applying
print_bids
to the recording gives:It seems that you divide the TR by the total number of acquisitions ($32400 = 3600 \times 9$ ) and not the number of acquisition for one volume.
Do you agree with that or do I am wrong ?
The text was updated successfully, but these errors were encountered: