[Nipy-devel] scl_slope value in test data

[Christopher Burns]

Thanks Rick, this looks good.  I'll check out the source and take a look.

Chris

On Sun, Aug 3, 2008 at 2:40 PM, rick reynolds <reynoldr@mail.nih.gov> wrote:
> 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/
> _______________________________________________
> Nipy-devel mailing list
> Nipy-devel@neuroimaging.scipy.org
> http://lists.neuroimaging.scipy.org/mailman/listinfo/nipy-devel
>



-- 
Christopher Burns
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/