Broadband NIRS

[buck06191]

Hey, I've recently started work with Ilias Tachtsidis's group at UCL and I'm looking at both storing new data and converting old data to use SNIRF but I have a few questions.

Firstly, one of the physiological signals we generate is cytochrome-c-oxidase but at present there's no option to store that in SNIRF. What's the best process to go about suggesting a change to add this to the list of allowed data types for processed data.

Secondly, our data consists of hundreds of wavelengths of light for each channel and I can't see the best way to store this in the SNIRF format as it currently stands. For example, my understanding is that the dataTimeseries is a matrix that has a number of columns equal to the number of channels, and then each of these channels is assigned a single wavelength. In our use case where for the raw data, each channel will itself have an array of N x T values (where N is the number of wavelengths and T is the number of time steps/samples) what's the best way to store this using SNIRF?

[rob-luke]

Hi there @buck06191,

Thanks for reaching out with this detailed question. I am not sure if anyone is storing broadband data with SNIRF yet. @dboas @Horschig @samuelpowell do you know of anyone using SNIRF in this way yet?

Regardless, it seems that we should consider either extending the specification to better support broadband data. Or, if support is already in SNIRF for this data type, provide better examples of how the data should be stored.

@buck06191, it's been a few weeks since you submitted this request. Have you had any further insights into how this problem could be solved? Please let's discuss this here. Additionally, the steering committee meets quarterly to discuss improving and maintaining SNIRF, might you be able to join us on the next call to discuss this further?

[samuelpowell]

Adding CCO as a processed data type is trivial, but without significant changes the only way to store the data is to have individual entries in the measurement list for each wavelength (may benefit from #103 #105).

[buck06191]

The only solution I came up with was to do as @samuelpowell suggests and have a measurement list entry for each wavelength and then to basically stack horizontally the data e.g. channel 1 with all wavelengths followed by channel 2 and so on.

I've not attempted this yet as we realised that conversion to SNIRF is lower priority that the data processing pipeline we're developing (it's going to be an output rather than input), but it looks from #103 that there could be a significant overhead from the amount of metadata we'll inevitably have.

Happy to jump on a call if I'm free

[buck06191]

I'd like to jump back into this briefly - is it possible for us to add CCO as a processed data type as a separate PR linked to this and then in the meantime I'm going to look into pulling together a simple example file for a broadband SNIRF file

cc @iliastachtsidis

[dboas]

@buck06191 As Sam said above, having a measurelist entry for each wavelength is the way to do this in SNIRF.

I am all for you adding "CCO" as a processed data type.

I suspect this is just adding a line for "CCO" with a description in snirf_specification.md under "Supported measurementList(k).dataTypeLabel" Does it need mentioning anywhere else?

Can you edit snirf_specification.md and do a pull request. But maybe others have thoughts to contribute

thanks

[buck06191]

Closing this as I'm no longer in the area/sector. Feel free to reopen if any other teams feel the need for it