Slice timing extraction GE for BIDS, interim files, and script output for fmriprep

,
1

I have 3 questions as I work through a a second voyage of fmriprep.

  1. We use a GE Healthcare Discovery MR750 3T MR System which does not output any slice timing information when converting to BIDS with dcm2bids. Searching the dicom headers with dicom_hdr I see no labeled field that would provide slice timing information or potentially allow for the calculation of it. I had noticed some threads where Chris Rorden commented on the topic of extracting this information after having gotten sample data from a GE scanner but am not sure what the results were. Is there a way I can get or calculate this information? Is there something specific I should be looking for? Unfortunately I think my problem is that I’m not sure what to look for as many of the rows in the dicom header are unlabeled.

  2. I notice that fmriprep just saves the finalized .nii files. Is there a way interim functional files can be saved? My PI would like a complete record of the processing done.

  3. In a similar vein to question 2 is there anywhere the actual fsl/afni/etc. commands that are run on the data are stored? I saw the passes to nipype on the GitHub page and it seems like the commands are shown in the terminal as they are run but having an exact list of commands outputted in a single file (or something similar) would be useful in case a particular step does not perform well and parameters need to be tweaked. This is said understanding that you have optimized the pipeline but nothing ever works uniformly for us.

  4. I actually just thought of a 4th question. I also noticed in one of the GitHub code files that fmriprep took non-steady-state scans into account somehow? However, when I ran my first subject through fmriprep - not physically removing the pre-steady-state scans - my GS, GSCF, GSWM, and DVARS parameters all showed essentially a big spike followed by a flat line, likely reflecting the pre-steady-state data affecting these parameters. When you run data through fmriprep should the pre-steady-state scans be removed first? If so will this removal affect any of the BIDS information (i.e. number of scans?)

Thank you for an interesting and helpful tool and for your help!
Lauren

2

If you pass -w argument with a path all intermediate files and command that created them will be stored there.

The detected non-steady state are marked in the NonSteadyStateOutlierXX columns in _confounds.tsv (see https://fmriprep.readthedocs.io/en/stable/outputs.html#confounds for details). You can remove them prior to modelling or just add those columns to your regression matrix.

1 Like
3

The upcoming release of dcm2niix (which is used by dcm2bids) will determine slice timing and phase encoding polarity from GE files. This has required reverse engineering some of the proprietary GE tags based on a limited set of data. I strongly urge GE users to test the current version of dcm2niix (v1.0.20180826 BETA) with their datasets and report any issues on GitHub. Once we are confident in the solution, this feature will be included in the next major release of dcm2niix.

Unix users can typically build the latest dcm2niix code with the command

$ git clone https://github.com/rordenlab/dcm2niix.git
$ cd dcm2niix/console
$ make

Windows users can get the latest commit by clicking on the AppVeyor artifacts button.

3 Likes
4

Thank you Chris and Chris, this is just what I needed to know.
I will try to get some GE test data to see if I can help out.

Prior to this I was using nikadon’s wrapper (https://github.com/nikadon/cc-dcm2bids-wrapper). I will try the new dcm3niix to see if the results converge.

Thank you both for your replies.

5

Hi Chris:

This is going to be the world’s stupidest questions but:
I attempted to build the newest version of dcm2niix using the exact commands you supplied. I received no errors at any step. However when I check the version of dcm2niix it says I am running v1.0.20180622 and no slice timing information is provided when I run it. Am I missing something?

6

Hi Lauren,

Not a stupid question at all. Did you update your $PATH variable with the directory of the dcm2niix binary that was generated with the make command?

If you are just testing on the fly you can type the following in your terminal, but if you want the path to be persistent place it in your .bashrc in your home directory:
export PATH=/directory/to/new/dcm2niix/:${PATH}

-James

7

As James mentions, running dcm2niix from the command line will run whichever version is in your path. If you run ./dcm2niix you will run the copy in your current working directory, if you run /usr/local/bin/dcm2nii you run the copy in that filder (if it exists). You can use the which command to determine the location that will run by default. Therefore, you can install several versions and select which one to run. As shown below, when I build a new copy of dcm2niix, I will compile the beta version in the console folder, but on my machine the default version of dcm2niix is the stable release.

git clone https://github.com/rordenlab/dcm2niix.git
    cd dcm2niix/console
    make
    ...
    $ ./dcm2niix
    Chris Rorden's dcm2niiX version v1.0.20180826 BETA  GCC6.1.0 (64-bit MacOS)
    ...
    $ dcm2niix
    Chris Rorden's dcm2niiX version v1.0.20180622 (JP2:OpenJPEG) (JP-LS:CharLS) Clang9.1.0 (64-bit MacOS)
    ....
    $ which dcm2niix
    /usr/local/bin/dcm2niix
8

Ahhhhhhhh what a horrible oversight on my part. Thank you both James and Chris, that was the exact problem and I probably would have not thought to change it myself. Much appreciated.

Just as a generally informative statement, this new version of dcm2niix and nikadon’s wrapper give approximately the same slice timing information although off at the third decimal place (e.g. dcm2niix: 1.0555, nikadon: 1.0578).

I will see if I can get the technicians at our center to let me get test data for this.

Again, your time and clarifications are much appreciated. Thank you both.