open-discussion
open-discussion > RE: Shared NIRS Data Format - SNIRF
Nov 5, 2012 04:11 PM | David Boas
RE: Shared NIRS Data Format - SNIRF
I respond to 3 points from the message copied below:
1) Description for ml has been updated in the spec on google docs to indicate that detector indicies also generally refer to opt ode naming and not necessarily the physical detector numbers on the hardware.
2) regarding adding an additional variable describing the geometry associated with qform, I hope that Mathieu Coursolle, Blaise, and others can resolve this.
3) Regarding data types, I agree that unless otherwise specified it will be double.
Originally posted by Blaise Frederick:
1) Description for ml has been updated in the spec on google docs to indicate that detector indicies also generally refer to opt ode naming and not necessarily the physical detector numbers on the hardware.
2) regarding adding an additional variable describing the geometry associated with qform, I hope that Mathieu Coursolle, Blaise, and others can resolve this.
3) Regarding data types, I agree that unless otherwise specified it will be double.
Originally posted by Blaise Frederick:
Originally posted by Mathieu Coursolle:
In the optional variables, the "qform" variable specified a 4x4 matrix to align the NIRS coordinate system to other geometries. Would it be useful to have an additionnal variable that describes that geometry (ex: MNI, Talairach, anatomical, etc) ? I am thinking of something that may be similar to the NIfTI file format.
That sounds like a good idea; we'll have to think about what geometries would make the most sense ("scanner anatomic" is probably not relevant, but "MNI", "Talairach", maybe "10-20" might be good choices- we'd have to decide how the last would be implemented).
Also, are there any constraints in terms of endianness of the file, and/or type encoding of the different variables?
The underlying file is an HDF5 file, which will take care of the
endianness.
There are some places where we have specified a data type, but I think in the absence of a clear description, we should probably assume "double". David, what do you think?
...
In the description of the "ml" structure, there
is a note specifying that "source indices generally refer to the
optode naming (probe positions)". I assume that it is the same for
detectors?
Yes. We'll revise the description to say that.
In the optional variables, the "qform" variable specified a 4x4 matrix to align the NIRS coordinate system to other geometries. Would it be useful to have an additionnal variable that describes that geometry (ex: MNI, Talairach, anatomical, etc) ? I am thinking of something that may be similar to the NIfTI file format.
That sounds like a good idea; we'll have to think about what geometries would make the most sense ("scanner anatomic" is probably not relevant, but "MNI", "Talairach", maybe "10-20" might be good choices- we'd have to decide how the last would be implemented).
Also, are there any constraints in terms of endianness of the file, and/or type encoding of the different variables?
There are some places where we have specified a data type, but I think in the absence of a clear description, we should probably assume "double". David, what do you think?
Threaded View
| Title | Author | Date |
|---|---|---|
| David Boas | Oct 19, 2012 | |
| David Boas | Aug 1, 2013 | |
| Mathieu Coursolle | Apr 2, 2013 | |
| Mathieu Coursolle | Apr 15, 2013 | |
| David Boas | Jul 31, 2013 | |
| David Boas | Jul 31, 2013 | |
| David Boas | Nov 20, 2012 | |
| Alex Cristia | Nov 20, 2012 | |
| Alex Cristia | Nov 5, 2012 | |
| David Boas | Nov 16, 2012 | |
| Mathieu Coursolle | Nov 16, 2012 | |
| Alessandro Torricelli | Oct 25, 2012 | |
| Blaise Frederick | Oct 26, 2012 | |
| David Boas | Nov 5, 2012 | |
| Alessandro Torricelli | Oct 25, 2012 | |
| Mathieu Coursolle | Oct 22, 2012 | |
| Blaise Frederick | Oct 22, 2012 | |
| David Boas | Nov 5, 2012 | |
| Mathieu Coursolle | Nov 20, 2012 | |