Welcome to our community

Be a part of something great, join today!

Log in
  • 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?

Eric Pascarelli said:
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.
Click to expand...

I had a dialog with Russ Andersson (author of SynthEyes, used to stabilize "Dragon Tattoo", etc.) on your figures.

He stated that for your calculations (outlined in one of your later posts), that they seemed correct, but:

"It would be a valuable double-check if he had measured a stationary frame of the vertical line also, to make sure it is really vertical --- that's actually pretty hard to get right. I wouldn't be surprised if there was a verticalness error of ±50 pixels, which would be ± 2 ms."

I asked him about whether 14ms was going to be a problem with motion tracking and he replied:

"There's no hard and fast rule possible on this. Less skew, less problems. No question 5 msec would be a cheerier number. But can 14 msec work for what you want to do? Probably, but hard to say exactly. 14msec is comparable to a budget CMOS camcorder doing 30i, and that can get ugly. Certainly integrating into green screen is fairly forgiving. Obviously people do do stuff with these cameras. If you were planning to do bouncy handheld "found footage" I'd be concerned. Things with dollies, cranes, jibs should be better. "

I've never gotten a direct answer from RED on the read/reset time - other than the one fellow who told me that he checked with the engineers and they said it was identical on the Epic and Scarlet, which ... does not seem to be the case.

I can only hope that as they have tuned chip production to get better yields (which is normal for a new chip), and that they newer chips used in the Scarlet are faster, but ... I just have no idea whether their firmware would take advantage of that. But, it would probably be set for the worst case read times with no way to tune the clock rate.

What Russ said about the speeds being comparable to a "budget CMOS camcorder doing 30i" is a bit disappointing, especially as I thought I'd put that question to bed weeks ago when I was told the Epic and Scarlet's read/reset were identical.
 
I checked for verticality using the frame lines. It's within a few pixels. So I think 14ms is accurate.

I will do the test again with FW 3.0.
 
With my nVidia graphic card, there's a control panel app to set overclocking. Maybe RED could provide something like this, where we could up the clock rate within sane boundaries?

nVidia users typically find a value where they can reliably overclock. Probably dependent upon ambient air, the cooling system in the computer and how their individual chips respond.

Overclocking can also be used with computer clock rates. The RED cameras are very fast computers with custom ASICs.
 
Just tested Scarlet again, under 3.0 firmware, and this time at a project setting and shooting fps of 29.97. I got a similar result - 14ms.
 
Eric Pascarelli said:
Just tested Scarlet again, under 3.0 firmware, and this time at a project setting and shooting fps of 29.97. I got a similar result - 14ms.
Click to expand...
OK, we know what the rolling shutter value is for the latest firmware.

We know what the author of SynthEyes motion tracking software said about that value "14msec is comparable to a budget CMOS camcorder doing 30i": http://www.reduser.net/forum/showth...nt-for-Scarlet&p=963306&viewfull=1#post963306

What we don't know is whether the clock rates are fixed in the Scarlet, or whether they can be tweaked in firmware.

But, unless we hear from from RED on this issue, 14ms is what we have to deal with.

BTW - I wonder what the delay is at 2K?
 
Last edited:
Another note - just received the Nikon D800 DSLR.

Very impressive video features and quality - noticeably better than any DSLRs I've used.

Tested the rolling shutter and it's the same as Scarlet - around 14ms.
 
I haven't had time to test my Scarlet myself, but 14ms vs 5ms sounds quite disappointing considering Graeme from RED specifically told me rolling shutter on Epic and Scarlet were identical a few days after the Scarlet announcement.

Admittedly, though, 1/60th sec readout rate is about what I've become used to on every camera I've owned since my EX1 so I don't suppose it is a big problem for the work I do, but it always helps to have more, especially in certain situations. I guess I still won't be shooting that shakycam action short I've always wanted to do :P
 

Attachments

  • temp.jpg
    temp.jpg
    45.8 KB · Views: 0
Noah, I am not sure that the cameras are actually different thought the fan test early in this thread seems to indicate it.

I have only ever tested Scarlet and found it to be a disappointing 14ms. I have never seen a number for Epic. No one on the forum has done a numerical test that I know of.

I doubt the Epic is as fast as 5ms. If anyone has an Epic to test I am happy to help determine its read time.
 
im disappointed by the rolling shutter, too.
its as bad as my old 7d it seems.
the suppose negligable rolling shutter was a big selling point for me, and am very frustrated by its severity in the field.
the c300 has less on a 35mm sensor. bummer.
 
Noah Yuan-Vogel said:
I haven't had time to test my Scarlet myself, but 14ms vs 5ms sounds quite disappointing considering Graeme from RED specifically told me rolling shutter on Epic and Scarlet were identical a few days after the Scarlet announcement.

Admittedly, though, 1/60th sec readout rate is about what I've become used to on every camera I've owned since my EX1 so I don't suppose it is a big problem for the work I do, but it always helps to have more, especially in certain situations. I guess I still won't be shooting that shakycam action short I've always wanted to do :P
Click to expand...

Interesting that Graeme would say that. I had a RED rep on 2/15/12 tell me clearly that "I have confirmed with our engineers that the read/reset rate for both EPIC and Scarlet will be the same.", so this is confusing.

As I'm buying a $15K camera and asking the sales team very directly what kind of horsepower it has, the correct answer is important to me.

I would love to hear that the Scarlet just hasn't been run at full throttle yet, and that a future build will resolve that.

I think you have better connections that I do! Maybe ask Graeme if that has changed - or post a thread here like "RED - what are the rolling shutter delays for the Epic and Scarlet" and see if anyone steps up to the plate?

If no one from RED answers, silence is also an answer.

BTW - I haven't seen any confirmation of a test for Epic at 5ms. Maybe it's 14ms for the Epic also, in which case the responses we got from RED were correct.
 
I don`t Own a EPIC but I had a few moments with one last week, and I did a little test for quick pans and for me the rolling shutter was very noticeable, I would say maybe almost as much as the RED One. Of course it was just a little impression from judging from the LCD, but it was definitely there. But in the other hand, my impression was that it was similar to the rolling shutter test of a Scarlet that it was posted here a few weeks ago... It was on the beach if I recall.... No where near the 7D...
 
Where are the Red fellas!?!?! This is going to turn into another "overheating" situation if it is not addressed. 14ms is WAY slower then they had promised (even slower than Red One), and I have a hard time believing that number. Anyone from Red care to comment? Please?
 
Whoa ... A marked reduction in rolling shutter vs. the competition was my main reason to invest in the RED system.

With extreme respect for RED's massive engineering effort on these products, and this is crazy speculation, would it be possible add a feature to the firmware to:

Have a user-selectable mode to do a faster readout at the expense of heat generation -- that is, having the camera go to a standby "I won't image anymore (no picture) until I cool down"? Such a mode might not necessarily wait but would proactively duty cycle or even give you a countdown until it has to take a break. I don't know if the hardware is capable of changing this behavior in software or perhaps FPGA reprogramming ... Like I said, pre speculation ...
 
Rodrigo Prata said:
I don`t Own a EPIC but I had a few moments with one last week, and I did a little test for quick pans and for me the rolling shutter was very noticeable, I would say maybe almost as much as the RED One. Of course it was just a little impression from judging from the LCD, but it was definitely there. But in the other hand, my impression was that it was similar to the rolling shutter test of a Scarlet that it was posted here a few weeks ago... It was on the beach if I recall.... No where near the 7D...
Click to expand...

I did a quick google and there seems to be 25ms for the 7D except in 60p mode where it may be 12.5ms (these figures may not be correct).

However, we do know that the measurement of 14ms for the Scarlet is correct, I ran the calculations by someone who would know.

Russ Andersson, the author of SythEyes (motion tracking software used in Avatar, Dragon Tattoo, etc.) has a lot of experience with rolling shutter. He said "14msec is comparable to a budget CMOS camcorder doing 30i"

It would be nice to have clarification from RED as to whether these values are set in stone.

Clint Lealos said:
Where are the Red fellas!?!?! This is going to turn into another "overheating" situation if it is not addressed. 14ms is WAY slower then they had promised (even slower than Red One), and I have a hard time believing that number. Anyone from Red care to comment? Please?
Click to expand...
Was there ever a 'promised value' for the rolling shutter?

I think we just assumed it would be smaller.

If you have something to brag about, you are very quick to publish the specs.

I don't really believe that RED ever stated the exact values, only that Epic and Scarlet would be identical (at least in their response to me on 2/15 for read/reset time and what Graeme replied to Noah a few posts above).
 
The expectation (perhaps quite incorrectly) I had is that since EPIC can scan at least 1.2GP/s given ~13MP/5kframe*96frames/s, EPIC(and Scarlet if it has "identical" rolling shutter) should be able to read out a ~8MP 4k frame in less than 7ms or about 2-3x as fast as most cameras which are commonly ~17ms at best (1/60th). In the end maybe the difference isnt that great.
 
I myself am quite surprised by the amount of RS skew in my test shots (which I did purposely to test for the skew). While not as bad as Canon 7D or 5D, the skewing is still pretty obvious. Having worked extensively with RED ONE, I get the impression that the RS issue is similar in both RED ONE and Scarlet, which is surprising as I remembered reading in this forum that the EPIC's readout is supposedly faster (hence less RS) and that Scarlet's would be similar to EPIC.
 
The developer of SynthEyes has added a method for dealing with rolling shutter to SynthEyes.

His new white paper outlines how to calculate it and a method for dealing with it (not 'correcting' it - which is pretty much impossible as you can have multiple objects moving at different rates and directions in the scene, along with the camera's motion - all generating their own unique effects which can't really be 'fixed' with any software)

http://www.ssontech.com/content/RollingShutter.pdf
 
You must log in or register to reply here.
Back
Top