Hi,
Isn't this just the standard NIfTI intensity mapping using "scl_slope"
of 0.00326 (and scl_inter, which I assume here is 0)?
avwhd spm5/templates/EPI.nii | grep -E 'data_type|scl'
data_type UINT8
scl_slope 0.003260
scl_inter 0.000000
E.g. using Matlab/SPM5:
V = spm_vol(fullfile(spm('Dir'),'templates','EPI.nii'))
img = spm_read_vols(V);
max(img(:))
fid = fopen(V.fname);
dat = fread(fid, inf, 'uint8');
max(dat)
max(dat)*V.pinfo(1)
shows the behaviour I'd expect. max(dat) is 255, but the image
intensities read in via spm_read_vols (and presumably FSL?) are scaled
by scl_slope. This is helpful with e.g. spm5/tpm/grey.nii where the
scaling allows meaningful 0-to-1 probabilities to be stored as UINT8.
By copying all the header information, including scl_slope, your
binary 1 maps to 1*scl_slope or 0.003260.
avwmaths is then casting this to zero, instead of setting an
appropriate scl_slope on the output volume. I'm not sure if this is a
bug or a feature... Though I believe SPM5 usually recomputes scl_slope
for the output volume so that the raw data can be efficiently stored
in the chosen data-type, while the intensities remain the same.
In any case, feature or bug, if you make scl_slope 1 in your binary
mask header, all should be well. E.g. use avwedithd.
HTH,
Ged
Alle Meije Wink wrote:
> That is what I found strange as well!
>
> As I said earlier, I know how segmented.nii is written, I know that
> there are only 0 and 1 voxels in that image. I opened it in MriCro
> though, and all the in-mask voxels show value 1 / .003260 (I guess that
> means the vvalue stored in the voxel array is 1, but in some way this
> represents 0.003260).
>
> The header is cloned from the template. I know that is not the
> `cleanest' way to go about. That's probably why the range etc are not
> set to 0..1.
>
> Fact is that before avwmaths++ I see the shape of the mask, and voxels
> that are stored as 1. After avwmaths they are gone, so more happens than
> just a type conversion. Probably header information is used?
>
> Where should I send the data, if you want to have a look?
>
> Thanks
>
> AM
>
> Christian Beckmann wrote:
>> Hi,
>>
>> Your segmented.nii does not appear to be a binary image at all, the
>> robust range is 0 - 0.003260. How did you deal with the header
>> information in the new image then? Did you simply clone the header
>> from the epi template? This also already appears to be inconsistent
>> wrt to it's range and the data type. ? Maybe it's indeed worthwhile to
>> upload the data. What happens when you load the original epp.nii and
>> segmented.nii into fslview - what values are reporte? The behaviour of
>> avwstats++ is as I expect it to be - all values are cast to 0.
>> cheers
>> christian
>>
>>
>>
>> On 25 May 2007, at 23:16, Alle Meije Wink wrote:
>>
>>> Hi Christian,
>>>
>>> Hmm, well I did the same now with the diagnostics on our EPI template
>>> (which is basically the MNI template, but thresholded for air and
>>> with the eyes removed). That is a 16-bit image.
>>>
>>> ================================================
>>> $ export FSLOUTPUTTYPE=NIFTI
>>> $ avwhd++ EPI.nii | head -4
>>> filename EPI.nii
>>>
>>> sizeof_hdr 348
>>> data_type INT16
>>> $ avwstats++ EPI.nii -r -R
>>> 0.000000 0.547875 0.000000 0.831373
>>> $ segmentIm EPI.nii
>>> segmented image segmented.nii written (2 regions [1 clusters])
>>> $ avwhd++ segmented.nii | head -4
>>> filename segmented.nii
>>>
>>> sizeof_hdr 348
>>> data_type INT16
>>> $ avwstats++ segmented.nii -r -R
>>> 0.000000 0.003260 0.000000 0.003260
>>> $ avwmaths++ segmented.nii segmentedBYTE.nii -odt char
>>> $ avwhd++ segmentedBYTE.nii.gz |head -4
>>> filename segmentedBYTE.nii
>>>
>>> sizeof_hdr 348
>>> data_type UINT8
>>> $ avwstats++ segmentedBYTE.nii -r -R
>>> 0.000000 0.000000 0.000000 0.000000
>>> ================================================
>>>
>>> So first the diagnostics on the template. It's a 16-bit image. Its
>>> voxel values are just the same as the 8-bit MNI template, so not sure
>>> what the output of avwstats means.
>>> After that, segmenting the EPI template. 2 regions: the background
>>> and the brain. The diagnostics: still 16-bit data type, voxel values
>>> are 0 and 1 (I wrote the program that wrote the voxels), again not
>>> sure what avwstats output means.
>>> After that, cast the segmented image to char. The header shows that
>>> the data type has been changed. The stats show zero all...
>>>
>>> There's more happening there than just a type cast!!!!
>>>
>>> How can a integer-valued image have these float-valued stats?
>>>
>>> Would it help if I send you the images involved?
>>>
>>> I'm running
>>> Linux 3 2.6.10-1.771_FC2smp #1 SMP Mon Mar 28 01:10:51 EST 2005 i686
>>> i686 i386 GNU/Linux
>>>
>>> And the FSL I'm using for this is a compiled version of FSL-3.3.8
>>>
>>> Thanks,
>>> Alle Meije
>>>
>>> Christian Beckmann <[log in to unmask]> wrote: Hi,
>>>
>>> I can't replicate this on my laptop (mac os x). Instead, it works as
>>> expected - if I create a binary mask and then do the type conversion
>>> I still have the mask intact. AFAIK avwmaths does not use division
>>> but simply casts the values to the required type in the ususal c++ way.
>>>
>>> Here is what I did:
>>> i) load in avg152 in fslview and create a binary mask, save this to
>>>
>>> [Josi:~] avwhd avg152T1_brain-mask.nii.gz
>>> filename avg152T1_brain-mask.nii.gz
>>> sizeof_hdr 348
>>> data_type INT16
>>> ...
>>>
>>> This is a binary file:
>>>
>>> [Josi:~] avwstats avg152T1_brain-mask.nii.gz -r -R
>>> 0.000000 1.000000 0.000000 1.000000
>>>
>>> When using avwmaths++ to convert the file
>>>
>>> [Josi:~] avwmaths++ avg152T1_brain-mask.nii.gz test -odt char
>>>
>>> it remains a binary mask
>>> [Josi:~] avwstats test -r -R
>>> 0.000000 1.000000 0.000000 1.000000
>>>
>>> and has the desired type
>>>
>>> [Josi:~] avwhd test
>>> filename test.nii.gz
>>> sizeof_hdr 348
>>> data_type UINT8
>>> ...
>>>
>>> I guess we need to investigate - what platform are you running this
>>> on and did you compile yourself?
>>> cheers
>>> christian
>>>
>>>
>>> Yahoo! Mail is the world's favourite email. Don't settle for less,
>>> sign up for your free account today.
>>
>> ____
>> Christian F. Beckmann
>> University Research Lecturer
>> Oxford University Centre for Functional MRI of the Brain (FMRIB)
>> John Radcliffe Hospital, Headington, Oxford OX3 9DU, UK.
>> [log in to unmask] http://www.fmrib.ox.ac.uk/~beckmann
>> tel: +44 1865 222551 fax: +44 1865 222717
>>
>
|
