 |
 |
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 > URL: http://www.fmrib.ox.ac.uk/~flitney > > > >