I currently have a DWI dataset that was processed with eddy_cuda without topup. I am now interested in adding topup to my processing pipeline. To save resources and processing time, I would like to use applytopup to apply the field to my already existing eddy_cuda outputs, rather than rerunning eddy with topup inputs.
Barring the fact that eddy isn’t deterministic and will yield slightly different outputs each run, would applying the topup field to the eddy output yield essentially identical outputs as inputting the topup fields to eddy? Or would using it as an input to eddy result in fewer interpolations than applying it to the outputs as a second step.
If, in fact, applying it after results in 2 interpolations rather than 1, could anyone advise on how to concatenate topup with eddy registrations so I could apply it all to the raw DWI in one step?
Even if more computationally demanding, my suggestion would be to re-run your dataset with topup + eddy, the way FSL recommends. Indeed, as stated by the documentation:
eddy can utilise the information from different acquisitions that modulate how off-resonance translates into distortions. An example of this would be acquisitions with different polarity of the phase-encoding. Hence we need to inform eddy about how each volume was acquired.
I think the eddy estimation for eddy currents + motions witout topup must be different than the estimation you would get if you provided eddy with susceptibility estimation from topup. May be that is why you noticed a non-deterministic behaviour of eddy. I never heard about this non determinism of eddy, could you elaborate on this point?
This are my views as a simple user of topup + eddy. You can get more information from the FSL developpers directly in this forum: JISCMail - FSL List at WWW.JISCMAIL.AC.UK .
Hi @jsein , thank you for the reply. I do agree that rerunning it would be ideal but I will ask the developers for their opinions as well. As for non-deterministic behavior of eddy, I have run multiple runs of the same scans using the --init_rand parameter as posted in this. Like they said, my values are very similar but always a little off. While not impactful on the preprocessing overall, maybe you will find this interesting.