NITRC GIFTI Forum: devel

RE: Writing vertex-wise probability vectors akin to FreeSurfer's GCS files

Richard Reynolds — Fri, 15 Mar 2024 17:18:11 GMT

As far as I can tell, NIFTI_INTENT_VECTOR is not restricted to length 3, though the included examples are of that length.  I think dim[5] would specify the length of the nodewise vectors.
Having said that, when I copy a mixed-stats dataset (beta/t-stat/F-stat) into GIFTI format, the INTENTs are specified one index at a time, meaning the dataset is a list of DataArray elements.  Given that, the intent_code might refer to the actual data, not the fact that there is a vector of such values at each node.  So it might be reasonable to use NIFTI_INTENT_ESTIMATE (or even NONE), for example.  I don't see anything to specifially note a probability, unless the values were from a specific distribution, like NIFTI_INTENT_GAMMA.
<ul>
<li>rick</li>
</ul>

RE: Writing vertex-wise probability vectors akin to FreeSurfer's GCS files

John Harwell — Thu, 14 Mar 2024 14:21:51 GMT

Oscar,
There is NIFTI_INTENT_VECTOR.  While the format states that it is for three-dimensional vectors, I think it would be okay to use for vectors of any dimension.
I have included a section of the GIFTI specification on extending GIFTI.  You could use NIFTI_INTENT_NONE or create a new intent as specified in the second paragraph (below).  Either way, you may want to put something in the metadata, perhaps a URL or email address for a description of the file’s content.  
I was unable to find a description of FreeSurfer’s GCS format.
John Harwell
 
 
 
12.0 Extending GIFTI 
This document describes the initial version of the GIFTI Surface Data Format. The data array intents in this version of GIFTI are those categories of data commonly interchanged between the various neuroimaging software packages. Developers are encouraged to use the GIFTI file format for new data intent types that do not require the addition of new XML tags. It is not necessary for developers to get approval of the GIFTI committee to add a new type of data intent. However, the GIFTI mailing list should be used to announce the new data intent to assess interest in the new data intent becoming an official GIFTI data intent.
When naming a new data intent, a process similar to that used for OpenGL extensions (<a title="http://en.wikipedia.org/wiki/OpenGL#Extensions" href="http://en.wikipedia.org/wiki/OpenGL#Extensions">http://en.wikipedia.org/wiki/OpenGL#Extensions</a>) should be followed. In the case of GIFTI, the name of the new data intent should begin with the name of the neuroimaging software package creating the new data intent. For example, if the developers of Caret wanted to store latitude/longitude data in a GIFTI data file, the data intent would initially be named “CARET_INTENT_LATITIUDE_LONGITUDE”. If the GIFTI committee supported the addition of this new data intent, its name would change to “NIFTI_INTENT_LATITUDE_LONGITUDE”.

Writing vertex-wise probability vectors akin to FreeSurfer's GCS files

Oscar Esteban — Thu, 14 Mar 2024 12:46:04 GMT

After carefully reading the specifications, it is my impression that there is not a proper intent code to encode surfaces where vertices have associated a vector of probabilities.
In this case, should we use NIFTI_INTENT_NONE? I think it would also be possible to "hack" my way around using NIFTI_INTENT_TIME_SERIES, but it doesn't seem very reasonable.
A further complication is that GCS (Gaussian Classifier atlas Surfaces) files of FreeSurfer also store some sort of local information about "cliques".
Would this use case justify the creation of a new data intent?

Suggestions to aid developers

Chris Rorden — Tue, 08 Jan 2019 14:31:45 GMT

1.) BrainVisa samples should be removed from the NITRC GIfTI downloads (or the data updated so the combination of matrix and vertex location matches the expectation of the specification. To demonstrate the issue, these images appear upside down in [url=https://github.com/Washington-University/workbench/issues/28]connecotme workbench[/url].

2.) Section 5.0 ("Data Compression") of the specification should include a sentence explicitly describing the encoding used. I would write 'The tag "Encoding="GZipBase64Binary" denotes the data is compressed using the deflate algorithm with the standard zlib 2-byte header and 4 byte footer (https://tools.ietf.org/html/rfc1950). Therefore the first byte of the compressed datastream will be 0x78. Be aware that GIfTI compressed files do not use the 10+ byte GZip header and 8-byte footer (https://tools.ietf.org/html/rfc1952) typical of GZip files compressed using the deflate algorithm (where the first two bytes are 0x1f8b).' if you want to describe all the GIfTI images I have seen (or if either RFC1950 and RFC1952 are acceptable this should be explicitly described and samples provided). The issue I ran into reading the documentation is that GIfTI uses the key "GZip" which is is associated with RFC1952, but in practice I needed to implement RFC1950.

These two changes would make it easier to develop and validate tools using this format.

RE: BrainSuite

David Shattuck — Mon, 02 May 2011 21:46:33 GMT

[i]Originally posted by Leonardo Barbosa:[/i][quote]Completely agree with that.

I'm having a hard time using it outside BrainSuite.

I can help to implement.[/quote]
[color=#000000]I just found this post today -- we plan to add GIFTI support. For now, if you need to work with BrainSuite files outside of our tools, you might want to look at this page:[/color]

[color=#000000]http://users.loni.ucla.edu/~shattuck/brainsuite/file-formats/dfs/[/color]

[color=#000000]which describes the format and has some links to source code for reading/writing the files.[/color]

[color=#000000]cheers,[/color]
[color=#000000]David Shattuck[/color]
[color=#000000] [/color]

RE: Valid GIFTI Data Array Dimensions

John Harwell — Wed, 20 Apr 2011 15:36:18 GMT

We received a functional file with a DataArray that had dimensionality=2 with Dim0=1 and Dim1=73xxx. The GIFTI Document does state (13.2) that a functional DataArray is Dimensionality=1 and Dim0=#nodes so it is technically not a valid functional file. Is there any valid case for a two-dimensional DataArray with the first dimension equal to one?

RE: Valid GIFTI Data Array Dimensions

Simon Warfield — Wed, 20 Apr 2011 15:07:05 GMT

What is the objective of making this change ?

Valid GIFTI Data Array Dimensions

John Harwell — Wed, 20 Apr 2011 14:53:57 GMT

In the GIFTI Document (2.3.4.4) it states "The last dimension shall never be one (The only exception is if the array contains one data value in which case Dim0 will be one)". Thus, a DataArray with "Dimensionality=2, Dim0=73730, Dim1=1" is invalid and should be "Dimensionality=1, Dim0=73730".

Does this also apply to the first dimension? Is a DataArray with "Dimensionality=2, Dim0=1, Dim1=73730" valid? Or should it be a one-dimensional array with "Dimensionality=1 Dim0=73730"?

I would like to change the GIFTI Document to state that "Neither the first, nor the last dimension shall be one (The only exception is if the array contains one data value in which case Dim0 will be one)".

RE: RGBA files

John Harwell — Mon, 14 Mar 2011 17:55:44 GMT

An unreleased version of Caret is able to read the RGBA file. Image is attached.

RGBA files

Arne Hans — Mon, 28 Feb 2011 21:07:40 GMT

As Ziad requested, let's continue the discussion about GIFTI RGBA files here on the message board.

I have attached a sample GIFTI surface and a sample RGBA file to go with it. The PNG screenshot illustrates how the colors should look like.
The data type of the RGBA file is float, with values between 0.0 and 1.0.