Hi,
The 4.1.3 binaries should be able to read/write larger images -
are you still getting the same error?
Many Regards
Matthew
> Sorry, my last message did not include the previous correspondence.
> It's pasted below.
> Thanks for your help.
>
>
> Hi,
> This is a different large-image bug, that's fixed in our
> internal builds - Lars: I'll send you a link to a centos5_64 fslhd
> that should allow your analysis to complete..
>
> Many Regards
>
> Matthew
>
>> Hi,
>>
>> This is likely either a big-RAM problem (in which case see the FSL
>> FAQ) or a previous large-image FSL bug. I think the very latest
>> version of FSL (4.1.2) may have fixed the latter (Matthew can
>> comment further on this maybe) so you may be ok if you just install
>> the latest version and try again?
>>
>> Cheers.
>>
>>
>>
>> On 14 Jan 2009, at 08:00, Lars Tjelta Westlye wrote:
>>
>>> Hi,
>>>
>>> I'm running TBSS (FSL 4.1.1-centos5_64) on a dataset comprising 433
>>> FA
>>> volumes. Everything runs fine up to tbss_3_postreg -S subsequent to
>>> the
>>> fslmerge command at line 164 in the tbss_3_postreg script where it
>>> errors
>>> attempting to compute the mask and mean FA. That is, all_FA.nii.gz
>>> is
>>> generated (2.5 GB), but FSL can't seem to read the file:
>>>
>>> ****
>>> [larstw@psyk077 stats]$ fslhd all_FA.nii.gz
>>> ** ERROR: nifti_image_open(all_FA): bad header info
>>> Error: failed to open file all_FA
>>> ERROR: Could not open file
>>> ****
>>>
>>> The same error appears when trying to open the 4D volume in Fslview.
>>> However, Freesurfer's mri_info yields the following info, which
>>> seems fine
>>> to me:
>>>
>>> ****
>>> [larstw@psyk077 stats]$ mri_info all_FA.nii.gz
>>> Volume information for all_FA.nii.gz
>>> type: nii
>>> dimensions: 182 x 218 x 182 x 433
>>> voxel sizes: 1.0000, 1.0000, 1.0000
>>> type: FLOAT (3)
>>> fov: 182.000
>>> dof: 0
>>> xstart: -91.0, xend: 91.0
>>> ystart: -109.0, yend: 109.0
>>> zstart: -91.0, zend: 91.0
>>> TR: 1000.00 msec, TE: 0.00 msec, TI: 0.00 msec, flip angle:
>>> 0.00 degrees
>>> nframes: 433
>>> ras xform present
>>> xform info: x_r = -1.0000, y_r = 0.0000, z_r = 0.0000, c_r =
>>> -1.0000
>>> : x_a = 0.0000, y_a = 1.0000, z_a = 0.0000, c_a =
>>> -17.0000
>>> : x_s = 0.0000, y_s = 0.0000, z_s = 1.0000, c_s =
>>> 19.0000
>>> Orientation : LAS
>>> Primary Slice Direction: axial
>>>
>>> voxel to ras transform:
>>> -1.0000 0.0000 0.0000 90.0000
>>> 0.0000 1.0000 0.0000 -126.0000
>>> 0.0000 0.0000 1.0000 -72.0000
>>> 0.0000 0.0000 0.0000 1.0000
>>>
>>> voxel-to-ras determinant -1
>>>
>>> ras to voxel transform:
>>> -1.0000 0.0000 0.0000 90.0000
>>> -0.0000 1.0000 -0.0000 126.0000
>>> -0.0000 -0.0000 1.0000 72.0000
>>> 0.0000 0.0000 0.0000 1.0000
>>> ****
>>>
>>> I have approx 1TB available disk space. This is the output of free -
>>> m (16
>>> GB RAM, 18 GB swap):
>>>
>>> ***
>>> [larstw@psyk077 stats]$ free -m
>>> total used free shared buffers
>>> cached
>>> Mem: 16053 4316 11736 0
>>> 475 1748
>>> -/+ buffers/cache: 2092 13960
>>> Swap: 18433 4781 13652
>>> ***
>>>
>>> ***
>>> [larstw@psyk077 stats]$ uname -a
>>> Linux psyk077.uio.no 2.6.18-92.1.22.el5 #1 SMP Fri Dec 5 09:28:22
>>> EST 2008
>>> x86_64 GNU/Linux
>>> ***
>>>
>>> Is this expected behavior on datasets of this size? Could the
>>> problem be
>>> due to insufficient memory on my system, and do you have any
>>> suggestions
>>> on how to solve this? It should be noted that everything works
>>> nicely with
>>> smaller datasets, although I would like to include everything in
>>> one run.
>>>
>>> Thank you very much,
>>> Lars
>>>
>>
>>
>> ---------------------------------------------------------------------------
>> Stephen M. Smith, Professor of Biomedical Engineering
>> Associate Director, Oxford University FMRIB Centre
>>
>> FMRIB, JR Hospital, Headington, Oxford OX3 9DU, UK
>> +44 (0) 1865 222726 (fax 222717)
>> [log in to unmask] http://www.fmrib.ox.ac.uk/~steve
>> ---------------------------------------------------------------------------
>
|