AeFlickerPeriod not taking effect?

[kbingham]

I'm trying to capture some tuning images for the IMX335 on RPi5 - which shows very visible flicker / horizontal banding unless the exposure is explicitly a multiple of 10000.

Using camshark, I can explicitly disable AeEnable - then set ExposureTime to 10000 and the flicker/banding goes away - but the AE is now disabled, instead of being active - but flicker-free.

I've tried setting AeFlickerPeriod to 10000 and setting AeFlickerMode to 1 - but I do not see a response/change in the ExposureTime, which is still coming out at 4882 instead of a multiple of the AeFlickerPeriod ?

Any known issues around this ? or am I doing something wrong ?

(I'm on top of https://github.com/raspberrypi/libcamera/tree/next)

[kbingham]

Is it common to require anti-flicker when tuning ? or am I missing something else fundamental.

With my lightbox, the RPi AGC is targetting an Exposure time of around 4500, while anything other than a mulitple of 10000 causes this oscliating flicker:

Screencast.from.02-06-25.17.24.53.webm

But when I try to take tuning captures with:

• rpicam-still -t 5000 --shutter 10000 -r -o imx335_${TEMP}k_${LUX}l.jpg

then the CTT reports macbeth detection errors for each capture:

Confidence: 0.802
WARNING: Macbeth patches have saturated!
Image discarded!

So it seems I need a multiple of 10000 which is less than 10000 ? ... (or a gain of 0.5?)

[naushir]

@davidplowman

[6by9]

I wouldn't expect it for any form of LED lightbox as the mains supply will have been converted to DC before feeding to the LEDs.

Generally it will be fluorescent based light boxes that will have issues as they "strike" every half cycle.

[kbingham]

No LEDs in this lightbox - bulbs and tubes ...

[6by9]

Filament bulbs shouldn't have an issue as they have enough "thermal inertia" to retain brightness across the half cycles.

It's the tubes, and there's very little that can be done to overcome it.

You could add a neutral density filter to reduce the image brightness, but that may have some effect on the tuning.

[davidplowman]

I'm not aware of any problems with flicker avoidance on the Pi, so far as I know it works but can re-test tomorrow. I don't think we have an automated test for it - evidently I should add one!

I've never had to use it for tuning using our lighting cabinet, however, there seem to be no problems with flicker there.

I'm not sure a bit of flicker would have a very great effect on our camera tuning tool. (Obviously LSC would be a problem, but hopefully you're not having a problem with those images.)

[kbingham]

I suspect the issue is that in this bright environment, the FlickerPeriod is unachievable because the required ExposureTime is less than the FlickerPeriod ...

The flicker is showing up quite prevalent indeed in the LSC - but fixing this to --shutter 20000 is a fine solution for those at least.

There were some issues on the CCM with the colour tuning - which is where I headed down this path of avoiding flicker ...

I'll try tuning the colours without avoiding flicker again and see how far out I get.

[davidplowman]

True, if the exposure time is less than 10ms, not much you can do. As regards LSC, what kind of lamps you using? You certainly need to turn them down or get an ND filter - carefully programming the banding into the LSC tables sounds like a super-bad thing!!

[kbingham]

2701

3025

4021

4125

6521

My current working theory is that the banding is causing things like the pink splodges on 3025 and 4021 ... (I've had other unexpected bright splodges like reds on the blacks etc too ...)

[kbingham]

True, if the exposure time is less than 10ms, not much you can do. As regards LSC, what kind of lamps you using? You certainly need to turn them down or get an ND filter - carefully programming the banding into the LSC tables sounds like a super-bad thing!!

I've got a white plastic card over the lens pointing up at my lights in the lightbox - as longs as I fix to shutter speed 20k, this seems fine at the moment. It's the colour corrections I want to get right before I submit to you ;-)

[kbingham]

Re-done without worrying about shutter time on the CCM captures. Maybe it's fine to use as a base tuning :-)

uncalibrated.json:

imx335.json

[kbingham]

Anyway - I think the answer to AeFlickerPeriod not taking effect is clear - it wasn't possible!

Out of the light box - I can confirm AeFlickerPeriod works as expected. (Setting steps of AeFlickerPeriod = 7000, 8000, 9000 clearly locks to multiples of those)