Closed DevonRD closed 3 months ago
Is this the place we are making this false assumption? Do we not do this elsewhere in the frontend that needs to be fixed
Is this the place we are making this false assumption? Do we not do this elsewhere in the frontend that needs to be fixed
It seems Gaussian blur, filter tightness, and contour ratio all use 0.1 step as well. I imagine the same queue buildup issue will occur with those, depending on the processing speed of the events. However, I believe decimal points are used in the backend so we can't simply restrict the setting without side effects like we can with exposure
Is this the place we are making this false assumption? Do we not do this elsewhere in the frontend that needs to be fixed
However, I did just notice that object detection has 0.01 step for confidence, contour area, and contour ratio, which could send an absurd number of data change events to the queue if sliding manually (depending on the frequency that vue triggers the update listener on the slider). This could also nuke the camera stream and the backend processing until the queue catches up or PhotonVision is restarted
The big difference here is that when you set camera properties like exposure, the backend sets the camera exposure through cscore in that main HTTP server thread. Other property changes are just accomplished through reflection and happen quickly.
This is a bandaid over a proper implantation of asynchronously changing pipeline parameters (including software only things like confidence, and hardware things like camera brightness)
The big difference here is that when you set camera properties like exposure, the backend sets the camera exposure through cscore in that main HTTP server thread. Other property changes are just accomplished through reflection and happen quickly.
This is a bandaid over a proper implantation of asynchronously changing pipeline parameters (including software only things like confidence, and hardware things like camera brightness)
Right, I am aware, but it at least mitigates the existing problem by doing earlier what would be done anyway, right? Maybe it would be better to step to 0.5 to avoid any exposure value misses in ov2311 while keeping backend updates minimal.
Potentially mitigates 1182, see comment there for more details. Exposure is rounded in the backend anyway, so there is no reason to send several update events for ultimately the same setting.