OK, some documentation looks like this:
% short int dim[ ]; /* Array of the image dimensions */
%
% dim[0] Number of dimensions in database; usually 4.
% dim[1] Image X dimension; number of pixels in an image row.
% dim[2] Image Y dimension; number of pixel rows in slice.
% dim[3] Volume Z dimension; number of slices in a volume.
% dim[4] Time points; number of volumes in database.
% dim[5] Undocumented.
% dim[6] Undocumented.
% dim[7] Undocumented.
%
% float pixdim[]; Parallel array to dim[], giving real world measurements in
mm and ms.
% pixdim[0]; Pixel dimensions?
% pixdim[1]; Voxel width in mm.
% pixdim[2]; Voxel height in mm.
% pixdim[3]; Slice thickness in mm.
% pixdim[4]; timeslice in ms.
% pixdim[5]; Undocumented.
% pixdim[6]; Undocumented.
% pixdim[7]; Undocumented.
%
So, you would use pixdim[4] above to store the TR, in ms?
Thanks very much, Darren
PS, I sent a note about this issue to Xmedcon developers.
----- Original Message -----
From: "Mark Jenkinson" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Wednesday, October 30, 2002 2:43 PM
Subject: Re: avwmerge problem
Hi Darren,
Glad that fixed the problem.
As for the fields - time is always the fourth dimension, not zero.
That is dim4=number of time points, pixdim4=TR.
Values of dim0 and pixdim0 both refer to the storage of intensity
(similar to bitpix).
I'm not exactly sure what they mean or how to interpret them (and
I don't think we use them ever), but the safest way to check is to
see what the output of avwmaths (or any other fsl program) is.
The other way to make sure that the header is correct is to create
a new one using avwcreatehd with the appropriate fields. Only
the values which can be set as arguments to this are ever used
by fsl.
Cheers,
Mark
On Wednesday, October 30, 2002, at 12:37 PM, Darren Weber wrote:
> Hi Mark,
>
> that's it. There must be important differences in the header information
> expected. My files were created with Xmedcon and avwmaths has corrected
> the
> fields to those expected by FSL.
>
> See below for details, but it appears that 'extents' should be 0, dim0
> should be 4 (even if it is only a 3D file for one time point), dim4 should
> be 1 (for one time point), and all the pixdim values are ordered so that
> pixdim0 is time (always zero?) and pixdim1-3 are XYZ (I guess).
>
> Cheers, Darren
>
> PS, I ran:
>
> [numerous siemens]$ avwhd c01 > c01.txt;
> [numerous siemens]$ avwhd newc01 > newc01.txt;
> [numerous siemens]$ diff -a c01.txt newc01.txt
>
> 1c1
> < filename c01
> ---
>> filename newc01
> 4,6c4,6
> < data_type dsr
> < db_name m003-ma0092
> < extents 16384
> ---
>> data_type
>> db_name
>> extents 0
> 9,10c9,10
> < hkey_un0
> < dim0 3
> ---
>> hkey_un0 ·
>> dim0 4
> 14c14
> < dim4 0
> ---
>> dim4 1
> 18c18
> < vox_units
> ---
>> vox_units mm
> 23c23
> < pixdim0 3.0000000000
> ---
>> pixdim0 0.0000000000
> 35,36c35,36
> < cal_max 0.0000
> < cal_min 0.0000
> ---
>> cal_max 251.0000
>> cal_min 2.0000
> 39,41c39,41
> < glmax 11
> < glmin 0
> < descrip Unknown
> ---
>> glmax 251
>> glmin 2
>> descrip
> 48c48
> < generated (X)MedCon
> ---
>> generated
>
>
>
>
> ----- Original Message -----
> From: "Mark Jenkinson" <[log in to unmask]>
> To: <[log in to unmask]>
> Sent: Wednesday, October 30, 2002 11:42 AM
> Subject: Re: avwmerge problem
>
>
>> Hi Darren,
>>
>> I'm not sure what would be causing this, as I've never had a problem on
>> any redhat machine.
>>
>> I'd suggest first running your files through avwmaths just to make sure
>> that they have all the correct elements saved. That is:
>> avwmaths c01 newc01
>> avwmaths c02 newc02
>>
>> then do:
>> avwmerge -t tmp newc01 newc02
>>
>> Then see if you still get the same problem.
>> Cheers,
>> Mark
>>
>>
>> On Wednesday, October 30, 2002, at 12:00 PM, Darren Weber wrote:
>>
>>> Hi Tracy,
>>>
>>> this is curious. It may not be your OS, it might be one of the
> components
>>> of avwmerge, as it appears to fail on my redhat linux 7.3 system.
>>>
>>> Just for kicks, I've tried to run avwmerge on a series of T1 MPRAGE
>>> anatomical volumes, to create a 4D file. The .img files are axial
>>> unflipped, int16.
>>>
>>> The command was 'avwmerge -t tmp c01.img c02.img' - here's a matlab
>>> listing
>>> of the hdr.dime fields from c01 and the result tmp (note that tmp is a
> 4D
>>> file, but there is no size in the fourth dimension):
>>>
>>>>> c01.hdr.dime
>>>
>>> ans =
>>>
>>> dim: [3 128 256 256 0 0 0 0]
>>> vox_units: ' '
>>> cal_units: ' '
>>> unused1: 0
>>> datatype: 4
>>> bitpix: 16
>>> dim_un0: 0
>>> pixdim: [3 1.3047 0.9800 0.9800 0 0 0 0]
>>> vox_offset: 0
>>> roi_scale: 1
>>> funused1: 0
>>> funused2: 0
>>> cal_max: 0
>>> cal_min: 0
>>> compressed: 0
>>> verified: 0
>>> glmax: 11
>>> glmin: 0
>>>
>>>
>>> tmp.hdr.dime
>>>
>>> ans =
>>>
>>> dim: [4 128 256 256 0 0 0 0]
>>> vox_units: ' '
>>> cal_units: ' '
>>> unused1: 0
>>> datatype: 4
>>> bitpix: 16
>>> dim_un0: 0
>>> pixdim: [3 1.3047 0.9800 0.9800 0 0 0 0]
>>> vox_offset: 0
>>> roi_scale: 1
>>> funused1: 0
>>> funused2: 0
>>> cal_max: 0
>>> cal_min: 0
>>> compressed: 0
>>> verified: 0
>>> glmax: 36
>>> glmin: 0
>>>
>>>
>>>
>>> Cheers, Darren
>>>
>>>
>>> ----- Original Message -----
>>> From: "Tracy L. Luks" <[log in to unmask]>
>>> To: <[log in to unmask]>
>>> Sent: Wednesday, October 30, 2002 10:57 AM
>>> Subject: Re: avwmerge problem
>>>
>>>
>>>> Hi,
>>>>
>>>> I have double-checked the files in my directories, and I can't find
>>>> any abnormalities. There are no extra files, no 4D files, and no
>>>> evidence that OSX sees them differently than any other UNIX system:
>>>> there are 60 .img files and 60.hdr files. I'm still puzzled that
>>>> avwmerge behaves differently when I give it three specific files and
>>>> when I give it 30 specific files...
>>>>
>>>> Is there anything else that I can try?
>>>>
>>>> Thanks,
>>>> Tracy Luks
>>>>
>>>>> Hi - this is what you would get if you were mistakenly entering
>>>>> avwmerge -t OUT run1_f*
>>>>> ie if you left off the .img ....but you're not doing that....
>>>>>
>>>>> so I suspect it is an oddity of the strange macos filesystem....what
> do
>>>>> you get if you type
>>>>>
>>>>> echo run1_f*
>>>>>
>>>>> maybe you also have capitalised versions as well as lower case in the
>>>>> directory (macos can't see the difference)?
>>>>>
>>>>> Thanks, Steve.
>>>>>
>>>>>
>>>>> On Sat, 26 Oct 2002, Tracy Luks wrote:
>>>>>
>>>>>> I'm trying to use avwmerge with Mac OSX.2. I have a directory with
> 60
>>> 3D
>>>>>> analyze files (i.e. 60 img and 60 hdr files). When I enter:
>>>>>>
>>>>>> avwmerge -t OUT run1_f*.img
>>>>>>
>>>>>> I get a 4D file with 120 volumes. If I enter the same thing with
>>>>>> three
>>>>>> complete file names, I get a 4D file with 3 volumes, BUT if I enter
>>> the
>>>>>> same thing with 30 complete file names, I get a 4D file with 60
>>> volumes.
>>>>>>
>>>>>> Any ideas?
>>>>>>
>>>>>> Thanks,
>>>>>> Tracy Luks
>>>>>>
>>>>>>
>>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>>> Tracy L. Luks, Ph.D.
>>>>>> Magnetic Resonance Science Center
>>>>>> 1 Irving St., AC-109
>>>>>> Department of Radiology
>>>>>> University of California, San Francisco
>>>>>> San Francisco CA 94143-1290
>>>>>> Tel: (415)514-0947
>>>>>> (650)219-6927
>>>>>> Email: [log in to unmask]
>>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>>>
>>>>>
>>>>> Stephen M. Smith
>>>>> Head of Image Analysis, FMRIB
>>>>>
>>>>> Oxford University Centre for Functional MRI of the Brain
>>>>> John Radcliffe Hospital, Headington, Oxford OX3 9DU, UK
>>>>> +44 (0) 1865 222726 (fax 222717)
>>>>>
>>>>> [log in to unmask] http://www.fmrib.ox.ac.uk/~steve
>>>>
>>>>
>>>> --
>>>> ********************************************************************
>>>> Tracy L. Luks Ph.D.
>>>> Dynamic NeuroImaging Lab
>>>> University of California San Francisco
>>>> [log in to unmask]
>>>> Office: 415-514-2527
>>>> Cell: 650-219-6927
>>>> Home: 415-459-5046
>>>>
>>
|
