So I did a rough timing of the Scarlet at 23.976 4KHD and was very disappointed to find a read time of about 14ms or about 1/72 second.
This is no better than the original RED One - maybe a bit worse.
If anyone has gotten a different result or anyone from RED knows the exact spec, please let us know. I would love to be wrong here. But I am quite confident about my methodology.
I measured it by doing a smooth, fast, long lens pan across a vertiical line and examining two successive frames in Photoshop. Used a tight shutter (1/1000) to reduce blur and made sure the vertical line intersected top and bottom of frame.
For the math, first, I found the pan speed in pixels per frame (around 1200 in this case) by comparing the bottom of the skewed vertical in the two succesive frames.
Then I found the amount of skew in pixels by looking at the horizontal offset (top to bottom) of the skewed vertical in each frame (around 400 in this case, and the same in both frames, proving constant speed). The ratio of the two numbers (400/1200=.3333) is the ratio of read-reset time to frame cycle time. Since frame cycle time is 1/24 of a second, read-reset time is 1/72 second.
I did find an un-comfirmed figure of read/reset time of 5ms for the Epic - and that the read-reset time is closely tied to the sensor click-speed. If they've slowed down the sensor clock speed on the Scarlet, it going to be slower.
It's annoying to think that the Scarlet could be slower, as on 2/15 I got an authoritative answer in an email from RED saying that
"I have confirmed with our engineers that the read/reset rate for both EPIC and Scarlet will be the same."
Now, I'm not sure what to think. If they don't publish the figures, I guess there must be a reason not to?
My understanding is that the ARRI has much less of a lag, so I guess there's competition in that regard. But, we should be provided with the facts in order to make an informed decision.
This thread also outlines another interesting way to measure rolling shutter:
And I wonder if the Foundry plug-in's 15 day trial could be used to calculate the offset? (btw - that plug-in, from the reviews I've read, sometimes works and sometimes if there's too much motion, creates a real mess).
Set up both cams, 100mm lens or longer, shoot a van driving past at exactlyish the same speed. (above 100kph would work best).
The math is pretty straightforward, so maybe I haven't explained it well. Basically I'm redefining time in terms of pixels (which you can do with a constant pan speed) and then counting how many pixels, as a unit of time, it takes to scan from top to bottom of frame. Each horizontal pixel accounts for 0.00003472 seconds of panning (1/(24*1200). Since it takes 400 pixels to get from top to bottom of frame (as evidenced by a 400 pixel skew from top to bottom) and each pixel is 0.00003472 seconds, then it takes 0.00003472 x 400 = .0138 seconds to scan from top to bottom. Approximately.
Very disappointing number.
I've heard Alexa is 7ms but haven't had a chance to test it.
I love the Foundry and all of their motion estimation plugins. But they all fall apart in extreme cases and can't be relied on to always fix a slow shutter.
Currently, our Scarlet and Epic are not available for a test.
If you ever get into motion tracking (for the money we are paying, hopefully you will not want to limit yourself to all jobs except those that need motion tracking), here's an explanation of rolling shutter on CMOS cameras affecting SynthEyes (used in many small movies like Avatar, Mission Impossible: Ghost Protocol, etc.)
BTW - Motion Tracking is not just for special effects shots. 'The Girl with the Dragon Tattoo' used SynthEyes and After Effects (all shot in 4K R3D files on Epic and RED MX) to stabilize the footage. So, this will affect a 'normal' workflow if Scarlet has more rolling shutter than the Epic. SynthEyes is very reasonably priced.
1/72 second is a lot of rolling shutter.
I hope the test used to arrive at that is somehow flawed, but ... the math does seem straightforward and logical.
Last edited by Les C.; 03-03-2012 at 08:26 AM.
|« Previous Thread | Next Thread »|