Hi,
That's great.
It is exactly what I was expecting, which means that everything is
working fine.
This image has a qform that is set (qform_name = Scanner Anat)
but no sform set (sform_name = Unknown). Hence the sform
values that you get from fslorient in this image are uninteresting
defaults - it is the qform that contains all the useful info.
After running fslswapdim the qform gets modified (correctly) and
then its contents are copied into the sform. That is why the sform
after the swapdim contains offsets that are not clear in the sform
prior to swapping, as these offsets were in the qform.
The bottom line is that fslswapdim is working correctly, what you
report is exactly what I'd expect for every stage, your left and
right orientations are being preserved correctly and that you
should continue to run fslswapdim on your data in order to make
the rest of the pipeline more straightforward.
All the best,
Mark
On 23 Apr 2008, at 22:51, Emily T Stoneham wrote:
> Hi,
>
> Here it is:
>
> Thanks!
> Emily
>
> filename 7_ep2d_pace_moco_3DFilter_20080107_0001.nii
>
> sizeof_hdr 348
> data_type INT16
> dim0 3
> dim1 64
> dim2 64
> dim3 48
> dim4 1
> dim5 1
> dim6 1
> dim7 1
> vox_units mm
> time_units Unknown
> datatype 4
> nbyper 2
> bitpix 16
> pixdim0 0.0000000000
> pixdim1 3.0000000000
> pixdim2 3.0000000000
> pixdim3 3.1799850464
> pixdim4 0.0000000000
> pixdim5 0.0000000000
> pixdim6 0.0000000000
> pixdim7 0.0000000000
> vox_offset 352
> cal_max 0.0000
> cal_min 0.0000
> scl_slope 1.000000
> scl_inter 0.000000
> phase_dim 2
> freq_dim 1
> slice_dim 3
> slice_name alternating_increasing
> slice_code 3
> slice_start 0
> slice_end 47
> slice_duration 0.040000
> 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.000000 0.000000 -0.000000 101.060242
> qto_xyz:2 0.000000 2.987657 -0.288172 -96.445969
> qto_xyz:3 0.000000 0.271861 3.166901 -75.362930
> 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 Unknown
> sform_code 0
> sto_xyz:1 0.000000 0.000000 0.000000 0.000000
> sto_xyz:2 0.000000 0.000000 0.000000 0.000000
> sto_xyz:3 0.000000 0.000000 0.000000 0.000000
> sto_xyz:4 0.000000 0.000000 0.000000 0.000000
> sform_xorient Unknown
> sform_yorient Unknown
> sform_zorient Unknown
> file_type NIFTI-1+
> file_code 1
> descrip ep2d_pace_moco_3DFilter
> aux_file
>
>
> ----- Original Message -----
> From: Mark Jenkinson <[log in to unmask]>
> Date: Wednesday, April 23, 2008 5:30 pm
> Subject: Re: [FSL] Header data
>
>> Hi,
>>
>> I need the output from fslhd on both of the images to see what has
>> happened.
>> I suspect that you have sform_code=0 and qform_code=1 before you do
>> theswap, but I really want to check. Can you please send me the
>> fslhd from
>> both images?
>>
>> All the best,
>> Mark
>>
>>
>>
>> On 23 Apr 2008, at 16:21, Emily T Stoneham wrote:
>>
>>> Mark,
>>>
>>> Before the image was swapped, I converted the DICOM in MRIconvert
>> to
>>> FSL NIFTI format. Beyond that, the only processing done at this
>>> point is the swapping of the sagittal image. Here is the output
>>> from fslhd on one of the swapped images (below).
>>>
>>> Thanks!
>>> Emily
>>>
>>> Byte swapping
>>> filename
>> swapped_7_ep2d_pace_moco_3DFilter_20080107_0001.nii.gz>
>>> sizeof_hdr 348
>>> data_type INT16
>>> dim0 3
>>> dim1 64
>>> dim2 64
>>> dim3 48
>>> dim4 1
>>> dim5 1
>>> dim6 1
>>> dim7 1
>>> vox_units mm
>>> time_units s
>>> datatype 4
>>> nbyper 2
>>> bitpix 16
>>> pixdim0 0.0000000000
>>> pixdim1 3.0000000000
>>> pixdim2 3.0000000000
>>> pixdim3 3.1799850464
>>> pixdim4 0.0000000000
>>> pixdim5 0.0000000000
>>> pixdim6 0.0000000000
>>> pixdim7 0.0000000000
>>> vox_offset 352
>>> cal_max 0.0000
>>> cal_min 0.0000
>>> scl_slope 1.000000
>>> scl_inter 0.000000
>>> phase_dim 2
>>> freq_dim 1
>>> slice_dim 3
>>> slice_name alternating_increasing
>>> slice_code 3
>>> slice_start 0
>>> slice_end 47
>>> slice_duration 0.040000
>>> 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.000000 -0.000000 -0.000000 -87.939758
>>> qto_xyz:2 0.000000 2.987657 0.288172 -109.990044
>>> qto_xyz:3 0.000000 0.271861 -3.166901 73.481400
>>> qto_xyz:4 0.000000 0.000000 0.000000 1.000000
>>> qform_xorient Left-to-Right
>>> qform_yorient Posterior-to-Anterior
>>> qform_zorient Superior-to-Inferior
>>> sform_name Scanner Anat
>>> sform_code 1
>>> sto_xyz:1 3.000000 0.000000 0.000000 -87.939758
>>> sto_xyz:2 0.000000 2.987657 0.288172 -109.990044
>>> sto_xyz:3 0.000000 0.271861 -3.166901 73.481400
>>> sto_xyz:4 0.000000 0.000000 0.000000 1.000000
>>> sform_xorient Left-to-Right
>>> sform_yorient Posterior-to-Anterior
>>> sform_zorient Superior-to-Inferior
>>> file_type NIFTI-1+
>>> file_code 1
>>> descrip FSL4.0
>>>
>>> ----- Original Message -----
>>> From: Mark Jenkinson <[log in to unmask]>
>>> Date: Wednesday, April 23, 2008 11:02 am
>>> Subject: Re: [FSL] Header data
>>>
>>>> Hi,
>>>>
>>>> If you have swapped LR and SI dimensions then FSLView will show
>>>> the axial slices with the left (L) on the left - this is normal.
>>>> Re-orienting
>>>> to match that of the standard brain is a good idea in this case
>> as it
>>>> preserves your left-right labelling correctly (-x y -z is fine for
>>>> this) and
>>>> should keep all the other labels attached to the correct anatomy.
>>>>
>>>> So I would recommend using this fslswapdim command in general.
>>>>
>>>> However, the sform outputs are a bit puzzling. Are you sure that
>>>> all you did was apply fslswapdim to
>>>> 7_ep2d_pace_moco_3DFilter_20080107_0085.nii
>>>> which gave you
>>>> swapped_7_ep2d_pace_moco_3DFilter_20080107_0085.nii.gz?
>>>> It is doing what I'd expect in x and z, but not in y. It seems to
>>>> be
>>>> creating an
>>>> arbitrary coordinate offset there which I don't normally see. This
>>>> isn'tnecessary a problem, it just creates slightly strange
>>>> coordinates. Can
>>>> you send me the output of fslhd run on these images (and let me
>>>> know if
>>>> any other processing went on)?
>>>>
>>>> On a separate note, it sounds like you are worried about the mm
>>>> coordinates. These will not be in standard space if you look at
>> the>> first-level outputs. Only the higher-level FEAT outputs are in
>>>> standardspace. If you want to see your first-level outputs in
>>>> standard space, then
>>>> I recommend using Renderhighres to resample your first-level FEAT
>>>> output into standard space, where you will see the usual standard
>>>> space coordinates (with negative mm ones).
>>>>
>>>> All the best,
>>>> Mark
>>>>
>>>>
>>>> Emily T Stoneham wrote:
>>>>> Hello-
>>>>> When I pull up the FSLView image, it shows L on the Left of the
>>>> image.
>>>>> However, I must caveat this: Our scaner flips the Sagittal and
>>>> the Coronal functionals (the structurals are fine though). When I
>>>> fix this, that is when I see the change in L R labels in FSL View.
>>>> The Standard Image from the subject looks fine in FSLView (R on
>>>> left, L on right side of image). I fixd the sagittal and coronal
>>>> image by doing this:
>>>>> for fn in *.nii ; do fslswapdim $fn -x y -z swapped_$fn ; done
>>>>> (I have 290 images that need to be swapped, this fixes them all
>>>> at once)
>>>>>
>>>>> The original reason I am trying to straighten this out is that
>>>> when I am viewing the FEAT data, the voxel and mm data in FSLView
>>>> is WAY off what it should be. For instance, it will tell me that
>>>> something clearly in the parietal lobe is actually in the
>>>> cerebellum. It is as if FSL view doesn't recognize negative values
>>>> (I never see any except in the mm section, although these aren't
>>>> right either), and so I figured it was something I did in the
>>>> inital stages. While trying to figure it out- I noticed the
>>>> difference in the labelling in FSLView and began to tackle that
>>>> first off.
>>>>>
>>>>> Here is the output I got from one image before I swapped it:
>>>>> Command: fslorient -getsform
>>>> 7_ep2d_pace_moco_3DFilter_20080107_0085.nii> Output: -3 0 0 0 0 3
>>>> 0 0 0 0 3.17999 0 0 0 0 1
>>>>>
>>>>> Here is the output I got from one image after I swapped it:
>>>>> Command: fslorient -getsform
>>>> swapped_7_ep2d_pace_moco_3DFilter_20080107_0085.nii.gz> Output:
>> 3
>>>> 0 0 -87.9398 0 2.98766 0.288172 -109.99 0 0.271861 -3.1669 73.4814
>>>> 0 0 0 1
>>>>>
>>>>> Regards,
>>>>> Emily
>>>>>
>>>>
>>>>
>>>>
>>>> Mark Jenkinson wrote:
>>>>> Hi,
>>>>>
>>>>> How are you determining that the displayed orientation is
>>>>> neurological?
>>>>> Are the labels right? That is the most crucial thing. The
>>>> terms> neurological
>>>>> and radiological for display get a bit confusing when the
>>>> brain is
>>>>> not in the
>>>>> same orientation as the standard brain.
>>>>>
>>>>> If the labels are correct (including left and right) then *do
>>>> not*> do a fslswapdim
>>>>> as that will muck the labels up. I would also avoid using
>>>>> fslorient to change
>>>>> things unless you know the labels are wrong.
>>>>>
>>>>> Can you explain more about what you see in FSLView, what you
>>>>> expect to see, and
>>>>> what the labels are like? Don't worry about the sform values
>>>> for> now, although it would
>>>>> be helpful to send us the output of fslhd.
>>>>>
>>>>> All the best,
>>>>> Mark
>>>>>
>>>>>
>>>>>
>>>>> On 22 Apr 2008, at 19:25, Emily Stoneham wrote:
>>>>>
>>>>>> Hello all,
>>>>>> I have performed an fslorient -getorient, and it tells me
>>>> it is
>>>>>> RADIOLOGICAL, however, when viewed
>>>>>> in FSLView, it shows it in Neurological orientation. If I run
>>>>>> fslswapdim, I can change that (albeit I get
>>>>>> a warning), but I suspect I should be using fslorient to do
>>>> that>> instead- (i.e., change the header)?
>>>>>> When I run fslorient -getsform, I get a string of numbers,
>>>> but I
>>>>>> don't know what they mean, or
>>>>>> how/if I should change one or more (and which) of them. Can
>>>> you>> help?
>>>>>>
>>>>>> Thanks,
>>>>>> Emily
>>>>>>
>>>>>
>>>>
>>> <estoneha.vcf>
>>
> <estoneha.vcf>
|