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
|