WIP: ENH: add support for legacy files *.elp, *.hsp

[teonbrooks]

@christianmbrodbeck @TalLinzen

Added functionality to import *.elp and *.hsp.

Needs

• test
• gui support

[teonbrooks]

The resulting dev_head_t for the legacy files is looks pretty similar to the current one using Polhemus data.

In [8]: raw.info['dev_head_t']['trans']
Out[8]: 
array([[  9.98212166e-01,  -3.72199953e-02,  -4.67669015e-02,
         -7.31597251e-04],
       [  5.39381802e-02,   8.98064971e-01,   4.36543216e-01,
          1.60134450e-02],
       [  2.57515796e-02,  -4.38285271e-01,   8.98466959e-01,
          6.13035779e-02],
       [  0.00000000e+00,   0.00000000e+00,   0.00000000e+00,
          1.00000000e+00]])

In [9]: raw_legacy.info['dev_head_t']['trans']
Out[9]: 
array([[  9.98068276e-01,  -3.95591290e-02,  -4.79039772e-02,
         -4.85254095e-04],
       [  5.65382477e-02,   8.97963786e-01,   4.36422348e-01,
          1.60131704e-02],
       [  2.57515488e-02,  -4.38287707e-01,   8.98465772e-01,
          6.13037270e-02],
       [  0.00000000e+00,   0.00000000e+00,   0.00000000e+00,
          1.00000000e+00]])

[TalLinzen]

cool! what can I do to help?

[teonbrooks]

I just don't know what the proper tolerance difference should be for the two. Since the operations should yield the same result, my old guess is there is a slight discrepancy that comes from the calculation of the norm when generating of the basis vectors in matlab versus python.

[agramfort]

the numerical error seem pretty large. You see errors at the second digit which is really weird for double precision computation.

[teonbrooks]

after looking into the coreg code in mne, I noticed that has changed a bit since it was originally written. the origin is being calculated as origin = lpa + np.dot(nasion - lpa, right_unit) * right_unit which is different than the method used in the legacy files, which is transform.origin = (fids(2,:)+fids(3,:))/2;. @christianmbrodbeck do you know why this step is different?

[christianbrodbeck]

I don't know about the change, does the current code not result in the desired neuromag space?

You could add a test comparing the points in raw.info after initializing a RawKIT with .txt files and initializing another one with corresponding .hsp and .elp? There you should get exactly the same results unless the code that produces hsp and elp files introduces inaccuracies

[christianbrodbeck]

There should be a note in the documentation clarifying that files are treated differently based on the extension. To avoid confusion it might be good to force other files to have the .txt extension? Also you might want to enforce that either both or none of the files are .txt, otherwise the files are in different coordinate systems.

[teonbrooks]

I don't know about the change, does the current code not result in the desired neuromag space?

I think that the difference in how the origin is defined between the two is what is resulting in slightly different estimates.

You could add a test comparing the points in raw.info after initializing a RawKIT

In my preliminary checking, I found that that there was a difference in the points, and resultantly the dev_head_t.

force other files to have the .txt extension

+1

[christianbrodbeck]

I looked through the ras-to-nm function (https://github.com/mne-tools/mne-python/blob/master/mne/coreg.py#L376) and as far as I can tell it implements the head coordinate system defined in the MNE manual (p. 97). If there are substantial numerical differences is it possible the elp/hsp files are not in the same coordinate system and still need to be transformed?

[christianbrodbeck]

It seems what you described first (transform.origin = (fids(2,:)+fids(3,:))/2;) is the "4-D Neuroimaging and CTF MEG systems" coordinate system ("The origin of the coordinate system is at the midpoint of the left and right auricular points") and not Neuromag (according to manual p. 97).

[teonbrooks]

so it would explain why the points in the legacy files are slightly different. i think doing the transform on these points might be the best solution. when doing a test with this transform, it yields similar results (to the 5 decimal) for the elp but not for the headshape. I don't know what's happening.

[teonbrooks]

@christianmbrodbeck would you mind looking at this if you get a chance? the problem is that the same transform works for elp but not hsp.

[teonbrooks]

this has been lingering for a while. I will try to resolve this. @christianbrodbeck mind looking at this with me. there's something going wrong with the hsp file transform.

[christianbrodbeck]

Sorry I’m kind of swamped at the moment, is this very urgent?

On Sep 24, 2014, at 9:47 , Teon [email protected] wrote:

this has been lingering for a while. I will try to resolve this. @christianbrodbeck mind looking at this with me. there's something going wrong with the hsp file transform.

—
Reply to this email directly or view it on GitHub.

[teonbrooks]

no, no, it's not. :) I was just clearing my to-do list.

[agramfort]

Can we close this now?

[teonbrooks]

this is a different elp file but I think the use case is rather small. it is a format used by KIT software but it can be bypassed now directly with the polhemus digitizer data. I will close it and it can be reopened if there is a demand.

[christianbrodbeck]

Hey @teonbrooks OK if I take over? At UMD these files are actually the default, they're output by the pen-based digitizer.

[teonbrooks]

totally ok if you take it over. let me know if I can be of help

[massich]

@teonbrooks why are .elp .hsp legacy? does Polhemus export .txt or is it us?

Cross ref #6461

[teonbrooks]

@teonbrooks why are .elp .hsp legacy? does Polhemus export .txt or is it us?

Cross ref #6461

the modern Polhemus export .txt files. the old setups of Polhemus used to generate those other files IIRC.