Advanced users • Re: Is the PISP a fake IP hidden by an over-complicated rpicam/libpisp/libcamera?

2) ov4689 datasheet is everywhere online: https://cdn.hackaday.io/files/193548280 ... Vision.pdf. Read it. You will see that both 8 and 10 bit are supported. The register to configure MIPI output is 0x3031 - page 94.

I read page 2 of that and see

supports output formats: 10-bit RAW RGB (MIPI)

OK there may be a register that mentions "mipi_bit_sel" with an 8-bit (and a 12-bit) setting, but from over 15 years of dealing with image sensors I put little faith in that until it has been proved to work (ie verify the raw images).
What has your Omnivision FAE said about running ov4689 in 8bit mode?

I remember OV5647 did have some 8bit modes supported, but they had issues so they were removed.

As for the reason, simple one: speed.

Changing between 8-bit and 10-bit will make no difference to the speed unless you also amend the PLL settings.
Section 2.9 of the datasheet covers the clock structure. The pixel array will generate data at the rate dictated by that, and fill the FIFO shown in Figure 2-1. The MIPI block will start sending at an appropriate point so it doesn't underflow.

I'm not trying to fix the problem of the picture. I think that the picture is an element indicating that the color conversion by rpicam-hello is not done in hardware but in software.

Think all you like, but I can assure you that you are wrong.
The CFE is producing 16bit Bayer (expanded from the N-bit that comes from the sensor), and the back end will be doing any conversions and scaling requested (along with all the other processing steps required for Bayer images).

Plus, I have tried ov4689 in 10 bit (one register to change), and I see the exact same issue.

New information. Have you looked at those raw images?

It's correct that this issue doesn't happen with ov5647. it doesn't necessarily means that it's an ov4689 kernel driver problem, it might be related to the configuration of libcamera.

In any case, nothing indicates for the moment that color conversion and scaling is done in hardware with ov5647.

Please enable V4L2 logging on the various backend device nodes (as I've already suggested).

My point is that I would like to process the color conversion and the scaling in hardware. That's all. Doing it in the first pipeline would be way smarter to my mind, but I'm fine with BE if that's the only solution.

There is no colour conversion in the CFE for writing out the image data, so whilst you could scale it, it'll always be in the Bayer domain.

Please confirm you are using the driver from mainline that has been validated on Rockchip RK3399, and not some random driver of unknown functionality.

Statistics: Posted by 6by9 — Wed Nov 13, 2024 11:34 am

---