Skip to main content
troth_nee_adobe
troth_nee_adobe
Inspiring
December 2, 2021
Answered

Poor man's workflow for preserving HLG for online platforms that support it

  • December 2, 2021
  • 2 replies
  • 3255 views

Let's say I'm a video enthusiast who wants to use Vimeo as my primary online distribution channel, AND I have a shiny new iPhone 13 Pro, that shoots Rec.2100 HLG for lots of things. And I want to edit this content in Premiere, and preserve the HLG in my AME-rendered output. Oh, and of course I will want to mix this HDR content with SDR content in the same project, and still have the HDR content look its best on Vimeo.

 

But let's also assume (correctly), that I haven't been discovered yet, so can't afford the hardware required to properly view and grade in HDR. What are the recommended best practices to accomplish this goal?

 

Vimeo supports HDR if you follow their rules (https://vimeo.zendesk.com/hc/en-us/articles/115015382768-Uploading-HDR-and-Dolby-Vision-videos). So if you upload properly constructed HDR content, a viewer with an HDR capable device (e.g. an iPhone 12 or 13) will see my work in all it's intended glory, and other viewers will see a SDR version, which Vimeo automatically transcodes from the uploaded original.

 

So, if I understand Premiere's new support for HDR, I think the workflow I need to get at least most of the way there goes like this:

1) Make sure my source footage is tagged properly with the appropriate color space. iPhone HLG footage is correctly tagged on import, as documented.

2) Use Rec.2100 HLG as my sequence's working color space. (To avoid HLG conversion to Rec.709.)

3) Make sure Display Color Management is enabled in prefs.

4) Make sure my project's "HDR Graphics White" setting is 203.

5) Use Lumetri corrections on the HLG content very sparingly, if I want to do some very minor color changes, such as tempature or tint changes to match other SDR footage in the project.

6) Export for rendering to AME, specifying HEVC(h.265), since it's an HDR format supported by Vimeo, and it's good enough quality for my purposes. Also choose the "HEVC - Match Source - HLG" preset, and appropriate encoding settings to achieve Rec.2100 HLG as the export color space.

 

What I've proven so far is that the simplest possible version of this workflow is successful, for a sequence with one iPhone HLG clip, and no Lumetri changes. The clip of course looks too bright in Premiere, but after rendering with AME the following is true:

1) It appears identical to the original clip when imported and viewed in Premiere.

2) It's metadata indicates its properly HLG.

3) It views correctly on Vimeo after uploading and compared to the original content on my iPhone.

4) It also views correctly back on my Mac after downloading from Vimeo and viewed side-by-side with the original.

 

So before I go further down this rabbit hole, it would be nice if someone could confirm that what I've described is the expected workflow to achieve my goals. If so, great, and of course, I realize it's impractical as soon as I would want to do any significant color editing/grading of my HLG content. But I'm thinking it would at least let me work with such content that doesn't need much color editing, and preserve it for platforms like Vimeo that are designed to support HDR.

This topic has been closed for replies.
Correct answer troth_nee_adobe

I think there might be a misunderstanding of my comments ... I was saying you have to go through the modify/Interpet process if you were trying to use an HLG clip on a Rec.709 sequence ... and export as Rec.709.

 

Because in the previous practice many HLG clips could be simply 'dropped' on a Rec.709 timline, exported as Rec.709 after color work, and work fine. Currently, that seems not to work for many users.

 

Your process was staying in HLG, which as I noted, does work. If you export with an HLG preset, or after manually modding the export controls to get an HLG export via settings.

 

Does that sound correct?

 

Neil


Well, no it doesn't sound completely correct, but it's no wonder why, with all the steps required and the two workflows I'm trying to test. It's pretty easy to misinterpret each other's descriptions of this stuff. 😉

 

My original post here was only about best practices for how to edit HLG content and preserve it on output, to give platforms that support HDR a chance to best display it.

 

With what I know now, I believe my only workflow error then was assuming I should use HLG as my working space. From my most recent results above, it makes sense now that the working space should be 709, since I don't have the hardware required to edit reliably in HLG. That of course necessarily means my HLG output from AME might be compromised, especially so the further away my color edits diverge from the original, but per my results when just trying to make HLG look reasonable in 709, they're surprisingly close to the original. So something fortuitous is happening in the HLG->709->HLG' transform, at least based on the tiny sampling of clips I've tried so far.

 

Along the way, I expanded the conversation to include best practice advice for the same source content (and possibly including SDR content too), targeting SDR output. And I now believe that the only change I have to make to achieve that is the target color space in AME. This is also what my testing results seem to prove, and seems to jibe with what you described as being problematic for many users.

 

I'm happy to believe maybe I'm getting lucky with just my iPhone 13 HDR footage, and my mileage may vary with other footage sources.

 

I think we're getting closer to converging on something, but any more comments? I very much appreciate them all!

 

 

2 replies

R Neil Haugen
R Neil Haugen
Legend
December 3, 2021

While much of the information of that pdf is still valid, there are a few things already outdated.

 

Such as the entire export section. They now have presets for HDR in HLG and PQ that are good starting places for work, and I would strongly suggest working with those as the basis for creating your own HDR export presets.

 

Yea, things are changing that fast.

 

As to working with HLG clips from your phone, that is easy to do accurately within Pr2022.

 

First, make sure the clips are HLG ... check the clip properties.

 

I have found that for some reason, even when using an HLG clip that is fully tagged and recognized by Pr2022 as HLG, if I use the "new sequence from clip" it will still make an SDR/Rec.709 sequence!

 

In that case, the HLG clip looks terribly blown out, and the Vectorscope may be blown to bits (metaphorically speaking ... ).

 

Simply go to the Sequence settings, and change the Sequence color space to HLG. I've found I need to manually shift the scopes to the correct color space also, and set the lower-right option for scope scale to HDR with HDR clips.

 

But I have quite successfully worked with HLG clips through export and re-import. It's pretty straight-forward once you've done it.

 

Neil

Everyone's mileage always varies ...
troth_nee_adobe
troth_nee_adobeAuthor
Inspiring
December 3, 2021

Thanx Neil, for your thoughtful reply. Based on everything you said, maybe I'm doing everything right then, and my expectations just need to be reset re how much Lumetri work is required. Perhaps you can comment on that too, based on  your experience?

 

I had found the AME presets for HLG export - a variant of one of these seems to work properly for export.

 

And I think I've got my source and working space correct, and my Lumetri scopes seem to behave properly. And so far, all my iPhone HLG footage is being properly, automatically recognized correctly by PP.

 

So am I correct that with all these prerequisites, I should expect to see my footage overexposed initially? If I simply use Lumetri to reduce the exposure, I can quickly make the footage look close to matching what either my iPhone displays for the same content (modulo the expected difference in brightness and dynamic range, since it's an actual HDR device). But then I find I need to spend quite a bit of additional time in Lumetri to get the footage to come close to matching what both  QuickTime Player and the TV app display for the same content. (Yes, I know about the historic gamma issue for QT, and possibly for TV, but I claim their display should be a reasonable reference point for simply trying to use Lumetri to get close.)

 

And if you follow all this logic, this is why I was thinking the workflow might be ripe for an input LUT to help automate this process when you only want SDR output. I'm imaging an iPhone-specific HLG-SDR input LUT, that would result in less additional Lumetri fiddling. And when I mentioned this to Paul Leeming, he enthusastically agreed.

 

Thanx for any additional wisdom, and keep up your good advice work. I really appreciate it!

R Neil Haugen
R Neil Haugen
Legend
December 3, 2021

Good questions.

 

First, whether you're working an HLG timeline or a Rec.709 timeline, all clips must have correct CM settiings in the bin. Period.

 

So an HLG clip on a Rec.709 sequence must be 'overriden' to Rec.709 with the clip properties in the bin.

 

Which is a ROYAL pain at the moment, as ... what if you want both a Rec.709 and HLG export?

 

Well ... say you stare with the clip overriden to Rec.709 for a Rec.709 sequence. Get everything looking good.

 

Now ... you have to create  DIFFERENT sequence for the HLG, and while working there, all clips need their CM set for HLG.

 

To export ... you have to make sure all the Rec.709 sequence clips are set to Rec.709, export.

 

Then ... reset everything to HLG, export the HLG sequence.

 

Supposedly you shouldn't need to do this, but from what I'm seeing "here" and testing myself, it is NOT handling CM correctly unless the clip and sequence and export all match perfectly.

 

You cannot currently take an HLG sequence and export to Rec.709 with any confidence.

 

So ... there are some problems to constantly test.

 

Bringing any clip whether it's been modded in CM to a different space, or simply say a Rec.709 clip on a Rec.709 sequence ... is going to need some adjustment. That's a given. There isn't any perfect camera through post exposure/contrast/saturation option out there.

 

Neil

Everyone's mileage always varies ...
Ann Bens
Community Expert
Ann BensCommunity Expert
Community Expert
December 2, 2021

Might want to read this pdf.

 

troth_nee_adobe
troth_nee_adobeAuthor
Inspiring
December 3, 2021

Thanx much for this doc Ann. I had seen the 2020 version, via Larry Jordan's site, but it's good to see this updated version too. For future reference, is this a white paper that Adobe has distributed apart from the PP user documentation?  If there's someplace I can bookmark for future white papers, I'd love to do that. The closest user doc I can find seems to be the "HDR for Broadcasters" page.

 

I'll comb through this paper in detail to make sure I'm following its recommendations, and in particular, it answers some questions I also had about the recommended AE HDR workflow, so that's great too.

 

The paper seems to confirm much of what I found in my experimentation, but a key point I'm still confused about is the current support for iPhone HEVC HDR footage, which is Rec.2100 HLG. This is the key para:

 

"Premiere Pro allows you to work natively in Rec. 2100 HLG and Rec. 2100 PQ thanks to a new sequence working color space option. Apple ProRes and Sony XAVC Intra are both fully color managed and GPU accelerated throughout the HDR pipeline. With the new native HDR workflow you can import, edit, color grade, and export HDR content in Premiere Pro. The first implementation of this workflow addresses the needs of professional broadcasters and in upcoming releases, we plan to add support for other HDR working spaces and additional format support, like H.264, and HEVC."

 

This implies to me that Apple's HEVC/Rec.2100 HLG content might not work at all, but that's not what I found. As I mentioned, I was able to use it in my simple (i.e. no significant color editing) workflow, and the AME-exported result, uploaded to Vimeo, appeared the same on Vimeo as the original footage resident on the same iPhone.

 

So I wonder if this para really means that for now only ProRes and XAVC Intra are GPU accelerated, and that such acceleration will be addded for other codecs, like HEVC, eventually. That would jibe with my observation that my AME export settings to achieve HEVC HLG required software encoding (which is of course slower).

 

This might ultimately all be acedemic for many users, of course, since any quality HDR color editing/grading still requires such expensive additional hardware. But what about the use case where you want to use iPhone footage mostly "as is" color-wise, and just preserve it's HDR goodness in a project that includes SDR footage too? In that case, the working space could be HLG, SDR footage would automatically work too (per the paper), and the HLG output would be optimized for those environments that could take advantage of it.

 

Separately, the paper's discussion of input LUTs was interesting too, and also aligned with what I suspected would be very useful. An example is SDR sequences that want to include HDR footage too. I'm kind of surprised I haven't found anyone marketing these yet (beyond the BBC ones mentioned for broadcasters). If anyone is aware of these, I'd be interested in learning more abou them, Also, I happen to be a customer of previous LUTs from Paul Leeming, and he recently told me he's working on this very problem - iPhone-specific LUTs for color space conversion - but he doesn't have an ETA yet. So maybe it's just a hard problem, and/or 3rd parties need time to catch up to Adobe and Apple advances...

 

So I'm also wondering what Adobe's position is on this workflow of just supporting iPhone HLG footage for SDR destinations. Without input LUTs as a good starting point, it seems like there's a fair amount of Lumetri editing required to make HLG look good in 709. I can't be the only one wanting to use iPhone HLG footage in PP, and it's also possible I'm still missing something basic that helps optimize this process.

 

Thanx again for the paper reference, and any additional comments this mark spark.

Ann Bens
Community Expert
Ann BensCommunity Expert
Community Expert
December 3, 2021

The doc will soon be updated for 2022.

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices