| T O P I C R E V I E W |
| dvsmith |
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.
|
| 15 L A T E S T R E P L I E S (Newest First) |
| charles.michelich |
Posted - Feb 09 2010 : 10:49:32 PM
quote:
Originally posted by syam.gadde
Unfortunately, the (7001,*) fields don't exist in the DICOM we are getting from our MR 750. :-(
I did some digging and found out that these fields are only populated when you save raw data from the raw file manager as DICOM file. Therefore, this won't help determine the acquisition order on standard reconstructed images. |
| dvsmith |
Posted - Feb 09 2010 : 10:57:35 AM
Ah, ok... I'll just hold off for a little bit then. Thanks for looking into this!
David
|
| syam.gadde |
Posted - Feb 09 2010 : 10:57:18 AM
For Duke sequences, the slice order field in the .bxh file should show you the same numbers as the slice-in-pass field. Consider any BXH file sliceorder fields you have before reorientation to be correct. printpfileheader.pl does print out the slice table (including the slice-in-pass field). The orientation of the data is also in there, but is probably easier to see by looking at the already extracted <direction> fields in the .bxh file. The tool "dumpheader file.bxh" will show you the three-letter code corresponding to the current orientation.
I've basically got bxhreorient, and extraction of slice order to an FSL-style slice order file, working, but I wanted to test it a little more before releasing it. I have not implemented writing slice order to the NIFTI file, but that's probably not crucial right now.
What we don't have as of yet is automated P-file transfer for GE sequences (i.e. those that come off as DICOM). But if you are using BIAC sequences with P-files, we should have a solution for reoriented data working soon. |
| tharsh |
Posted - Feb 09 2010 : 10:53:53 AM
I think it would actually work, but I don't have data available right now where I know for sure which way things were defined...
|
| dvsmith |
Posted - Feb 09 2010 : 10:43:42 AM
Thanks so much for helping with this.
Before we get a final fix implemented, is there any way for me to check my data now? I assume Todd's post didn't pan out (quoted below), but assuming that works, I could write some something that uses it to check my data.
quote:
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...
Alternatively, is there anything in the current pfile that could be used to check orientation and slice order/axis/direction? A few months ago we noticed that disdaqs weren't being recorded correctly on some scans, and Syam provided a script that read the pfiles (printpfileheader.pl) allowed me to extract certain parts of that file to ascertain whether a scan included disdaqs despite not recording them in the bxh file. I assume this can't be used for a similar purpose here? I'm just trying to figure out if I should shelf my analyses for a little bit and work on other stuff.
Thanks again for all your help!
Cheers,
David
|
| syam.gadde |
Posted - Feb 08 2010 : 4:08:32 PM
Unfortunately, the (7001,*) fields don't exist in the DICOM we are getting from our MR 750. :-( |
| syam.gadde |
Posted - Feb 07 2010 : 8:29:37 PM
Hi Chuck,
How did I miss that? It's good to have friends in high places. :-)
|
| charles.michelich |
Posted - Feb 07 2010 : 12:56:31 PM
quote:
Originally posted by syam.gadde
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.
Sections of the P-file header are stored in the GEMS_MR_RAW_01 section of the DICOM header. You can find more info under the (7001,XXXX) tags in the GE MRI DICOM conformance statements |
| dvsmith |
Posted - Feb 04 2010 : 10:28:15 PM
In the event that reorientation does actually change the slice axis, I would suggest also displaying a warning that the user should no longer apply slice timing correction to the re-oriented file (assuming STC won't be done properly in these cases).
I was hopeful that one viable option for cases like this would be to do all the pre-stats stuff and then reorient the file (possibly with fslswapdim) to get everything into LAS. However, it appears as though this approach does not avoid the problem Syam mentioned earlier (quoted below for reference).
quote:
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.
(This appears to happen even when you just do pre-stats; i.e., no registration.) |
| syam.gadde |
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. |
| dvsmith |
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. |
| dvsmith |
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... |
| syam.gadde |
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 |
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 |
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). |
|
|
