Handling of calculated or derived data types

[forihuelaespina]

Extracted from the Google Docs: https://docs.google.com/document/d/1kLQnFNSXsCAcUNcCPtyTerSwatCOnLcX4fAaZsidCbI/edit

David Boas
One issue that remains to be resolved is how to handle calculated or derived data types. The specification presently supports several raw data types. It is desirable to add a data type for concentration results. An issue we are struggling with is that every channel of data, i.e. column of "d", has a corresponding descriptor in the "ml" structure. The "ml" structure indexes the source, detector, and data type for the corresponding data channel. It also indexes the wavelength. For concentration, there is no wavelength. Thus, it seems that if we have a data type for concentration, then the corresponding "ml(n).wavelengthIndex" field would be ignored. In addition, the "ml(n).dataTypeIndex" could be used to reference what chromophore is stored in the data. The list of chromophores could be provided by sd.Chromophores, which could be a string array with possible entries of "HbO", "HbR", "H2O", "aa3", etc.

Luca Pollonini
I agree on having to address the data type, as of raw vs. processed, if not both. For instance, Shimadzu outputs both raw (3 wavelengths) and hemoglobin (2 chromophores) data on the same file, and it would be nice to make SFNIRS compatible to their preferred output to facilitate them embracing the SNIRF standard.
A separate issue for discussion is whether to include other probe/anatomical variables of interests, e.g. a certain number of fiducial points alongside the source and detector positions. If the matrix qform is missing, these will be needed to operate any affine transformation towards another coordinate system or an anatomical scan. The aux seems to be suited for time course variables, so it is less than ideal for additional locations. We could always promote recording 3D locations in a separate file (e.g., AtlasViewer-like), but it would be nice to attempt standardize that as well.
In addition, I also wonder if there should be an additional field(s) in stim for adding optional trial-specific data, such as reaction time, response accuracy or other variables extracted from presentation programs like E-prime. As above, these could live in a separate file, but it could be useful to forward think about integrating other behavioral data.

Felipe Orihuela-Espina
Will a set of predefined constants ensure a better compatibility (e.g. it will avoid different nomenclature "HbO2" "O2Hb", etc although at the cost of needing periodic review of the constant list as new parameters may be measured?
Also, will this file format consider data not just reconstructed but also more or less heavy processed? Is it expected that it keeps track of the status of the data alone, or to be fully capable of "remembering" every processing operation that the data have underwent as well as the processing operations metaparameters? Perhaps a solution is to have a "list" of data, each "data" unit represents the data in a particular state of processing, and then include some information alike the "Comando" software pattern.

[fangq]

measurementList.dataType now supports both raw and processed types, see

https://github.com/fNIRS/snirf/blob/master/snirf_specification.md#appendix

closing for now.