Confusing filter specification in EEG, MEG, iEEG

[sappelhoff]

Intro to the issue

We are currently having two temporal filter related fields in the electrophysiology specification:

• SoftwareFilters
• HardwareFilters

both fields have a description as follows (with slight adjustments), please focus on the specification of filters:

list of temporal software filters applied. Ideally key:value pairs of pre-applied software filters and their parameter values: e.g., {"Anti-aliasing filter": {"half-amplitude cutoff (Hz)": 500, "Roll-off": "6dB/Octave"}}. Write n/a if no software filters applied.

So we can always use a string "n/a".

Beyond that, the information is a bit confusing, as identified by @effigies in https://github.com/bids-standard/bids-specification/pull/322/files#r321275320.

We are asking for a list, which brings to mind an array of the following form:

{
    "myKey": ["val1", "val2", 45455.3, {"obj": 1}]
}

However, in the validator and our examples (e.g., starter kit), we are requiring an "object of objects" in the form:

{
    "HardwareFilters": {"HighpassFilter": {"CutoffFrequency": 0.1}}
}

questions

Should we:

1. stay with our current way to specify filters and simply clarify the language in the specification to drop the word "list", and use "object of objects" or similar?
2. change the way we specify filters to be a "list of objects" --> this would allow the benefit to intuitively specify the order of how filters were applied to the data
3. allow both and change validator and spec text accordingly

I am not a signal processing expert ... but as long as the order in which filters are applied is irrelevant (e.g., because they are linear operations), I am in favor of option 1.

[effigies]

Related: #322

[effigies]

I think either 1 or 2 is fine. I think having too much flexibility is a validation nightmare so I would recommend against 3. You already have the ability to have a string or an object with one entry. The question is whether multiple entries involve an object with multiple entries or a list of objects with one entry each.

I don't really have a dog in this fight, as I don't ever try to use *EG data. My inclination is that ordering is good to specify even when it isn't critically important. (Also that linear filters are mathematically exchangeable on real numbers, but floating point numbers are not reals, and error accumulates.)

[CPernet]

given #322 is this one resolved? ie use of a list

[effigies]

I don't think so. #322 punted on the issue, improving the docs, but not actually addressing whether we use a list of objects or a multi-entry object.

[CPernet]

I vote list of objects @sappelhoff @jasmainak @robertoostenveld any pref?

[robertoostenveld]

I vote list of objects.

[jasmainak]

Agreed! But please also update the validator.

On Fri 11 Oct 2019 at 09:45, Robert Oostenveld ***@***.***> wrote: I vote list of objects. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#339?email_source=notifications&email_token=ADY6FIVNV2QTEV4WLVNDYBDQOB7RJA5CNFSM4IZI2CQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBABNDY#issuecomment-541070991>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADY6FIULYKRDQVAN6QATXQTQOB7RJANCNFSM4IZI2CQQ> .

-- Sent from my iPhone

[sappelhoff]

For being pragmatic, I vote "object of objects" ... if the order is important, it can be specified with a custom key value pair inside the object. This would mean only a specification clarification within the text.

going the "list of objects" way will require:

• changing spec
• adjusting validator
• fixing existing bids-examples
• fixing examples on bids-starter kit
• fixing openneuro datasets
• acknowledging that several user datasets will now suddenly be invalid although they were valid before

[jasmainak]

On second thoughts, I agree with @sappelhoff . Backwards compatibility is important.

[CPernet]

Wow, yeh if that breaks so many things, and even if that's not as elegant, let's go object of objects then

…

-- Dr Cyril Pernet, Senior Academic Fellow Neuroimaging Sciences Centre for Clinical Brain Sciences Chancellor's Building, Room GU426D The University of Edinburgh 49 Little France Crescent Edinburgh BioQuarter EH16 4SB [email protected] tel: +44 (0)131 465 9530 http://www.sbirc.ed.ac.uk/cyril http://www.ed.ac.uk/edinburgh-imaging

________________________________ From: Stefan Appelhoff <[email protected]> Sent: 15 October 2019 09:29:33 To: bids-standard/bids-specification <[email protected]> Cc: PERNET Cyril <[email protected]>; Comment <[email protected]> Subject: Re: [bids-standard/bids-specification] Confusing filter specification in EEG, MEG, iEEG (#339) For being pragmatic, I vote "object of objects" ... if the order is important, it can be specified with a custom key value pair inside the object. This would mean only a specification clarification within the text. going the "list of objects" way will require: * changing spec * adjusting validator * fixing existing bids-examples * fixing examples on bids-starter kit * fixing openneuro datasets * acknowledging that several user datasets will now suddenly be invalid although they were valid before — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#339?email_source=notifications&email_token=ABENIDUUFQUUMBGLDTOO53TQOV5O3A5CNFSM4IZI2CQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBH4ZDI#issuecomment-542100621>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABENIDWOAMHZMO2ZEHGRQCDQOV5O3ANCNFSM4IZI2CQQ>. The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.