Hi,
I want to running topup to HCP dwi data with qsiprep. However, I get a error report about TotalReadoutTime. I converted the unprocessed data with hcp2bids. In the filed of TotalReadoutTime, it gives a 0.6. seem not right?
TotalReadoutTime = Echo spacing * (ReconMatrixPE - 1)
so, TotalReadoutTime=0.00078*(143-1)=0.11154?
Right?
This is the value I’ve used using the same calculation.
Got it. Thank you. 
@Jinboasltw and @bwinsto2 So, may I know what is the TotalReadoutTime for HCP DWI data - 0.6 s or 0.11154 s?
@jagruti BIDS temporal fields are specified in seconds. A readout time of 0.6s is incompatible with the specified echo time. The issue has been reported here. As [noted in the documentation}topup/ExampleTopupFollowedByApplytopup - FslWiki), When the readout time is identical for all acquisitions this simply serves to ensure that the estimated field is correctly scaled in Hz, but it doesn't affect the result in terms of undistorted images. Therefore, while these values are wrong, they will not influence the performance of typical tools.
@neurolabusc Thanks a lot for the reply. I have already seen this page, so what I understand is that the value of 0.6s as coded in hcp2bids is wrong! Also, may I know if you some idea what are the echotime2 mentioned for T1w and T2w image json files in the code of hcp2bids. Also, may I know if these have any impact on the construction of a connectome?
From HCPPipelines (line 222), which confirms the first answer given for this thread: The HCPPipelines is using the echo spacing to calculate themselves the Total Readout time value.
# Calculate the readout time and populate the parameter file appropriately
# Total_readout=EffectiveEchoSpacing*(ReconMatrixPE-1)
# Factors such as in-plane acceleration, phase oversampling, phase resolution, phase field-of-view, and interpolation
# must already be accounted for as part of the "EffectiveEchoSpacing"
For HCP-YA data (collected on custom ‘Connectom’ scanner):
"TotalReadoutTime": 0.111542,
For HCP-Lifespan data (collected on Prisma scanner):
"TotalReadoutTime": 0.0959097,
This Prisma protocols are available online. Relevant details are:
@Chris_Rorden Thanks. But I want to know if these read-out time written in json files, do they have any effect on the construction of connectome?
The written readout times will not influence the final unwrapped data:
When the readout time is identical for all acquisitions this simply serves to ensure that the estimated field is correctly scaled in Hz, but it doesn't affect the result in terms of undistorted images
As an aside, the actual formula is TotalReadoutTime = Echo spacing * (ReconMatrixPE/ParallelReductionFactorInPlane - 1). In these examples, ParallelReductionFactorInPlane is 1, so it can be ignored. Where ParallelReductionFactorInPlane is not one, you may need to have some insight regarding the rounding method used by the manufacturer. For example, for GE this rounding factor is not intuitive and interacts with partial Fourier.
Fortunately, the HCP sequences do not use in plane acceleration, and in general dcm2niix will accurately derive the TotalReadoutTIme for you.
@Chris_Rorden Hi thanks a lot for the information.But I still have a doubt. I downloaded preprocessed data from HCP Young Adult Dataset which is already in nifti format, so no need of dcm2niix I guess. Then I used this hcp2bids code to convert the data into BIDS format that by changing the anat, dwi names and then adding the json files. Then I have used mrtrix for the tractography process and then final connectome. May I know since the hcp2bids has a hard-coded value of “TotalReadoutTime” as 0.6s, would it have impacted the process of tractography and finally the construction of the connectome?
See my previous comment. If you doubt me, change the TotalReadoutTime values and re-process the data.
@Chris_Rorden hey, thanks a lot for all the answers. I am sorry that my questions are a bit naive. I now understand what you had mentioned.
MANAGED BY INCF