Hi,
I’m struggling again trying to export a file.
Doco graded P3D65 ACES, rendered to me as 16bit EXR.
I need to export a rec2020 prores 4444xq.
I put on a TLFX view transform ACES 2065> ACES 1.1HDR video(1000nits)>rec2020.
I can view this and although it looks burned out on my gui (I’m remote), I can adjust the viewer exposure and all the detail is there, but when I export to prores and bring back in, all the highlights are clipped.
Do I need to ‘pre-transform’ the source to something prior to export?
use an input transform from ACES > rec2020 and skip the middle step you’ve got there.
make a viewing rule/monitor lut that will display rec2020 on a rec709 monitor (choose rec709 OOTF as the view transform and make sure your rec 2020 material is tagged correctly). This will allow you to view a reasonable aproximation of the result without having to mess about with exposure.
That being said I could be wrong somehow. I’ve heard a lot of confusing info about what rec2020 is or isn’t. My personal understanding is it’s got the same gamma curve as rec709 (2.4) and a wider gamut. I have however heard of it being an HDR colorspace, which is confusing to me because the entire point of rec2100 is that it’s HDR rec2020.
Hi Andy,
thanks for responding.
I’ve tried a straight input transform ACES>REC2020 and get the same result. I’ve never dealt with 2020 before, only ever 2100PQ and ST2084 (PQ) p3d65, for Disney and Netflix. This is also for Disney, but not seen 2020 in their spec till today.
The transforms on the timeline appear to be doing the right thing, its the export to Prores that’s clipping. I just cant understand it!
Typically, its late here and this file’s need first thing…
Yeah Rec. 2020 or BT.2020 is Standard Dynamic Range (SDR) with a wide colour gamut.
Not too sure about the transform sorry but I suspect that it should go through a view transform so that ACES can tonemap the HDR into SDR for you.
I’m not familiar with proresXQ, but maybe it´s a bit depth issue. Have you check bit depth of your exported QT? I guess it should be should be 16bpc so that they do not clip highlights.
Reading that spec sheet I have questions for whoever made it:
what is the “linear” in the bit depth referring to? 12 bit is not a suitable format for linear color spaces.
why rec2020 colorspace and not rec2100 for HDR?
why no specification for which HDR standard (PQ or HLG?)?
what does, “All QuickTime (MOV) files must be delivered as 64 bit. 32 bit files are not acceptable” even mean? Quicktimes can only be 8, 10, or 12 bits per channel. Even if you sum up all four channels on a 4444xq you can’t get to 64 bits! Are they talking about like the CPU or application that writes the quicktime?
just bonkers.
I’ve hated spec sheets since forever. You can never get ahold of the person who made them and everyone who hands them to you just blows you off and says, “just follow the spec sheet”.
You’ve summed up everything that was bugging me about that spec! It doesnt ‘smell’ right if you know what I mean.
Its defo missing some crucial detail.
thanks
Des
Hi guys,
thanks for your help and comments on this.
This show is actually a Disney/Nat Geo delivery so the spec is indeed different to what I’m used to with Disney.
I had another good look around the spec,and found this rather helpful little gem tucked away on the end of the ‘Welcome to’ section on page 2, the obvious place to find the missing jigsaw piece of spec info!!
A REC2100PQ view transform was the way to go, and inded this is what I left rendering out last night, as deep down I knew I was giving them what they wanted and needed, even if not necessarily what they’d asked for…
Happy you were able to get through this. The main issue is the confusion of BT.2020 PQ vs BT2100. Starting from now, when you see a spec document with BT.2020 PQ then your brain will tell you ithey mean BT.2100!
the only thing that confuses me is the “RGB video levels” thing.
Prores should never be full-range and .mov doesnt have a metadata tag saying what it is… so thats VERY dangerous, but if the spec sheet says RGB levels that means full-range i recon.
the 32bit/ 64bit seems to come from “mov32” and “mov64” writing libraries, dint know how that would matter for a final file however. maybe someone had a issue with some mov32 quicktime exporter for adobe mediaencoder 2.0 15 years back for whatever reason xD
Them not specifiying transfer function or any hdr metadata is of course… funky.
I’m going to disagree with quite a few people here
Rec2020 is a colour gamut. On its own It has nothing to do with defining something being HDR or not.
Gamma curve is entirely a different thing though. St.2084/PQ (they’re the same thing) defines it to be a High Dynamic Range format. Or HLG would do the same.
The difference between Rec2020 and Rec2100 is simply that Rec2100 specifically defines the gamma curve in the SMPTE specifications. So saying Rec2020PQ is not incorrect by any means. Tagging something as Rec2100PQ is the same as delivering something as Rec2020PQ.
If the project has accompanying Dolby Vision metadata then you definitely need at least 12bit depth. Asking for Full Range RGB is a means to get more information for potential transforms into SDR at a later stage. By going full range over video range, you have more numbers covering the same range. Considering this is a display referred colour space, and should be limited to the colour space, some of the reasons you potentially wouldn’t use QuickTime for a scene referred colour space are mute. It is a valid delivery medium.
The linear reference to bit depth doesn’t make sense but I see odd things in almost every spec. Quite often spec documentation even contradicts itself, especially in layout.
