Back to the main page.

Bug 2516 - using ft_sourceinterpolate and ft_sourceplot for 2D, 3D, 4D and 5D data

Status ASSIGNED
Reported 2014-03-31 05:48:00 +0200
Modified 2015-09-29 13:14:20 +0200
Product: FieldTrip
Component: plotting
Version: unspecified
Hardware: PC
Operating System: Windows
Importance: P5 normal
Assigned to: Robert Oostenveld
URL:
Tags:
Depends on:
Blocks:
See also:

Tyler - 2014-03-31 05:48:17 +0200

I have been trying to plot my interpolated source data using the code: % interpolate sources mri = ft_read_mri('Subject01.mri'); mri = ft_volumereslice([], mri); cfg = []; cfg.downsample = 2; cfg.parameter = 'avg.pow'; sourceInt = ft_sourceinterpolate( cfg, source, mri); sourceInt = rmfield( sourceInt,'time'); % The avg.pow parameter % does not vary over time, therefore the time dimension is not needed. % Plot interpolated data cfg = []; %#ok cfg.method = 'ortho'; % spline cfg.funparameter = 'avg.pow'; ft_sourceplot( cfg, sourceInt); However the figure that comes up just had orange squares in the subplots. I dont know where I have gone wrong. </p>

Tyler - 2014-03-31 05:48:47 +0200

Created attachment 601 example of error


Jörn M. Horschig - 2014-03-31 17:06:11 +0200

(please regard this as a separate discussion than the one on the mailing list) I tried to reproduce your problem, and it seems to stem from the fact that you do not have source.pos field. While ft_sourceplot refuses to plot such a source-structure, ft_sourceinterpolate is perfectly fine with it. However, it does some nasty things. Here an example: If we have a regular source structure like this: source = dim: [20 25 22] pos: [11000x3 double] inside: [1x5798 double] outside: [1x5202 double] method: 'average' avg: [1x1 struct] cfg: [1x1 struct] Then interpolating on a standard MRI template_mri = dim: [91 109 91] anatomy: [91x109x91 double] hdr: [1x1 struct] transform: [4x4 double] unit: 'mm' is fine and results in (with cfg.downsample=2) source_diff_int = inside: [46x55x46 logical] avg: [1x1 struct] dim: [46 55 46] transform: [4x4 double] anatomy: [46x55x46 double] unit: 'mm' cfg: [1x1 struct] However, when I remove all fields outside the brain and trim all other fields accordingly (and remove .dim): source = pos: [5798x3 double] inside: [1x5798 double] outside: [] method: 'average' avg: [1x1 struct] % source.avg.pow is also 5768x1 now and then doing sourceinterpolate results in source_diff_int = avg: [1x1 struct] pos: [902629x3 double] dim: [91 109 91] inside: [1x902629 double] outside: [1x0 double] unit: 'mm' cfg: [1x1 struct] I don't quite see why this is happening, so we need to discuss this at the next FieldTrip meeting ;) Either, some magic is happening that I cannot understand, or the whole approach to start off (trimming the source-structure) is faulty and it should have resulted in an error


- 2014-04-02 13:53:06 +0200

discussed 20140402: -ft_sourceinterpolate identifies the sparse functional data as is2Dfun, due to the dim-field missing. Therefore, it gives the 'unexpected' output. -the 'unexpected' output is a bit funny in two ways: *it misses a transform and has a pos, although the interpolation was done onto a volume structure *the inside and outside are non informative, and should be removed. -the latter point pertains probably to more code, and not only with respect to the inside/outside field. E.g it also pertains to the sampleinfo field. It seems there is a mixture of unexpected things happening. What we need is: -a test script for ft_sourceinterpolate -it remains to be checked whether the source data in the input contained meaningful avg.pow to begin with. -also, why was the input defined on a sparse grid, where the dim was lost? Was it manually sparsified, rather than using ft_source2sparse?


Robert Oostenveld - 2014-09-24 22:03:04 +0200

Here is the commit to keep the anatomical description and the labeling of the parcellation in a "brainordinate" substructure mac011> svn commit ft_sourceparcellate.m Sending ft_sourceparcellate.m Transmitting file data . Committed revision 9836.


- 2015-03-02 14:40:38 +0100

ft_sourceinterpolate works on 2D and 3D functional data, and 2D and 3D functional data. The 2D data can be defined on an irregular point cloud such as a cortical mesh. One of the functions in ft_sourceinterpolate is to "smudge" low resolution 2D functional data to fit on a 2D high resolution anatomical data. Do we have any existing functional data like this? If we do not, could I get some pointers on creating a low resolution 2D functional data (from a high res one?)


Jan-Mathijs Schoffelen - 2015-03-02 15:23:35 +0100

if you take a random 2D source model from one of the MOUS subjects, e.g. V1020sourcemodel2Dsurfreg, the bnd.orig contains the original high resolution 2D mesh, from which the 8196 point low resolution mesh has been created


Robert Oostenveld - 2015-09-02 18:09:17 +0200

I discussed this with Nietzsche and looked at some of the open issues. We decided that it is desirable to have (in general) either this interp = ft_sourceinterpolate(cfgi, function anatomical) ft_sourceplot(cfgp, interp)) or this ft_sourceplot(cfgp, function anatomical) where the two should not differ in the figure that they create. Right now the 3nd input argument in ft_sourceplot is not documented, which allows for some flexibility (if needed) in changing its internal handling of that data. Once the implementation works like this, Nietzsche can start finalising the plotting tutorial. I have taken the test_ft_sourceinterpolate script that Nietsche committed earlier today, and will clean it and extend it to test all possible cases. This includes 4D and 5D data, and all possible permutations of the geometrical description (2x surf, 2x volume).


Robert Oostenveld - 2015-09-29 09:32:33 +0200

I made a large commit with all reorganised code. As far as I can tell, all existing test scripts still work as they used to do. mac011> svn commit ft_sourceinterpolate.m ft_sourceplot.m test/test_ft_sourceinterpolate.m Sending ft_sourceinterpolate.m Sending ft_sourceplot.m Sending test/test_ft_sourceinterpolate.m Transmitting file data ... Committed revision 10700.


Robert Oostenveld - 2015-09-29 10:45:25 +0200

I identified a section of code in ft_checkdata from line 565-757 that deals with converting volume and source data. This code should be removed and some functionality (if needed) merged into ft_datatype_source and ft_datatype_volume.


Robert Oostenveld - 2015-09-29 13:14:20 +0200

(In reply to Robert Oostenveld from comment #9) this (and some previous commits) removes the obsolete code from ft_checkdata. mac011> svn commit ft_sourcegrandaverage.m ft_sourceparcellate.m utilities/ft_checkdata.m Sending ft_sourcegrandaverage.m Sending ft_sourceparcellate.m Sending utilities/ft_checkdata.m Transmitting file data ... Committed revision 10718. Please note that source.pow and fourier are not treated specially any more.