NITRC NIfTI Forum: nifti2_data_format

DWI B0 with gradient values

elisajulia — Mon, 09 Aug 2021 10:51:07 GMT

Hi,
I am trying to work with some nifti DWI data, obtained from the ISMRM 2021 challenge. This dataset consist of 99 patients, each with some DWI images, for which the bvals and bvecs values are attached (32 directions and B=1000, 1 B=0 image).

I was expecting that the B=0 image had [0, 0, 0] as gradient vector. However, there is no such value in the bvecs value (it is an 33x3 array, all different than 0). Attached is the bvecs file.

I was wondering what does it mean to have a B=0 image with some gradient directions, and what type of processing/transform do I have to do to obtain the expected vectors.

Thank you very much.

RE: creating nifti1 images with library v2?

Richard Reynolds — Thu, 04 Mar 2021 23:58:45 GMT

Hello,

AFNI can handle NIFTI-2 files, though not for every datum (e.g. no 64-bit floats). And the nifti_tool program (from AFNI or from the NIFTI library) can be used to verify them, too.

If you would like, post the output of:
[code]nifti_tool -disp_hdr -infile MY_NIFTI2.nii[/code]
for your image (assuming MY_NIFTI2.nii here)?

- rick

RE: creating nifti1 images with library v2?

Jon Clayden — Tue, 02 Mar 2021 17:09:14 GMT

I don't know the details of FSL or mricron's NIfTI-2 support, but it is possible that the issue is with the NIfTI-2 library itself. I [url=https://github.com/NIFTI-Imaging/nifti_clib/pull/124]ran into problems[/url] (link) with producing valid NIfTI-2 files with the library last year, and although that is patched on GitHub I don't think it has propagated to a generally released version yet. If you can, it might be worth dropping in the latest library from GitHub to see if that helps.

Regarding your other question, it is possible to create NIfTI-1 images with the NIfTI-2 library, by setting the nifti_type field to NIFTI_FTYPE_NIFTI1_1 (or NIFTI_FTYPE_NIFTI1_2) before calling nifti_image_write().

I hope that's helpful!

creating nifti1 images with library v2?

Alle Meije Wink — Tue, 02 Mar 2021 14:51:54 GMT

I am using the latest version of the nifti library in my program and when I save images to (nifti-2) files, neither fsl nor mricron (on a Ubuntu Focal system) accept them. The program can read nifti-2 images that it has just saved (putting the bar low), but it would be nice to have an external reference!

Are there any open-source image viewers that already support nifti-2? Or, failing that, is it possible to create nifti-1 images with the nifti-2 library? The only routine that seems available for creating a new nifti image seems to be nifti_simple_init_nim(), which only makes nifti-2.

Many thanks!

RE: 64-bit update to the NIfTI format

Cinly Ooi — Thu, 17 Mar 2011 13:39:27 GMT

[i]Originally posted by Mark Jenkinson:[/i][quote]Thank you for your thoughtful response to the format revision.

We have taken aboard you comments and made changes to the revised format (the original message in this thread has been edited appropriately). In particular, we agreed that it seemed necessary for consistency to have slice_start and slice_end set to int64_t. In addition, and to ensure 8-byte alignment, we have upgraded the other fields to int, except for datatype which we feel still has sufficient capacity (with at least 240 codes still left, and there being a limit to how many different types of data might be stored without requiring extensions to decode the datatypes).

The code range for the custom codes is still to be defined, but it is likely to be a limited range (and not set bitwise) since the use of custom codes is only encouraged as a very temporary measure, with the expectation that useful elements will be registered and obtain official codes. Otherwise there is a risk of the format becoming less open and accessible for all users.

As a consequence the header is now 540 bytes + 4 bytes for the initial extension info (total of 544 bytes).[/quote]
Thank you for considering and adopting some of my proposal. I'm sorry I caused you more work. It was much more work than I was anticipating[quote]The unused_str will be forced to be filled with \0 characters.

Finally, in answer to your last question, the quatern_a is still stored in the same way (via pixdim[0]) in order to retain the same logic as NIfTI-1 and make the implementation change easier for developers. I fully expect that future formats will not follow this scheme, and this should be raised in that forum, but for now it is the most consistent and simplest way of modifying the existing format.[/quote]
[color=#000000]I agree with your decision. My original intention is just to conform quatern_a is still pixdim[0] as I had inferred it to be.[/color]

[color=#000000]Thank you.
[/color]

RE: 64-bit update to the NIfTI format

Mark Jenkinson — Wed, 16 Mar 2011 22:56:43 GMT

Thank you for your thoughtful response to the format revision.

We have taken aboard you comments and made changes to the revised format (the original message in this thread has been edited appropriately). In particular, we agreed that it seemed necessary for consistency to have slice_start and slice_end set to int64_t. In addition, and to ensure 8-byte alignment, we have upgraded the other fields to int, except for datatype which we feel still has sufficient capacity (with at least 240 codes still left, and there being a limit to how many different types of data might be stored without requiring extensions to decode the datatypes).

The code range for the custom codes is still to be defined, but it is likely to be a limited range (and not set bitwise) since the use of custom codes is only encouraged as a very temporary measure, with the expectation that useful elements will be registered and obtain official codes. Otherwise there is a risk of the format becoming less open and accessible for all users.

As a consequence the header is now 540 bytes + 4 bytes for the initial extension info (total of 544 bytes).

The unused_str will be forced to be filled with \0 characters.

Finally, in answer to your last question, the quatern_a is still stored in the same way (via pixdim[0]) in order to retain the same logic as NIfTI-1 and make the implementation change easier for developers. I fully expect that future formats will not follow this scheme, and this should be raised in that forum, but for now it is the most consistent and simplest way of modifying the existing format.

RE: 64-bit update to the NIfTI format

Cinly Ooi — Wed, 16 Mar 2011 15:31:06 GMT

One more thing to ask, which I only realized once I start to think through how I am going to use NifTI-2: Any chance of requiring all unused field and empty byte after the string termination character for the field to be set to \0?

Right now with NifTI-1 I have to use nifti_tool -diff to compare two headers, because it ignore rubbish that might be present in unused field or empty space after string termination character. it would be useful to be able to use standard UNIX diff as well. Furthermore, the proposal works better with revision control system: the difference in unused field or space after termination character will cause them to treat two identical nifti files (in information) as different.

RE: 64-bit update to the NIfTI format

Cinly Ooi — Tue, 15 Mar 2011 18:46:59 GMT

Sorry, editor_plugin.js failed on my browser (corrected)

RE: 64-bit update to the NIfTI format

Cinly Ooi — Tue, 15 Mar 2011 18:45:54 GMT

[First attempt was a disaster coz editor_plugin malfunctioned on my browser. Attempt 2 has formating error. This is attempt 3]

[i]Originally posted by Mark Jenkinson:[/i][quote][color=#00e000]Determining the NIfTI version[/color]
[color=#00000f]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.[/color][color=#00000f]
[/color][color=#00000f]read in the first 4 bytes from the file[/color][color=#00000f]
[/color][color=#00000f]let d = the content of these bytes, formatted as a 32-bit int[/color][color=#00000f]
[/color][color=#00000f]if (d==348) then it is a NIfTI-1 file, no byte-swapping required[/color][color=#00000f]
[/color][color=#00000f]else if (swap_4bytes(d)==348) then it is a NIfTI-1 file, but with byte-swapping required[/color][color=#00000f]
[/color][color=#00000f]else if (d==508) then it is a NIfTI-2 file, no byte-swapping required[/color][color=#00000f]
[/color][color=#00000f]else if (swap_4bytes(d)==508) then it is a NIfTI-2 file, but with byte-swapping required[/color][color=#00000f]
[/color][color=#00000f]else it is not a valid NIfTI file[/color][color=#00000f]
[/color][/quote]

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.

[quote] [b][color=#00000f]C Header Struct[/color][/b][/b][/quote]

[u][b](1) datatype, intent_code: [/b][/u]
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.

[u][b](2)slice_start, slice_end : [/b][/u]

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.

[u][b](3) qform_code, sform_code: [/b][/u]

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

[b][u](4) quantern_a: [/u][/b]

Is it still pixdim[0]?

RE: NIFTI-2 proposal

Cinly Ooi — Tue, 15 Mar 2011 18:18:22 GMT
[i]Originally posted by Mark Jenkinson:[/i][quote]<span style="font-family: Helvetica; font-size: medium;">[b] [/b]</span>- A request to have a pure XML header is also a major change and shares some of the same issues as the above request, and so should be forwarded to the discussion forum for future formats. Note that there has never been an official nifti-1 format that allowed a purely XML header - there is some code in nifticlib to allow such XML to be generated, but this was never part of the official nifti-1 specification.[/quote]
[color=#000000]This is definitely a topic not for nifti-2 but nifti long-term evolution.[/color]

[color=#000000]XML is great, except if you try to use it to represent binary data, then, IMHO, it's horrible. I hope with XML header it is image.xml/image.img pair, not image.xml where the img data is a binary blob. The binary blob will complicate showing the XML in simple viewer, e.g. Firefox browser. Also, with XML, in theory you cannot stop programs putting the binary blob as the first XML element. This will make it very difficult to see the non-binary blob because the binary blob is huge.[/color]

[color=#000000]One suggestion is to follow the Eclipse plugin's jar file, which is now adopted by Microsoft in docx, xlsx format and ODF. Basically it is a zip file of directories and files. [Unzip a docx and you will see what I mean (Unix user note: Microsoft has a lot of important files in the zip package with name startiing with a dot which unix will treat it as 'hidden file). We don't need such a complex structure and multiple xml file to hold file control data. A simple one one will do. The advantage of this approach is we have one zip file that can carry any data we want, including XML, binary, jpeg etc. The data are carried separately as we will expect.[/color]

[color=#000000]If we go down this route, we should also allow the nifti library to interpret an unzipped directory as well. For example, if your mydata.niz zip file contain MANIFEST.xml, data/image.img, data/image.xml, icon/my.jpg, then it can also read the directory mydata/ whose content directory content is exactly like the zip file. With the unzipped directory it is easier to change the data, useful for testing. In fact, in the Eclipse system, if I have not mistaken, if there is a choice of plugin_1.0.0.jar or plugin_1.0.0 directory, the directory will be read instead of the jar file.
[/color]