 |
 |
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 >>> >> >