Back to the main page.
Bug 629 - implementation problems with epoched egi_mff format
| Status | CLOSED WORKSFORME |
| Reported | 2011-05-04 09:54:00 +0200 |
| Modified | 2012-04-11 16:48:43 +0200 |
| Product: | FieldTrip |
| Component: | fileio |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P1 normal |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Robert Oostenveld - 2011-05-04 09:54:16 +0200
Ik heb een interessant gevalletje waar ik tegenaan loop met mijn fijne ge-epochte egi_mff data, maar wat misschien algemene FieldTrip aanname bloot legt die niet helemaal ok is...? Ik heb data met twee epochs, tussen die epochs is de recording "gepauzeerd" en mist er dus data Epoch 1 loopt van sample 1 tot 1202, epoch 2 loopt van sample 1203 tot endsample. Tussen de epochs zit ongeveer 600 ms dataverlies. Om een tijdsas te krijgen voor het tweede epoch die de tijd weergeeft ten opzichte van het begin van de recording, moet ik een offset kiezen die 1202 samples is PLUS de 600 verloren samples. Dat heb ik nu zo geimplementeerd, werkt allemaal prachtig. Is ook erg practisch, aangezien de events niet in samples gedocumenteerd worden door EGI, maar in absolute tijd (kloktijd). Als is dus de events wil vertalen naar een sample nummer dan MOET ik weten hoeveel tijd er tussen de epochs zit. Heb ik ook allemaal geimplementeerd zo, werkt perfect. Maar.... als ik alleen het tweede epoch inlees, met dus een tijdsas die begint op 1802 ms, en checkdata vervolgens van mijn tijdsas weer een offset gaat maken, dan is die offset dus niet correct in samples. Met het gevolg dat als ik iets selecteer in de databrowser, het rode blok dat de geselecteerde data weergeeft dan 600 samples (=ms in mijn geval) opschuift, zo kwam ik achter dit probleem. Het komt er dus op neer dat er in FIeldTrip geen manier is om tijd (zoals weergegeven op de tijdsas) los te koppelen van sample-nummer. Dit wordt alleen problematisch bij semi-continue data (met epochs dus). (voor zover ik weet dan, misschien ben ik gewoon niet op de hoogte van een handige truc). Ben benieuwd naar jullie gedachten hierover.
Robert Oostenveld - 2011-05-04 11:00:10 +0200
>> ft_read_header('p05_test') reading xml files to obtain header info... ??? Error using ==> ft_read_header at 687 Fs and nSamples should be the same in all signals
Robert Oostenveld - 2012-03-11 12:21:44 +0100
I suspect this bug to be resolved by now, with all changes to the egi_mff implementation. I was not able to find a dataset p05_test, but the following works now datadir = '/Volumes/Data/roboos/data/dataformat/testdata/egi/egi_mff Ingrid'; cd(datadir); dataset = 'pilot05_test 20110120 1433.mff'; hdr = ft_read_header(dataset); event = ft_read_event(dataset); The pilot05_test dataset is ~330MB, so I won't put that on home common. I have added the test_bug629 script to svn. @Ingrid: If you disagree, please reopen the bug and provide more details.