Dear all,
Sorry for raising this subject again...
I'm trying to circumvent an intensity scaling problem happening after using SPM5 for the spatial processing of arterial spin labeling (ASL) images.
I noticed the image intensity of the ASL images changed after normalization and I don't know how to calculate the scaling factor (I presume the offset is 2048)...
As proposed below, I tried to convert the 16-bit integer ASL files into 32-bit (float) files prior to normalization.
I tried to do it by using:
1) MRIcro: File → Save as... → 32-bit integer → etc. etc. etc.
2) ImCalc: using the expression: 'i1',{0,0,spm_type('float32'),0}
The result differs between these approaches and, in both of them; there is a change of the intensity values as well...
What should I do to convert the files?
Alternatively, how can I calculate the scaling factor? (to avoid converting the files and repeat all the spatial processing again...)
Regards,
Antonio
-----Mensagem original-----
De: SPM (Statistical Parametric Mapping) [mailto:[log in to unmask]] Em nome de Ged Ridgway
Enviada: terça-feira, 12 de Setembro de 2006 11:45
Para: [log in to unmask]
Assunto: Re: [SPM] Image intensity
Hi All,
Volkmar Glauche wrote:
> As an example, tissue probability maps which contain
> values between 0 and 1 would become binarised when stored as uint8 data if
> there was no scaling factor to map 0 to 0 and 1 to 255.
In case anyone's interested, it's reasonably simple to change
spm_preproc_write (I think that was the only file) so that it writes
everything as float32 with unity scaling. I did it on a previous
revision of the software, so can't provide uptodate files, but could
probably help if anyone needs to do this.
> DICOM conversion does not scale the data, therefore raw images will have
> scale factor 1.
I'm a bit puzzled by this, Volkmar... some DICOMs that I've looked at
are 16 bit unsigned integers, which appear to have window-width/centre
scaling. E.g. medcon reports these fields:
(0028,0100) US[1] BitsAllocated: 16 (2 bytes)
(0028,0101) US[1] BitsStored: 16 (2 bytes)
(0028,0102) US[1] HighBit: 15 (2 bytes)
(0028,1050) DS[1] WindowCenter: [4416] (4 bytes)
(0028,1051) DS[1] WindowWidth: [8833] (4 bytes)
So I would hope that SPM doesn't *re*-scale the data, in the sense of
uint16 values remaining unchanged, but this will mean that the scale
factor and offset will have to be chosen appropriately (i.e. not 1,0)
to give the same reported intensities as the window and centre.
It's quite possible that I'm talking nonsense though...
> If you need to export data with fixed scaling factors, use the Volumes
> toolbox available from the SPM extensions page.
Another simple way of getting unity-scaling float output is to use imcalc:
spm_imcalc_ui('in.img','out.img','i1',{0,0,spm_type('float32'),0})
Though I expect the volumes toolbox might be quicker if you have a lot
of files you want to convert...
Best,
Ged.
|