snapsy
Online
• • • • • •
Upload & Sell: On
|
 p.3 #15 · p.3 #15 · Call for help - building sensor readout speed database | |
rscheffler wrote:
While I don't shoot with stacked sensor cameras, rather the Canon R6 and R6II, I've found Canon's high speed flicker compensation in the R6II quite useful for some stage lighting situations. In my case, corporate events. The spots used at these are LED and often dimmed quite a lot because they're used in smaller venues and the corporate execs doing the on-stage presentations don't like bright stage lights in their eyes... At the most recent event I did, the flicker compensation feature indicated these spots operated at 1200Hz. The e-shutter banding in these situations with the R6II was fairly faint, but still noticeable if you looked for it because there were numerous bands. My guess is the a1/Z9 would still see some banding but it would be quite broad and probably disguised by the scene unless there are a lot of blank, even-toned surfaces. Based on the calculations in the above example of the LED at 1920Hz, the scenario I was in, if shooting with an a1 or Z9 would likely have resulted ~9 bands across the frame.
FWIW the high speed flicker compensation feature works very well, but is an additional step that has to be done (camera analyses the light and sets/recommends the correct shutter speed). ...Show more →
Thanks for this. I've done the math of what Canon is doing and it checks out 
In the scenario you described, you had 1200 Hz lights and the R6 II's automatic fractional shutter speed logic selected a speed just south of 1/400.
There are two factors at play here. First, by using a slower shutter speed relative to the light cycling frequency, each sensor row is capturing multiple cycles of light. This means the brightness difference of the bands between rows receiving +1 or -1 cycles vs other rows is less noticeable. For example, on a light source cycling 1,000 times/sec, a 1/8000 shutter will capture on average 1 cycle of light, meaning some rows will have 100% and others 0% - a very noticeable 100% difference. Drop the shutter down to 1/250 and some rows get 4 cycles while others get 3 - much less noticeable 33% difference. This is why bands become less noticeable at slower shutter speeds. They start to blend together and fill in the black gaps since the brightness difference of missing a light cycle becomes less and less.
Second, the camera is selecting a shutter speed that's an even multiple of the lighting cycle rate. This puts all the rows in alignment with the light cycling phase, reducing the partial-cycles on some rows that increases the visibility of the bands.
Here is a demonstration and the math to support it. First, here are images of the Arduino 500Mhz LED taken with the Z6 (1/20 readout speed) at various shutter speeds:
Animation: Z6 Arduino 500Hz LED, Various Shutter speeds, 100% crop (5MB)
Notice how delineated the bands start at 1/8000, and how even the band height is between the "on" and "off" bands. This is because the shutter speed is fast enough to capture only a single cycle of light, so it's a binary situation on the resulting photograph. As the shutter speed gets slower the bands get fuzzier and the "on" bands become larger than the "off" bands, reaching the point where the "off" is not really off but just darker than the "on" bands. This was discussed above - it's the result of a 1 cycle difference representing a smaller percentage of the total light captured, thus less distinct between rows capturing all cycles vs those capturing all cycles minus 1.
As the shutter speed reaches 1/500 and slower you'll see the banding visibility vacillate between increasing and decreasing. This is due to the second effect I described - the alignment of the shutter speed vs the cycling frequency of light. Here's a spreadhseet with the simple math behind this:
Bit of an eye chart but this sheet depicts the following:
* Nominal shutter speed vs actual exposure time. As many of you may already know, some of the shutter speeds depicted by cameras are rounded to make them easier to understand but the actual exposure time is not rounded, so there's a differential in exposure. Normally this doesn't matter since we all think in EV's but in this case it matters since we're matching to a known LED lighting frequency. "Nominal" represents what the camera depicts the shutter as to the user. "Actual" is what the actual exposure time is for that nominal shutter speed. "Nominal -> Actual Diff" shows the difference between the two as a percentage.
* The aligntment of the actual shutter speed to the cycling frequency of the Arduino 500Hz LED, represented as a percentage of misalignment. A 0% value means both are aligned perfectly. 10% means they're misaligned by that amount, relative to their total time, etc... The smaller the misalignment, the closer the exposure time is to the LED cycles, and the less visibility of the banding.
I've highlighted the two actual shutter exposure times that have the best alignment to the LED, and those match the lowest visibility of banding around their respective peer shutter speeds.
|
