| Author |
 Topic  |
|
dvsmith
Advanced Member
USA
218 Posts |
 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.) |
 |
|
|
charles.michelich
BIAC Alum
USA
183 Posts |
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 |
Edited by - charles.michelich on Feb 07 2010 12:57:56 PM |
|
|
|
syam.gadde
BIAC Staff
USA
421 Posts |
Posted - Feb 07 2010 : 8:29:37 PM
|
Hi Chuck,
How did I miss that? It's good to have friends in high places. :-)
|
|
|
|
syam.gadde
BIAC Staff
USA
421 Posts |
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. :-( |
|
|
|
dvsmith
Advanced Member
USA
218 Posts |
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
|
|
|
|
tharsh
BIAC Faculty
USA
76 Posts |
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...
|
***********************
Todd Harshbarger
Instructor
BIAC, Duke University
todd.harshbarger@duke.edu
*********************** |
|
|
|
syam.gadde
BIAC Staff
USA
421 Posts |
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. |
|
|
|
dvsmith
Advanced Member
USA
218 Posts |
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
|
|
|
|
charles.michelich
BIAC Alum
USA
183 Posts |
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. |
|
|
|
Topic |
|
bxhreorient and slice timing correction
