Hi Dave, I get it now.

To record, for future users: 

I ran into trouble because of importing the nifti raw (INT16) to matlab, doing quantitative analyses and then saving  the result with the "same" header information (using save_untouch_nii), thus confusing FSL with an arbitrary scale slope (since it was already factored out of data through the analyses), hence magnifying my expected quantities by an order of ~2! 

Thanks everyone for your help.

(Now, is there already a script to divide a 4D volume by a vector? ;) )
 
Best
Naj




On Tue, Feb 23, 2010 at 3:20 PM, David Flitney <[log in to unmask]> wrote:
I.e. the value IS 1165.95 regardless of underlying representation? This would seem entirely correct to me. The fact that the INT16 value needs to be scaled by 2.268.... is correct. Otherwise when viewing the INT16 image it would, incorrectly, report an intensity of 514!!

On 23 Feb 2010, at 13:19, Najmeh Khalili-Mahani wrote:

Thanks Matthew, 

However,

in "raw" file 4D file A      (INT16)      intensity of  voxel(36,26,8,0) is 1165.95 and the  scl_slope = 2.268376.
in vol0 of 'fslsplit'ted file (FLOAT32) intensity of voxel (36,26,8)    is 1165.95 and the scl_slope = 1.000000 

So, it seems to me that fslsplit has changed the data type, and the scale-slope label, without scaling the actual intensities?

?

Tnx,
Naj






On Tue, Feb 23, 2010 at 1:36 PM, Matthew Webster <[log in to unmask]> wrote:
Hi,
     I just spotted that your file had a non-unitary scl_slope - this means that your file is read in as a float to honour the scl_slope value ( e.g. for voxel (36,26,8,0) the "raw" stored value is 514, multiplied by the the scl_slope this gives 1165.95 which will be the value used in our tools, and the output files will be saved with the scaled values and a scl_slope of 1.0 ).

Hope this helps,
Many Regards
Matthew

Hi Matthew, 

While at it, it seems that the fslsplit also sets the scl_slope to 1.00 (without scaling the intensities with the initial scl_slope?)? 

Many thanks
Naj


On Tue, Feb 23, 2010 at 10:10 AM, Matthew Webster <[log in to unmask]> wrote:
Hello!
           I've been able to replicate this behaviour locally ( it seems to be for 4D splits only ) and we're looking into a fix...

Many Regards
Matthew
Hello;

I just noticed that running fslsplit changed the data type?!

I had a 4D image of (INT16) which is split into (FLOAT32) files. Attached, the histograms. Top (float32), bottom (INT16). 

Many thanks
Naj
<bad_top_good_below.tiff>





-- 
Dave Flitney, IT Manager
Oxford Centre for Functional MRI of the Brain
E:[log in to unmask] W:+44-1865-222713 F:+44-1865-222717