search

bkainz / fetalReconstruction

GPU accelerated source code for motion compensation of multi-stack MRI data
57 stars 28 forks source link

Reconstructing fetal brain using SVR: target resolution bias field correction and arg -p #18

Open ShawnWangKuvychko opened 5 years ago

ShawnWangKuvychko commented 5 years ago

  1. Our typical fetal brain MRI raw data are T2W images (haste sequence, SIEMENSE 3T scanner) have 1mm in-plane resolution and 3mm thickness. We acquire 9 of these stacks with 3 repetitions for transverse, coronal, and sagittal plane respectively. It seems I can reconstruct target volume at 0.75mm, 0.8mm, 1.2mm etc, but not at 1 mm isotropic resolution. If I do so, there are error messages. Do you know why is that?

  2. I don’t think I understand the -p [ --packages ] option. I thought it has things to do with interleaved acquisition, which we always use in our scans. However, when I specify –p 2, there was an error message and the process got killed. If - p is what I think it is, then how the algorithm know the slice timing since nifti files have being notorious of not keeping slice timing (I use dcm2nii. Is there any conversion software you’d recommend from dicom to nifti?)

  3. Bias field correction. We use flexible coil (basically multi-array surface coil) for maternal imaging, as a result we have significant intensity gradient from abdominal surface to inside uterus. The reconstructed volumes using SVR package still have significant signal intensity inhomogeneity. What parameter(s) you would recommend to tune to ameliorate that?

  4. In your 2015 IEEE Transactions on Medical Imaging paper, you described an algorithm to automatically select a least-motion-corrupted stack as the initial reference volume (in both PVR and SVR). Is there any way to find out which stack is the least motion-corrupted one hence chosen as the reference?

bkainz commented 5 years ago

thanks for posting as discussed in the email thread! Here the answer I have sent you:

Thank you for your interest in our work! Unfortunately, I am lacking the manpower to keep these repositories always up-to-date, bug-free and well documented. Let me try to answer your questions as good as I can.

  1. Which error messages do you get? I would assume that your point spread function is quite different from the one assumed during implementation of this project. It could be that it isn’t large enough or oddly shaped for certain reconstruction target sizes. Are you using the thickness parameter to define the 3mm slice thickness. Our slices are usually thinner.
  2. If your stack has been acquired with parallel imaging in packages you can use this. In this case each package will be temporally close, so less motion corrupted, but interleaved with all other packages in the entire stack.
  3. Bias field correction isn’t perfect in this implementation. You could also simply deactivate it to have faster reconstruction and then use itk’s n4 bias field correction either on the stacks individually before reconstruction or after recon on the resulting volume.
  4. After four years since publication of this article I would recommend you to have a look at our more recent work for SVR/PVR initialisation: https://ieeexplore.ieee.org/document/8295121 We are currently working on an out-of-the-box implementation of this, which is still work in progress: https://github.com/farrell236/SVRnet
ShawnWangKuvychko commented 5 years ago

Thank you!

  1. The task got simply killed without any specific complains during my previous run. Oddly when I tried on a better data set (higher SNR, less motion, however same acquisition parameters), 1 mm target reconstruction worked! In case of PSF, we uses HASTE sequence (SIEMENSE Prisma), do you think it has a significantly different PSF than ssTSE? Do we have options to specify different PSF in SVR/PVR? 3mm usually give us decent SNR. However, for future scans, would you recommend thinner slice at the cost of lower slice SNR?
  2. I tried correct for the bias field on the raw image and in the final reconstructed volume. It turned out much better, thank you for your suggestion!
  3. Thanks for direct us to this new effort!
bkainz commented 5 years ago

I believe thinner with lower SNR is better since the SNR will anyway improve through the orthogonal oversampling. Unfortunately, the PSF is not cleanly implemented and misses some config params on command line level. The only way to modify it is to recompile and to configure here. or extend the PSF variants themselves, which are hardcoded here.

glad to hear that you are making progress!