Hi,

This all sounds correct to me.
FSLView does not load everything at once, but loads things as needed.
If you play the movie then it will be forced to load everything, and this is probably when it fails.

I suspect that fslmerge and fslsplit (and all the other fsl tools) are fine but just viewing the images with FSLView is a problem.
I also recommend trying matlab to check, or you could try doing things with fslstats on the volumes before and after merging to identify what is what in order to double check.

All the best,
	Mark



On 10 Aug 2012, at 20:29, Sebastian Moeller wrote:

> Hi Emily,
> 
> 
> 
> On Aug 10, 2012, at 11:10 AM, Emily Lindemer wrote:
> 
>> I rebooted my machine in 64-bit mode and I still got the same problem when using fslmerge. 
>> One thought that I had (for anyone else following this) is that the problem could potentially be with fslview?
>> It seems a little off-the-mark, but I have a couple of reasons for thinking that.
>> 
>> 1) When I loop through the 4D image in "video mode" on fslview, the program crashes somewhere between image 60-80.
>> 2) When I use fslsplit on the incorrectly assembled 4D image, the splits come out in the correct order that I input them
>> 
>> Could it be that the problem is actually with fslview, and that the 4D file itself is actually OK? Does anyone know a way that I could test this (i.e. another program to open the 4D image with besides fslview)? 
> 
> 	Good call:
> hms-beagle:~ moeller$ file ${FSLDIR}/bin/fslview.app/Contents/MacOS/fslview
> /opt/fsl-4.1.9-macosx/bin/fslview.app/Contents/MacOS/fslview: Mach-O universal binary with 2 architectures
> /opt/fsl-4.1.9-macosx/bin/fslview.app/Contents/MacOS/fslview (for architecture i386):	Mach-O executable i386
> /opt/fsl-4.1.9-macosx/bin/fslview.app/Contents/MacOS/fslview (for architecture ppc):	Mach-O executable ppc
> hms-beagle:~ moeller$ 
> 
> so in 4.1.0 fslview is only 32bit and will run into the 2GB limit (if it tries to load everything into memory at once, which I am not certain of). You could try to load the resulting nifty file in matlab and test different time points for consistency…
> To me it looks like fslmerge and fslsplit work like advertised (at least in 64bit mode) and it really is only fslview that makes the 4D data look funny. Side note macosx should allow 64bit userspace even if started in 32bit mode by virtue of thunking (there is a column called "Kind" in activity monitor that tells the fitness of running programs which can be used to check whether even in i386 mode fslmerge and friends run as 64bit binaries).
> 
> Best
> 	Sebastian
> 
> 
>> 
>> -Emily
>> 
>> 
>> 
>> On Fri, Aug 10, 2012 at 1:17 PM, Emily Lindemer <[log in to unmask]> wrote:
>> Thanks so much Sebastian, you're right, my OS is not running in 64bit mode, I'm getting i386. What do you suggest that I do from here? Reset my machine to default startup in 64bit mode? 
>> -Emily
>> 
>> 
>> On Fri, Aug 10, 2012 at 1:07 PM, Sebastian Moeller <[log in to unmask]> wrote:
>> Hi Emily,
>> 
>> freesurfer for maces is 32bit only, so that probably explains the out of memory errors for mri_concat.
>> So maybe your operating system is running in 32bit mode, try to run "uname -a" on the terminal:
>> hms-beagle:~ moeller$ uname -a
>> Darwin hms-beagle 11.4.0 Darwin Kernel Version 11.4.0: Mon Apr  9 19:32:15 PDT 2012; root:xnu-1699.26.8~1/RELEASE_X86_64 x86_64
>> 
>> Which version of machos are you running?
>> 
>> you want to read x86_64 not i386 (that would mean you OS is 32 bit and you will have a 2GB limit for userspace address space).
>> 
>> then run "file `which fslmerge`" (note the back ticks "`"):
>> hms-beagle:~ moeller$ file `which fslmerge`
>> /opt/fsl-4.1.9-macosx/bin/fslmerge: Mach-O universal binary with 4 architectures
>> /opt/fsl-4.1.9-macosx/bin/fslmerge (for architecture ppc):      Mach-O executable ppc
>> /opt/fsl-4.1.9-macosx/bin/fslmerge (for architecture ppc64):    Mach-O 64-bit executable ppc64
>> /opt/fsl-4.1.9-macosx/bin/fslmerge (for architecture i386):     Mach-O executable i386
>> /opt/fsl-4.1.9-macosx/bin/fslmerge (for architecture x86_64):   Mach-O 64-bit executable x86_64
>> 
>> you want to find Mach-O 64-bit executable x86_64 in there. I assume that fsl most likely is the default multi arch distribution, so my bet is on your OS not running in 64bit mode.
>> 
>> 
>> On Aug 10, 2012, at 7:59 AM, Emily Lindemer wrote:
>> 
>>> Hi Mark,
>>> I have 32 GB of memory, so I know that it's definitely not an issue of not having enough, I am more concerned about how my OS was allocating it, and whether or not this is something I can change in FSL.
>>> I was originally running version 4.1.5 and then I upgraded to 4.1.9 to see if that helped, but I still got the same result.
>>> There are no errors or warnings from fslmerge, just the bad output, but you wouldn't know it was bad unless you went through and manually checked all of the volumes.
>>> I also tried running fslmerge with the 'nice' bash command to prioritize it, and no change in output.
>>> I also forgot to mention that I used fslmaths to downsample all of my data to 2mm resolution, and after doing this, fslmerge worked properly (another piece of evidence pointing to a memory issue).
>>> 
>>> I think you might be onto something with the 2GB limit, it looks like my 70th image puts me at about 1.88GB. My dimensions are 182*218*182 voxels and they're in float.
>>> Any suggestions?
>>> Thanks,
>>> Emily
>>> 
>>> 
>>> 
>>> 
>>> On Thu, Aug 9, 2012 at 4:49 PM, Mark Jenkinson <[log in to unmask]> wrote:
>>> Dear Emily,
>>> 
>>> I have not experienced this myself but this does sound a little like a memory issue, especially given the FreeSurfer error.
>>> How much memory do you have on your Mac?
>>> And what version of FSL are you using?
>>> Are there any errors or warnings from fslmerge or does it just silently give this poor output?
>>> It might be worth working out whether the 70th-80th image corresponds to the 2GB point.
>>> To do this just calculate xsize * ysize * zsize * 70 * 4  (the 4 is if the output image is in float, but should be 8 if it is in double)
>>> If the image was 128*128*128 voxels then this would only be 560MB at 70 images (or 936MB for 117 images) by my calculations.
>>> So unless your images are much bigger than this then I don't think it is to do with the 2GB limit.
>>> Even if it is over 2GB I'm not sure why this would happen, but let us know the answer to the above questions and we'll try and help get to the bottom of it.
>>> 
>>> All the best,
>>>        Mark
>>> 
>>> 
>>> 
>>> On 9 Aug 2012, at 20:21, Emily Lindemer wrote:
>>> 
>>>> Hi All,
>>>> I am working with a somewhat large set of FA data, and I have come across a problem when using fslmerge and fslsplit with my data. I have 117 subjects, and when I try to concatenate them into a 4D image using fslmerge, the first 70ish images of the 4D output file are in the correct order, but then the last chunk of them are in a seemingly-random order. I have checked and re-checked this many times to make sure that I wasn't mistaking the order of my input subjects, and I am sure that I am not doing anything wrong with labelling. I have used both imglob and an input list that I created, and I am having the problem both ways. I'm running FSL with a MAC OS, and I'm starting to think that it is a memory issue, for a couple of reasons.
>>>> 
>>>> 1. When I try to loop through all of the images in the 4D file with fslview, the video crashes around the 80th subject.
>>>> 2. For anyone who uses FreeSurfer: I also attempted to create the 4D image with mri_concat and I get a "cannot allocate memory" error.
>>>> 
>>>> The most puzzling part is that the first chunk of subjects appear in the correct order in the 4D image, and this disorganization does not start at an obvious point (such as subject ID number switching to the 100's.)
>>>> 
>>>> Furthermore, when I then go to use fslsplit on the 4D image, the splits come out in the same order as I input them (i.e. the last output split does not match up with the last frame of the 4D image, but rather, with the last subject that I input to fslmerge.)
>>>> 
>>>> If anyone has an answer or has come across a similar problem, please let me know.
>>>> Best,
>>>> Emily
>>>> 
>>> 
>> 
>> --
>> Sebastian Moeller
>> 
>> telephone: +1-626-325-8598 /+1-626-395-6523 / +1-626-395-6616
>> fax: 626-395-8826
>> German GSM:  +49 - 15 77 - 1 90 31 41
>> mobile:         +1-626-325-8598
>>                +1-626-807-5242
>> US CDMA: +1-626-807-5242
>> [log in to unmask]
>> 
>> Division of Biology
>> MC 114-96
>> California Institute of Technology
>> 1200 East California Boulevard
>> CA 91125, Pasadena
>> USA
>> 
>> 
> 
> -- 
> Sebastian Moeller
> 
> telephone: +1-626-325-8598 /+1-626-395-6523 / +1-626-395-6616
> fax: 626-395-8826
> German GSM:  +49 - 15 77 - 1 90 31 41
> mobile: 	+1-626-325-8598
>                +1-626-807-5242
> US CDMA: +1-626-807-5242
> [log in to unmask]
> 
> Division of Biology
> MC 114-96
> California Institute of Technology
> 1200 East California Boulevard
> CA 91125, Pasadena
> USA
>