Back to the main page.
Bug 2032 - ft_sourceplot: build in check for matching coordsys when using method = 'surface'
| Status | CLOSED FIXED |
| Reported | 2013-03-06 14:46:00 +0100 |
| Modified | 2017-03-14 12:49:28 +0100 |
| Product: | FieldTrip |
| Component: | plotting |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P3 normal |
| Assigned to: | Jan-Mathijs Schoffelen |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | 3142 |
| See also: |
Jan-Mathijs Schoffelen - 2013-03-06 14:46:16 +0100
Jan-Mathijs Schoffelen - 2013-03-06 14:47:41 +0100
Right now ft_sourceplot assumes the source level data to be in the same coordinate system as the surface. Typically, the surface from the template directory is used, which is in SPM-based coordinates. Combining it with CTF based source level data leads to a 90 degree rotation
Jan-Mathijs Schoffelen - 2014-06-23 14:08:46 +0200
bash-4.1$ svn commit -m "enhancement - moved functionality of on-the-fly interpolation to a cortical sheet to a more appropriate location" ft_sourceplot.m ft_sourceinterpolate.m private/interp_gridded.m private/interp_ungridded.m Sending ft_sourceinterpolate.m Sending ft_sourceplot.m Sending private/interp_gridded.m Sending private/interp_ungridded.m Transmitting file data .... Committed revision 9673. Although not directly related to the named bug, I just moved the functionality of on-the-fly interpolation to a cortical surface to ft_sourceinterpolate. This involved moving the projection code contributed by Joachim to interp_gridded as a new method. NOTE: this projection method seems sub-optimal to me, since it takes [0,0,0] as the centre of the projection.
Robert Oostenveld - 2017-02-07 11:37:49 +0100
I just encountered a similar (but not identical) issue related to the functional data and the atlas. I added this in the section that prepares the atlas % ensure that the coordinate systems match assert(isequal(functional.coordsys, atlas.coordsys), 'coordinate systems do not match'); % ensure that the units are consistent, the atlas will be converted if required atlas = ft_convert_units(atlas, functional.unit); mac011> git commit -am "ENH - ensure that the atlas coordsys and units are consistent with the functional data" [master 4c1c689] ENH - ensure that the atlas coordsys and units are consistent with the functional data 1 file changed, 4 insertions(+) The atlas I tested with was AAL from template. I have not checked the other template atlases.
Robert Oostenveld - 2017-02-07 12:08:20 +0100
lets do this slightly more formal. I cerated a branch bug2032-coordsys and made these changes: [bug2032-coordsys fd9c540] ENH - improved reading of atlas from mat files, added coordsys to brainweb templates, created test script for http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=2032 which is currently failing. The surfaces in fieldtrip/template/anatomy do not specify the coordsys. 5 files changed, 169 insertions(+), 103 deletions(-) rewrite template/atlas/brainweb/brainweb_discrete.mat (78%) create mode 100644 test/failed_bug2032.m
Robert Oostenveld - 2017-02-07 12:10:05 +0100
(In reply to Robert Oostenveld from comment #4) I created this PR https://github.com/fieldtrip/fieldtrip/pull/320
Robert Oostenveld - 2017-02-07 15:28:00 +0100
(In reply to Robert Oostenveld from comment #5) I have made further updates. The PR can be merged after successful testing.
Robert Oostenveld - 2017-02-08 10:41:37 +0100
(In reply to Robert Oostenveld from comment #6) there are some bugs which I am now squashing. One is that 'mni' is not equal to 'spm'. mac011> git commit -a [bug2032-coordsys 2f5fea6] FIX - the coordsys mni and spm should be recognized as identical. See http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=2032 2 files changed, 42 insertions(+), 1 deletion(-) create mode 100644 private/fixcoordsys.m