-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reading 3D coordinates from snirf produces different result than read_custom_montage() #545
Comments
If it's from that line then I think it's expected, and if you pass |
Thanks for sharing @kdarti , and great detailed issue. |
Hi Rob, it's Kristoffer from Artinis, we just implemented export of digitised 3d positions to snirf files in our main software, so that's the origin of the snirf file. I made the .elc manually, based on the coordinates in the snirf.
Yep, with that added I do get the same behavior with the .elc using read_custom_montage() as with the coordinates from the snirf file. However, then the positions are not really what I expect. Below is a screenshot from our software (where the positions were digitised and from where the .snirf file was exported), showing the digitised positions in our 3d vis, along with a 3d vis of the positions using read_custom_montage() + .elc (not using |
So if things are okay with |
Maybe I was a bit unclear, if I use |
Okay -- if |
Sorry, forgot to reply to this. Having a head_size parameter for read_raw_snirf that functions the same way as the same parameter for read_custom_montage() would indeed help. Tbh, I'm not even sure what I should expect when reading the coordinates from a .snirf file, all I know is that I got a mismatch when reading identical coordinates using two different functions. I think @rob-luke would have to say what is actually the intended result when reading the coordinates from a .snirf file. |
Describe the bug
I'm not completely sure that this is a bug, and I'm not sure it's even expected that you'd get the same results when automatically reading coordinates from a snirf file as when reading the same coordinates using read_custom_montage().
Steps to reproduce
20240327-snirf3d-mne.zip
import mne
mne.io.read_raw_snirf(r"2x12_nz-to-nasion.snirf").get_montage().plot()
mne.channels.read_custom_montage(r"digitisation_2x12.elc").plot()
mne.io.read_raw_snirf(r"2x12_nz-to-nasion.snirf").get_montage().get_positions()
mne.channels.read_custom_montage(r"digitisation_2x12.elc").get_positions()
Expected results
I'd expect the resulting coordinates to be the same, given the coordinates in the .snirf and the .elc files are identical.
The difference seems to lie here:
https://github.com/mne-tools/mne-python/blob/eee8e6fe580034f4a3a4fb13bdca3bfc99240708/mne/channels/_standard_montage_utils.py#L274
If I comment out that line I get identical results.
Actual results
I should say that the digitisation is bad and not realistic, but the result that I expect is what I get from read_custom_montage()
Additional information
Platform Windows-10-10.0.19045-SP0
Python 3.12.2 | packaged by conda-forge | (main, Feb 16 2024, 20:42:31) [MSC v.1937 64 bit (AMD64)]
Executable C:\Users\kdahlslatt\Anaconda3\envs\mne\python.exe
CPU Intel64 Family 6 Model 158 Stepping 10, GenuineIntel (12 cores)
Memory 15.7 GB
Core
├☑ mne 1.6.1 (latest release)
├☑ numpy 1.26.4 (OpenBLAS 0.3.26 with 12 threads)
├☑ scipy 1.12.0
├☑ matplotlib 3.8.3 (backend=Qt5Agg)
├☑ pooch 1.8.1
└☑ jinja2 3.1.3
Numerical (optional)
├☑ sklearn 1.4.1.post1
├☑ numba 0.59.1
├☑ nibabel 5.2.1
├☑ nilearn 0.10.3
├☑ dipy 1.9.0
├☑ openmeeg 2.5.7
├☑ pandas 2.2.1
└☐ unavailable cupy
Visualization (optional)
├☑ pyvista 0.43.4 (OpenGL 4.5.0 - Build 30.0.101.1404 via Intel(R) UHD Graphics 630)
├☑ pyvistaqt 0.11.0
├☑ vtk 9.2.6
├☑ qtpy 2.4.1 (PyQt5=5.15.8)
├☑ pyqtgraph 0.13.4
├☑ mne-qt-browser 0.6.2
├☑ ipywidgets 8.1.2
├☑ trame_client 2.16.5
├☑ trame_server 2.17.2
├☑ trame_vtk 2.8.5
├☑ trame_vuetify 2.4.3
└☐ unavailable ipympl
Ecosystem (optional)
├☑ mne-nirs 0.6.0
└☐ unavailable mne-bids, mne-features, mne-connectivity, mne-icalabel, mne-bids-pipeline
The text was updated successfully, but these errors were encountered: