Back to the main page.

Bug 1661 - ft_databrowser: NaN-padding is now inconsistently applied both in the function, and by fetch_data

Reported 2012-08-17 14:55:00 +0200
Modified 2021-09-16 14:49:03 +0200
Product: FieldTrip
Component: plotting
Version: unspecified
Hardware: PC
Operating System: Windows
Importance: P3 normal
Assigned to: Roemer van der Meij
Depends on:
Blocks: 2314
See also:

Roemer van der Meij - 2012-08-17 14:55:26 +0200

In two cases, NaNs are appended to the data. 1) When zooming out further than the trial, or when you are at the end of your continuous-mode data-piece, NaNs are padded to zoom out further and to keep the current zoom level respectively. 2) When 'continous' = yes and you have multiple trials present, the data can have gaps between trials. NaNs are padded to be able to view it as continuous. In case 1, NaNs are padded inside ft_databrowser. This is done after prepoc, and purely for visual purposes. This means filtering is done on the non-padded data, and thus, can be done. In case 2, NaNs are padded by ft_fetch_data, and is done before preproc. This means no preproc is done at all, and an annoying warning is given (by fetch_data as well).

Jan-Mathijs Schoffelen - 2021-09-16 14:28:12 +0200

OK, long story short: on-the-fly preproc'ing of epoched data in the 'continuous' viewmode causes NaN related side effects (e.g. truncation of epochs due to filter edges). As a fix I could see a presence-of-nans conditional looping across the non-nan contiguous sub-segments. That's easy to implement at little extra computational time cost for the majority of the cases

Jan-Mathijs Schoffelen - 2021-09-16 14:48:52 +0200

The inconsistent handling is not addressed, yet case 2 is handled in a different way. Note that currently FT's preproc is not bypassed as soon as nans are detected, but the nans are handled gracefully, as far as possible. The relevant PR is