Back to the main page.

Bug 2765 - senstype gives inconsistent type for planar and planar_combined layouts

Status CLOSED WONTFIX
Reported 2014-11-18 18:19:00 +0100
Modified 2019-08-10 12:41:19 +0200
Product: FieldTrip
Component: core
Version: unspecified
Hardware: Macintosh
Operating System: Mac OS
Importance: P5 minor
Assigned to:
URL:
Tags:
Depends on:
Blocks:
See also:

nno - 2014-11-18 18:19:31 +0100

the sensor type for some systems (including but not limited to bti148) seems inconsistent for the _planar and _planar_combined varieties: >> ft_senstype(ft_senslabel('bti148_planar_combined'),'meg_axial') ans = 1 >> ft_senstype(ft_senslabel('bti148_planar'),'meg_planar') ans = 1 >> ft_senstype(ft_senslabel('bti148_planar_combined'),'meg_planar') ans = 0 I would expect that the first line would return 0 and the third line 1. I would think that once planar sensors are combined, they are still planar.


Jan-Mathijs Schoffelen - 2017-01-17 11:13:54 +0100

It's unclear what the status of this one is, but given the fact that we're severely underpowered in terms of people contributing to fixing issues on bugzilla, Robert and JM have decided to close the low-priority bugs for now. This in order to keep the number of open bugs manageable. Feel free to reopen it, if you are willing to move this one forward towards a more proper resolution. From the senslabel alone it is not always possible to correctly infer the senstype. The convention currently is to represent the combined planar channels (at least for systems that need a synthetic planar gradient as an intermediate step to get there, i.e. with chanX_dV and chanX_dH pair per original sensor) in the labels with the original sensor names (to facilitate plotting etc. Therefore, it's by construction impossible to identify the senstype correctly. I know that it's been a long while since this was first submitted, but is there any recollection of the direct cause of submitting this in the first place?


nno - 2017-01-17 12:08:09 +0100

> Therefore, it's by construction impossible to identify the senstype correctly. I know > that it's been a long while since this was first submitted, but is there any > recollection of the direct cause of submitting this in the first place? Thanks for asking - indeed it's been a long time ago. Probably this was submitted when working on a function to get the M/EEG layouts and associated channel types in CoSMoMVPA [1], in particular the cosmo_meeg_senstype_collection function [2]. Even though I don't remember everything in detail, looking at the code [2] it seems I added some processor functions to get around issues with senstypes being different than what I expected (@fix_neuromag306_planar_combinations,@fix_neuromag306_combined_with_mag,@fix_neuromag122_planar_name,@fix_eeg10XX_senstype). Some other processor functions there deal with older versions of FieldTrip that have presumably been updated in the past (@fix_ctf275_planar_old_fieldtrip,@fix_eeg10XX_channels_old_fieldtrip,@fix_yokogawa440_planar_old_fieldtrip,@fix_egiX_channels_old_fieldtrip). For operations with CoSMoMVPA it would seems it is fine to close this issue, and I understand this issue may not be of top priority. [1] https://github.com/CoSMoMVPA/CoSMoMVPA [2] https://github.com/CoSMoMVPA/CoSMoMVPA/blob/master/mvpa/cosmo_meeg_senstype_collection.m


Jan-Mathijs Schoffelen - 2017-01-17 12:25:59 +0100

OK, thanks for the feedback. Will keep it like this for now, since you seem to work around it anyway. Keep up the constructive comments, and sorry for not having taken this up anytime sooner.


Robert Oostenveld - 2019-08-10 12:35:07 +0200

This closes a whole series of bugs that have been resolved (either FIXED/WONTFIX/INVALID) for quite some time. If you disagree, please file a new issue on https://github.com/fieldtrip/fieldtrip/issues.


Robert Oostenveld - 2019-08-10 12:41:19 +0200

This closes a whole series of bugs that have been resolved (either FIXED/WONTFIX/INVALID) for quite some time. If you disagree, please file a new issue on https://github.com/fieldtrip/fieldtrip/issues.