Dear Mike,
Fixing these images turned out to be quite tricky due to several issues of
incorrect scaling, incorrect datatype and byte swapping. However, using
a combination of nifti_tool and fslmaths it can be fixed with the following
set of commands:
export FSLOUTPUTTYPE=NIFTI_PAIR
nifti_tool -mod_hdr -prefix orig2 -infiles original.hdr -mod_field scl_slope 0.0
nifti_tool -mod_hdr -prefix orig3 -infiles orig2.hdr -mod_field datatype 512
fslmaths orig3 orig4
fslmaths orig4 -sub 32768 orig5
fslmaths orig5 -uthr 0 -mul -1 orig5neg
fslmaths orig5neg -bin -mul -1 -add 1 -bin -mul orig5 orig5pos
fslmaths orig5neg -mul -1 -add 65536 -mas orig5neg -add orig5pos orig5fix
The final, fixed image is orig5fix
If you don't have nifti_tool then you need to download nifti_clib by going to:
http://sourceforge.net/projects/niftilib/
Then, once you have the tar file, move it somewhere you want and then just do:
tar -zxvf nifticlib-2.0.0.tar.gz
cd nifticlib-2.0.0
make
and at this point nifti_tool should be in the bin directory, and ready for use.
If you want it generally available, you could copy it to $FSLDIR/bin/
If you then follow the above steps for all your images separately, then
it should allow you to recover them.
All the best,
Mark
On 9 Nov 2010, at 19:31, Mark Jenkinson wrote:
> Hi Mike,
>
> Thanks for sending the data.
> DO NOT use it as it is or with any scaling.
> It is definitely byte swapped, and most intensities
> are around 1e32, which is why you see a blank
> screen in FSLView. If you change the display
> range to this then you see an inverted outline,
> but essentially everything there is unusable in
> its present form.
>
> This problem is due to both the header and the data
> having different conventions for the byte ordering
> (or endianness) as well as the ridiculous value of the
> intensity offset (-72534755819308628381974659072.000000).
>
> It is probably possible to fix the files but I'll have
> to get back to you on that soon. Just don't use the
> data in the meantime as it is not usable as it is or
> in a scaled form.
>
> All the best,
> Mark
>
>
>
>
>
> On 9 Nov 2010, at 16:21, Mark Jenkinson wrote:
>
>> Hi,
>>
>> I would be very wary of this as I suspect that there is a byte
>> swapping issue happening and this can corrupt data in both
>> a very obvious way and also in very subtle ways. The division
>> trick just doesn't work in this case.
>>
>> Probably best if you can upload an example to our site at:
>> http://www.fmrib.ox.ac.uk/cgi-bin/upload.cgi
>> and send us the reference number. I've seen this kind of
>> thing before so should be able to figure out what needs to
>> be done.
>>
>> All the best,
>> Mark
>>
>>
>> On 9 Nov 2010, at 16:08, Matt Glasser wrote:
>>
>>> You could divide the images by some number to get them to more reasonable
>>> values. If the relative intensities in the image make sense then the data
>>> is probably ok. If the image is all the same intensity or doesn't make
>>> sense after lowering the values, then you are probably stuck.
>>>
>>> Peace,
>>>
>>> Matt.
>>>
>>> -----Original Message-----
>>> From: FSL - FMRIB's Software Library [mailto:[log in to unmask]] On Behalf
>>> Of Mike Sugarman
>>> Sent: Tuesday, November 09, 2010 9:03 AM
>>> To: [log in to unmask]
>>> Subject: Re: [FSL] High Intensity Values
>>>
>>> Are you sure there's no way to salvage the scan? My original scan is in .img
>>> format, and although the intensity values are very high, I can still view
>>> the scan; the surrounding space outside the head just also has very high
>>> values (and displays as white in the viewer) and I am unable to perform BET
>>> on it.
>>>
>>> Thanks,
>>> -Mike
>>>
>>
>
|