Dear Colm,

For file sizes we recommend using the compressed form of
nifti file - nii.gz.  You can specify this using NIFTI_GZ as
the value of the FSLOUTPUTTYPE variable.  This will save
you disk space.

As for actual sizes in memory - it won't matter whether
the file is compressed or not, as it will be fully unpacked
in memory.  The reason that your image size increases so much
is that you are converting your low resolution fmri data in run1
(with 80x80x32 voxels of size 2.8x2.8x3.8 mm) to standard
space (with 91x109x91 voxels of size 2x2x2 mm).  If this is
really what you *need* to do then there is no setting that
will help as that is how big the data needs to be.  However,
in FSL we do not convert the original fmri data to standard
space first.  Instead we do the single subject analysis in the
original functional space (or at least at the same resolution)
and then upsample the statistical results into standard space
afterwards.  This means that we don't need to have 142
timepoints upsampled, but only the total number of
copes and varcopes (= number of contrasts * 2).  This results
in much smaller sizes which are more manageable.

The issue of changing TR is a consequence of upsampling
using a reference image where the TR is different.  It basically
just copies the TR (pixdim4) from the reference image.  You
can modify this using avwedithd (or script it) if it is necessary
to fix it, but for FSL this value is not read automatically, and
needs to be specified in the FEAT GUI by hand.

I hope this answers your questions.
All the best,
    Mark



Colm G. Connolly wrote:

>Hi all,
>
>I have a question about data types and file sizes.
>I have converted some files, both anatomical and functional, from PAR/REC to 
>NIfTI using Chris Rorden's mricron 
>tools  http://www.sph.sc.edu/comd/rorden/mricron/source.html
>
>As you can see, the output below, from avwinfo, shows that the data type of 
>the of the original data (filenames without normalised) is INT16 and the 
>output data type if FLOAT32. This conversion results in enormous files. For 
>example, for run1 it goes from 56MB to 489MB. Is this increase in size 
>normal? 91*109*91*142*32 seems to yield a size, in bits, which matches the 
>the file size below. Is there a way to tell bet and flirt to keep the output 
>data in INT16 format? Alternatively, is it possible to coerce the data type 
>from FLOAT32 to INT16 without loss of information?
>
>Why would I like to avoid these enormous files? Concatenating 7 half-gig files 
>yields one even bigger file on which I simply don't have the RAM to operate.
>
>Also, the original functional data has a TR of 2sec (I'm assuming that 
>dim4=time and pixdim4 is the granularity) but in the normalised file the TR 
>has become 1sec. Is this normal? Is there a way of preventing this 
>conversion?
>
>################################################################################
>### ctrl/em0001/em0001.anat.nii
>################################################################################
>-rw-r--r--  1 colmconn mriuser 23M May 29 17:19 ctrl/em0001/em0001.anat.nii
>data_type      INT16
>dim1           256
>dim2           256
>dim3           180
>dim4           1
>datatype       4
>pixdim1        0.8984375000
>pixdim2        0.8984375000
>pixdim3        0.8999999762
>pixdim4        0.0080000004
>cal_max        0.0000
>cal_min        0.0000
>file_type      NIFTI-1+
>################################################################################
>### ctrl/em0001/em0001.anat.noskull.nii
>################################################################################
>-rw-r--r--  1 colmconn mriuser 46M May 29 18:10 
>ctrl/em0001/em0001.anat.noskull.nii
>data_type      FLOAT32
>dim1           256
>dim2           256
>dim3           180
>dim4           1
>datatype       16
>pixdim1        0.8984375000
>pixdim2        0.8984375000
>pixdim3        0.8999999762
>pixdim4        0.0080000004
>cal_max        1596.2588
>cal_min        0.0000
>file_type      NIFTI-1+
>################################################################################
>### ctrl/em0001/em0001.anat.noskull.normalised.nii
>################################################################################
>-rw-r--r--  1 colmconn mriuser 3.5M May 29 18:14 
>ctrl/em0001/em0001.anat.noskull.normalised.nii
>data_type      FLOAT32
>dim1           91
>dim2           109
>dim3           91
>dim4           1
>datatype       16
>pixdim1        2.0000000000
>pixdim2        2.0000000000
>pixdim3        2.0000000000
>pixdim4        1.0000000000
>cal_max        1596.2588
>cal_min        0.0000
>file_type      NIFTI-1+
>################################################################################
>### ctrl/em0001/em0001.run1.nii
>################################################################################
>-rw-r--r--  1 colmconn mriuser 56M May 29 17:19 ctrl/em0001/em0001.run1.nii
>data_type      INT16
>dim1           80
>dim2           80
>dim3           32
>dim4           142
>datatype       4
>pixdim1        2.7999999523
>pixdim2        2.7999999523
>pixdim3        3.8390624523
>pixdim4        2.0000000000
>cal_max        0.0000
>cal_min        0.0000
>file_type      NIFTI-1+
>################################################################################
>### ctrl/em0001/em0001.run1.normalised.nii
>################################################################################
>-rw-r--r--  1 colmconn mriuser 489M May 29 18:15 
>ctrl/em0001/em0001.run1.normalised.nii
>data_type      FLOAT32
>dim1           91
>dim2           109
>dim3           91
>dim4           142
>datatype       16
>pixdim1        2.0000000000
>pixdim2        2.0000000000
>pixdim3        2.0000000000
>pixdim4        1.0000000000
>cal_max        0.0000
>cal_min        0.0000
>file_type      NIFTI-1+
>
>Thanks in advance,
>
>  
>