Large frames with tiling issues?

[kbingham]

Capturing on a Raspberry Pi 5: I'm trying to process a 'super sized' IMX283 image (5592x3694 RAW)

And things get very purple and blotchy

I think I remember there were some alignment constraints hit on the OV64A40 that might have looked like this too? or that needed a larger tile size or something somewhere?

RAW (SRGGB16) output with debayer in camshark looks ok:

[naushir]

Adding @davidplowman

Have you tried a capture in rpicam apps to see if it also shows the issue?

[davidplowman]

Posting a dng of the raw file and a png of the output would be helpful too.

Wouldn't it be great if libcamera had a feature where you could take a raw file and "reprocess" it back through the h/w pipeline, with the ability to tweak blocks and turn them on and off? 😃

[6by9]

Wasn't this the type of output we got when the advertised crop was wrong and it threw lens shading off?

[kbingham]

Well that was unexpected:

root@beehive:~# rpicam-raw  --width 5592 --height 3710 -o imx283-super.dng
[1:08:02.181171782] [1951]  INFO Camera camera_manager.cpp:340 libcamera v0.7.1+rpt20260609+1-6f927502
[1:08:02.194025375] [1952]  INFO RPI pisp.cpp:720 libpisp version v1.5.0 86d71c805c3f 18-06-2026 (14:37:23)
[1:08:02.197684377] [1952]  INFO IPAProxy ipa_proxy.cpp:184 Using tuning file /usr/local/share/libcamera/ipa/rpi/pisp/imx283.json
[1:08:02.211461512] [1952]  INFO Camera camera_manager.cpp:223 Adding camera '/base/axi/pcie@1000120000/rp1/i2c@80000/imx283@1a' for pipeline handler rpi/pisp
[1:08:02.211518624] [1952]  INFO RPI pisp.cpp:1181 Registered camera /base/axi/pcie@1000120000/rp1/i2c@80000/imx283@1a to CFE device /dev/media0 and ISP device /dev/media2 using PiSP variant BCM2712_C0
Overriding H.264 level 4.2
Mode selection for 5592:3710:12:P
    SRGGB10_CSI2P,5472x3648/0 - Score: 1385.83
    SRGGB12_CSI2P,48x3694/0 - Score: 15602.9
    SRGGB12_CSI2P,2736x450/0 - Score: 13946.8
    SRGGB12_CSI2P,4096x450/0 - Score: 12360.1
    SRGGB12_CSI2P,1824x1216/0 - Score: 12545.8
    SRGGB12_CSI2P,5472x450/0 - Score: 10754.8
    SRGGB12_CSI2P,2736x1824/0 - Score: 9505.83
    SRGGB12_CSI2P,2304x3072/0 - Score: 10123.8
    SRGGB12_CSI2P,4096x3072/0 - Score: 4789.83
    SRGGB12_CSI2P,5472x3648/0 - Score: 385.833
    SRGGB12_CSI2P,5496x3672/0 - Score: 299.637
    SRGGB12_CSI2P,5496x3694/0 - Score: 282.379
    SRGGB12_CSI2P,5592x3710/0 - Score: 0
Stream configuration adjusted
[1:08:02.212969614] [1951]  INFO Camera camera.cpp:1216 configuring streams: (0) 5592x3710-YUV420/Rec709 (1) 5592x3710-RGGB_PISP_COMP1/RAW
[1:08:02.213080892] [1952]  INFO RPI pisp.cpp:1485 Sensor: /base/axi/pcie@1000120000/rp1/i2c@80000/imx283@1a - Selected sensor format: 5592x3710-SRGGB12_1X12/RAW - Selected CFE format: 5592x3710-PC1R/RAW
Raw stream: 5592x3710 stride 5632 format RGGB_PISP_COMP1

root@beehive:~# ls -alh imx*
-rw-r--r-- 1 root root 837M Jun 30 17:24 imx283-super.dng
-rw-r--r-- 1 root root 2.9M Jun 30 17:22 imx283-super.jpg

a gigabyte raw image from a 20MP sensor ?

[kbingham]

rpicam-jpeg -r --width 5592 --height 3710 -o imx283-super.jpg gives the attached (3MB) jpg though

[davidplowman]

Ah yes, the gigabyte raw file does smack of an underflow when dealing with frame sizes.

[kbingham]

Wasn't this the type of output we got when the advertised crop was wrong and it threw lens shading off?

This is a strong lead - I have some negative coordinates :D

[kbingham]

root@beehive:~# rpicam-still --list
Available cameras
-----------------
0 : imx283 [5496x3694 12-bit RGGB] (/base/axi/pcie@1000120000/rp1/i2c@80000/imx283@1a)
    Modes: 'SRGGB10_CSI2P' : 5472x3648 [10.62 fps - (12, 20)/5472x3648 crop]
           'SRGGB12_CSI2P' : 48x3694 [10.91 fps - (-72, 0)/48x3694 crop]
                             2736x450 [151.06 fps - (12, 1388)/5472x900 crop]
                             4096x450 [79.78 fps - (696, 1616)/4096x450 crop]
                             1824x1216 [49.51 fps - (12, 20)/5472x3648 crop]
                             5472x450 [67.64 fps - (12, 1616)/5472x450 crop]
                             2736x1824 [37.46 fps - (12, 20)/5472x3648 crop]
                             2304x3072 [12.86 fps - (1596, 308)/2304x3072 crop]
                             4096x3072 [15.17 fps - (696, 308)/4096x3072 crop]
                             5472x3648 [10.70 fps - (12, 20)/5472x3648 crop]
                             5496x3672 [10.70 fps - (0, 12)/5496x3672 crop]
                             5496x3694 [10.70 fps - (0, 0)/5496x3694 crop]
                             5592x3710 [10.70 fps - (-96, -16)/5592x3710 crop]

Maybe I'm into the realm of (purple) dragons - I'm capturing that 5592x3710 [10.70 fps - (-96, -16)/5592x3710 crop] mode, which is negative because it's actually including the horizontal and vertical optical black regions.

[naushir]

rpicam-raw would have saved over 5s of raw data, hence the large size.

You want rpicam-still -r ...

[6by9]

Wasn't this the type of output we got when the advertised crop was wrong and it threw lens shading off?

This is a strong lead - I have some negative coordinates :D

I did advocate a couple of weeks back that we should scream and shout if the driver tells us such rubbish, as it is very likely a driver bug. Perhaps this can be another little nudge.

I'm vaguely recalling that optical black regions are frequently sent on a different CSI-2 data type to the image data, so is the full image received into the one buffer in this case?