nifti2_data_format > RE: 64-bit update to the NIfTI format
Mar 15, 2011  06:03 PM | Cinly Ooi
RE: 64-bit update to the NIfTI format
[First attempt was a disaster coz editor_plugin malfunctioned on my browser. Attempt 2 has formating error. This is attempt 3]

Originally posted by Mark Jenkinson:
Determining the NIfTI version
The following pseudo-code shows how a file can be tested to see: (a) if it is a NIfTI image file, (b) what version of NIfTI it is, and (c) whether byte-swapping is required.
read in the first 4 bytes from the file
let d = the content of these bytes, formatted as a 32-bit int
if (d==348) then it is a NIfTI-1 file, no byte-swapping required
else if (swap_4bytes(d)==348) then it is a NIfTI-1 file, but with byte-swapping required
else if (d==508) then it is a NIfTI-2 file, no byte-swapping required
else if (swap_4bytes(d)==508) then it is a NIfTI-2 file, but with byte-swapping required
else it is not a valid NIfTI file



Can I suggest putting the magic string test earlier:
read in the first 4 bytes,
let d = the content of these bytes, formatted as a 32 bit int
read in the next 8 bytes
let m = the content of these bytes, formatted as char[8]
jump to the magic string location for NIfTI1. Read in 4 bytes
let m1 - content of these bytes, formatted as char[4];

let byteSwap = UNKNOWN
let actualHdrSize = UNKNOWN
let magicStringType = UNKNOWN

if(d==348 or d==508) then
   let actualHdrSize=d
   let byteSwap=FALSE
else if (swap_4 bytes(d)==348 or swap_4bytes(d)==508) then
   let actualHdrSize = swap_4bytes(d)
   let byteSwap=TRUE

if(testNifTI1MagicString(m1)==TRUE) then
   magicStringType = NIFTI-1
if(testNifTI2MagicString(m) == TRUE) then
   magicStringType = NIFTI-2

if(actualHdrSize==348 and magicStringType == NifTI-1) then we have NifTI 1. STOP
if(actualHdrSize==348 and magicStringType == UNKNOWN) then we have Analyze File. STOP
if(actualHdrSize==508 and magicStringType == NIFTI-2) then we have NifTI 2. STOP
FAIL as we don't have Nifti1 or 2 or Analyze.

C Header Struct[/b]



(1) datatype, intent_code:
can we bump it up to integer to increase the range of available value.

I am glad that the committee agree to make a range of values available for customization. For intent_code at least, I think the existing code fill up almost the full spectrum, meaning available range for customization is small and have to be squeeze in. This means it is more likely that anyone using customization might find their value used by other person. Granted, this is an issue for the developer to sorted out between themselves. However, it will be good to provide sufficient range that collision rarely happens.
For others, it is easier if I simply have to check a bit to tell whether someone had used a custom value, i.e. I will prefer

if ( intent_code & 1<<64 ) then custom intent code used

Instead of
if (25530<25556) then custom intent code used.


(2)slice_start, slice_end :

Is it big enough to accommodate all possible slice value, especially since dim[3] is now int64. Recommend bump them up to int64 as well.


(3) qform_code, sform_code:

Bump up to int for the same reason as datatype??


(4) quantern_a:

Is it still pixdim[0]?

Threaded View

TitleAuthorDate
Mark Jenkinson Mar 15, 2011
RE: 64-bit update to the NIfTI format
Cinly Ooi Mar 15, 2011
Mark Jenkinson Mar 16, 2011
Cinly Ooi Mar 17, 2011
Cinly Ooi Mar 16, 2011
Cinly Ooi Mar 15, 2011