aces
[electrophysiology_browser] Effect of filters between chunks
Describe the bug In between chunks, there appears to be a gap, only visible when zoomed in. When applying filters, the gap becomes very visible, as the signals appear to diverge from the gap in a noticeable way. These filters should also be validated to determine if they are appropriate for more than one specific set of recording parameters.
@jeffersoncasimir to take an hour before Friday 11 am and see if the solution is easy, consult with @laemtl if needed.
The cause for the gap is identified and is due to an off-by-one error.
This line should be inclusively producing all equally distributed numbers within the interval, but never equals interval[1] since i / values.length is never 1.
The unexpected filter behaviour between chunks is caused by filters being applied to chunks discretely as opposed to interpreting all visible points as a continuous signal.
est 2-4 weeks to refactor the filter application ->
could interpolation solve it ?
LF and JC to touch base
These filters should also be validated to determine if they are appropriate for more than one specific set of recording parameters. This is because they were hard-coded in the original Open MNI Atlas (for that recording, w values from N.von Ellenrieder) and then brought into LORIS. Not relevant to all recordings.
un/related: #8892 will be in the 25.1 release (ideally), but not too related to this issue which will persist
break this down, seems we have the following options (consult w LF and bring possible plans to the Loris-EEG meeting when ready)
- remove all filters
- @jefferson what's a small/medium scope solution? e.g. limit filter options, pre-cache...
- solve with dynamic calculations across chunk boundaries in the browser - what's the perfomance
A solution has been implemented, with a PR coming soon, which performs the signal filter on all visible chunks, instead of chunks individually. This is achieved by concatenating them all into one chunk/signal and works similarly to how DC offset was implemented.
This has a performance cost by introducing technically redundant memoizations but there is a lot of room for improvement on that front, which is due for a revisit.
@jeffersoncasimir has a PR been sent and merged in the end? Should this be closed?
