in lines 73-77 is linear extrapolation between 2 last points.
in lines 83-103 new point is calculated to store in last_output and at end
new calculated point is set as result.
this behave produces jitering.
here is example (in 1D):
After pushing new input from camera new point is calculated. So let say at
start in last_output we have:
T0:
last_output[0][0] = 20;
last_output[1][0] = 10;
last_output[2][0] = ... irrelevante -- will be relased.
T1: we get new input from cam, let say new calculated point will be 30
so at end we will in last_output have:
last_output[0][0] = 30;
last_output[1][0] = 20;
last_output[2][0] = 10;
and as result will be returned same value as last_output[0][0], So result
is =30
T2: we get next filtered value, but without new Cam input, so result is
from lines 73-77 and is linear interpolation between last_output[1] and
last_output[0].
If d is half of frame_delta when c=0.5 and result is =25.
So if from Cam we get more inputs than we process in filter, it will work
fine, but if we have "slow" input, filter will produce jittering.
Whole thing become more problematic if from cam we get input in various
intervals.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So if from Cam we get more inputs than we process in filter, it will work
fine, but if we have "slow" input, filter will produce jittering.
I don't think that less than 30 Hz operation is feasible at all.
In the case of face tracking, it'll lose track for the reason face tracking's typically done, at least in the cases of FaceAPI and HT.
In the case of other input sources, it'll produce more motion blur and hence, inaccurate results either way.
As for different time deltas, it's hard to ever support auto-exposure, which seems to be the only (?) reasonable cause of variance in input timing.
If you have a solution to the issue you raised, please state it. Also note that definite majority of the users of the software have at least 30Hz, lots have 60-180. It's hard for me to change the way the filter works because in an edge case it performs somewhat worse than desired...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In source code:
https://github.com/opentrack/opentrack/blob/master/ftnoir_filter_accela/ftnoir_filter_accela.cpp
in lines 73-77 is linear extrapolation between 2 last points.
in lines 83-103 new point is calculated to store in last_output and at end
new calculated point is set as result.
this behave produces jitering.
here is example (in 1D):
After pushing new input from camera new point is calculated. So let say at
start in last_output we have:
T0:
last_output[0][0] = 20;
last_output[1][0] = 10;
last_output[2][0] = ... irrelevante -- will be relased.
T1: we get new input from cam, let say new calculated point will be 30
so at end we will in last_output have:
last_output[0][0] = 30;
last_output[1][0] = 20;
last_output[2][0] = 10;
and as result will be returned same value as last_output[0][0], So result
is =30
T2: we get next filtered value, but without new Cam input, so result is
from lines 73-77 and is linear interpolation between last_output[1] and
last_output[0].
If d is half of frame_delta when c=0.5 and result is =25.
So if from Cam we get more inputs than we process in filter, it will work
fine, but if we have "slow" input, filter will produce jittering.
Whole thing become more problematic if from cam we get input in various
intervals.
I don't think that less than 30 Hz operation is feasible at all.
In the case of face tracking, it'll lose track for the reason face tracking's typically done, at least in the cases of FaceAPI and HT.
In the case of other input sources, it'll produce more motion blur and hence, inaccurate results either way.
As for different time deltas, it's hard to ever support auto-exposure, which seems to be the only (?) reasonable cause of variance in input timing.
If you have a solution to the issue you raised, please state it. Also note that definite majority of the users of the software have at least 30Hz, lots have 60-180. It's hard for me to change the way the filter works because in an edge case it performs somewhat worse than desired...