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

EPIC 12 and 16 bit RAW

Elizabeth: I'm confused. You got the more expensive model to shoot less data? I apologize about the confusion, but we still allow control over such a thing through selection of resolution, framerate & compression ratio. Compression like the one we employ does not really work with "X" bits per pixel, it works with "X" bits per frame (compression ratio). That is what controls the quality (and thus how many bits are used). 12- or 16-bit input changes nothing about that (it just picks where you throw data "away"). So you definitely have the control you wanted, it's just a different, but better (!), knob to turn.
 
Rob Lohman said:
Elizabeth: I'm confused. You got the more expensive model to shoot less data? I apologize about the confusion, but we still allow control over such a thing through selection of resolution, framerate & compression ratio. Compression like the one we employ does not really work with "X" bits per pixel, it works with "X" bits per frame (compression ratio). That is what controls the quality (and thus how many bits are used). 12- or 16-bit input changes nothing about that (it just picks where you throw data "away"). So you definitely have the control you wanted, it's just a different, but better (!), knob to turn.
Click to expand...

Wow, Rob are you implying that changing the Compression Ratio on an Epic-X will change the Bit Depth?

So, as an example, at 8 to 1 the system might be in 16bit mode, but then if you go to say 12 to 1 it might go to 12 bit mode?

I'm not trying to cause trouble here, I am just trying to learn my camera as best I can. I am very proud to own an Epic-X.
 
I don't think thats what he's saying its sounds more like he's saying, instead of giving you control over amount of bits per pixel(12bit or 16bit), they give you control over bits per frame (compression ratio).....both give you control over the amount of data and quality. No matter what compression ratio you choose the processing is still 16bit
 
Joseph is correct. There is no way to specify a number of bits per pixel with compression systems like this, that notion makes no sense anyway. One pixel may need more bits than another. You WANT the bits to go where they are needed, not be wasted where they're not (which is what uncompressed and lossless compressions do).

Don't think of it as changing bit depth, think of it as deciding how many bits total you want to use to represent a frame.

Just to clarify: I'm simplifying things greatly here, you can't make sweeping statements like "compression ratio changes bit depth", that's too simplified :) I appreciate you want to understand as much as you can, but compression is a complex topic you can spend years or decades of your life on :)
 
Rob Lohman said:
Elizabeth: I'm confused. You got the more expensive model to shoot less data? I apologize about the confusion, but we still allow control over such a thing through selection of resolution, framerate & compression ratio. Compression like the one we employ does not really work with "X" bits per pixel, it works with "X" bits per frame (compression ratio). That is what controls the quality (and thus how many bits are used). 12- or 16-bit input changes nothing about that (it just picks where you throw data "away"). So you definitely have the control you wanted, it's just a different, but better (!), knob to turn.
Click to expand...

Hi Rob,

Just to reiterate, my (very limited) understanding of how REDCODE shooting works was that in forfeiting a choice between 12 and 16 bit sampling I would also be forfeiting a method (however infrequently used) to limit file size (or maximize recording time on an SSD). I realize, of course, that compression ratio is another way to handle that issue (and presumably would offer different tradeoffs). But I thought that bit depth was another. And that was attractive for me (especially since my understanding is that the RED One sampling depth is 12, and those files look pretty darn good to me).

I appreciate you making clear why it's more sensible to use compression ratio only, and that allocating bits per frame -- not per pixel -- will get you better results at the same data rates. But the fact remains that the information on Epic on the main RED site is misleading in this regard. It doesn't sound like there is any user control over bit depth in sampling, and the website clearly states or implies there is: a choice between 12 and 16. That information should be changed. So I still want to make that point. But thank you for explaining things for a brand new Epic owner who hasn't even yet taken delivery.:wink5:
 
Elizabeth: you're welcome :) We'll fix the site. You're not really forfeiting anything, it's a different knob that results in the same thing (bigger or smaller files). It's just a cruder, less refined way of doing it than changing compression ratio.

By altering bit depth, you're actually making things harder for the compression because you picked what to throw away (per pixel!) instead of having the compression decide (whole image!). Since it's looking at more than the individual pixel it can do that more efficiently with finer control then just arbitrarily throwing things away when you have no idea what it represents :)
 
Glad we got some clarification on this.

Was the 12 bit part mistakenly placed in there from the RED One? I'm curious to know as to why it was included.
 
Correct me if I am wrong.
My understanding is that Sensor and all internal sensor data paths in the camera are 16 bit.
Next, since it is Wavelet compression it uses Wavelet Transforms that acts on a whole frame rather than on the pixel by pixel data and decides what detail on the frame needs more bits all the way to oversampling to 32 bit float if mathematical calculations will force result to go higher in the bit resolution.

http://en.wikipedia.org/wiki/Wavelet_transform

Next, the compression used by the operator is kind of a knob that allows you to take more or less of these bit resolution and together with final material format may force it into the 32(float) 16, 12 or even 10 and 8 bits if desired.

Well, there is no point to have 10 bit resolution output for 8 bit Blu-ray format but processing all data in 16 or 32 bit float is desirable for color manipulation and accuracy.

The data acquisition restrain is another game.

If you are forced to use higher compression because of data storage constrain or fps speed than you will use higher compression ratio, (turn down the knob) but as we see from Wavelet Transform such higher compression may still deliver the same final data resolution of 16 bit regardless.
 
Andrew, I think you are still making some assumptions that may not apply to RED's JP2K implementation. Rob's note about complexity is the crux. For example, when one metric changes it may affect several other metrics, some in a non-linear way. Modern compression strategies like RedCode resist simple quantification. It is also worth noting that 10 bits well distributed on a log scale can hold a similar amount of image data to a 14 bit linear scale which is technically a form of compression, though its usually not thought of that way.

Cheers - #19
 
Yes, I am assuming 16 bit hardware architecture.
As to Wavelet compression I am just trying to explain it in simple words.
In the supplied link they are giving example of stars on the black sky background.

I will give the example of the small lit window to the fully furnished room on the background of the large building wall.

Lit window takes only 10% of the total surface of the frame but it has a lot of details and colors in it.
Including some people sitting there at the table and skin tones:-)

Well, Wavelet compression will preserve skin tones and all the details in the room even if the compression is set to high. Why? Because 90% of the frame is black building wall that is compressed and almost completely eliminated from the data stream. Other compression technique may have trouble to compress such background especially if the building has slight shaded transition to one side.

Even more, fine skin tones calculated from 16 bit integers may produce fine fractions of these 16 bit integers that we may want to preserve as well, thus using more than 16 bit resolution.

This explains why 16 bit sensor may produce more than 16 bit data stream resolution.

Graeme would be the best to explain it here.
 
sorry to dive in to an old thread with a long post...

got here through a link

and I just had to clarify some points I think may be worth it for someone who stumbles in.
if anything I say is utterly wrong, or can be better explained or expanded on, i'd be happy to be corrected and learn.

it would seem from reading this thread that some users may find 12 bits: not-enough, disappointing, not-what-they-bargained-for and all and all confusing.

guys... get real.

i realize most folks here are shooters, and this is technical digital video stuff... but you should know this.

there are a hand full of cameras capable of producing 12 bit color depth files.
and most of these cameras are way, way more expensive than a SCARLET
just to put it in proportions, the screen you are looking at right now is only capable of producing 16.7 million colors (in most cases) while an EPIC or SCARLET can produce files with 68 billion colors.
change colors with dollars if you still feel out of proportions.

16 bit internal processing as well as 32 bit software processing in REDCINEX is great, (and in the later case much needed) but it is still internal. and as sush, not so much in the user's control.

16 bit video files (to my best knowledge) do not exist. and if existed, you wouldn't be able to monitor them on anything and through any video IO device I know of.

film scans can be 16 bit tiffs. but that's about it. you use the 16 bits... but never "see" them as it's either printed back to film and out of "bits" world, or screened digitally and lower than 16 bits.

which makes 12 bits, not only the best option currently in existence

but also a small pice of future in our hardly 10 bits pro video present

you should be praising the gods of cameras (and the good people at RED) for this blessing.

a few facts about 12 bits (i hope i got them all right)

most IO video cards monitor out only 10 bits. (see bluefish for exceptions)
most professional grading monitors only reproduce true 10 bit (at best) an expensive few will show 12 bits (see dolby monitors for exception)
the hopefully soon to come REDRAY projector is supposed to project at 12 bits (yay)
ProRes 4x4 is the only video file i'm aware of that maintains 12 bits (with no color subsampling) that is of course, not counting R3D.
other alternatives are high end image sequences (DPX, EXR, TIFF).
to my best knowledge AVID, and PREMIERE won't handle 12 bits properly and FCP7 (only in PR444 sequence) may be problematic too (QT internal renders).
you would need to go SMOKE, SCRATCH, DAVINCI (and REDCINE) for proper onlines
more than 90% of viewers will not notice any banding artifacts in 12 bit projections

broadcast TV as well as the internet are both at 8 bits
most 10 bits cameras (and not that much of these) can maybe do 10 bits, but at 4:2:2 color sub sampling.


for me it is one of the most overlooked facts about RED cameras,

and this exceptional color depth is one of the main reasons why i not only own a RED, but also teach and advocate for the usage of these cameras.
 
Hector Berrebi said:
to my best knowledge AVID, and PREMIERE won't handle 12 bits properly
Click to expand...

Adobe Premiere Pro CS6, After Effects CS6, and SpeedGrade CS6 all handle 8-bit, 16-bit, and 32-bit floating point color. I work primarily in 16 bit.
 
Phil Holland said:
Adobe Premiere Pro CS6, After Effects CS6, and SpeedGrade CS6 all handle 8-bit, 16-bit, and 32-bit floating point color. I work primarily in 16 bit.
Click to expand...

thanks phil.

do you work with original R3D's in adobe?

i need to reed some more on the new Adobe color engine...
 
I work with original files all the way through Premiere, After Effects and Resolve in 32 Bit float space.

Why convert? Even a Retina MBP can handle it (well, a REDRocket helps). Why loose anything?
 
[COLOR=#FFFFFF !important]
Uli Plank said:
I work with original files all the way through Premiere, After Effects and Resolve in 32 Bit float space.

Why convert? Even a Retina MBP can handle it (well, a REDRocket helps). Why loose anything?
Click to expand...


hi Uli

there are many reasons to convert. especially in high end workflows and environments.

working with original R3D's is certainly an option, and a very good one, however it does require a monster station to give you full frame rate when grading (definitely not on a retina MBP)
not that a high end image sequence wouldn't.

main issues with R3D workflow is compositing (having to later match in grading RAW and non RAW shots)
and the added step in grading (the RAW settings) which is a great place to over complicate stuff for many users.

I think that in a careful and supervised environment, converting files (at the right step) is visibly (and to most extent non visibly) un harmful.

Phil Holland said:
Adobe Premiere Pro CS6, After Effects CS6, and SpeedGrade CS6 all handle 8-bit, 16-bit, and 32-bit floating point color. I work primarily in 16 bit.
Click to expand...

I believe that the new Lumetry deep color engine only applies in Speedgrade. and though PP has 16 bit processing, I seriously doubt its true 16 bit (or 12 to that matter) support.
if you try importing a 16 bit Tiff, DPX or EXR sequence, you get the "The video bit depth of this file is unsupported." error message. there are AE workarounds, but if you read about it online, and carry some tests, you will find much confusion. for comparison, SMOKE, just opens the same image sequence without any problem. this isn't neccesairly the case with native R3D workflows, which truly, in Premiere are the best option. it is still though, for many reasons, unfit for high-end long format workflows.



I forgot to add earlier that Cineform's studio premium, like PR 4x4, supports 12 bit depth.
 
You must log in or register to reply here.
Back
Top