Color dot problem

[glddiv]

Hi there,

When I was using libcamera-app, there was a strange color dot problem, but when I switched to qcam, there was no problem.
What could be the cause of this?

raspberry pi:
P4B 8GB

camera:
imx219

system version:
Linux raspberrypi 5.10.17-v7l+ #1 SMP Thu Mar 18 16:45:46 CST 2021 armv7l GNU/Linux

[naushir]

The corruption looks to match the saturated bits of the image quite well. This probably rules out anything to do with the CSI-2 link (i.e. cable, clocking, etc.).

As a guess, I would say colour denoise might be causing this, as qcam disables colour denoise by default. Some further questions:

• How reproducible is this?
• What is the command line you are running?
• Assuming this is libcamera-still, does this happen in preview and capture?
• Could you try running with the --denoise=cdn_off command line argument and see if you can reproduce this?

[glddiv]

Hi @naushir

thanks for the reply,

How reproducible is this?

I have this problem almost every time I run libcamera-hello/vid/still.
I am using imx219, and the json file is also the default.

What is the command line you are running?

libcamera-still/vid/hello -t 0

Assuming this is libcamera-still, does this happen in preview and capture?

I tried several times, but the image saved by still has no problem (because the color dots have been flashing, I'm not sure if I got a good frame), but the h264 file saved by vid has this problem.

Could you try running with the --denoise=cdn_off command line argument and see if you can reproduce this?

This problem disappeared after adding the --denoise=cdn_off parameter.

[naushir]

This problem disappeared after adding the --denoise=cdn_off parameter.

Thanks for confirming. This does sound like video CDN causing this corruption.

Unfortunately, I did not manage to reproduce this yet for myself, will keep trying. @davidplowman, are you able to see this corruption on your setup?

[naushir]

@glddiv if you point the camera at a dark scene, without any bright lights or windows to saturate the image, do you still see the corruption?

[davidplowman]

No, I'm not seeing it but will keep an eye open.

[glddiv]

Hi @naushir,

This was shot under my desk, but there was still corrosion.

h264_file.zip

[naushir]

@glddiv thank you for trying that out. So it does not seem to be specific to saturated bits in the image. I will need to look at the code in a bit more detail....

[naushir]

I'm really struggling with this one. I cannot reproduce it, and nothing in the code seems wrong as far as I can tell.

@glddiv, to rule out hardware problems, can you do the following (if possible):

• Swap to another sensor board if you have one.
• Add core_freq_min=300 at the bottom of /boot/config.txt and reboot and re-test.

[glddiv]

Hi @naushir

I tried IMX219 and IMX477, no luck.
I also tried core_freq_min=300, but it did not improve.

Today I tried to update everything to the latest, and now the program cannot run.

config.txt

[naushir]

Today I tried to update everything to the latest, and now the program cannot run.

Things going from bad to worse :-(

I did just try a full rebuild and update of kernel and firmware and I do not see the same problem. Here is my version strings:

pi@pi4:~ $ uname -a
Linux pi4-naush 5.10.25-v7l+ #12 SMP Fri Mar 26 07:20:46 GMT 2021 armv7l GNU/Linux

pi@pi4:~ $ sudo vcdbg version
vcos_build_version     = 0dee547b98252c8013f6603f5d1c79e24a42a6e8 (clean)
vcos_build_branch      = bcm2711_2
debug_sym: ReadVideoCoreMemoryBySymbol: Symbol not found: 'vcos_build_application'
vcos_build_application = ?
vcos_build_date        = Mar 26 2021
vcos_build_time        = 07:24:28
vcos_build_user        = naushir
vcos_build_hostname    = naush-laptop
vcos_build_platform    = raspberrypi_linux
debug_sym: ReadVideoCoreMemoryBySymbol: Symbol not found: 'vcos_build_type'
vcos_build_type        = ?

Any chance you might have another Raspberry Pi board to try this on?

[glddiv]

update:
I think I figured it out. I used the IMX219 without ATSHA204A. I disabled the camera in raspi-config and it can be used normally. Is this a bug?
Anyway, the corruption still exists.

Strange, I flashed an sd card again and performed the operations in the libcamera document, but the same error persists. Am I missing something?
Tried Pi3B V1.2 and Pi4B, no luck.

[naushir]

Just to clarify, the update I did was a custom build on ToT for linux and firmware. I have subsequently done a rpi-update, and it now matches exactly with your versions:

pi@pi4:~ $ uname -a
Linux pi4-naush 5.10.25-v7l+ #1408 SMP Mon Mar 22 12:49:24 GMT 2021 armv7l GNU/Linux
pi@pi4:~ $ sudo vcdbg version
vcos_build_version     = 81fb91910274d9cb53baee496477fa7b6c6df739 (clean)
vcos_build_branch      = bcm2711_2
debug_sym: ReadVideoCoreMemoryBySymbol: Symbol not found: 'vcos_build_application'
vcos_build_application = ?
vcos_build_date        = Mar 23 2021
vcos_build_time        = 22:05:02
vcos_build_user        = dom
vcos_build_hostname    = buildbot
vcos_build_platform    = raspberrypi_linux
debug_sym: ReadVideoCoreMemoryBySymbol: Symbol not found: 'vcos_build_type'
vcos_build_type        = ?

Everything still works fine for me. @davidplowman, are you able to do an update on your device and see if you get any errors?

[davidplowman]

I've just been round the "install fresh image, follow all those instructions" loop with my Pi4 and imx219, and it works with no problems. So this is definitely proving very puzzling. I shall continue to look out for the "dots", however...

[glddiv]

Hi @naushir
I tried different cameras IMX219, IMX219 NO-IR and IMX477 (Arducam), tried different cables, tried Pi4B 4GB, Pi4B 8GB and Pi3B, they all have the same problem.
So I moved my gaze to other places. All the Raspberry Pis tested used the same SD card but I tried two and re-flashed one of them, so I think this should not be a problem. There is no lightning sign when running the program, so we can rule out the power supply problem.
I moved my gaze to the peripheral interface. I connected the USB HUB (with the mouse and keyboard connected to it) and the network cable every time.
Then I tried to remove the network cable, and the magic happened, the corrosion did not appear, no matter how I moved the camera or switched scenes, there would be no corrosion. At this time, I connected the network cable back again, and the corrosion problem came back (sometimes I need to shake the camera a few times before it appears).

Photos of my hardware settings:

[glddiv]

Things have become even more weird. It seems to have the same problem when connecting to WIFI. I recorded a simple video to show this phenomenon.

https://drive.google.com/file/d/1YyGSmgeqwu5lObZBVF4lhFM-o57lf9W6/view?usp=sharing

[naushir]

@glddiv thanks for the update.

I'm using wifi in my setup at home, but I have also tried with an Ethernet cable and still no luck reproducing. If it's an electrical issue, it does seem strange that switching off colour denosie seems to solve it, I can't really explain that....

Will continue to try and reproduce.

[glddiv]

@naushir
I think if no one else can reproduce this problem, maybe there are some special operations I haven't noticed. I will update again if there is more information.

[naushir]

@glddiv, thank you for your help debugging this. I will continue looking at this in the background. If you have any updates, please do post them here.

[popcornmix]

A fix has been pushed to the latest rpi-update firmware.

[naushir]

@glddiv the fix in rpi-update might just solve your colour dots problem. It's hard to tell, as I cannot reproduce the original fault, but I did fix a problem in the colour denoise code that could cause pixel corruption in the right circumstances.

If you do get a chance to try it out, please let us know the results.

[glddiv]

Hi @popcornmix , @naushir

Thank you.
I just ran the test and so far I haven't found corrosion.
It seems that the fix has worked, and I think I can close this issue now.