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.
Hope that helps, Jenn Jennifer Elam, Ph.D. Outreach Coordinator, Human Connectome Project Washington University School of Medicine Department of Anatomy and Neurobiology, Box 8108 660 South Euclid Avenue St. Louis, MO 63110 314-362-9387 [email protected] www.humanconnectome.org -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Matthew Brett Sent: Sunday, August 18, 2013 2:41 AM To: [email protected] Subject: [HCP-Users] Fwd: Nifti2 extensions - are they converted correctly? Hi, On Fri, Aug 2, 2013 at 5:19 PM, Timothy Coalson <[email protected]> wrote: > There is a large amount of workbench-written cifti data available in > the hcp data releases (http://www.humanconnectome.org/data/), which > are nifti2 files, though you have to agree to data use terms (don't > try to identify subjects, attribution for research) to get them, and > then do a little digging to find one (.dtseries.nii, or .dconn.nii if > you want something large). > > I don't know of any "reference" nifti2 files made easily available for > testing, though. I think I've found another problem with the nifti2 files and extensions. I downloaded some example files to look at, and our software gave an error reading the extensions of the nifti2 files. Looking into it, it seems that the extensions often have extension length (esize) that is not divisible by 16, as specified in the standard: http://nifti.nimh.nih.gov/nifti-1/documentation/nifti1fields/nifti1fields_pa ges/extension.html/view?searchterm=extension "esize is the number of bytes that form the extended header data + esize must be a positive integral multiple of 16 + this length includes the 8 bytes of esize and ecode themselves" Here is the first file that I tried: hexdump -d -s 540 -n 16 100307/MNINonLinear/100307.aparc.164k_fs_LR.dlabel.nii 00001 00000 63144 00028 00032 00000 15370 18755 Here the first 4 bytes are correct - 1 0 0 0. 63144 and 00028 are the esize. However: In [3]: (63144 + 28 * 2 ** 16) / 16. Out[3]: 118634.5 So the esize value is not divisible by 16. I noticed the vox_offset in the main header was also often not divisible by 16. This is also recommended by the nifti1 standard: http://nifti.nimh.nih.gov/pub/dist/src/niftilib/nifti1.h "When the dataset is stored in one file, the first byte of image data is stored at byte location (int)vox_offset in this combined file. The minimum allowed value of vox_offset is 352; for compatibility with some software, vox_offset should be an integral multiple of 16." By the way - it looks like the extension type code (ecode) is 32 - but I can't see that documented here: http://nifti.nimh.nih.gov/nifti-1/documentation/faq#Q21 Do you have any documentation on that? 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
