Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom MFF event field information not usable in Fieldtrip #15

Open
arnodelorme opened this issue Oct 11, 2019 · 11 comments
Open

Custom MFF event field information not usable in Fieldtrip #15

arnodelorme opened this issue Oct 11, 2019 · 11 comments
Labels
enhancement New feature or request

Comments

@arnodelorme
Copy link
Owner

When single-trial mff data is read by the v3 code, the cell names seem to be discarded. While I can see them in the event data and the .orig branch of the header, they are no longer distinguishable from other events in the trials. I’ve worked out a possible method for deducing the original cell name from the event information but it relies on making the assumption that the hdr.orig.epoch.eventlabel field never contains anything other than the cell name. Can I make that assumption? If not, would it be possible to add in some kind of marker that reliably indicates the cell name?

@arnodelorme
Copy link
Owner Author

I understood about the .type field. It was just a suggestion of how the problem might be solved. Nonetheless, the concern about mffmatlabio not providing the cell label information stands. Before we talk about possible solutions, let’s see if we can agree there is a problem. Knowing the label of a segment is critical information. This isn’t a minor issue from the standpoint of the user. Can you explain why you don’t see this as being a problem?

For example, in an oddball experiment you might have “target” and “standard”.
or if you were being more complicated, they might be “target-correct”, “target-error”, “standard-correct”, and “standard-error”

@arnodelorme
Copy link
Owner Author

arnodelorme commented Oct 11, 2019

My personal understanding is that all the event information is in the imported dataset. This is true for EEGLAB and also for Fieldtrip in the hdr.orig.epoch.eventlabel field. I am assuming you have found a workaround Joe but if not let me know.

Pending Joe response to make sure the problem is solved and close.

@jdien07
Copy link

jdien07 commented Oct 12, 2019

Hi Arno. I appreciate your looking into this. I'm afraid that this problem is not solved. Let me try again. The problem is that while the raw information is in the events field, its nature and location are entirely experiment-specific. There is no way for another user or another program to be able to consistently extract the needed information without detailed instructions from the original researcher. Likewise the original researcher would have to customize their own script or manually instruct the program in how to obtain the cell information from a given file.

My impression is that NetStation does not have this problem when reading mff files because the mff file format has a dedicated field that lists the cell name for each segment that is generated when NetStation segments the data. Unfortunately the current mffmatlabio code seems to ignore this information and does not make it available to the user. I cannot imagine that it would take more than fifteen minutes to figure out where this information is stored in the mff files and to make it available in the mffmatlabio output.

At any rate, the current code leaves me in the unacceptable position as a software developer of EP Toolkit of having to explain to users that the reason the EP Toolkit is not reading their mff files correctly is due to mffmatlabio rather than my own code. Or alternatively telling users that they have to program their own script to decode the files. I presume eeglab users have the same problem, whether or not you are hearing from them. I can certainly point some aggrieved users your way if that would be helpful. Ultimately it is up to EGI how user-friendly they want to make this process and up to yourself to tell them how much adding the support would cost them.

@arnodelorme
Copy link
Owner Author

Hi Joe, OK, we are moving forward. Would you mind to share a data file and indicate which information you would want to see and that is currently not available to you. Thank you - Arno

@jdien07
Copy link

jdien07 commented Oct 12, 2019 via email

@arnodelorme
Copy link
Owner Author

Discussion by email revealed that Joe uses the Fieldtrip version which does not have the option to import custom MFF fields into as types. The EEGLAB function has a wrapper and a GUI that allow users to choose which field to import for types.

The problem is that the Fieldtrip function does not accept such parameter. What I propose is to change ft_read_event and add a parameter 'typefield' that would then be passed on to the function mff_fileio_read_event. Robert @robertoostenveld, please approve and I can make the change and submit a pull request to FileIO/Fieldtrip. This is an important deal for users of the MFF format.

@arnodelorme arnodelorme changed the title Cell names discarded Custom field information not usable in Fieldtrip Dec 31, 2019
@arnodelorme arnodelorme changed the title Custom field information not usable in Fieldtrip Custom MFF event field information not usable in Fieldtrip Dec 31, 2019
@jdien07
Copy link

jdien07 commented Jan 13, 2020 via email

@arnodelorme
Copy link
Owner Author

arnodelorme commented Jan 13, 2020 via email

@jdien07
Copy link

jdien07 commented Jan 14, 2020 via email

@robertoostenveld
Copy link

... when using Fieldtrip it is not possible to choose which MMF field should be used for Fieldtrip event values

Might this mean that ft_read_event should be improved? As long as it fits into the event structure, i.e. type/value/sample/duration/offset and optionally timestamp, it should work fine. Replicating events (under different "types") is also fine, that is what we also do for other data types.

@jdien07
Copy link

jdien07 commented Jan 14, 2020 via email

@arnodelorme arnodelorme added the enhancement New feature or request label Oct 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants