Back to the main page.
Bug 2083 - ft_prepare_atlas: deprecate this function
| Status | CLOSED FIXED |
| Reported | 2013-03-29 15:54:00 +0100 |
| Modified | 2013-10-26 18:00:09 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P3 normal |
| Assigned to: | Jan-Mathijs Schoffelen |
| URL: | |
| Tags: | |
| Depends on: | 1725 |
| Blocks: | 1114 |
| See also: |
Jan-Mathijs Schoffelen - 2013-03-29 15:54:14 +0100
This function's functionality should eventually be covered by ft_read_atlas, which supports a much larger amount of different atlases. Ft_prepare_atlas currently outputs the Afni bricks in old format, not consistent with ft_datatype_segmentation. It contains brick0 and brick1, and the descriptive labels are in the field descr. To move forward I suggest to: -replace the call to ft_prepare_atlas in ft_sourceplot and ft_volumelookup into a call to ft_read_atlas and update these functions accordingly to deal with the well-defined segmentation format -adjust atlas_lookup to also deal with the new segmentation format.
Jan-Mathijs Schoffelen - 2013-03-29 16:37:23 +0100
as an addition: probably atlas_init and atlas_mask can be removed, they don't seem to be called from anywhere: cd ~/matlab/fieldtrip grep atlas_init *.m grep atlas_mask *.m return nothing
Jan-Mathijs Schoffelen - 2013-04-02 21:57:09 +0200
created a git-branch atlas on my local repo to work with.
Johanna - 2013-04-26 10:54:39 +0200
see bug 1725
Jan-Mathijs Schoffelen - 2013-05-01 13:46:33 +0200
discussed in FT-meeting (also in relation to the ft_sourceparcellate function).
Jan-Mathijs Schoffelen - 2013-06-04 15:35:45 +0200
Hi Jörn, You might want to keep track of what's happening in this bug.
Jörn M. Horschig - 2013-06-04 15:39:21 +0200
ah, thanks, good to know, I missed the meeting on May 1 ;) anyway, for now the function works again, so that I can use my beloved atlas again in ft_sourceplot and wonder about my strange beamformed data ^^
Jan-Mathijs Schoffelen - 2013-06-04 15:45:49 +0200
ow, I thought that ft_sourceplot already used ft_read_atlas. I guess it's time to resolve some conflicts (for me I mean)...
Jan-Mathijs Schoffelen - 2013-09-24 16:52:29 +0200
removed atlas_init and atlas_mask in revision 8520
Jan-Mathijs Schoffelen - 2013-09-24 17:00:06 +0200
Deleted ft_prepare_atlas, and svn commit -m "enhancement - added compatibility wrapper in compat directory for now" ft_prepare_atlas.m
Jörn M. Horschig - 2013-09-25 10:46:29 +0200
(In reply to comment #9) you crashed the test script of bug 1114 because of the existence of a compat version. Nothing to worry about, just for the notebook
Jörn M. Horschig - 2013-09-25 10:50:45 +0200
and test_bug2193 fails, because ft_prepare_atlas is called with cfg.filename but ft_read_atlas without a cfg
Jan-Mathijs Schoffelen - 2013-09-25 11:36:26 +0200
Issue addressed with r8537. test_bug1114 still fails, but this is not anymore due to ft_prepare_atlas.
Jan-Mathijs Schoffelen - 2013-09-25 12:01:20 +0200
My bad. It still blocks 1114 (I tested this test_bug1114 with my own FT-version, and not the one on /home/common). ft_volumelookup still uses ft_prepare_atlas. Hope to work on this today.