Digitization: how to use .pol files, continued

[ecoffey]

Dear Francois,

I am using someone else's dataset, who did not use Brainstorm to do their headshape digitization, so the file is in .pol format and I don't have a .pos file.

The first three points digitized were the HPI coils, and afterwards they did multiple trajectories over the head in an anterior-to-posterior direction and side to size, so points all over the head and some on the brow and nose that I suggested. They sent me a 3D matlab figure that looks entirely normal to our standard McGill digitization strategy.
However, I'm having trouble using it.

When I first read in the raw .ds folder, the surface comes up with some points already on it. These have EEG labels, though they are not all EEG and are in the wrong places, so I don't intend to use them and they aren't meaningful. At this stage it looks like this:

If I right-click on the file > Digitized head points > Add points > and navigate to my .pol file, it tells me "315 new head points added. 315 duplicate points (ignored). Total 325 points" and adds a shell of points in a funny orientation. I also notice that there are three clusters of large numbers of points that are probably at the HPI coils, but I don't think that these were digitized by my colleague as they don't make much sense and were not present in that matlab 3D view I mentioned above. Now it looks like this:

If I attempt to use these head points to refine registration, nothing changes and it says: " The optimization failed finding a better fit"

Since I believe the EEG points are useless, I went to Digitized head points > Remove all points. I then tried to reload the .pol file. Now the EEG points are gone and it looks like this:

If I refine using head points now, I still get no change and a warning that a better fit was not found.

I looked at some forum topics and found the suggestion of reformatting the .pol data in the same format as the .pos files. However, looking at a past (successfully used) .pos file as an example, it' s not clear what's what. In the good file, I have abut 430 lines each numbered sequentially, and then 3 coordinates, and at the end there's the nasion, LPA and RPA twice. 430 is more than the number of points that were collected, I believe.

In the new, problematic .pol file, I have about 315 lines, and the first column repeats the sequence 01-04. And then there are 6 instead of 3 columns of presumably coordinates. Every number 01 has an extra column that has a 1 in it, but in one case a 0. Here is the first bit:

01 27.62 26.77 7.56-178.20 4.48 28.43 1
02 25.98 34.09 9.83 130.25 23.66 -85.92
03 19.67 34.41 1.50 36.42 -45.01 58.85
04 14.06 31.64 9.70 69.29 64.96 93.85
01 14.11 24.35 8.31 5.95 17.98 88.46 0
02 24.92 33.92 9.94 131.68 22.87 -84.48
03 18.54 34.14 1.69 36.90 -44.69 60.84
04 13.23 31.28 10.04 72.73 65.67 96.30
01 18.89 33.41 4.10 -74.23 12.51 79.10 1
02 25.18 33.93 9.94 130.72 23.13 -84.74
03 18.85 34.13 1.62 36.74 -44.48 60.09
04 13.53 31.31 9.96 70.63 65.26 94.67
(...)

So now I' m out of ideas about how to use or convert this .pol file! Do you have any suggestions?

Thanks,

Emily

[Francois]

Hi Emily,

To be useful, the .pol/.pos file must follow one of these constrains:

1. being saved in the same coordinate system as the MEG (what is done with Elekta systems),
2. include both the anatomical fiducials (NAS, LPA, RPA) and the position of the head localization coils (HPI-N, HPI-L, HPI-R) - this is applicable only in the case of a .pos file copied in the .ds folders, which is what we do at the MNI
3. include only one set of fiducials (NAS,LPA,RPA), corresponding to the position of the head localization coils, and in this case you must define the same coil points in the MRI viewer when importing the anatomy (instead of using the real anatomical landmarks, as you did with MEG recordings from the MNI).

Do NOT try to simply copy your .pol file in the .ds folder and rename it .pos, this will not work. If you want to do this, you need to rewrite completely the .pos file with the appropriate format, and you must have both the anatomical landmarks and the HPI coils (case #2).

I don’t know what file format this corresponds to, I haven’t seen this before, I can’t tell you how to use this file…
Try to get information on what each of these columns mean, what device/software produced the file, and I will be able to add this as a supported file format in Brainstorm.
You will also need to identify which are the points corresponding the to HPI coils in this file…

Good luck
Francois

[ecoffey]

Hi Francois,

It looks like I have case #3, I have only the HPI coil locations and know that they are the first three points. (I had tried to copy and rename the pol file just in case in an attempt to troubleshoot before bothering you, and indeed it didn’t work ;))

So I’ll see about figuring out where this thing came from and what it means.

Thank you,

Emily

[ecoffey]

Hi Francois,

It looks like I do have another file containing HPI coil positions and head shape (i.e. three coordinates for each point), but the format of the file is specific to this centre. I attempted to modify it to a few of the other systems like BESA but it only partly works as there are apparently differences in the head coordinate systems.

I think there are two solutions, both of which I might need some help with. The first idea is to identify which of the existing file types that Brainstorm can read in is most similar and then I can modify my files accordingly, but I’m not sure which uses the same coordinate system. The second is as you suggested to add a supported file format in Brainstorm. I’m not sure which is better / easier for you?

Information about the file: it’s a text file with ending .XYZ.
The first three rows contain the HPI coil positions: (left ear, right ear, nasion), you can see how they are orthogonal to one another by the values (Y axis = ear to ear, X is coming out of the nasion, Z is going up through the top of the head)
L.Ohr -0.11 6.42 0.00
R.Ohr 0.11 -6.42 -0.00
Nasion 8.97 -0.00 -0.00
For the main set of head points, the first column has a non-unique label like “Cont01, Cont02”. This refers to ‘contour’ of the points over the skull and is not meaningful. Then there are three coordinates that are based on the HPI coil locations as per CTF standard (?), which I believe is different for some other systems (X-Y axes switched, axis through the ears either goes through the HPI s). They were collected with some kind of Pohlemus system. The columns are delineated by some spaces, 7 or 8 depending on the line, which makes it a bit tricky to read in. At the bottom there are some unused lines that start with a label like “Cont07” but then don’t have any associated points, for example, here’s the end of the file:

(…)
Cont11 7.93 4.25 5.14
Cont11 6.40 5.24 5.34
Cont12
Cont13
Cont14
Cont15
Cont16
Cont17
Cont18
Cont19
Cont20

What do you recommend?

Thanks as always,

Emily

[Francois]

Hi Emily,

It this is a format specific to this center and created by homemade software, I will not add it to Brainstorm.

If you want to copy this file in the .ds folder and have Brainstorm use it automatically, you need to write in the same format as the .pos files created by the Brainstorm digitizer, and save with the name “datasetname.pos”. See any example file you have. This will be the only easy way to use both the real anatomical landmarks (NAS/LPA/RPA), and the HPI coils. In this case, mark the anatomical landmarks in the MRI viewer.

Otherwise, you can make it a “EEG: ASCII: Name, XYZ” file, saved with any particular name. Each line must have a unique label followed by the coordinates, saved with any name, where you want. In this case, you you cannot use the real anatomical landmarks. You work with the original CTF convention, with the labels NAS/LPA/RPA refer to the head localization coils. You need to make the HPI coils instead of the anatomical landmarks in the MRI.

Francois

[ecoffey]

Hi Francois,

Okay thanks. The real anatomical landmarks have not been collected, so I think we don’t have the .pos within folder option (my situation corresponds to #3 in your original response).

I had tried reconfiguring my file to the ASCII format but unsuccessfully (perhaps the delimiters or some other aspect of the file is not correct). Where can I find an example/template of what brainstorm is expecting for that option?

Can you confirm that the CTF coordinate system is used if we use the EEG: ASCII read-in option? I’ve been told that there is a difference between the way the horizontal axes are defined in some systems, like the BESA one is definitely incorrect.

Emily

[ecoffey]

Hi Francois,

I kind of got it working using "EEG: ASCII: Name, XYZ" file option described above, but the head position looks quite unreasonable. Is this likely to be a coordinate system problem, do you think (or a terrible recording??)?

Here's a second subject...

...and that last subject, if I don' t use the head points at all...

I suppose I could just ignore the head shape files, but I would prefer to use them as the HPI coil locations relative to the anatomical landmarks was not precise.

Do you have any tips about how to figure out if this is a coordinate system probelm?

Sorry for the trouble!

Emily

[Francois]

Hi Emily,

I don’t know what the problem can be, maybe the naming of the point in your text file is not correct, or you selected the anatomical landmarks in the MRI instead of position of the coils?
If in your digitized file you don’t have both the anatomical landmarks and the HPI coils, you have to set the HPI coils as NAS/LPA/RPA points in your MRI.

If the registration looks that bad without any correction with the head points, either the HPI are not correctly positioned in the MRI, or the subject was not seated well in the MEG (which is a frequent issue).

I will be away for 10 days, but if you want me to look at it, send me your data and I’ll see if I can help when I come back.

Francois

[ecoffey]

Hi Francois,

I confirm that I selected the HPI coil positions as LPA, RPA, etc in the MRI registration. The last picture above is from the data read in without the head points. It looks more reasonable (the subjects are supine and it’s a long sleep recording so they don’t stay all the way in, but the head should be at least somewhere near the business end of the helmet! )

If you’re willing to look at it, yes please. Presumably you have remote BIC access? I already uploaded a dataset for Beth to play with, I can just add the position files and anatomy.

Thank you!

Emily

[ebock]

HI Guys,
I have tried to follow this discussion and I see at the very end, you are telling me you already gave me the data. If it is “subjectthatrunsbutisslow” I might be skeptical of the position of the subject since the fit errors are really high throughout and even the first position in the continuous channel is very far from the head localization. The “subthatwontrun” looks better.
Also, is the subject wearing an EEG cap? Could be they are actually this far out. Do you have any photos? Do they use this head support in supine? This can make the subject out of the helmet.
Beth

[ecoffey]

Hi Beth,

The subject is wearing 2 electrodes but not a full cap. They are supine, with the support.

I have a picture but from far away on the monitoring screen, and only for a different subject - don't think it's that useful. I blurred the face a little bit for privacy.

I'm putting the positioning files in the ../subthatwontrun/ folder, the .pol which is the unintelligible CTF file, the .XYZ file that they produced somehow, and the brainstorm.XYZ file that I attempted to reconfigure so that Brainstorm can read it in with the EEG ASCII option Francois suggested. Do you need some anatomy or would a std brain do?

My colleagues have finished about half of their data collection. What would you suggest to improve registration issues for the second half? I'm thinking putting the HPI coils up higher, marking the anatomical fiducials with their tracking system in addition to the HPI coil locations, photographing the HPI positions, getting brown and nose coverage, and just trying to wedge the subject in a bit better. (The head points won't help though, if there's some kind of coordinate system problem).

Emily

[ebock]

It looks to me like the subject is pretty far out of the helmet. The front edge of the helmet is at the hairline. We don’t use that head support because it doesn’t get them in very far. Instead we purchased some memory foam and can add it under the back of the head and neck for support.
We typically put the coils higher up - especially the nasion - because they are not captured well once they are near the edges of the helmet. However, you do need to take good photos or capture both the HPI and anatomical points if you don’t put the coils at the normal locations. Brainstorm digitizer does this.
It could be interesting to see how this subject in the photo looks under the helmet after registration in Brainstorm - it might give you a better idea about how the other subjects should look.
I’ll try to have a look at the positioning files next week.

[ecoffey]

Thanks Beth. I don’t have that subject’s data yet but will check it carefully when it arrives.

E

[ecoffey]

Hi again,

I’ve managed to understand my digitization file and reorganize it in a sort of standard format, by modifying some fieldtrip functions, that looks reasonable when I plot it with the gradiometer positions taken from inside the CTF .ds folders (this suggests that the coordinate system and units are correct).

I’d now like to read it out, either using a fieldtrip funtion or configuring it myself, in some format that Brainstorm will understand.

There is a fieldtrip function, ft_write_headshape, which “writes a head surface, cortical sheet or geometrical descrition of the volume conduction model or source model to a file for further processing in external software.” The output options for this are:

Supported output formats are
’mne_tri’ MNE surface desciption in ascii format
’mne_pos’ MNE source grid in ascii format, described as 3D points
’off’
‘vista’
‘tetgen’
‘gifti’
‘stl’ STereoLithography file format, for use with CAD and generic 3D mesh editing programs
’vtk’ Visualization ToolKit file format, for use with Paraview
’ply’ Stanford Polygon file format, for use with Paraview or Meshlab
’freesurfer’ Freesurfer surf-file format, using write_surf from FreeSurfer

The Brainstorm import menu found be doing this: Right click on channel file > Digitized head points > Add points offers quite a number of different formats, but I don’t see any in particular that match up.

Might someone know which fieldtrip export option I should use and which Brainstorm import option would correspond, or conversely could provide an example of one of the ASCII files that works with CTF-coordinates points? Right now the format of my data are 3*HPI coil positions (X,Y,Z), and about 80 scalp points with no label just coordinates, so I suppose I can save them however.

-E

[Francois]

The file formats you are listing here are used to export meshes (lists of triangles), I guess for storing the FieldTrip head model (= the head+cortex surfaces). This will be of no use for you here.

You can save files you list of 3D points in simple ASCII files “Name, X, Y, Z”.
If you don’t mind adding a column manually in your file: save the only the 3D coordinates of the 83 points with Matlab’s save function (adding parameter ‘-ascii’), then open it with the text editor and add a column for the names (eg. NAS, LPA, RPA, 1, 2, 3, …)

[ecoffey]

Hi Francois,

I've tried this, it puts the helmet on sideways (looks like it's rotated 90 degrees to the right or so, inset).
I have used the ASCII NAME.XYZ read-in option, is that correct?

E

[ecoffey]

Okay I tried switching around some of the columns and weirdly it didn't seem to do much.

However the trick seems to be deleting the raw file from the database and reading it in again, erasing any existing points, and adding your own new points in the format described above, each time you try something or rearrange the file.

If you try to delete and add new points after already having played around with it, the incorrect position of the head is somehow retained.

So now I have:

(this seems correct, note that we have some issues with getting heads to stay up inside there during sleep recordings so that's unfortunately the actual position for this sub).

For posterity: I think if you need to update your head shape files, you need to read in your recording again as deleting the old ones, adding new ones, and using the registration algorithm again doesn't fix the problem.

[Francois]

If this is so approximate anyway: maybe you should not even bother doing this and use only the NAS/LPA/RPA points for the registration…

[ecoffey]

Not for this file, but in general good precision is going to be important. We’re working on the head position issue so this will apply to better positioned recordings too, and are improving the registration to MRI, so I very much don’t want it to be approximate. Running the registration algorithm with the head points does seem to give a better alignment between the head shape points and MRI. I was also planning to try using Beth’s movement detection thing to break the .ds file into sections (It’s a long recording with inevitable movement), in order to be as precise as possible for the models and localization. (I think this funny thing that the head position is somehow retained might be a problem though, unless perhaps I don’t read in any shape points until after the file is split). Is this a bug or is it supposed to do that?