Back to the main page.
Bug 1902 - ft_prepare_sourcemodel should use consistent unit handling
| Status | CLOSED FIXED |
| Reported | 2012-12-18 11:02:00 +0100 |
| Modified | 2018-03-10 21:57:51 +0100 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P3 normal |
| Assigned to: | Lilla Magyari |
| URL: | |
| Tags: | |
| Depends on: | 1956 |
| Blocks: | |
| See also: |
Robert Oostenveld - 2012-12-18 11:02:48 +0100
It has cfg.sourceunits='auto', whereas private/prepare_headmodel has sourceunits=[] to indicate auto. It also has a section like % convert the source/functional data into the same units as the anatomical MRI scale = 1; switch cfg.sourceunits case 'mm' scale = scale / 1000; case 'cm' scale = scale / 100; case 'dm' scale = scale / 10; case 'm' scale = scale / 1; otherwise error('unknown physical dimension in cfg.sourceunits'); end which should be done with private/scalingfactor, or with ft_convert_units Better would be that the consistency of all input objects with units (grid, grad, vol, mri?) is checked early on in the code. If they are not consistent, or if they are different from cfg.sourceunits, action needs to be taken.
Robert Oostenveld - 2013-01-24 12:29:04 +0100
I changed a bunch of bugs that were assigned to fieldtrip-bugs from ASSIGNED into NEW, since nobody is now explicitly working on them.
Lilla Magyari - 2013-01-24 15:22:19 +0100
I changed it back to assigned, because this is the one I was working on yesterday, but had no time to commit.
Johanna - 2013-01-24 16:13:58 +0100
But then you must actually assign it to yourself! I will do that now for you. Otherwise people don't know who is working on it.
Lilla Magyari - 2013-01-24 19:43:12 +0100
Thanks Johanna. I forgot to add my name... While I am working on this bug and testing it, I am wondering why is the output different when I run ft_prepare_sourcemodel with the same mri and cfg input. mri = ft_read_mri('/home/common/matlab/fieldtrip/data/test/latest/mri/nifti/single_subj_T1.nii'); cfg=[]; tpm = ft_volumesegmet(cfg,mri); % gray, white, csf tissue prob. map cfg=[]; cfg.mri=tpm; grid01 = ft_prepare_sourcemodel(cfg,tpm); cfg=[]; cfg.mri=tpm; grid02 = ft_prepare_sourcemodel(cfg,tpm); grid01 = rmfield(grid01,'cfg'); grid02 = rmfield(grid02, 'cfg'); isequal(grid01,grid02) answer is 0.
Johanna - 2013-01-25 10:38:15 +0100
Most bizarre! I tried it again, to create a grid03, and the main difference is in the grid*.dim >> grid01.dim 16 19 16 >> grid02.dim 16 19 17 >> grid03.dim 16 20 17
Johanna - 2013-01-25 10:44:19 +0100
It comes from how many voxels are marked as cortex: grid01 264699 from 902629 voxels in the segmentation are marked as cortex (29%) grid02 292593 from 902629 voxels in the segmentation are marked as cortex (32%) grid03 313373 from 902629 voxels in the segmentation are marked as cortex (35%)
Johanna - 2013-01-25 10:52:52 +0100
Every time spm_smooth is called, it seems to re-smooth it further, so that the max(mri.gray(:)) keeps getting smaller and smaller. It's as if the cfg.mri that is used currently is taking the smoothed mri from the previous call.
Johanna - 2013-01-25 11:05:11 +0100
How is it possible that the values of 'tpm' are changed after the call to ft_prepare_sourcemodel? cfg=[]; tpm = ft_volumesegment(cfg,mri); % gray, white, csf tissue prob. map tpm.gray(55,60,21) ans = 0.9882 cfg=[]; cfg.mri=tpm; grid01 = ft_prepare_sourcemodel(cfg,tpm); tpm.gray(55,60,21) ans = 0.5169
Lilla Magyari - 2013-01-25 11:40:19 +0100
(In reply to comment #8) thanks. yes, I remember now that there are some spm functions which change their own input. for example, spm_smooth. If you look at private/volumesmooth, this function doesn't do anything else then using spm_smooth in a way that the output won't be changed. And in line 444 of ft_prepare_sourcemodel spm_smooth is called. So, perhaps we should change spm_smooth to volumesmooth.
Robert Oostenveld - 2013-12-02 13:14:03 +0100
(In reply to comment #9) I changed it in ft_volumedownsample.m, although there it was making an explicit local copy (to prevent modification). It is better to be consistent, i.e. not use spm_smooth in any FT function. mac001> svn commit ft_volumedownsample.m Sending ft_volumedownsample.m Transmitting file data . Committed revision 8937.