Back to the main page.
Bug 2068 - Brainvision problems
| Status | CLOSED DUPLICATE |
| Reported | 2013-03-18 16:46:00 +0100 |
| Modified | 2019-08-10 12:03:28 +0200 |
| Product: | FieldTrip |
| Component: | fileio |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P3 normal |
| Assigned to: | Jim Herring |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Vladimir Litvak - 2013-03-18 16:46:39 +0100
Created attachment 439 Data plot Hi, Here is what I got on SPM list. You might want to get data example directly from the user. Vladimir ---------- Forwarded message ---------- From: Christoph Hofstetter <Christoph.Hofstetter@unige.ch> Date: Mon, Mar 18, 2013 at 3:03 PM Subject: [SPM] EEG convert for BrainVision format erroneous? To: SPM@jiscmail.ac.uk Dear SPM EEG and FieldTrip developers, I have noticed that from version SPM8 5236 on the conversion of BrainVision files gives weird results for me. The data set I am using are from intracranial recordings which I converted into BrainVision format using cartool. I used the convert (epoch, define trials) routine in SPM8 4667 and it worked well. However, when using the same approach in SPM8 5236 the results are different and many trials have very high peaks (see file attached). After looking a bit into this issue I found that replacing the following SPM8 5236 functions from the SPM8 4667 brought back the same results as using pure SPM8 4667: spm8_4667\external\fieldtrip\fileio\ft_read_data.m spm8_4667\external\fieldtrip\fileio\private\read_brainvision_vmrk.m spm8_4667\external\fieldtrip\fileio\private\read_brainvision_eeg.m spm8_4667\external\fieldtrip\fileio\private\read_brainvision_pos.m spm8_4667\external\fieldtrip\fileio\private\read_brainvision_vhdr.m It seems the problem is rather with FieldTrip than SPM, nevertheless I felt like sharing this with you. Please let me know if using the "old" fileio FieldTrip functions could be problematic. Many thanks in advance for any comments on how to best deal with this. Best regards, Christoph
Jim Herring - 2013-06-13 12:11:52 +0200
This bug is possibly related to bug2153. If all channels are read-in at once and the binary format of the source file is not 'uint16' the offsets are off by one-half of the intended offset. It could be that this has happened here as well and wrong segments are read-in. The problem should not have occurred when specific channels are read-in as opposed to reading-in all channels. I'll send Christoph an e-mail to check whether this is the same problem as in bug2153
Jim Herring - 2013-08-02 09:08:35 +0200
I have not heard back from Christoph so I'll assume this bug is related to bug2153 and I'll therefore mark this as a duplicate. *** This bug has been marked as a duplicate of bug 2153 ***