Hi,
Sorry - FSL can only write files in the local machine ordering.
It didn't seem worth changing our i/o library just to make avwcreatehd
++ more
general so it also writes everything out in local ordering, and hence
the critical
codes that determine byte-ordering in nifti get written like that
too. FSL will read
files with any orderings, but you'd need to find a header that has
the alternative
byte-ordering in order to get the image read correctly. If you
really needed a
different header and didn't have access to an appropriate machine,
then I'd
recommend using matlab and just modifying our read_avw_img to ignore
take
a user-defined ordering, then write it out with the reversed (native)
ordering.
As for your second question - the origin in Analyze is a real hack
and is stored
in an array of short ints, and so that's all it can handle.
Therefore there is
nothing more you can do with Analyze. This is one (of many) useful
improvements
in nifti.
All the best,
Mark
On 22 May 2007, at 13:57, Ged Ridgway wrote:
> Hi all,
>
> I'm using avwcreatehd++ from an .xml file that I've created (in
> order to convert "raw" MRI volumes to NIfTI)
>
> It seems to ignore the specification of
> byteorder = 'MSB_FIRST'
> and instead create LSB_FIRST NIfTI images (on an LSB_FIRST AMD/
> Linux system). Is this is a bug or a feature? ;-)
>
> The raw data I have are MSB_FIRST even though I am working on an
> LSB_FIRST system, and I was under the impression that this could be
> true of the NIfTI volumes too, no? Does avwcreatehd always create
> LSB_FIRST, or does it always match the local machine byte-order?
>
> My second query is that when creating Analyze images (or using
> avwchfiletype ANALYZE on previously created NIfTIs) the origin
> information is converted to integers. Is this deliberate? I guess
> that origin-offsets (or more general voxel-world mapping) was never
> really properly standardised for Analyze images, but would using
> floats for origin-offsets be significantly more non-standard (!)
> than integers?
>
> Thanks,
> Ged
|