You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I stumbled across something in tools.dewow which I believe is a bug (or if it is intended behavior, I do not understand the reasoning behind it).
Dewow removes a moving average from a trace. For the purposes of this example, assume that one trace has 300 samples and the window size for dewow is set to 101. For each sample in the trace, dewow calculates the average of the 101 samples around it (50 in both directions) and subtracts that average from the sample. At least that is how I understood the function to work.
But there is a problem for the first and last window/2 samples (in this example, the first and last 50 samples) in each trace: the averaging window would extend beyond the available samples.
The usual solution I am aware of is to shrink one side of the window to keep it contained within the trace samples. Keeping with this example for sample number 20, the window should cover samples -30 to 70. Since not all these samples exist, a smaller window from samples 0 to 70 is used instead.
Here is a very simple example how this would look like in Matlab/Octave:
However, GPRPy does it differently: For the first window/2 samples, is always uses the window from 0 to window/2. This means even for sample 49, which could arguably use a window from 0 to 99, dewow is still just subtracting the average from 0 to 50.
A similar example with GPRPy therefore gives a different result:
# For the first few samples, it will always be the same
This seems weirdly different to other moving average implementations I am aware of. If this is indeed not a bug, what was the reason for this implementation?
The same issue just along the other dimension is probably also present in tools.remMeanTrace (just by looking at the code, I did not test that yet).
The text was updated successfully, but these errors were encountered:
I stumbled across something in tools.dewow which I believe is a bug (or if it is intended behavior, I do not understand the reasoning behind it).
Dewow removes a moving average from a trace. For the purposes of this example, assume that one trace has 300 samples and the window size for dewow is set to 101. For each sample in the trace, dewow calculates the average of the 101 samples around it (50 in both directions) and subtracts that average from the sample. At least that is how I understood the function to work.
But there is a problem for the first and last window/2 samples (in this example, the first and last 50 samples) in each trace: the averaging window would extend beyond the available samples.
The usual solution I am aware of is to shrink one side of the window to keep it contained within the trace samples. Keeping with this example for sample number 20, the window should cover samples -30 to 70. Since not all these samples exist, a smaller window from samples 0 to 70 is used instead.
Here is a very simple example how this would look like in Matlab/Octave:
However, GPRPy does it differently: For the first window/2 samples, is always uses the window from 0 to window/2. This means even for sample 49, which could arguably use a window from 0 to 99, dewow is still just subtracting the average from 0 to 50.
A similar example with GPRPy therefore gives a different result:
There is a comment in there that makes me think that this might actually be the intended behavior instead of a bug:
GPRPy/gprpy/toolbox/gprpyTools.py
Line 71 in 69609ea
This seems weirdly different to other moving average implementations I am aware of. If this is indeed not a bug, what was the reason for this implementation?
The same issue just along the other dimension is probably also present in tools.remMeanTrace (just by looking at the code, I did not test that yet).
The text was updated successfully, but these errors were encountered: