Understanding Flicker Banding

[mattday]

I'm in the UK where the AC frequency is 50Hz, so indoor lighting will usually either flicker at the same rate, or twice, i.e. 100Hz. The time for one complete oscillation of the light intensity is then either 10ms or 20ms. Setting the shutter speed to a multiple of this makes sense. If you always have a complete number of oscillations, then you should always have the same amount of light per frame regardless of when you start sampling.

However, it will not always be possible to choose a shutter speed of 1/100s (i.e. 10ms) or slower. For example, you might need to capture fast movements. From a related topic:

If your exposure time is not a multiple of 10ms (assuming 50Hz mains) then you'll get banding due to uneven lighting. If the exposure time is <10ms, then there's nothing you can do about it.

If the exposure time is less than one complete cycle of the flicker, different amounts of light will be captured in each frame (unless we can start sampling at exactly the same point in the flicker cycle for every frame). So that will appear as flicker in the captured video. What is not so obvious, is how this manifests in each frame.

Here is a frame captured in a room with only fluorescent lighting using a 5ms exposure time (raspivid with parameters -ss 5000 -fps 25)

5ms_25fps.jpg (214.06 KiB) Viewed 695 times

For comparison, using a 10ms exposure time there is negligible banding (raspivid with parameters -ss 10000 -fps 25)

10ms_25fps.jpg (159.53 KiB) Viewed 695 times

There is clearly another factor coming into effect here to create the multiple bands within the frame, because the sampling period for the frame is less than a single flicker cycle. I would really like to understand what this factor is.

[6by9]

Two little words - rolling shutter.

https://picamera.readthedocs.io/en/late ... osure-time is a pretty good explanation.
You don't say which camera version, resolution, or sensor mode you're using, so I'll take the V2 camera in mode 5 (1640x922) as an example.

The sensor starts exposing line 1 at time t=0.
In that mode each line takes 18.9us to read out, so line 2 starts exposing at t=18.9us.
At t=5ms the sensor has started exposure on line 264, and starts reading out line 1.
At t=10ms (the flicker period), line 529 starts exposing, so it will have the same illumination as for line 0.
(At t=17.4ms the last line has started exposing, so at t=17.4+5 = 22.4ms the sensor has read out the whole frame and will be adding blanking lines until t=40ms to achieve your 25fps.)

So in that example I would expect 1.7 bands to be visible in the output image. The line length (in usecs) and frame length (in lines) varies between modes, so the number/height of the bands will vary.
The intensity variation will depend on the exposure time as a percentage of the flicker period. In your example, the worst you could achieve would be from -2.5ms to +2.5ms around the mains zero crossing point. Assuming a sinusoidal illumination pattern (not true for fluorescent lights), that would have a maximum intenity of sine(45) = 0.707 of the peak intensity. If you shorten the exposure time to 1ms, then maximum would be sine(9) = 0.156 the peak intensity.

That is why I said that if your exposure time is less than the flicker period then there is little you can do.

(Global shutter cameras would at least make each frame uniformly illuminated, but then the frame rate has to be a multiple of the flicker period to avoid variation between frames. They're also generally lower resolution, significantly more expensive, and there isn't one that works with the Pi firmware).

[mattday]

I suspected it was related to rolling shutter, but that explains it perfectly. The key point, not previously obvious to me, was that the time from top to bottom of frame can be several times longer than the exposure time (which only applies to any given line).

Perhaps if a mechanism existed to precisely synchronise the start of each frame with the same point in the lighting flicker cycle, then from one frame to the next, the bands would appear static and could be removed/reduced via post-processing. Not a practical suggestion, more speculation that some cameras may be taking this approach to avoid global shutter.