Yes, it is not recommended to deoblique the EPI. Are the reverse blip volumes 78 slices because they were deobliqued as well? It seems like they should all have 56 slices.
-rick
They reversed blip has 78 slices because it was deobliqued. The nondeobliqued image does have 56 slices.
If I DON'T deoblique any of the images in question and run the afni_proc.py command, I get an error:
** error: reverse blip obliquity (0) does not match EPI (1)
** invalid block : blip
Hi, Matthew-
Deobliquing can be done in a couple different ways:
- one where data is not regridded (so no blurring happens), and instead the obliquity transform is just purged (
3drefit -deoblique ...) - one where data is regridding (so blurring happens), because the obliquity transform is applied (
3dWarp -deoblique ...) - one where data is not regridded (so no blurring happens), and the obliquity transform is purged but the coordinate origin location (x,y,z)=(0,0,0) is preserved (
adjunct_deob_around_origin ...)
If the grid changes, then probably 3dWarp was used. We typically don't want to blur the data.
On your blip datasets in question, they should have the same grid as each other and as the input EPI. This can be checked with:
3dinfo -same_all_grid -prefix DSET1 DSET2 [DSET3 ...]
What is the output of that? If it isn't all 1s (each row shows the output of matching or not for a particular grid property, where 1=match; see the list in the 3dinfo help file), then some grid property is not matching. Why it doesn't should be tracked down.
--pt
Hi Paul,
The output of the 3dinfo command is:
NO-DSET NO-DSET NO-DSET NO-DSET NO-DSET NO-DSET
0 0 0 0 0 sub-xxxx_ses-MRI1_task-rest_echo-1_part-mag_nordicNoNoise_bold.nii.gz
** AFNI converts NIFTI_datatype=4 (INT16) in file /home/hoptman/neurodesktop-storage/TSIB/subjects/sub-xxxxx/AP_prescan_rest_009/TSIB_xxxx_AP_prescan_rest_9_ph.nii to FLOAT32
Warnings of this type will be muted for this session.
Set AFNI_NIFTI_TYPE_WARN to YES to see them all, NO to see none.
0 0 0 0 0 TSIB_xxxx_AP_prescan_rest_9_ph.nii
0 0 0 0 0 TSIB_xxxx_PA_prescan_rest_12_ph.nii
What would be the best way to investigate this, or at least to fix it? They're all listed as 90x90x56 slices in RPI orientation. Do I need to align the centers?
Thanks,
Matt
Hi, Matt-
What was your exact comand? There should be none of the NO-DSET outputs---that means a filename/path is incorrect for one fo the dsets. And I think that is further throwing off the check for same-grid-ness.
--pt
Hi Paul,
The "-prefix" flag seemed to have screwed things up. I had entered:
3dinfo -same_all_grid -prefix regrid sub-xxxx_ses-MRI1_task-rest_echo-1_part-mag_nordicNoNoise_bold.nii.gz /home/hoptman/neurodesktop-storage/TSIB/subjects/sub-xxxx/AP_prescan_rest_009/TSIB_xxxx_AP_prescan_rest_9_ph.nii /home/hoptman/neurodesktop-storage/TSIB/subjects/sub-xxxx/PA_prescan_rest_012/TSIB_xxxx_PA_prescan_rest_12_ph.nii
When I omit "-prefix" or the "regrid", I get all 1s. But now I'm not sure why I get the error I saw initiallly.
Hi, Matt-
I don't know what "regrid" is doing there? That is not a keyword or command to use, that is likely the problem. Using "-prefix" helps show which row corresponds to which dset, and I would recommend using it.
So, if running (note, the first one here has no path, unlike the other two?):
3dinfo -same_all_grid -prefix \
sub-xxxx_ses-MRI1_task-rest_echo-1_part-mag_nordicNoNoise_bold.nii.gz \
/home/hoptman/neurodesktop-storage/TSIB/subjects/sub-xxxx/AP_prescan_rest_009/TSIB_xxxx_AP_prescan_rest_9_ph.nii \
/home/hoptman/neurodesktop-storage/TSIB/subjects/sub-xxxx/PA_prescan_rest_012/TSIB_xxxx_PA_prescan_rest_12_ph.nii
... shows three rows of all five 1s, you should be in good shape with using these dsets.
--pt
Hi Paul,
Yes, I figured that out. I added the "regrid" because when I saw "prefix", I thought it needed a dataset name. When I take "regrid" out, I get 3 rows of all 5 1s.
I do see a warning of:
- AFNI converts NIFTI_datatype=4 (INT16) in file /home/hoptman/neurodesktop-storage/TSIB/subjects/sub-xxxx/AP_prescan_rest_009/TSIB_xxx_AP_prescan_rest_9_ph.nii to FLOAT2
Warnings of this type will be muted for this session.
But I don't see that that should matter.
However, I'm now back to the error:
** error: reverse blip obliquity (0) does not match EPI (1)
** invalid block : blip
Hi Matt,
Something is odd there. The check for obliquity in afni_proc.py is running "3dinfo -is_oblique" on the dataset. The output states that the reverse blip dataset is not oblique, but it should be. Can you be sure of that for the datasets given to afni_proc.py?
Thanks,
-rick
Hi Rick,
Good catch. If I run the 3dinfo command with the -is_oblique flag on the original dataset, it comes out as oblique (value of 1).
I'm wondering if it's something simpler. In the script, for the file name, I had
"${p1}/subjects/${subj}/PA_prescan_rest_012/TSIB_xxxx_PA_prescan_rest_12_ph.nii.gz[0]" \
When I change this to just single quotes around the [0] only, the command runs.
Thanks,
Matt
Note that if the name were something like ".../{$subj}/.../DSET[0]", the {} characters would end up in the result around 'subj'. Perhaps it was something like that?
-rick
It must have been. In the example in afni_proc.py, it has single quotes around the entire blip forward or blip reverse filename. I had gotten the file from someone else, which is why I saw the double quotes.
Thanks again!
Matt
One other question. I saw a brief discussion about this, but no specific advice about what to do with data that have already been collected. In the absence of good respiration data (loose belt), can the respiration time series be omitted? I think physio_calc.py will run without it.
Thanks again!!
Yes, unlike the earlier RetroTS.py, physio_calc.py can handle cardiac or respiratory data individually, as well as simultaneously.
--pt
Actually, I believe RetroTS.py could also handle only one of resp or card data, too, it was just not commonly done. So the few times it popped up, we were unsure, and it took a little time to figure out how to do it.
-rick
Thanks to both of you!