[FieldTrip] ft_sourceanalysis single trial reconstruction
CHATEAUX Manon
manon.CHATEAUX at univ-amu.fr
Thu Nov 4 13:43:59 CET 2021
Dear Jan Mathijs,
Thank you so much for your detailed and very helpful answer!
At first, I had used DICS by following this tutorial: https://www.fieldtriptoolbox.org/tutorial/coherence/. However, I had not seen anything striking or that would have seemed useful to answer the research question.
As I understand it, DICS is used in this tutorial to reconstruct in source space, coherence that was previously computed in sensor space.
I thought it would be interesting to first reconstruct MEG data in source space and then compute coherence in source space believing that it would allow to extract information that couldn’t be extracted with the previous method.
But in this case, I don’t see how we could use DICS because after reconstructing MEG data with DICS, we get power data in the frequency domain. However, to compute coherence, we need to compute the cross spectrum and for this we need complex numbers, don’t we?
So I am wondering: is there a way to use DICS anyway before computing coherence in sensor space? And is computing coherence in source space roughly the same as reconstructing sensor space coherence?
I thought ‘mne’ was a beamforming technique so I am completely mistaken here, thank you for the information!
Here is the code I used to compute leadfields :
cfg = [];
cfg.grad = hdr.grad; % sensor information in m
cfg.channel = MEG_contr.label; % used channels
cfg.grid = sourcemodel; % source points information in m
cfg.headmodel = headmodel; % volume conduction model in m
leadfield = ft_prepare_leadfield(cfg);
Comparing it with your advised code, I guess that we actually don’t need to use cfg.grad because sensor positions should already be found in sourcemodel, headmodel or data structure? But the thing is there is no such information in any of these structures. Does it mean I am missing something when computing headmodel or sourcemodel or MEG_contr?
I changed the previous code into
cfg = [];
cfg.headmodel = headmodel;
cfg.sourcemodel = sourcemodel;
cfg.channel = MEG_contr.label;
leadfield = ft_prepare_leadfield(cfg, MEG_contr);
which returns the following expected error :
“Error using ft_fetch_sens (line 202)
no electrodes, gradiometers or optodes specified.”
So I added cfg.grad again
cfg = [];
cfg.headmodel = headmodel;
cfg.sourcemodel = sourcemodel;
cfg.channel = MEG_contr.label;
cfg.grad = hdr.grad;
leadfield = ft_prepare_leadfield(cfg, MEG_contr);
Here I get the same leadfield as I computed with the first version of code so it seems that cfg.grid and cfg.sourcemodel come down to the same thing.
I have to say 4D channel ordering seems quirky to me too and I accidentally reordered channels in alphanumeric order when I visualized data with the Timone software called AnyWave. This mistake left me with different ordering in hdr.grad and in MEG_contr (data). But the problem is solved, leadfield computation should be fine now. The order of channels in leadfield structure now matches the order of channels in data (MEG_contr) structure.
I mixed things up when computing mne indeed and I don’t understand why an empty room measurement is needed for mne only (and not for beamformer techniques). In any case Jean-Michel also advised me not to use mne and I want to use a beamformer technique anyway so.. let’s go for lcmv!
Whether I will have enough RAM to compute all the dipoles’ single trial time courses will depend on
- the sourcemodel resolution
- the number of trials
(and the computer RAM of course but It’s already 16GB)
I always have around 100 trials and I don’t want to lose any data, so I won’t be able to play with this parameter.
MRIs have a 2 mm resolution so it would not make sense to try a better resolution with the sourcemodel, would it?
So I tried a 2mm sourcemodel resolution but it returned ‘out of memory’ error when computing single trial source data. I tried with 4 mm and it worked.
I used the following code to compute single trial source level time series data, taking into account the fact that cfg.rawtrial should not be used :
% Compute noise-covariance matrix
cfg = [];
cfg.covariance = 'yes';
cfg.keeptrials = 'yes';
tlcontr_MEG = ft_timelockanalysis(cfg, MEG_contr);
% Compute lcmv filters
cfg = [];
cfg.method = 'lcmv';
cfg.sourcemodel = leadfield;
cfg.headmodel = headmodel;
cfg.lcmv.keepfilter = 'yes';
source_MEG_filters = ft_sourceanalysis(cfg,tlcontr_MEG);
% Get source data for all trials : project channel level trials through filters
source_MEG = MEG_contr; % copy the architecture of sensor data stucture
source_MEG.label = cellstr(string(1:sum(sourcemodel.inside)))';
source_MEG = rmfield(source_MEG,'hdr');
FILTER = source_MEG_contr.avg.filter(cellfun(@(a) ~isempty(a),source_MEG_filters.avg.filter));
for triali = 1 : length(source_MEG.trial)
source_MEG.trial{triali} = cell2mat(cellfun(@(a) sum((a*MEG_contr_1s.trial{triali}).^2,1),FILTER,'UniformOutput',false));
disp(['Trial n° ' num2str(triali) ' out of ' num2str(length(source_MEG.trial))])
end
Does it seem to be a correct method ?
Thank you again!
I hope everyone enjoyed the risotto! I sometimes cook it as well, it’s delicious with mushrooms 😊
Manon
-----Message d'origine-----
De : fieldtrip <fieldtrip-bounces at science.ru.nl> De la part de fieldtrip-request at science.ru.nl
Envoyé : dimanche 31 octobre 2021 12:00
À : fieldtrip at science.ru.nl
Objet : fieldtrip Digest, Vol 131, Issue 32
Send fieldtrip mailing list submissions to
fieldtrip at science.ru.nl
To subscribe or unsubscribe via the World Wide Web, visit
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
or, via email, send a message with subject or body 'help' to
fieldtrip-request at science.ru.nl
You can reach the person managing the list at
fieldtrip-owner at science.ru.nl
When replying, please edit your Subject line so it is more specific than "Re: Contents of fieldtrip digest..."
Today's Topics:
1. Re: Magnitude of leadfield in beamformer
(Schoffelen, J.M. (Jan Mathijs))
2. Re: Question regarding the function ft_freqstatistics.
(Schoffelen, J.M. (Jan Mathijs))
3. Re: ft_volumelookup: Different devices different results same
script (Schoffelen, J.M. (Jan Mathijs))
4. Re: ft_sourceanalysis single trial reconstruction
(Schoffelen, J.M. (Jan Mathijs))
5. Re: hdr_read_header (Schoffelen, J.M. (Jan Mathijs))
----------------------------------------------------------------------
Message: 1
Date: Sat, 30 Oct 2021 13:36:34 +0000
From: "Schoffelen, J.M. (Jan Mathijs)"
<janmathijs.schoffelen at donders.ru.nl>
To: FieldTrip discussion list <fieldtrip at science.ru.nl>
Subject: Re: [FieldTrip] Magnitude of leadfield in beamformer
Message-ID: <0C26DD96-7AB9-4461-A968-8206388E760F at donders.ru.nl>
Content-Type: text/plain; charset="utf-8"
Hi Jinwen,
The physical units of the lead field are units-of-the-stuff-you-measure-with-your-measurement-device / units-of-dipole-moment.
Thus - for EEG - this will be something like V / Am.
I don’t think I fully understand your question: do you mean with ’the resulting magnitude of lead field was 10^-5’ that the resulting signal was of magnitude 10^-5 (which for EEG would be 10 microvolts)? I would say that this does not sound too bad.
Best wishes,
Jan-Mathijs
On 20 Oct 2021, at 10:14, Jinwen Wei via fieldtrip <fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl>> wrote:
Dear all,
My name is Jinwen and I am conducting forward modelling for EEG source reconstruction following https://www.fieldtriptoolbox.org/workshop/oslo2019/forward_modeling/<https://urldefense.com/v3/__https://www.fieldtriptoolbox.org/workshop/oslo2019/forward_modeling/__;!!HJOPV4FYYWzcc1jazlU!oldn94sFtU6sSZ3RhSg1GJfmLd1KDLSj8B0iy5NPqJS8fTZkip453A0marDA7JmkgmcppbJRrIlKPpA$>. I have a question about the magnitude of lead field matrix.
According to the tutorial, the leadfield describes what would be seen at the sensor level given that a source was active with a given current (1 Am). In the ending part of the tutorial, a realistic source current of 100 nAm was used to plot the lead field and the resulting magnitude of lead field was 10^-5. That is to say, the original lead field had a magnitude of 10^2 because 10^2 *100*10^-9 = 10^-5. However, how come the original lead field has such a huge magnitude. Actually, when I modelled the lead field using standard BEM, I found the magnitude of the original lead field was quite small, like 10^-5. So I am wondering what magnitude of the original lead field is.
Best regards,
Jinwen
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://urldefense.com/v3/__https://doi.org/10.1371/journal.pcbi.1002202__;!!HJOPV4FYYWzcc1jazlU!oldn94sFtU6sSZ3RhSg1GJfmLd1KDLSj8B0iy5NPqJS8fTZkip453A0marDA7JmkgmcppbJRGYbBKX4$
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20211030/1d3031ab/attachment-0001.htm>
------------------------------
Message: 2
Date: Sat, 30 Oct 2021 13:41:51 +0000
From: "Schoffelen, J.M. (Jan Mathijs)"
<janmathijs.schoffelen at donders.ru.nl>
To: FieldTrip discussion list <fieldtrip at science.ru.nl>
Cc: "Chauviere, Laetitia" <laetitia.chauviere at brain.mpg.de>
Subject: Re: [FieldTrip] Question regarding the function
ft_freqstatistics.
Message-ID: <64BF93C5-2C4D-4AB1-8816-5C5E6C7B57B3 at donders.ru.nl>
Content-Type: text/plain; charset="utf-8"
Hi Laetitia,
My suggestion would be to check the sanity of the data structure, and to check the dimensionality of cfg.design.
Since you handcrafted your numerical data, and don’t give any specifics w.r.t. the metadata (*.dimord, *.freq, *.time, *a.label) of your BigMatdef variable It’s a mismatch between the data and the design that causes the error.
I don’t understand why you index the cfg.design variable as if it’s a 4D matrix, typically it’s a row vector (or a matrix with a few rows), with the observations in the columns.
Best wishes,
Jan-Mathijs
On 21 Oct 2021, at 09:30, Chauviere, Laetitia via fieldtrip <fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl>> wrote:
Dear FieldTrip users,
I have a question regarding the function ft_freqstatistics.
I would like to do statistics on the powerspectrum data (output of the function ft_freqanalysis) between two conditions (same monkey).
I have the Data Input whose structure corresponds to the output of the function ft_freqanalysis, and the design matrix whose size is the same as the data input (datainput.powspctrm) : size(datainput.powspctrm) = size(cfg.design), and the data to compare are in datainput.powspctrm.
BigMat = NaN(8670,1,182,164);
BigMat (1:2078,1,1:91,1:77) = MM25; % matrix (trials, channel, freq, time) – 1st condition
BigMat (2079:8670,1,92:182,78:164) = M25; % matrix (trials, channel, freq, time) – 2nd condition
BigMatdef = PowAllCond_ALLFBS{1,1}; % PowAllCond_ALLFBS{1,1} : output function ft_freqanalysis, so to get the same structure
BigMatdef.powspctrm = BigMat; % big matrix (trials, channel,freq,time) – with the two conditions
cfg.design(1:2078,:,:,:) = 1; % 1st condition
cfg.design(2079:8670,:,:,:) = 2; % 2nd condition
However I still have this error message from Matlab:
"Error using ft_freqstatistics (line 294) the number of observations in the design does not match the number of observations in the data"
Any tip/suggestion?
Many thanks in advance!
Best,
Laetitia.
Dr. Laetitia Chauvière - PhD
Post-Doc - Prof. Singer's lab - Room 303 Max Planck Institute for Brain Research Deutschordenstr. 46
60528 Frankfurt am Main - Germany
laetitia.chauviere at brain.mpg.de<mailto:laetitia.chauviere at brain.mpg.de>
T: +49 69 96769-272
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://urldefense.com/v3/__https://doi.org/10.1371/journal.pcbi.1002202__;!!HJOPV4FYYWzcc1jazlU!on07W9aDE29PzvTPBIUCi0hZuP9TA4hlXO-ygI12L8s6HbAtFRv7QOEFdzf48crMsLGXox9hr7pMJyg$
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20211030/5d1f1a37/attachment-0001.htm>
------------------------------
Message: 3
Date: Sat, 30 Oct 2021 15:09:40 +0000
From: "Schoffelen, J.M. (Jan Mathijs)"
<janmathijs.schoffelen at donders.ru.nl>
To: FieldTrip discussion list <fieldtrip at science.ru.nl>
Subject: Re: [FieldTrip] ft_volumelookup: Different devices different
results same script
Message-ID: <84C17A11-A09F-4B30-8627-BD0596FA133A at donders.ru.nl>
Content-Type: text/plain; charset="utf-8"
Dear Michelle,
Given the lack of responses so far, it seems that no one has encountered your issue before.
Yet, I was wondering whether this is not a user error indeed. The help of ft_volumelookup mentions that it should work on a ‘volume’ structure as input. You mention that you use (of course :) ) a warped grid, which is probably not what you want, for 2 reasons:
1) the atlas should be in the same coordinate space as the object that is used in ft_volumelookup, using something warped sounds as if this is expressed in a possibly ill-defined space. In your pasted code, you explicitly specify sourcemodel.coordsys as ‘mni’, but is this truly the case?
2) the geometric info in a sourcemodel structure is defined by a set of dipole positions in 3D (i.e. a Nx3 matrix), rather than by a 3-element dim-field, which combined with a transform-field implicitly define the positions in the volume.
Somehow, FT gives you the benefit of the doubt, and manages to convert the source(model) representation into a volume representation. It’s still surprising that the downstream effects of this depend on the matlab version + device.
Also, it might be informative to the readership of the list, to what extent the different matlab versions return different numbers of grid points. Have you inspected this in more detail?
Best wishes,
Jan-Mathijs
On 27 Oct 2021, at 13:44, Michelle via fieldtrip <fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl>> wrote:
Dear Fieldtrip community,
I was wondering if you could help me with a problem occurring using the function ft_volumelookup. Depending on the computer I use, I get a different number of selected grid points. I use the same script (see scrip below) and the same FieldTrip Version (20210825), the only difference is that I used different MATLAB Versions on the different devices: MATLAB 2020b, MATLAB 2019b, MATLAB 2018a. But even when I used the same MATLAB Version (2019b) on different devices I received different results.
Has someone ever encountered a similar problem, or do I have some kind of error in my code (of course I always load the same warped grid I calculated from an MRI)?
<pastedImage.png>
Thank you in advanced.
Best wishes,
Michelle
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://urldefense.com/v3/__https://doi.org/10.1371/journal.pcbi.1002202__;!!HJOPV4FYYWzcc1jazlU!vfCCM0D-bJncXMU16CeN-dBPTUkeJ01aGEhRydNhgWOnhLRWmLU8SA9MtxQwxVqdZBI_wexPFML2Rhs$
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20211030/a62a589e/attachment-0001.htm>
------------------------------
Message: 4
Date: Sat, 30 Oct 2021 17:07:23 +0000
From: "Schoffelen, J.M. (Jan Mathijs)"
<janmathijs.schoffelen at donders.ru.nl>
To: FieldTrip discussion list <fieldtrip at science.ru.nl>
Subject: Re: [FieldTrip] ft_sourceanalysis single trial reconstruction
Message-ID: <39EF5F26-0683-485C-A535-9D00FE671B32 at donders.ru.nl>
Content-Type: text/plain; charset="utf-8"
Dear Manon,
Just as a pre-preliiminary: you write that you want to compute EMG-MEG coherence. Did you consider to use DICS for this? If you know which frequency (range) you want to look at, I think that this would be the most straightforward. There’s plenty of documentation on the website for this.
Then, as a second preliminary: you write that you want to use a ‘beamformer technique in the time domain’, but in your code you use ‘mne’ as a method, which is a different algorithm altogether. Yet, it is not really relevant to the problem you are facing, so for now I’ll let it slip :). As a side note, the option ‘rawtrial’, for ft_sourceanalysis, and as far as I know, does not have any funcionality for the mne method, and only (historically) was functional for beamformers. These days, this option is explicitly DISrecommended. (nobody has found the time yet to cleanly deprecate this functionality altogether)
OK, after these preliminaries, let’s think about the conceptual challenges first:
What you have looked into, and already understand quite well, is the way in which FieldTrip does a lot of bookkeeping in order to try and ensure that all data objects that implicitly have a channel dimension are well matched w.r.t. the assumed order of the channels.
Specifically, in the context of forward and inverse modelling, different types of data ‘come together’. There’s leadfieds (either or not precomputed), spatial filters, and data (covariances and time series data). In order for the mathematical operations to make sense, the identity and the order of the channels in the data objects need to match. This assumed equivalence of channel order is not always guaranteed, particularly if you have a quirky naming (and ordering) scheme as the la Timone MEG system, but perhaps the other JM (=JeanMichel) would disagree with me calling your system quirky. Typically, the channel order in raw data from 4D-neuroimaging/Magnes/BTI systems is NOT in alphanumeric order, neither in the time series, nor in the description of the magnetometer array. Sooo, the long story short is that books need to be kept regarding the channel ordering. Yet, another thing to keep in mind in addition, is that any (linear) operations applied to the time series data (e.g. removal of spatial topographies by using ICA followed by backprojection, or applying denoising using the reference channels) need to be represented in the leadfields as well. In other words, if you precomputed the leadfields on an unbalanced grad-structure (fieldtrip speak for a sensor representation that has not been processed with the same processing pipeline that was used to preprocess the actual data) then this is not good.
Long story short, if you are to precompute your leadfields in a separate step (which I’d recommend), I would do it as follows:
cfg = [];
cfg.headmodel = <headmodel>
cfg.sourcemodel = <sourcemodel>
cfg. < some other options >
cfg.channel = data.label (assuming that the data does not contain non-MEG channels) leadfield = ft_prepare_leadfield(cfg, data)
where data is the data structure that you later want to subject to ft_sourceanalysis. This would result in leadfields that not only have a more or less consistent order in the channels (i.e. consistent with the data), but also the leadfields are properly ‘balanced’. Note, however that a lot of the stuff you described in your e-mail related to the code that you identified in FT tries to ensure a correct channel order between different data objects.
Now, concretely, if you want to use a beamformer for source reconstruction, you should specify cfg.method = ‘lcmv’, rather than ‘mne’. If you on the other hand want to compute an mne-solution, you should NOT input the full data covariance matrix, but rather use an estimate of the noise (e.g. using an empty room measurement). In the code that you pasted in the e-mail you seem to have mixed these two things up.
Then, finally getting to what you want to achieve, the question is how to efficiently obtain single trial source level time series data. Indeed, I’d recommend a two-step approach, where you first obtain a set of spatial filters, and then subject the channel data to the spatial filters. I would assume that if you use precomputed leadfields as per the above suggestion, the order of the channels will match the order of the channels in the data (again provided the data does not contain non-MEG) channels. Now the question is whether you will have enough computer RAM to begin with to fit all the dipoles’ single trial time courses.
Perhaps we could follow up on this in a next set of e-mails in this thread - also to give other people the opportunity to chime in -, but also because 1) the above might already give you ample food for thought for now, and 2) my risotto is almost cooked, so I have to summon the troups at home to the dinner table.
Keep up the good work and critical thinking,
JM
On 25 Oct 2021, at 19:02, CHATEAUX Manon via fieldtrip <fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl>> wrote:
Dear FieldTrip community,
I want to compute coherence between brain sources and an EMG channel that I selected. Here is the pipeline I am using :
* Preprocess MEG and EMG data
* Process single subject MRI data to get (a) the head model, (b) the source model with leadfields
* Reconstruct MEG data using beamformer techniques in the time domain.
* Compute coherence between source data and EMG data
To be able to compute coherence, I need to reconstruct data for all trials and not as an average of trials. But I encountered a problem at this level.
Here is the code I used first :
% Compute noise-covariance matrix
cfg = [];
cfg.covariance = 'yes'; %default takes the whole time window to estimate the noise covariance matrix
cfg.keeptrials = 'yes';
tlcontr_MEG = ft_timelockanalysis(cfg, MEG_contr);
% Compute inverse modelling with mne : source data averaged over % trails
cfg = [];
cfg.method = 'mne';
cfg.sourcemodel = leadfield;
cfg.headmodel = headmodel;
cfg.mne.lambda = 3; %%????
cfg.mne.keepfilter = 'yes';
cfg.rawtrial = 'no';
source_MEG_contr = ft_sourceanalysis(cfg,tlcontr_MEG);
% Get source data for all trials : project trials by hand
FILTER = source_MEG_contr.avg.filter(cellfun(@(a) ~isempty(a),source_MEG_contr.avg.filter));
for triali = 1 : length(MEG_contr.trial)
source_MEG_contr_trials.pow{triali} = cell2mat(cellfun(@(a) sum((a*MEG_contr.trial{triali}).^2,1),FILTER,'UniformOutput',false)');
disp(['Trial n° ' num2str(triali) ' out of ' num2str(length(MEG_contr.trial))])
end
source_MEG_contr_trials is to be the structure that contains source data for all trials. As you can see I computed it by hand, following a thread that I found on the website.
Then I found it was possible to use ft_sourceanalysis again, to project all trials through the filter computed at the first use of the function. So I replaced the last paragraph of code with the following :
% project all trials through common spatial filter to get source data
% for separate trials
cfg=[];
cfg.method = 'mne';
cfg.sourcemodel = leadfield; % previously computed grid
cfg.headmodel = headmodel; % previously computed volume conduction model
cfg.rawtrial = 'yes'; % project each single trial through the filter to reconstruct single trial data
cfg.sourcemodel.filter = source_MEG_contr.avg.filter; % use the common filter computed in the previous step!
source_MEG_contr_trials = ft_sourceanalysis(cfg, tlcontr_MEG); % contains the source estimates for all trials/both conditions
I preferred this “automatic” way rather than the manual one because it allows me to keep the FieldTrip shape of structures more easily and display results using FieldTrip functions.
However, I realized that it returned completely different results. After trying to understand the steps performed in the second use of ft_sourceanalysis, I realized that filters used to compute trial source data from trial channel data (l. 295 in ft_inverse_mne of fieldtrip-20210921 : estimate.mom{i} = sourcemodel.filter{i}*dat) were different from filters in cfg.sourcemodel.filter.
In fact, channel labels are taken from the leadfield structure. Lines (channel dimension) in filter matrices (in cfg.sourcemodel.filter) are reorganized so that it matches channel order from data.label (= tlcontr_MEG.label).
See l.404-410 in ft_sourceanalysis of fieldtrip-20210921 :
[dum, chansel] = match_str(data.label, sourcemodel.label); sourcemodel.label = sourcemodel.label(chansel); for i=1:numel(sourcemodel.filter)
if ~isempty(sourcemodel.filter{i})
sourcemodel.filter{i} = sourcemodel.filter{i}(:, chansel);
end
end
Thus, if I understand it correctly, this step assumes that lines in filter matrices (which come from source_MEG_contr structure) are organized in the same way as channels in leadfields. However, this is not actually the case here because
1. source_MEG_contr.avg.label and data.label (= tlcontr_MEG.label) are equal.
2. I don’t understand why but leadfields.label is different from the original alphanumerical channel organization – A1 A2 A3 etc…- found in raw data (as well as in source_MEG_contr, and in tlcontr_MEG).
So I think that in my case, lines in filter matrices should not be reorganized (when they are not, I get the same results as by hand) but as leadfield structure is also used when I compute source_MEG_contr from tlcontr_MEG, I am not sure I can trust source_MEG_contr either.
I would truly appreciate if someone could proofread and pinpoint some problems in this reasoning to help me solve this annoying problem. In the meantime I will try to recompute the leadfield structure so that channel order is the same everywhere.
Thank you in advance for your help and the time you will spend reading through this message!
Manon Châteaux
phD Student at Aix-Marseille University
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://urldefense.com/v3/__https://doi.org/10.1371/journal.pcbi.1002202__;!!HJOPV4FYYWzcc1jazlU!sfGi3q4aOeMCoe7W0_ghPeD-viaovjeAzPnJRvx05cVOf7UZKHz_GIupVsUV7rEW0MzP5TGOqE2mnKs$
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20211030/d346eaa6/attachment-0001.htm>
------------------------------
Message: 5
Date: Sat, 30 Oct 2021 19:35:12 +0000
From: "Schoffelen, J.M. (Jan Mathijs)"
<janmathijs.schoffelen at donders.ru.nl>
To: FieldTrip discussion list <fieldtrip at science.ru.nl>
Subject: Re: [FieldTrip] hdr_read_header
Message-ID: <4AA0CA72-7D2D-499D-A409-0692A3BCBE22 at donders.ru.nl>
Content-Type: text/plain; charset="utf-8"
Hi Eva,
Perhaps the following quote - from the help documentation of the read_edf.m function, which is in fieldtrip/fileio/private, and which is used under the hood by ft_read_header - may give you some ‘aanknopingspunten’:
% READ_EDF reads specified samples from an EDF datafile. It neglects all trial or % data block boundaries as if the data was acquired in non-continuous mode.
%
% Note that since FieldTrip only accommodates a single sampling rate in a given % dataset, whereas EDF allows specification of a sampling rate for each channel. If % there are heterogenous sampling rates then this function will automatically choose % a subset. If the last such channel is different from the rest, the assumption will % be made that it is the annotation channel and the rest will be selected. If that % is not the case, then the largest subset of channels with a consistent sampling % rate will be chosen. To avoid this automatic selection process, the user may % specify their own choice of channels using chanindx. In this case, the automatic % selection will only occur if the user selected channels still have heterogenous % sampling rates. In this case the automatic selection will occur amongst the user % specified channels. While reading the header the resulting channel selection % decision will be stored in hdr.orig.chansel and the contents of this field will % override chanindx during data reading.
Best wishes,
Jan-Mathijs
On 19 Oct 2021, at 10:06, Eva Schlösser via fieldtrip <fieldtrip at science.ru.nl<mailto:fieldtrip at science.ru.nl>> wrote:
Dear all,
Hope you are doing okay.
I'm making two script for selecting EEG or aEEG data.
When I use the ft_read_header function for EEG data (edf file), my script is working and selecting all the right channels (because of the frequency of the EEG data is most common in the edf file).
However, when I have the aEEG .edf file, hdr_read_header is taking the 1 [Hz] channels instead of the channels of the aEEG, because the 1 [Hz] is now more common in the edf. file, but those channels I don't need!
I tried to use the edf2fieldtrip function, ft_channelselection and ft_selectdata.
Now it is possible to get the data for only the aEEG channels. However, I want to read this data with the ft_read_header function, so I can use the same hdr.Fs (for example) in my script.
Can somebody help me with this?
Kind regards,
Eva
<hdr_read_header.txt>_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://urldefense.com/v3/__https://doi.org/10.1371/journal.pcbi.1002202__;!!HJOPV4FYYWzcc1jazlU!offyjAwct_fSvMS6_c7A5F5Ahr6lp9sKbYcMFxRum_u-eLxv9HCRjbqfjCCIEBGl0kEAD-nawGnngUQ$
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20211030/633f0d87/attachment-0001.htm>
------------------------------
Subject: Digest Footer
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
_______________________________________________
fieldtrip mailing list
https://mailman.science.ru.nl/mailman/listinfo/fieldtrip
https://doi.org/10.1371/journal.pcbi.1002202
------------------------------
End of fieldtrip Digest, Vol 131, Issue 32
******************************************
More information about the fieldtrip
mailing list