HQ Camera on-sensor defective pixel correction (DPC) - legacy camera stack only

[naushir]

There have been several requests by the community on disabling on-sensor defective pixel correction (DPC). This might be useful for astrophotography applications where faint stars might get blurred out due to the filtering involved.

A switch has been added to the firmware driver to allow control of the on-sensor DPC. To use it, update the firmware via rpi-update, and run the following command before starting the camera:

Code: Select all

sudo vcdbg set imx477_dpc <value>

where <value> can be one of:
0 - All DPC disabled.
1 - Enable mapped on-sensor DPC.
2 - Enable dynamic on-sensor DPC.
3 - Enable mapped and dynamic on-sensor DPC.

The default is (3). It would be useful to get feedback from users who do astrophotography if disabling DPC actually makes a difference or not.

Note that this does not disable the ISP defective pixel correction that will still be active, so you will likely only see changes in the RAW image.

[gordon77]

Thanks for sharing. Sounds useful.

[tmorley]

Just had a quick test of this, and it looks good. Appears to make a difference even in jpegs.

I'll extract the images from my pi tomorrow, and have a proper look at the raws, and post some comparisons here!

Thanks a lot!

[tmorley]

Last night, between te clouds I managed to get a some photos with the HQ camera and a fujinon fisheye lens. These are 10 second exposures at ISO3200, and I've cropped out a small region to compare the 4 different DPC settings. In both of these imx477_dpc =0 on the left across to imx477_dpc =3 on the right

First off crops from the jpgs straight from raspistill, even in those there is some difference visible.



And after extrcting the raw from the same frames and processing with dcraw



As you can see it definatley makes a difference, both in the noise levels, and the faint stars visible!

[therealdavidp]

Very interesting. Are you able to upload the raw files somewhere and share them? We'd be very keen to take a look for ourselves (and share any findings, of course). Thanks!

[tmorley]

Very interesting. Are you able to upload the raw files somewhere and share them? We'd be very keen to take a look for ourselves (and share any findings, of course). Thanks!

The images are available at https://ordered.chaos.org.uk/~tim/pi-hq-camera/ either as individual files, or a zip file of the whole lot.

[therealdavidp]

Thanks for sharing that link. I downloaded them and ran one of each type through a software ISP, having carefully turned off all forms of Defective Pixel Correction, Spatial Denoise, Colour Denoise and Colour anti-aliasing.

You can find the results here: https://drive.google.com/drive/folders/ ... sp=sharing and here's a summary image showing the same crop from each of the four.

all_four.jpg (191.78 KiB) Viewed 7635 times

A number of things strike us immediately.

• The dpc0 and dpc1 images show large numbers of defective pixels. It's even more obvious if you download the full set and have a look for yourself. It's pretty clear why on-sensor DPC is enabled by default. (Though actually the in-ISP DPC seems to work reasonably well too, judging by the JPEGs.) I get the impression that the dcraw images in the earlier post are still showing some degree of correction. In these versions I like how it's easy to spot which colour in the Bayer pattern the "hot" pixels are!
• Generally there's less difference between dpc0 and dpc1, and between dpc2 and dpc3 (as compared to dpc0 vs. dpc2 for example). I guess this suggests the "mapped" correction isn't doing very much - but then, manufacturers generally like to avoid doing (expensive) per-sensor calibration.
• Comparing dpc0 and dpc1 is quite interesting. The "stars" that stay completely fixed are of course the sensor artifacts; real stars reveal themselves by appearing to move as the earth turns.

Looking at this it would seem to me that there's some mileage in developing one's own software DPC tools. You could measure the presence of defects from one (or more) calibration images, or even from an existing set like this - using the fact that defects stay put but real stars don't. There's an open question as to how much further correction one would need if one could "map" all these obvious defects effectively. Sounds like there's some fun to be had here!

[CanPi]

Brilliant work!

[gordon77]

"using the fact that defects stay put but real stars don't. "

Stars don't move if you guide your camera / telescope.

One method is to use dark frames.

[xkubazz]

Thank you for this change, much appreciated!
I'm away from my camera for next month, but I cannot wait to test this feature for astrophotography and will do it as soon as possible and report results. With dithering, stacking and dark frame subtraction it should pretty straightforward to remove hot pixels, samples from @therealdavidp look really promising!

[RoboRob]

"using the fact that defects stay put but real stars don't. "

Stars don't move if you guide your camera / telescope.

One method is to use dark frames.

then you can use dithering (move you camera a little bit to ensure dark and hot pixels are not always in the same place). Then you can remove the defective pixels by applying flat and dark masters...