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 :)

16 BIT REDRAW

S

sebastian toro

Well-known member
Joined
Nov 8, 2007
Messages
48
Reaction score
0
Points
0
I check the technical info over the red web and i found that the epic have a 12 and 16 bit raw option. i 've been working with the idea that is 12 bit linear redcode raw.
Is the 16 bit raw option available now using current epic firmware?
is an upcoming feature?

best regards
 
Hi Jakko thank you for the response....

check this... http://www.red.com/products/epic/ in tech specs. it mention 12 and 16 bit raw option...

could any confirm how is this working now... are you sure that the camera records 16 bit RAW on every compression and resolution?
 
I think the higher compression rate you use like 18:1 then i think that may be using 12 bit, but i'm no professional so i may be wrong
 
1 minute epic ff is about 8.7 GB this is red code 3:1
no 16 bit if i have my calculator correct.... is 12 bit at this size at redmag.... probably 16 bit internally only?


regards
 
There has always been, for me anyway, a few questions around this and my quick maths couldn't help me.

As well as the how big are the files test i also did a test where I recorded black (body port on in a dark room) boosted this black in redcine still it steps then compared with the image in linear. I concluded that something odd was going on BUT the pictures definitely seemed more precise than 12bit linear?

Does it really matter?


ps What seems likely (to my lay thinking) is that we have 16bit sampling transformed into a more efficient picture carrier (12bit log?)... So in most meaningful ways (at least from a picture perspective) we have precision very similar to 16bit Lin?
 
sebastian toro said:
1 minute epic ff is about 8.7 GB this is red code 3:1
no 16 bit if i have my calculator correct.... is 12 bit at this size at redmag.... probably 16 bit internally only?


regards
Click to expand...

Sebastian,

I've just spent some time working on this, and I believe these are the uncompressed rates for RAW 5K (5,120 X 2,700):

8-bit: 18.5 GB/min.
10-bit: 23.2 GB/min.
12-bit: 27.8 GB/min.
14-bit: 32.4 GB/min.
16-bit: 37.1 GB/min.

So I have to agree with you that at 3:1 compression (as I understand it) the bit depth of your .R3D file would seem to be closest to 12-bit.
 
I think anyone who takes a few minutes to do a little bit of maths realises the files are not 16bit linear (in iany traditional sense)... If any of it matters at all ...it is the question of 'are redraw files linear?'... And as far as I can tell nobody at Red has every wanted to confirm this.
 
Michael Lindsay said:
I think anyone who takes a few minutes to do a little bit of maths realises the files are not 16bit linear (in iany traditional sense)... If any of it matters at all ...it is the question of 'are redraw files linear?'... And as far as I can tell nobody at Red has every wanted to confirm this.
Click to expand...

Michael, I distinctly remember hearing when the R1 came out that Red files are 12-bit linear. I can't point you to quotable source at the present time, but I might be able to find a reference somewhere. And I certainly don't know what changes may have been made to the .R3D structure to accomodate the Epic and Scarlet cameras.
 
Peter Moretti said:
Sebastian,

I've just spent some time working on this, and I believe these are the uncompressed rates for RAW 5K (5,120 X 2,700):

8-bit: 18.5 GB/min.
10-bit: 23.2 GB/min.
12-bit: 27.8 GB/min.
14-bit: 32.4 GB/min.
16-bit: 37.1 GB/min.

So I have to agree with you that at 3:1 compression (as I understand it) the bit depth of your .R3D file would seem to be closest to 12-bit.
Click to expand...

Are these number based on raw sensor data, or finished uncompressed images at 5,120 X 2,700 resolution. If you calculate from raw sensor data, how do you find the data rate from the MX-sensor?
 
Yes I am pretty sure the Red one encoded and created a 12bit linear file... But I don't see how that precludes epic creating a nonlinear file. Unless you know of a way to get to the picture in a epic file without the red sdk or redcineX?

Might be wrong but my guess is 12bit nonlinear otherwise Red wouldn't have made such a big deal about increased precision...

Pictures look good either way ;-)
 
Jon MIchael Puntervold said:
Are these number based on raw sensor data, or finished uncompressed images at 5,120 X 2,700 resolution. If you calculate from raw sensor data, how do you find the data rate from the MX-sensor?
Click to expand...

Those were calculated assuming RAW sensor data at 5,120 X 2,700. By that I mean it assumes a single color value per pixel. If it were uncompressed 4:4:4, the rates would have to be multiplied by three.

These are the rates that I calculated for the MX sensor's 4K (4,096 X 2,304) uncompressed RAW data assuming various bit depths:

8-bit: 12.7 GB/min.
10-bit: 15.8 GB/min.
12-bit: 19.0 GB/min.
14-bit: 22.1 GB/min.
16-bit: 25.3 GB/min.

Hope that helps, and that my math is correct :).
 
Michael Lindsay said:
Yes I am pretty sure the Red one encoded and created a 12bit linear file... But I don't see how that precludes epic creating a nonlinear file. Unless you know of a way to get to the picture in a epic file without the red sdk or redcineX?

Might be wrong but my guess is 12bit nonlinear otherwise Red wouldn't have made such a big deal about increased precision...

Pictures look good either way ;-)
Click to expand...

Michael, your suspicion may of course be confirmed. But I think the increased precision comes from internally processing the sensor data at 16-bits, instead of 12-bits like I believe the Red One does. But you definitely said it best:

"Pictures look good either way ;-)"
 
You must log in or register to reply here.
Back
Top