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

4:2:2 vs 2K?

4:2:2

4:2:2

Does the RED shoot 4:2:2 in the field onto the RED Drive, or does it have to be shot at "K" resolution then downgraded to 4:2:2?
Click to expand...

RED ONE always records REDCODE RAW... so yes you create 4:2:2 later in Post.
 
4:2:2 is a video color-subsampling format, the RED camera records a monochrome RAW image with a Bayer filter pattern which then has to be processed later into color, usually RGB.

If you want to work in a video format though like 1080P 4:2:2, you could create that.
 
Jesse Tunison said:
Does the RED shoot 4:2:2 in the field onto the RED Drive, or does it have to be shot at "K" resolution then downgraded to 4:2:2?
Click to expand...

While the other answers are absolutely right, they don't address a bit of confusion.

2K is a resolution. "K" refers to the horizontal pixel resolution of imagery.

4:2:2 is a chroma subsampling scheme.

They have nothing to do with one another. In fact the RED can record 1080p resolution, but the image information is always recorded as RAW.

The answer is that the RED shoots RAW footage at any resolution it supports. The RED footage is 4:4:4. So, as said before you can create 4:2:2 video from the RAW footage.

What may not have been clear is that the RAW footage has a lot more information than 4:2:2 video, then again that might be completely fine for your production- it certainly has been for most of my productions. Still, if you can, I would preserve as much of that RAW data as you can throughout your post production workflow.
 
Redcode

Redcode

David Mullen ASC said:
the RED camera records a monochrome RAW image with a Bayer filter pattern
Click to expand...

From what I have been able to gather, the RGB parts of the Bayer pattern are not compressed as a monochrome image, rather,

1) The RED and BLUE images are made from the RED and BLUE pixels, and are 1/4 the area or the full image (bacause RED and BLUE pixels are only 25% of the bayer pattern), or half width, so the RED and BLUE parts of the image are compressed as 2K images for a 4K sensor area.

2) The GREEN pixels are interpolated in the camera and the GREEN images is compressed full size, that is the GREEN image is 4K for a 4K sensor area. The GREEN image should contain some luma detail as well because the Bayer filter is not saturated.

If they did not do that chroma issues would happen because the wavelets cannot simulate the Bayer checker board to 12bit accuracy for some colors and shapes. There is nothing in particular lost using the smaller RED and BLUE images since you can interpolate them before or after compression with similar but not identical results.

In the Bayer pattern RED and BLUE have less "bandwidth" than the GREEN, and so are a little like LUMA + half bandwidth for chroma axis, but in the luma chroma system there is some mixing of the colors. Because the chroma matrix is done after the de-bayer interpolation (?) the large GREEN image should also have some luma detail from the red and blue light as well, so the visable resolution for all three colors ends up being more than 1/2 for most colors, depending on the low pass filters used in the de-Bayer.

Because there were plans to have a true RAW output port on the RED ONE the original idea seems to have been to have the frame de-Bayer compatable between the true RAW data and the wavelet compressed RAW data. Because they are ONLY using compressed data now, there might be advantages to using WIQ or other axis than RGB, since the data is processed in the camera, it is a matter of is the result better to do this interpolation before compression or do it after compression, and what matrix gives the best end result.
 
"...there might be advantages to using WIQ or other axis than RGB, since the data is processed in the camera, it is a matter of is the result better to do this interpolation before compression or do it after compression, and what matrix gives the best end result."

Dan, I often ask "what the hell?" after reading your stuff. This time is no exception.

What is "WIQ" and is this a current option?

Has anyone tested the end results compared to RGB?

Whatever happened to LOG? Is this related?

How do you know this stuff?
 
Dan Hudgins said:
1) The RED and BLUE images are made from the RED and BLUE pixels, and are 1/4 the area or the full image (bacause RED and BLUE pixels are only 25% of the bayer pattern), or half width, so the RED and BLUE parts of the image are compressed as 2K images for a 4K sensor area.
Click to expand...

I haven't studied debayering math enough to say i'm certain... but as far as i can tell this is essentially the same amount of information as 4:2:0 subsampled 4K would have - at least that's how i've always thought about it. It looks good to the eye, but the chroma isn't tack sharp or full resolution.

When the image is scaled down to 2K, it will be same as 4:4:4, where the green/luma information is supersampled, but the R and B is not.

Am i correct?
 
Eki Halkka said:
I haven't studied debayering math enough to say i'm certain... but as far as i can tell this is essentially the same amount of information as 4:2:0 subsampled 4K would have - at least that's how i've always thought about it. It looks good to the eye, but the chroma isn't tack sharp or full resolution.

When the image is scaled down to 2K, it will be same as 4:4:4, where the green/luma information is supersampled, but the R and B is not.

Am i correct?
Click to expand...

Well, for one thing, you can't directly compare those, since chroma subsampling and RED use completely different colour spaces...
 
RGB vs. WIQ etc.

RGB vs. WIQ etc.

Stephen Gentle said:
Well, for one thing, you can't directly compare those, since chroma subsampling and RED use completely different colour spaces...
Click to expand...

That was my point above, since REDCODE is no longer related to true RAW data, as seemed to be the plan two years ago, is there any need to be in RGB color space for the compression.

WIQ was the standard used for the original NTSC system, since then changes have been made to reduce the cost of equipment by not having two delay lines, and changing the bandwidth of the I and Q so they are not un-equal and such, but the original idea was to have more bandwidth for some colors than others, and that would reduce the blue noise without loosing detail in some of the green/yellow colors that the eye can see better and to improve flesh tones etc..

Using RGB with G as the LUMA and RB as the equal low bandwidth was not adopted by the NTSC, RCA tried that but NTSC thought the color was not good enough (dot encodeing). By re-mixing the colors into WIQ the results were improved and the noise from the camera tubes was reduced. The sensor is somewhat like the camera tubes in that the blue signal has higher noise than the red signal.

RED seems to have picked RGB color space because that way the R and B signals do not need interoplation IN THE CAMERA. That reduces the workload of the camera circuits, but does not in turn produce the lowest noise in the final images as viewed because the wavelet artifacts are introduced into the smaller R and B images (artifacts twice as wide as in GREEN) which ends up adding noise and artifacts to the LUMA later. If the LUMA was in the W ratio before compression rather than sensor GREEN there would be a small increase in detail and somewhat less noise in the final images, perhaps. It would depend on how well the de-Bayer was done in the camera to get LUMA rather than sensor GREEN for the full resolution compressed image.

Sensor GREEN is not full saturated GREEN so is not TOO far from W (W is a white standard, a little different from Y which is another white standard). It just puts the detail in an odd non-standard white balance that is not optimised for the human eye. Because R and B are lower resolution and distorted by the wavelet compression you cannot get the same LUMA detail by mixing in R and B after de-compression, it would be better to de-Bayer in the camera and derive LUMA before compression.

Again, I think they did not do that because of:

1) Compressing LUMA rather than sensor GREEN would cost more in camera CPU power, power, and heat.

2) There was a plan to have the true RAW port so the color space of the compressed and non-compressed data was made the same to have the same post production tools work with both source files.

These are not big issues, Build 21 looks better than Build 1 because they have inched away from their original vision, and are overcoming some of the RGB color space issues in the REDCODE compression.

My point was just that with the ALL NEW cameras does it make sence from a quality stand point to keep the RGB system, or go with what everyone else does which it to save LUMA at high bandwidth and CHROMA at the lower bandwidth?
 
Chuck Z said:
That doesn't make any sense. RED RAW can't really match true 4:4:4 since there is a single sensor of a Bayer filter design. However, that doesn't mean it can't look really good.
Click to expand...

That depends on the output image size. I.e. at standard definition output, R1 is definitely "better than 4:4:4", as all colors are well supersampled. At 4K, what you say is true of course, assuming the 4:4:4 would be done with three full 4K sensors. BUT, when using the same, current sensor, saving RAW and debayering in post is very likely better than debayering in-camera and then saving as 4:4:4.
 
You must log in or register to reply here.
Back
Top