Welcome to our community

Be a part of something great, join today!

  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Rolling shutter different for Scarlet?

Speaking of rolling shutter...

Speaking of rolling shutter...

Hi there,
Anyone know the value of the scarlet rolling shutter inside the foundry shutter plugin?
Red one value is close to 0.32. After a couple of testing I didn't find the scarlet value yet
 
A Fan blade is a really bad test since you really need to capture the exact same angle. The scarlet could very well just be slightly more on the vertical than the other shot.
 
Monte,

I've tracked handheld Scarlet footage in NukeX and it tracks very well.

Haven't tested the read/reset time for Scarlet yet, but will get to that soon.
 
So, I tested both cameras, and there is a difference. Even the Scarlet is better than most other cameras, but the Epic is visibly better:

RS_Compare.jpg

This test is not conclusive at all... The blade on the right may be bigger, but how do you explain the others being larger on the other frame?

Shutter is based on the sensor and it's buffer memory, not the processor. The sensor and it's buffer memory are identical on both cameras.

Better yet, just ask RED themselves. But I am pretty sure they'd say they are identical.
 
I have a Scarlet-X and an Epic-X and right now when I do a whip-pan test with both of them
I cannot really see a difference.

So, most likely they both have the same Read-Reset time.
 
I have a Scarlet-X and an Epic-X and right now when I do a whip-pan test with both of them
I cannot really see a difference.

So, most likely they both have the same Read-Reset time.
Do a rapid, but in the range of usable, pan of a flag pole - something straight up and down and you are panning left/right.

If the straight pole is no longer straight, that's the rolling shutter.

You may not be able to see a significant difference between the Epic and Scarlet with just your eyes.

This video shows what to look for and explains it pretty well:

http://www.youtube.com/watch?v=Zt0u9hsPuZY&feature=player_embedded
 
This test is not conclusive at all... The blade on the right may be bigger, but how do you explain the others being larger on the other frame?

The RS is working in vertical direction, so the blades get larger when moving down and smaller when going up. So, that is consistent, since without any RS all should be the same size.
I got very clear results with exactly the same method when comparing the 5D MII and the RED One, and that's what it's all about for me, relative improvements. Neve tried an iPhone, though. The blades might be all over the place, judging from all the propeller videos on Youtube shot with iPhones :wink5:
 
They seem to be different. But the test is quite hard to judge. It's in this case also dependent on shutter. You need a 360 shutter for this spinning test to be fully relevant. Something moving from left to right in front of cam at constant speed is a better indicator. then what should be "vertical" can be measured as an angle to give a number to the amount of distortion.

I would be supprised if there was a difference.
 
I've done hand-held tests with a Scarlet, panning it side to side at a not-unusual speed, with an 85mm lens and found almost 30degrees of skew on veritcal lines, which was not what I expected to see.

This test was at 3k but I did try 48fps too, which yielded the same results. 48th shutter, although that shouldn't make a difference to skew.
 
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.
 
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.
How did you measure?

Possibly Uli Plank, who has both an Epic and a Scarlethttp://www.reduser.net/forum/member.php?1845-Uli-Plank, can run the test?

14ms is a LOT of delay. I was under the impression it would be in the 5ms range?
 
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 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.

Hmmm. I'm going to have to get my head around the math and why you chose to calculate it that way!!!

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:

http://www.scarletuser.com/showpost.php?p=93030&postcount=3

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.
 
Currently, our Scarlet and Epic are not available for a test.


Uli… maybe you can ask Graeme…

I seem to remember him categorically saying that there was no difference in rolling shutter between Epic and Scarlet as the read out times were supposed to be the same.

Perhaps he meant no significant difference?

I don’t know??

Eric
 
Uli… maybe you can ask Graeme…

I seem to remember him categorically saying that there was no difference in rolling shutter between Epic and Scarlet as the read out times were supposed to be the same.

Perhaps he meant no significant difference?

I don’t know??

Eric
I can't find a comment from Graeme on this, but someone said he said that here:
http://www.reduser.net/forum/showth...shutter-issues&p=907974&viewfull=1#post907974

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.)
http://www.ssontech.com/phpBB2/viewtopic.php?t=478

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:
Back
Top