ENH: Channel tags

[larsoner]

It would be nice to be able to tag channels as belonging to a particular "group". What tags/groups are useful could be up to each user/system to decide, but just a few compelling examples we've found working on MNE-Python include:

• for Triux NEO (and older systems), we would optionally add tags/groups to indicate 1) each triplet of sensors that share a common spatial location, and also 2) which selection they are a part of. For example, MEG0111 could have tags ('011X', 'Left', 'temporal') or so (part of the 0111/2/3 triplet, in the Left-temporal group in .sel)
• for ECoG/sEEG/implanted electrodes, each electrode shaft (sEEG) or grid (ECoG) could be encoded (recordings often include multiple shafts/grids)
• for OPM MEG, manufacturers sometimes refer to one "sensor" as having multiple sensitive volumes (even if spatially offset from one another) which we would then encode as individual channels; thus being able to have each "sensor" name/group for each channel would be useful.

I propose we add to our new enhanced channel block ch_info (#33) the ability to specify sets of string tags for each channel, i.e., to:

fiff-constants/DictionaryTags.txt

Lines 350 to 361 in 5bd84d2

	#==============================================================================================================
	#
	# Tags used for channel info
	#
	#==============================================================================================================
	:id channel_info
	#==============================================================================================================
	ch_coil_type 350 enum(coil) - "Coil type"
	ch_coord_frame 351 enum(coord) - "Channel coordinate frame"
	#<free> 352
	#... ...
	#<free> 399

We could add:

ch_tags		352	str	-	"Channel tags"

This could would then be written using the same name_list / :-concatenated string mechanism as other places in MNE, assuming that's general enough for MEGIN use.

Thoughts @jnenonen @mkajola ?

[jnenonen]

Hi Eric, Sorry this lipped past during my holidays, but I would like to involve also Matti in the discussion. BR, Jukka [A screenshot of a cell phone Description automatically generated]-- From: Eric Larson ***@***.***> Reply to: mne-tools/fiff-constants ***@***.***> Date: Wednesday 28. July 2021 at 19.51 To: mne-tools/fiff-constants ***@***.***> Cc: Jukka Nenonen ***@***.***>, Mention ***@***.***> Subject: [mne-tools/fiff-constants] ENH: Channel tags (#36) It would be nice to be able to tag channels as belonging to a particular "group". What tags/groups are useful could be up to each user/system to decide, but just a few compelling examples we've found working on MNE-Python include: * for Triux NEO (and older systems), we would optionally add tags/groups to indicate 1) each triplet of sensors that share a common spatial location, and also 2) which selection they are a part of. For example, MEG0111 could have tags ('011X', 'Left', 'temporal') or so (part of the 0111/2/3 triplet, in the Left-temporal group in .sel) * for ECoG/sEEG/implanted electrodes, each electrode shaft (sEEG) or grid (ECoG) could be encoded (recordings often include multiple shafts/grids) * for OPM MEG, manufacturers sometimes refer to one "sensor" as having multiple sensitive volumes (even if spatially offset from one another) which we would then encode as individual channels; thus being able to have each "sensor" name/group for each channel would be useful. I propose we add to our new enhanced channel block ch_info (#33<#33>) the ability to specify sets of string tags for each channel, i.e., to: https://github.com/mne-tools/fiff-constants/blob/5bd84d224de502bee66f70b7867b8f45b45264c1/DictionaryTags.txt#L350-L361 We could add: ch_tags 352 str - "Channel tags" This could would then be written using the same name_list / :-concatenated string mechanism as other places in MNE, assuming that's general enough for MEGIN use. Thoughts @jnenonen<https://github.com/jnenonen> @mkajola<https://github.com/mkajola> ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#36>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADR3D6TBKYNPYBF63VUEUGLT2AYPVANCNFSM5BEXYKHQ>.

[larsoner]

@jnenonen @mkajola any thoughts on this one?

[jnenonen]

Hi Eric, I will pass this question to Matti, hope that he can think about it? BR, Jukka [A screenshot of a cell phone Description automatically generated]-- From: Eric Larson ***@***.***> Reply to: mne-tools/fiff-constants ***@***.***> Date: Tuesday 21. September 2021 at 23.23 To: mne-tools/fiff-constants ***@***.***> Cc: Jukka Nenonen ***@***.***>, Mention ***@***.***> Subject: Re: [mne-tools/fiff-constants] ENH: Channel tags (#36) @jnenonen<https://github.com/jnenonen> @mkajola<https://github.com/mkajola> any thoughts on this one? From: Eric Larson ***@***.******@***.***>> Reply to: mne-tools/fiff-constants ***@***.******@***.***>> Date: Wednesday 28. July 2021 at 19.51 To: mne-tools/fiff-constants ***@***.******@***.***>> Cc: Jukka Nenonen ***@***.******@***.***>>, Mention ***@***.******@***.***>> Subject: [mne-tools/fiff-constants] ENH: Channel tags (#36) It would be nice to be able to tag channels as belonging to a particular "group". What tags/groups are useful could be up to each user/system to decide, but just a few compelling examples we've found working on MNE-Python include: * for Triux NEO (and older systems), we would optionally add tags/groups to indicate 1) each triplet of sensors that share a common spatial location, and also 2) which selection they are a part of. For example, MEG0111 could have tags ('011X', 'Left', 'temporal') or so (part of the 0111/2/3 triplet, in the Left-temporal group in .sel) * for ECoG/sEEG/implanted electrodes, each electrode shaft (sEEG) or grid (ECoG) could be encoded (recordings often include multiple shafts/grids) * for OPM MEG, manufacturers sometimes refer to one "sensor" as having multiple sensitive volumes (even if spatially offset from one another) which we would then encode as individual channels; thus being able to have each "sensor" name/group for each channel would be useful. I propose we add to our new enhanced channel block ch_info (#33<#33>) the ability to specify sets of string tags for each channel, i.e., to: https://github.com/mne-tools/fiff-constants/blob/5bd84d224de502bee66f70b7867b8f45b45264c1/DictionaryTags.txt#L350-L361 We could add: ch_tags 352 str - "Channel tags" This could would then be written using the same name_list / :-concatenated string mechanism as other places in MNE, assuming that's general enough for MEGIN use. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#36 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADR3D6T55HVUDBJY3XRTI2DUDDST3ANCNFSM5BEXYKHQ>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[mkajola]

HelloEric, I throw back some quick thoughts… The idea of the grouping is pretty natural, and that is done all the time with some external to fiff mechanisms. Having ability to code groups in fiff would thus be good idea. We recently expanded (was in v 1.5) the channel info to tagged data, so now adding new attributes for the channels if feasible. However I somewhat dislike the idea of using channel tags to this purpose. The reason is that field “tags” is too unspecific. You could add the groups into the tags, but since the tags could potentially contain tags to whatever purpose, there would be no way to know which tags are related to groups, and which to something else. So with this very quick evaluation, I would rather go to something like “spatial-groups” tag. I think all your examples were such. There might be some other groups later on, and there could be also “tags” with tags for which we don’t specify any particular semantics. t. mjk From: Jukka Nenonen ***@***.***> Sent: keskiviikko 22. syyskuuta 2021 10.49 To: mne-tools/fiff-constants ***@***.***> Cc: Matti Kajola ***@***.***>; Mention ***@***.***> Subject: Re: [mne-tools/fiff-constants] ENH: Channel tags (#36) Hi Eric, I will pass this question to Matti, hope that he can think about it? BR, Jukka [A screenshot of a cell phone Description automatically generated]-- From: Eric Larson ***@***.***> Reply to: mne-tools/fiff-constants ***@***.***> Date: Tuesday 21. September 2021 at 23.23 To: mne-tools/fiff-constants ***@***.***> Cc: Jukka Nenonen ***@***.***>, Mention ***@***.***> Subject: Re: [mne-tools/fiff-constants] ENH: Channel tags (#36) @jnenonen<https://github.com/jnenonen> @mkajola<https://github.com/mkajola> any thoughts on this one? From: Eric Larson ***@***.******@***.***>> Reply to: mne-tools/fiff-constants ***@***.******@***.***>> Date: Wednesday 28. July 2021 at 19.51 To: mne-tools/fiff-constants ***@***.******@***.***>> Cc: Jukka Nenonen ***@***.******@***.***>>, Mention ***@***.******@***.***>> Subject: [mne-tools/fiff-constants] ENH: Channel tags (#36) It would be nice to be able to tag channels as belonging to a particular "group". What tags/groups are useful could be up to each user/system to decide, but just a few compelling examples we've found working on MNE-Python include: * for Triux NEO (and older systems), we would optionally add tags/groups to indicate 1) each triplet of sensors that share a common spatial location, and also 2) which selection they are a part of. For example, MEG0111 could have tags ('011X', 'Left', 'temporal') or so (part of the 0111/2/3 triplet, in the Left-temporal group in .sel) * for ECoG/sEEG/implanted electrodes, each electrode shaft (sEEG) or grid (ECoG) could be encoded (recordings often include multiple shafts/grids) * for OPM MEG, manufacturers sometimes refer to one "sensor" as having multiple sensitive volumes (even if spatially offset from one another) which we would then encode as individual channels; thus being able to have each "sensor" name/group for each channel would be useful. I propose we add to our new enhanced channel block ch_info (#33<#33>) the ability to specify sets of string tags for each channel, i.e., to: https://github.com/mne-tools/fiff-constants/blob/5bd84d224de502bee66f70b7867b8f45b45264c1/DictionaryTags.txt#L350-L361 We could add: ch_tags 352 str - "Channel tags" This could would then be written using the same name_list / :-concatenated string mechanism as other places in MNE, assuming that's general enough for MEGIN use. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#36 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADR3D6T55HVUDBJY3XRTI2DUDDST3ANCNFSM5BEXYKHQ>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#36 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKJMTHHVJMALSNNXJ4UFPHLUDGDANANCNFSM5BEXYKHQ>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[larsoner]

So with this very quick evaluation, I would rather go to something like “spatial-groups” tag.

Indeed the most critical / motivating use cases currently have to do with spatial groups (position and/or orientation and/or physical connection between channels). So starting with a "spatial groups" list-of-str for each channel within the new channel info blocks sounds good to me!

There might be some other groups later on, and there could be also “tags” with tags for which we don’t specify any particular semantics.

Agreed we can wait on something like this and add it later if there are good motivating use cases. I don't see any harm in having these other tags separate from the spatial grouping tags, as having them separate just adds information, in that the spatial ones are more specific / targeted.

I'll open a pull request in the coming days to add this sort of thing here, probably along with some joint MNE-Python and MNE-MATLAB PRs that at implement some form of this (as a way of testing the constants/infrastructure here).

[mkajola]

Fine, I suppose at that point the idea has had a bit time to ripen, and the decision will not be too difficult to make. t. mjk From: Eric Larson ***@***.***> Sent: keskiviikko 22. syyskuuta 2021 20.07 To: mne-tools/fiff-constants ***@***.***> Cc: Matti Kajola ***@***.***>; Mention ***@***.***> Subject: Re: [mne-tools/fiff-constants] ENH: Channel tags (#36) So with this very quick evaluation, I would rather go to something like “spatial-groups” tag. Indeed the most critical / motivating use cases currently have to do with spatial groups (position and/or orientation and/or physical connection between channels). So starting with a "spatial groups" list-of-str for each channel within the new channel info blocks sounds good to me! There might be some other groups later on, and there could be also “tags” with tags for which we don’t specify any particular semantics. Agreed we can wait on something like this and add it later if there are good motivating use cases. I don't see any harm in having these other tags separate from the spatial grouping tags, as having them separate just adds information, in that the spatial ones are more specific / targeted. I'll open a pull request in the coming days to add this sort of thing here, probably along with some joint MNE-Python and MNE-MATLAB PRs that at implement some form of this (as a way of testing the constants/infrastructure here). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#36 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKJMTHD32O62S3AC7XUMKJTUDIEKDANCNFSM5BEXYKHQ>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.