-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Broader support of the SNIRF file format and enable reading GowerLab data #10555
Merged
Merged
Changes from all commits
Commits
Show all changes
16 commits
Select commit
Hold shift + click to select a range
6f57595
Add support for SNIRF timeunit
rob-luke 08fc60f
Flake
rob-luke f4fb273
Fix landmark reading
rob-luke 6b89d3e
Remove commented code
rob-luke 3b78561
Merge branch 'main' into snirftimeunit
rob-luke ffa38db
More tests
rob-luke 7e55e66
Merge branch 'snirftimeunit' of github.com:rob-luke/mne-python into s…
rob-luke 7edec29
Report api change
rob-luke 9fb918c
Update docs
rob-luke d28ecb7
Flake
rob-luke b1486d6
Update config.py
rob-luke 5c0b057
Update config.py
rob-luke 07c4c9b
Update test indicies
rob-luke df66ca5
Merge branch 'snirftimeunit' of github.com:rob-luke/mne-python into s…
rob-luke a8d6b91
More tests
rob-luke 59a5c27
Update latest.inc
rob-luke File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hum. This will make a copy of the data buffer but more importantly this is not consistent with the other readers which read the channels in the order they appear in the file on disk. I prefer to avoid doing magic in readers. Relevant functions down the road should deal with files with channels present in different orders, eg combine_evoked grand_average etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If
preload=False
it won't because we can pick without loaded data now. This means people who really need to save this 2x memory can doread_raw_nirx(...).load_data()
instead. But really NIRS data tends to be pretty small so I don't think this will be an issue in practice.I agree with this idea in principle, but it will require a big refactoring of our existing code, which assumes and requires that the frequency pairings are essentially properly "interlaced" to work correctly.
So to me I would like to add a comment
# TODO: Remove this reordering
, which would give us some months to properly craft order-agnostic code, which I think will be a bigger undertaking involving coordination between MNE-Python and MNE-NIRS and changes in probably 5-10 public functions...There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rob-luke I realized this is problematic. Let's say we have this arrangement with the more-or-less standard "logical channel numbering":
The native file will be written as
['S1_D1 760', 'S1_D2_850', 'S2_D1_760', 'S2_D1_850', 'S1_D3_760', 'S1_D3_850', ...]
, i.e., a pair ordering of[S1_D1, S2_D1, S1_D3, S3_D1, S2_D4, S3_D3, S3_D4]
, and people will naturally expect these pairs to be associated with channel numbers 1 through 7. But thispick(argsort(ch_names))
will result in a reordered pair ordering of[S1_D1, S1_D3, S2_D1, S2_D4, S3_D1, S3_D3, S3_D4]
, so channels 1-7 from before now show up in the order[1, 3, 2, 5, 4, 6, 7]
.Rather than this
pick(argsort(...))
it seems like it would make sense to reorder the channels such that the original "logical channel" ordering is preserved, but such that pairs are still immediately adjacent. We could start by making sure that the firstN
channels are all fNIRS channels, and that they are paired. Non-fNIRS channels go after that in channelsN+1:
. Sound good?Eventually like we said before we could/should relax this by making the channel logic smarter everywhere, but that's a bigger undertaking. All we need to do to fix this immediate/lpressing "logical channel" reordering problem I think is
.pick(a_better_order)
wherea_better_order
comes from a few lines of pairing logic.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I disagree that there is a standard logical channel ordering. Even for the trivial example which you illustrate I would assign the channel numbers differently to you.
You have assigned
I would have thought the logical ordering was
I also don't think that the channel number has any meaning. And it's the pair naming that should be used.
That's why I went for a simple sort. It will always be the same and can be easily described.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure it can differ by system or setup, but to me the acquisition system sets the "standard order" when it writes data to disk in some order. So the idea is just to respect the order as written to disk as much as possible until we can remove any ordering restrictions whatsoever.
FWIW we used to have this order problem with MEEG data, too, and removing it made the code cleaner in the end. So I'm looking forward to removing the paired-order restriction for fNIRS, as the cleanest long term solution is just to keep the order each manufacturer uses in the first place, or a user does with reorder_channels, etc. Currently reorder_chaanels is problematic for fNIRS and it shouldn't be!