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

Prores 4444 - YUV or RGB ?

B

Bryan Golder

Well-known member
Joined
Sep 12, 2007
Messages
72
Reaction score
0
Points
6
Location
Burbank, CA
When exporting from Redcine-X to Prores4444, is that CODEC storing the image data as YUV or RGB data?

Is it possible for the conversion application, ie Redcine-X, to select YUV or RGB values to store in Prores 4444?

I'm confused about it...because apparently ProRes4444 supports both...

Thanks,
Bryan
 
I would think it depends on your final delivery target. For HD broadcast you want YUV. For film finish or web media RGB.
 
This could be wrong, so somebody from RED please verify this, but I THINK that it depends on how you set color in REDCine-X. For example, if you transcode using Camera RGB, I think ProRes 4444 retains the RGB. If you're using REDColor, I believe that is YUV. Again, can somebody from RED confirm or refute this please?

- Jordan
 
ProRes4444 is RGB only. If you want YUV, you want ProRes422 (or for 10-bit, ProRes422 HQ).
 
Jordan Livingston said:
That was basically my understanding as well, although I heard that it can either YUV+ or RGB+.

- Jordan
Click to expand...

cool, good to know. I'll bet the color space of the current FCP would mean exports from FCP are YUV only and I'll hazard a guess that cineX export would be RGB.
 
Gary wrote on one of his blogs that it could be both, and that he had measured the one on the beta-alexa he was doing his initial test on to be YUV, but that he expected it to be RGB by the release, or something... Over @ the cow, me thinks...
 
Erich Ocean said:
ProRes4444 is RGB only. If you want YUV, you want ProRes422 (or for 10-bit, ProRes422 HQ).
Click to expand...

Well, it turns out I was wrong. Here is the correct information (direct from Apple):

The new Apple ProRes 4444 codec preserves motion image sequences originating in either 4:4:4 RGB or 4:4:4 Y’CBCR color spaces. At its remarkably low data rate as compared to uncompressed 4:4:4 HD, Apple ProRes 4444 supports 12-bit pixel depth with an optional, mathematically lossless alpha channel for true 4:4:4:4 support. Apple ProRes 4444 preserves visual quality at the same high level as does Apple ProRes 422 (HQ), but for 4:4:4 image sources, which can carry the highest possible color detail.
Click to expand...

and

4:4:4 is the highest quality format for preserving chroma detail. In 4:4:4 image sources, there is no subsampling, or averaging, of chroma information. There are 3 unique samples, either Y’, CB, and CR or R, G, and B, for every pixel location. Apple ProRes 4444 fully supports 4:4:4 image sources, from either RGB or Y’CBCR color spaces. The fourth “4” means that Apple ProRes 4444 can also carry a unique alpha-channel sample for every pixel location. Apple ProRes 4444 is intended to support 4:4:4:4 RGB+Alpha sources exported from computer graphics applications such as Motion, as well as 4:4:4 video sources from high-end devices such as dual-link HDCAM-SR.
Click to expand...

And here's Apple's white paper on ProRes: http://images.apple.com/finalcutstudio/docs/Apple_ProRes_White_Paper_July_2009.pdf
 
OK, one sec here.... 4:2:2 is another way to define YUV, where you allocate twice the bandwidth for the luminance channel, due to bandwidth limitation. Since 4:4:4 doesn't have the same bandwidth limitations it is inherently RGB.

At least thats my understanding.

Any one else smarter care to chime in?
 
I get that ProRes 4444 can handle either RGB or YUV sources. I also get that the Alexa testing Gary was doing was of a beta implementation that did not have all the flavors of ProRes available. That said, AFAIK, once you write a ProRes 4444 file it is RGB+A. I have always treated it as RGB and had the results I expected. Perhaps there is a toggle to create a YUV version but that would be news to me.

Cheers - #19
 
what do you mean inherently?

Y stands for luma, so YUV (Y,Cb,Cr) means its storing the greyscale channel, the blue channel and the red channel and green is calculated differentially.
 
Color difference signal

Color difference signal

An analog color difference signal (Y,Pb,Pr) can be digitized (to create Y,Cb,Cr) at 4:2:2 or 4:4:4 sample rate ratios.

It's most common to do so at 4:2:2 and RGB is always digitized at 4:4:4, hence the potential for confusion.

So best to specify when using 4:4:4 what you mean.
 
Blair S. Paulsen said:
AFAIK, once you write a ProRes 4444 file it is RGB+A. I have always treated it as RGB and had the results I expected. Perhaps there is a toggle to create a YUV version but that would be news to me.
Click to expand...

I too haven't ever seen Y'CBCR ProRes4444 footage, but according to Apple, it's possible:

In addition to supporting Y’CBCR or RGB 4:4:4 pixel data, the new Apple ProRes 4444 codec type optionally supports an alpha channel. The sampling nomenclature for such Y’CBCRA or RGBA images is 4:4:4:4, to indicate that for each pixel location, there is an alpha – or A – value in addition to the three Y’CBCR or RGB values. An alpha value specifies the proportion of its associated RGB or Y’CBCR pixel that should be blended with the pixel at the corresponding location of a background image, creating the effect of varying transparency for use in compositing workflows. Unlike Y’CBCR or RGB pixel values, alpha values do not represent samples of a real-world image, or even samples of a computer-generated image, both of which are intended for human viewing.
Click to expand...
 
Glad I posted this...looks like there's a few out there who will benefit from sharing some info on this issue...

Let me extend the question a bit for more context:

Would there be any additional benefit to transcoding R3D images to Prores4444 as YUV, vs RGB?

Isn't one of the benefits of YUV in a 422 codec that is can store superwhites/superblacks?

Would that same benefit apply with respect to a 444 codec storing YUV?

I'm just not clear as to what is the specific benefit of Prores 4444 being able to store YUV, and for what specific reason would someone choose to do so?

(All of this in the context of R3D raw as the source...)

Could more luma information be preserved from the R3D's (and throughout an FCP/Color workflow) if Redcine-X was outputting YUV in Prores4444?

This all stemmed from issues I'm running into with conversion of color spaces in a compositing program...a separate issue...but to provide context, I'm running into a bug in Conduit v2 (a nodal compositing program for use in FCP or AE) which will not allow rendering to Prores4444 as RGB. My source images are 4K Prores4444 from Redcine-X. Conduit only allows me to specify YUV at export. Choosing RGB fails with an error. It may just be a bug in Conduit (developer just replied to me today and is going to check it out), but...in the meantime, it got me wondering again about the Prores 4444 YUV vs RGB issue.

Also, Redcine-X is having problems exporting Prores4444 4K images (crashing intermittently during rendering due to issues with Quicktime memory handling according to Red), so at this point I'm about to chalk the whole 4K Prores4444 workflow experiment up as a lesson learned and go back to using image sequences.

I was excited about the prospects for saving time/bandwidth/storage/etc by using Prores4444 for a bunch of fairly straightforward greenscreen/vfx shots on this project...but it's just turning out to be too much trouble.

But the only way to find out was to try it... :nopity: :svengo:

Thanks,
Bryan
 
RE super whites and super blacks.

I've taken media from my canon dslrs and transcoded to 4444 using compressor.
(at this stage I'm assuming its YCbCr because FCP is not rgb native)
When I send that transcoded 4444 file from FCP to COLOR and look at the trace I see that
super white and super black is not supported.
If I repeat everything with 422 I can see on the color trace that it is.
 
You must log in or register to reply here.
Back
Top