Back to the main page.
Bug 3307 - bitcmp error in read_trigger (Matlab 2014b)
| Status | CLOSED FIXED |
| Reported | 2017-06-12 14:38:00 +0200 |
| Modified | 2019-08-10 12:41:59 +0200 |
| Product: | FieldTrip |
| Component: | fileio |
| Version: | unspecified |
| Hardware: | Macintosh |
| Operating System: | Mac OS |
| Importance: | P5 normal |
| Assigned to: | |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Karen Dijkstra - 2017-06-12 14:38:05 +0200
When attempting to slice biosemi data, there is a call to bitcmp in fieldtrip/fileio/private/read_trigger, line 97, that fails from (at least) Matlab 2014b onwards. Replacing dat(signbit) = bitcmp(abs(dat(signbit))-1,32); with dat(signbit) = bitcmp(abs(dat(signbit))-1,'uint32'); solves the issue for me locally. Note: A similar issue has apparently been solved elsewhere: http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=2409 Error trace: Error using bitcmp ASSUMEDTYPE must be an integer type name. Error in read_trigger (line 97) dat(signbit) = bitcmp(abs(dat(signbit))-1,32); Error in ft_read_event (line 422) event = read_trigger(filename, 'header', hdr, 'dataformat', dataformat, 'begsample', flt_minsample, 'endsample', flt_maxsample, 'chanindx', statusindx, 'detectflank', 'up', 'trigshift', trigshift, 'fixbiosemi', true); Error in N400_trialfun (line 5) event = ft_read_event(cfg.dataset); Error in ft_definetrial (line 178) [trl, event] = feval(cfg.trialfun, cfg); Error in preprocessing (line 35) cfg = ft_definetrial(cfg);
Robert Oostenveld - 2017-06-13 07:43:31 +0200
I am not sure why the current solution in the two pieces of code looks so different, probably because they were implemented by different people at different times. Could you try whether the same code as used in ft_read_event can be applied here?
Karen Dijkstra - 2017-06-13 14:14:49 +0200
If I apply the code from ft_read_events, the line 349 sdata = bitand(int32(sdata), 2^24-1); does not give the same result as: read_trigger line 93-103 signbit = find(dat < 0); % change type to double (otherwise bitcmp will fail) dat = double(dat); % make number positive and preserve bits 0-22 dat(signbit) = bitcmp(abs(dat(signbit))-1,'uint32');% bitcmp(abs(dat(signbit))-1,32); % apparently the 24 bits are still shifted by one byte dat(signbit) = bitshift(dat(signbit),-8); % re-insert the sign bit on its original location, i.e. bit24 dat(signbit) = dat(signbit)+(2^(24-1)); % typecast the data to ensure that the status channel is represented in 32 bits dat = uint32(dat); And therefore the triggers that are computed in line 366 of ft_read_events are then incorrect. The bitcmp in the else portion of ft_read_events (line 354): bitcmp(abs(sdata(bit24i))-1,24); is called with 24, rather than 32 used to call bitcmp in read_trigger line 97, so I suppose this might reflect a difference between biosemi .gdf and .bdf files?
Robert Oostenveld - 2017-06-13 18:31:46 +0200
I don't think that gdf is a biosemi format, it is a generic format. The code that is in ft_read_event is only there to support the specific case that biosemi data (which is 24 bit by default) gets stored in a gdf file. Of those 24 bits, the upper (most significant) bits are used for battery status and such, and not for triggers. Only the lower 16 bits correspond to triggers. How many bits do you have in the Status channel in the GDF file?
Karen Dijkstra - 2017-06-16 10:50:36 +0200
I'm not sure how I would tell. For context, I'm in the BCI group at the DCC. We use biosemi hardware and I think in the past experiments used to be saved to .bdf files, but nowadays it's all .gdf. I've uploaded a .mat file with the status_channel and correct trigger information for both a .gdf file from my current experiment and a .bdf from an older experiment in our group. For both, it contains the header information, the 'raw' status channel as read by fieldtrip and a trigger channel computed with either the method in read_trigger (for the .gdf; lines 93-110), or ft_read_events (for the .bdf; lines 347-366). This results in the correct triggers for both cases, as far as I can tell. You can find it here: https://surfdrive.surf.nl/files/index.php/s/IXMAr3Am4Dc8faB I talked to Jason to see if he knows why it is implemented differently for biosemi .gdf files, but it was also not clear to him.
Robert Oostenveld - 2017-06-19 09:20:18 +0200
Hi Karen, I think the DCC is the only one storing Biosemi data in the GDF format. I suggest you follow the instructions here http://www.fieldtriptoolbox.org/development/git and implement the required changes yourself. You can then send these changes as a "pull request". best Robert
Karen Dijkstra - 2017-06-26 11:12:44 +0200
Thanks Robert, I've addressed the issue and created a pull-request. Best, Karen
Robert Oostenveld - 2017-06-27 16:34:12 +0200
I merged https://github.com/fieldtrip/fieldtrip/pull/467
Robert Oostenveld - 2019-08-10 12:35:44 +0200
This closes a whole series of bugs that have been resolved (either FIXED/WONTFIX/INVALID) for quite some time. If you disagree, please file a new issue on https://github.com/fieldtrip/fieldtrip/issues.