Back to the main page.
Bug 2837 - extend and document electrocorticography (ecog) tools
| Status | CLOSED FIXED |
| Reported | 2015-02-11 13:57:00 +0100 |
| Modified | 2019-08-10 12:33:14 +0200 |
| Product: | FieldTrip |
| Component: | documentation |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P5 normal |
| Assigned to: | Arjen Stolk |
| URL: | |
| Tags: | |
| Depends on: | 279328393013 |
| Blocks: | 3059 |
| See also: | http://bugzilla.fcdonders.nl/show_bug.cgi?id=2781http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=3033http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=3096 |
Arjen Stolk - 2015-02-11 13:57:13 +0100
There is a growing interest in tools that promote the analysis of (human) ECoG with FieldTrip. This bug aims at systematically implementing and documenting tools that either exist or require development. An initial but not fully exhaustive list includes: 1) a general pipeline for preprocessing (e.g. lay-outs, re-referencing), analyzing, and plotting EcoG data 2) accurate co-registration of sensorspace electrode positions (CT-scan) and sourcespace brain voxels/surface points (MRI-scan) 3) an approach for group analysis (e.g. warping single-subject electrodes to a template MNI-brain) 4) an approach for linking electrode positions to cortical parcellations and labels (e.g. electrode xxx over area xxx) More suggestions are welcome. Some relevant existing documentation: related to point 1: http://fieldtrip.fcdonders.nl/tutorial/ecog http://fieldtrip.fcdonders.nl/tutorial/layout http://bugzilla.fcdonders.nl/show_bug.cgi?id=2781 More references are welcome.
Tzvetan Popov - 2015-07-15 13:39:35 +0200
Monkey Ecog is coming from : http://neurotycho.org/
Tzvetan Popov - 2015-07-15 13:39:58 +0200
Template macaque brain: http://www.bic.mni.mcgill.ca/ServicesAtlases/MacaqueDownload
Tzvetan Popov - 2015-07-15 14:07:47 +0200
Breaking down the tutorial: 1) Various sources of distortion: - lens distortion will lead to mismatch between MRI and photo of the electrodes - MRI is also misplaced, e.g. brain is at different position with respect to the skull while seated and supine.
Tzvetan Popov - 2015-07-15 14:15:18 +0200
Created attachment 718 Dalal et al. 2009
Arjen Stolk - 2015-07-15 14:21:44 +0200
Created attachment 719 Miller et al., Brain surface electrode co-registration using MRI and x-ray
Arjen Stolk - 2015-07-15 14:22:40 +0200
Created attachment 720 Hermes et al., Automated electrocorticographic electrode localization on individually rendered brain surfaces
Tzvetan Popov - 2015-07-15 15:51:32 +0200
For the tutorial documentation: - clarify the difference between EcoG, iEEG and stereotactical EEG. iEEG and stereotactic are the same.
Tzvetan Popov - 2015-07-15 16:05:41 +0200
Provide a documentation of the existence and usability of the macaque template
Arjen Stolk - 2015-07-15 18:04:47 +0200
The general approach for now is to chunk the relevant analysis steps, depending on the type of data available, e.g.: -preprocessing of ecog data (maybe buttonpress data?) - though this may be obsolete given the already present tutorials on this step regarding eeg and meg data -photography-based layout and topoplotting -co-registration of x-ray and mri to obtain 3d electrode positions on a rendered cortical surface (for surface-based plotting of data), see directly below In a nutshell, x-ray & mri co-registration involves (according to Miller et al. technique): 1) manual overlay (by stretching etc) of a rendered cortical surface* on a CT scan, such that the outlines overlap (Fig 4A, note this is a y- and z- dimension view, with x-dimension ignored at this stage) 2) manual placement of 'anchor points' in 2D (e.g. on brain outline, Fig 4B) 3) removal of the cortical surface overlay, such that the anchor points, as well as the electrodes, become visible and assignable on the x-ray 4) calculation of a scaling factor s, between anchor positions on brain b and x-ray x, etc. 5) 3rd projection of 2d electrode positions on cortical hull idea for a first step: construct manual (or automated) image registration/alignment, in which (transparent) MRI volume (or slice, e.g. mean along x-dimension) is overlaid on x-ray (see interactive code in ft_electro/volumerealign, defacevolume)
Arjen Stolk - 2015-10-26 20:47:38 +0100
(In reply to Arjen Stolk from comment #9) notes from meeting with Cal, on ecog recons: 1) MR (structural, mostly multiple, requires selection of the best one - in bioimage suite): dicom images -> anonymize (Jamie's script) -> .nii -> bioimage suite 2) CT (mostly multiple scans (eg 5-15), requires selection of the best one - in bioimage suite): dicom images -> anonymize (Jamie's script) -> .nii -> bioimage suite -> convert to 3d (consider PRS to LPS orientation) 3.1) Recon/coregr (product of MR and CT): bioimage suite -> load in MR -> brain extraction bioimage suite -> load in CT -> threshold so that electrodes are visible (grids are not visible on intra-operative MR) -> determine coordinates of electrodes in CT space 3.2) Cogregr ct to extracted brain (Jamie's script, spits out multiple trans matrices, e.g. linear, affine) -> bioimage suite -> select the best transformation matrix (e.g. linear inverse, generally works best) by comparing electrode positions to brain 3.3) Coregr extracted brain to mni (Jamie's scripts)
Arjen Stolk - 2015-10-26 21:04:02 +0100
Quick follow-up on this, a first time-saving implementation would be to make a thresholding tool that allows sliding the image intensity thresholds such that the electrodes can be isolated from brain tissue. Then there should be an option to (bwlabel alike) identify the separate image blobs (electrodes), and assign an electrode position to the center coordinates of each blob. Ideally, those positions are also spit out in bioimage suit compatible format.
Robert Oostenveld - 2015-10-27 09:44:40 +0100
(In reply to Arjen Stolk from comment #11) I suggest a ft_volumethreshold function that takes a volume as input, default cfg.parameter=anatomy, and that presents the 3-ortho-view like ft_sourceplot and two sliders: one for the lower and one for the higher threshold. There would also be a button to toggle between the view of the full anatomy (grey values) and the thresholded binary image (black-white). And/or the result of thresholding would be shown color coded and with opacity on top of the anatomical MRI (in grey values).
Jan-Mathijs Schoffelen - 2015-10-27 09:53:22 +0100
We could consider building this into ft_volumesegment with cfg.method = 'interactive'; Don't know whether this merits a separate function. Note, there's a private function called volumethreshold. Note, tangentially, there's also a private function called volumeedit, which may deserve to be called from within a higher level ft-function (e.g. ft_volumesegment) to do additional manual refinements to any segmentation. It was designed to improve the white matter segmentation provided by freesurfer, but it might be useful for Arjen's purposes as well.
Robert Oostenveld - 2015-10-27 09:54:22 +0100
(In reply to Jan-Mathijs Schoffelen from comment #13) thanks, those are valuable suggestions!
Arjen Stolk - 2015-11-09 01:03:16 +0100
Thanks both. Just wanted to let you know I'm still gaining intel from others and exploring the different functions out there. It seems that the volume thresholding and automatic electrode assignment may be a great addition, just is not bulletproof. The CT scans may contain artefacts (e.g., electrode blurring in a certain direction), so some manual labor is still required or even the predominant approach, in the form of handpicking electrodes. Another desired functionality, I think (but haven't seen it in other toolboxes), is to change the luminance/intensity of the image for spotting the electrodes in the first place. In conclusion, it seems a separate function may be needed here, e.g. ft_electrodelocalise, that does all that. For overview purposes, this gui should: - large view of a CT slice - toggle between different views (toggle) - adjustment of intensity/luminance (sliders) - handpicking of electrodes, and undoing (mouse polling and clicking functionality) - thesholding and automatic selection of electrodes
Arjen Stolk - 2015-11-10 08:41:08 +0100
Created attachment 751 ft_electrodelocalise Work in progress: The bottom slider allows moving 1 slice in the z-direction. The slides on the side allow changing the intensity of the image. It's become clear that automatic thresholding is not going to be a desired feature: there is overlap in intensity between electrodes and skull tissue, meaning that simple intensity-based thresholding is not straightforward. Desired features: 1) Ability to specify electrodes labels, for guiding the selection process and assignment process (two birds with one stone). For instance: cfg.eleclabels = hdr.labels; makes a list of electrodes show up on the side. Each time an electrode is selected, the electrode label on the top of the list disappears (=assignment). Otherwise, the labels list will be a growing; 1, 2, etc, i.e. in order of selection. One thus later has to sort these out / re-assign them so that they match the hdr.label. 2) Another realtime axis showing the selected electrodes in 3D (e.g. plot3).
Robert Oostenveld - 2015-11-10 10:52:13 +0100
(In reply to Arjen Stolk from comment #16) we should try to keep the functions consistent. There is now ft_sensorrealign and ft_electroderealign. I always forget why there are two, but somehow there was a reason. I am aware that I am always asking myself: "why are there two separate functions?" but I always forget to write down the answer. The method=manual option in ft_sensorrealign allows for clicking electrodes (on the skin surface). That is functionality-wise similar to what you are now trying to implement (i.e. manual placement, of course your geometrical input data is different).
Jan-Mathijs Schoffelen - 2015-11-10 11:03:31 +0100
Note: -there's a hidden option in ft_volumerealign that allows to store additional points (i.e. beyond the fiducials), to be achieved by right-clicking. (I intended this once upon a time to mark electrode positions on patient CTs :o). -fieldtrip/private/volumeedit has an efficient way of going through slices quickly (if I remember correctly, by moving over the panels with the left-button pressed). -w.r.t the electroderealign/sensorrealign: there's also an interactiverealign
Arjen Stolk - 2015-11-10 16:55:43 +0100
(In reply to Jan-Mathijs Schoffelen from comment #18) Many wheels invented already. Ill check those out as soon as im sure sbout things like the layout, eg ortho vs single slice view. Thx for the tips. Speed is an issue. The ortho is relatively slow ( clearing many of the uiresumes helps) so volumeedit may certainly be interesting.
Arjen Stolk - 2015-11-11 07:11:13 +0100
Created attachment 752 version 2 Not fully functional yet. The idea is to have 1) A list of electrodes for selecting/assigning, either with cfg.channel = hdr.label in the function call. Otherwise a list is automatically created consisting of elec1, elec2, .. Each time a elec label is clicked, its font turns black, and the position of the crosshair is stored (latter needs to be implemented). Also a marker needs to be placed. 2) Labels radiobutton allows seeing the labels associated with the markers within the orthoplot (to be implemented). Otherwise correcting say the order of an electrode array would be impossible. 3) Magnet radiobutton activates a search to a near-click-location (e.g. 3mm radius) peak intensity voxel (to be implemented).
Arjen Stolk - 2015-11-11 07:52:56 +0100
(In reply to Arjen Stolk from comment #20) BTW, so far there's strong overlap in code with the ortho part of ft_volumerealign. However, that function name does not fit well the present purpose of localizing electrodes. :/
Robert Oostenveld - 2015-11-11 14:49:53 +0100
the http://www.fieldtriptoolbox.org/tutorial/ecog tutorial explains the 2D layout for plotting, but not the procedure for obtaining 3D electrode positions (as it is not needed there). Arjen is currently working on the 3D positions.
Robert Oostenveld - 2015-11-11 15:03:40 +0100
I made a new function (actually Arjen made it, I only added it to SVN) for electrode placement (e.g. by poking the surface or a CT/MRI). mac011> svn commit ft_electrodeplacement.m Adding ft_electrodeplacement.m Transmitting file data . Committed revision 10873. See also bug 2837.
Robert Oostenveld - 2015-11-11 15:55:42 +0100
(In reply to Robert Oostenveld from comment #23) mac011> svn commit ft_electrodeplacement.m plotting/ Sending ft_electrodeplacement.m Sending plotting/ft_select_point3d.m Transmitting file data .. Committed revision 10875. Placing electrodes on a surface now works. mac011> svn commit ft_electrodeplacement.m plotting/ Sending ft_electrodeplacement.m Sending plotting/ft_plot_mesh.m Transmitting file data .. Committed revision 10876. And this makes it even better. Try this cfg = []; cfg.headshape = ft_read_headshape('surface_pial_both.mat') ft_electrodeplacement(cfg)
Arjen Stolk - 2015-11-13 01:58:56 +0100
Created attachment 754 ft_electrodeplacement Function is good to go. Might do a bit more tweaking, but in essence it works pretty good. Especially the magnet feature makes it easy to directly localize electrodes and their center coordinates.
Arjen Stolk - 2015-11-14 03:20:00 +0100
(In reply to Arjen Stolk from comment #25) See this documentation for a human ecog pipeline in spe: http://www.fieldtriptoolbox.org/tutorial/ecog The electrodeplacement bit is ready. Previously, we've built in support for reading in ecog data recordings in edf fileformat (the bay area standard it seems). What needs emphasis still is: 1) coregistering CT to MR: explore specialized algorithms out there (AFNI?) 2) projecting electrodes to a brain surface hull to correct for the ~1cm brain shift under CT (due to surgery drugs; necessary for grids only) 3) project/plot data on a brain surface (I believe Roemer has quite some experience here)
Robert Oostenveld - 2015-11-16 12:02:25 +0100
(In reply to Arjen Stolk from comment #26) I don't think that monkey and human ecog should be part of the same tutorial. Perhaps for human we should start with only an example page, as we'll also not be sharing data.
Arjen Stolk - 2015-11-16 19:04:37 +0100
(In reply to Robert Oostenveld from comment #27) Agreed, I've created this (unlinked) page for the moment. We can choose a different title and location as it evolves: http://www.fieldtriptoolbox.org/faq/how_can_i_place_electrodes_on_an_anatomical_ct_or_mr
Roemer van der Meij - 2015-11-16 19:41:43 +0100
Hadn't responded here yet, but fantastic work Arjen! I currently don't have much experience localizing electrodes, the data I've used always had it done already. But I will be doing this more often, and will gladly contribute. I'll be mostly working with depth electrodes, so will mostly be able to contribute there. Plotting I've done with custom code for years. Single value per electrode, but also vectors/matrices. Can contribute there! W.r.t. to reconstructions: One thing to keep in mind though, when writing code/documentation, is that there's not a lot of standards. Many labs do it in different ways. Some, like e.g. the Knight lab, use a preop MR and a postop CT, others use pre/postop MR (which will probably become more common?). Some do it in Talairach space (e.g. the Kahana lab), some in MNI. Not saying of course we should worry about this, but just to keep it in the back of our mind (e.g., not enforcing a CT in MNI as input). Fantastic work Arjen, looking forward to using it! The tools I've seen so far, often a patching together of random software bits it seemed, were not great. Time to do it better! :)
Arjen Stolk - 2015-11-16 19:58:49 +0100
(In reply to Roemer van der Meij from comment #29) Nice to see your enthusiasm! And welcome aboard :P
Arjen Stolk - 2015-11-21 00:22:40 +0100
(In reply to Arjen Stolk from comment #30) One more objective down: coregistration & electrodeplacement are implemented http://www.fieldtriptoolbox.org/faq/how_can_i_place_electrodes_on_an_anatomical_ct_or_mr Open/remaining challenge: correct for a brainshift in CT (grid cases) by, for instance, projecting electrodes on a surface hull. The same hull could also be used for plotting ecog data.
Robert Oostenveld - 2015-11-25 11:03:37 +0100
On 20 Nov 2015, at 21:30, Arjen Stolk wrote: Heb die viewdim's ingebouwd in realign and sourceplot: svn commit ft_volumerealign.m -m 'enhancement: added the possibility to change the orthoplot axes, either square of data dimension-dependent' svn commit ft_sourceplot.m -m 'enhancement: added the possibility to change the orthoplot axes, either square of data dimension-dependent' ------------- I will follow this up in bug 3013
Robert Oostenveld - 2015-12-04 10:47:25 +0100
The development of documentation is too scattered and inconsistent, us working on out (jointly) should be more transparent and include contributions from all. I renamed the existing ecog tutorial to monkey_ecog. I have deleted http://www.fieldtriptoolbox.org/faq/how_can_i_place_electrodes_on_an_anatomical_ct_or_mr and moved the content over to the new http://www.fieldtriptoolbox.org/tutorial/human_ecog This page is linked in the tutorial overview and I expect all relevant documentation to appear here. It does not have to be perfect from the start, but by having it visible we can have many people contributing on perfecting it!
Arjen Stolk - 2015-12-06 00:58:55 +0100
(In reply to Robert Oostenveld from comment #33) Thanks for thinking along, Robert. It seems the website wasn't updated yet, so I've created that human_ecog weblink myself. Haven't incorporated the other changes you mentioned (renaming/relocating animal ecog, deleting old elecetrode placement page). The status quo: In principle, the pipeline is finished for analyzing depth-recordings. I've tested in on a couple of tough cases (patients with big lesions/lobotomies, poor quality scans), but the coregistration using spm12 seems to operate just fine (because it looks for mutual information across ct and mri, which mostly constitutes the skull). Another positive aspect is the little amount of time manual labor needed. A rough layout of the steps and their required time: - read in and align the mr (<1 min, manually) - read in and align the ct (<1 min, manually) - coregistration of the ct to the mr (<5 min) - localize electrode positions on the ct (<15 min, manually) - create surface mesh using freesurfer (~8 hours, not manually!) For grid-recordings, what needs to be added still is a correction for the 'brain shift' (obj #1). Practically, this involves the creation of a brain mask/hull, and project the positions stored in elec.elecpos onto it using a still to be selected algorithm. Some input/suggestion is needed here. There is a project_elec function in the private dir. And ft_volumesegment allows building brainmasks, but those are based on the whole brain (incl. csf), whereas ideally we have a smooth surface around the cortex (i.e. as how an electrode grid would lay over the cortex). The second remaining objective (obj #2) is to develop/adjust the existing plotting functionalities for plotting the ecog data on the freesurfer meshes. Some Roemer-magic may come in handy here. ;) A third, less critical point (obj #3) is to investigate the quality of inter-brain coregsitrations/normalisations for plotting ecog data or electrode locations on a template/group mri/surface.
Robert Oostenveld - 2015-12-06 14:24:53 +0100
(In reply to Arjen Stolk from comment #34) Hi Arjen, On Friday the DCCN web server crashed and had to be restored from backup. A few hours of work have been lost.
Arjen Stolk - 2015-12-06 19:01:47 +0100
(In reply to Robert Oostenveld from comment #35) Ouch :/
Roemer van der Meij - 2016-02-01 21:56:24 +0100
I'm working on one of the plotting functions right now, and I have a request. Could we provide an additional field in the elec structure, indicating whether an electrode is a 'surf' surface electrode, or a 'depth' electrode. Could we use the field elec.chantype for this? If so, Arjen, do you think we could add this distinction in ft_electrodeplacement? The reason is simple, surface electrode need to be plotted on a pial surface, while depths need to be plotted on an MRI, which both require different handling in terms of preparing and visualization and things like surface area coloring. Another option is for this to be user-provided information, but I think it blends well with ft_electrodeplacement. Thoughts?
Roemer van der Meij - 2016-02-04 00:04:42 +0100
I'm going through the tutorial a bit, and got stuck at realigning the CT prior to coregistration. According to the tutorial I have to define the ears, nose, and midline. But, how do you do that? Ear's are big :p. Or isn't it that important? Either way, the reader will be curious as well. I couldn't see anything at the CT due to the contrast limit, so I stole and added the intensity sliders from ft_electrodeplacement. Thanks! ;). (waiting on approval of the pull request currently). The sliders half disappeared in the background, as that was set to white by default. I changed this back to matlab defaulting it, making the sliders fully visible. I noticed the same thing actually in ft_electrodeplacement, would be great to change there too. Even with modifying the contrast, I could still not identify the ears though.
Roemer van der Meij - 2016-02-04 00:25:09 +0100
(made ft_electrodeplacement contrast changing quite a bit faster by removing the explicit clipping of the data, which existed both there and in ft_plot_ortho, ft_plot_slice handles this using a quick caxis)
Arjen Stolk - 2016-02-04 02:33:15 +0100
Nice work! Yeah, clicking the exact location of the ears is not necessary, on the CT. It's just to ensure left is left and right is right.
Roemer van der Meij - 2016-02-06 01:26:37 +0100
RE brain shift: I've been thinking about this a bit. Thought would be maybe good to brainstorm a bit. I'll try and find an 'extreme case' of a brain shift and attach it. Goal: make electrodes from grid fall exactly on the subject's individual cortex, as the grid should be. Step 1: obtain smoothed surface from pial surface/MRI - I've seen this popup occasionally while browsing through some of the source/headshape related functions. Am I correct in that something of this form is already implemented? Step 2: wrap grid on smooth surface This can be really sophisticated, but I find it hard to get my search terms right for this, because I'm sure some algorithms exist. We can't simply do a 'closest point on surface for all electrodes simultaneously', because that would not take into account the inter-electrode difference, which should remain intact, to some reasonable degree at least. So, here's the simplest algorithm I can think of right now. 1) find inter-electrode distance: average of distance to closest neighbor for each electrode using their xyz coordinates 2) for electrodes with a distance to the nearest surface point of 5% of this, snap the electrode to this point. 3) lock these electrodes in place 4) find the electrode with the next biggest distance to the surface 5) shift this electrode to the surface 6) for all electrodes, whose x,y,z sign of the distance to the closest point on the surface is the same, move all these electrodes the same degree to the surface as the electrode in 5 7) lock the electrode in 5, and return to 2 What this hopefully achieves, is that when a grid is 'sticking out' partly, it is wrapped to the surface in a way that somewhat preserves the inter-electrode distance A more sophisticated approach in step 5 would be to fit a spline to the surface, with the origin being the closest electrode-on-surface, and the distance being equal to the electrode in 5 the this origin. Save the endpoint of the spline. Do this for some number of splines whose endpoint will be close to the electrode in 5 (or all in the circle from the origin) and select the spline whose endpoint coordinate has the least difference with the electrode in 5. That will be the new location of the electrode in 5. Use the translation to shift all electrodes, following step 6. Ideas?
Arjen Stolk - 2016-02-06 04:55:26 +0100
Thanks for raising this issue. I've been playing a bit with the hull creation and came up with: mesh_l = ft_read_headshape('SubjectUCI29_lh.pial'); shp_l = alphaShape(mesh_l.pos, 5); % alpha shape ft_plot_mesh(mesh_l,'facecolor', [0.781 0.762 0.664], 'EdgeColor', 'none') hold on; plot(shp_l, 'facealpha',0.3) lighting gouraud material shiny camlight The challenge is to snap electrodes to it, possibly using any of the sophisticated methods you outlined. I've snapped electrodes to their nearest hull coordinate, but the result was unsatisfying as those coordinates (shp.Points) are on the edges really (e.g. gyri) and never on the ridges (e.g. above sulci).
Roemer van der Meij - 2016-02-09 01:24:23 +0100
I thought we could use something like the following, which I stole from ft_volumerealign. However, it is clear the electrodes have partially 'sunk' into the brain. Which I was surprised about. For sure there could be some noise in the procedure, but it extracts 'brain' (defined as csf, white, grey), as such it should fit? Or am I interpreting ft_volumesegment incorrectly? Regardless, it made me wonder how successful the coregistration was. Could you add a step to the tutorial to check this? Is there a way we can plot both of them on top of each other? I added a fixme for the tutorial for this. ************* % read MRI mri = ft_read_mri('SubjectECoG_MR_preproc.mgz'); mri.coordsys = 'tal'; % segment mri and extract brain cfg = []; cfg.method = 'spm8'; cfg.output = 'brain'; segmented = ft_volumesegment(cfg, mri); % use extracted brain to generate surface cfg = []; cfg.tissue = 'brain'; cfg.method = 'isosurface'; cfg.numvertices = inf; brain = ft_prepare_mesh(cfg, segmented); % plot mesh figure ft_plot_mesh(brain, 'edgecolor', 'none', 'facecolor', 'cortex') camlight(0,0); lighting phong material dull set(gca,'DataAspectRatio',[1 1 1], 'PlotBoxAspectRatio', [1 1 1]); alpha(.7) hold on % add electrodes plot3(elec.elecpos(:,1),elec.elecpos(:,2),elec.elecpos(:,3),'o','markerfacecolor','r','markeredgecolor',[0 0 0]) *************
Arjen Stolk - 2016-02-09 01:42:54 +0100
"'brain' (defined as csf, white, grey)" I've been playing with ft_volumesegment in the past for this purpose. By default, the 'brain' option outputs a mask involving csf indeed, which - after carefully checking - creates a hull that is rather large. Or at least, not as tight to the cortex surface as I'd hoped. This means, for ecog purposes, we'd like to have a hull option, which is only the white and grey matter, but then smoothed so that the hull does not follow the surfaces of the gyri too strictly. I guess you can plot both meshes, making the hull mesh transparent, to see whether the freesurfer surface mesh fits?
Roemer van der Meij - 2016-02-11 20:07:36 +0100
Hey both, I added an option to ft_volumerealign, cfg.viewresult (default is no). When the input is one volume, cfg.viewresult produces an interactive figure at the end of the volume in the new coordinate space. When the input is two volumes, like in our case here, they are plotted on top of each other, using transparency masking, with the target volume being red (MRI in our case), and the realigned volume being blue (CT in our case here). It's interactive, so you can click through the ortho plot to check whether the alignment succeeded. I've added a picture showcasing it here. This might seem trivial, as realigned works perfectly in most experimental situation (?). However, in the case of ECoG, the MRIs and the CT are usually taken for medical purposes, and can contain all sorts of things that can disrupt the realignment. Examples are contrast fluid MRIs, a particular noisy anatomical sequence, and of course intense artifacts produced by (the wires from) the electrodes, especially in the case of a post implantation MRI. I'll add it to the wiki in a sec, and create a pull request to master.
Roemer van der Meij - 2016-02-11 20:09:50 +0100
Created attachment 775 Example showing cfg.viewresult for MRI + CT Note that the purpose of the colors chosen such that, when using a preop and postop MRI, the result will be purple in the case of good alignment
Arjen Stolk - 2016-02-11 20:52:23 +0100
Great work, Roemer! How did you solve the issue of the CT and MR having different dimensions? Do you reslice one of the two on-the-fly, or plot them on top of each other using different axis dimensions?
Roemer van der Meij - 2016-02-12 00:06:22 +0100
ft_plot_ortho/slice take care of that actually. As long as their in the same coordinate space, which they should if the realignment was successful, they should fall on top of each other. The images are actually surface objects, so it's not really pixels that are drawn, but polygons, and then it doesn't matter whether they are sampled identically or not. (which probably also holds for ft_sourceplot?)
Arjen Stolk - 2016-02-12 00:45:24 +0100
Niicceee. Yeah, ft_sourceplot (method ortho and slice) also call ft_plot_ortho and ft_plot_slice under the hood. I'm still very curious to see those surface renderings you made.. ;)
Arjen Stolk - 2016-03-15 03:41:53 +0100
Instead of working on my deadline, I followed a hunch. Good news is that another outstanding obstacle bit the dust, i.e. spatial normalization of electrodepositions: % normalise anatomical scan mri_n = ft_volumenormalise([], mri); % non-linear transformation % normalise electrode positions elec_n = elec; elec_n.elecpos = ft_warp_apply(mri_n.params, elec.elecpos, 'individual2sn'); Two obstacles left: 1) correct for 'the brain shift' using a 'hull', i.e. snap electrodes to outer surface 2) (surface-)plotting, projecting functional data on the brain (using ft_sourceplot method surface?) Did you make any progress with either one of these, Roemer? For instance, were you able to create a good hull? I lost track of what you were doing. :) These are the things I came up, but not happy with the results: mesh_l = ft_read_headshape(['SubjectUCI29_lh.pial']); shp_l = alphaShape(mesh_l.pos, 5); % alpha shape Freesurfer also outputs a mask, which would need further smoothing to make a hull: mask = ft_read_mri(['xxx/freesurfer/mri/ribbon.mgz']);
Arjen Stolk - 2016-03-15 04:32:06 +0100
Created attachment 783 hull, using code by Roemer
Arjen Stolk - 2016-03-15 04:34:22 +0100
That hull looks awesome - sorry, saw and tried out your code only just now. Only presumed inaccuracy is that it includes the csf as well, which is not exactly at the brain's outline? % segment mri and extract brain cfg = []; cfg.method = 'spm8'; cfg.output = 'brain'; segmented = ft_volumesegment(cfg, mri);
Arjen Stolk - 2016-03-15 04:44:17 +0100
Actually in this instance, it looks pretty good (even with csf included?): mri.dat = double(segmented.brain); cfg = []; cfg.funparameter = 'dat'; ft_sourceplot(cfg, mri); Notice that ft_volumesegment thinks that that left hemisphere hematoma is brain tissue as well.
Arjen Stolk - 2016-03-15 04:47:19 +0100
Created attachment 784 hull & mri
Robert Oostenveld - 2016-03-15 13:08:21 +0100
Created attachment 785 color-coded 3D mesh Ok, so I have just been trying to catch up with all the comments on this thread. What I care about is that we implement things in a way that allows them to be reused. Simon (now also CC) is working on electrode placement on basis of 3D photogrammetry and 3D scanning (and on spatial matching of individual head surfaces to template EEG volume conduction models). For that we also want to use ft_electrodeplacement, with as input a headshape mesh like the one attached (the picture is a screen shot of the color-coded 3D mesh). Also for that the clicked electrode locations are displaced relative to the surface, so here we also need the electrodes to be projected onto a surface. I propose to make the projection of electrodes on a surface part of ft_electroderealign (with a new method), where the surface could be either the skin compartment of a EEG volume conduction model, or a bounding mesh around a FS cortical sheet, or some other surface. Given previous discussions on different handling of elec.chantype for sEEG and ECoG and EEG channels, the ft_electroderealign cfg.method=projectsurface implementation would project a subset of channels (default cfg.channel={'ECoG' 'EEG'}) and excluding sEEG. Channel selection on the basis of elec.label is not done anywhere in FT code at the moment. Besides ft_electroderealign, also ft_prepare_layout should do it (allowing for a 2D topographic layout being constructed from an ECoG grid, but excluding sEEG). To include the sEEG channels in a multi plot, they would have to be placed somewhere at the side. Or make a combination of two layouts (one with the channels on the surface, another one with method=ordered) and merge them. @Jan-Mathijs, about a month ago we also discussed layouts and planar channels and ICAs and merging layouts, etc. That had to do with ft_databrowser. Do you know where that was?
Roemer van der Meij - 2016-03-15 17:30:57 +0100
(In reply to Arjen Stolk from comment #50) I'll go through the comments and catch up later. As a quick reply, Arjen, please discuss all post-localization plotting matters in bug3059.
Robert Oostenveld - 2016-03-16 10:17:08 +0100
(In reply to Robert Oostenveld from comment #55) to answer my own question about "layouts and planar channels and ICAs and merging layouts, etc." -> that is part of bug 3033.
Martin Krebber - 2016-03-30 18:59:35 +0200
Hi everyone, First of all, great work on the new ECoG functionality! I believe this will be very helpful to many people. I'm not sure if this is the right place for my comment, but I wanted to let you know that I uploaded the functional analysis part of the human ECoG tutorial as we talked about earlier this year. I broke it down into easily digestible bits of FieldTrip code and left out most of our custom code (except for the high gamma extraction). I left some of the sections empty that I wasn't sure about. I didn't really have much to say about re-referencing, although I understand that this is an important point. As for visualizing the data, I don't think we need special multiplotters for ERP/TFR data, since that can already be accomplished with existing FieldTrip functions (by making an ordered layout or an individual layout based on an image of electrode placements). I just wasn't aware of this before. I also included your new functions for surface rendering and electrode plotting, so users can now plot the electrode positions of our dataset the same way you do in the first section (if that's no too redundant). We'd be grateful for any suggestions and feedback.
Robert Oostenveld - 2016-03-30 20:01:13 +0200
Hi Martin, Very good to report here. I had noticed your wiki edits over the last days. I have added the dataset to http://www.fieldtriptoolbox.org/faq/what_types_of_datasets_and_their_respective_analyses_are_used_on_fieldtrip?&#ecog-visual given it the name ecog-visual (and the tag), added the shared page http://www.fieldtriptoolbox.org/tutorial/shared/ecog-visual which I subsequently included in http://www.fieldtriptoolbox.org/tutorial/human_ecog The idea of the shared sections (also used for other datasets) is that we keep the complete dataset description in once place, but can use the data in multiple tutorials and have them link to each other. You may want to edit the respective pages to complete them or further reorganize. @Arjen, should we call the other ecog-anatomy (for tags and a shared section)? @Arjen, should we present the section on "calculate and plot HGPs" both with corrected TFRs and with differentiated and broadband power analysis?
Arjen Stolk - 2016-03-30 20:12:23 +0200
Nice work indeed, Martin. @Arjen, should we call the other ecog-anatomy (for tags and a shared section)? > Sure @Arjen, should we present the section on "calculate and plot HGPs" both with corrected TFRs and with differentiated and broadband power analysis? > I'm working on a proof of concepts of the 'differentiated' analysis. I'll think of how to add it to this page as soon as it's finished, so let's leave it out for moment as it's far from routine.
Robert Oostenveld - 2016-03-30 21:04:07 +0200
(In reply to Arjen Stolk from comment #60) @Arjen, can you then provide content for http://www.fieldtriptoolbox.org/tutorial/shared/ecog-anatomy and http://www.fieldtriptoolbox.org/faq/what_types_of_datasets_and_their_respective_analyses_are_used_on_fieldtrip?&#ecog-anatomy @Martin, there is now the sentence "Support by the CRCNS Data Sharing Grant 01GQ1416 is gratefully acknowledged" at a not so logical place around here http://www.fieldtriptoolbox.org/tutorial/human_ecog#processing_of_functional_data should that not be be part of the shared section for ecog-visual
Martin Krebber - 2016-03-31 12:38:22 +0200
(In reply to Robert Oostenveld from comment #61) Great. Shared sections for the datasets make a lot of sense. I added some descriptions to that section and removed the unnecessary parts from the main tutorial. @Arjen: Do you mind if I ask what the 'differentiated' analysis you are working on is? Is it related to high-gamma analysis? It sounds interesting to me.
Gio Piantoni - 2016-06-14 13:36:29 +0200
I just wanted to add that I implemented the Dykstra 2012 algorithm to correct the brain-shift in ECoG recordings, see this pull request https://github.com/fieldtrip/fieldtrip/pull/179
Arjen Stolk - 2016-06-14 18:27:46 +0200
Excellent work, Gio. Thanks for this. I noticed make_outer_surface is a matlab script, which we could technically also supply in /external/freesurfer to prevent users from having to add freesurfer. But presumably mris_fill requires the freesurfer repository anyway?
Gio Piantoni - 2016-06-14 20:02:55 +0200
Yeah, if possible, make_outer_surface should be in external/freesurfer. There are two things that we need to figure out. I don't understand the Freesurfer license enough to see if we can just copy those scripts to a GPLv3 project, see https://surfer.nmr.mgh.harvard.edu/registration.html It seems to be the case, but I'm not sure. Some of the functions in external/freesurfer are taken from freesurfer v4.3 and v5.1. I used freesurfer v5.3. I don't expect big changes but I'm not comfortable modifying the external/freesurfer folder if that means introducing some regressions. Also, I think that FieldTrip uses a slightly modified version of the freesurfer matlab toolbox.
Robert Oostenveld - 2016-06-14 20:17:03 +0200
(In reply to Gio Piantoni from comment #65) we should not put our own stuff in external/freesurfer. That directory should only contain MATLAB code that we borrow from Freesurfer, under their license and according to their release/versioning schedule.
Arjen Stolk - 2016-08-20 05:55:03 +0200
(In reply to Robert Oostenveld from comment #61) @Robert, I have added content about the Ecog-anatomy dataset to http://www.fieldtriptoolbox.org/faq/what_types_of_datasets_and_their_respective_analyses_are_used_on_fieldtrip?&#ecog-anatomy What was the idea behind this page again? http://www.fieldtriptoolbox.org/tutorial/shared/ecog-anatomy Is it an intended location replacement for this one? http://www.fieldtriptoolbox.org/tutorial/human_ecog If so, I have no objections keeping things as they are. @Martin, It's a neural measure we have been developing. It's currently still in the process of testing and being documented.
Robert Oostenveld - 2016-08-22 11:40:08 +0200
(In reply to Arjen Stolk from comment #67) I have removed the empty shared page, it is not needed any more. The current format (part 1 anatomy with dataset 1, part 2 functional with dataset 2) is fine. If in the future we want to elaborate, we can always change it. There is still some (apparently relatively) small stuff that needs to be done (teach for fixme on the page), but overall I think that the tutorial is already perfectly useful for ECoG researchers. Hence I have removed the warning about it being in development and possibly wrong.
Arjen Stolk - 2016-08-23 06:57:06 +0200
(In reply to Robert Oostenveld from comment #68) Thanks, pretty content with the tutorial myself. There's a bunch of stuff that is currently implemented - sort of - that still needs to be documented, such as electrode normalization using a template and snapping of electrodes to a surface (courtesy of Gio). I will document these tools at a later stage, when we have a broader scope of the different methods out there (i.e. what works best) and thus what we really want to include in this already long tutorial. For now I will close this thread, since it seems we have achieved the goal to "extend and document electrocorticography (ecog) tools". But feel free to re-open it, or post related comments.