Acquisition Formats for Scarlet -X

[Jean Simenon]

Redcode is Red's proprietary Bayer raw compression scheme. It records the raw sensor data to a compressed data file that is otherwise not altered, 16 or 12 bit values for every pixel for every frame. This is debayered and encoded to any number of available formats from full 16 bit RGB TIFF's to different versions of Prores or other encoded video formats in Redcine-X. The HDMI and HDSDI monitor outputs debayer and encode the raw data real time to uncompressed 4:2:2 10bit YPbPr digital video or according to the manual 8 bit 4:4:4 RGB video, your choice. Although there was some discussion in the past of recording 1080p RGB from the full frame sensor to internal media, this option is not listed in the specifications of Scarlet. Internal acquisition formats are all Redcode Bayer RAW only.
1080p and 720p RGB recording are listed as part of Epic's specs, but that feature has not been enabled yet and no one knows what exactly the RGB format will be or when it will be added.

Excellent. So RAW is what the sensor delivers to a REDCODE processor inside scarlet. But we never get RAW, we always get REDCODE... it looks great, lots of data, but ever only an interpretation of the RAW data. Just never RAW.

Processing power is inside the scarlet to deliver scaled down version of the RAW, or maybe scaled down version of the REDCODE. So potentially with the scaled down you end up with 1 or 2 layer of compression, which is unknown to us or we know what we get?

Until you display any of the production in full 4K, what are the other reasons for having a 4K frame, especially if you consider non-feature fiction films (or should we only consider scarlet for that application), if you consider you're not going to crop inside of it to reframe your picture. How much would you lose if you were actually recording to these formats:
- The inexistant 2K scaled down redcode version of the 4K (5K if the scarlet is actually able to ingest RAW from the sensor at more than 12fps).
- uncompressed 422 10bit YPbPr (especially if your image is flat: low contract/saturation)
- 8bit 444 RGB

Maybe there's a thread (I looked..) where these images are compared. Might be worth to point to them if someone ever had that reference.

I am sorry, but this shows a lack of fundamental understanding of what RAW even is. You cannot have a 2K "RAW" from a 5K camera at the same sensor size - it doesn't work that way since the image has to (at that point) be scaled in some form or the other.

So what do we have? Why are we using the term RAW? Don't we have redcode only anyways? Isn't that an extrapolated then compressed version of RAW? Just a good looking one? Couldn't we get 2K REDCODE from 4k/5k?

------

Thanks for the time, explanation, effort. Hope it helps others as well.

 

[D Fuller]

So what do we have? Why are we using the term RAW? Don't we have redcode only anyways? Isn't that an extrapolated then compressed version of RAW? Just a good looking one? Couldn't we get 2K REDCODE from 4k/5k?

No. It is not extrapolated then compressed. It is simply compressed raw sensor data.

 

[Jean Simenon]

No. It is not extrapolated then compressed. It is simply compressed raw sensor data.

How is this possible when the sensor is only 2K red/blue.. and 3K green? Color has to be extrapolated one way or another to define each pixel.

 

[Stacey Spears]

How is this possible when the sensor is only 2K red/blue.. and 3K green? Color has to be extrapolated one way or another to define each pixel.

The debayer happens after decode.

 

[Jean Simenon]

The debayer happens after decode.

What's decode? How do you create a 5K color map, when you only have 2K blue/red.. 3K green?

EDIT... Ok got it. From Terry's post. REDCODE records sensor data, then REDCINE-X decodes with debayer.

 

[Terry VerHaar]

Jean - I am not at all sure I understand what you are saying, but one thing it might be helpful to remember is that RAW is not necessarily uncompressed and uncompressed is not necessarily RAW. In REDCode, you get all the RAW data from the sensor but it is then compressed in a proprietary wavelet compression mode to yield REDCode RAW. And, depending on the compression, the resulting file might be mathematically lossless, visually lossless or, at high compression rates, somewhat lossy. When the signal is decoded, in REDCine-X, you still have access to all the RAW metadata and can adjust things like ISO, white balance, etc, without losing anything from the original signal; nothing is "baked in" until you output another type of RGB-based file.

(And, just to complete the thought, you can of course have an uncompressed signal that is not RAW - it will already have been placed in an RGB format and you are simply getting all the bits from those frames. This is not how RED does it.)

Does that help - or make it worse? :scared:

 

[Jean Simenon]

Jean - I am not at all sure I understand what you are saying, but one thing it might be helpful to remember is that RAW is not necessarily uncompressed and uncompressed is not necessarily RAW. In REDCode, you get all the RAW data from the sensor but it is then compressed in a proprietary wavelet compression mode to yield REDCode RAW. And, depending on the compression, the resulting file might be mathematically lossless, visually lossless or, at high compression rates, somewhat lossy. When the signal is decoded, in REDCine-X, you still have access to all the RAW metadata and can adjust things like ISO, white balance, etc, without losing anything from the original signal; nothing is "baked in" until you output another type of RGB-based file.

(And, just to complete the thought, you can of course have an uncompressed signal that is not RAW - it will already have been placed in an RGB format and you are simply getting all the bits from those frames. This is not how RED does it.)

Does that help - or make it worse? :scared:

OK. Do I get it? The debayer is only done in REDCINE-X? The redcode from your REDMAG is the sensor data... 2K blue/red.. 3K green..? So REDCODE is the RAW sensor data for compression 1:1?

Then REDCINE-X extrapolates the REDCODE info to create 5120x2700 pixels image, with the 2560x1350 blue/red and 2560x2700 green?

 

[Terry VerHaar]

OK. Do I get it? The debayer is only done in REDCINE-X? The redcode from your REDMAG is the sensor data... 2K blue/red.. 3K green..? So REDCODE is the RAW sensor data for compression 1:1?

I think we are getting somewhere...

Just to be clear - debayering has to happen in order for there to be a visual image. So, de-bayering happens in the camera as you are monitoring the recorded signal off the sensor and when you play it back.

As for your question about 1:1... not sure what you are asking. REDCode is compressed, period. And, I don't think you can separate the terms REDCode and RAW and have them be meaningful on their own. The ASICs in the camera take the data off the sensor, compress it and record it, along with some metadata. The amount of compression is set ahead of time by the user. When you want to "use" the data that has been recorded, you basically reverse the process. The de-bayer process is part of the "decoding."

 

[Kevin Marshall]

Excellent. So RAW is what the sensor delivers to a REDCODE processor inside scarlet. But we never get RAW, we always get REDCODE... it looks great, lots of data, but ever only an interpretation of the RAW data. Just never RAW.

RAW is unprocessed data from the sensor. It is linear light data from each photosite on the sensor. This data can, however, be compressed. Even RAW on DSLRs is compressed, just with their own methods. The processing that normally would happen in a video camera (debayering, application of gamma curve, ISO/gain, white balance, etc) to create a video signal is done after the fact for greater control, quality, and options. You can compress RAW, and you can have uncompressed video. You can also have uncompressed RAW, and you can have compressed video. Compression and RAW are independent from each other. Redcode is simply the name of the compression scheme Red uses to compress their data. Currently there is no uncompressed (or 1:1) option.

 

[Jean Simenon]

I think we are getting somewhere...

Aha! Maybe.

Just to be clear - debayering has to happen in order for there to be a visual image. So, de-bayering happens in the camera as you are monitoring the recorded signal off the sensor and when you play it back.

As for your question about 1:1... not sure what you are asking. REDCode is compressed, period. And, I don't think you can separate the terms REDCode and RAW and have them be meaningful on their own. The ASICs in the camera take the data off the sensor, compress it and record it, along with some metadata. The amount of compression is set ahead of time by the user. When you want to "use" the data that has been recorded, you basically reverse the process. The de-bayer process is part of the "decoding."

I understand there's no 1:1. 3:1 is minimum. So 3:1 is LOSSLESS? That's what makes REDCODE 3:1 be RAW. Just not beyond that?

So RED made the choice of offering 18:1 compression at 4K, but didn't want to offer recording a scaled down image from 4K to 2K... with potentially a less lossy image than 4K 18:1?

 

[D Fuller]

What's decode? How do you create a 5K color map, when you only have 2K blue/red.. 3K green?

By decode, he means the decompression part of compress/decompress. Redcode compresses the raw sensor data, not the color image that can be made from it. You get the 5K image from the Bayer data. You posted the illustration from the Wikipedia page on Bayer pattern sensors above, so I assume you know how that works. If not, please go back to the Wikipedia page and re-read it.

An important part of the design of the Red camera is that they employ the power of your editing workstation for image processing, and it lets you work fro the raw data, rather than a quickly-produced image that can be done in-camera. The difference is like the difference between using the Raw file from a Nikon D3, and a jpeg produced by the same camera. Once again, it is not video. The color-under models and the like that video employs have no relevance to this camera.

 

[D Fuller]

Aha! Maybe.



I understand there's no 1:1. 3:1 is minimum. So 3:1 is LOSSLESS? That's what makes REDCODE 3:1 be RAW. Just not beyond that?

So RED made the choice of offering 18:1 compression at 4K, but didn't want to offer recording a scaled down image from 4K to 2K... with potentially a less lossy image than 4K 18:1?

The image can't be scaled with out first being debayered to RGB. They do that going out to the SDI port. You can record that if you want to, but you lose all the grading advantages that having the Raw data gives you. Also, it's questionable whether an RGM image at a lower data rate than an 18:1 4K Raw image will be less lossy.

 

[David Rasberry]

Excellent. So RAW is what the sensor delivers to a REDCODE processor inside scarlet. But we never get RAW, we always get REDCODE... it looks great, lots of data, but ever only an interpretation of the RAW data. Just never RAW.

Processing power is inside the scarlet to deliver scaled down version of the RAW, or maybe scaled down version of the REDCODE. So potentially with the scaled down you end up with 1 or 2 layer of compression, which is unknown to us or we know what we get?

Until you display any of the production in full 4K, what are the other reasons for having a 4K frame, especially if you consider non-feature fiction films (or should we only consider scarlet for that application), if you consider you're not going to crop inside of it to reframe your picture. How much would you lose if you were actually recording to these formats:
- The inexistant 2K scaled down redcode version of the 4K (5K if the scarlet is actually able to ingest RAW from the sensor at more than 12fps).
- uncompressed 422 10bit YPbPr (especially if your image is flat: low contract/saturation)
- 8bit 444 RGB

Maybe there's a thread (I looked..) where these images are compared. Might be worth to point to them if someone ever had that reference.



So what do we have? Why are we using the term RAW? Don't we have redcode only anyways? Isn't that an extrapolated then compressed version of RAW? Just a good looking one? Couldn't we get 2K REDCODE from 4k/5k?


------

Thanks for the time, explanation, effort. Hope it helps others as well.

Redcode raw is as raw as any similar image file that comes out of any Bayer sensor still camera, Nikon, Canon, etc,. all of which process and compress the sensor data in one way or another to their own unique file formats. It is raw because the raw luminance values for each individual pixel are recorded and extracted for post processing into a finished image as opposed to a finished encoded color image being recorded.

 

[Terry VerHaar]

Aha! Maybe.



I understand there's no 1:1. 3:1 is minimum. So 3:1 is LOSSLESS? That's what makes REDCODE 3:1 be RAW. Just not beyond that?

So RED made the choice of offering 18:1 compression at 4K, but didn't want to offer recording a scaled down image from 4K to 2K... with potentially a less lossy image than 4K 18:1?

RAW is RAW - it has nothing to do with compression. Without compression, you have all the sensor data in the file. With compression, you still have all the sensor data represented in the file, it has just been compressed. Like all compression algorithms, higher and higher compression eventually introduces mathematical loss - a point where the original file can no longer be perfectly reconstructed from the compressed version.

 

[Jean Simenon]

Like all compression algorithms, higher and higher compression eventually introduces mathematical loss -

Loss? But still RAW?

 

[Terry VerHaar]

Loss? But still RAW?

Yep!

 

[Jean Simenon]

Yep!

What you call RAW is only the fact that you can decode REDCODE only to find a similar but not the same original sensor bayer pattern then (still you have lost the original pattern... virtually turning your image in a smaller resolution image... let's say 3K). Any compression amount will still yield RAW with such a definition even 5K:1. Correct?... just because it hasn't been RGB'ed.

 

[Terry VerHaar]

Remember, we are talking digital here - 0's and 1's - that's all. So, the RAW file is simply a bunch of 0's and 1's that represent the luminance and color data (before it is actually color data) that has been captured by the sensor - plus some metadata that will travel along with the frame. As with all digital data, there are clever ways to compress it to take up less "digital space" - some with no loss of data whatsoever, others with varying degrees of loss.

If you are very clever with your algorithms (and RED is) you can squish this stuff down to be much smaller; first without losing ANY data and, as you squish more, only losing the least important data. And, if you are equally clever at restructuring that data when you "decode" (and RED is), you end up with a very (VERY) good representation of what you original captured. And, because you have recreated the RAW file (not an RGB image), you can still futz with things like ISO and color temp because you have access to THAT data in the "reconstructed" file.

(Where are Graeme and Deanan when we need them?) :smiley:

 

[David Rasberry]

What you call RAW is only the fact that you can decode REDCODE only to find a similar but not the same original sensor bayer pattern then (still you have lost the original pattern... virtually turning your image in a smaller resolution image... let's say 3K). Any compression amount will still yield RAW with such a definition even 5K:1. Correct?... just because it hasn't been RGB'ed.

When you debayer a 5k frame you get the full resolution 5120 x2700 pixel image with every pixel being a fully defined RGB pixel. How much compression you can get away with before the image visually degrades depends on how sophisticated the compression algorithm is at compromising only the data that is not visually relevant.

 

[Jean Simenon]

Remember, we are talking digital here - 0's and 1's - that's all. So, the RAW file is simply a bunch of 0's and 1's that represent the luminance and color data (before it is actually color data) that has been captured by the sensor - plus some metadata that will travel along with the frame. As with all digital data, there are clever ways to compress it to take up less "digital space" - some with no loss of data whatsoever, others with varying degrees of loss.

If you are very clever with your algorithms (and RED is) you can squish this stuff down to be much smaller; first without losing ANY data and, as you squish more, only losing the least important data. And, if you are equally clever at restructuring that data when you "decode" (and RED is), you end up with a very (VERY) good representation of what you original captured. And, because you have recreated the RAW file (not an RGB image), you can still futz with things like ISO and color temp because you have access to THAT data in the "reconstructed" file.

I can't imagine that you wouldn't be losing anything for color/luminance data. The data is 16-bit information and quite impossible to compress without loss. Beyond that the compression is saying that there are 3 red in row, eliminating the data for 2 pixels... just adding info to indicate the position of those 2 pixels in relation with the 1st pixel. But photo/video data is incompressible without loss. It's certainly possible to look at a line/group of pixels, identify their positions, and then indicate the DELTA between them to avoid having to replicate 16-bit info for each pixel.... Whatever they're doing. But there's loss.