We appear to be padding to 8 bytes rather than 16, not sure how that happened. It should not affect us to change that (workbench doesn't care what the alignment is on reading), so I will make it pad to a multiple of 16 bytes.
Tim On Mon, Aug 19, 2013 at 10:44 AM, Matthew Brett <[email protected]>wrote: > Hi, > > On Mon, Aug 19, 2013 at 8:13 AM, Jennifer Elam <[email protected]> > wrote: > > Hi Matthew, > > > > The original NIFTI-1 file format was based on 16-bit signed integers and > was > > limited to 32,767 in each dimension. The NIFTI-2 format > > (http://www.nitrc.org/forum/message.php?msg_id=3738) > > is based on 64-bit integers and can handle very large volumes and > matrices. > > Thanks - I know what the nifti2 format is, partly because (as I > mentioned further up the thread) I have written my own io routines for > it in Python. > > My question was about your software's implementation of the standard. > I think (from the quotes in my email) the standard requires the > recorded extension size and the vox_offset field to be integer > multiples of 16. Do y'all agree with my interpretation of the > standard? > > Thanks a lot, > > Matthew > _______________________________________________ > HCP-Users mailing list > [email protected] > http://lists.humanconnectome.org/mailman/listinfo/hcp-users > _______________________________________________ HCP-Users mailing list [email protected] http://lists.humanconnectome.org/mailman/listinfo/hcp-users
