Dear Patrick,
the length of a 3-vector is defined as
sqrt(x^2 + y^2 + z^2)
Thus, a vector (1 -1 0) has a length of sqrt(1+1+0) = sqrt(2).
Volkmar
Zitat von Patrick Hales <[log in to unmask]>:
> It worked! DTIFit will now process the images. Thanks very much.
>
> One last thing - just to clarify, a '1' in the bvecs file means
> sqrt(2)? Why isn't it 1/sqrt(2)? When I produced these images I used
> factors of 1/sqrt(2) in each direction, so the total magnitude would
> always equal 1. For instance, in my 2nd volume (1 1 0) I multiplied the
> total gradient by (1/sqrt(2)) in the x direction, and the same in the y
> direction. Sorry if this is a stupid question, but how do I tell FSL to
> use 1/sqrt(2) as a unit length?
>
> Thanks
>
> Patrick
>
>
>
>
> On 15 Oct 2007, at 16:13, Tim Behrens wrote:
>
>> PS -
>>
>>> 0 1 0 1 0 1 -1
>>> 0 1 1 0 1 -1 0
>>> 0 0 1 1 -1 0 1
>>>
>>> i.e. the gradients directions have been normalized to unit length,
>>
>>
>> These are not unit length. They have a length of sqrt(2)
>>
>> This does not matter for the new version of FDT, but probably does
>> matter for the old version you are working with
>>
>> T
>>
>>
>>
>>
>> On 15 Oct 2007, at 15:53, Patrick Hales wrote:
>>
>>> Hi
>>>
>>> Thanks again for the help. I've tried running bedpost_datacheck on
>>> my data (after renaming everything to the appropriate filenames).
>>> The output I get is:
>>>
>>> bedpost_data/data
>>> data_type INT16
>>> dim1 128
>>> dim2 128
>>> dim3 7
>>> dim4 1
>>> datatype 4
>>> pixdim1 0.2343750000
>>> pixdim2 0.2343750000
>>> pixdim3 1.0000000000
>>> pixdim4 1.0000000000
>>> cal_max 25500.0000
>>> cal_min 40.0000
>>> file_type NIFTI-1+
>>>
>>> bedpost_data/nodif does not exist
>>> bedpost_data/nodif_brain_mask
>>> data_type INT16
>>> dim1 128
>>> dim2 128
>>> dim3 7
>>> dim4 1
>>> datatype 4
>>> pixdim1 0.2343750000
>>> pixdim2 0.2343750000
>>> pixdim3 1.0000000000
>>> pixdim4 1.0000000000
>>> cal_max 4.0000
>>> cal_min 0.0000
>>> file_type NIFTI-1+
>>>
>>> num lines in bedpost_data/bvals
>>> 1
>>> num words in bedpost_data/bvals
>>> 7
>>> num lines in bedpost_data/bvecs
>>> 3
>>> num words in bedpost_data/bvecs
>>> 21
>>> number of elements in bvals is not equal to number of vols in data
>>> number of elements per line in bvecs is not equal to number of vols in data
>>>
>>> I don't understand what's wrong with my bvals and bvecs files. My
>>> 'data' file should now be made up of 7 volumes, the 1st with b=0
>>> and the other 6 with diffusion weighting in various directions. My
>>> bvals file looks like this:
>>>
>>> 0 1025 1048 826 1003 582 826
>>>
>>> and my bvecs file looks like this:
>>>
>>> 0 1 0 1 0 1 -1
>>> 0 1 1 0 1 -1 0
>>> 0 0 1 1 -1 0 1
>>>
>>> i.e. the gradients directions have been normalized to unit length,
>>> and the vectors run in columns. Could you tell me what I'm doing
>>> wrong with these files? - I've read the help and it sounds like I
>>> have set them up correctly, but I'm obviously doing something wrong.
>>>
>>> Thanks very much
>>>
>>> Patrick
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 15 Oct 2007, at 14:28, Tim Behrens wrote:
>>>
>>>> Although - if you have the old version of FSL, it will be called
>>>> bedpost_datacheck!
>>>> T
>>>> On 15 Oct 2007, at 13:00, Matt Glasser wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Fslmerge is in the latest version of FSL whereas avwmerge is in earlier
>>>>> versions. You could navigate to the data directory with the
>>>>> commandline and
>>>>> try running bedpostx_datacheck and post that output here.
>>>>>
>>>>> Peace,
>>>>>
>>>>> Matt.
>>>>>
>>>>> -----Original Message-----
>>>>> From: FSL - FMRIB's Software Library [mailto:[log in to unmask]]
>>>>> On Behalf
>>>>> Of Patrick Hales
>>>>> Sent: Monday, October 15, 2007 6:36 AM
>>>>> To: [log in to unmask]
>>>>> Subject: Re: [FSL] Problem with DTIFit
>>>>>
>>>>> Hi
>>>>>
>>>>> Thanks for that. The command 'fslmerge' isn't recognized for some
>>>>> reason, however, I have been able to make my 4D data file using
>>>>> 'avwmerge' instead. Unfortunately, when I try to process the data in
>>>>> DTIFit, I now get the error message: "Error: child killed: bus
>>>>> error". Would you be able to tell me how to fix this?
>>>>>
>>>>> Thanks very much for your help
>>>>>
>>>>> Patrick
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 15 Oct 2007, at 11:14, Tim Behrens wrote:
>>>>>
>>>>>> You need to merge your data from different diffusion directions
>>>>>> into a single 4D nifti file - you can use fslmerge to do this.
>>>>>>
>>>>>> T
>>>>>> On 15 Oct 2007, at 09:52, Patrick Hales wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> This is the first time I have tried using FSL, and I am trying to
>>>>>>> get the DTIFit program to work. I have
>>>>>>> a series of diffusion weighted images, each of which are stored as
>>>>>>> individual fid files (created using
>>>>>>> Varian's VnmrJ software). There are seven images in total, one
>>>>>>> with b=0 and 6 with diffusion
>>>>>>> gradients applied in non co-linear directions. I have converted
>>>>>>> each of these into Nifti format, and
>>>>>>> stored them all in a directory. I used FSLview to create my binary
>>>>>>> mask, and have created text files
>>>>>>> with my gradient directions (all normalized to unit length), and
>>>>>>> my b-values (in units of s/mm2). In
>>>>>>> the DTIFit program, I have selected 'specify input files
>>>>>>> manually', and supplied it with the directory
>>>>>>> containing my nifti files, and the filenames of my gradients and b-
>>>>>>> values text files.
>>>>>>>
>>>>>>> When I press 'go', I get a number of error messages, such as:
>>>>>>> 'ERROR: nifti_image_read(....directory
>>>>>>> name....)can't open header file', 'ERROR: nifti_image_open
>>>>>>> (...):bad header info', 'Error: failed to open
>>>>>>> file', etc. I get the same errors when I try it with analyze files.
>>>>>>>
>>>>>>> Would you be able to tell me what I'm doing wrong? Thanks very much
>>>>>>>
>>>>>>> Patrick Hales
|