Back to the main page.

Bug 2769 - make ft_sourceplot and ft_sourceinterpolate behave consistently

Reported 2014-12-01 11:23:00 +0100
Modified 2015-01-26 11:09:38 +0100
Product: FieldTrip
Component: core
Version: unspecified
Hardware: PC
Operating System: Mac OS
Importance: P5 normal
Assigned to: Robert Oostenveld
Depends on:
See also:

Robert Oostenveld - 2014-12-01 11:23:50 +0100

When plotting something, I realised that both source plot and sourceinterpolate are handling their internal if variant A elseif B elseif C end structures rather inconsistent. Quite often the handling of data inside each variant is generic and can be moved to prior handling the variants. Since the data structures are now much more consistent, these functions can be implemented much cleaner. I will do a cleanup. Also, I suggest to implement ft_sourceplot(cfg, functional, anatomical) which interpolates the functional data on the fly (using ft_sourceinterpolate). This allows for removing (or merging) the on-the-fly interpolation that is presently done for surface visualisation. any objections?

Jan-Mathijs Schoffelen - 2014-12-01 11:34:51 +0100

No objection. One additional point to consider for the 3D-volumetric visualization is to *not do* an interpolation (up sampling) on the fly. In principle, it should be possible to overlay the data as long as the coordinate systems are consistent (which they need to be to begin with in order to do the correct interpolation). The reason I mention it is because I would foresee in the future recurring questions about the lack of support for interpolation of volumetric source data with a (time)/(freq) axis. This lack of support is currently inspired by potential memory constraints, to protect the user of itself. But perhaps the direct benefit of this change is small compared to the amount of work it requires.

Robert Oostenveld - 2014-12-02 10:53:42 +0100

I have cleaned up the code of ft_sourceinterpolate and made it optional in ft_sourceplot to interpolate on the fly. That interpolation is now implemented as a single call to ft_sourceintrepolate, i.e. interp = ft_sourceinperpolate(cfg, functional, anatomical) ft_sourceplot(cfg, interp) is now functionally equivalent to ft_sourceplot(cfg, functional, anatomical) Note that I have not documented it yet in ft_sourceplot. The next step is to go through ft_sourceplot and see what kind of interpolations are now done in there. I am aware of the interpolation of volume data onto the cortical sheet if method=surface. That is another form of on-the-fly interpolation, which should be made consistent. In the end, I would like to see all interpolations in ft_sourceplot to be done just before the data is sent to the figure. That should allow for visualisation of time/frequency data without blowing up memory. But if people want to interpolate it fully and handle themselves with the data, that should also be possible.

Robert Oostenveld - 2014-12-02 10:54:15 +0100

(In reply to Robert Oostenveld from comment #2) oh, for reference: the SVN commits related to this were those around 9999-10005.

Robert Oostenveld - 2014-12-02 15:45:46 +0100

my change with fixpos (pnt->pos) caused a lot of test scripts to fail. I just reverted it in the generic functions, it is still in place in ft_sourceinterpolate mac011> svn commit Sending utilities/ft_checkdata.m Sending utilities/ft_datatype.m Transmitting file data .. Committed revision 10010.

Robert Oostenveld - 2015-01-26 11:09:38 +0100

roboos@mentat001> svn commit Sending utilities/private/determine_segmentationstyle.m Transmitting file data . Committed revision 10121. The test script was failing because in the simulated data the source.pow ranged from -5 to +5. This caused it to be identified as segmentation field, which failed further down due to the negative numbers. I fixed it, negative numbers now result in the field not being seen as segmentation. Note that this specific commit does not contribute to the larger issue at hand.