Back to the main page.
Bug 1661 - ft_databrowser: NaN-padding is now inconsistently applied both in the function, and by fetch_data
| Status | CLOSED FIXED |
| 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 |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | 2314 |
| See also: | http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=3238 |
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