DNxHR 444 10 and 12 bit Support

Report · Jul 14, 2022

Premiere Pro has major issues with DNxHR 444. Regardless, if it's the 10 bit or the 12 bit flavor and if it's wrapped in MOV or MXF. I won't even get into the whole Full/Legal debate, as that is another topic, but you can take a look at this thread, it lays out very detailed explanations of that issue:

https://community.adobe.com/t5/premiere-pro-discussions/dnxhr-444-doesn-t-work-properly-in-premiere-...

As a colorist, this presents a challenge, since for a lot of us who do not work on a Mac, exporting ProRes from Resolve is not an option and not every production has the capacity of handling uncompressed files. Be they DPX/TIFF sequences or even uncompressed MOV wrapped codecs.

To give you an example, I just had a project shot on the Sony Venice in 6k, client wanted to do a roundtrip workflow where I send them the graded shots in 6k for them to online and deliver. I'm sure you can see the problem of trying to render and playback 6k uncompressed media, especially in an image sequence format, for most it's unmanageable.

Presently, Premire Pro just straight up is not reading DNxHR 4444, but it used to. I relied on it to substitute ProRes 4444 and now I cannot. I am that it is not officially supported as it's not listed on the supported file formats page - https://helpx.adobe.com/premiere-pro/using/supported-file-formats.html ;however, I find it unacceptable that such a major and established codec is incompatible with your software.

I urge the Premiere Pro development team to take a look at this issue and fix it as soon as possible, as there is a massive need from countless people who rely on it every day to be able to deliver to premiere users.

The image below showcases that even the properties' interpretation of different DNxHR 4444 favors is incorrect:

MXF wrapped 10 & 12 bit files are both seen as 10bit
MOV wrapped 10 & 12 bit files ar both seen as 12 bit.

Below are the correct interpretations by the software Media Info:

This Problem only compounds when trying to deliver files with Alpha to premiere from Resolve on Windows. Again, most productions can't handle 6k DPX/TIFF sequences and DNxHR with Alpha is not supported and does not open in Premiere Pro.

Report · Jul 14, 2022

@josemariaabreusantos wrote:

I urge the Premiere Pro development team to take a look at this issue and fix it as soon as possible, as there is a massive need from countless people who rely on it every day to be able to deliver to premiere users.

Premiere Pro User Voice

Report · Jul 14, 2022

Yea, this is still an issue. Unfortunately ... and maybe time for @Francis-Crossman to pop in about this.

Although I've got a slug of DNxHR presets, RGB, HQX and such available here on my PC ...

But it's not accepting the 4444 on yours? I guess I need to test that on my rig later today.

Neil

Report · Jul 14, 2022

Well....

Premiere seems fine with Resolve 12- bit RGB files, unless you have an alpha channel attached ... then you get the dreaded frame-excursion warning and a black/void screen for the clip.

Neil

Report · Jul 14, 2022

Are you wrapping them in MOV or MFX?

For me, it's erratic at best:

I had to render 6k Source Res Files for a roundtrip workflow, and those weren't being read no matter the combination I tried. I get the same error you get with alpha; however, I don't have alpha.

But 1080p MOV wrapped 444 was working.

Report · Jul 14, 2022

These were mxf ... and no-alpha, they're fine.

Include an alpha from Resolve ... no go.

And I just posted on the Premiere Beta forum, which is followed by some of the dev staffers also.

Neil

Report · Mar 06, 2023

I second that this is huge issue as my team and I just ran into this issue with a big client. DNxHR looked correct in Premiere when viewing the source files in the viewer, but in the Program viewer it looked washed out and completly not as creatily intended. Checked sequence settings and even made a new sequence with the colored DNxHR footage and the same problem persisted. On export, it looked yet another way and we needed to so a patch job to try and get it close but I resent the fact we even had to do that considering Premiere Pro considers itself a professional software.

Report · Mar 06, 2023

@Fergus Hammond ... another post on this issue, and please advise?

Neil

Report · Mar 06, 2023

Apology for the spelling or gramatical errors. Let me know if clarification is needed. Thanks.

Report · Jan 03, 2024

Hi Jack,

the Problem is that Premiere & AfterEffects understand DNxHR 444 as a Fullrange Codec,

but DNxHR 444 is a legal Range Codec.

@ Neil, Fergus now this Problem, he say it will be stop to the midel of 2023. I test it in September 2023 a day for the IBC, and the problem was not finish.

Report · Jan 03, 2024

DNx in 444 can be either, from my memory of reading the 'white paper' from Avid on it.

And there's no options in Premiere to tell Premiere how to recognize or adapt to the file as-is. To either set legal/full or check off on 10 or 12 bit.

That ... is still a big problem.

@Fergus H ...?

Report · Jan 04, 2024

Hey Neil,

No, it can't be both!
444 is not RGB!
It is so that you have information for each pixel at 444, so that you can convert to RGB without loss (chroma subsampling), as AVID points out. But AVID doesn't say that the codec is either RGB or 444.

RGB is full range.
RGB is always full range!

DNxHR444 is not RGB but YCbCr.

AVID developed the legal range codec and this is how it works in all other tools except ADOBE.
The two of us have discussed the topic again and again in an ADOBE forum. Until ADOBE fixes the error, I will point out that ADOBE is interpreting it incorrectly.

Finally, back to your theory, if DNxHR 444 could also be RGB, and therefore full-range, a different name would certainly have been found, and then you could certainly recognize it from the metadata and thus eliminate the ADOBE errors.

Have a nice day

C.

Report · Jan 04, 2024

Yes, we've been through this, and in the main, I agree with you that Adobe's color people aren't handling this format as most users coming from Avid would expect.

That said ... having also read Avid's white paper on the codec ... they specifically state that the 444 can contain either YUV or RGB data. So they do "allow" the choice.

I've argued with certain Adobe staffers that if they insist on treating the 444 like this, they should at least allow users the choice of how it's interpreted. Sadly, to no avail.

Report · Jan 05, 2024

Sorry Neil,

I don't see the wording on the AVID page,
that you can either work with the DNxHR 444 codec in YCbCr or RGB.
The only way I can understand AVID's wording is that you can switch between YCbCr and RGB with the codec without any color loss.
But this does not refer to the fact that both take place with the DNxHR 444.
That's how I understand AVID, and that's how the AVID formulation was on the IBC at the AVID stand. That, for example, there is no color loss when converting from DNxHR 444 to DPX and back.
The fact that you always have to pay attention to setting the fullrange and legalrange parts correctly is an additional point.

DNxHR 444 is a legal range codec.
ADOBE knows this too.
You also know that this is wrong.
We were once promised that this would be resolved by mid-2023.
But once again these were just empty words.

Neil, I agree with you, a small step forward would be the ability to edit the footage for Full. and legal range.
But apparently 🙂 cannot buy this function on the market,
You have to adjust them yourself, which is obviously too strenuous.

ADOBE charges a fair amount of rent from us users every year,
It's probably not too much to ask for the problem to be fixed after many years.

I think it will sort itself out, at least in EUROPE, in the next two years. Of the 40x ADOBE licenses in the Premiere / After Effects area in 2022, we will be at 20x in 2024 and around 10x in 2025. The artists I look after switch to another tool inflationary.
First the young people.
The older artists since summer 2023.

Best Greetings

C.

Report · Jan 05, 2024

I had a LONG email exchange with an Adobe color scientist over this a few years back. He argued that (if I can recall correctly) 4444 in 12 bit by 'standards' is always RGB and therefore Full, I think it was. And should never be "mis-used" as YUV.

So in the main, I believe your reading is correct, as in the way the rest of the world sees this. But ... that key person is ... not ... seeing it that way.

And we're still stuck in this mess.

Report · Jan 08, 2024

4444 in 12 bit by 'standards' is always RGB and therefore Full, I think it was. And should never be "mis-used" as YUV.

Neil, I believe that someone from ADOBE told you that.
But it is technically incorrect and not based on technical facts.

The thing is, ADOBE is the only company that misinterprets DNxHR 444 as fullrange. I find it very unprofessional to just say that's how it is!

Then you should explain in technical detail why YUV suddenly becomes RGB at 12 bits.
Also you have your error with 10 bit DNxHR 444 too.

Without a technically sound statement, it's just blah blah blah.

We also spoke to ADOBE people who said they will fix your bug by mid-2023.

Greetings

C.

Report · Jan 08, 2024

The same thing came up on the BM forum yesterday, btw. With one of the regulars noting that it can officially be set to either (which is a right pain to me by itself) and some things do one way, others the other, and ... you have to always test the flipping codec in what you're sending it to.

I've seen a number of non-Adobe folks, people in post and compositing, saying that 12 bit should be assumed to be RGB, so it isn't just "Adobe". It also ... clearly ... isn't universal.

I don't defend anything here, just explain. And yea, it's a mess. Not quite as bad as Apple's weird use of the old Rec.709 camera transform function as a display function, but ... still a mess.

Report · Jan 10, 2024

Dear Niel,

I wonder why some people mix Bit, RGB and YUV.
Is this an inner desire?
You are welcome to discuss and “opinion”, but then you should give up giving technical reasons/explanations.

What does Bit have to do with YUV or RGB?
What does bit have to do with full range or legal range?

I can save a black and white image in 1Bit, 8Bit, 16Bit, ...
completely detached from color.
Why should 10 or 12 bit = RGB
Or 8Bit = YUV

444 stands for YUV or YCbCr!
And in the AVID World YCbCr is legal.

If you want to create a workflow across borders of countries, tools, companies and artists,
In my opinion, something like this has to be able to function perfectly and in a structured manner.
But that doesn't happen when you discuss technologies emotionally. As far as DNxHR 444 is concerned, it is long overdue that ADOBE does not refuse to provide a clean workflow here!

Just because you think something looks nicer can't be a certificate for a codec.

Personally, I would be happy if there was a newer post-production codec that was defined (certified) full-range in 12bit
and runs on all platforms Linux, MAC and Windows from all manufacturers.

Niel, have a nice evening!

Greetings

C.

Report · Jan 10, 2024

You keep thinking an explanation is a defense. No clue why you do that. To me, that's just odd.

In Avid's old detailed paperwork (I downloaded and read the many page thing years ago) yes, legal is the norm in Avid. But specifically, full is allowed. Especially in compositing workflows.

The Adobe color scientist says that should, by general use norms, be Full as I recall. Because that's what X media type is supposed to be in general. And looking it up, "in general" he has a defendable point. Which may not be the best choice here in this specific situation. Ahem.

Avid and Resolve both allow the user to change the "read" of the file. For how their workflow needs to work.

The Premiere devs haven't. And should have a LONG time ago.

Period.