Back to the main page.
Bug 2623 - Create function to 'reverse parcellate' data, to allow for visualisation at source-level
| Status | CLOSED FIXED |
| Reported | 2014-06-25 15:01:00 +0200 |
| Modified | 2018-03-10 21:36:01 +0100 |
| Product: | FieldTrip |
| Component: | plotting |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P5 normal |
| Assigned to: | |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
- 2014-06-25 15:01:50 +0200
Currently parcellated datasets are treated as channel level data. So statistics and visualisation are done with sensor-level functions. The plan is to 'unwrap' the parcels to allow visualisation of the data at the source level using e.g., ft_sourceplot. Assumes that user has volumetric data which has been parcellated using a template (whereby each voxel is assigned to a parcel). Now, we want each voxel (source) belonging to a parcel to be given the same values as that parcel such that all voxels at the source level are filled. This data can then be subsequently used at the source-level. Things to consider: 1. make the function flexible to the type of parcellation this would probably require the user to specify as an inarg the type of parcellation used, together with labels. 2. is it worth pre-specifying a certain parcellations? There are many ways of parcellating... I have some code that does the reverse parcellation but am not sure how to develop it into being more general i.e. suitable for different datasets.
Jan-Mathijs Schoffelen - 2014-09-24 13:48:39 +0200
Robert just has committed something to ft_checkdata which is essentially doing this (for ft_sourceplot).
Jan-Mathijs Schoffelen - 2014-09-24 13:49:23 +0200
da code that undoes the parcellation is in fieldtrip/utilities/private/unparcellate.m
Jan-Mathijs Schoffelen - 2014-09-24 13:56:18 +0200
thing to be done: make a test function + dig up a MOUS source-TFR (parcellated) and ask help from Robert to see whether it also works for this type of data. If it doesn't: fix it.
Robert Oostenveld - 2014-09-24 17:29:08 +0200
the following demonstrates how it works parcellation = ft_read_atlas(dccnpath('/home/common/matlab/fieldtrip/template/atlas/aal/ROI_MNI_V4.nii')); source = ft_checkdata(parcellation, 'datatype', 'source'); source = removefields(source, {'tissue', 'tissuelabel'}); source.pow = randn(prod(parcellation.dim), 1); source.pow(parcellation.tissue==0) = nan; source.dimord = 'pos'; cfg = []; cfg.funparameter = 'pow'; ft_sourceplot(cfg, source); cfg = []; cfg.parameter = 'pow'; sourcep = ft_sourceparcellate(cfg, source, parcellation); cfg = []; cfg.funparameter = 'pow'; ft_sourceplot(cfg, sourcep);
- 2014-12-15 15:40:41 +0100
As discussed in today's FT meeting: 1. Use ft_sourceparcellate to do the parcellation. Check that is similar (but probably more generic) to what I've written myself. Here the brain ordinates are specified which contains information on the geometry e.g. 'pos' field. 2. ft_sourceplot calls ft_checkdata which requires 'volume' or 'source' data. Have ft_checkdata deal with the freq input as 'source' data.
Robert Oostenveld - 2014-12-15 16:06:50 +0100
(In reply to n.lam from comment #5) mac011> svn commit utilities/ft_checkdata.m Sending utilities/ft_checkdata.m Transmitting file data . Committed revision 10049. Have a look at https://code.google.com/p/fieldtrip/source/diff?spec=svn10049&r=10049&format=side&path=/trunk/utilities/ft_checkdata.m and then try the following with the latest FT version ------ parcellation = []; parcellation.pos = randn(10,3); parcellation.tri = [1 2 3]; % one triangle parcellation.tissue = [1 1 1 1 1 2 2 2 3 3]; parcellation.tissuelabel = {'1', '2', '3'}; source = []; source.pos = parcellation.pos; source.pow = randn(10,20); source.time = 1:20; source.dimord = 'pos_time'; cfg = []; cfg.parameter = 'pow'; sourcep1 = ft_sourceparcellate(cfg, source, parcellation); sourcep2 = ft_checkdata(sourcep1, 'datatype', 'timelock'); sourcep3 = ft_checkdata(sourcep2, 'datatype', 'source'); ------
- 2015-02-11 16:19:06 +0100
Using a dataset from the MOUS project to test whether or not we can visualise parcellated data. The reason for this is because we have a parcellated atlas for this dataset (but as far as I know, not in FT'S ftp repository). The MOUS dataset was adapted to have the generic fields and format as if the dataset had been computed from ft_sourceanalysis. Dataset was parcellated - OK Dataset was unparcellated - OK; required a change in line ft_checkdata on line 1729 to also deal with "chan_freq_time" data. Dataset visualisation - still working on it.
- 2015-02-11 16:38:03 +0100
unparcellated data using ft_checkdata contains all the correct fields. However the field 'pos' does not contain the correct values. unparcellated.pos = 'pos_freq_time'; % this is incorrect unparcellated.pos = [11000 x 3]; % should have source positions will make this happen.
- 2015-02-11 16:43:04 +0100
ignore comment 8, I made a mistake
- 2015-02-11 17:18:32 +0100
unparcellated data using ft_checkdata leads to missing 'time' and 'freq' field which are needed in order to visualise the data (using ft_sourceplot)
- 2015-02-24 16:02:10 +0100
modifications were made to parcellated2source, a subfunction in ft_checdata 1. 'chan_freq_time' was added as one of the possible dimords for the input data 2. time and/or freq field is copied over when applicable
- 2015-02-24 16:04:02 +0100
closing bug
Robert Oostenveld - 2015-02-24 17:08:18 +0100
(In reply to n.lam from comment #11) The changes were the ones ones (from "svn log"). Next time just copy and paste the svn output here, so that we can keep track of the revision in which the changes were made. ------------------------------------------------------------------------ r10257 | nielam | 2015-02-24 16:00:31 +0100 (Tue, 24 Feb 2015) | 1 line added chan_freq_time as possible dimord for data; copy over time and/or freq fields ------------------------------------------------------------------------ r10256 | nielam | 2015-02-24 15:35:06 +0100 (Tue, 24 Feb 2015) | 1 line tests plotting of parcellated data