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

Enter the Dragon

Guys! Today I saw 4k footage on the 84inch 4k LG LED TV. The details are so ridiculous is not even funny! I mean, I am taking about details of a wide shot of a city in motion and virtually no artifacts. It is absolutely astounding. then I saw a 1080p footage on the same TV. I now understand the power of 4k! I am so glad I am part of this awesome RED Journey since Scarlet came out!! whoever says 1080p is enough, I am so sorry but you need to see it yourself to truly witness it with your own eyes!

My 2 cents

Alain Maiki
 
Thats how I felt watching 4K footage on those displays at the RED party last year!

Alain M said:
Guys! Today I saw 4k footage on the 84inch 4k LG LED TV. The details are so ridiculous is not even funny! I mean, I am taking about details of a wide shot of a city in motion and virtually no artifacts. It is absolutely astounding. then I saw a 1080p footage on the same TV. I now understand the power of 4k! I am so glad I am part of this awesome RED Journey since Scarlet came out!! whoever says 1080p is enough, I am so sorry but you need to see it yourself to truly witness it with your own eyes!

My 2 cents

Alain Maiki
Click to expand...
 
Noah Yuan-Vogel said:
It's possible RED would add a mathematically lossless mode to REDCODE, but I think it would be a different setting and would not be as consistent in its bitrate as the currently used REDCODE compression schemes.
Click to expand...

I actually notice the bitrate changing quite a bit depending on the material in the scene with the current REDcode.
 
Jeff Kilgroe said:
Bits and stops don't need to corolate directly. The number of stops is your range of illumination that the camera can see. The number of bits used to represent that range is the precision or number of increments in illumination along that scale. You can have 20 stops of DR and a single bit to represent, of course it would just show the very darkest and very brightest values. A 16bit scale allows for the potential of 65,536 steps or values in gradation from darkest to lightest. With that many transitional steps and the fact that the human eye can only adaptively see an approximate range of 17 or 18 stops at any given time, we have to wonder just how far the precision needs to go. Every bit increase raises the amount of data that must pass through all the internal pathways, processors, be held in memory, etc..

Who knows what precision the ADC for Dragon will operate at, I think 16bit is fine... But bumping it to 18bit would remove all doubt and give us a potential 262,144 steps along our range. If you think that's not enough, that equates to 18,014,400,000,000,000 distinct RGB values...

For reference, 16bpc color precision equates to 281,474,976,710,656 distinct RGB values.
Click to expand...

I know it says epic is 16bit on the red.com epic/spec pages .. but has anyone ever seen a quote from someone at red confirming this isn't marketing describing tiff exports ..

i've asked several times. i'd love to actually know. my understanding is that we are still in a 12bit world, redcode wise, even with epic..
 
I'm sure this has been mentioned but what will 6K Anamorphic mode look like on the Dragon sensor? I assume it will be similar to the current Epic 5K ana mode but with less crop?
 
egon touste said:
I know it says epic is 16bit on the red.com epic/spec pages .. but has anyone ever seen a quote from someone at red confirming this isn't marketing describing tiff exports ..

i've asked several times. i'd love to actually know. my understanding is that we are still in a 12bit world, redcode wise, even with epic..
Click to expand...

Yes, I believe the camera captures what is called floating point bit rate, and this can be anywhere from 8 bit to 12 bit. NO S35 camera is doing 16 bits yet. The camera exports 10 bit.

Also, I must say the original post picture looks strange, those are most definitely not full stops! They look more like shades of grey that are probably half stops or even thirds. Can anyone confirm this, please?
 
António Fagundes said:
Yes, I believe the camera captures what is called floating point bit rate, and this can be anywhere from 8 bit to 12 bit. NO S35 camera is doing 16 bits yet. The camera exports 10 bit.

Also, I must say the original post picture looks strange, those are most definitely not full stops! They look more like shades of grey that are probably half stops or even thirds. Can anyone confirm this, please?
Click to expand...

Hm... This is just not right... :-)

So... The bit/stop equation seems to have some relevance in the AD process. Then that can be downsampled (not lossless, but practically lossless) "some".

F65 uses a 16bit container, but it is half-float, as far as I have understood 12 bits for precission and the last four for float operations.

In a linear container (like RED raw), all theoretical precission can only be kept in a bit/stop relation.
Now... That is true IF the mathematical theoretical max is actually captured, which I guess is hardly the case.
Because even though the mathematical precission is the highest in the last stop, that is also where most sensors start to misbehave/be unpresice...

So...

In short... Let's leave the judgement to someone who actually knows what oes on in there, like Graeme and sensor designers.... And let us pray for a 24bit linear container for the dragon with the option to record 1:2 compression...

Hahahaha

For processing, I still wouldn't mind 12 bit log, though...
 
It can't output +16 bit! GO on DaVinci and check the bit rate of your file, it reads 10bit! Why has no one on Red ever was clear about this, seems to sound like its not an information they happily want to disclose.

Can Graham or anyone at Red, please once and for all state the exact bit depth output of Red One's Redcode 42 or Epic's 3:1?

And please let's not get theoretical about it, its a simple question.
 
The + part is that some of the internal SDK decode and processing is done at float precision, the rest being 16bit precision. The R3D itself is 16bit precision too.

Graeme
 
António Fagundes said:
It can't output +16 bit! GO on DaVinci and check the bit rate of your file, it reads 10bit! Why has no one on Red ever was clear about this, seems to sound like its not an information they happily want to disclose.

Can Graham or anyone at Red, please once and for all state the exact bit depth output of Red One's Redcode 42 or Epic's 3:1?

And please let's not get theoretical about it, its a simple question.
Click to expand...

Thats because you probably have your project set up for 10bit in Resolve... go into settings and change it.
 
Graeme Nattress said:
The + part is that some of the internal SDK decode and processing is done at float precision, the rest being 16bit precision. The R3D itself is 16bit precision too.

Graeme
Click to expand...

r3d (from Epic/Scarlet I presume, as the R1 was allways 12-bit, no?) is 16 bit linear, then?
But the processing partly happens in (insert bitrate here) float, right?
 
In the RED tab of the Camera RAW project settings in Resolve it defaults to 10-bit, probably because that gives better real time performance. If you change it to 16-bit then Epic clips will read as 16-bit.

resolve_raw.png


r3d_bit_depth.png
 
Nick Shaw said:
In the RED tab of the Camera RAW project settings in Resolve it defaults to 10-bit, probably because that gives better real time performance. If you change it to 16-bit then Epic clips will read as 16-bit.

r3d_bit_depth.png
Click to expand...

Thank you Nick, knew that's what he was doing.
 
Is the internal A/D Converter on the EPIC 16 bit?
 
Noah Yuan-Vogel said:
My understanding was that it is common for mathematically lossless video to be able to get around 1:2.5 compression on average but with great variation depending on scene content. I don't think RED is saying we should expect 3:1 REDCODE to be mathematically lossless or even if they came out with 2.5:1 I don't think we could expect that to be mathematically lossless.
Click to expand...

RED has said a few times that 3:1 is mathematically lossless. 2.5:1 is usually mathematically lossless compression of pure noise. jp2k can take some shortcuts since the real world isn't pure noise.
 
Terry VerHaar said:
FWIW, for some time RED has said that around 2.5 or 3:1 compression is mathematically lossless, which is somewhat provable since math is specific and measurable. Meanwhile, they have also claimed, and I think many are willing to accept, that REDCode is "visually lossless" up to about 5 or 6:1. This is a bit more subjective but still seems to be a claim that holds some water.
Click to expand...

5 or 6:1 might be visually lossless but when the REDOne (on mysterium) first launched they were claiming that the standard REDCode (equivalent to about 10:1) was visually lossless even though it looked like it had been run through a 3px median filter. :P
 
You must log in or register to reply here.
Back
Top