Back to the main page.
Bug 937 - ft_prepare_mesh inconsistencies and restructure suggestion
| Status | CLOSED FIXED |
| Reported | 2011-09-06 16:09:00 +0200 |
| Modified | 2013-01-16 15:03:29 +0100 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P1 normal |
| Assigned to: | Johanna |
| URL: | |
| Tags: | |
| Depends on: | 1756 |
| Blocks: | |
| See also: |
Johanna - 2011-09-06 16:09:18 +0200
At the moment, ft_prepare_mesh works by first having the user do something like this (modified from Cristiano's recent email to the List): % read in the mri mri = ft_read_mri('Subject01.mri'); % segment it cfg = []; cfg.output = {'scalp', 'skull', 'brain'}; seg = ft_volumesegment(cfg, mri); % assign a label scalp = (seg.scalp) & ~(seg.skull | seg.brain); skull = 2*(seg.skull); brain = 3*(seg.brain); seg.seg = scalp + skull + brain; % this line is different than in the email Then calling ft_prepare_mesh such as: cfg = []; cfg.method = 'segmentation'; cfg.tissue = [1 2 3]; % scalp = 1; skull = 2; brain = 3; cfg.numvertices = [2000 1000 800]; cfg.sourceunits = 'mm'; cfg.mriunits = 'mm'; bnd = ft_prepare_mesh(cfg, seg); 1) However, this does not work at the moment because, as suggested by a user on the list, line 25 of prepare_mesh_segmentation must be commented out so that cfg.tissue is not set to 1. I have fixed this for now by removing that line (with Cristiano's recommendation), but perhaps consider: 2) I think it would be better if the part under '%assign a label' was incorporated into ft_prepare_mesh, and instead the user specifies which segments to use, for example cfg.segment={'scalp' 'skull' 'brain'} (or a subset) rather than cfg.tissue = [1 2 3]. 2a) therefore seg.seg should not be a required subfield 3) cfg.method (in documentation) is not actually called by the code, and should be replaced by documenting cfg.interactive ('yes' calls 'manual', otherwise 'segmentation' or other options are used). (I've fixed this). 4) contrary to documentation, an un-segmented MRI does not work as input. The '.seg' field is required regardless. I have updated the 'example' at the end of documetation to reflect the current implementation. However, a more thorough check of all the cfg options with the documentation is still needed.
Robert Oostenveld - 2011-11-11 11:19:44 +0100
I closed all bugs that were recently resolved.
Robert Oostenveld - 2012-09-28 11:54:58 +0200
the redesign of ft_prepare_mesh by Robert and Johanna has to be validated. The test_bug937 script might be useful, but should be revised.
Johanna - 2012-09-28 15:51:54 +0200
The original complaints of this bug are either fixed or obsolete. I now fix test_bug937 for it to work with current ft_prepare_mesh. It is fixed now (svn 6598) except: Bug in ft_voltype.m, introduced svn r5288. Current lines 105-106 fail: elseif isfield(vol, 'bnd') && strcmp(type, {'dipoli', 'asa', 'bemcp', 'openmeeg'}) type = any(strcmp(type, {'dipoli', 'asa', 'bemcp', 'openmeeg'})); Since 'type' does not exist. I realise the logic here is that it should only be give type='bem' if one of specific bem-types, but then A) how to detect that it is one of 4 BEM-types and not already taken care of by vol.type earlier in code? or B) what to do with input that indeed has vol.bnd but is not a BEM?
Johanna - 2012-10-02 10:59:54 +0200
comment 3 is now bug 1756. I will wait on that bug to be fixed, and then uncomment the lines in test_bug937 that depend on that part being fixed.
Johanna - 2012-10-04 09:54:32 +0200
bug 1756 resolved and updated ft_voltype in svn commit 6671. Also updated this test function to better relfect what is desired (and removed some examples that made less sense).
Johanna - 2012-10-10 13:25:35 +0200
test_bug937 fails again; dependent on bug 1756