10-bit HEVC to DCP workflow

[russh54641493]

Hi all - I have an extremely specific workflow question, but I'm hoping someone might be able to help me unravel a couple things.

I work for a cinema chain, and my end deliverables are DCPs created using the CuteDCP plug-in in Premiere. My question is about the best workflow to preserve color space when working with 10-bit source material. With increasing frequency, I'm editing footage either shot on a Sony FS7 in the XAVC-I codec at 10-bit 4:2:2, or material from consumer UHD BluRays, transmuxed to 10-bit HEVC mp4's at 4:2:0, which CC2020 plays quite nicely with.

One of my biggest limitations is that we don't have 10-bit monitoring available (believe me, it's on my wish list). So there's a decent amount of educated guessing going on. With FS7 material, I usually apply a LUT to make the slog3 footage look good in an sRGB color space, and call it a day. What I see on the big screen when DCPs (with their XYZ color space) play back through the projector usually looks pretty 1:1 from what I see on my 8-bit monitor. My guess is I'm sacrificing a little chroma and luma depth using this workflow? Although in theory Premiere should be preserving that depth when I drop the footage into a timeline? It's hard to say how much is power of suggestion.

Of course with HEVC material from consumer discs, I only want to transpose the already-color-corrected material as accurately and richly as possible from REC2020 to the DCPs' destination XYZ color space. Naturally with my 8-bit monitor the gamma is transposed very inaccurately, but this is to be expected and I can throw a temporary saturation/contrast effect on top of it for the sake of my eyes and brain as I work. However, if I leave the material untouched, should CuteDCP's color conversion not leave the bit depth intact as it converts to XYZ? (I realize CuteDCP is a very niche product and maybe I should be asking them). I'll definitely do some tests ASAP, but does anyone have any knowledge about how color spaces are preserved and converted through a workflow like this? Would the "maximum bit depth" check box under sequence settings have any impact? I greatly appreciate any help folks could offer.

[chrisw44157881]

the old HD Bluray gamma is 2.4 but premiere may be incorrectly interpreting it as gamma 2.2 by default, but tricking you as the color management conversion is temporarily showing gamma 2.4 in the default viewer. Premiere doesn't convert luma by default so you will need to test with colorbars or use a lut to convert.

CuteDCP can convert from 2.2 or 2.4, but obviously that is impractical if you haven't converted your whole timeline to the same gamma level for overall luma conversion. (note: premiere is not color managed)

DCP's are 12 bit, but HD bluray is only 8 bit. UHD is 10 bit.

max bit depth is for higher than 8 bit which may be useful if you have footage both above 8 bit and are exporting above 8 bit.

To make it even more confusing, UHD Bluray content can be distributed in either the REC.709 or REC.2020 color gamuts. Also, if using rec. 2020, then your gamma could be SMPTE ST2084.

Premiere can ingest rec. 2020 material depending on if its interpreted that way (which can be tricky, as afaik, there's only a handful of codecs it will natively support in this way)

Here is the readme of what is HDR supported in premiere
https://community.adobe.com/t5/premiere-pro/faq-setting-up-for-hdr-work-in-premiere-2019/td-p/106464...

So, I think the main problem will be if premiere is interpreting the right gamma, and if CuteDCP even supports ST. 2084 UHD bluray to XYZ gamma 2.6.(i did not see that option.)

Do a test to see if you can even ingest and interpret ST 2084 footage correctly. If you don't have all the hardware listed in that thread, then you won't even be able to view the HDR video.

But like you said, you may end up having no choice but to eyeball it off the projector since ACES color management has not been implemented yet and CuteDCP appears to be missing that conversion option. Also, Premiere's internal wraptor DCP converter accepts gamma 2.2 as default, so that's also a problem. You could use openDCP or something to finalize it, but yea, its a mess.

[R Neil Haugen]

You have to see clearly what is the actual processing  "chain". Viewing and internal processing and export chains are three different things. What you view over an 8-bit monitor link isn't what necessarily is happening in either the processing chain or the export chain.

I'll deal with one incorrect comment first ... "Premiere isn't color managed." ... Um ... no, it is in fact very tightly color managed ...  but in a way that is different than most other apps. It was in many ways a perfect design for a few years back. The internal processes were designed to completely abide by the One Standard that ruled all media for deliverables, which was ... and still over 90% is ... Rec.709. Bit depth within Rec.709 is a factor of the standards of the format and codec chosen to carry the media. NOT Rec.709 itself.

So ... Premiere takes the media that comes in as it is, period. Using the standards that are set for that specific format/codec combination. Internally, all processing is 32-bit float, totally agnostic of an individual clip's bit depth. Unless of course, one chooses to use any of the older effects that are coded in 8 bit math. Those are all clearly marked in the Effects panel. DO NOT USE any effect that deals with color that doesn't have the 32-bit lego block. Just ... don't.

IF you have say 12-bit media coming in, and you apply wise choices to your effects within Premiere, and you export to a high-bit-depth format/codec combination, you get 12 bit media out, full color depth and purity. And this has nothing to do with the gamma of the viewing display device. Or it's bit-depth.

There is a TON of media edited through Premiere daily that is exported for work in professional theatrical release, in the the higher bit-depth and deeper gamma that is called for in either professional P3 color ... arenas. I'm including a graph of the Wiki for DCI-P3, covering the three P3 pro spaces ... and Apples unique "Display P3".

Note that bit-depth isn't even discussed here. It's ... not relevant to the color space issues. (Other than you really need the higher depth data to really support that many different color data points of course. That's a "carrier" issue, though.)

Look through either that Wiki or the articles on say the Lightspace.com site. The two theatrical release versions both have a gamma of 2.6, and were set for a max brightness of around 48 cdm2/Nits. Material edited through Premiere and properly exported then worked through a good colorist's setup could be converted into those color spaces/gamma/brightness ranges without trouble. Has been, and is today.

Premiere doesn't throw away your bits ... it just displays them in a Rec.709 broadcast standard fashion. Be respectful of your bits within Premiere. Export to the higher bit-depth format/codec combinations that Premiere has available, and do so with either a proper GPU or if not, setting the "Max Bit Depth" option on export. IF you have proper media coming in, your GPU is up to Premeire's needs, and you export to a high-bit-depth format/codec, then all your bits go out that back side just fine. And of course, can be re-shaped into the appropriate delivery space by whatever app does the final work.

If you're not delivering HDR (and realistically there's not that much pro HDR delivery done yet) then Premirere's internal monitors actually are not an issue, designed as they are for Rec.709/100 nits screens with gamma of 2.4. HDR deliverables directly out of Premiere ... that's harder. You have to have (as of this date still) the exact AJA outboard devices between your media and your monitors to see HDR media correctly while working within Premiere. IF you have the right kit, you can actually work quite properly with HDR media. Premiere is currently capable of working with HDR media at higher brightness levels than any monitors made can show. It's the monitor situation that is the limiter ... the viewing situation, not the export situation.

But then, if you're delivering for Netflix, you've got an over-$30,000 monitor you're using anyway.

Going forward, the engineers are telling everyone at NAB and MAX and other events they are working on the user-controllable settings to give Premiere users the options to change the color management that other apps like AfterEffects and Resolve and Avid have. Can't be too soon, and yea, I've been arguing for that with them for years.

But again ... you have to break down the separate processing chains ... input, processing, display and export. Premiere's clunky "issue" is one of display really. It's the one area Premiere isn't currently working with ... unless you've got one of the two nearly-$2,000 AJA devices to send your display an HDR image. Of course, I don't know of an approved HDR monitor for color work under $30,000 or thereabouts at this time.

Which is why ... most colorists do not have a setup to actually fully deliver HDR in-house to say Netflix/DolbyVision standards. When they need to deliver to those standards, they have to rent the kit or suite to do the work. And understand most any pro colorist has monitors already that cost over $5,000, and the still aren't up to specs to work HDR media.

Neil

[chrisw44157881]

Steve Hoeg, one of the Premiere Pro engineers, provided some examples of how Premiere Pro will handle color precision in different scenarios:

1. A DV file with a blur and a color corrector exported to DV without the max bit depth flag. We will import the 8-bit DV file, apply the blur to get an 8-bit frame, apply the color corrector to the 8-bit frame to get another 8-bit frame, then write DV at 8-bit.

2. A DV file with a blur and a color corrector exported to DV with the max bit depth flag. We will import the 8-bit DV file, apply the blur to get an 32-bit frame, apply the color corrector to the 32-bit frame to get another 32-bit frame, then write DV at 8-bit. The color corrector working on the 32-bit blurred frame will be higher quality then the previous example.

3. A DV file with a blur and a color corrector exported to DPX with the max bit depth flag. We will import the 8-bit DV file, apply the blur to get an 32-bit frame, apply the color corrector to the 32-bit frame to get another 32-bit frame, then write DPX at 10-bit. This will be still higher quality because the final output format supports greater precision.

4. A DPX file with a blur and a color corrector exported to DPX without the max bit depth flag. We will clamp 10-bit DPX file to 8-bits, apply the blur to get an 8-bit frame, apply the color corrector to the 8-bit frame to get another 8-bit frame, then write 10-bit DPX from 8-bit data.

5. A DPX file with a blur and a color corrector exported to DPX with the max bit depth flag. We will import the 10-bit DPX file, apply the blur to get an 32-bit frame, apply the color corrector to the 32-bit frame to get another 32-bit frame, then write DPX at 10-bit. This will retain full precision through the whole pipeline.

6. A title with a gradient and a blur on a 8-bit monitor. This will display in 8-bit, may show banding.

7. A title with a gradient and a blur on a 10-bit monitor (with hardware acceleration enabled.) This will render the blur in 32-bit, then display at 10-bit. The gradient should be smooth.

From my understanding. even 32bpc effects can be clipped if max bit depth is turned off as above.

Although if no effects are used, premiere may pass things through? (can't remember off the top of my head)

i don't see how something can be 'called' color managed when you can't actually manage the color gamut or gamma, but that's just my opinion.

[R Neil Haugen]

Steve put that out some time back, and I've had the ... joy? ... of going through that with both then-color engineer (now co-Product manger for Premiere) Francis Crossman and senior Adobe scientist Lars Brog. Along with Steve actually.

The issue is the statements in 4) and 5), isn't it?

That's where I was going to Steve, Francis, and Lars for clarification. Over ... and over. And for the article/tutorial I did for MixingLight.com ... and before that was published, both colorists Patrick Inhofer and Robbie Carman of MixingLight had a few bazillion questions for Francis and Lars. They had to be satisfied before publication. That process covered hours of phone calls, computer screen-shares, and in-person time between myself and Adobe color staffers. Then when Pat and Robbie got into the email chain, months and months of emails.

Where it seemed to come down was that use of the blur in Steves scenaros ... oddly, that was the complicating factor it seemed. Yet every scenario, Steve chose to "apply" a blur. I'm not sure why. Without the blur, or any intrinsicly 8-bit effect applied to a clip, Premiere's internal processing chain simply runs by converting input data to 32 bit float. And on "exit", goes directly from 32 bit float to the depth of the chosen export media.

Where the "Max bit depth" option/flag comes into play is definitely if the GPU isn't the processing unit for color corrections/modifications applied within Premiere. If the computer's CPU does the processing, it will be 8 bit unless the "Max Bit Depth" option is selected.

Francis could not find a situation where he imported 10 bit or 12 bit media, and did not get proper bit depth out, if the internal processing decisions were made properly. As soon as any non-32-bit color effect was applied, naturally, it went down the rabbit hole to 8 bit immediately.

From talking over this with a lot of people concerned with their color bits, I think there are a few effects that are not intrinsically recognized as a "color" effect that can affect processing chain bit depth. Which those are, I don't know. I know a number of colorists/editors who have never had an issue with bit dept after figuring out Premiere's arcanities. And a few who've had no issues ... except ... for a project or two that had a nasty surprise for them.

I would appreciate (and have asked) for the Adobe color folks to actually test each effect by itself. "Do you know how many hours that would take?" ... Um, yea, got a really good idea. A LOT. And budgeted time is always below needs.

But I think we users need to know this for certain.

Neil

[R Neil Haugen]

When I was thinking back through this this morning, I realized one deficiency in my own approach ... and that of some of the others I mentioned in my last post.

I'm assuming color work is done to every clip, which would invoke the GPU and therefore render the Max Bit Depth option non-necessary. Which ... seems obvious to me.

But I missed totally that for many editors, color is not part of their particular workflow. For that situation, you would definitely need to have the Max Bit Depth button on.

And for clarity ... do I think that should be needed? No. I don't know why they would auto-drop a high bit-depth file to 8 bit for any reason other than there is an 8 bit effect used. But clearly it made sense maybe ten years ago to someone. It's something that I hope changes. Soon.

Neil

[chrisw44157881]

thx for your post. it is helpful. It seems adobe does everything backwards!

wish list. 

1. Un-backwards everything.

for the original poster, get your technical conversion luts ready, cuz you'r gonna need about 40 of 'em.

haha!

[russh54641493]

Sounds like I have a lot to learn about technical conversion LUTs. Any advice generally speaking?

[R Neil Haugen]

Russh,

Tech conversion LUTs are an interesting discussion. Among the colorists I know, and for prepping images for working in color, there's basically three "schools" ...

• one uses the tech LUTs given out by manufacturers religiously ...
• one takes a manufacturer's LUT, drops it on a clip, and tries to emulate it with their grading controls. And after, if they want to apply one for that cam, they "roll their own" ...
• and the third school avoids them entirely, and simply uses their grading apps regular or Log controls to handle this task.

I tend to be in the middle group, occasionally the third.

As to say exporting ... I export always in stock standard format/codec specs, which for most things from Premiere is Rec.709/gamma-2.4/100-nits. I don't try and 'cheat' towards any one outlier display form, as ... why? Any attempt to look better on one display format will look worse on every other.

Yea, I know that Apple uses a really unfortunate set of decisions for both the Color Sync utility that sets the display spaces for various media and the Display-P3 color "space" they created. But in my experience, those are not nearly uniform across Apple devices, go both more and less saturated and more and less contrasty ... so there's no way to  outguess the Mac systems.

By keeping my exports straight down the standard, it does mean that they should appear similar to any other professionally produced media displayed on any one system. That's all I ... or anyone ... can do.

Neil