Separate publish and poll rates

[chataign]

Added output_rate parameter to control the output rate (ie. images processed and published) vs the camera poll rate (frame_rate). On most cameras the poll rate indirectly controls device properties such as exposure and affects the imagery. This change allows users to downsample the publication rate without affecting the quality of the imagery.

by default output_rate=frame_rate

[anqixu]

Regarding phenomenon: My original operating hypothesis was that if none of the camera's parameters were set to auto (e.g. no auto exposure, no auto gain, not auto white balance, no IR color correction), then the frame rate should not logically affect any of the other static parameter settings. Nevertheless, I just did some testing with ueyedemo using an UI-3251LE camera, and obtained slightly brighter frames using 2fps+50ms exposure settings compared to 14fps+50ms exposure settings. This result corroborates your statement, although I am very perplexed as to the cause of this discrepancy.

Regarding PR: Could you update the PR to adhere to standard indentation please (L1007, L1008, L1043)?

Also, it would be great to use a fixed time origin when computing time differences, so as to improve the accuracy of the desired output rate. To illustrate this:

PR's implementation: if (tk - t(k-1)) >= O then pub and update t_(k-1) <- t_k (where t_k is the time of frame k, and O is 1/output_rate) e.g.: poll rate = 10Hz, O=9Hz, resulting delay between frames=200ms (constant)

Proposed implementation: if (t_k - t_0)/O > n then pub and update n <- (t_k - t_0)/O (where t_0 is time of first frame after resume, and n is internal counter for expected output frame number) e.g.: poll rate = 10Hz, O=9Hz, resulting delay between frames will be variable, but converging to 1000/9 = 111.11ms on average

[chataign]

I made the change you suggested and as you said it does result in a more accurate output rate. Thank you for the feedback!