Hi,
Are you sure your files are Analyze?
Nifti images can either be stored as a single file (with a .nii
extension)
*or* as a file pair, using the same extensions as Analyze (that is, .hdr
and .img). If you do fslhd, and look at the "file_type" field (near the
end) that will tell you if it is ANALYZE, NIFTI-1 or NIFTI-1+ (the
latter is the one-file format).
All the best,
Mark
On 19 Dec 2007, at 20:53, Shawn Yeh wrote:
> Ahh, I made an assumption that the warning was only nifti related,
> and I
> guess it really applies to both analyze and nifti files. Sorry for
> the
> bother, this looks to be unrelated to FSL itself.
>
> On Wed, 19 Dec 2007 08:11:38 +0000, Steve Smith
> <[log in to unmask]> wrote:
>
>> Indeed - I think you would save yourself a lot of time by fixing the
>> input files to be valid NIFTI!
>> But yes, if you have set FSLOUTPUTTYPE to ANALYZE then I believe that
>> no NIFTI files should be generated at any stage.
>> Cheers.
>>
>>
>>
>> On 18 Dec 2007, at 23:29, Shawn Yeh wrote:
>>
>>> Hi, been reading the archive looking for clues to the WARNING: posn
>>> not header size messages in my
>>> log reports.
>>>
>>> One question: does FSL 4.0 use nii.gz formats for intermediate
>>> files generated during FEAT?
>>>
>>> I ask this because I attempted to do a FEAT report comparison using
>>> ANALYZE format (hdr/img) in
>>> FSL 4.0 with that of an older FSL 3.x report. I set the
>>> FSLOUTPUTTYPE to ANALYZE, which I thought
>>> should sidestep any nifti related warnings(such as posn not header
>>> size). However, I still
>>> encountered them in the report log. Some investigation has led me
>>> to believe that the warnings
>>> come from differently localized gzip/gunzip, as the same nifti files
>>> will report the warning (when
>>> using utils such as fslhd or fslinfo) when compressed (nii.gz), but
>>> seem normal when uncompressed
>>> (nii). Unless there are other changes when compressing a file to
>>> nii.gz, they ought be be identical, so
>>> my conclusion was that the fslutils are using a different build of
>>> gzip/gunzip than the ones on our
>>> machines.
>>>
>>> Of course, the likelihood is great that our conversion tool (UCLA)
>>> is the main culprit, but in the interim, I'd like to know of
>>> possible temporary solutions.
>>>
>>> Thanks in advance.
>>>
>>
>>
>> ---------------------------------------------------------------------
>> ------
>> Stephen M. Smith, Professor of Biomedical Engineering
>> Associate Director, Oxford University FMRIB Centre
>>
>> FMRIB, JR Hospital, Headington, Oxford OX3 9DU, UK
>> +44 (0) 1865 222726 (fax 222717)
>> [log in to unmask] http://www.fmrib.ox.ac.uk/~steve
>> ---------------------------------------------------------------------
>> ------
>> =====================================================================
>> ====
>
|