OpenCVVideoCapture implementation

[m-decoster]

Describe your changes

Implement OpenCVVideoCapture based on the proposal in #81

Checklist

• Have you modified the changelog?
• If you made changes to the hardware interfaces, have you tested them using the manual tests?

[Victorlouisdg]

Looks good, and seems to work perfectly with my webcam, a Zed2i as USB webcam, and an mp4 video file.

Some remarks:

• I would rename generic_opencv/generic_opencv.py to opencv_videocapture/opencv_videocapture.py
• OpenCV opens all video streams at 640x480 by default. I've found you can use the command below to find the supported resolutions and framerates. However it would be a nice-to-have to open at maximum resolution by default, but that doesn't seem super trivial to implement, so we can skip that for now.
• When using video files, we raise a Runtime error at the end. Maybe we want to explore the use cases of video files further and have a different ("softer") way to signal the end of a stream. I'm thinking e.g. running a keypoint detector on a prerecorded video and saving the result to a video as well.
• When you supply a path to a non-existent video file, we raise RuntimeError("Cannot open camera"). We could improve that message but it's not crucial.

Command to list available resolutions and framerates of a camera:

 v4l2-ctl -d /dev/video0 --list-formats-ext

[m-decoster]

I would rename generic_opencv/generic_opencv.py to opencv_videocapture/opencv_videocapture.py

Okay, I was unsure about the filename.

OpenCV opens all video streams at 640x480 by default. I've found you can use the command below to find the supported resolutions and framerates. However it would be a nice-to-have to open at maximum resolution by default, but that doesn't seem super trivial to implement, so we can skip that for now.

We can do the same as with the Realsense and Zed cameras: allow the user to select a desired resolution and FPS.

capture.set(cv2.CAP_PROP_FRAME_WIDTH, width)
capture.set(cv2.CAP_PROP_FRAME_HEIGHT, height)
capture.set(cv2.CAP_PROP_FPS, fps)

When using video files, we raise a Runtime error at the end. Maybe we want to explore the use cases of video files further and have a different ("softer") way to signal the end of a stream. I'm thinking e.g. running a keypoint detector on a prerecorded video and saving the result to a video as well.

We could add a property that indicates whether the camera still has frames to produce?

When you supply a path to a non-existent video file, we raise RuntimeError("Cannot open camera"). We could improve that message but it's not crucial.

This should be fairly simple to do

[m-decoster]

@Victorlouisdg When setting the desired resolution for a webcam, OpenCV silently selects the closest match supported by the webcam. Do we want to log a warning or raise an error in this case?

[Victorlouisdg]

OpenCV silently selects the closest match supported by the webcam. Do we want to log a warning or raise an error in this case?

I guess we can use it with this behavior until it causes problems.

We could add a property that indicates whether the camera still has frames to produce?

Maybe we could just return None to signal that there are not more images, e.g:

camera = OpenCVVideoCapture(("video.mp4",))

while True:
    image = camera.get_rgb_image()
    if image == None:
        break
    cv2.imwrite(image, "image.png")

[Victorlouisdg]

I discussed with Thomas and as we don't want to change the RGBCamera interface, we would keep the exception when calling get_rgb_image(), so usage would be like so:

while True:
    try:
        image = camera.get_rgb_image()
    except EOFError:
        break
    cv2.imwrite(image, "image.png")

It's a bit ugly, but you only need to add that to scripts where you want to support using video files as RGBCamera, which will probably be quite rare anyways.