Back to the main page.

Bug 1572 - Fix for empty channels in ft_read_header.

Reported 2012-06-29 11:12:00 +0200
Modified 2012-11-16 12:27:26 +0100
Product: FieldTrip
Component: fileio
Version: unspecified
Hardware: All
Operating System: All
Importance: P3 normal
Assigned to: Boris Reuderink
Depends on:
See also:

Boris Reuderink - 2012-06-29 11:12:41 +0200

Received following email from Philip with suggested fix for problem caused by unlabeled channels. Seems like a sensible fix to me. Does anyone have an objection? --- Bij de testen een paar maanden geleden met de tmsi porti hadden we een probleem veroorzaakt door de labeling van kanalen door tmsi (sommige kanalen hebben geen label). Ik heb dit toen snel gefixed door de volgende aanpassing in ft_read_header, zie info hieronder. In feite moet dit in de interfacing software van tmsi worden opgelost, maar misschien is er een andere reden om geen incidentele lege labels toe te staan? Gr. Philip % quick fix for tmsi_porti if isfield(orig,'channel_names') orig.channel_names(cellfun(@isempty,orig.channel_names))={'no label'}; end

Robert Oostenveld - 2012-06-29 11:20:30 +0200

channel names should be unique. See line 1651 in ft_read_header and/or search for "checkUniqueLabels" For other systems without channel names we use this for i=1:hdr.nChans hdr.label{i} = sprintf('%d', i); end Search for "sprintf" So I suggest here as well to use "%d" as the format for the channels with empty labels. That makes the channels unique and keeps them identifiable for the users. Please go ahead and implement it.

Benjamin de Jonge - 2012-06-29 11:49:44 +0200

It seems that the last channel has no label, but in fact it does. The label that is always 'empty' according to ft_read_header is 'Saw' which controls data integrity of TMSi devices. According to this bugreport, I understand that the fix will be to create a label for empty channel labels? Gr Benjamin de Jonge (TMSi)

Robert Oostenveld - 2012-06-29 12:04:48 +0200

(In reply to comment #2) the label is not empty according to ft_read_header (which simply represents labels that it reads) , but the label is empty according to the representation in the buffer. If the label should have been "Saw", it suggests that the label was not written into the buffer. The problem then is in the tmsi application that writes the data to the buffer. The suggested fix from Philip, but then using sprintf('%d') rather than 'no label', remains a valid solution for ft_read_header in case the acquisition software failed to write all channel names to the buffer. It makes ft_read_header more robust and allows MATLAB to deal with errors that are caused elsewhere. The error of the TMSi specific acquisition software that writes data to the buffer with an accompanying header that has one missing channel also needs to be fixed by TMSi. As it is not part of FieldTrip and the source code is not accessible to us, we cannot help with that. But as it stands, the present implementation of the tmsi software seems not to be fully compliant with

Boris Reuderink - 2012-06-29 14:24:34 +0200

From reading the code of ft_read_header, I get the impression that the creation of labels is disabled intentionally for the realtime buffer for efficiency reasons. See for example the comment at line 105 of ft_read_header [1]. Instead of Philips fix, we could set 'checkUniqueLabels = true'. To prevent then the issue of created thousands of labels for real-time fMRI, we build in a safeguard in at [2], where the labels are created? Say, don't create channel names if 'hdr.nChans >= 2000' and 'strcmp(headerformat, 'fcdc_buffer')'? [1] [2]

Robert Oostenveld - 2012-06-29 14:45:08 +0200

(In reply to comment #4) I am confused. Are there no channel labels at all, or just some channel labels missing? If there are no at all, then they should be generated (except in case of fMRI). If there are some missing, the missing ones should get fixed.

Boris Reuderink - 2012-07-04 15:03:58 +0200

Fixed in SVN revision 6227. I have added a few warnings to complain about missing and empty channel labels in ft_read_header, and added code to 'fix' these labels.

Robert Oostenveld - 2012-11-16 12:27:26 +0100

(In reply to comment #3) Here is an update on the TMSi side of things: On 15 Nov 2012, at 14:58, Benjamin de Jonge wrote: Het is al weer enige tijd geleden dat we contact hebben gehad over onderstaand issue. Inmiddels hebben we het probleem gevonden en opgelost. Het probleem zat in onze applicatie waar de header length specifier had 4 bytes te weinig had, waardoor het laatste kanaallabel niet of niet goed over kwam. Het zat dus inderdaad aan onze kant. Inmiddels is dat dus gefixed.