Back to the main page.

Bug 1902 - ft_prepare_sourcemodel should use consistent unit handling

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
Depends on: 1956
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.

Robert Oostenveld - 2013-12-02 13:18:56 +0100

I think (suspect) that the problem has been resolved by now. I was not able to find the spm_smooth call that originally was wreaking havoc. I did make a test script (but did not run it yet). Let's see how it behaves on the dashboard. mac001> svn commit test_bug1902.m Adding test_bug1902.m Transmitting file data . Committed revision 8938.