Posts made by Gicu Panaghiu

@modaltb thanks for the response. Hope it will make it in :).

@Alex-Kushleyev thanks for the detailed response.
Sorry for not specifying, I am on a VOXL2.
Under /usr/lib what is available at the moment is

Binary file /usr/lib/camera/com.qti.sensor.ov7251.so matches
Binary file /usr/lib/camera/com.qti.sensor.ov7251_front_left.so matches
Binary file /usr/lib/camera/com.qti.sensor.ov7251_front_right.so matches
Binary file /usr/lib/camera/com.qti.sensor.ov7251_rear_left.so matches
Binary file /usr/lib/camera/com.qti.sensor.ov7251_rear_right.so matches

The only camera_config.xml I have identified is the one within voxl-camera-server.

Since I am configuring the tracking camera, I assume ov7251.so is used which is RAW8.
Is there currently any sensor library on VOXL2 which supports 10bit?

Assuming the correct driver is in place, as you mention I would still have to modify and deploy a voxl-camera-server which would:

1. Unpack the pixel data
2. Pass a image with IMAGE_FORMAT_RAW16 to the pipe with the unpacked data

From what I see in the voxl-logger this format is already supported and I would then obtain 16bit grayscale images.

Hello I have a MSU-M0014-1-01(OV7251) and I'm trying to determine what would be required to get RAW10 frames.
From what I've investigated the voxl-camera-server will either way trim the buffer received from the lower layer to RAW8.
When doing the initial stream configuration for the preview stream HAL_PIXEL_FORMAT_RAW10 is passed to the lower layer. But even with this step the received data is still in RAW8 format.
This leads me to believe that the actual supported format by the low level driver is RAW8, and this is chosen to begin with as being the only option.

If this is not the case and the sensor operates as RAW10, where exactly along the way is this trimming performed and how can this be adjusted to obtain RAW10 frames?

I hope someone can help with some info or documentation.