| Author |
 Topic  |
|
dvsmith
Advanced Member
USA
218 Posts |
 Posted - Feb 02 2010 : 10:41:16 AM
|
Hi all,
McKell and I were curious about bxhreorient and slice timing correction. I know we use bxhreorient to force everything into LAS convention, most likely because we get a mix of orientations depending on how exactly the techs define the FOV (cf. https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0911&L=FSL&D=0&P=41537). The question (and concern) is how exactly this orientation issue relates to the order in which the slices are acquired. For example, is slice 1 always the most inferior slice? Or could we have cases where slice 1 is actually the most superior slice? If so, does bxhreorient also fix this? If we have some subjects whose data are already in LAS and others that are in RAS, can we be certain that the slice ordering is consistent across subjects?
On a related note, can someone describe how bxhreorient differs from dcm2nii, where you can choose to orient to the nearest orthogonal plane (at least for anatomical data). According to this webpage (http://www.cabiatl.com/mricro/mricron/dcm2nii.html), it seems like reorienting might be a bad idea in general when it comes to fMRI data -- mainly because it disrupts slice timing correction. This makes sense.
I realize slice timing correction is one of those things that, for various reasons, some people do and some people don't do; however, it would be important to know whether the data is appropriate for such corrections for those of us who want to use it. Perhaps some solutions would be to stop doing bxhreorient on the functional data (use Full search to account for potential registration issues that might arise) and start using slice order files for the slice timing correction.
Thanks,
David
PS: I figured the forums were better than personal emails since others could potentially benefit from this information.
|
|
|
syam.gadde
BIAC Staff
USA
421 Posts |
Posted - Feb 02 2010 : 11:42:27 AM
|
To answer your second (easier) question first, bxhreorient only flips image (voxel) data or rotates by multiples of 90 degrees. So when you tell it to go to LAS orientation, it does any necessary flips/90-degree rotations to the image data (and negates some orientation vector components and adjusts the "origin" fields) to get it closest to the requested orientation. I think this is equivalent to reordering and/or negating the upper 3 rows of an affine identity matrix.
(Edited above: bxhreorient does more than flips)
In the case where bxhreorient (or any other re-orientation tool for that matter) flips the slice axis, it can potentially change the slice acquisition order/slice timing values you need to give to analysis tools. However, cases like RAS->LAS, RAI->LAI don't change the third letter and so don't affect the slice axis.
The key is knowing what the actual slice acquisition order was for an scan with respect to brain location (i.e. sequential starting from the bottom of the brain, interleaved starting from the top slice of the brain, etc.). If you know that (at scan time -- GE doesn't seem to give you any way to verify this in the image headers after the fact) and if you know the orientation of data on disk, you can calculate the slice timing or indices that you need to give to FSL or other tools. So if you reorient your sequential (from the bottom of the brain) data, the bottom slice of the brain would always have been the the first slice acquired, but might now be in a different order on disk. This can be tricky, especially in the case of interleaved data and odd numbers of slices.
That link you pointed to is interesting -- it says the orientation of the image can change depending on how the tech drags the mouse to define the FOV. I assume the slice acquisition order (with respect to the brain) doesn't change?
Note that if you don't reorient your data to a FSL-blessed orientation (one of the 24 orientations FSL labels as radiological), it will helpfully flip the X axis for you and not adjust the orientation vectors in the headers. So beware.
|
Edited by - syam.gadde on Feb 03 2010 2:40:46 PM |
 |
|
|
dvsmith
Advanced Member
USA
218 Posts |
Posted - Feb 02 2010 : 2:23:23 PM
|
Thanks, Syam. We're mostly worried about conversions and aspects of the data acquisition process that could disrupt slice-timing correction. The main concern would be cases where a subject was acquired in RAI format and then we convert it to LAS -- thus changing the slice order axis.
We assume (and I'm trying to test) whether the slice acquisition order can change depending on how the tech drags the mouse to define the FOV. This would be the biggest concern. To test this, I'm re-converting all of our data on Imagene.01 and then running fslhd to check the qform and sform fields on the data that has not been reoriented with bxhreorient. Presumably, all subjects should be "Inferior-to-Superior" in the qform_zorient and sform_zorient fields. I don't know much about these fields, so it would be great if someone could correct me or help out, if what I'm doing is wrong. I've already discovered several examples of the sform_zorient field being Superior-to-Inferior instead of Inferior-to-Superior; however, I don't think the the qform_zorient field is oriented the same way for these subjects/runs.
Has anyone used slice order files? FSL provides 6 options for slice timing correction: 1) none, 2) regular up, 3) regular down, 4) interleaved, 5) custom slice order file, 6) custom slice timing file. All of our data are acquired using an interleaved acquisition. I guess the key consideration here is slice #1...
Thanks,
David
|
|
|
|
tharsh
BIAC Faculty
USA
76 Posts |
Posted - Feb 02 2010 : 2:45:01 PM
|
When I convert the pfile header to a text file (using rdgehdr, program I found somewhere on the web), within it is a list of the slices, three points describing their positions, as well as a note "slice in pass = #", where number appears to be the slice acquisition order. I'm not sure off-hand if this is really correct (it is certainly interleaved as it should be). I may have some data already with slices described both in a superior to inferior (tech dragging slices down) and I-S (dragging up) orientations. I'll have to see if I can find them to compare this field...
|
***********************
Todd Harshbarger
Instructor
BIAC, Duke University
todd.harshbarger@duke.edu
*********************** |
|
|
|
dvsmith
Advanced Member
USA
218 Posts |
Posted - Feb 02 2010 : 2:45:11 PM
|
Correction: I haven't found examples of "I to S" getting flipped with "S to I" (yet). My script that was checking this had a bug, but it's currently still running.
|
|
|
|
syam.gadde
BIAC Staff
USA
421 Posts |
Posted - Feb 02 2010 : 5:37:24 PM
|
| Todd, that's great. I do look at the P-file slice table that has that field (slice in pass), but didn't realize that was related to slice acquisition order. Unfortunately, this doesn't seem to get transferred to the DICOM header, which is a problem for GE sequences which don't by default transfer P-file headers. I think there was a proposal to somehow grab P-file headers even for sequences that produce DICOM. If we can finagle a way to do that, we could extract slice order automatically into the .bxh header *and* that field can be adjusted automatically if needed with bxhreorient. |
|
|
|
dvsmith
Advanced Member
USA
218 Posts |
Posted - Feb 02 2010 : 7:03:51 PM
|
Thanks for the note, Todd. Determining whether the images were acquired I-S or S-I is the biggest concern, but then I'm not sure if FSL automatically accounts for this (e.g., if it can tell which slice is #1 and work appropriately without further direction -- but see link below). I can't find instances of S-I across 600+ scans in Imagene.01, but I'm just not sure if my script is extracting the right information to verify the acquisition direction. Again, I'm using fslhd, which prints out something like what I have below:
USING BXHREORIENT (ORIENTATION=LAS):
quote:
David-V-Smiths-MacBook-Pro:Framing dvsmith$ fslhd run1.nii.gz
filename run1.nii.gz
sizeof_hdr 348
data_type INT16
dim0 4
dim1 64
dim2 64
dim3 34
dim4 180
dim5 1
dim6 1
dim7 1
vox_units mm
time_units ms
datatype 4
nbyper 2
bitpix 16
pixdim0 0.0000000000
pixdim1 3.7500000000
pixdim2 3.7500000000
pixdim3 3.8002080917
pixdim4 2000.0000000000
pixdim5 0.0000000000
pixdim6 0.0000000000
pixdim7 0.0000000000
vox_offset 352
cal_max 0.0000
cal_min 0.0000
scl_slope 0.000000
scl_inter 0.000000
phase_dim 0
freq_dim 0
slice_dim 0
slice_name Unknown
slice_code 0
slice_start 0
slice_end 0
slice_duration 58.823528
time_offset 0.000000
intent Unknown
intent_code 0
intent_name
intent_p1 0.000000
intent_p2 0.000000
intent_p3 0.000000
qform_name Scanner Anat
qform_code 1
qto_xyz:1 -3.750000 0.000000 -0.000000 118.125000
qto_xyz:2 0.000000 3.743822 0.218051 -120.130898
qto_xyz:3 -0.000000 -0.215170 3.793947 -4.626168
qto_xyz:4 0.000000 0.000000 0.000000 1.000000
qform_xorient Right-to-Left
qform_yorient Posterior-to-Anterior
qform_zorient Inferior-to-Superior
sform_name Scanner Anat
sform_code 1
sto_xyz:1 -3.750000 0.000000 0.000000 118.125000
sto_xyz:2 0.000000 3.743829 0.218182 -120.130898
sto_xyz:3 0.000000 -0.215042 3.793940 -4.626168
sto_xyz:4 0.000000 0.000000 0.000000 1.000000
sform_xorient Right-to-Left
sform_yorient Posterior-to-Anterior
sform_zorient Inferior-to-Superior
file_type NIFTI-1+
file_code 1
descrip
aux_file
NO BXHREORIENT:
quote:
David-V-Smiths-MacBook-Pro:Framing dvsmith$ fslhd run1_S-I_check.nii.gz
filename run1_S-I_check.nii.gz
sizeof_hdr 348
data_type INT16
dim0 4
dim1 64
dim2 64
dim3 34
dim4 180
dim5 1
dim6 1
dim7 1
vox_units mm
time_units ms
datatype 4
nbyper 2
bitpix 16
pixdim0 0.0000000000
pixdim1 3.7500000000
pixdim2 3.7500000000
pixdim3 3.8002080917
pixdim4 2000.0000000000
pixdim5 0.0000000000
pixdim6 0.0000000000
pixdim7 0.0000000000
vox_offset 352
cal_max 0.0000
cal_min 0.0000
scl_slope 0.000000
scl_inter 0.000000
phase_dim 0
freq_dim 0
slice_dim 0
slice_name Unknown
slice_code 0
slice_start 0
slice_end 0
slice_duration 58.823528
time_offset 0.000000
intent Unknown
intent_code 0
intent_name
intent_p1 0.000000
intent_p2 0.000000
intent_p3 0.000000
qform_name Scanner Anat
qform_code 1
qto_xyz:1 -3.750000 0.000000 0.000000 118.125000
qto_xyz:2 0.000000 -3.743822 0.218051 115.730324
qto_xyz:3 0.000000 0.215170 3.793947 -18.173792
qto_xyz:4 0.000000 0.000000 0.000000 1.000000
qform_xorient Right-to-Left
qform_yorient Anterior-to-Posterior
qform_zorient Inferior-to-Superior
sform_name Scanner Anat
sform_code 1
sto_xyz:1 -3.750000 0.000000 0.000000 118.125000
sto_xyz:2 0.000000 -3.743829 0.218182 115.730324
sto_xyz:3 0.000000 0.215042 3.793940 -18.173792
sto_xyz:4 0.000000 0.000000 0.000000 1.000000
sform_xorient Right-to-Left
sform_yorient Anterior-to-Posterior
sform_zorient Inferior-to-Superior
file_type NIFTI-1+
file_code 1
descrip
aux_file
CODE SNIPPET:
cd ${FOUTDIR}
fslhd run${R2}_S-I_check.nii.gz > temp_file.txt
SFORMZ=`grep 'sform_zorient' temp_file.txt | awk '{print $2}'`
QFORMZ=`grep 'qform_zorient' temp_file.txt | awk '{print $2}'`
if [ ! "$SFORMZ" == "Inferior-to-Superior" ]; then
echo ${FOUTDIR}/run${R2}_S-I_check >> ${EXPERIMENT}/Data/not_I_to_S_log.txt
fi
if [ ! "$SFORMZ" == "$QFORMZ" ]; then
echo ${FOUTDIR}/run${R2}_S-I_check >> ${EXPERIMENT}/Data/q_and_s_mismatch_log.txt
fi
SFORMX=`grep 'sform_xorient' temp_file.txt | awk '{print $2}'`
QFORMX=`grep 'qform_xorient' temp_file.txt | awk '{print $2}'`
if [ ! "$SFORMX" == "Right-to-Left" ]; then
echo ${FOUTDIR}/run${R2}_S-I_check >> ${EXPERIMENT}/Data/not_R_to_L_log.txt
fi
if [ ! "$SFORMX" == "$QFORMX" ]; then
echo ${FOUTDIR}/run${R2}_S-I_check >> ${EXPERIMENT}/Data/Xq_and_s_mismatch_log.txt
fi
I'm still a bit curious about what exactly our scanner is doing and whether slice timing could potentially be hurting our analyses. I dug up some old FSL posts that could hopefully shine light on the situation (or just future questions about this issue).
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0907&L=FSL&D=0&m=14217&P=54413 -- first slice is what FSLview registers as z=0
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0801&L=FSL&D=0&m=14217&P=83896 -- FSL recommends using temporal derivatives instead of STC, which seems odd for interleaved acquisitions
I am aware of the fact that people have been debating the pros and cons of STC for 10 years. :-) If we use it, we just want to be certain it's done correctly -- and it looks like FSL might not even care if the first slice is at the top or bottom since it just starts with z=0 and works from there. Maybe McKell can interject here?
|
|
|
|
dvsmith
Advanced Member
USA
218 Posts |
Posted - Feb 02 2010 : 7:21:27 PM
|
Syam, just noticed your post (didn't see before my last post). Anyway, that sounds great. The more information, the better.
Cheers,
David
|
|
|
|
syam.gadde
BIAC Staff
USA
421 Posts |
Posted - Feb 02 2010 : 8:23:13 PM
|
Unless the "slice_code" field is populated in the NIFTI header (and I'm not sure how this would be populated, though Todd's note gives us some hope for P-file acquisitions) tools like fslhd will only be able to tell you how the data is ordered on disk, but will not necessarily tell you what order those slices were acquired by the scanner (unless you know that the scanner always starts any image with the first acquired slice, though the thing about the FOV mouse drag changing the output orientation seems to make this unlikely; and despite that interleaved is another matter).
|
|
|
|
dvsmith
Advanced Member
USA
218 Posts |
Posted - Feb 02 2010 : 8:51:00 PM
|
| I was afraid of that... A few of the posts I saw warned against the way the data was stored on disk and how that related to information in the header. I was hopeful the information in the qform and sform would be enough, but I wasn't 100% sure about the information in these fields. Maybe we can get the "slice_code" field populated using Todd's information... |
|
|
|
syam.gadde
BIAC Staff
USA
421 Posts |
Posted - Feb 02 2010 : 8:53:00 PM
|
I remembered implementing the extraction of slice order from Siemens DICOM files, but I guess I completely forgot that I already implemented extracting the slice order into a "sliceorder" field for sequences that give you P-files (all BIAC-grown sequences) too.
I guess there's nothing stopping me from having bxh2analyze to populate the slice order fields in the NIFTI header, and also getting bxhreorient to do the right thing. One that's done, it should be very straightforward to get the right values to send to an FSL slice order file (even after reorienting). |
|
|
|
dvsmith
Advanced Member
USA
218 Posts |
Posted - Feb 02 2010 : 10:24:53 PM
|
| That would be great! Hopefully it's an easy fix. Once this is corrected, could we then extract the slice order from the reoriented bxh files? I know there's a slice order field in there right now, but, as you pointed out, it might not match the way the data were actually acquired. If we have confidence in these numbers after you update bxh2analyze (and if everyone is happy using FSL and slice timing correction), it would be great to have an option to output a slice order text with bxh2analyze/bxhreorient (i.e., single column text file with row 1 corresponding to the first slice acquired). |
|
|
|
syam.gadde
BIAC Staff
USA
421 Posts |
Posted - Feb 03 2010 : 07:51:43 AM
|
| If there is a sliceorder field in the original .bxh files, it should accurately represent the order in which the data was acquired using the indices of the slices as stored on disk. Once we have a fix for bxhreorient, the reoriented files (you may have to re-run bxhreorient) should also have the same. I don't remember if FSL slice order starts at index 0 or 1 for the first slice, but in any case, I can easily create something that extracts the appropriate slice order file for FSL, and fix bxh2analyze to populate the slice_order field in the NIFTI files (I don't know if FSL/slicetimer uses this yet). Stay tuned. |
|
|
|
dvsmith
Advanced Member
USA
218 Posts |
Posted - Feb 03 2010 : 09:19:53 AM
|
Thanks, Syam.
FSL's slicetimer treats the first slice as 1 (not 0), which is a little confusing since their other tools are refer to slice 1 as slice 0 (like their spatial index system). https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind06&L=FSL&D=0&m=2691&P=115373
And, as far as I know, FSL/slicetimer does not use any information from the slice fields in the NIFTI headers. I suspect they won't change this since they recommend using temporal derivatives in place of STC. To me, this seems odd for interleaved acquisitions since spatial smoothing would effectively average slices whose time course is separated by TR/2... |
|
|
|
dvsmith
Advanced Member
USA
218 Posts |
Posted - Feb 03 2010 : 6:06:42 PM
|
quote:
To answer your second (easier) question first, bxhreorient only flips image (voxel) data or rotates by multiples of 90 degrees. So when you tell it to go to LAS orientation, it does any necessary flips/90-degree rotations to the image data (and negates some orientation vector components and adjusts the "origin" fields) to get it closest to the requested orientation. I think this is equivalent to reordering and/or negating the upper 3 rows of an affine identity matrix.
(Edited above: bxhreorient does more than flips)
Thanks for the clarification, Syam. I was a little worried about rotations, but I think (though I'm not sure) that as long as the slice order remains valid (i.e., linked to the order in which the data were acquired), it should be OK. I think the bigger concern would be doing any rotations on DTI data (as Chris Rorden's web page suggested), but I think most people use dcm2nii for DTI data anyway. |
|
|
|
syam.gadde
BIAC Staff
USA
421 Posts |
Posted - Feb 03 2010 : 7:57:09 PM
|
| One issue, and perhaps the main one that people are worried about with regards to re-orientation and slice timing correction, is if the slice axis is changed (i.e. if you change between axial, coronal or sagittal orientations). Then tools won't be able to apply slice timing correction anymore because the slices that need to be corrected won't be in the 3rd dimension (the "slice" axis) anymore. So if the reorientation does change the slice axis, I will not update the sliceorder field -- I will remove it. In any case where the sliceorder field is updated or removed, I will retain the original value of sliceorder in another field with a different name, for reference. |
|
|
|
Topic |
|
bxhreorient and slice timing correction
