Hi,
The problem, I think, is due to the 32bit-only nature of FSLview 3.x on Mac. Sadly FSLview 4.x, which is 64bit on Mac, doesn't work well enough on the Mac.
FSLview has a simple volume cache mechanism built into it which should allow it to cope with such situations but there is clearly a problem and I intend to look into fixing this as soon as possible.
Dave
On 4 Apr 2013, at 10:45, Andreas Bartsch <[log in to unmask]> wrote:
> Hi,
>
> I can in part replicate this on OSX 10.6.8, 8 GB RAM:
>
> - crash in movie mode on your data
> - got 0:10 & 267:277 B0
> - does not show the B0 at 534:544 and 801:811 when going to these volumes
> in fslview (yet they are there), instead volumes with diffusion weighting
> are shown
> - in movie mode before the crash I can see the B0s at 534:544
>
> Cheers,
> Andreas
>
> Am 04.04.13 02:15 schrieb "Tanja Kassuba" unter <[log in to unmask]>:
>
>> Hi again,
>>
>> Too quick to reply:
>> B0s of eddy output are out of order only when using the Mac version of
>> fslview, not the Linux version running on our cluster. This was the same
>> with both Mac fslview 3.1.8 and 3.2.0.
>>
>> Further, when using Mac fslview, the app will crash when trying to run
>> the eddy output data in Movie Mode (but it doesn't crash running the eddy
>> input data in Movie Mode - which is a much smaller file size). Here is
>> the crash message:
>>
>> fslview(52693,0xac0d4a28) malloc: *** mmap(size=4063232) failed (error
>> code=12)
>> *** error: can't allocate region
>> *** set a breakpoint in malloc_error_break to debug
>> std::bad_alloc
>>
>> So this doesn't seem to be an eddy-specific problem, but a problem
>> related to the large file size and the Mac version of fslview.
>>
>> Here's a download link to the eddy output data file if interested:
>> https://dl.dropbox.com/u/3889124/data.nii.gz
>>
>> There are in total 1068 volumes, and the B0s are supposed to be at the
>> positions (with the first volume=0):
>> 0:10 267:277 534:544 801:811
>>
>> thanks,
>> Tanja
>>
>>
>>
>>>> Dear Jesper,
>>
>>>>
>>
>>>> I found out that the eddy output data was actually fine, it was just
>>>> fslview showing the B0s at wrong positions, having
>>>> memory problems with the big data set, when the data was accessed
>>>> remotely from our server. When I view a local copy of
>>>> the data or when I run fslview differently on the server it's fine. I'm
>>>> really sorry having bothered you with this!
>>
>>>> Thanks,
>>
>>>> Tanja
>
--
Dave Flitney
Oxford Centre for Functional MRI of the Brain
E:[log in to unmask] W:+44-1865-222713 F:+44-1865-222717
URL: http://www.fmrib.ox.ac.uk/~flitney
|