I need wait for clear sky to test and provide feedback

Finally tested, for gain value 20 it is looks pretty same with color sensor with ISP, but background no so black as for color sensor.
For me this issue resolved, attached examples to compare (10 seconds stacks)

IMX462 mono

IMX462 color with ISP

Also for register 0x3009 I got value 0xffff instead ox11 but seems like HCG enabled anyway.

I need wait for clear sky to test and provide feedback

PS:
After upgrade at the end it writes: "Failed to write register" message but upgrade done , can I just ignore it?

I have one more question but it is a little bit out of topic.
 
Yesterday I tried to take pictures of the night sky to compare with 462 color sensor, even with high gain value stars are not bright as for the same parameters on 462 color (but mono should be more sensitive) . It looks like there is no switching between  LCG and HCG modes or I need to tune some other parameters.
Can you advise what could be tuned for this case?

Also I managed start video by this command:
rpicam-still --tuning-file /source/libcamera/src/ipa/rpi/pisp/data/uncalibrated.json -t 0
and it works!

But better run it without additional parameters
Thank you.

I used set media script before:

Maybe forgot something else.

Did not find solution yet, probably need play with source code, will let you know if any updates.

https://github.com/veyeimaging/libcamera
https://github.com/veyeimaging/raspberrypi_v4l2

I fixed it and can open raw image from python, but anyway need find way how to decode video in real time, because now decode one frame is about 3 seconds.

Same Image as above:

mode
Allows you to specify a camera mode in the following colon-separated format: <width>:<height>:<bit-depth>:<packing>. The system selects the closest available option for the sensor if there is not an exact match for a provided value. You can use the packed (P) or unpacked (U) packing formats. Impacts the format of stored videos and stills, but not the format of frames passed to the preview window.

Bit-depth and packing are optional. Bit-depth defaults to 12. Packing defaults to P (packed).

For information about the bit-depth, resolution, and packing options available for your sensor, see list-cameras.

Examples:

4056:3040:12:P - 4056×3040 resolution, 12 bits per pixel, packed.

1632:1224:10 - 1632×1224 resolution, 10 bits per pixel.

2592:1944:10:U - 2592×1944 resolution, 10 bits per pixel, unpacked.

3264:2448 - 3264×2448 resolution.

Packed format details
The packed format uses less storage for pixel data.

On Raspberry Pi 4 and earlier devices, the packed format packs pixels using the MIPI CSI-2 standard. This means:

10-bit camera modes pack 4 pixels into 5 bytes. The first 4 bytes contain the 8 most significant bits (MSBs) of each pixel, and the final byte contains the 4 pairs of least significant bits (LSBs).

12-bit camera modes pack 2 pixels into 3 bytes. The first 2 bytes contain the 8 most significant bits (MSBs) of each pixel, and the final byte contains the 4 least significant bits (LSBs) of both pixels.

On Raspberry Pi 5 and later devices, the packed format compresses pixel values with a visually lossless compression scheme into 8 bits (1 byte) per pixel.

Unpacked format details
The unpacked format provides pixel values that are much easier to manually manipulate, at the expense of using more storage for pixel data.

On all devices, the unpacked format uses 2 bytes per pixel.

On Raspberry Pi 4 and earlier devices, applications apply zero padding at the most significant end. In the unpacked format, a pixel from a 10-bit camera mode cannot exceed the value 1023.

On Raspberry Pi 5 and later devices, applications apply zero padding at the least significant end, so images use the full 16-bit dynamic range of the pixel depth delivered by the sensor.

https://www.raspberrypi.com/documentation/computers/camera_software.html#common-options

Hi @veye_xumm

Hi, I managed to decode mipi packed raw format in rawfile_to_opencv_show.py file and seems like problem is not only in pixel format. If you look to image bellow : it has 6 same small areas which overlaps each other

Also enabled "test image" in camera configuration and it looks similar:

It is most probably driver issue or hardware issue.
What is else I can try to modify?

Also I tried open stream in qv4l2 application, it could open but video image broken