Back to the main page.
Bug 2286 - implement a working version of eloreta
| Status | CLOSED FIXED |
| Reported | 2013-09-14 18:36:00 +0200 |
| Modified | 2014-01-15 14:46:14 +0100 |
| Product: | FieldTrip |
| Component: | inverse |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P3 normal |
| Assigned to: | Jan-Mathijs Schoffelen |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Jan-Mathijs Schoffelen - 2013-09-14 18:36:51 +0200
In Hamburg I discussed this with Guido and Marlene. Guido kindly provided his implementation, and Marlene kindly offered to build it in. As it stands now, the function outputs the spatial filter (as a matrix), and needs the leadfield in the input (as a matrix). What needs to be done: -build in support for cell-array leadfield in input. -output filter as cell-array. -change the api to the function so that it resembles the general inverse functions. although this may change in the future, for the time being it would be nice to also have a data matrix in the input (and thus a 'dip.mom' in the output. -upload the code (which is in an e-mail attachment in my inbox) to bugzilla.
Jan-Mathijs Schoffelen - 2013-09-14 20:19:35 +0200
Created attachment 517 Guido's code
Jan-Mathijs Schoffelen - 2013-09-15 09:51:14 +0200
Marlene commented: I created a subline in the ft_sourceanalysis function asking whether to use eloreta in the section on freqanalysis data. Then I used the beamformer_dics function as a template and adjusted the lines and commands and essentially, introduced a line to make the fieldtrip leadfield structure fit into Guidos code. Afterwards it appeared to Guido, that since the eloreta filter construction is independent on the data, it would be a no use to wait for the filter to be constructed everytime the function ft_sourceanalysis is applied to the different conditions of the same subject. So alternatively, one could ask during the leadfield construction whether eloreta would be used at some point and then construct the filter conditionally together with the leadfield. But this then gets already complicated for the beginner to answer questions that apply to one step further....Alternatively one could save the filter the first time it is constructed during ft_sourceanalysis in the leadfield structure and then reuse it the next time for the next subject and comment in the function help that user should opt for "keepfilter" since it would accelerate computation. This is an issue where you have to decide what suits the comfort of using fieldtrip better.,,
Jan-Mathijs Schoffelen - 2013-09-15 09:54:23 +0200
Great! indeed it seems most of the work has already been done. I suggest to upload the latest version of the eloreta code to this bug. I will review it and then commit it to FieldTrip. How does that sound for a plan? Indeed I think it would be most logical to use the cfg.keepfilter option in ft_sourceanalysis. Note that if one uses subject specific headmodels, one should recompute the filter for each of the subjects separately (but not for the conditions within a subject). Also, is there a reason that the algorithm should be applied only to frequency domain data?
- 2013-09-16 07:22:53 +0200
In Guidos impementation the filter is solely constructed on the leadfield and in a seperate function the dipoles moments are extracted. Here Input is the cross-spectra, but there is no reason not to use covariance istead. So it could also be applied to timedomain data. I used in my first draft the latter function after the call to Guidos mkfilter function to get the dipoles moment. I will upload my code as soon as I have introduced the covariance option and the keepfilter option.
Jan-Mathijs Schoffelen - 2013-09-16 11:51:03 +0200
OK, let me know if I can be of assistance.
- 2013-09-22 22:47:58 +0200
Created attachment 521 Filter to Power using CSD/Cov adopted from code from guido nolte
- 2013-09-22 22:49:24 +0200
Created attachment 522 adopted from beamformer_dics and adjusted to make use of guidos eloreta implementation adopted from beamformer_dics and adjusted to make use of guidos eloreta implementation
- 2013-09-22 22:50:58 +0200
Created attachment 523 original version from jan 2013 complemented with eloreta option
- 2013-09-22 22:53:24 +0200
Hi Jan-Mathijs, a bit of progress has been done on the eloreta build-in tot he ft_sourceanalysis function. Attached the ft_sourceanalysis function with eloreta included for now only from freq_analysis data but I am also working on the option to work from timelocked data. Eloreta is an adaptation from beamforming_dics where I adopted everything that can also be applied to the eloreta routine, like making the leadfield, keeping leadfield and keeping filter options, calculating the filter only if not supplied. I also used the subspace option since to my perception it only changes the leadfield and thus indirectly the filter. But what is the sense of the subspace projection? I dismissed the project noise option and the fixedori option though since it is too much directly intertwined with the filter construction. I kept the ft_progress option although it does not really makes sense since it would then inform about the progress of a not very time consuming step namely the leadfield construction and not the actual filter computation. This is done on the whole of the dipoles at once and thus can’t inform about the progress at every dipole. Do you know what I mean? I also dismissed the realfilter function since I don’t really understand the use of it. But if you can convince me of the use I could reinclude it easily since it only affects the Cf computation. What is the difference between the projectmom and the fixedori option? Why is there only for lcmv a projectmom option? There is a ‘keepmom’ option in ft_sourceanalysis, but during beamformer_dics there is the moment information not kept in the dipout. Where could the dip.mom information come from? I introduced the option to keep the moment in eloreta. Related to that, line 19 in eloreta_getdipdir, Is that correctly implemented? Regarding lambda: I use now the default lambda from guidos code (0.05). Would it make sense to estimate it in case the user doesn’t specifiy (l 178 to 182 in beamformer_dics).
Jan-Mathijs Schoffelen - 2013-10-04 21:04:11 +0200
(In reply to comment #9) Hi Marlene, >I also used the subspace option since to my perception it only >changes the leadfield and thus indirectly the filter. But what is the sense of >the subspace projection? I started cleaning up the code a bit. Hope to upload anything soon for your approval ;-). The subspace projection should go I think, this is more specific to beamforming, and I don't know what the conequence is for eloreta in this case. I think we should start with a 'native' implementation, i.e. an implementation that works as described in the literature. >I dismissed the project noise option and the fixedori option though since it is >too much directly intertwined with the filter construction. OK. >I kept the ft_progress option although it does not really makes sense since it >would then inform about the progress of a not very time consuming step namely >the leadfield construction and not the actual filter computation. This is done >on the whole of the dipoles at once and thus can’t inform about the progress at >every dipole. Do you know what I mean? Yes, I do. I removed the progress thingy. >I also dismissed the realfilter function since I don’t really understand the >use of it. But if you can convince me of the use I could reinclude it easily >since it only affects the Cf computation. Well, this is beamformer specific, because the spatial filter is a function of the data crosspectral density matrix. If the complex-valued csd matrix enters the beamformer spatial filter formula, the filter will have complex values. This is a bit strange in terms of physical interpretation, because this means that the channels are shifted in phase relative to one another. This violates physical reality. >What is the difference between the projectmom and the fixedori option? Why is >there only for lcmv a projectmom option? >There is a ‘keepmom’ option in ft_sourceanalysis, but during beamformer_dics >there is the moment information not kept in the dipout. Where could the >dip.mom information come from? I introduced the option to keep the moment in >eloreta. Related to that, line 19 in eloreta_getdipdir, Is that correctly >implemented? No, I don't think it's correct, and it would be anyhow my suggestion to move the functionality in eloreta_getdipdir into eloreta itself. The use of the field mom is a bit messy in fieldtrip. In the input 'dip' structure, this is more or less expected to be a 3xNdip matrix, that specifies the orientation of the dipole at each of the locations. (Question: should we apply this to the leadfields prior to computing the eloreta filter, or should we apply this only once the filter has been computed? I think this makes a difference, and I don't know which one is correct. At present both is done in the code, and this will probably not work). The projectmom in lcmv is probably a historic remnant in the code. This functionality is supposed to be taken care of by ft_sourcedescriptives, which essentially applies the same algorithm as your svd based thingy in eloreta_getdipdir. The keepmom option is related to the construction of a different 'mom' which is essentially dip.filter{i}*avg (in the case of time domain data, avg will contain the event-related potential, in the case of frequency domain data, this will be a fourier matrix (channels x observations), if the input freq-structure into ft_sourceanalysis contained a fourierspctrm). To make a long story short, the dip.mom generated in this way is per location a 3xNtimepoints (or Nobservations) matrix. >Regarding lambda: I use now the default lambda from guidos code (0.05). Would >it make sense to estimate it in case the user doesn’t specifiy (l 178 to 182 in >beamformer_dics). Perhaps for the time being it would be best to use your standards, and don't use the convention in the beamformer functions. I guess that the regularization in eloreta means something else than the regularization in beamforming anyway.
Jan-Mathijs Schoffelen - 2013-10-08 13:12:03 +0200
Created attachment 527 JM's updated version of Marlene's eloreta function I updated the flow of the code quite a bit. the functionality is essentially the same as Marlene's original implementation.
Jan-Mathijs Schoffelen - 2013-10-08 13:13:47 +0200
Hi marlene, I put an updated version of the eloreta code in an attachment. essentially, it does the same as your version, only I cleaned up the code here and there. Also I removed the dependency on the getdipdir function. This is now done in ft_eloreta itself. Please have a look at the code. If you are happy with it, I'll push this to the release version of FieldTrip. Would you like me to address the support for ERP data?
- 2013-10-31 21:51:18 +0100
Created attachment 549 ft_eloreta_JM_MB
- 2013-10-31 22:20:53 +0100
(In reply to comment #12) Hi Jan-Mathijs, not very promptly, but here my reply and commitment to a soon release of the fieldtrip extension by eloreta. Sorry for the delay. I see in your last version of ft_eloreta that you have dismissed the subspace and realfilter option. Regarding the field mom: I understand what you meant in comment 10. The field dipori from Guidos code is obtained from the svd of the cross-spectrum in source space and in lcmv (and I cant find the original construction of the field .mom in dics) it is obtained by multiplying the data with the filter (ine 288 in beamformer_lcmv). Maybe it is the same in the end, I didn't check it out. You have introduced the moment calculation in line 175 if time-resolved data is present which is mostly only the case in lcmv. A problem I found is that the integration of previously calculated moment doesn’t work when I address it, since the output .mom is a cell array of number of dipoles cells each with [ 3 x time points] and thus the line 121 shoots an error. I checked how it works in dics or lcmv and found that in those cases the corresponding line where the moment should be integrated with the leadfield is never carried out (i.e. line 268 in dics) since the conditional line above (266) would never be met because size(mom,1) is always one and not three. Instead I introduced the output dip.ori into the current ft_eloreta (line 187 and 206 to 209). How do you like this? Should we keep it? I checked the functionality of ft_eloreta with freq and tmlck data and both works. Also uploaded the ft_sourceanalysis function where I wrote sth to eloreta. What do you think about where we stand? From my perspective we could get others to try it out after you have adressed the above points. Many greetings, Marlene
- 2013-10-31 22:21:58 +0100
Created attachment 550 ft_eloreta_JM_MB_MB ft_eloreta JM_MB_MB
- 2013-10-31 22:23:05 +0100
Created attachment 551 changed as in comment 14