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-bit and 16-bit Recording Options?

D Fuller said:
Exactly what I meant. But you said it better. Thanks Mike.
Click to expand...

And the lack of precision of the sampling makes it impossible to use less bits than stops in digital image aquisition - this is the whole issue, not the analog device in use.
 
D Fuller said:
Not so true. Bit depth is only relevant to the "resolution" of color depth, not dynamic range. 20 stops could be mapped to 10 bits, or 6 bits, for that matter. You'd just see more banding.
Click to expand...

you only see banding when you expand gamma, not when you compress it.
 
Robin Balas said:
First I need to point out that I am talking real life implementation here and not theoretical math, and I am an engineer - not a mathematician or physics expert.

If you are squeezing 14 stops into 8 bits RAW lin - how many levels do You expect there are to describe the contents of the darkest stop's worth of info (remember the LINEAR state)?
There are none, nothing can change that. I suggest reading up on binary arithmetics if this sounds strange.

If one assumes a log encoded RAW file you may squeeze in more stops than bits, but to go from lin to log, in the digital domain, the darkest stop contains the least resolution mathematically speaking. The lowest bit only describes 1 level of info and the highest describes 2^n-1 levels, which is 128 for a 8 bit file, hence a shadow issue and not a highlight issue. Regardless of redistributing bits etc. there are no info left to distinguish the contents or levels in the shadow stops when doing the lin to log transformation. But in theory it is possible to do as you describe if you accept the extreme banding in the shadows which is in my opinion not a realistic assumption in the real world.

To properly provide a gradation in the darkest shadows you really need more bits than stops when doing the binary math step from lin to log.
The damage is irreversibly done when the digitizing of the analog signal into the digital linear representation occurs. This is normally step 1 in the A/D chain.

In a 8-bit lin to log transformation the top bit is describing the brightest values in the captured light, it causes the (from bright to dark) 1.stop to contain 128-levels, 2. stop 64-levels, 3. stop 32-levels, 4. stop 16-levels, 5. stop 8-levels, 6. stop 4-levels, 7. stop 2-levels and 8. stop 1-level. There are no definition to describe 14 discreet stops of information with a 8-bit lin file. It would look cr#p in the shadows.

To avoid all of this one needs to go from a lin signal to a log one in the analoge domain prior to digitizing, then you need a lot less bits to keep all info. Hence all this is not a sensor issue but a A/D digitizing issue. The sensor might capture 13.5 stops, but you loose the ability to distinguish those dark gradations

I am not aware of any digital image sensor which have log characteristics in the analog domain. There might be one around which isn't described in the literature tough.

IMHO 16-bits is a very good thing if you wan't to capture 13.5 stops of linear data that needs to go through a lin-log transformation to be usefull. It gives a realistic shadow representation for digital images both stills and moving. Anything else assumes you are in a log domain prior to digitizing.

Its the way it have been working in A/D converters and is the way it is working today. Maybe someone can think outside the box and come up with a whole new set of thinking to accomplish a direct analog to digital log quantization method, and you are then likely a nobel candidate if you do.

I wonder if I got the message through, but the whole point is its about the stuff between black and white not the absolute ends describing black and white - unless you are producing a lithographic look.

I appoligize for the awkwardly arranged line of arguments - its a bit late and I started out in the wrong end with all this.
But please prove me wrong, and the engineering world will be greatfull for overcomming one of the major challenges in A/D conversions.
Click to expand...

Thanks!
I started off a couple of times on a similar explanation, but not being an engineer, it got clumsy...

However, this is pretty much exactly how I understand it and reflects very well on what I see in both the R1 and Epic images.

If one are to accept that the R1 MX has 13.5 stops, there is something thrown out to achieve that. Possibly in the top and the bottom.

On the Epic OTOH, that should not be the case.

One can extend the DR by adding analogue gain in the lower exposure range and/or filtering - prior to AD, which is done in a lot of cameras. But that isn't really re-mapping, just an altering of the signal.

RED does not do that afaik I know and they have stated.

There's also other optical ways of extending the DR prior to AD, but the signal captured will then still be within the limits of one stop pr bit.

To get precission in the bottom, the lower bits need to be not used. Thus giving the complaint that "my blacks aren't really black" that we saw a lot in the early R1 days. Typically from video-backround-shooters.

Cheers and THX!

G
 
Rob Ruffo said:
you only see banding when you expand gamma, not when you compress it.
Click to expand...

I wish this was true. A 4 bit image will have banding even if you compress the gamma. Not that this is relevant.
 
Can anyone from Red answer, please?

Can anyone from Red answer, please?

Over 3 months later and still no answer to this question.

The latest Epic manual still says (on p11):
"The digital image received from the sensor is formatted as a ... 12-bit, 14-bit or 16-bit per pixel RAW data frame."

How do we know how many bits we are set up for?

Is it linked to the compression rate?

Or something else?
 
Antony M said:
Over 3 months later and still no answer to this question.

The latest Epic manual still says (on p11):
"The digital image received from the sensor is formatted as a ... 12-bit, 14-bit or 16-bit per pixel RAW data frame."

How do we know how many bits we are set up for?

Is it linked to the compression rate?

Or something else?
Click to expand...

Currently all processing on Epic and compression is done at 16bit.
 
I'm sure that we have 16bit RAW files too - don't forget that Epic and Scarlet are producing 30% larger files with same format size and compression as RED ONE.

Also think about Canon and Nikon RAW which are 14bit :-)
Hasselblad is 16bit
 
Why doesn't RED just explain when it's 12 or 16 bit?
 
You must log in or register to reply here.
Back
Top