Dear All,

While NifTI tries its very best to be inclusive, there will always be time where the NifTI format did not account for certain use case, or advancement in the field required data to be stored in a way that NifTI did not anticipate.

In these cases, it is inevitable that developers will simply create a customised version of NifTI for their own use. NifTI's licensing T&C permits them to do this, giving us no recourse (even legal one) if someone insisting on customising NifTI. That is assuming we want to prohibit creation of customisation of NifTI in the first place which we don't.

We can, however, guide these customisation so that there will be less conflict with existing NifTI format. Some of these effort are simply minor changes that has very minor impact in everyday use of NifTI.

In NifTI, if we permit customisation in datatype (NIFTI_TYPE_*), intent code (NIFTI_INTENT_*), xform code (NIFTI_XFORM_), measurement unit (NIFTI_UNITS_) and slice sequence (NIFTI_SLICE_*), then together with nifti_extension, virtually anything we envisage to use in neuroimaging will be covered.

To provide guidance to customisation, what we have to do is to define a range, e.g. say 2020-2047 for NIFTI_INTENT_* (highest defined is 2005 for NIFTI_INTENT_SHAPE), which users can use to define anything they want. The NifTI standard will not use code in this range when defining new constants in return for them using codes in the defined range. This way, instead of user using any code to define their customisation, we restrict them to known codes.

In C, it is common to mark the range using a preprocessor constant, e.g
  
    #define NIFTI_INTENT_CUSTOM 2020   /* USER CUSTOM INTENT CODE 2020-2047 inclusive */

This system is like DICOM's even number group code, which DICOM reserves for use by anyone who care to put custom data into dicom.

Thanks
Cinly