Closed alexk101 closed 6 months ago
I have found where the problem comes from. In our optode layout, we have bundles of sources and detectors, 8 each. In this layout, we are using 16 sources and 15 detectors. However, because the sources and detectors are in these bundles, there is one remaining detector that would otherwise hang off the cap. To make this less of an obstruction, that detector is placed on the side of the cap, but is not used to capture any signal information. For that reason, it exists in the detector position array, but not in the channels. I have a fix for this by making the detectors
array into a dictionary and can open a pull request if this solution is alright with the maintainers. Please let me know.
A dictionary lookup seems reasonable to me! @rob-luke any opinion? If no response from @rob-luke by the end of the week @alexk101 feel free to open a PR and I'll look.
It looks like I put this in the wrong place. The error is actually in the main mne package, though this is an fnirs issue. I will reopen this issue there and reference this one
Describe the bug
I am working with snirf files produced from a NirX Sport 2 system. I have validated the files against the official specification using (pysnirf2)[https://github.com/BUNPC/pysnirf2]. It shows that these are valid snirf files according to the official protocol. When attempting to read these files into mne using
read_raw_snirf
, an assertion is failed that causes the parsers to fail early. I haven't found any additional documentation to explain why this file isn't capable of being read. Regardless, the parser shouldn't fail to read a file that meets the official specification without explanation as to why (ie missing features). I include below the validator result. Additionally, the snirf file is following version 1.1 of the spec.Looking into this problem myself, it seems that the assertion of the number of detector positions and number of detectors in the channel data does not always hold true. Looking at my data, the number of detector positions is 15, while the number of detectors found in the channel data is 14, where D8 is missing. Why this is the case for my data is something that I will have to investigate myself. However, this should be corrected for this package, as valid snirf files should never fail to be parsed without a reason. I also attach the relevant file.
2024-01-19_007.snirf.zip
Steps to reproduce
Expected results
A parsed snirf file as a RawSNIRF object.
Actual results
Additional information