RED Rocket

[oldphart]

Sorry, you lost me there. It clear that more resolution means less visible pixies. But there is a limit to that, because of the resolution of the human eye.


I read that "The eye can resolve two black lines on bright background separately if the distance between them (from center to center) is at least 0.05 millimetres (40 arc-seconds, considering 25cm of viewing distance).

Or in an other way: "In modern studies, like Curcio et al. (1990), acuity is measured in cycles per degree. Curcio et al. derived 77 cycles per degree, or 0.78 arc-minute/cycle. Again, you need an minimum of 2 pixels to define a cycle, so the pixel spacing is 0.78/2 = 0.39 arc-minute, close to the above numbers."

That results in 24 pixels per degree. So a HD-TV with 1920 horizontal resolution would have destinguishable pixels when it covers about 80° of our viewfield. For easy calculation let' say 90°. An object takes up 90° in our horizontal viewfield when it is at half the distance as its horizontal dimension. So a 50" monitor could have indistinguishable pixels when you sit 25" away from it. And that would be quite close if you think about it.

A 4k projection may even take up as much as 170° of our horizontal viewfield without a pixel been detected. Imagine how close that is in relation to the dimensions of the screen. Let's say 50" and it's there right on your nose.

Just a hypothesis... please correct me if my assumtions are wrong!


Edit: With a 4k 50" screen that would mean a distance of about 2 inch.

My experience is that pixels are visible in a 2k digital cinema if you sit close to the screen. Not consistently, but enough to be annoying.

I suspect that the Nyquist theorem applies even to our quite subjective vision. Thus, linear resolution in quantized systems needs to be twice as high as the reliable visual resolution of the human eye.

For good immersion, the picture will need to cover 120 degrees. This worked quite well in old curved-screen systems like Cinerama and Cinemiracle. To obtain this, we need a minimum of 2880 pixels. In order to be certain that there are no visible artifacts from quantization, I would like to double that. That would leave us with 5760 horizontal pixels.

I suppose 4k will do, but from experience I will claim that 2k is not enough. I can see pixels on my Eizo monitor if I lean forward enough to fill most of my field of vision.

 

[Alex Dobbie]

Are cinema screens still perforated ? How many pixels in 5k would go through the perforations ?

 

[Gavin Greenwalt]

I'm looking at my monitor right now. (24" 1080p) and I can see the dot pitch *BETWEEN* the pixels at around 50degree fov. That would imply that detail is perceptible at over 12k on a 90fov screen.

 

[Graeme Nattress]

Yeah, I think there's a slip in the math... 1920 pixels, 77cycles needed per degree, is 154 pixels per degree, 12 degrees. Check my math someone... I'm still recovering from NAB.

 

[Shane Betts]

Thinking out loud

Thinking out loud

Hmm. Questions unanswered. (thinks) What does this mean? Red Rocket and Red Ray are interconnected. So Red Rocket is converting from R3D RAW (or RGB?) to Red Ray on the fly, which is then a cinch to decompress on the way out.

Temporal compression is unconfirmed but, even if Red Ray does employ it, it won't be embedded in the clip, just used in the RT stream. So it shouldn't affect the editing process as the NLE is dealing with real frames. And same deal with DVD release items.

Currently (low cost) coloring and compositing apps are playing a down-sample on play (often pixel binned) and then full res on pause. Red Rocket using Red Ray would mean a higher quality (if still down converted) play stream and, one presumes, back to (practically indistinguishable) full res on pause.

So, no matter how it's done, Red Rocket is going to be invaluable and very, very cool. I'm still very excited - but I would like to know...

 

[Roberto Lequeux]

So will we be able to get a downconverted 1080p RBG our of the card from 5k?

Or will the Red Rocket only handle the debayering?

We know the Red team is hard at work. I am trying to be as patient as possible.

 

[Jannard]

Full specs well before delivery... best we can do right now.

Jim

 

[Roberto Lequeux]

Full specs well before delivery... best we can do right now.

Jim

Thanks a million Jim. Hearing back from you makes it easier to be patient.

 

[Jeff Kilgroe]

Temporal compression is unconfirmed but, even if Red Ray does employ it, it won't be embedded in the clip, just used in the RT stream. So it shouldn't affect the editing process as the NLE is dealing with real frames. And same deal with DVD release items.

I don't know if Jim or Graeme are ready to clarify this yet, but I don't think I'd be going out on a limb to say that the RED RAY codec is not an editing codec. As in it's meant primarily for distribution and we could be taking a serious quality penalty or generational loss by using it for editing.

 

[Robert Frank]

Maybe REDflix.

Maybe 4kforindies?

Remember what I said way back Mark?

 

[Graeme Nattress]

REDRAY and Rocket Are different products.

Graeme

 

[Theo Valich]

RED SDK is not running on pixelshaders/GPU, hence it won't benefit from CUDA. At least as of now.

Greetings,

I am not sure what GPU are you referring to, since starting in 2006, graphics chips no longer have pixel or vertex shaders. DirectX 10 API introduced Unified Shader Architecture, thus both ATI and nVidia are shipping GPUs with universal SIMD cores that can do pixel, vertex & geometry shader instructions. Upcoming DirectX 11 API enables existing DX10 cards to use Computational shader as well.

AFAIK, RED SDK could use either CUDA or OpenCL to gain access to GPU hardware. GPU is nothing else but a stream processor and video is a stream processing operation. Given the current trend of streaming applications gaining 15-100x performance increase by switching to GPU Computing, not using the GPU in some way doesn't make sense.

That's just my $0.02

 

[Kyle Mallory]

I am also curious what clip you were looking at. Since we can't tell the difference in any clip, it might have been the clip itself. But I'd be happy to post a side by side grab if I knew which one.

Jim

Jim,

I want to say it was one of the ones with a lot of trees or other high detail. I remember thinking "evil tree from hell" and the pre-build 16 days. But in all honesty, I may be thinking of the same shot in the 400 reel that I was like "holy shit! that is amazing detail!" It really was a whirl-wind ride. The best I could offer is that it was somewhere within the 2nd quarter of the reel, otherwise if you want to send me a copy of the 300 reel (even low quality) it might jog my memory more.

 

[Gavin Greenwalt]

Greetings,

AFAIK, RED SDK could use either CUDA or OpenCL to gain access to GPU hardware. GPU is nothing else but a stream processor and video is a stream processing operation. Given the current trend of streaming applications gaining 15-100x performance increase by switching to GPU Computing, not using the GPU in some way doesn't make sense.

That's just my $0.02

The problem isn't the concept. It's the execution. They simply haven't done it. (REDCine uses the GPU) but the SDK doesn't... ?yet? I think the OP was refering to the current state of the SDK not the capability.

 

[Roberto Lequeux]

Jim,

I want to say it was one of the ones with a lot of trees or other high detail. I remember thinking "evil tree from hell" and the pre-build 16 days. But in all honesty, I may be thinking of the same shot in the 400 reel that I was like "holy shit! that is amazing detail!" It really was a whirl-wind ride. The best I could offer is that it was somewhere within the 2nd quarter of the reel, otherwise if you want to send me a copy of the 300 reel (even low quality) it might jog my memory more.

It's been posted on the Surprise thread. Maybe you can find it? I am sure Jim and Graeme would appreciate being able to checking it out. I can't believe I didn't go.

So will there there be an LA screening?

 

[GlennChan]

Don't have time to read through all the posts, but Dalsa was doing this on a GPU. But I'm not sure if they could output to a 4K monitor (it would output to a 4xHD computer monitor), and don't know about the image quality. (And it didn't have to decode wavelet compression.) Of course, they are no longer in the digital cinema business...

2- Who cares who was 'first' (and Red has enough of those already)... this still looks badass and very useful!

 

[Sindre Saebo]

I seriously doubt that RED RAY will output SD - for one thing, all the renders only have HDMI and SDI outputs. And really, there's not really any point to having it anyway - if you're buying a $1000 video playback device, you're not going to be using it with an old analogue SD TV...

Yes Stephen, I agree completely regarding what comes out of the physical outputs of the box. But I'm talking about what we might expect from the codec itself, as file output options. For streaming purposes if bandwith is an issue, like YouTube, I prefer visually lossless SD before YouTube "HQ" any time.

Sindre Saebo
Oslo, Norway

 

[Shane Betts]

I don't know if Jim or Graeme are ready to clarify this yet, but I don't think I'd be going out on a limb to say that the RED RAY codec is not an editing codec. As in it's meant primarily for distribution and we could be taking a serious quality penalty or generational loss by using it for editing.

Well, Graeme's just said the two are separate products and as I said, just thinking out loud - trying to get my head around it. What the Red team are achieving in terms of Red Ray is a bit of a mind fuck (for a bear of very little brain like myself) - visually lossless 4K at 10Mb/s - WOW.

The statements we've been seeing from the show indicate the codec is extremely strong and we might see less penalty in terms of image quality on the screen than editing in ProRes or DNxHD36 - and all without the need for a transcode.

But - bear in mind that what I'm postulating on is not a transcoded file but an on-the-fly compress/decompress - if Red Rocket did use Red Ray as a display codec and if Red Ray is temporally compressed, we'll only be seeing that at full speed playback, so its impact would be negligible. The 'i' frames would move about depending on where you hit play and you won't be making cuts on reference frames - your cut decisions will refer back to the original, non temporally compressed, R3Ds. Pause, rock 'n' roll over a cut, no compression - so no issue.

Anyway, from Graeme's statement my entire thread appears moot but either way, Red Rocket sounds like a great asset and one I'll be lining up for when it goes on sale.

 

[Felix K.]

Yeah, I think there's a slip in the math... 1920 pixels, 77cycles needed per degree, is 154 pixels per degree, 12 degrees. Check my math someone... I'm still recovering from NAB.

You are of course right. I got a devision by two mixed up with a multiplication by two. Sorry for that.

 

[Jeff Kilgroe]

Well, Graeme's just said the two are separate products and as I said, just thinking out loud - trying to get my head around it. What the Red team are achieving in terms of Red Ray is a bit of a mind fuck (for a bear of very little brain like myself) - visually lossless 4K at 10Mb/s - WOW.

Yep separate products, I was just responding to to the above mention of using the RED RAY codec for editing. Not sure if it will be intended for that. I'm also betting that the codec is RGB/ YUV and does not specifically retain the actual RAW image data. If the codec can be made frame-accurate, then it could be a good candidate for proxy editing. But if the RED ROCKET will accelerate REDCODE RAW for real-time playback, color, editing, etc.. Then what would be the point of transcoding to RED RAY format for editing?

Anyway, from Graeme's statement my entire thread appears moot but either way, Red Rocket sounds like a great asset and one I'll be lining up for when it goes on sale.

Same here.