Hi. I'm new here, so hi to all 🙂 . I've been using Adobe Premiere Pro for a while, and now I want to start editing and exporting in UHD HDR. I have a few questions (I want to explain the issues in detail, so please bear with me, and also with my english 🙂 )
AMD Ryzen Threadripper 2990WX
Motherboard: Asus ROG Zenith Extrema Alpha
64 GB RAM
NVIDIA GTX Geforce 1070
Sadly, an sdr monitor yet (but the rest of the hardware, specially the cpu, is a beast).
Samsung SSD 970 Pro 512 GB for OS installation.
Plenty of storage space on regular hdds.
Windows 10, with latest drivers.
Adobe Premiere Pro 2020
Adobe Media Encoder 2020
Latest version of Klite codec pack.
I know the limitations Pr has with showing hdr content on its internal monitors, but I understand that you can import and export hdr content that retains all of the color data. I don't mind those limitations too much, but it's been a little difficult for me to know how to actually work with these footages. A little info: my source file is a movie rip I made a while ago using Handbrake. It's in a mkv container, and it's UHD, codec h.265 10 bit. It has two audio streams and subtitles, so to be able to work with it in Pr without losing quality and suffering long encoding times, I "extracted" the video and one audio stream to a single HEVC file (for that purpose I used ffmpeg, just copied the streams, no encoding involved). I looked into that HEVC file using Mediainfo and it says that it's in fact HEVC, Main 10, Level 5, 15.6 mb/s video bitrate (the same as the original mkv file), chroma subsampling 4:2:0, Color space YUV , bit depth 10 bits and BT.2020, but variable bitrate (I don't know why since ffmpeg just copied the stream of the mkv file, which showed as cbr. Maybe Mediainfo is too sensitive sometimes, because I understand that there's no such thing as a perfect cbr file). So the file is fine for hdr, but since it's a long-GOP format I wanted to transcode it to another (hopefully) lossless format that also works well while editing, without losing any of the hdr required settings. Here are my questions/issues:
1) I want my original files to remain cbr, for streaming stability purposes and because I've read that using vbr with hdr can make some dark areas look not as good as they should. I tried with every version of Prores as Proxies, but I couldn't fix a sync issue. When I toggle proxies on and off you can see that the original file is not synced with the proxy (and like by 2 - 4 seconds, both video and audio), so it's useless for editing in my case. My guess is that it's because Prores is vbr and my footage is cbr, and that somehow may cause this sync problem. So I went for a not long-GOP format that keeps the hdr data, that's as lossless as it can be, that works well while editing, and cbr so hopefully it doesn't produce this sync problem. Another useful info: file sizes are not an issue for me. I went for DNxHR RGB 444 10 bits, because I gave up with proxies and wanted to use that one as the source file (in other words, the final export would be done using the DNxHR file as source file, not the original footage). I understand that DNxHR RGB 444 10 bits is probably my best bet for that because of the almost lossless quality, it works very good for editing purposes, and I won't have to worry about sync problems since I would be editing on the file itself (not proxy). My main questions regarding this are simple: is this a good idea? Does DNxHR RGB 444 10 bits in fact retain all the hdr data from a HEVC mkv file, with no loss in quality? In case that I go for this route (transcoding the original files to an intermediate file that would be the one used for exporting) and not using proxies there's no sync issue to worry about, so in this case would you recomend DNxHR RGB 444 10 bits or one of the Prores flavors? The thing that's keeping me with DNxHR and not Prores is that comment I read about vbr codecs not being ideal as source files for hdr, but I really don't know if that's true. Makes sense to me, though, since vbr could favor bitrate instead of quality in, for example, some dark areas. I remember that the guy that made the comment was very experienced in editing and coloring, and he strongly advised to edit hdr in cbr, never vbr.
2) To be honest, from the beginning I wanted to edit hdr content using proxies, and I didn't want to transcode my cbr original footage. The problem is that I simply couldn't find any format for the proxies that didn't have this sync issue besides DNxHR and AVI, but AVI looks more washed out when I'm previewing (I know that in Pr even DNxHR and Prores won't show the footage in rec.2020 as it should, but DNxHR proxies looked closer to the original files. Like I said, file size is not an issue for me). I really would want to edit with proxies, but I don't want to transcode the original files to vbr just because of this "out of sync" issue (and I'm not even sure that that's the cause of it, it's just a theory). What would you do? There's a lot of people that suggests Prores for proxies, but like I said I simply couldn't create them without being out of sync with the original footage, and that defeats all purposes for editing. Do you consider a good idea what I'm doing (transcoding the original HEVC file to DNxHR RGB 444 10 bits, edit with that file, and export to, let's say, a h.265 main 10 level 5.1 (mp4 as container) file directly from it?
3) Many people edit with Prores as the format for proxies, and don't suffer from this sync issue. That's only the case if the original files are vbr? The people that use Prores as proxies and don't have this issue, what's usually the format of the original files they have?
4) This is something that caught my attention, and I don't know if it matters or not (I googled and found contradicting info). When I look into the original mkv file with Mediainfo, it says that the color range is limited and that it's cbr. The "extracted" mp4 file using ffmpeg says color range limited and vbr. When I look into the created DNxHR file, it says that it's cbr, color space RGB, and no word about color range. Then I did a test and exported a clip with all of the hdr required settings with h.265 10 bit as codec (main 10, hdr enabled, rec.2020, maximum color depth and quality, include hdr10 metadata enabled) and mp4 as container, using the DNxHR as the source file, and when I open that exported file with Mediainfo it says that it's cbr, and color range full. The question is, why did the color range info changed from limited to full after the final export? Because of enabling the include hdr10 metadata option? Does it matter in anyway? There are a lot of things that I'm trying to learn, and I don't know if editing with a DNxHR as source file with color range limited according to Mediainfo will have an impact on the final export (quality and hdr wise).
5) Related to the previous questions, when I import the "extracted" mp4 file (the one that in theory wasn't encoded in anyway from the original footage) and go to the Lumetri scopes tab (and enabling rec 2020 color space and selecting hdr at the bottom), the whole video, in it's brightest parts, is always clipped at 100 nit. It looks overexposed in the monitor, but the fact is that this way it seems I'm not even opening an hdr file, or that it's not being recognized as such. I've yet to try to import the DNxHR file to see if the same thing happens (I'm not at home right now), but I did a test last night. I exported a short clip with all the hdr settings enabled (rec. 2020 primaries, hdr, include hdr10 metadata, etc), codec h.265 main 10 level 5.1 using the extracted mp4 file as source file (which, like I said, is a direct copy of the original stream, that was always clipped at 100 nit), and then imported that HEVC clip to Pr. When I looked at the Lumetri scopes tab, to my suprise it seems to behave as a true hdr file, with bright parts even reaching 200 nits. What's happening here? Again, is it because of the "include hdr10 metadata" feature being enabled when generating this file? If I wanted to edit with that extracted mp4 source file, I wouldn't be able to color correct if it's clipped. Hopefully it won't be clipped when I try with the DNxHR file when I get home, but I would like to understand this a little better. So far, the only clip that wasn't clipped at 100 nit is the HEVC one that was generated with Pr, and I really don't want to color correct with it since it's slow for editing and would require an extra encoding step, which I think is unnecesarry and time consuming (let alone that it could degrade the quality a little).
6) In Pr, when I look at the metadata of any of this clips (no matter if it's the HEVC file, DNxHR or Prores), in the dynamic media section, when I look at color space the field is empty. I watched a hdr workflow tutorial on Youtube and the guy showed examples of clips that did say BT.2020 on that field and clips that didn't. He said that this was because Pr is still early in hdr adoption and that the clips with that empty field are not being recognized as hdr files, so if that's the case you shouldn't be editing with that file if you want to export real hdr. Is that so? Because no matter what file I import, doesn't matter the codec or container, that field is always empty. So if the guy is right, I'm not going to export in true hdr, and I want to know what should I do in that case (maybe a format that I don't know about that actually shows something at the metadata tab, idk). Anyway, if I click on properties of that particular clip inside Pr, it does recognize it as a HEVC 10 bit file.
7) This has nothing to do with my previous questions, and I think many are suffering from this, so I'll ask here. Pr 2020 continuosly freezes (sometimes at random moments, and it's very common when trying to export). In my case it's not when starting the program, but randomly when I'm working with it. Haven't been able to troubleshoot this because the freezes are literally random. Sometimes I'm even just moving the mouse and it freezes and I have to kill the process. Does this have a fix yet? Any suggestions? I'm the kind of guy that feels more comfortable using the latest versions of a software, specially when dealing with a technology that's not so mainstream yet (hdr), so I'm reluctant to go back to a previous Pr version, but this is unusable most of the times. Pr 2019 worked a little better, but had these random crashes too sometimes. I've read that Pr 2018 is very stable, but idk if I'm going to lose some valuable features for hdr editing and coloring with it.
8 ) I'm used to Pr, so it has to be a really powerful reason for me to change to another software like Resolve (and I also don't have much time to learn how to use a new powerful software from scratch), so for the meanwhile I'm staying with Pr. I say this because I'd appreciate your help with this, but it's still not an option for me to change the editing software.
9) Any news about plans on improving the sdr conform feature, or something that replaces it? It's not a pleasant experience having to color correct the project two times, and export it two times too.
10) Probably not, but is there any official info by Adobe about true Rec 2020 support? Not just for importing and exporting. And if there is, any estimated date? It should be on the top of the to do list.
Thanks for reading and sorry for the long text, but I wanted to give all the info you could need. Thanks in advance, and again, sorry for my english 🙂
Just following up on your old post - How much success did you have with HDR export? I haven't gotten far with Premiere. Any HDR export (H264 or HVEC) comes out way too dark - I've tried all options I can see and tested files on a variety of HDR and SDR platforms with the same dark result.
My source content is not video, but 16 bpc CGI sequences. At this stage I'm not concerned with perfect color matching within PP as I understand it has preview limitations, but it still doesn't make sense that the workflow is so bad. I've heard Davinci Resolve Studio is much better for HDR editing so may have to look into that.
Anyway hope you had more luck 🙂
CGI dude ...
PrPRo's current HDR capabilities are a bit awkward to work with. And they've changed since the original post here was filed, significantly.
First, you need to work with media which can do the HDR fandango ... it's as much bit color volume or gamut as well as bit depth. Many H.264 files will be both 8 bit and in straight Rec.709 primaries, and may not stretch all that well because it isn't just the dynamic range (dark to light) but the color hue range (gamut) that is also significantly bigger in HDR.
RAW or log media tend to work better, for example.
And yes, you do want 10 bit if at all possible.
Next, in Premiere, you would need to set the Project settings to (probably) Color Management option to 203 nits. Then in the Sequence settings, color space to either 2100 PQ or HLG. You need to set the Lumetri scopes to the same color space as your media, and select the HDR option in the lower-right corner for what scales are displayed on the scopes.
You should have the Display color management option on in the preferences. Now you can actually work in HDR, and at least the scopes should show what is going on. You may be able to get sorta kinda the proper view IF you have an HDR-capable monitor and say Windows will show that monitor in HDR mode.
Your CGI images/plates coming in ... what color space & gamut are they? What primaries?
Hi Neil - thanks for your reply. I had done those things in Premiere but I think the problem as you aluded to was earlier in my process, i.e. the colour gamut of the CGI imagery. My 3D app is Maya, all input textures were sRGB as was the output sequences. But since Maya 2022 has been released I now have the following 5 options to choose from:
- scene-linear Rec.709-sRGB
- scene-linear DCI-P3 D65
- scene-linear Rec.2020
I'm assuming I should choose Rec.2020 output, but would this mean all textures on the 3D models also need to be HDR in the Rec.2020 color space? I will ask the Redshift user forum for advice on this maybe.
It may be that this is too much of a mission right now and I certainly don't need it yet for business, but it is very interesting to learn about so I'm ready when HDR becomes more standard.
I think for working in PrPro at this time ... you'd need to use the Rec.2020 output from Maya, worked on a Rec2020 sequence in PrPro.
It's sorta kinda possible at this time to work HDR in PrPro as I've noted, but I'm hoping they'll give us better controls and capabilities ... soon.
I've just found out that the next version of my GPU renderer for Maya (Redshift 3.0.46), fully supports ACEScg output. Any 8bit sRGB texture conversion will be handled by Redshift automatically at render time, so I shouldn't have to do anything which is great.
What is an unknown is ACEScg support inside of Premiere... which from what I've googled is non-existant sadly...
ACES isn't supported at this time in PrPro. It's a very, very different and complex color math setup.
I'm a contributing author at MixingLight.com, a pro colorist's subscription website. The team of founders ... Robbie Carman, Pat Inhofer and Dan Moran ... are folks that have taught at NAB and other places for years. Robbie had only the second facility on the east coast US certified for DolbyVision production. And they were hired by Dolby Labs to do the in-house made training on using DolbyVision in pro work.
They've of course been based in DaVinci Resolve (though Dan has moved on to Baselight). And as I teach people who are typically based in Resolve to work color in Premiere, I have to be pretty well versed in Resolve.
Of the many colorists that are teachers or members of MixingLight, I'd guess a third at most actually work most of the time in a full ACES workflow. It's so different, the correction tools seem different, the process to get media into and through is more complex, and the results are ... sometimes better.
Even the ones that work a lot in ACES don't do every job in it. It's that different. And in many ways, more difficult. In a few ways, it is more simple of course.
I would love to have ACES available in PrPro. I'm pushing the program heads and color scientist to get the ability to set the color gamut (not space, gamut) of a timeline to a wider one such as RED wide-gamut, or the Arri and Sony equivalents. With the ability to do a transform on all media into that gamut for working on a timeline no matter if the project is Rec.709 or 2020. Or both.
But at this time, ACES is not part of PrPro. And it's not a savior of the image ... it's another tool. Parts of it are wondrous, but it ain't the cure for everyone's ills.