I think we might want to add our own Camera class. This would simplify a few things in VisionServer, by pulling some of the code into one place. Eg Camera would "own" both the cscore.Camera and cscore.Sink instances (which are really tied together).

In the future, if we have different cameras on the robot, it would be easier to auto-sense which brand each one is.

Right now, we use a dictionary to hold a bunch of things about a contour, such as bounding box values, area, etc. This is done so that we don't calculate these values multiple times.

We should create a small class to handle this. For each value, it can see if it has it, if not calculate it, and then return it.

Also, the class can hold extra info such as the reason that contour was cut (eg see 2021 galactic_search).

The finders should have 1-2 new variables to support making visionserver.switch_mode() generic. Probably need things like:
finder.desired_camera (better variable name?)
finder.exposure

To support this, probably want the new genericfinder to have init variable for these, so they can be set on creation.

Good start on genericfinder. I think we can go a little further (sorry if you are already planning this):

• include a rotation. Parameter would be the image rotation parameter from OpenCV

Referring to this line in your startup script... pretty sure cscore should be able to get/set any property that uvcdynctrl can set, since they'll end up using the same API... getProperty on the sink followed by a set would do it. The cscore settings example shows how to do this.

Is that something you tried and it didn't work? Or just lack of documentation so you didn't realize the functionality was there?

Definitely low priority.

We should generally use the Python "logging" facility, although it might depend on what is done inside cscore and the related Python code.

logging let you have messages with different priority (debug, warning, etc) and you can set what is recorded. You can still send it to a file as needed.

One thing to remember though: if you have "logging.debug("foo")" everywhere, it will still slow down your code even if the "debug" messages are not saved. So low level logging code should still be used sparingly and/or commented out for "production".