These are the "common derivatives" which lay out the foundation for other derivatives to build on. That being said, there is a lot of MRI stuff on top though.
I think we can wait with the implementation of this within MNE-BIDS at least until the PR is merged and a new release of BIDS is out (~2 to 3 weeks).
I'd prefer to wait a bit longer and see how the situation evolves ... but if it's important to you @dominikwelke I'd be happy to review a PR :)
yes, i'd also wait at least until the new BIDS is out.
it's not particularly important to me, atm. i just think it would be a nice and easy to implement feature, that could also simplify interaction with e.g. EEGLAB that has some standardized preprocessing pipelines.
i might end up writing something like this anyway, if so I'lld release a PR :)
does anyone here work w/ iEEG data and electrode localization that wants to work on simplifying the error-prone and tedious process?
Was looking for some collaborators w/ open-source experience to help kick off a few ideas I had after OHBM. Hoping to migrate a chat over email and video if someone is...
question re:bids on brainhack mattermost:
@agramfort I'm trying to bring ds248 in bids-examples in line with the spec. Some of the channels types are listed as MEGGRAD this needs to be MEGGRADPLANAR or MEGGRADAXIAL do you know off the top of your head which it should be?
@sappelhoff @jasmainak how would you name evoked data according to BIDS convention (anticipating derivatives):
/bids_root/sub-01/ses-01/meg/sub-01_ses-01_evoked.fifhence extending kind or rather
"The proc label is analogous to rec for MR and denotes a variant of a file that was a result of particular processing performed on the device. This is useful for files produced in particular by Elekta’s MaxFilter (e.g. sss, tsss, trans, quat, mc, etc.), which some installations impose to be run on raw data because of active shielding software corrections before the MEG data can actually be exploited."
I think it makes sense to release mne-bids shortly after MNE-Python (which is scheduled for September 15)
--> then we have some short time to make sure mne bids 0.5 works well with the latest MNE release (0.21) ... and perhaps even one or two releases prior to that.
And then for 0.6.dev we can (if necessary at all) adopt MNE
master features again
That said, I think it'd be a good idea to start tagging issues and PRs that we want to have finished prior to 0.5 release.
@hoechenberger do you want to make a release this time around? I wrote pretty extensive docs on what to consider, so it should be fairly easy :)
write_raw_bidsthe procedure failed due to some issues with the events in my file (ValueError: You have 1 events shorter than the shortest_event.). I know this has nothing to do with mne-bids and should not happen in the first place. In mne-python I can fix this issue and work with the raw file alright, but it seems there is currently no way to fix/bypass the issue with mne-bids. So, my question would be, whether it would make sense/was possible, to increase the flexibility of
write_raw_bidssomehow, so that users have the opportunity to do something about issues inside their raw files? If not, I would have to temporarily change my local installation of mne-bids to allow this specific file to be read.