[FIX] Add SoftwareFilters to EEG sidecar example

[Remi-Gau]

Related to issue #321. Closes #321

Just a small addition to make eeg json side car example a valid one according to the specs.

[effigies]

The spec says "List of temporal software filters applied.", and this is an object that does not have an inherent ordering. If ordering is important, than this should probably be lists of single-element objects. If the ordering is not important, then it can be kept as is, but I would suggest updating the language of the spec to change from "list", which has a meaning in JSON.

As an example of a list of single-element objects:

  "SoftwareFilters": [
    {
      "Anti-aliasing filter": {
        "half-amplitude cutoff (Hz)": 500,
        "Roll-off": "6dB/Octave"
      }
    },
    {
      "Other filter": {
        "param1": "val1",
        "param2": "val2"
      }
    }
  ],

[sappelhoff]

So far, we have always dealt with objects, see also the schema implemented in the validator

and the examples in the starter-kit

A change of language in the spec is thus warranted IMO.

[effigies]

And order does not matter? Because software that parses JSON is not obligated to provide key-value pairs in any particular order, or preserve it when copying metadata forward to derivatives.

[sappelhoff]

This was never discussed in detail. I think in most use cases the order of filters (order in which they are applied after one another) is irrelevant - but in cases where it IS relevant, perhaps a keyword "order": "first" ... could be used? --> This would however be more easily solved with a list that has a naturally defined order, as you mentioned above Chris.

cc @robertoostenveld for some third opinion

[sappelhoff]

tagging more EEG folks: Please read this thread and leave your opinion on how we want to format filters in BIDS. Estimated time: <5minutes @bids-standard/raw-electrophys

[sappelhoff]

1. As far as I understand it, JavaScript Arrays are a bit like Python lists.
2. yes, the idea is that:
   1. either we allow an object ("SoftwareFilters") which contains one object per filter used .... and these filter objects then have key value pairs for their parameters
   2. OR we allow a list ("SoftwareFilters"), which is empty if None were applied ... or it contains objects, each of which is corresponding to a filter. Then the order of objects in the list corresponds to the order in which the respective filters were applied to the data

The second of the ideas above allows for an easy way to specify the order in which filters were used. ... the first of the ideas is how it's currently implemented in the validator

I think a practical solution would be to allow both variants. and IF the order of filters is relevant, then we RECOMMEND that users take the list of objects (solution 2) rather than the object of objects (solution 1) way.

Opinions?

[effigies]

@jasmainak

1. https://json.org/

JSON is built on two structures:

• A collection of name/value pairs. In various languages, this is realized as an object, record, struct, dictionary, hash table, keyed list, or associative array.
• An ordered list of values. In most languages, this is realized as an array, vector, list, or sequence.

Their grammar does refer to the structure as an array, so I suppose there's some ambiguity as to whether "list" is a reserved word in that sense. But it does have a common computer-science meaning, which is referenced above.

2. Sure.

---

To the point, though: does ordering ever matter? If it does, then I would suggest that an actual list (or array) be used. If it does not, then we can refer to it as an object.

[sappelhoff]

To the point, though: does ordering ever matter? If it does, then I would suggest that an actual list (or array) be used. If it does not, then we can refer to it as an object.

this is a signal processing question, as long as the filters are linear, then the order of application of the filters should not matter.

I am not sure about non-linear filters though.

[robertoostenveld]

The example of an anti-aliasing filter without subsequent resampling does not make much sense for most acquisition systems. An anti aliasing filter would typically be implemented in hardware. I would prefer a better (i.e. a more common and more easily recognized) example.

[sappelhoff]

Example:

The Brain Products BrainAmp always samples the data at 5kHz, applying a 1kHz anti-aliasing filter. However, in the recording software settings, you can also select lower sampling rates (e.g., 1kHz).

--> If that is done, the software applies a "software filter" and downsamples the data (online) ... before saving it to disk.

This is reflected in the present example, which I find good :-)

If you prefer a better example, could you perhaps suggest one?

[jasmainak]

The link for circle CI artifacts is missing. Did you branch from latest master @Remi-Gau ?

[Remi-Gau]

This was branched from the latest at the time so 4c39c10fb a week ago or so.
Want me to rebase from the latest things?

[sappelhoff]

@Remi-Gau this is the PR that Mainak is referring to #315 ... everything after this PR will have an additional "check" which is a bogus check that acts as a convenient link directly from GitHub to the built html pages on CircleCi.

So yes, a rebase would be nice!

[Remi-Gau]

hum... If there is a way to do a rebase and not force-push to the remote branch, I did not find it.

[effigies]

If there is a way to do a rebase and not force-push to the remote branch, I did not find it.

There is not. Anything that's not a fast-forward merge needs to be force-pushed.

[sappelhoff]

@effigies I suggest to merge this PR, because it is improving the status quo.

We can open a separate issue where we can discuss the wording of the SoftwareFilters field, and whether it should be an array of objects, or an object of objects, or both permissible. See #339

[robertoostenveld]

If it were up to me, BIDS for raw electrophysiology should not have software filters at all, since the data would be stored/archived/shared in the original form. But in practice, shared data might be minimally processed, so I see the justification for this. I don't care too much about the format, but supporting both a single string and a list sound nice to the researchers. Both soft and hardware filters should be kept consistent between the different electrophys modalities.

[effigies]

Sure, we can merge this as an improvement.