[Nipy-devel] scl_slope value in test data

[rick reynolds]

Hi Chris and others,

The NIFTI group was happy to have updates for ANALYZE and swapping,
so I went ahead and made some.  If you don't like any of these, or
would really like a few more changes, please let me know.

1. A nifti_analyze75 struct was added in nifti1_io.h.  It matches the
   one published at the mayo site, except that it is one struct (like
   nifti), not a collection of 3.  It is binary compatible.

   Note that there is no difference between reading a nifti or an
   analyze header via nifti_read_header().  Only a cast of the returned
   pointer is "needed".

2. The swap_nifti_header function now swaps all (non-byte) fields, for
   both nifti and analyze headers.

    --> So there is no longer an endian inconsistency.  Displaying the
        analyze or nifti headers (via nifti_tool, say) should produce
        identical output, regardless of the CPU type (assuming the 
        datasets are valid enough so that the library knows whether or
        not to swap).

3. Options were added to nifti_tool (see -help for more details):

        -help_ana    : display the format of the nifti_analyze75 struct
        -disp_ana    : display the field contents of an analyze dataset

        -swap_as_analyze : these allow for specific swapping methods
        -swap_as_nifti
        -swap_as_old  

Besides being in the CVS trees (AFNI or sourceforge), the source is
available at the "quick download" location:

    wget http://nifti.nimh.nih.gov/pub/dist/data/Clibs.tgz

This should not aversely affect Michael Hanke's PyNIfTI interface.

Please let me know if you have any comments or questions.

Thanks,

- rick


> > On Thu, Jul 17, 2008 at 11:39 AM, Christopher Burns <cburns@berkeley.edu>
> > wrote:
> > 
> > > Hey Rick thanks for your reply!
> > >
> > > It would appear I was thrown by SPM's scalefactor extension to the Analyze
> > > format:
> > > http://imaging.mrc-cbu.cam.ac.uk/imaging/FormatAnalyze
> > >
> > > To fix my file problem I'll convert the file to a proper Nifti pair.
> > >
> > > Regarding Nifti's general support for Analyze... I think the nifticlibs
> > > should stay with the documented standards.  I'd like to think of them as
> > > 'the ground truth'.
> > >
> > > I do find it bothersome that nifti_tool returns a mixed endian display of
> > > the header.  I tend to use nifti_tool to display the headers when debugging.
> > >
> > > Would there be any problem if swap_nifti_header performed a byteswap on all
> > > (reasonable) fields so the header display makes sense.  It doesn't appear
> > > this would effect the nifti_image on load, nifti_convert_nhdr2nim only uses
> > > nifti values _if_ it's a nifti file.  So in this instance, the scl_slope is
> > > lost on read.  On save, the scl_slope would be written as zero, from
> > > nifti_image.  However, if a user knew the field had a real value, they could
> > > discover the value using nifti_tool and update the field (using nifti_tool?)
> > > before saving the image.   This would allow one to convert an spm analyze
> > > into a proper nifti.
> > >
> > > Thoughts?
> > > Chris
> > >
> > >
> > > On Thu, Jul 17, 2008 at 6:35 AM, rick reynolds <reynoldr@mail.nih.gov>
> > > wrote:
> > >
> > >>
> > >> Hi Chris,
> > >>
> > >> The scl_slope and scl_inter fields are not part of an ANALYZE
> > >> header, they are specific to NIfTI (according to nifti1.h, at
> > >> least).  So the NIfTI library does not touch them in the case
> > >> of an ANALYZE header.
> > >>
> > >> This is not nifti_tool, but the underlying NIfTI library, which
> > >> I believe nipy is written on top of.
> > >>
> > >> The ANALYZE-specific fields that the NIfTI library does swapping
> > >> on are: dim, pixdim, datatype, bitpix, vox_offset, cal_max and
> > >> cal_min.  This is the list of fields that is considered "common"
> > >> between the ANALYZE and NIfTI headers.
> > >>
> > >> This list does seem a little short to me, given the comparison
> > >> in nifti1.h.
> > >>
> > >> ---
> > >>
> > >> Fields could be added to the ANALYZE swap list.  Or I could add
> > >> another library function like nifti_swap_extra_analyze_fields().
> > >> That might be a safer route to go, as it would not affect any
> > >> existing software.  On the downside, it would not be currently
> > >> called by anyone, either.
> > >>
> > >> If, from your knowledge of ANALYZE datasets (I have little), the
> > >> swap list is too short, I could bounce the question by others
> > >> in the NIfTI group and see whether they would be bothered by
> > >> adding to it.
> > >>
> > >> What do you think?
> > >>
> > >> - rick
> > >>
> > >> > -----
> > >
> > >
> > 
> > 
> > -- 
> > Christopher Burns
> > Computational Infrastructure for Research Labs
> > 10 Giannini Hall, UC Berkeley
> > phone: 510.643.4014
> > http://cirl.berkeley.edu/