Dear openfnirsers,
I would like to initiate a general open information-sharing discussion thread on analysis approaches people are pursuing for TD-fNIRS data recorded from the new Kernel Flow system.
Myself and my group are in early stages of work on this topic (device arrived this week), but are keen to make progress fast. Sharing knowledge and resources across this new user community is clearly the way to do that.
Please reply to this thread with your thoughts on this topic. In particular:
- Any analysis code you have been using / have developed and are interested to share and collaborate on
- Any technical hardware/software issues you have encountered that would be useful for others to know about
- If you are not currently working with a KF device but are interested in collaborating on the above we get you some data to play with
- Any interest in a discord user group or similar, for some more organic back-and-forth discussions where useful?
- Anything else worth mentioning!
I’ll kick things off on the next reply to this with my current knowledge of options. I’m quite certain others have more advanced knowledge than me, so looking forward to hearing comments and updates.
More generally, very much looking forward to connecting and working with people in this great community.
John Grif
Ok - starting at the beginning, namely i/o options.
In my group we are assessing three analysis options for Kernel Flow: 1. Homer3, 2. MNE-Python, and 3. Kernel’s new cloud-based tools.
Option 3 is still a bit of an unknown, and in general like the rest of the neuroimaging community we don’t use closed-source tools. But it will be interesting to see what’s supported.
Re: 1 and 2 - Obviously Homer3 is the mature fNIRS option here, and MNE is the ‘young upstart’. But MNE is also very well established in the broader nipy neuroimaging community, and has a very active and well-organized developer community and processes. Plus, Python.
So, I’m very grateful to Zahra Aghajan for implementing Kernel Flow .snirf file i/o capability in both these tools.
Homer3
------------
Zahra’s Homer3 KF i/o patch
https://github.com/BUNPC/Homer3/pull/62
is now merged to master, and I understand David Boas and co are off to the races with it already.
We are getting stuck into this now - but would be really helpful if anyone has some analysis scripts that we could build on 😉
MNE
-------
Zahra’s MNE PR for KF .snirf compatibility had an informative discussion
https://github.com/mne-tools/mne-python/pull/9661
but was declined for reasonable sounding support and compatibility reasons, not all of which I fully understand.
Not sure what the plans of Zahra or others are to address the issues raised, but for now the reader functionality can at least be accessed from this github branch
https://github.com/Zahra-M-Aghajan/mne-python/tree/feature/TD-nirs_snirf
(git clone; git checkout to this branch)
and I can confirm that it seems to work ok and provides a useful access point to the .snirf file contents
Some other misc MNE comments:
Rob Luke, the main mne-nirs developer, started a discussion a while back on options for proper photon migration simulation functionality
https://github.com/mne-tools/mne-nirs/issues/62
Looks like they're looking for people to chip in on this.
In Lieu of that, mne-nirs does appear to have some newish brain source space functionality
( go to 30 mins in )
It's in the code but not in any examples or documentation as far as I've seen.
https://github.com/mne-tools/mne-nirs/blob/main/mne_nirs/visualisation/_plot_GLM_surface_projection.py
Some brief discussion in some PRs
https://github.com/mne-tools/mne-nirs/issues/62
https://github.com/mne-tools/mne-python/pull/9396
It's not a proper photon migration calculation, it's a channels-nearest-brain projection. But does look potentially useful.
Please drop comments, corrections, additions on the above in replies and let's move this forward together 🙂
JohnGrif
Hi @johngriffiths
I just stumbled upon this conversation, sorry I didnt see it earlier. I am now trying to be more active on this forum. Always feel free to @ me if relevant.
Congrats on the new device, that will be fun to explore the possibilities that TD-fNIRS opens up. I am excited to see what you come up with.
I think your high level summary of the 3 options is accurate.
However, I would just correct one thing. We did not decline the PR from Zahra, we just asked for additional details and my understanding is that she will get back to us when she's ready. I've spoken with Zahra and she knows MNE is supportive of her efforts. I assume her delay is simply due to the hectic life in a startup tech company. We are VERY keen to get support for TD-NIRS in to MNE and will support anyone that opens a PR. I would do it myself, but I don't have a Kernel device (I'd be pleased to work with anyone that does though ? ). The original PR was also opened before SNIRF hit version 1.0, but now SNIRF is stable and we can just mirror the SNIRF spec within MNE, much easier.
The main thing we need to accept the PR is clarification on exactly what data types need to be added to MNE. This is important because addition of data types requires agreement from various software platforms and standards organisers (e.g. from the MEG community), and once the decision is made it cannot easily be walked back. Then all we need is a small example file, maybe 5 seconds of measurement with a trigger or two to use as testing data. If you want to take over the PR from Zahra we could have a quick zoom to knock these points over together, it should be easy.
I am glad someone watched the video! Yes we now have basic source space projection in MNE (it simply projects the scalp estimates to the closest cortical surface), it is not a full photon migration yet. But this means that we have all the plotting and backend infrastructure code ready for when a proper photon migration is added. Proper photon migration is something I am very keen to add. I recently spoke with Qianqian (of MCX fame) about how this could be done. As Qianqian uses a nice standardised format for his data input I think it should be quite straightforward to interface between the two softwares, so this is at the top of priority list for the coming year. Thanks for highlighting that it's missing examples, I will add this ASAP.
As a side note. In the next week or so we will be releasing the next stable version of MNE. This will be the first stable version of MNE with really great fNIRS support. These stable versions have support for several years. For end users this means that installation will be simpler, support will be easier to obtain, you can be sure that we won't make breaking API changes, etc. And most interestingly for this thread, I can start focusing on adding new features rather than battle testing our existing code. So please feel free to add feature requests on the MNE issues board.
Thanks for kicking of the TD discussion, I am keen to hear everyones experiences,
Rob
I attach a basic analysis script for calling Homer functions to process Kernel Flow data. It worked last Fall in tdnirs branch of Homer either at https://github.com/BUNPC/Homer3/tree/tdnirs-development or at https://github.com/sstucker/Homer3/tree/tdnirs-development .
Note that some of the functions needed updating to handle the TD data types. I don't think we ever propagated those changes to the master branch.
I also need to attach the plotProbeHRF.m script which is called by the basic analysis script.
Actually, I pruned channels from the kernel snirf file before loading it into the basic analysis script above since the fast majority of channels has useless data. Here is the pruning file and the files it calls.
English