Now that it seems more likely that the video DR Boost implementation is similar or the same as the DR-boosting behavior of the photography mechanical shutter, I've started visual experiments to reverse-engineer a potential dual-gain readout of the sensor.
Revisiting sensor readout rate
As I
measured here, the 6K24p open-gate (5952x3968) readout measurements using my
rolling shutter measurements are as follows:
- DR Boost Off: 1/66.85 (14.95 ms)
- DR Boost On: 1/29.31 (34.11 ms)
Those measurements are taken by pulsing an LED at 500 Mhz and counting the number of resulting bands. The bands occur because as the sensor readout progresses vertically down the frame it is capturing the on/off cycles of the LED. The slower the readout, the more bands captured in the resulting image. The total readout rate is then calculated by measuring the number of bands vs total # rows in the image .
How can we reverse-engineer potential DGO?
The pulsing LED is great for precise rolling shutter mechanism but it lacks any spatial information because it's a single LED, ie the rows across the sensor either see the LED on or off, with no information about the progression or what happens in between.
The theory of the S1 II's DR advantage is that it's using a dual-gain readout, where the sensor is performing two full readouts across the sensor - one at lower gain (LCG) and the other at higher (HCG), then combining the two. These two full readouts is why the readout rate is 2x+ longer with DR Boost On (34.11ms) vs Off (14.95 ms).
But consider what is occurring during these two separate readouts. The first readout is simple - reset the sensor rows, wait the integration time (shutter speed), then readout the sensor rows. But what happens for the second readout? Did the first readout deplete the charge in those sensor rows, as normally occurs on a CMOS sensor, and if so, did the camera use a second, overlapping integration so the rows can accumulate a new charge for the second readout (ie, a T1/T2 DOL HDR implementation)?
Or is the sensor somehow retaining the charge after the first readout and is just reading out the second at the different gain? Presumably the photography implementation of this DR boost would have to work this way since it works with the mechanical shutter, which means it's not possible to perform a second exposure integration for T1/T2 since the shutter is only cycled once, unless there is some type of hybrid electronic+mechanical shutter being used.
These are the questions that need to be answered to fully understand how the camera/sensor implemented its HDR.
DGO sniffer
To understand what is happening during DR boost's first and second readouts it would be helpful if we could somehow alter the scene while the sensor readouts are occurring so that it changes between the two readouts. We could then analyze the resulting HDR frame generated by the sensor and try to figure out which parts came from the first version of the scene and which came from the second.
This lead me to create a new Windows app today I'm calling "DGO sniffer". Right now the implementation is simply:
- Draw a single vertical line on the screen
- 4 ms later, draws a second vertical line next to the first
- Repeat until the window is filled with lines
I chose 4 ms because my monitor has a 240 fps refresh rate; drawing the lines any faster than 4 ms will simply mean multiple lines rendered for each refresh cycle.
I then record the screen with the camera and analyzed the individual video frames. I used a 1/2000 shutter @ 24fps. Each video frame will capture a different phase of the DGO sniffer's cycle, since there's no way to interlock/sync the beginning of the sniffer's cycle to the camera's readout of frames. So I have to scrub through the resulting video to find frames where the two somewhat aligned.
Here's one of those frames with DR boost off:
Video Frame: 6K24p DR Boost Off
While the sensor is being read-out one row at a time from top to bottom, my DGO sniffer is drawing a new vertical line at 4ms intervals. That means the number of vertical lines "seen" (ie, captured) for each row in the resulting video frame increases by one every 4ms. But only the first line captured will be a full-height line - the subsequent lines will get smaller and smaller because those lines didn't exist at the time the previous rows were read out. That is what's demonstrated in the above video frame.
Since there's no way to sync the DGO sniffer's drawing to the sensor capture, nor is the multiple of lines to readout even, the number of lines captured by the sensor wont precisely match the maximum lines that could've been captured. For example, a DR Boost-off 6K24p readout is 14.95ms, which means I should be able to capture 14.95ms/4ms number of lines (3.7375). To account for this, I can simply measure the height difference between any two lines and extrapolate the readout rate for the full frame, which I do as a sanity check to confirm the timing of my DGO sniffer app.
Here's that same frame but with the readout rate calculation performed for two lines:
Video Frame: 6k24p DR Boost Off, Readout Rate Calculated
This isn't as precise as the 14.95 ms rate calculated from a flashing LED but that's ok since I'm only doing the calculation to confirm the timing of DGO sniffer. This conformation is necessary because there are many factors which can interfere with the timing of the app, including system latency, display refresh cycles, display response time (ie, black -> white pixel transition times), phase differences between monitor refresh and sensor readout, etc.. etc..
Here is the same confirmation performed with DR Boost On:
Video Frame: 6K24p DR Boost On
Video Frame: 6K24p DR Boost On, Readout Rate Calculated
So far so good. But does this give us any new information about what the sensor is doing for two potential readouts that we're not getting with a simple LED? Not yet. But now that I have a way to precisely control the content the sensor sees between its two potential readouts, I can now alter that content and instrument what the resulting captures looks like to help tease out what the sensor is doing...
