Asa

Any updates on this?

Also, I just checked the 3d model for this and it is not accurate. It only has 3 ports.

What about the design files for this board? The PCB folder hasn't been updated in several years.

State estimation systems like to have nice hardware synchronization. If you can trigger the imu at multiples of the images this would help build these kind of tightly coupled systems.

Is the timing between the camera triggers and the triggering of reads from internal imu etc fixed in this case? What manages the triggering of the first camera(which drives sync to all the other camers) relative to imu reads?

I am happy do do whatever is necessary as a manual task as long there is some kind of api exposed.Any hooks for that I can look at yet?

Is the sensor crop pipeline different in RVC3? Are we able to have more of this kind of control there?

Understood, albeit dissappointing. You would improve the performance of all of the cameras if you can support this as you are currently exposing and reading out a third more pixels than you need to. If you are center cropping 4k you are throwing away even more at around 4mp of data every frame. This has to limit the aggregate isp performance of all of your systems, increases the jello effect etc. As for this affecting a large commitment of devices, you may not be too far off. At any rate, I would love to track this issue. Perhaps this is an area that will open up in the SDK over time?

Timmm these are "fractions of whole width and height" I believe.

I am looking for something that would be before isp. I am trying for the lowest latency, closest to the metal experience. Reducing the width of the readout ROI on the sensor should let you reduce the rolling shutter artifacting by a decent amount as well(less pixels to read out each line at the same clock rate = less overall time between rows). I would like to ideally set this up as my own SensorResolution (THE_12_MP_CENTER_CROP_1_TO_1?). Is this possible? I know the Sony sensors support this ROI type of setup. Being able to specify the correct integer column offset would be important so that we don't change the debayering order of course. I guess its up to you to setup support for something like this as you currently are pulling whole frames off all the time, even if you crop to 4k downstream?

I would like to crop the raw stream of a color camera to a square aspect ratio with a precise integer pixel offset from the left. The sensorCrop function only takes a single float (percentage of sensor) for the left, and does not offer a right side. How can I assure that I am employing the most low level region of interest crop so that the data coming off of the sensor is lessened for each frame. Hopefully this would give me a little more FPS as there is 1.33x less data.

Is this possible?