KIT-UMD sensor positions

[christianbrodbeck]

The KIT system at UMD has a different sensor layout from the KIT system in New York, although the two systems have the same number of sensors. This leads to problems in a few places, so far I have encountered two:

• When plotting topomaps, the KIT-NY layout is automatically chosen by default which is not valid for UMD data. I can’t find anything in the info dict that would distinguish the two systems. To distinguish the KIT-NY from the KIT Abu Dhabi systems the number of channels is used, which is based on the fact that the Abu Dhabi system has many more channels, so the same heuristic can’t distinguish the NY and UMD systems. A solution that would work for both systems as far as I can tell would be to switch both KIT 157 sensor systems to the auto-generated layout. Is there a better option? The squid files contain a flag as to what system they’re coming from, would it be possible to store that in FIFF files in the future?
• The KIT-157 sensor neighbors file is also not valid. I can’t see that file on the FieldTrip templates page. How was it obtained/how could I produce a corresponding file for UMD?

(@teonbrooks are there more developers working on KIT in the meantime?)

[larsoner]

The squid files contain a flag as to what system they’re coming from, would it be possible to store that in FIFF files in the future?

We would probably want to talk to the Elekta folks and Matti about it, but it seems like it should be doable.

The KIT-157 sensor neighbors file is also not valid.

You might be able to trace back the origin using the blame interface on GitHub and find the relevant commit and PR. I imagine there would have been some discussion about it.

[christianbrodbeck]

Thanks @Eric89GXL ! I will construct a UMD neighbors file analogous to #2269. What's the best way to start a discussion with the Elekta folks and Matti?

[larsoner]

@jaeilepp had a thread going with them and is in charge IIRC of maintaining our chunk of the FIFF constants (although these wouldn't be MNE-specific, hence why we need to talk to the Elekta folks). @jaeilepp do you have time to dig into this issue a bit to see if you think it makes sense to add a constant? Maybe we need to lay out the problem clearly to them in an email with a proposed solution.

@christianbrodbeck what did you have in mind in terms of a FIFF constant? What datatype would it be? Some sort of enum for KIT system locations?

[jaeilepp]

Since this has nothing to do with the neuromag stuff, I suppose the most reasonable thing would be to use the MNE-range. So maybe just ask @mshamalainen if he's okay with it?

[larsoner]

It has nothing to do with Neuromag acquisition, but it could have to do with how to properly analyze KIT data. In that sense I see it more like the coil defs from other systems, including KIT, which are in the Elekta namespace. The KIT head coord frame is in the MNE namespace, though, so maybe we don't need to bother the Elekta folks with it.

[christianbrodbeck]

It seems that each KIT system gets an 4 byte integer ID for every major stage if its life (https://github.com/mne-tools/mne-python/blob/master/mne/io/kit/constants.py#L110) and I think sensor positions can change slightly over time. I don't know if they would do major rearrangements (requiring a different layout) but before kit2fiff could read sensor positions directly from the SQD files we used to have a TXT file with sensor positions that depended on when the data was acquired. So I think it would make sense to store that system-ID integer?

That said I realize an alternative approach might be to infer the system from the spatial position of a specific sensor, e.g. the NY system has sensor "MEG 001" at a different location than the UMD system. But storing the SYSID would be cleaner and would not break if the channel happened to be excluded...

[larsoner]

So I think it would make sense to store that system-ID integer?

Sounds reasonable to me. @jaeilepp do you agree?

[jaeilepp]

Yeah, I think we could actually use FIFF.FIFF_DESCRIPTION for this as long as we just use a string. It seems to store that kind of information and currently it is not used by the kit reader.

[agramfort]

fine with me. No strong opinion

[teonbrooks]

@christianbrodbeck, I don't think anyone else is currently working on KIT stuff. I can help point out anything you might need. I think the machine ID as a string (per FIFF requirement) would be the best way to deal with it. but this would mean that legacy fiff files with KIT data would still default to NYU since that bit of metadata isn't there.

I see that you found the thread about how I formed the neighborhood. I had opened an issue on fieldtrip a while back about having them add the specific ones but I didn't follow it up and it was closed. It might be nice to see if the fieldtrip team would include neighborhood files for both systems since it is their triangulation + art which formed the other ones we have in our library.

[larsoner]

We shouldn't use description as users can reasonably set this manually (and
might already be doing it) to store their own metadata.
On Jun 17, 2016 2:11 AM, "jaeilepp" notifications@github.com wrote:

Yeah, I think we could actually use FIFF.FIFF_DESCRIPTION for this as long
as we just use a string. It seems to store that kind of information and
currently it is not used by the kit reader.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#3311 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ACQZXpzrYwoOzbboH6SiDIh8Z3JS1d7oks5qMjqGgaJpZM4I2-fe
.

[jaeilepp]

But are we not moving towards a frozen info structure anyways?

[larsoner]

Not frozen, just providing cleaner/safer ways of updating it. For example users need to be able to set bads, so we'll eventually have something like an info.bads = setter instead of directly doing info['bads'] =. Equivalently we could have info.description = instead of info['description'] =, and the same for any other fields users might want to update.

[christianbrodbeck]

@teonbrooks

but this would mean that legacy fiff files with KIT data would still default to NYU since that bit of metadata isn't there.

Yeah here we could guess based on sensor positions?

It might be nice to see if the fieldtrip team would include neighborhood files for both systems

Did you have an issue/PR on https://github.com/fieldtrip/fieldtrip? I can't find anything for author:teonbrooks

[christianbrodbeck]

Regarding topo-plots: I just learned that with KIT systems sensor positions can also change between maintenance events (when a different gradiometer is wired to a channel), so I wonder whether for KIT systems it would be safer to just always compute a layout by projecting sensor positions onto a plane?