| Author |
 Topic  |
|
|
vvs4
Junior Member
USA
40 Posts |
 Posted - Feb 21 2010 : 2:51:44 PM
|
Hi,
I am starting to preprocess some of our early functional runs, and after using bxhreorient to fix the orientation and bxh2analyze to make a nifti, upon trying to open my image in fslview, I get the error that "the image type is not supported." I did the exact same process for our anatomicals, and it worked fine! I double checked the BIAC wiki and Richard Yaxley's PDF about Preprocessing, but couldn't find anything to give me insight about this error. Here is the info from the functional after reorientation and such:
sizeof_hdr 348
data_type UINT16
dim0 4
dim1 64
dim2 64
dim3 34
dim4 172
dim5 1
dim6 1
dim7 1
vox_units mm
time_units ms
datatype 512
nbyper 2
bitpix 16
pixdim0 0.0000000000
pixdim1 3.7500000000
pixdim2 3.7500000000
pixdim3 3.9999990463
pixdim4 2000.0000000000
pixdim5 0.0000000000
pixdim6 0.0000000000
pixdim7 0.0000000000
vox_offset 0
cal_max 0.0000
cal_min 0.0000
scl_slope 0.000000
scl_inter 0.000000
phase_dim 1
freq_dim 0
slice_dim 3
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.712194 0.566552 -93.937790
qto_xyz:3 -0.000000 -0.531142 3.959673 -30.791872
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.712196 0.566563 -93.937790
sto_xyz:3 0.000000 -0.531131 3.959671 -30.791872
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 2
descrip
aux_file
Are we acquiring it incorrectly on the scanner? It would be great to figure this out promptly, in the case that our functionals are being acquired incorrectly.
Best,
Vanessa |
-Vanessa |
|
|
syam.gadde
BIAC Staff
USA
421 Posts |
Posted - Feb 21 2010 : 8:38:07 PM
|
Your NIFTI header indicates UINT16 (unsigned 16-bit integer). Is this data from BIAC or somewhere else? All our data typically starts out with signed 16-bit integers.
Anyway, FSL doesn't support all the NIFTI data types, only the ones that were originally supported by ANALYZE 7.5 (i.e. INT16 rather than UINT16). If you want to use these NIFTI files with FSL, you can try to add the --preferanalyzetypes option. So, for example:bxh2analyze --preferanalyzetypes --niigz input.bxh outputprefix
|
 |
|
|
vvs4
Junior Member
USA
40 Posts |
Posted - Feb 21 2010 : 8:51:14 PM
|
Hi Syam,
This data is indeed from BIAC - BIAC5 to be exact!
I tried the command that you specified:
bxh2analyze --preferanalyzetypes --niigz reoriented_run04.bxh test.bxh
and got the following message:
Trying int16 data type (instead of input uint16 datatype).
Detected overflow -- going back to original data type uint16.
The strange thing is that it says that it goes back to uint16, but actually produces a compressed nifti that is of type int16 (at least that's what fslhd says.)
When I try to open it in fslview, it works this time! I will try using this image for analysis tomorrow - I'm not completely comfortable with the multiple error messages down the path to get this nifti.
And I wonder, why is BIAC5 spitting out a UINT16? Is there something wrong with the setup of our functional runs?
Best,
Vanessa |
-Vanessa |
|
|
|
syam.gadde
BIAC Staff
USA
421 Posts |
Posted - Feb 21 2010 : 9:07:50 PM
|
I think I will have to take a look at the original data. If you could mail me offline the exam number and experiment name, I'll take a look.
|
|
|
|
jim.voyvodic
BIAC Faculty
138 Posts |
Posted - Feb 21 2010 : 9:22:20 PM
|
The functional runs are SENSE spiral on BIAC5 and the BXH header created with the Analyze format files says "uint16".
Presumably this is an arbitrary decision in the Recon program. Data values are always positive so storing unsigned gives a greater range. But the scale factor is also arbitrary so the recon can just as easily store them as "int16" and make sure the values stay in range.
I am amazed to see that the recon is creating old-style volume format data files! Surely nobody wants that format anymore. Why don't we automatically create NIfTI-type 4D files?
Jim |
|
|
|
petty
BIAC Staff
USA
453 Posts |
Posted - Feb 22 2010 : 09:00:51 AM
|
I was told to create the SENSE data specifically as uint16 to prevent the overflows that we were seeing a while back.
Also, anyone can get their data in NIIGZ format by default just by sending me an email directly.
I added some new options for experimenter preferences a while back. (as announced here: http://www.biac.duke.edu/forums/topic.asp?TOPIC_ID=1346) |
|
|
|
syam.gadde
BIAC Staff
USA
421 Posts |
Posted - Feb 22 2010 : 09:22:12 AM
|
Aha, I forgot about the uint16 SENSE recon (due to overflow with int16). I guess we didn't realize the consequences on using the data with FSL. Well then. If we have the pipeline make the NIFTI files directly, we will need to choose whether it should make them, say, single-precision floats or something. The file size will be bigger, but it will be readable by FSL tools. Hopefully we can discuss this at our tech meeting today.
In any case, I will add some options to bxh2analyze to "upgrade" to the next ANALYZE 7.5-supported data type if overflow is detected. |
|
|
|
vvs4
Junior Member
USA
40 Posts |
Posted - Feb 22 2010 : 09:30:18 AM
|
| Is there any reason we can't get dicom images for the functional data? We have dicoms for the anatomical. |
-Vanessa |
|
|
|
syam.gadde
BIAC Staff
USA
421 Posts |
Posted - Feb 22 2010 : 09:32:32 AM
|
| Only images from stock GE sequences come off the scanner as DICOM, unfortunately. Your anatomicals are using GE sequences, which is why they come off as DICOM. Other sequences (like any of the spiral sequences) can only come off as P-files, which the daemon then reconstructs to image files. |
|
|
|
dvsmith
Advanced Member
USA
218 Posts |
Posted - Feb 22 2010 : 11:01:22 PM
|
I also have SENSE data from BIAC5 (datatype = UINT16), but I haven't noticed anything weird with FEAT (or any of the tools related to FEAT). It seems to be working OK for us. Here are two example headers from the converted raw data (bxreorient then bxh2analyze) -- i.e., the inputs for two successful FEAT analyses...
Header 1
David-V-Smiths-MacBook-Pro:SequenceTest dvsmith$ fslhd run1.nii.gz
filename run1.nii.gz
sizeof_hdr 348
data_type UINT16
dim0 4
dim1 64
dim2 64
dim3 37
dim4 476
dim5 1
dim6 1
dim7 1
vox_units mm
time_units ms
datatype 512
nbyper 2
bitpix 16
pixdim0 0.0000000000
pixdim1 3.7969000340
pixdim2 3.7969000340
pixdim3 3.8000001907
pixdim4 1580.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 1
freq_dim 0
slice_dim 3
slice_name Unknown
slice_code 0
slice_start 0
slice_end 0
slice_duration 42.702702
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.796900 0.000000 -0.000000 113.101547
qto_xyz:2 0.000000 3.794768 0.127338 -96.682281
qto_xyz:3 -0.000000 -0.127234 3.797866 -48.895870
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.796900 0.000000 0.000000 113.101547
sto_xyz:2 0.000000 3.794768 0.127342 -96.682281
sto_xyz:3 0.000000 -0.127230 3.797866 -48.895870
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
Header 2
David-V-Smiths-MacBook-Pro:SequenceTest dvsmith$ fslhd run3
filename run3.nii.gz
sizeof_hdr 348
data_type UINT16
dim0 4
dim1 128
dim2 128
dim3 32
dim4 380
dim5 1
dim6 1
dim7 1
vox_units mm
time_units ms
datatype 512
nbyper 2
bitpix 16
pixdim0 0.0000000000
pixdim1 1.7500000000
pixdim2 1.7500000000
pixdim3 1.8000006676
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 1
freq_dim 0
slice_dim 3
slice_name Unknown
slice_code 0
slice_start 0
slice_end 0
slice_duration 62.500000
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 -1.750000 0.000000 -0.000000 104.625000
qto_xyz:2 0.000000 1.748901 0.063785 -86.432243
qto_xyz:3 -0.000000 -0.062013 1.798870 -14.112603
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 -1.750000 0.000000 0.000000 104.625000
sto_xyz:2 0.000000 1.748901 0.063792 -86.432243
sto_xyz:3 0.000000 -0.062007 1.798870 -14.112603
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
I have no idea why we're not seeing the error. It looks like there are a few discrepancies between some of the values in our headers (e.g., vox_offset has a value for us and Vanessa has a 0). Additionally, we have different values for the file_code field. I'm not sure what either of these fields are, but I suspect they should be the same across sequences. It looks like one other different field is the file_type, which might be the critical difference.
In case it helps, here are examples to my typical calls to bxhreorient and bxh2analyze:
bxhreorient --orientation LAS run*${RUNS}.bxh reoriented_run${RUNS}.bxh
bxh2analyze -s -b --niigz reoriented_run${RUNS}.bxh ${MOUTDIR}/run${R1}
David
|
Edited by - dvsmith on Feb 22 2010 11:13:03 PM |
|
|
|
dvsmith
Advanced Member
USA
218 Posts |
Posted - Feb 22 2010 : 11:37:33 PM
|
I spoke too soon... While FEAT seems to work OK, I cannot open the images with FSLview. It just produces segmentation faults. I can convert the images using fslmaths and FSLview works then. Maybe this is just a "feature" of FSLview?
Converting to INT:
[smith@node4 SequenceTest]$ fslmaths run1 run1_int -odt int
[smith@node4 SequenceTest]$ fslhd run1_int.nii.gz
filename run1_int.nii.gz
sizeof_hdr 348
data_type INT32
dim0 4
dim1 64
dim2 64
dim3 37
dim4 476
dim5 1
dim6 1
dim7 1
vox_units mm
time_units s
datatype 8
nbyper 4
bitpix 32
pixdim0 0.0000000000
pixdim1 3.7969000340
pixdim2 3.7969000340
pixdim3 3.8000001907
pixdim4 1580.0000000000
pixdim5 0.0000000000
pixdim6 0.0000000000
pixdim7 0.0000000000
vox_offset 352
cal_max 55162.0000
cal_min 0.0000
scl_slope 1.000000
scl_inter 0.000000
phase_dim 1
freq_dim 0
slice_dim 3
slice_name Unknown
slice_code 0
slice_start 0
slice_end 0
slice_duration 42.702702
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.796900 0.000000 -0.000000 113.101547
qto_xyz:2 0.000000 3.794768 0.127338 -96.682281
qto_xyz:3 -0.000000 -0.127234 3.797866 -48.895870
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.796900 0.000000 0.000000 113.101547
sto_xyz:2 0.000000 3.794768 0.127342 -96.682281
sto_xyz:3 0.000000 -0.127230 3.797866 -48.895870
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 FSL4.0
aux_file
Converting to FLOAT:
[smith@node4 SequenceTest]$ fslmaths run1 run1_float -odt float
[smith@node4 SequenceTest]$ fslhd run1_float.nii.gz
filename run1_float.nii.gz
sizeof_hdr 348
data_type FLOAT32
dim0 4
dim1 64
dim2 64
dim3 37
dim4 476
dim5 1
dim6 1
dim7 1
vox_units mm
time_units s
datatype 16
nbyper 4
bitpix 32
pixdim0 0.0000000000
pixdim1 3.7969000340
pixdim2 3.7969000340
pixdim3 3.8000001907
pixdim4 1580.0000000000
pixdim5 0.0000000000
pixdim6 0.0000000000
pixdim7 0.0000000000
vox_offset 352
cal_max 55162.0000
cal_min 0.0000
scl_slope 1.000000
scl_inter 0.000000
phase_dim 1
freq_dim 0
slice_dim 3
slice_name Unknown
slice_code 0
slice_start 0
slice_end 0
slice_duration 42.702702
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.796900 0.000000 -0.000000 113.101547
qto_xyz:2 0.000000 3.794768 0.127338 -96.682281
qto_xyz:3 -0.000000 -0.127234 3.797866 -48.895870
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.796900 0.000000 0.000000 113.101547
sto_xyz:2 0.000000 3.794768 0.127342 -96.682281
sto_xyz:3 0.000000 -0.127230 3.797866 -48.895870
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 FSL4.0
aux_file
One odd discrepancy between these headers and the old headers is the time_units field. For some reason, FSL converted it to seconds. I don't think this really affects anything in FEAT since you have to specify the TR in seconds (mainly for slice timing correction and scan length) -- but it's still weird...
David
|
Edited by - dvsmith on Feb 22 2010 11:43:15 PM |
|
|
|
syam.gadde
BIAC Staff
USA
421 Posts |
Posted - Mar 25 2010 : 1:00:07 PM
|
Just wrapping up some loose threads. As was announced by Chris in a separate forum post a while ago, new SENSE data is now being written out as int16, with voxel values at half their previous values. Details here:
http://www.biac.duke.edu/forums/topic.asp?TOPIC_ID=1400
In addition, if overflow is detected, the new version of bxh2analyze will now automatically upgrade to the next ANALYZE 7.5-supported type if you specify the --analyzetypes option, which means any FSL tool should be able to read it. This version will be running on the new cluster, when it is unveiled. |
|
|
| |
Topic |
|
"Data Type Not Supported" after using BXH Tools
