Closed Kyle0122 closed 9 months ago
Hello,
thank you for the detailed report. In the past I got many issue reports related to IMX290. It is either a widely used camera or it makes more trouble than others. I have HQ (IMX477) and V1 (OV5647) cameras only and should bye one to make my own experience. By the way, I believe the V1 camera is useless for astrophotography and guiding.
Back to your issue. I have two questions:
libcamera
as IMX290.The 'indi_pylibcamera' is one layer in a stack of software:
INDI client (for instance KStars, PHD2, CCDciel, ...)
--> INDI server
--> indi_pylibcamera
--> picamera2
--> libcamera library
--> kernel driver
It can not work when the versions of libcamera
and picamera2
are too old (both are in a dynamic development). And it can not work when the libcamera-tools (like libcamera-hello
and libcamera-still
) have issues with your camera.
You wrote that libcamera-still
does not work on Pi 5. You need to fix this first! I can imagine that the Pi 5 is too new and the libcamera
library or the kernel driver will get updates and bug fixes in near future.
The grid pattern you see is likely Moiré (https://en.wikipedia.org/wiki/Moir%C3%A9_pattern) caused by de-bayering the color pixel in PHD2. You can verify this by showing the same image in KStars: HQ camera test image (white wall, not in focus) seen in PHD2: Same image displayed in KStars FITS viewer: If it is Moiré than the pattern frequency will depend on the size of the image on the screen: All these images are from the same exposure! The only difference is the size of the PHD2 window on the screen. The pattern is an artifact of the image display. As far as I know this does not influence the guiding algorithm in PHD2. If not you can try the "2x2 mean" noise reduction in PHD2: With the "2x2 mean" the pattern is gone:
There is a different issue #53 regarding IMX290 crashing after the first exposure. Does it also crash in your setup? The next driver release will have a fix for issue #53.
Best Regards, Ronald
Pretty sure the pattern above is simply the bayer matrix as it's a raw image vs some RGB JPEG?
Exactly. It is Moire between the Bayer pattern and the screen pixel grid.
Thank you for the thorough explanation. My module is a WX-RP-290-327 from Waveshare.
After my initial test, I couldn't get it working properly on Pi 3 again, but I'm sure it is the Moiré pattern. Getting PHD2 compiled on Pi 3 is painful; It is unlikely that anyone would want to do it again, except for testing purposes.
Thankfully, after a rpicam-apps and python3-picamera2 update today, the libcamera-still -r --shutter 100000 --gain 1 --awbgains 1,1 --immediate -o test.jpg
on Pi 5 is fully working now. But I am still encountering the same issue of having noisy pictures on PHD2.
It is an IMX290. I just wanted to be sure :-)
I compiled PHD2 on a Pi 3 with the scripts from https://gitea.nouspiro.space/nou/astro-soft-build . It was needed to:
JOBS=1
in the scripts. That prevents compilation in parallel running threads which needs too much RAM.sudo dphys-swapfile swapoff
b.) Modify the size of the swap: As root, edit the file /etc/dphys-swapfile
and modify the variable CONF_SWAPSIZE to 2048:
sudo vi /etc/dphys-swapfile
c.) Initialize swap file
sudo dphys-swapfile setup
d.) Start swap
sudo dphys-swapfile swapon
After that it compiles INDI, KStars and PHD2 without errors. But it takes ages! I left it run over night.
Regarding the noisy pictures on your Pi 5: are the pictures also noisy when you do exposures with KStars/EKOS or CCDciel?
I tried but kStars says the indi crashed immediately after starting the capture:
org.kde.kstars.ekos.guide: "The connection was refused by the peer. Make sure the PHD2 is running, and check that the host name and port settings are correct."
org.kde.kstars.ekos.capture: "Warning: option \"Always Reset Sequence When Starting\" is enabled and resets the sequence counts."
org.kde.kstars.ekos.capture: "Job requires 1.000-second images, has 0/1 frames captured and will be processed."
org.kde.kstars.ekos.capture: "Capture exposure = 1 sec, type = Light, filter = , upload mode = 0, batch mode = true, seq prefix = Light, format = DNG, encoding = Native, Cannot bin, Cannot subframe"
org.kde.kstars.ekos.capture: "Capturing 1.000-second image..."
org.kde.kstars.indi: LibCamera : "[INFO] CCD_CAPTURE_FORMAT.DNG -> 1 "
org.kde.kstars.indi: LibCamera : "[INFO] CCD_EXPOSURE.CCD_EXPOSURE_VALUE -> 1.000000 "
org.kde.kstars.indi: INDI driver "indi_libcamera_ccd" crashed!
org.kde.kstars.ekos: "LibCamera is offline."
org.kde.kstars.ekos: "INDI services stopped."
The CCDciel returned the same image as the PHD2.
You used the wrong camera driver in KStars. No need to repeat when you see the same high noise with CCDciel.
Please can you run
indi_pylibcamera_print_camera_information
on Pi 3 and Pi 5 and send me both outputs? This program prints the camera information the driver gets from libcamera
. Maybe I can see something strange in the Pi 5 output.
Hi, Thanks for helping me troubleshoot the issue. You can find the camera_information output from the Pi 5 in the first post. I checked it hasn't changed. Here is the camera_information from the Pi 3:
pi@raspberrypi:~ $ indi_pylibcamera_print_camera_information
Testing numpy:
numpy 1.19.5
Testing astropy:
astropy 4.2
[0:18:00.763671643] [2190] INFO Camera camera_manager.cpp:297 libcamera v0.0.5+83-bde9b04f
[0:18:00.810257716] [2192] INFO RPI vc4.cpp:437 Registered camera /base/soc/i2c0mux/i2c@1/imx290@1a to Unicam device /dev/media3 and ISP device /dev/media0
[0:18:00.810503080] [2192] INFO RPI pipeline_base.cpp:1101 Using configuration file '/usr/share/libcamera/pipeline/rpi/vc4/rpi_apps.yaml'
Found 1 cameras.
Camera 0:
{'Id': '/base/soc/i2c0mux/i2c@1/imx290@1a',
'Location': 2,
'Model': 'imx290',
'Rotation': 0}
[0:18:00.818061341] [2190] INFO Camera camera_manager.cpp:297 libcamera v0.0.5+83-bde9b04f
[0:18:00.871329428] [2195] INFO RPI vc4.cpp:437 Registered camera /base/soc/i2c0mux/i2c@1/imx290@1a to Unicam device /dev/media3 and ISP device /dev/media0
[0:18:00.871464271] [2195] INFO RPI pipeline_base.cpp:1101 Using configuration file '/usr/share/libcamera/pipeline/rpi/vc4/rpi_apps.yaml'
Camera properties:
{'ColorFilterArrangement': 0,
'Location': 2,
'Model': 'imx290',
'PixelArrayActiveAreas': [(12, 8, 1920, 1080)],
'PixelArraySize': (1945, 1097),
'Rotation': 0,
'ScalerCropMaximum': (0, 0, 0, 0),
'SystemDevices': (20749, 20737, 20738, 20739),
'UnitCellSize': (2900, 2900)}
Raw sensor modes:
[0:18:00.892196612] [2190] INFO Camera camera.cpp:1033 configuring streams: (0) 640x480-XBGR8888 (1) 1280x720-SRGGB10_CSI2P
[0:18:00.893077755] [2195] INFO RPI vc4.cpp:565 Sensor: /base/soc/i2c0mux/i2c@1/imx290@1a - Selected sensor format: 1280x720-SRGGB10_1X10 - Selected unicam format: 1280x720-pRAA
[0:18:00.923700798] [2190] INFO Camera camera.cpp:1033 configuring streams: (0) 640x480-XBGR8888 (1) 1920x1080-SRGGB10_CSI2P
[0:18:00.926162458] [2195] INFO RPI vc4.cpp:565 Sensor: /base/soc/i2c0mux/i2c@1/imx290@1a - Selected sensor format: 1920x1080-SRGGB10_1X10 - Selected unicam format: 1920x1080-pRAA
[0:18:00.972935667] [2190] INFO Camera camera.cpp:1033 configuring streams: (0) 640x480-XBGR8888 (1) 1280x720-SRGGB12_CSI2P
[0:18:00.973971601] [2195] INFO RPI vc4.cpp:565 Sensor: /base/soc/i2c0mux/i2c@1/imx290@1a - Selected sensor format: 1280x720-SRGGB12_1X12 - Selected unicam format: 1280x720-pRCC
[0:18:01.007548491] [2190] INFO Camera camera.cpp:1033 configuring streams: (0) 640x480-XBGR8888 (1) 1920x1080-SRGGB12_CSI2P
[0:18:01.010113536] [2195] INFO RPI vc4.cpp:565 Sensor: /base/soc/i2c0mux/i2c@1/imx290@1a - Selected sensor format: 1920x1080-SRGGB12_1X12 - Selected unicam format: 1920x1080-pRCC
[{'bit_depth': 10,
'crop_limits': (320, 180, 1280, 720),
'exposure_limits': (22, None),
'format': SRGGB10_CSI2P,
'fps': 60.0,
'size': (1280, 720),
'unpacked': 'SRGGB10'},
{'bit_depth': 10,
'crop_limits': (0, 0, 1920, 1080),
'exposure_limits': (14, 115686250, None),
'format': SRGGB10_CSI2P,
'fps': 60.0,
'size': (1920, 1080),
'unpacked': 'SRGGB10'},
{'bit_depth': 12,
'crop_limits': (320, 180, 1280, 720),
'exposure_limits': (22, 115686258, None),
'format': SRGGB12_CSI2P,
'fps': 60.0,
'size': (1280, 720),
'unpacked': 'SRGGB12'},
{'bit_depth': 12,
'crop_limits': (0, 0, 1920, 1080),
'exposure_limits': (14, 115686250, None),
'format': SRGGB12_CSI2P,
'fps': 60.0,
'size': (1920, 1080),
'unpacked': 'SRGGB12'}]
Camera configuration:
{'buffer_count': 4,
'colour_space': <libcamera.ColorSpace 'sYCC'>,
'controls': {'FrameDurationLimits': (100, 83333),
'NoiseReductionMode': <NoiseReductionModeEnum.Minimal: 3>},
'display': 'main',
'encode': 'main',
'lores': None,
'main': {'format': 'XBGR8888',
'framesize': 1228800,
'size': (640, 480),
'stride': 2560},
'queue': True,
'raw': {'format': 'SRGGB12_CSI2P',
'framesize': 3110400,
'size': (1920, 1080),
'stride': 2880},
'transform': <libcamera.Transform 'identity'>,
'use_case': 'preview'}
Camera controls:
{'AeConstraintMode': (0, 3, 0),
'AeEnable': (False, True, None),
'AeExposureMode': (0, 3, 0),
'AeMeteringMode': (0, 3, 0),
'AnalogueGain': (1.0, 31.62277603149414, None),
'AwbEnable': (False, True, None),
'AwbMode': (0, 7, 0),
'Brightness': (-1.0, 1.0, 0.0),
'ColourGains': (0.0, 32.0, None),
'Contrast': (0.0, 32.0, 1.0),
'ExposureTime': (14, 115686250, None),
'ExposureValue': (-8.0, 8.0, 0.0),
'FrameDurationLimits': (16666, 115687148, None),
'NoiseReductionMode': (0, 4, 0),
'Saturation': (0.0, 32.0, 1.0),
'ScalerCrop': ((0, 0, 64, 64), (0, 0, 1920, 1080), (240, 0, 1440, 1080)),
'Sharpness': (0.0, 16.0, 1.0)}
Exposure time:
min: 14, max: 115686250, default: None
AnalogGain:
min: 1.0, max: 31.62277603149414, default: None
Hi. I compared the two files and indeed there is something strange on the Pi 5: The raw sensor modes have data format "SRGGB10_CSI2P" or "SRGGB12_CSI2P". But when creating a camera configuration the data format changes to "RGGB16_PISP_COMP1". It is now 16bit (expected are 12bit) and PISP COMP1. On Pi 3 (and on all my cameras with HQ and V1 camera) the format stays CSI2P. Maybe the reason for the noise is a different packing of the pixel data.
I searched the internet for PISP_COMP1 and could not find a description of that format. I will try to find out how libcamera and the libcamera-apps are handling this.
According to https://datasheets.raspberrypi.com/camera/raspberry-pi-image-signal-processor-specification.pdf, section 4:
The PiSP Compressed Raw Format is a fixed-rate lossy compression format with 8 bits per pixel.
It would be needed to decompress this before sending the INDI FITS image. And it will likely make artifacts when used for astrophotography. I will try to find a way to force CSI2P.
Great work, I hope it's an easy fix. I tried an ov5647, and it has the same noise issue. I'll try the PI HQ camera when it arrives. Since this issue is not limit to imx290, I'll change the issue title.
That info helps me a lot! I will order a Pi 5. Than I can test with the cameras I have.
I received the Pi HQ camera. It has the same noise using indi_pylibcamera driver.
I also discovered another problem, the HQ camera can not be used with an extension cable on the pi 5. I'm using a 15-pin "FFC FPC Extension Board" to connect two PFC cables. The imx290 module worked without any problem, but the HQ camera will not work on the Pi 5 with an extension board. Maybe it's running on a much higher frequency than other modules.
My new P5 arrived Yesterday. Now I am waiting for the power supply and the heat sink. This should also arrive in the next days.
When I ordered the Pi5 accessories I saw that I need other cables for the cameras. The camera connector on the Pi5 has now a different size to the previous versions. What a pain! I suppose you also have the new cables.
I hope I get all together the next days and can start testing + debugging.
I can replicate the issue with a v1 camera. Unfortunately I can not test with my HQ cameras because I got the wrong adapter cable delivered (ordered camera cable, got display cable). I will complain about the wrong cable. In the meantime I can analyze the issue with the v1 camera.
I am surprised that the "official HQ camera" does not work on the "official Pi5". Maybe an OS bug that gets fixed later.
The modifications in branch 54-noisy-image-with-raspberry-pi-5 work on Pi 5 with V1 and HQ camera. I will merge and make a new release.
I do not have issues with the HQ camera directly connected to the Pi 5. I tested with Bookworm and did sudo apt update; sudo apt upgrade
2 days ago.
Problem Description
Thank you for developing this Raspberry Pi camera driver. I'm currently using it with an IMX290 module on OpenAstroGuider project, recommended for its exceptional low-light performance.
However, I've encountered a problem where the captured frames appear corrupted. I tried both on Raspberry Pi 3b and Pi 5, the image captured from Pi 3b seems less corrupted but still has a grid pattern. I found a discussion on the Raspberry Pi forums that may be related to the problem I'm facing: https://forums.raspberrypi.com/viewtopic.php?t=357256. The discussion in that thread seems to touch upon similar concerns. libcamera commit is here: ipa: rpi: imx290: Hide one frame on startup
Steps to Reproduce
To reproduce the issue, follow these steps: Install Bullseye 64bit on Pi 3b and Bookworm 64bit on Pi 5. Add/modify three lines in config.txt:
camera_auto_detect=0
dtoverlay=imx290,frequency=37125000
display_auto_detect=0
On the Pi 5, there is no official camera tune file for IMX290, so make a copy of the other sensor as follows:sudo cp /usr/share/libcamera/ipa/rpi/pisp/imx296_noir.json /usr/share/libcamera/ipa/rpi/pisp/imx290.json
Reboot and test if the module is loaded:Next, compile and install indi-core and phd2 on both machines. Finally, install indi_pylibcamera.
libcamera-hello -t 0
works well on both machines, but the commandlibcamera-still -r --shutter 100000 --gain 1 --awbgains 1,1 --immediate -o test.jpg
on Pi 3b works fine but not on Pi 5.Images from PHD2:
Here are the images captured from PHD2, they are captured in a dark room where the monitor is the only light source: On Pi 3b: https://i.imgur.com/uPmtzec.png On Pi 5: https://i.imgur.com/mHLFGru.png You can see the grid pattern on Pi 3 and the noise issue on Pi 5.
logs from Pi5: