Logical problem with CTF 3rd order gra diometers correction

Michael Wibral wibral at BIC.UNI-FRANKFURT.DE
Fri Aug 1 10:00:01 CEST 2008


Dear Robert,

thank you very much for your answer. What I tried to do is invoke reject artefact after denoise_synthetic so that it works on the already denoised data (which is of course useless as it reads the data anew as I see now) . The aim of this procedure was to keep more trials. Is there any way to achieve this? 
The only thing I can think of right now is to run 3rd grads in the CTF software, save these data, then read them in with the new  functions (Fieldtrip should know then that data are already in 3rd grad, shouldn't it?) and proceed as usual (i.e. run rejectartefact + preprocessing).

Best Regards,
Michael

> -----Ursprüngliche Nachricht-----
> Von: "Robert Oostenveld" <r.oostenveld at FCDONDERS.RU.NL>
> Gesendet: 31.07.08 23:01:00
> An: FIELDTRIP at NIC.SURFNET.NL
> Betreff: Re: [FIELDTRIP] Logical problem with CTF 3rd order gradiometers correction


> Hi Michael
> 
> On 31 Jul 2008, at 18:11, Michael Wibral wrote:
> > Dear listusers,
> >  I have a logical problem with denoise-synthetic.
> >
> > here's  what I want to do:
> >
> > 1. use definetrial to make cfg.trl (works fine)
> > 2. use preprocessing with the new cfg. headerfile='ctf_new' ,  
> > cfg.datafile='ctf_new' options to read the reference gradiometer  
> > information and the data into a fieldtrip structure (works fine)
> > 3. use denoise_synthetic to denoise the data (works fine ?)
> 
> In the (sofar limited) experiences that I heard there are noticeable  
> differences mainly on the central/vertex sensors (which are also the  
> closest to the reference sensors).
> 
> > 4. un artefact detection on these data (-> this works fine and  
> > updates cfg.trl)
> 
> after artifact_xxx and rejectartifact you should read the data using  
> preprocessing. Or are you using rejectvisual? If so, then you don't  
> have to call preprocessing a second time, because the output of  
> rejectvisual is again your data with the bad trials removed.
> 
> > 5. run preprocessing a second time for filtering and actually  
> > applying the results of artefact corrcetion,... i.e. those things  
> > that I didn't want to do before denoise_synthetic.
> 
> After rejectartifact, you should be calling it here like preprocessing 
> (cfg), and not with a second input argument.
> 
> If you call it like preprocessing(cfg, data), then the cfg should not  
> contain cfg.dataset and cfg.trl but only filtering options, because  
> the data should not be read from file.
> 
> > BUT preprocessing complains that cfg shouldn't contain the cfg.trl  
> > field when no data are read - which is the case because I am  
> > invoking preprocessing a second time here on an existing fieldtrip  
> > structure.
> 
> I suspect that you are mixing up rejectartifact and preprocessing.  
> Calling preprocessing with a 2nd data input argument is only meant to  
> apply another set of filters on that data (i.e. if you forgot to do  
> it in the first run, or if you sequentially want to bandstopfilter  
> some line noise or CRT artifacts).
> 
> > Therefore all information from artefact rejection is lost.
> >
> > Somehow it seems that I can run denoise_synthetic only after  
> > artefact rejection, because I need a fieldtrip dataset to run it,  
> > but NO dataset for preprocessing to perform artefact correction,  
> > i.e. accept cfg.trl. This would be a pity.
> 
> I must say that I had not considered sofar the interaction between  
> denoising and artifact detectoin and removal. The artfifact_xxx  
> functions perform detection on data from disk(*), i.e. prior to  
> reading the data into memory. The historical reason for (*) is to  
> save on memory when a lot of filter padding is used and when there is  
> a lot of overlap between padded trials. The padded regions should be  
> checked for artifacts (esp jump artifacts which cause a lot of filter  
> rinning), but in the end we don't need them in memory. The denoising  
> only happens after the data is read into memory.
> 
> > Any suggestion how to solve this?
> 
> For the moment I suggest to use the following sequence
> 
> definetrial
> preprocessing
> denoise_synthetic
> rejectvisual
> 
> and not use artifact_xxx combined with rejectartifact. We are  
> revising the automatic artifact detection functions at the moment,  
> since computers nowadays have much more RAM than when we started  
> implementing it 5 years ago, and reading the padded data into memory  
> is now much less of a concern. So in the near future, it will be  
> possible to do autodetection of artifacts also on data that is in  
> memory, which means that then you could also do the autodetection  
> after denoise_synthetic.
> 
> best regards
> Robert
> 
> ----------------------------------
> The aim of this list is to facilitate the discussion between users of the FieldTrip  toolbox, to share experiences and to discuss new ideas for MEG and EEG analysis. See also http://listserv.surfnet.nl/archives/fieldtrip.html and http://www.ru.nl/fcdonders/fieldtrip.
> 



----------------------------------
The aim of this list is to facilitate the discussion between users of the FieldTrip  toolbox, to share experiences and to discuss new ideas for MEG and EEG analysis. See also http://listserv.surfnet.nl/archives/fieldtrip.html and http://www.ru.nl/fcdonders/fieldtrip.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Michael Wibral.vcf
Type: text/x-vcard
Size: 443 bytes
Desc: not available
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20080801/c2faee45/attachment-0001.vcf>


More information about the fieldtrip mailing list