As I’m developing a driver for a new imaging sensor, I have been looking at other drivers and see how they implemented all the modes. I successfully implemented 18 modes already, but I can’t seem to understand how to implement Region of Interest functionality.
I’ve been looking around and see that more sensors have a programmable ROI section or even multiple ROI sections like mine does. It allows you to set two coordinates to create a ROI. Unfortunately, it’s a subject I can’t find any information about regarding Video 4 Linux.
I’ve looked up information about sensors with available drivers, but these don’t seem to have any ROI functionality.
We have hardware engine to perform cropping. You can capture full-size frames and leverage the hardware engine to crop the ROI zone. Please refer to 12_camera_v4l2_cuda.
That’s rather unfortunate. By using the sensor’s ROI mode, a higher framerate can be achieved instead of cropping sections of a full frame.
Hopefully this function will be implemented in the future.
If you’re able to set the starting coordinates of the ROI in a custom control, then shouldn’t it also be possible to set the width and height of the ROI?
I believe I understand how I have to implement the ROI mode, but how do I make use of these custom settings? Do I have to start a video stream through a command with the desired settings?
The issue with changing the size of the image is that each sensor mode has a static width and height. So, every time you change the width and height you would need to change the sensor mode. If you wanted to support a few different ROI window sizes, you could implement separate modes for each one. For example, if you had a 1920x1080 image and wanted to support ROIs that are 1/2 and 1/4 of the image, you can do something like this in your device tree:
If you create v4l2 controls called roi_start_x and roi_start_y that set the starting coordinates, you can use the following terminal command to change the start position:
Hmm, my method (which I can not test at the moment) was to create a separate ROI function in the C file. Here the user can input the ROI parameters (they’re vaguely explained in the datasheet of the sensor, so I’m sure I have to change things in my code).
I added a custom entry in the tegracam_ctrl_ops struct that defines the custom ROI function.
The problem now is the device tree, but is it really necessary to include the active widths and heights?
Because in theory, the VMAX is fixed to the value used for all-pixel scan (in my case with a resolution of 1920x1200)