MEG empty-room sessions & date shifting

[marc.lal...@mcgill.ca]

Hi,

(tl;dr : How would you deal with emtpy-room recordings when shifting dates on a per-subject basis in a large dataset?)

It just occurred to me that with a large MEG dataset, having all the empty room recordings under a single emptyroom subject may lead to complications when date shifting. The rationale was to be able to match subjects with the closest empty room session by date. But with a per-subject date shifting scheme, the recommended empty-room session naming as dates can become confusing and can also lead to "collisions" (two separate sessions being shifted to the same date). 

So I was wondering what others thought about this issue and how to deal with it.

In my present case, we have hundreds of subjects, some with multiple sessions. Even with a non-random date shifting approach, say increment the resulting shifted date by 1 day for each subject (sub-1 = Jan 1st, sub-2 = Jan 2nd, etc), I would end up with unwanted collisions on subsequent sessions - and we need to keep the relative session dates intact.  

So I have to deviate from the recommendation, and I'm not sure what's the best approach. Some ideas I had:

1. Add the time to the empty-room sessions (ses-yyyyMMDDThhmm).

2. Use a single fixed dataset-wide date shift. Not as "secure".

3. Move the empty-room recordings to the subject folders. 

I like 3 in the case where there's a 1-to-1 correspondence between subject sessions and empty-room recordings.  It's simple and makes sense even with date shifting.  If there isn't an empty-room on each day however, then the "date as session id" rationale breaks down with per-subject shifting.  It becomes complicated and requires duplication if we want to maintain the relative dates between subject and empty-room.  So this basically makes it again 1-to-1 and might as well just put them in the subject folders... Otherwise it's rather messy and we have to rely entirely on the AssociatedEmptyRoom field of each subject's MEG recordings anyway.  

Sorry for the long post.  A lot of this was possibly discussed when creating MEG-BIDS, but I didn't really find much on the topic.  Looking forward to ideas and comments.

Cheers,

Marc

[Robert Oostenveld]

Hi Marc,

This was indeed discussed while drafting MEG-BIDS. Two (lab or centre-specific) common practices were identified, or actually three: 

1 - one daily empty room scan

2 - an empty room scan per subject/session

3 - no empty room scans (or not commonly done)

At the Donders we do mainly do “3”, and therefore If I were to advise local people on their empty room scans, that would look more like “2” and therefore I would represent those as task-noise (*) within the subject/session meg session. Whereas in a centre/lab where “1" is the common strategy, that is less efficient, especially if you consider that all data ends up in a common shared archive. Perhaps also relevant is that at the Donders we store/archive the data with access restrictions per project and not in a commonly accessible archive for everyone, so that might also bias me here. 

When storing it as task-noise under the subject, you don’t really need to explain how that works: there is a clear implicit link. If you store it under sub-noise at the top level the link needs to be explicit. I suspect that the text at https://bids-specification.readthedocs.io/en/stable/04-modality-specific-files/02-magnetoencephalography.html#empty-room-meg-recordings mainly aims at clarifying how “1” is to be done, although it mixes it a bit with “2”. And by choosing dates it did not consider GDPR/privacy issues. 

If the empty room scans don’t take up too much space compared to the scans of interest, I would opt for (mental) simplicity rather than (storage) efficiency, and hence put it as task-noise along with the subject data, thereby possibly replicating it. So I would deviate from the recommentation. And I might actually still choose to use "task-emptyroom” anyway (see *).  

best

Robert

PS (*) initially I wrote “task-emptyroom”, but in the spec I read that one SHOULD use "task-noise”, hence I updated my email.

--
We are all colleagues working together to shape brain imaging for tomorrow, please be respectful, gracious, and patient with your fellow group members.
---
You received this message because you are subscribed to the Google Groups "bids-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bids-discussi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bids-discussion/737483cd-a8f7-495a-a491-72de3fdf95f9n%40googlegroups.com.

[Marc Lalancette]

Thanks Robert, this is very useful.  I now feel more confident in not respecting this BIDS recommendation. 

It should probably be amended a bit eventually to clarify when it is appropriate, and what other approach is recommended when it is not, as you explained here.

Cheers