Welcome to our community

Be a part of something great, join today!

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

12-bit or 16-bit? Scarlet specs that no one seems to know....

No I am pretty sure redcode is 16 bit as well, as was explained by red in the first link I provided...

"REDCODE™ 16-bit RAW Processing: Compression choices of 18:1 to 3:1 "

"RCX (and SDK) does processing at 16-bit and 32-bit float where needed"

"Martin: Jarred is clarifying that you should only concern yourself with the 16-bit number. Forget about 12-bit. "

this is in reference to REDCODE being 16 bit, now is it actually, does it fill the container? does a source have to fill it's container to earn the title of the format it's in? don't know don't care makes great pictures and this is the info we are given so, I'll move on.

because I'm going to trust the manufacturer on this one as in their own words it's rather complicated so unless they tell me otherwise that is the way I see it, it's 16 bit for all intents and purposes even in R3D's.

If this is for teaching purposes I would use only the facts from red and if you wanted to very carefully the assumptions of others, because in all reality only red knows these things so to assume anything is dangerous.
 
I just figured it was a 16bit container/12bit capture but because RCX uses 16bit, any manipulations you do after capture will be processed in (and "fill") the 16bits as needed (particularly with fine-tuning of things like FLUT and colouring adjustments.)

As per prores 4444, isn't luma data carried by the green channel (meaning the files are closer to 444 instead of 4444) or am I completely wrong in that guesstimation? What does the alpha data do with respect to the file bit-depth (it has to affect it somehow, right)?
 
Last edited:
Okay. I just got official word from Graeme. Combined with Jarred's information this should clarify everything:

Jarred Land said:
It's rather complicated, but all that is important is that in camera it is indeed 16 bit, and RCX pro is 16 bit+ . Rob ( if he is listening ) can explain the "+" part .
Click to expand...

And Graeme:

Graeme Nattress said:
The quote from Jarred is correct. The Rob bit is that the R3D is 16bit as decoded, but it's processing is a mix of float and 16bit integer as appropriate through the raw pipeline. Internally I concatenate as many operations as possible to maintain precision in the data.

It says exactly what it says. REDCode's wavelet coefficients are 16bit precision.
Click to expand...
 
Stephen Matthews said:
No I am pretty sure redcode is 16 bit as well, as was explained by red in the first link I provided...

"REDCODE™ 16-bit RAW Processing: Compression choices of 18:1 to 3:1 "

"RCX (and SDK) does processing at 16-bit and 32-bit float where needed"

"Martin: Jarred is clarifying that you should only concern yourself with the 16-bit number. Forget about 12-bit. "

this is in reference to REDCODE being 16 bit, now is it actually, does it fill the container? does a source have to fill it's container to earn the title of the format it's in? don't know don't care makes great pictures and this is the info we are given so, I'll move on.

because I'm going to trust the manufacturer on this one as in their own words it's rather complicated so unless they tell me otherwise that is the way I see it, it's 16 bit for all intents and purposes even in R3D's.

If this is for teaching purposes I would use only the facts from red and if you wanted to very carefully the assumptions of others, because in all reality only red knows these things so to assume anything is dangerous.
Click to expand...



you misunderstood this matter, and the links you provided.

jarred wrote "in camera it is indeed 16 bit, and RCX pro is 16 bit+" that's in-camera and in-software, not in R3D.

many things are calculated in bits

internal processing (such as calculations from sensor to file) does not give R3D files 16 bits of color depth. no matter how much word juggling you do around it.
and color depth is what matters eventually, for grading and screening purposes

it amazes me how people react to 12 bits as if it is such a horrible choice. while only 2-4 cameras can produce 12 bit imagery
 
Hector Berrebi said:
and in proper post production you would at least hope to display your full color depth

as well as the very near future of digital projection.
Click to expand...


Of course.
Though it's not essential for harvesting the advantages of higher sampling.



Hector Berrebi said:
in projection tests

more than 80% of viewers notice banding in 8 bits
about 50% of viewers see banding in 10 bits

and about 2 % see it in 12 bit

makes a good argument for what the human eye can properly see.
Click to expand...


It may seem that way, but no it doesn't.

Makes a good argument what a human eye can see with used projection technology.
With a rough set of criteria.

Also,
"banding" factor and constantly repeating argument is the heritage of 8 bit era + 6 bit monitoring.
In 12-16 bit imaging it's a non-issue, hence irrelevant factor. The advantages exist regardless.
 
Hrvoje Simic said:
Of course.
Though it's not essential for harvesting the advantages of higher sampling.






It may seem that way, but no it doesn't.

Makes a good argument what a human eye can see with used projection technology.
With a rough set of criteria.

Also,
"banding" factor and constantly repeating argument is the heritage of 8 bit era + 6 bit monitoring.
In 12-16 bit imaging it's a non-issue, hence irrelevant factor. The advantages exist regardless.
Click to expand...

this test info came from an FXPHD lecture.

banding artifacts can be seen in 8 bit and even 10 bit monitoring and projecting. (or maybe we use a different signification for banding)
 
Hector Berrebi said:
here is another quote from Graeme to Bob from GlueTools on the DVINFO forum... its clearer and shorter

"12bit actually.

Graeme"

www.dvinfo.net/forum/hd-uhd-2k-digital-cinema/125765-arriraw-vs-redcode-raw.html
Click to expand...

Yes, RED One was 12bit R3D. We bumped that to 16bit precision on the Epic ASIC.

As for the discussion of banding, one of the nicest things I can say there is that I've never ever seen banding/posterization in an R3D. I've seen it in files produces from an R3D or as monitoring artifacts, but never in the source data, never from the REDCODE.

Graeme
 
Graeme Nattress said:
Yes, RED One was 12bit R3D. We bumped that to 16bit precision on the Epic ASIC.

As for the discussion of banding, one of the nicest things I can say there is that I've never ever seen banding/posterization in an R3D. I've seen it in files produces from an R3D or as monitoring artifacts, but never in the source data, never from the REDCODE.

Graeme
Click to expand...

hi Gaeme
can you please clarify

does this mean that R3D files hold 16 bits color depth? as in 65kx65kx65k colors?

thank you

hector
 
Talking of number of colours doesn't quite make sense. Bit depth more relates to numerical precision in this context. You're right that 16bit implies 65536 code values though, and remember this is RAW data so there's no actual "colour" yet.

Graeme
 
Hector Berrebi said:
this test info came from an FXPHD lecture.

banding artifacts can be seen in 8 bit and even 10 bit monitoring and projecting. (or maybe we use a different signification for banding)
Click to expand...

Firstly,
my post addressed the main cause of banding issues emerging and how the whole banding argument started. It also addresses the conclusion suggested about the limits of human vision, which is false. Where the tests come from is irrelevant in this case as they are not contradicted. Although it would be interesting to see the full context with all the factors included in mentioned banding projection tests.

Secondly,
not sure about the full context of the quotes, but without it - what the statements from the test suggest is over-generalized and may lead to false conclusions. Banding can be caused by numerous factors, starting from the imaging device, material conversions, post production, monitoring pipeline or display itself. And it also doesn't have to be apparent at all. As mentioned, it can appear in 8 bit and 10 bit sampling as well, but it does not necessarily mean it will, nor is it the only important factor for utilising higher sampling precision. It is merely the most obvious one.
 
The R3D compresses the raw linear sensor data.

Graeme
 
Graeme Nattress said:
Talking of number of colours doesn't quite make sense. Bit depth more relates to numerical precision in this context. You're right that 16bit implies 65536 code values though, and remember this is RAW data so there's no actual "colour" yet.

Graeme
Click to expand...

as you know I appreciate your work greatly. so I will take it as an answer, and I stand corrected to statements I have made before.
however, I doubt this holds in the traditional, mathematical sense of the term i.e. the way color depth is calculated and stored

I realize its a RAW file, no actual color does not mean no color data.
and as de-bayering has to happen for all useful purposes, its the definite, actual, color depth that I was referring to.
one I can take to the bank.



as someone who does workflow consulting as well as training and lecturing for a living,
I must add that it is kind of hard to get properly documented, valid tech info about the REDCODE codec.

I realize there must be secrets and patents to protect

but some sort of codec whitepapers are much needed in my opinion.
or they exist and I wasn't aware of them?


regardless ... thanks for REDCODE :)
 
I think what I'm getting at is even when you say 8bit colour is 256x256x256 = 17.6million colours, it's correct enough, but misleading because most of those colours are not perceptibly different from each other, and it's counting shades of the same colour as a different colour. Although there' 17.6 million colours, there's only 256 shades of grey, for instance.

Graeme
 
Graeme Nattress said:
I think what I'm getting at is even when you say 8bit colour is 256x256x256 = 17.6million colours, it's correct enough, but misleading because most of those colours are not perceptibly different from each other, and it's counting shades of the same colour as a different colour. Although there' 17.6 million colours, there's only 256 shades of grey, for instance.

Graeme
Click to expand...

agreed... but that's the magic and maybe the downside of math... its cold and does not take human perception into account, (at least not the non CIE human perception:smile:) but it creates an objective basis of comparison,
so even if 8 bits is not really 16.7M different colors in our limited, subjective and non accurate eye, it is so in calculations. and this fact allows for other calculations to take place above it, or in relation to it.

god this can give you a headache

:) digital color is such a hard uncharted field

the things you do i consider magic
 
You must log in or register to reply here.
Back
Top