[FieldTrip] ft_channelrepair increases the size of the data file

Vitoria Piai v.piai.research at gmail.com
Sat Mar 21 01:35:24 CET 2015


Hi FT-ers,

I think I won't be able to figure out this problem by diving into the 
ft_channelrepair code. So if you can shed any light to what could be 
going on, I'd be *very *thankful!!

I followed Eelke's and JM's advice to split the data, fix some channels 
only for certain trials, then put the data together. All fine, except 
for the following. If I apply this procedure a large number of times 
(haven't figured out what the threshold is yet), the file size increases 
by a considerable amount. For example, when I fixed one channel for all 
trials, and then 7 channels for a couple of trials, the file went from 
1GB to almost 3GB. Then Matlab slows down and eventually hangs, and the 
data (saved with '-v7.3') is "corrupted" once I try to load it to my 
workspace again.

It seems to me that ft_channelrepair is keeping information in a 
'previous' field such that every call to it will just keep adding bytes, 
is that the case? I'm planning to delete everything that is in 
cfg.previous and just keep the .trl field for later. Can you foresee I 
will run into unrepairable trouble later because of this? Is there any 
other field within the cfg.previous I should keep besides the .trl?

Thanks a lot again!!
Have a nice weekend,
Vitória

On 3/13/2015 9:08 AM, Schoffelen, J.M. (Jan Mathijs) wrote:
> Hi V,
> Note that you can use the trialinfo field in your data for bookkeeping, e.g. (assuming there is already such field in your data)
>
> data.trialinfo(:,end+1) = (1:numel(data.trial))’;
> cfg = [];
> cfg.trials = sel_to_be_repaired;
> cfg.etc
> data1 = ft_channelrepair(cfg,data);
>
> cfg = [];
> cfg.trials = sel_to_be_unrepaired
> data2 = ft_selectdata(cfg, data);
>
> data = ft_appenddata([],data1,data2);
>
> Although the order has now been changed, you’ll see that the last column of the trialinfo field still pertains to your original trial indices.
>
> JM
>
>
>
> On Mar 13, 2015, at 4:35 PM, Vitória Piai <v.piai.research at gmail.com> wrote:
>
>> Thanks, Eelke!
>>
>> I had already done what you suggested. The issue is that ft_appenddata appends (;-) ) the data rather than restoring it back to normal. Since I defined all trials to repair at the very beginning, none of the indexes for those trials make sense anymore after the first call to ft_appenddata. I guess I'll work around it by keeping values rather than indices for the trials I need to repair.
>>
>> Thanks a lot,
>> Hope all is well in Nijmegen!!
>>
>> On 3/11/2015 12:32 AM, Eelke Spaak wrote:
>>> Hi Vitoria,
>>>
>>> Yes, that is the expected behaviour of ft_channelrepair, because that
>>> is consistent with all other functions supporting a cfg.trials-option
>>> (i.e. select first, then do the work on what remains).
>>>
>>> It should be quite straightforward to do something like:
>>>
>>> cfg = [];
>>> cfg.trials = goodtrials;
>>> dat1 = ft_selectdata(cfg, data);
>>>
>>> cfg = [];
>>> ...
>>> cfg.trials = badtrials;
>>> dat2 = ft_channelrepair(cfg, data);
>>>
>>> datcmb = ft_appenddata([], dat1, dat2);
>>>
>>> to achieve what you want.
>>>
>>> Groetjes,
>>> Eelke
>>>
>>> On 10 March 2015 at 23:58, Vitoria Piai <v.piai.research at gmail.com> wrote:
>>>> Hi all,
>>>>
>>>> I'm using ft_channelrepair, ($Id: ft_channelrepair.m 9520 2014-05-14
>>>> 09:33:28Z) to repair bad channels. I wanted to do it only for certain
>>>> trials, and when I saw the option cfg.trials, I was really happy.
>>>> However, if I pass cfg.trials with a vector rather than 'all', then the
>>>> function does:
>>>> ft_selectdata (lines 104, 108),
>>>> then from line 352 onwards, things are converted back to normal.
>>>> But if the cfg contained only some trials (as I'm trying to use it for),
>>>> these are not restored back, and so I'm left with a data structure that
>>>> only has as many trials as my cfg had.
>>>>
>>>> I was just wondering whether that is the expected behaviour of
>>>> ft_channelrepair and that I should restore things myself (presumably
>>>> with ft_append-like functions). If so, it would be nice if the help on
>>>> this function would say that...
>>>> If I'm simply using a too old version, my apologies. (I should start
>>>> working with github, I know!!)
>>>>
>>>> Thanks a lot,
>>>> Vitoria
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> fieldtrip mailing list
>>>> fieldtrip at donders.ru.nl
>>>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip
>>> _______________________________________________
>>> fieldtrip mailing list
>>> fieldtrip at donders.ru.nl
>>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip
>> _______________________________________________
>> fieldtrip mailing list
>> fieldtrip at donders.ru.nl
>> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip
>
> _______________________________________________
> fieldtrip mailing list
> fieldtrip at donders.ru.nl
> http://mailman.science.ru.nl/mailman/listinfo/fieldtrip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20150320/da00c421/attachment-0002.html>


More information about the fieldtrip mailing list