MRG: Add SNIRF support for 2D locations and NIRx files

[rob-luke]

Reference issue

Closes #9338 mne-tools/mne-nirs#257 #9308.

What does this implement/fix?

This PR enables reading of SNIRF files from the NIRx vendor and it also enables reading of SNIRF files with 2D locations from the SfNIRS team.

Support for 2D locations was enabled by setting the z coordinate to 0.

Support for NIRx was enabled by not relying on the sourceLabels field in SNIRF. Which was optional in the spec, so I shouldn't have expected it to be there.

Additional information

People may wish to support no sensor location info, but they can do that in a future PR.

It may also be possible to do some fancy 2D to 3D conversion for data, but that would be significant work.

I wanted to use an exact copy of some code, so I turned it in to a function called _validate_nirs_info

Specifically validating and testing Artinis files will have to wait till someone can provide test data. However, I think this will achieve the 2D support they require.

[rob-luke]

This will fail until mne-tools/mne-testing-data#84 is merged.

[rob-luke]

@larsoner @agramfort @drammock Could you please review and merge if happy. I expect CIs to go green

[rob-luke]

I expect CIs to go green

Famous last words, I forgot to update the testing hash and version

[rob-luke]

Ok there is some weird CI behaviour going on. The new files are being found and read in the Mac and windows CI tests (I opened the logs and checked all snirf tests were run and passed). But the linux CIs cant find the files.

Could it be a caching thing?

Other than the ci not finding the files I think this is good to go

[rob-luke]

Ok I'm truly stumped here. @larsoner could you please give me a clue when you have a chance?

[rob-luke]

I just redid the experiment for our tutorial at https://mne.tools/stable/auto_tutorials/preprocessing/plot_70_fnirs_processing.html

I measured 25 minutes worth of data on myself with the NIRSport2 device and it was saved in the SNIRF format. The tutorial above worked simple by changing read_raw_nirx to read_raw_snirf, so I am confident the reader is now working correctly. We just need to squish these pesky CI errors.

[rob-luke]

bash magic, thanks @larsoner

[larsoner]

Really StackOverflow magic :)

https://stackoverflow.com/questions/63521430/clear-cache-in-github-actions#answer-64819132

[larsoner]

I can replicate the failure locally:

mne/io/snirf/tests/test_snirf.py:44: in test_basic_reading_and_min_process
    raw = read_raw_snirf(fname, preload=True)
mne/io/snirf/_snirf.py:47: in read_raw_snirf
    return RawSNIRF(fname, preload, verbose)
<decorator-gen-250>:24: in __init__
    ???
mne/io/snirf/_snirf.py:78: in __init__
    fname = _check_fname(fname, 'read', True, 'fname')
mne/utils/check.py:178: in _check_fname
    raise FileNotFoundError(f'{name} does not exist: {fname}')
E   FileNotFoundError: fname does not exist: /home/larsoner/python/MNE-testing-data/snirf/SfNIRS/snirf_homer3/1.0.3/snirf_1_3_nirx_15_2_recording_w_short.snirf

Is it perhaps a real path problem that only Linux tests because on other CIs there is a slowtest marker that makes it get skipped for example?

[larsoner]

@rob-luke I take it you're either on macOS or Windows, which both play more loosely with case than Linux...?

[rob-luke]

@larsoner Mac at home, windows at work. And currently very embarrassed.

[larsoner]

I think we should all blame the OS and not the user here :)

[rob-luke]

Im actually quite surprised that they handle case differently, you learn something every day.

[larsoner]

Thanks @rob-luke !

[larsoner]

Closes #9338 mne-tools/mne-nirs#257 #9308.

FYI @rob-luke another nugget for the day, these need to be on separate lines -- only the first closed automagically on merge

[rob-luke]

Thanks @larsoner. And I am pleased as squeezed this in before the release. Cheers