processBIDS for MEG #232

ethanknights · 2021-02-25T15:23:23Z

ethanknights
Feb 25, 2021

Hi

I was trying to add an option to autoidentify BIDS meg data, to support:

aap.directory_conventions.rawdatadir = 'BIDSDir';
aap = aas_processBIDS(aap);

My approach so far was to define megimages (i.e. meg filepaths from spm_select()) in aa_engine/aas_processBIDS.m: Branch here
Note this is very basic (i.e. I'm not trying to add events, skip/order series etc).

But I get the impression I am going about this the wrong way - megimages etc. are used as input to aap = aas_addsubject():

if toAddData
    aap = aas_addsubject(aap,subjname,mriname,...
        'structural',structuralimages,...
        'functional',functionalimages,...
        'fieldmaps',fieldmapimages,...
        'diffusion',diffusionimages,...
        'specialseries',specialimages,...
        'meg',megimages); 
end

aas_addsubject.m expects MEG data in a 1x2 cell array (ie. mri and meg filenames).
Whereas input to aas_addsubject.m from processBIDS.m is a larger cell array whose number of columns is determined by all potential modalities e.g.:

varargin =
  1×12 cell array
  Columns 1 through 4
    {'structural'}    {0×0 cell}    {'functional'}    {0×0 cell}
  Columns 5 through 8
    {'fieldmaps'}    {0×0 cell}    {'diffusion'}    {0×0 cell}
  Columns 9 through 12
    {'specialseries'}    {0×0 cell}    {'meg'}    {1×1 cell}
	).

I guess I could make an ugly solution (e.g. if the meg filename cell ~isempty, then read those filenames for meg data) but that's not ideal.

I'll look again later, but wanted to ask if anyone could steer me at all?

tiborauer · 2021-02-25T16:01:33Z

tiborauer
Feb 25, 2021
Maintainer

Hi @ethanknights,

Some initial thoughts:

I suggest you re-forking your repo from the central repo or at least merge it into your one.
I am not sure whether you really want to further develop and support the CBU's MEG example, which has very limited functionality. I suggest you look at the more recent MEEG example, which is based on an open LEMON dataset, so anyone can run it, and it exploits a more advanced set of modules based on EEGLAB and FieldTrip. Of course, I also understand that your priority might be to maintain continuity with the CamCAN workflow, but even though you may consider migrating it to the new module-set. Apart from Rik's ICA-denoising, all other functionalities are covered; and the aamod_meeg_icclassification even offers similar functionality as implemented in ICLabel
Since my major update on M/EEG, we switched from "meg" to "meeg" in modulenames and filednames. Therefore, I suggest you keep that convention; especially if you plan to modify low-level functions, such as aas_addsubject. N.B.: The old aamod_meg* modules of the CamCAN workflow has not been renamed to avoid issues on your side, and because I have no intention to further support/develop them.

To answer your question

The data argument optionally has two items to support that MRI and MEEG data may come from different places (as has been the case at the CBU). The varargin is a variable set of arguments, which may or may not include pointers to data depending on the workflow. It seems from within the aas_addsubject function as a cell array, but when you actually call it (e.g. from aas_processBIDS), then the items are separate inputs. So if there is no, say, diffusion data, then you do not have to include them in the argument list.
I think it is a great idea to distinguish fMRI and MEEG. At the moment 'functional' argument in aas_addsubject refer to both. Therefore, I also support introducing a separate argument called 'meeg' (following the convention).

I am happy to have a call with you if you think it helps the communication.

0 replies

Navigation Menu

Uh oh!

processBIDS for MEG #232

Uh oh!

{{title}}

Uh oh!

Replies: 1 comment

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Select a reply

Uh oh!

Uh oh!

processBIDS for MEG #232

Uh oh!

ethanknights Feb 25, 2021

Replies: 1 comment

Uh oh!

Uh oh!

tiborauer Feb 25, 2021 Maintainer

ethanknights
Feb 25, 2021

tiborauer
Feb 25, 2021
Maintainer