RPi HQ: expose defective pixel correction (DPC)?

[schoerg]

The IMX477 camera has a DPC algorithm that might "delete" weak stars being detected as pixel errors.

The setting is in /sys/module/imx477/parameters/dpc_enable

According to this link these are the available options:

0 - All DPC disabled.
1 - Enable mapped on-sensor DPC.
2 - Enable dynamic on-sensor DPC.
3 - Enable mapped and dynamic on-sensor DPC.

My camera has 1 as default after reboot. Might be worth to consider for some, I don't see a huge difference if set to 0.

[troublestarter]

same for me:
cat /sys/module/imx477/parameters/dpc_enable
1

Someone added an interseting thing:

_"sudo vcdbg set imx477_dpc 0" is only applicable to the legacy camera stack, not libcamera.
The legacy camera stack does not work on 64bit OSes, therefore trying to use "sudo vcdbg set imx477_dpc 0" is totally redundant.

If you wish to set it with libcamera, then either follow naush's instructions to set it dynamically (actually his command reads the current status), or put "imx477.dpc_enable=0" in /boot/cmdline.txt (All on one line - no carriage returns permitted) to set it at boot time._

[troublestarter]

Maybe it does not really delete weak star, maybe it detect real defective pixel and that's it ?

[schoerg]

Maybe, I couldn't see much of a difference, here are some pictures: https://forum.astronomie.de/threads/dpc-einstellung-des-imx477-raspberry-pi-hq-cam.355875/ but maybe for others it will help.

[troublestarter]

as a result with you're images, i think it is better to have dpc enable i think

[schoerg]

You are right, although those are not my pictures. :)

[astrobrothers]

I think I have another thread about this somewhere... anyway, it does work with Pi4 + HQ + 64bit OS, but you can't use that vcdbg command. I think mine defaulted to DPC=3 again, but I plan on using 0 or 1 in the final build. I don't think there's a huge difference between 0 and 1, but 0 and 3 will look a lot different.

You do lose stars with 3 and the darks make a lot less sense if an algorithm is arbitrarily removing hot pixels. My end goal is to do real photometry and the values will be suspect if I can't properly correct for noise. It also gets weird with JPG's, so for this to be really useful you'd need to use RAW images (PNG may work as well). Then you need a solid dark library. For most users, 0 will probably make more headaches.

[EricClaeys]

I think most users will be best off with a good set of darks, once we support them on RPi. I suspect they won't need DPC and many will simply be confused by it. @astrobrothers you are likely not "most users", and for you we offer the "Extra Parameters" option and the ability to take .png files (be aware that they typically take several seconds to save due to no hardware support, versus fraction of a section for .jpg files).

[astrobrothers]

@EricClaeys - I'm definitely not like "most users" haha. Anyway you're totally right, most users should not worry about DPC. I did take some darks indoors today, despite being a different temp (same nighttime exposure), it seems to be correcting for the hot pixels with DPC=0.

Yes, PNG's work fine with Pi4 8GB and 64-bit os, I forget but I think it's like 10 seconds extra for saving. I'm just using JPG while I tweak some of the final settings.

[EricClaeys]

Yea, I think when I tried it on my Pi 4 it also took around 10 seconds, and I put something about that in the documentation.
I haven't tried it with a lower-resolution camera or with a Pi 5, but they should both be quicker. "Most people" probably wouldn't notice a difference.

[aaronwmorris]

As far as I can tell, the setting in /sys/module/imx477/parameters/dpc_enable is still a legacy method.

libcamera dynamically manages the DPC from the tuning file. I had success disabling DPC using the tuning file for the camera.

Something like this:

### backup original file
sudo cp /usr/share/libcamera/ipa/rpi/vc4/imx477.json /usr/share/libcamera/ipa/rpi/vc4/imx477.json_original
sudo cp /usr/share/libcamera/ipa/rpi/pisp/imx477.json /usr/share/libcamera/ipa/rpi/pisp/imx477.json_original


DPC_JSON_VC4=$(mktemp --suffix=.json)
DPC_JSON_PISP=$(mktemp --suffix=.json)


### Pi4 and older uses VC4
jq --argjson rpidpc_strength "0" '."rpi.dpc".strength = $rpidpc_strength' /usr/share/libcamera/ipa/rpi/vc4/imx477.json > "$DPC_JSON_VC4"

### Pi5 uses PISP
jq --argjson rpidpc_strength "0" '."rpi.dpc".strength = $rpidpc_strength' /usr/share/libcamera/ipa/rpi/pisp/imx477.json > "$DPC_JSON_PISP"


sudo cp -f "$DPC_JSON_VC4" /usr/share/libcamera/ipa/rpi/vc4/imx477.json
sudo chown root:root /usr/share/libcamera/ipa/rpi/vc4/imx477.json
sudo chmod 644 /usr/share/libcamera/ipa/rpi/vc4/imx477.json

sudo cp -f "$DPC_JSON_PISP" /usr/share/libcamera/ipa/rpi/pisp/imx477.json
sudo chown root:root /usr/share/libcamera/ipa/rpi/pisp/imx477.json
sudo chmod 644 /usr/share/libcamera/ipa/rpi/pisp/imx477.json


rm -f "$DPC_JSON_VC4"
rm -f "$DPC_JSON_PISP"

From my notes:

### libcamera Defective Pixel Correction (DPC) Strength
# https://datasheets.raspberrypi.com/camera/raspberry-pi-camera-guide.pdf
#
# 0 = Off
# 1 = Normal correction (default)
# 2 = Strong correction
###

[EricClaeys]

@aaronwmorris, is a tuning file needed for DPC since it can be specified on the command line?

[aaronwmorris]

Probably not, at least for the IMX477. However, not all camera kernel drivers expose the DPC setting (and I am not sure which ones have DPC that can be controlled). I just wanted to show how the settings can be controlled via the documented settings.

There are also quite a few other noise related settings that may be controlled via the tuning files.

[EricClaeys]

@aaronwmorris,
Not sure what your experience has been with RPi and RPi-compatible cameras, but the data returned by libcamera-still -v --metadata isn't very complete or accurate.

Unlike ZWO cameras where we can use their library to query a camera's capabilities to determine what field to display on the WebUI as well as their minimum, maximum, and default values, with RPi cameras I've been hard-coding that data into the capture program. I want to query it dynamically using libcamera-still -v --metadata so I don't need to do anything to support a new camera, but not all capabilities are returned (e.g., DPC for some cameras as you mentioned), many defaults aren't specified, and some values are simply wrong.

I may need to go to a hybrid approach where I query what I can and then hard-code the rest.

I've notified the libcamera-apps team and they've fixed some things but not most. "We report what the kernel driver returns so we'll ask the kernel team" has been one response. Have you asked them to improve the data quality?

[aaronwmorris]

My experience has been mixed, as well. I have had to hard code some parameters related to the cameras, too. You can see the parameters here: https://github.com/aaronwmorris/indi-allsky/blob/main/indi_allsky/camera/libcamera.py#L630 . I primarily had to do this to put bounds on the gain and exposure values. I eventually purchased one of most of the camera modules, just to verify some of this info, as it is not widely available.

From what I can tell, a much greater wealth of information is available from the libcamera API, the most common being the python Picamera2 module. I considered creating my own camera driver using Picamera2, but scriptorron beat me to the punch with indi_pylibcamera so it can natively work with INDI. The INDI team is still working on the indi_libcamera_ccd so hopefully that will be available at some point. The libcamera-still interface is just a stop-gap until a better option becomes available.