Fiducial/headmodel handling.

[georgeoneill]

I've been looking at the portions of the code which handle using fiducials and I've realised its become quite a mess in some respects. I think this needs a bit of a tidyup.

I think a part of it is how spm_opm_create is tying to be both the convert and headmodel specfication elements of SPM, which I think is a noble effort but just needs some finessing (which I am happy to do). I'm wondering if we need to separate out the importing of data and the headmodel specification into seperate routines (like what happened to spm_opm_sim). But have the option to call the headmodel specification from spm_opm_create if required. This can be done in a fashion which means the end user doesn't notice the difference, but tidies up the code a bit.

Some proposed behaviours.

• If S.coordsystem provided, but not S.sMRI. Read in fiducials and export them to dataset. Dont bother trying to register, but keep fiducials. This would be the closes to an spm_eeg_convert behaviour where all the neccesary files are imported to at least play with the source reconstuction in the GUI or live in the batch universe after that,
• If S.coordsystem not provided but S.sMRI is, assume the sensors and anatomical are in the same space. Export fiducials derived from SPM to the dataset. Initiate the coreg.
• If S.coordsystem provided, and S.sMRI=1 (for template). Read in fiducials and export them to dataset. Possibly handle some headpoints from, say, a polhemus or iPad. Initate the coregistration.
• If S.coordsystem provided, and S.sMRI is an actual anatomical, do the registration between the provided coil and anatomical landmarks (if found) in coordsys.json. Initate coreg.
• If S.coordsystem provided, and S.sMRI is an actual anatomical, do the registration between the provided coil locations in S.coordsystem and the derived fiducials from SPM preprocessing. Initiate coreg.

Most of these behaviours are already available in the code with have (with some tidying up, having everthing being called coil1, coil2 etc. might be too reestrictive a behaviour) or we can hand everything over to the headmodel specification matlabbatch on behalf of the user.

Thoughts?

[tierneytim]

Agree, it's a mess, fix if you can. My only wish is that there is no matlabbatch inside of the code.

[georgeoneill]

Okay, so just reporting back on the behaviour of the code. I have a test dataset when the sensors are in a completely different space to the MRI (a possibility if its a template brain or perhaps a Cerca dataset).

Here its failed to align as the default behaviour is to assume the transformation between the MRI and the sensors is identity when no explicit description of the sensor-space fiducials are supplied (i,e from coordsystem json). So far so good.

Using the coordsystem json which has the sensor-space fiducials, In this case as the antomical fields in coordsystem are optional it will try and use the derivved coordinates from the MRI. In the case of a coordsystem json having MRI landmarks supplied it will use those instead. Alignment works.,

Also please to say its still smart enough to use digitised headpoints (from a "polhemus") if supplied when doing a registration. In the case below its the registering to the template brain.

[tierneytim]

cool stuff George, maybe a warning needs to be thrown for first case

[tierneytim]

did not mean to close.

[georgeoneill]

Agreed with the warning. Once I've finessed the last bugs I'll trigger a pull request.

[georgeoneill]

https://github.com/tierneytim/OPM/pull/7

[tierneytim]

Think you need a final D.save after the headmodel stage, but maybe this is my superstition

[georgeoneill]

Thats a good point, I'll chuck that in for safety,

[georgeoneill]

Right #8 should be it, but no rush to pull now, can do tomorrow. Toot toot!