nifti2_data_format
12 Subscribers 
nifti2_data_format > NIFTI-2 proposal (initial discussion)
Showing 26-26 of 26 posts
Mar 15, 2011 06:03 PM | Cinly Ooi
RE: NIFTI-2 proposal
Originally posted by Mark Jenkinson:
This is definitely a topic not for nifti-2 but nifti long-term evolution.
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.
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.
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.
-
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.
This is definitely a topic not for nifti-2 but nifti long-term evolution.
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.
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.
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.