Why ProRes/DNxHR 4444 should always be legal/limited range?...

[poisondeathray]

Originally Posted by kolak

ProRes is always YUV based internally.

Perhaps it's stored that way, like other codecs that have YUV and RGB, but do you know of any implementation that handles Pr4444 with RGB options properly ?

The Apple Prores whitepaper claims that Pr4444: "also offers direct encoding of, and decoding to, both RGB and Y’CBCR pixel formats."

Originally Posted by kolak

ProRes444 out of Resolve will have min Y as 254 and max Y of 3765 for SMPTE bars. Both slightly off ideal values.
ProResHQ will have 63 and 941.
(at least those are reported by ffmpeg, which I don't trust 100% either).

I don't 100% trust them either, and I always try verify with other tools/workflows. You can export 12bit dpx out of Resolve, using various Resolve decoder(s) and measure that (if the import wasn't 12bit dpx, resolve 17 clips 4095 on windows according to the test above) also check export 16bit PNG/TIFF and downcovert to 12bit without dithering and measure

DNxHR has 245 and 3777, but because ffmpeg decodes it to YUV (even if file is RGB). I requested YUV stats, so actually it has to convert.

Yes, reported before on ffmpeg trac for DNxHR 444 12bit RGB. The dev answer was: "This is because files use ACT, adaptive color transform, when some blocks are encoded in RGB instead of YUV and vice versa." - and it's not implemented in libavcodec for DNxHR decoding . If you take the test ramp posted above, and encode to DNxHR 444 12bit in resolve, you can see the errors in ffmpeg/libavcodec based decoders on the RGB blocks.
(e.g. vapoursynth/avisynth lsmash, ffmpeg/ffplay/mpv) . I also posted examples in other threads

Some things never change- it's that much you can trust those pro tools

Certainly the lessons I've learned in the past are are don't blindly trust any tool (pro or opensource) . Version upgrades can break stuff previously working. Don't upgrade in the middle of projects. Verify your workflow before you commit to anything

[groucho86]

Broadcast/ streaming services don't care about this stuff and will expect limited range anyways

There's one service that explicitly asks for full range and I've been academically debating it with them....

This is just academic geeky testing

100%. And loving it

Can you check on a mac if the 12bit DPX import/export clips 4095 ?

Confirmed still clipping.

Originally Posted by kolak

No one said YUV has to be legal. There is no such a hard requirement. It's just how it was used in the past, so it became a norm, but it's really obsolete "requirement". Today's digital world doesn't need it anymore. If not worse compression efficiency we could just stick to RGB snd don't even bother with YUV. YUV is for saving bandwidth (by 'cheating' on sampling) and also to get better compressibility.
When it comes to ProRes itself then things are bit different, because by official spec ProRes should always be legal. There is no way to flag range in ProRes private headers (nor in eg. MOV container), but there is in MXF. Saying this you can export full range ProRes, just be careful when importing as app has to be "somehow" aware it's full range. Resolve lets you interpret both ways, where eg. Premiere has (stupid) hard coded rules- 422 is always treated as limited where 444 as full!. ProRes is always YUV based internally.
In this aspect DNxHR is better as it has private headers range flag and 444 can also be YUV or RGB based, so it covers all cases (if I remember well Resolve uses RGB version).

I did not know Premiere assumed ProRes 4444 (MXF and MOV?) was full range. That is strange.

...

So I decided to take a break from pattern testing - clearly the SMPTE bars were giving me an incredibly incomplete picture of of RGB > ProRes 4444 > RGB.
I took 10min worth of 16bit DPX source of Rec2020 (P3 constrained) PQ 1000nit and used Colorfront Transkoder to render out ProRes 4444 legal and ProRes 44444 full and brought them back in to run PSNIR metrics against the original source. Results:

Legal ProRes 4444
min: 52.4257
max: 90.0
avg: 59.19808741851951

Full ProRes 4444
min: 53.2485
max: 162.556
avg: 59.91924627198857

As predicted by poisondeathray and others, full range provided a slightly better match. My SMPTE bars test was flawed.

In conclusion...?
Pros for full range ProRes 444 MOV

• Higher fidelity

Cons for full range ProRes 444 MOV

• No tag that specifies full range. Most softwares will misinterpret it as legal

Pros for legal range ProRes 444 MOV

• Expected spec
• Most softwares will correctly interpret it

Cons for legal range ProRes 444 MOV

• Slightly lower fidelity

[poisondeathray]

Originally Posted by groucho86

There's one service that explicitly asks for full range and I've been academically debating it with them....

Not common at all...

Which service out of curiosity ? One would have to assume they were handling full range correctly

And did they ask for Pr4444 full range specifically ? or just full range in general ?

[groucho86]

Originally Posted by poisondeathray

Not common at all...

Which service out of curiosity ? One would have to assume they were handling full range correctly

And did they ask for Pr4444 full range specifically ? or just full range in general ?

I'd rather not say on a public forum. But yes, we need to assume they're handling it correctly...

UHD deliverables (SDR and HDR) are to be ProRes 4444(XQ) full range

HD SDR deliverables are to be ProRes 422 HQ legal.

[poisondeathray]

Originally Posted by groucho86

UHD deliverables (SDR and HDR) are to be ProRes 4444(XQ) full range

Interesting, full range unexpected for SDR in this scenario

[kolak]

Dolby created mess saying DV has to be full range. It all went bad as most people use ProRes for DV mastering (one level down from 16bit TIFF masters) without knowing that there is nothing describing range in ProRes MOVs.
Now it's all been recalled You can and maybe should use limited range for DV ProRes masters. It's practically harmless (lost precision is meaningless), where full range will in 50% cases handled badly!

If delivery place says full range ProRes I would assume they know what they are saying and will handle it properly. 99% is limited range and better stay this way until specifically requested otherwise.

[kolak]

Originally Posted by poisondeathray

Perhaps it's stored that way, like other codecs that have YUV and RGB, but do you know of any implementation that handles Pr4444 with RGB options properly ?

The Apple Prores whitepaper claims that Pr4444: "also offers direct encoding of, and decoding to, both RGB and Y’CBCR pixel formats."

This is confirmed now by many different sources including a guy who can write bit-perfect to Apple ProRes encoder.

Apple paper says encoder/decoder can take RGB data directly (it does internal conversion). Basically that's all what it says in this magic line. Internal data is always YUV (probably for efficiency).

There is no ProRes which stores data as RGB as this is not in Apple spec.
If you want that use DNxHR (just make sure app uses RGB variant for 444) or Cineform.

[poisondeathray]

Originally Posted by kolak

There is no ProRes which stores data as RGB as this is not in Apple spec.

I was asking about output from the decoder (less interested in how it's stored; but YCgCo would technically be better) - Are you aware of any Pr4444 implementation that has YCbCr vs. RGB output options or controls? Whitepaper implies 2 decoding cases, RGB and YCbCr. For example, you feed RGB in , you get RGB out. Or you feed YCbCr in you get YCbCr out . It seems to be YCbCr in most cases, and the host application possibly converts to RGB .

[groucho86]

Originally Posted by poisondeathray

Are you aware of any Pr4444 implementation that has YCbCr vs. RGB output options or controls?.

Nope, always been under the hood.

[kolak]

Originally Posted by poisondeathray

I was asking about output from the decoder (less interested in how it's stored; but YCgCo would technically be better) - Are you aware of any Pr4444 implementation that has YCbCr vs. RGB output options or controls? Whitepaper implies 2 decoding cases, RGB and YCbCr. For example, you feed RGB in , you get RGB out. Or you feed YCbCr in you get YCbCr out . It seems to be YCbCr in most cases, and the host application possibly converts to RGB .

As far as I understand official decoder provides many pixel formats on output (you can feed many on input as well).
It' up to the app to call what it needs/wants. I think Resolve in most cases uses b64a (16bit RGBA), FCPX 32bit float YUV4444 (r4fl). If app is good it writes properly which pixel format was used on input and you can check it with advanced view in mediainfo. Some apps may "lie" though
So basically it all depends how app is written. Good ones try "most direct" pixel format between input/output, eg. if you converting ProResHQ to Cineform it will most likely go over v210. If there is no need you should avoid going to RGB.
RGB in, RGB out would make sense if encoder had native support for YUV and RGB (DNxHR, Cineform). If it does conversion then it's already "less perfect", but you may still avoid double conversion.

Nuke may let you choose requested pixel format. Use to have this.

You have list of supported formats here:
https://wiki.multimedia.cx/index.php/Apple_ProRes

[kolak]

Originally Posted by groucho86

I did not know Premiere assumed ProRes 4444 (MXF and MOV?) was full range. That is strange.

I think last version I tested was 2020. It's was hard coded and Premiere has no "easy" way to overwrite range (like eg. Resolve does). It's very dangerous behaviour.
MOV, no idea about MXF.
Try it. You will see bad levels straight away if you feed limited ProRes444. Then do full and it should be fine.
Resolve (and many tools) always (for 422 and 444) uses limited by default (this is more per Apple spec I think).