open-discussion > RE: Shared NIRS Data Format - SNIRF
Oct 22, 2012  06:10 PM | Blaise Frederick
RE: Shared NIRS Data Format - SNIRF
Originally posted by Mathieu Coursolle:
Hi,

Thanks for sharing this draft specification. Here are a few small (late) comments I'd like to share on the latest version.

Our new NIRS system should be released in a few months, and we made it very modular. The system can be made from any combination of up to 4 "blocks", each having the potential of having a different number of sources, detectors and wavelengths (as well as different wavelength values). 

That being said, I just wanted to make sure that the specification doesn't enforce the usage of all wavelengths available on the system for all measurements (I may be wrong, but I do believe it was the case for the Matlab based .nirs file format).
The intention here was to to have a complete description of all the data that is included in the file.  What data you choose to put in is up to you.  The ml variable has to exist for every data vector in the file, and specifies information about that vector of data (it refers to a source position, a detector position, and a wavelength) but it does not have to be a complete set of possible source detector pairs (it is not required that you record source detector data for pairs that are too far apart to have useful information, or for lasers that are off, etc..  The only requirement is that if it's in the file, it needs to be completely described).
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?
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?

Thank you,

Mathieu Coursolle

Rogue Research Inc.

Threaded View

TitleAuthorDate
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
RE: Shared NIRS Data Format - SNIRF
Blaise Frederick Oct 22, 2012
David Boas Nov 5, 2012
Mathieu Coursolle Nov 20, 2012