Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New AWB algorithm breaks custom lens shading #1198

Closed
jtc42 opened this issue Jul 19, 2019 · 13 comments
Closed

New AWB algorithm breaks custom lens shading #1198

jtc42 opened this issue Jul 19, 2019 · 13 comments

Comments

@jtc42
Copy link

jtc42 commented Jul 19, 2019

This was briefly mentioned in this comment, but the new AWB algorithm described here breaks custom lens-shading tables in the Pi camera.

Examples

This comment describes raspistill hanging when built with a custom lens-shading table.

More relevant to me personally, the lens-shading implementation in rwb27/picamera is broken in a similar way.

The module will work fine until you write any data to the lens-shading table. After that, all captures will hang until timeout.

This is immediately seen when, for example, running this auto-calibration routine for lens shading, using that picamera fork

Workaround

As a workaround, you can switch back to the old AWB version by running sudo vcdbg set awb_mode 0. This comment describes creating a service to run the command on boot, which may be useful.

Ideal outcomes

My understanding is that the new AWB algorithm is part of the closed-source bit of the firmware? Any guidance on how to update custom lens-shading implementations to work with the new algorithm would be ideal.

In the meantime, do you have any information on if vcdbg set awb_mode will be sticking around, at least for the foreseeable future? Custom lens-shading is absolutely mission critical to the project I'm working with, so removal of this option would be extremely challenging for us.

If we know it'll stick around as an option, it'd save us a huge headache.

Many thanks! Please let me know if I can provide any more information, or if any particular logs would be useful.

@JamesH65
Copy link
Contributor

@naushir For you I think!

@6by9
Copy link

6by9 commented Jul 19, 2019

The main thing to say at this stage is the sudo vcdbg set awb_mode 0 is likely to give substandard results on a Pi4. The old AWB algorithm uses parts of the 3D hardware for the stats analysis, and on Pi4 that is not an option (new hardware, and controlled by the ARM not VPU).

For Pi0-3 the option is likely to hang around for a fair while (many months, if not years, as it is effort to remove it), but we will be aiming to resolve the issue of the new AWB and custom lens shading within weeks.
Apologies that we hadn't picked up on the issue report on the forum earlier. Github issues are always a more reliable reporting mechanism if there is an obvious regression.

@jtc42
Copy link
Author

jtc42 commented Jul 19, 2019

The main thing to say at this stage is the sudo vcdbg set awb_mode 0 is likely to give substandard results on a Pi4. The old AWB algorithm uses parts of the 3D hardware for the stats analysis, and on Pi4 that is not an option (new hardware, and controlled by the ARM not VPU).

For Pi0-3 the option is likely to hang around for a fair while (many months, if not years, as it is effort to remove it), but we will be aiming to resolve the issue of the new AWB and custom lens shading within weeks.
Apologies that we hadn't picked up on the issue report on the forum earlier. Github issues are always a more reliable reporting mechanism if there is an obvious regression.

Thanks for the information. Do you have specifics on "substandard results"? Basically everything we do involves taking an AWB once, then immediately turning AWB off, fixing the white balance values, and then auto-calibrating lens-shading.

If the AWB is just slow, we can absolutely deal with that. If it's likely to be WAY out, or totally broken, then we may have to just recommend against using the Pi4 for the project until we can come up with a proper fix for our custom lens-shading.

Absolutely no worries about not catching this earlier. I feel it's a fairly niche use-case, and it's been a busy few weeks!

@naushir
Copy link

naushir commented Jul 19, 2019

This should be an easy fix. Working on it now.

@6by9
Copy link

6by9 commented Jul 19, 2019

Thanks for the information. Do you have specifics on "substandard results"? Basically everything we do involves taking an AWB once, then immediately turning AWB off, fixing the white balance values, and then auto-calibrating lens-shading.

If the AWB is just slow, we can absolutely deal with that. If it's likely to be WAY out, or totally broken, then we may have to just recommend against using the Pi4 for the project until we can come up with a proper fix for our custom lens-shading.

There are actually 3 different AWB algorithms of varying complexities in the old driver, and if they reported that they couldn't find a sane set of settings they'd drop back.
Only the main one has been tuned on the Pi, and that is the one that can not run on the Pi4. It'll therefore immediately drop back to a partially tuned far simpler algorithm, hence results can't be guaranteed. They'll work in many situations, but there will be some corner cases where they go wrong, and that is why we updated to the newer algorithm.

@jtc42
Copy link
Author

jtc42 commented Jul 19, 2019

There are actually 3 different AWB algorithms of varying complexities in the old driver, and if they reported that they couldn't find a sane set of settings they'd drop back.
Only the main one has been tuned on the Pi, and that is the one that can not run on the Pi4. It'll therefore immediately drop back to a partially tuned far simpler algorithm, hence results can't be guaranteed. They'll work in many situations, but there will be some corner cases where they go wrong, and that is why we updated to the newer algorithm.

Okay, thanks for the info. For the time being, that should be fine for us.

This should be an easy fix. Working on it now.

Amazing, thank you! Let me know if there's anything useful we could do. Even just testing or something.

@naushir
Copy link

naushir commented Jul 19, 2019

The changes should be going into the new firmware. If you run a rpi-update early next week, this should hopefully be fixed.

@jtc42
Copy link
Author

jtc42 commented Jul 19, 2019

Thats fantastic, thanks for the super quick fix.

popcornmix added a commit that referenced this issue Jul 23, 2019
kernel: overlays: Add PCF2129 RTC
See: #1190

kernel: overlays: dpi18 and dpi24 vc4 compatibility
kernel: overlays: Add i2c0 and i2c1 for regularity

kernel: Pisound: Remove spinlock usage around spi_sync
See: raspberrypi/linux#3069

kernel: configs: Enable iio driver for TI ADS1015
See: raspberrypi/linux#3083

kernel: bcm2711_defconfig: enable PCI portbus support (and implicitly, PCIe AER)
See: raspberrypi/linux#3086

kernel: FKMS hdmi_timings settings
See: raspberrypi/linux#3082

kernel: overlays: audremap: Support GPIOs 18 & 19
See: #1178

kernel: FKMS overscan support
See: raspberrypi/linux#3090

firmware: Change order of display remapping for default display number

firmware: AWB: Set default number of stats regions for RPi AWB
See: #1198

firmware: Fix composite interrupt HVS channel

firmware: scalarlib: Fix width setting for SCALERLIB_PIXEL_FORMAT_YUV10COL

firmware: vcmailbox: Add a new SET_AUDIO_LDO_STATE mailbox command

firmware: Add mailbox call to report the HDMI timings

firmware: H264: Set the decoder cache AXI burst length to the same as the encoder

firmware: gencmd: Fix gencmd max result length
firmware: bootloader_config: New gencmd to read the EEPROM config

firmware: pwm_audio: Use PWM1 on BCM2838 unless remapped
See: #1178
popcornmix added a commit to Hexxeh/rpi-firmware that referenced this issue Jul 23, 2019
kernel: overlays: Add PCF2129 RTC
See: raspberrypi/firmware#1190

kernel: overlays: dpi18 and dpi24 vc4 compatibility
kernel: overlays: Add i2c0 and i2c1 for regularity

kernel: Pisound: Remove spinlock usage around spi_sync
See: raspberrypi/linux#3069

kernel: configs: Enable iio driver for TI ADS1015
See: raspberrypi/linux#3083

kernel: bcm2711_defconfig: enable PCI portbus support (and implicitly, PCIe AER)
See: raspberrypi/linux#3086

kernel: FKMS hdmi_timings settings
See: raspberrypi/linux#3082

kernel: overlays: audremap: Support GPIOs 18 & 19
See: raspberrypi/firmware#1178

kernel: FKMS overscan support
See: raspberrypi/linux#3090

firmware: Change order of display remapping for default display number

firmware: AWB: Set default number of stats regions for RPi AWB
See: raspberrypi/firmware#1198

firmware: Fix composite interrupt HVS channel

firmware: scalarlib: Fix width setting for SCALERLIB_PIXEL_FORMAT_YUV10COL

firmware: vcmailbox: Add a new SET_AUDIO_LDO_STATE mailbox command

firmware: Add mailbox call to report the HDMI timings

firmware: H264: Set the decoder cache AXI burst length to the same as the encoder

firmware: gencmd: Fix gencmd max result length
firmware: bootloader_config: New gencmd to read the EEPROM config

firmware: pwm_audio: Use PWM1 on BCM2838 unless remapped
See: raspberrypi/firmware#1178
@popcornmix
Copy link
Contributor

Latest rpi-update firmware includes this.

@jtc42
Copy link
Author

jtc42 commented Jul 24, 2019

Latest rpi-update firmware includes this.

Fantastic, thank you! I'll test this as soon as possible.

@JamesH65
Copy link
Contributor

@jtc42 Did you have time to test this? If its all OK, please close the issue.

@jtc42
Copy link
Author

jtc42 commented Jul 26, 2019

@jtc42 Did you have time to test this? If its all OK, please close the issue.

Hey sorry I'm away until Monday but will test it first thing and close the issue if all good. Apologies for the delay.

@jtc42
Copy link
Author

jtc42 commented Jul 29, 2019

Updated firmware fixes this brilliantly. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants