Hello Brainstorm Team,
I am having trouble coregistering one of my subject's MEG scans (acquired on a CTF system) to their individual anatomy. Their head appears above (see image below) the MEG helmet even after I attempt to refine the coregistration using their .pos file. What's odd is that this issue only appears for one run of a collection of several concurrently acquired runs and each run appears to be using the same .pos file during coregistration.
At first, I thought that it may have been some file issue that occurred after transferring the file from one location to another, so I deleted the subject and began again using their original data files. This did not resolve the issue.
S08pre_ON50_MEG_3D_coreg_OUTSIDEHELMET.tif (180.4 KB)
I've attached the .pos file and I wasn't sure what was the best way to share .ds folder for the MEG run?
sub-S08pre_ses-20190424_headshape.pos (8.0 KB)
Any help would be greatly appreciated!
Best,
Katie
The localization of the head is saved in the .res4 file of the .ds folder.
At the beginning of each recording session, the CTF acquisition system sends a current in the head localization coils in order to detect their position with respect to the MEG sensor array. This information is saved in the recordings and can't be fixed after. Sometimes this step fails, and you can rely only on manual fixes (eg. in Brainstorm, copy the channel file from another run).
The .pos file is used only for a much smaller transformation: from the CTF coordinate system (based on the head localization coils NAS/LPA/RPA identified in the MEG) to the Brainstorm coordinate system (possibly based on the anatomical fiducials: the real nasion and ear landmarks set in the MRI viewer).
This is possible because this .pos file should contain both the CTF coils (NAS/LPA/RPA) and the antomical landmarks (Nasion, left ear, right ear).
If you suspect any issue related with the .pos file: simply remove it from the .ds folder before linking it to the Brainstorm database, and you'll be left with what was really saved by the CTF acquisition workstation.
@ebock @Marc.Lalancette Is this correct?
That's correct, but it's also more complicated.
CTF localizes the head 2 slightly different ways. The original way localizes before the recording starts, and that's the position that gets saved in the .hc (head coils) file and used to compute the relative position of the sensors (in head coordinates) in the .res4 file. It's also the position used by default by practically all software. CTF eventually added continuous head tracking which is saved as channels along side the MEG data, for the x,y,z coordinates of each of the head coils. But many analysis tools do not use this additional information.
In your case, it looks like the initial localization failed and the "default" position was used. The default position is configurable, but the default default position is high above the helmet and at a 45 degree rotation, which looks like your case. Now, Brainstorm has additional head motion tools to make use of the continuous head tracking, so you can replace that poor initial position. You'll want to make sure the continuous tracking was valid, by looking at the fit errors, and the motion time series for example.
I would still recommend looking for notes or talking to whoever collected the data to know what happened.
Cheers,
Marc
Could that be a consequence of one of the coils falling from their position?
I remember it happened in a couple of participants and I corrected it as soon as I caught up. Normally, we'd just re-do the scan if we had enough time, but sometimes we just couldn't.
Hi Zaida! Not just one no, all 3 coils are above the helmet here. After you clicked ok to accept the initial position, you would have seen a small window warning the localization failed and asking if you accepted to use the default head position. You can also double check inside the .hc file (small text file), if the "default" position matches the "measured" position, both in dewar coordinates.
I would recommend always looking at the continuous tracking (to make sure nothing looks wrong with it) and updating the initial position based on it as described in that tutorial.
I followed the tutorial that Marc mentioned, but I was unable to fix the problem. After using the defaults mentioned in the tutorial I received this error:
** Error: [process_adjust_coordinates] Import > Channel file > Adjust coordinate system
** Line 40: ctf_seek (line 40)
** Epoch #1 is not accessible in any of the meg4 files of this dataset.
**
** Call stack:
** >ctf_seek.m at 40
** >in_fread_ctf.m at 92
** >in_fread_ctf.m at 81
** >in_fread.m at 84
** >process_evt_head_motion.m>LoadHLU at 358
** >process_evt_head_motion.m at 24
** >process_adjust_coordinates.m>AdjustHeadPosition at 473
** >process_adjust_coordinates.m>Run at 174
** >process_adjust_coordinates.m at 24
** >bst_process.m>Run at 229
** >bst_process.m at 36
** >panel_process1.m>RunProcess at 151
** >panel_process1.m at 26
** >gui_brainstorm.m>CreateWindow/ProcessRun_Callback at 788
** >bst_call.m at 28
** >gui_brainstorm.m>@(h,ev)bst_call(@ProcessRun_Callback) at 312
**
**
** File: S08pre/@rawsub-S08pre_ses-20190424_task-AEF_run-07_meg/data_0raw_sub-S08pre_ses-20190424_task-AEF_run-07_meg.mat
**
I was a little confused by this error because I've analyzed other runs from this subject with no issues so I'm not sure why the first epoch is not accessible? Ideas?
Thank you!
This seems like something related with the way the files are handled by Brainstorm, epoched vs. continuous. Have you forgotten to change this only for this run?
https://neuroimage.usc.edu/brainstorm/Tutorials/ReviewRaw#Epoched_vs._continuous
We should improve the error, or debug if it's not simply epoch/continuous related. Can you send me the files? You can put it on /meg/meg1/... same as last time. It might be simplest to export the subject from Brainstorm and send me the zip file. It might be big, but since we're on the same network it shouldn't be an issue.
Alright I sent it. You should be able to see it now. Thanks Marc!
Sorry for the delay. Indeed the file is empty, which is why Brainstorm complains about not finding the first epoch. You can tell from the tiny .meg4 files (8 bytes each) which are the files that should contain the sensor data. And the fact there is a .lock file in the dataset folder means the acquisition program crashed, so it's probably not just a question of a bad file copy. Hopefully the person doing the scan realized this and repeated the run... Sorry for the bad news.
That's ok. Thank you for your response!