4K RAW data rates

Stuart English

Stuart English

Red Team
There has been some speculation on various boards as to the accuracy of our stated data rates for 4K RAW uncompressed data - i.e the data rate PRIOR to compression... The math is as follows :

4K at 24fps RAW - 4096 x 2304 x 24 x 12 / 8 / 1024 / 1024 = 324MB/s ..

After REDCODE RAW compression this is reduced to about 28MB/s (224Mb/s)

From the high speed data port, our maximum uncompressed data rate is -

4.5K at 60fps RAW - 4520 x 2540 x 60 x 12 / 8 / 1024 / 1024 = 986MB/s (7.888 Gb/s)
 
is it possible to transfer data at almost 1GB a sec without fry the sensor.? Is there such hard disc capable of that?
 
When it gets REALLY fun is when you take that 60fps RAW data @ 986MB/sec and process it to a linear or logarithmic image sequence (DPX, Tiff, whatever.) Im not sure what the data rate would balloon to but I suspect it would be over or close to 2GB/sec (thats Giga Bytes!.)

So that wold mean youd need 1.2TB of storage to hold 10 minutes of 60p 4k uncompressed footage, hooray!
 
tucamone said:
is it possible to transfer data at almost 1GB a sec without fry the sensor.? Is there such hard disc capable of that?
Click to expand...

There is no single drive that can handle that data rate but there are many RAIDS which are plenty capable, course they cost a pretty penny.

Anyone interested in a 4k uncompressed DI workflow should be looking into getting the new Quad 4GB Fibre Channel HUGE Media Vaults 4440 capable of 1.5GB/sec. They'll cost you a few REDS.
 
a 36 drive array should be able to handle the data rate comfortably.

a 12 drive array can handle 24p, and with RED CODE, all you need is a single 3.5" or dual 2.5" drive.
 
If I read this forum correctly, the camera will have between 32-64GB of onboard RAM to supplement the main storage. This would absolutely make sense - if you need a speed ramped shot up to 60/120fps, then the main storage magazine may not be able to do it in real time even with RedCode.

BUT.... if you can do a take with the footage going into RAM until the take is over (it would have a time limit obviously based on amount of RAM), then automatically transfer it to the main storage while you reset for take 2 etc, you'd have the problem licked. Seems like a brilliant answer to the problem of high speed footage acquisition at 4K. I hope I'm close to the mark...
 
Stuart English said:
There has been some speculation on various boards as to the accuracy of our stated data rates for 4K RAW uncompressed data - i.e the data rate PRIOR to compression... The math is as follows :

4K at 24fps RAW - 4096 x 2304 x 24 x 12 / 8 / 1024 / 1024 = 324MB/s ..

(7.888 Gb/s)
Click to expand...

I've tried to get this calculated in my head, but I couldn't understand all the elements.

4096(the amount of the horizontal pixels) x 2304(the amount of the vertical pixels) x 24(the amount of the frames) x 12(the amount of bits per channel) / 8 (?) / 1024(?) / 1024(?) = 324MB/s

Could anyone help me replace those question marks?
Thanks in advance.

Nook
 
janghos said:
I've tried to get this calculated in my head, but I couldn't understand all the elements.

4096(the amount of the horizontal pixels) x 2304(the amount of the vertical pixels) x 24(the amount of the frames) x 12(the amount of bits per channel) / 8 (?) / 1024(?) / 1024(?) = 324MB/s

Could anyone help me replace those question marks?
Thanks in advance.

Nook
Click to expand...

The last bit of the math, specifically, the /8 /1024 /1024 is rather simple.

The /8 is conversion from bits to Bytes.

The /1024 is the decimal equivalent of Kilo 2^10 (base 2),

/1024 /1024 is the reciprocal of Kilo Kilo or Mega.

Therefore /8 / 1024 /1024 is the conversion from bits per second (b/s) to MegaBytes per second (MB/s).
 
Thanks khmuse,
I didn't take the conversion into my consideration, because I assumed that part was done after the math. That was my mistake. Now it all makes sense after your kind help. Thanks a ton.

EDIT: I've noticed a mistake that I made to describe the number 12. It should be bits per pixel, not bits per channel. It would be amazing to have a sensor that records 12 bits per channel, though.

Nook
 
Last edited:
janghos said:
I've tried to get this calculated in my head, but I couldn't understand all the elements.

4096(the amount of the horizontal pixels) x 2304(the amount of the vertical pixels) x 24(the amount of the frames) x 12(the amount of bits per channel) / 8 (?) / 1024(?) / 1024(?) = 324MB/s

Could anyone help me replace those question marks?
Thanks in advance.

Nook
Click to expand...
4096 x 2304 x 24 x 12 / 8 (bits to bytes) / 1024 (bytes to kilobytes) / 1024 (kilobytes to megabytes)

update: wrote this while the others were being posted.
 
luki said:
4096 x 2304 x 24 x 12 / 8 (bits to bytes) / 1024 (bytes to kilobytes) / 1024 (kilobytes to megabytes)

update: wrote this while the others were being posted.
Click to expand...

Thanks luki,
I know it's getting off the topic here if I go a little further, but I'd like to take this opportunity to really understand the math of digital image data rate.

So here it goes...
Just how you guys wrote the math, let me apply that to DVX camera as an example.

Would it be 720 x 480 x 30 x 8(R) x 8(G) x 8(B) / 8 / 1024 / 1024 = 632MB/sec?

And after the compression it would something like..

720 x 480 x 30 x 8(4)* x 2(1)* x 2(1)* / 8 / 1024 / 1024 = 39MB/sec ?
*4:1:1 color sampling applied.
This really doesn't make sense since I know that Mini-DV data rate is merely
25Mb/sec. There must be something wrong, here.

Any help?

Nook
 
Multiplying the bit depth of each channel out that way doesn't make sense. 8 bits per channel gives you 24-bit color (8*3), not 512-bit color (8*8*8).

720 x 480 uncompressed RGB would be 720 * 480 * 24 / 8 / 1024 / 1024 = ~1MB per frame, or 30 MB per second. With 4:1:1 YUV that drops to just 494K per frame, or ~15 MB/s.

Then DV compression is about 5:1, which gets you down to about 3 MB/s, which is 24Mb/s.
 
Chris Kenny said:
Multiplying the bit depth of each channel out that way doesn't make sense. 8 bits per channel gives you 24-bit color (8*3), not 512-bit color (8*8*8).
Click to expand...

That makes sense. Thanks for your correction.

With 4:1:1 YUV that drops to just 494K per frame, or ~15 MB/s.
Click to expand...

Well, but we don't get 15MB/s data rate when we digitize the video as QuickTime files. What am I missing, again?

Nook
 
You are missing the intra frame compression used. Try uncompressed sometime to get a full appreciation of what is going on.
 
janghos said:
Well, but we don't get 15MB/s data rate when we digitize the video as QuickTime files. What am I missing, again?
Click to expand...

DV uses about 5:1 lossy DCT compression. This puts it in the same class of compression algorithms as JPEG, and it exhibits some of the same artifacts, such as blockiness and noise around hard edges.
 
My thick skull

My thick skull

I'm sorry about dragging this out, but can someone please explain to me th "12" in the data rate calculation. I thought that was bits/pixel which should be #of color channelsXbits/channel, or am I all screwed up.
 
Right, Bert. But remember, we're talking about RAW data, and RED has a Bayer pattern sensor. What this means is that at each pixel, RED only picks up red, green or blue. So, in the RAW data, there are only 12 bits of data per pixel, not 36.

When shooting RAW, 36-bit data is created for each pixel by the demosaicing algorithm in the Redcine software.
 
You must log in or register to reply here.
Back
Top