fMRI_Data_Analysis_Pipelines

This folder contains a standardized workflow for the analysis of fMRI data, including essential preprocessing steps such as motion correction, spike detection, spatial smoothing, and various others.

To work and utilise scripts in this folder you will first need to clone the folder into your local machine. To do so, please follow the steps below:

RepositoryName="Name of the repository from github account" 
#fmri_data_analysis_pipelines in this case

cd ~/Desktop 
git clone https://gitlab.tuebingen.mpg.de/njain/fmri_data_analysis_pipelines.git
cd ~/Desktop/$RepositoryName
open fMRIAnalysis.sh

This will start analysing data in the terminal/ console. Please note this works on UNIX based systems such as LINUX or MAC. If you want to run in the Windows based platform please either download Linux Subsystem for Windows or either you can get Neurodesk. Please find links below:

• WSL
• Neurodesk

Step 1: Analysing and storing data on server

Conducting data analysis on a local machine and subsequently transferring the analyzed data to a server can present several challenges, including the risk of infrequent data updates. This can lead to discrepancies in the analyzed data, resulting in inconsistencies in the information accessible to all users. The first goal of this data analysis is to locate data on the shared server and then prepare it for further analysis. This data can be called temporarily on either local machine or any other machine that you would like to use for analysis. Once you call the data, run command then the next step is to push back data on the server. In this script you will find following variables that you can set to your choice

• Raw_Data_Path="$PATH_for_raw_data_to_be_analysed"

• Analysed_Data_Path="$PATH_where_analysed_data_can_be_stored"

Step 2: Creating a folder where the analysed data stays

In the first inner for loop, specify the run numbers you wish to analyze, regardless of whether they are structural or functional runs, as the later part of the script will handle this distinction automatically. We utilize a function called "CHECK_FILE_EXISTENCE" to verify the existence of the subfolder for the analyzed data. If the subfolder does not exist, the function creates one in the main analyzed data folder using the naming convention "RunNumber_SequenceName" to facilitate easy navigation back to the folder.

Step 3: Separating Structural and Functional Runs from all the data acquired

We then extract "No of Repetitions" and Sequence Name form the methods file generated by the scanner. By Convention, a file with only 1 repetition is labelled as structural file where as files with more than one run are sent for further analysis to make sure if these are test runs or actual fMRI scans. By comparing the number of repetitions needed and the number of repetitions actually acquired, we can estimate if the scan is a functional run or test run.

Step 4: Standard Preprocessing Steps

• Convert to NIFTI Use brkraw to convert Bruker format into NIFTI format. There are many other toolboxes that can help with this but brkraw is currently supported and active so prefer to use it.

• brkraw It still uses some libraries that require older versions of python, in this case you can install miniconda3 environment and then

• Check/ Perform Reorientation Correct orientation is critical for co-registration to template. Wrong orientation will lead to wrong co-registration. Use fslview/fsleyes or MRIcro/MRIcroGL to check the orientation of the brain. You can check orientation using the following command

fsleyes $filename

Futher commands for indepth use of FSLEYES can be found on the following website

• FSLEYES CLI

• Despiking

Movement can induce artifacts that cause spikes in the data, leading to false signal changes. To address this, we use despiking techniques with either FSL or AFNI. Despiking can identify and eliminate a broad spectrum of these artifacts, which are otherwise difficult to address through standard preprocessing methods such as linear regression.

Note: It is always good to check if your data needs despiking or not. If there are not significant spikes then this method may not be needed.

3dToutcount -automask -fraction -polort 3 -legendre $1 > spikecountTC.1D

• Motion Correction

Although motion is not typically expected in anesthetized animals, motion-corrected images may be preferred for analysis if there is "motion" induced by field drift or respiration. Motion parameters can capture physiological noise and thus can be used as nuisance regressors.

3dvolreg -base $MiddleVolume -Fourier -zpad 1 -1Dfile motion.1D -1Dmatrix_save mat_vr.aff12.1D -prefix rG1_fsl $InputData

• Spatial Smoothing

Spatial smoothing involves averaging data points with their neighboring points. This process acts as a low-pass filter, removing high-frequency components of the signal while enhancing low-frequency components. Consequently, the sharp "edges" of the images become blurred, and spatial correlation within the data is increased. typical fMRI use Gaussian smoothing kernel FWHM of 1-3 pixels. Three cases can be considered:

1. For minimal smoothing in high-res study, 1 pixel size is recommended.
2. To make data isotropic, can also use kernel size the same as the pixel size in the dimension of the lowest resolution (eg, slice direction).
3. If data is noisy, 3 pixels can be considered.

NOTE: FSL use sigma not FWHM. Calculate smoothing kernel using sigma = FWHM / 2.3548 --> 0.25mm → 10x = 2.5mm à use 2.5/2.3548 = 1.0166 --> 0.3mm → 10x à use 1.274 --> 0.25mm → 20x = 5mm à use 2.1233226

fslmaths rG1_fsl.nii.gz -kernel gauss 0.212 -fmean sG1_fsl.nii.gz

• Activation Maps

• Percent Signal Change

Authors and acknowledgment

Naman Jain (designed scripts, functions, acquired data, experimental pipeline, written README.md)