Why ProRes444 is not RGB based?

Why ProRes4444(XQ) out or Resolve is not RGB based, but YUV 4:4:4?
It would be better to have it as RGB (or ideally have option to choose) as then there is way less constant RGB<->YUV conversion further in the production chain. As a very high quality codec and often used not for final delivery, but as intermediate production format it should be RGB based.

Apple quite clearly says it can be RGB:

"Direct encoding of, and decoding to, RGB pixel formats"

which is exactly what we want, instead of constantly going YUV<->RGB on every import/exports.

(https://documentation.apple.com/en/fina ... tasks=true)

There seems to be some contradictory statements as quite many industry people keep saying ProRes is alway YUV based, yet Apple in white paper is clearly saying RGB based encoding is also supported. Yet, I have never seen RGB based PorRes file (if mediainfo is to be trusted).

Resolve ProRes444 is actually "strange" as it uses src_pix_fmt=14, which is "invalid". This field suggest what uncompressed data was fed into code for encoding. Possible options are here:
https://wiki.multimedia.cx/index.php/Apple_ProRes
Most typical for 4:2:2 option is v210.
For 12bit RGB we should expect 'b64a' (16-bit ARGB). 12bit YUV 4:4:4 should go over 'r4fl' (32-bit floating-point 4:4:4:4).

In contradiction to ProRes444, DNxHR 444 is exported as RGB, which is good. It also perfectly supports 12bit precision. In case of ProRes4444 there is some "strange" noise in last bits, so it's more like 11.5 bit, not 12. This may be related to actual fact that data is YUV encoded and has to be converted to RGB (in Resolve or AE).

Another hint that ProRes4444 in Resolve is YUV based is fact that new super white/black preservation option is enabled, where for DNxHR 444 is not (as it's RGB based).

I would really like to get some official statement about it (and option to be able to choose RGB/YUV for DNxHR/ProRes 444).

There are no ProRes4444 RGB output options in Apple FCPX, Motion or Compressor either, so it's probably an issue to take up with Apple rather than BMD.

Well, this is not an explanation.
If RGB mode is there in codec, it should be used, specially when it makes perfect sense.

There are no ProRes4444 RGB output options in Apple FCPX, Motion or Compressor either, so it's probably an issue to take up with Apple rather than BMD.

it's not an apple problem, several of their white papers make it blatantly clear that RGB is supported.

It is not used by DR. Simply use another codec, DNxHR is just as good and Cineform even better.

There are no ProRes4444 RGB output options in Apple FCPX, Motion or Compressor either, so it's probably an issue to take up with Apple rather than BMD.

it's not an apple problem, several of their white papers make it blatantly clear that RGB is supported.

While the Apple Prores Whitepaper does indicate RGB support, Apple have not implemented RGB support in any of their software products. Apple probably have more info on why this is so, rather than BMD.

However, I can understand Andrew, because reading things expressively stated this way (see bold parts) doesn't give you any feeling it may result in the contrary and/or random stuff...

The Apple ProRes 4444 codec offers the utmost possible quality for 4:4:4 sources and for workflows involving alpha channels. It includes the following features:

Full-resolution, mastering-quality 4:4:4:4 RGBA color (an online-quality codec for editing and finishing 4:4:4 material, such as that originating from Sony HDCAM SR or digital cinema cameras such as RED ONE, Thomson Viper FilmStream, and Panavision Genesis cameras). The R, G, and B channels are lightly compressed, with an emphasis on being perceptually indistinguishable from the original material.

Lossless alpha channel with real-time playback

High-quality solution for storing and exchanging motion graphics and composites

For 4:4:4 sources, a data rate that is roughly 50 percent higher than the data rate of Apple ProRes 422 (HQ)

Direct encoding of, and decoding to, RGB pixel formats

Support for any resolution, including SD, HD, 2K, 4K, and other resolutions

A Gamma Correction setting in the codec’s advanced compression settings pane, which allows you to disable the 1.8 to 2.2 gamma adjustment that can occur if RGB material at 2.2 gamma is misinterpreted as 1.8. This setting is also available with the Apple ProRes 422 codec.

While the Apple Prores Whitepaper does indicate RGB support, Apple have not implemented RGB support in any of their software products. Apple probably have more info on why this is so, rather than BMD.

Yes, but if RGB is supported then it's just a switch in SDK to encode as RGB or YUV, so crazy easy to implement.

However, I can understand Andrew, because reading things expressively stated this way (see bold parts) doesn't give you any feeling it may result in the contrary and/or random stuff...

Code: Select all

The Apple ProRes 4444 codec offers the utmost possible quality for 4:4:4 sources and for workflows involving alpha channels. It includes the following features:

    Full-resolution, mastering-quality 4:4:4:4 [b]RGBA color[/b] (an online-quality codec for editing and finishing 4:4:4 material, such as that originating from Sony HDCAM SR or digital cinema cameras such as RED ONE, Thomson Viper FilmStream, and Panavision Genesis cameras). The R, G, and B channels are lightly compressed, with an emphasis on being perceptually indistinguishable from the original material.

    Lossless alpha channel with real-time playback

    High-quality solution for storing and exchanging motion graphics and composites

    For 4:4:4 sources, a data rate that is roughly 50 percent higher than the data rate of Apple ProRes 422 (HQ)

    [b]Direct encoding of, and decoding to, RGB pixel formats[/b]

    Support for any resolution, including SD, HD, 2K, 4K, and other resolutions

    A Gamma Correction setting in the codec’s advanced compression settings pane, which allows you to [b]disable the 1.8 to 2.2 gamma adjustment that can occur if RGB material at 2.2 gamma is misinterpreted as 1.8[/b]. This setting is also available with the Apple ProRes 422 codec.

Whitepaper repeats it:

"It also offers direct encoding of, and decoding to, both RGB and Y’CBCR pixel formats."

key word there is direct for me. It means it should encode RGB as RGB, not convert internally to YUV.

update:

after further discussion with "some" people I'm not so 100% sure anymore. If you read this carefully it says direct, but it also says "encoding of, and decoding to". This can also easily mean- we can take RGB data and decode to RGB data, but it doesn't guarantee encoded data is RGB based. This may be as well the case!