DNXHR 444 doesn't work properly in Premiere! Shame.

[nightjar84]

Hi there,

Since Premiere still doesn't have a proper RAW decoder, you must go over Resolve with Cinema DNGs. I exported the DNGs to DNXHR 444 and imported the files  into Premiere: The footage looks washed out! I tested out various scenarios (incl. .mxf) and its definitely a Premiere problem!! The footage looks correct Resolve.

Is there a way to fix this? If not, Adobe should really address this!! Other DNX formats work fine (e.g. HQX, LB etc.).

Cheers

[R Neil Haugen]

Resolve has some different settings for internally handling/using color spaces & settings. Occasionally some of the ones people use that seem to work with Resolve do not work with PrPro. That might be an issue (small probability, but there).

Neil

[Waldorf & Statler]

Sorry Neil, your Answer is not correct. The Problem is, that ADOBE have a wrong interpretation for Fullrange and Legalrange at DNxHR 444. Your Answer is from 2017. ADOBE have it not fixed to 12/2019.

[Jim_Simon]

The Cineform exports from Resolve work fine in Adobe software.

[Waldorf & Statler]

The Problem is not Resolve!

The Problem is a wrong interpretation from legal and full range in ADOBE Premiere and AfterEffects.

DNxHR 444 is a legal Range Codec, but the devoloper from ADOBE have a problem to understand this.

We have been reporting this problem for over 2 years, but so far the problem has not been resolved.

[R Neil Haugen]

Waldorf & etc. ...

DNxHR 444 is an RGB format/codec, which typically means full range. DNxHQ on the other hand is in YUV.

I've seen numerous posts on other non-Adobe forums on how to get proper DNxHR 444 out of Resolve, which includes manually setting it to Full range in Resolve. This way the files from Resolve go into both Premiere and Avid correctly without needing futzing in the 'receiving' app. For it seems most Resolve users, the correct export has been done since I think about 15.1 without needing to change from 'Auto' levels, but some still occasionally report troubles.

So ... there may be some diffence of opinion on this, but ... offhand, I don't know of any RGB codec that is legal range.

There are Lumetri presets that ship with Premiere for conversion from full to legal and legal to full, of course.

Neil

[Waldorf & Statler]

High Neil,

AVID call the Codec DNxHR 444 and not RGB! Correct?

444 is an YUV CODEC! The conversion between 444 and RGB can be pixel by pixel,

so some people say or mean 444 and RGB are the same, but that ist not correct.

I think Blackmagic now this litel different, so you get at automatik the correct legal range version!

Greetings

Waldorf

[R Neil Haugen]

I was just looking at an Avid doc that stated DNxHR 444 is RGB, unlike the HQX which is YUV. Here's a chart from Avid ... showing RGB  Chroma Subsampling for DNxHR 444:

I've just been through several forums from Lowepost to Reddit and Avid ... the accepted tale is that DNxHR 444, as an equal 4:4:4 codec, is full RGB, unlike the rest of the DNxHR codecs, all 4:2:2, and which are YUV.

So I'm fairly comfortable with saying Avid apparently considers this an RGB codec.

Neil

[R Neil Haugen]

And here's my latest comment from the other thread on this ...

This sparked a fun set of responses on a private Slack channel.

Two major colorists, "A" works a lot with the BlackMagic team and teaches Resolve for BM at things like NAB, including demoing both the full $30G panel and the editing keyboard full-time in the BM booth. He was part of the on-screen team for DolbyVision's in-house produced series on working in Dolbyvision HDR.

The other, "B", is another major colorist, also noted as A for his technical knowledge of the media and the craft. Both have done their share of features, docs, shorts, commercials, and episodic work.

A says that well, it can be argured either way technically, but Avid currently treats it like legal range in Avid, so ... that's probably how everyone should treat it.

B came right back saying that is just WRONG. As a general rule, if the codec is full RGB then you don't need to have over/under values to account for gamut/encoding errors. This technically should be full range, and Avid um ... screwed up.

A says well again it could be either, BM gave up and decided to go with Avid, but Premiere doesn't have a way to allow the user to over-ride their view of codec standards.

B comes back with ... its' wrong, fella, just admit it's wrong ...

A says ok, Avid is wrong about a lot of things, but hey, they made this format ...

B says "Thank you for admitting it. Your honor, I rest my case."

I've personally discussed this in the past with Lars Borg, chief color scientist for the Adobe video apps. His take is purely technical: as a full RGB codec, by all that is right and Holy in video formats and codecs, and like all other full RGB codecs, DNxHR 444 should be treated as full range. And further, he also made the same statement as B's comment, that as a non-chroma subsampled codec it doesn't need protection from overs/unders and rounding, which is the only reason to continue the whole full/legal range mess to begin with.

Even though I'm not an Adobe staffer, I do considerLars ...  a bit above my pay-grade. As well I do with the two colorists mentioned above.

Yea, I would personally prefer we had the option in Premiere to 'set' full/legal as in Resolve, but currently we don't. They do ship the full->legal and legal-> full Lumetri presets which if you drop onto the clips in the bin, it will appear on them as a Master clip effect. This will accomplish that for you the same as if you had a switch.

They have options for 8, 10, and 12 bits each way. The use a LUT in the Basic tab of that Lumetri effect, so if the clip ... clips or crushes ... create another Lumetri effect, put it above the other one in the Master tab, and trim the clip while viewing the scopes and monitor for best blacks/whites.

Neil

[Waldorf & Statler]

I know the table.
But your interpretation is not there,
as you understand it.
There is nothing legal or full in the table!
I think we all agree that the codec only
4: 4: 4
or
RGB
can be, and not both at the same time.
I mean the table is not well done.
I think the high quality of the codec should be put out and the lossless Croma Subsampling at 4: 4: 4 and RGB should be pointed out.
But if this codec were RGB,
AVID would certainly have called him "DNxHR RGB".

Not only do I think that the DNxHR 444 codec in the AVID works as a legal codec, but this information can also be found in the forum and I also got it from AVID at the IBC.
I hope you agree with me that it is not about what a colorist has to twist so that it works in ADOBE.
If you use the footage in different tools, it has to work properly.

Many thanks
Waldorf

[R Neil Haugen]

If you use the footage in different tools, it has to work properly.

In all the checking I've done, the DNxHR444 media I've worked with, it's showing as RGB in MediaInfo and anywhere online I've checked. Avid's own chart shows it clearly as RGB, which falls in line with being a 4:4:4 clip, it doesn't have conversion to YUV values in sub-sampling.

It's RGB. Period.

Now ... all other RGB codecs are full-range. It's kinda the point, actually.

So there is a solid technical argument that DNxHR 444 should be treated as all other RGB codecs. This follows established professional behavior.

On the practical side, Avid for some reason decided to 'treat' this as a default behavior in their own editing app as a legal range codec. So working in Avid, it's 'seen' as legal/16-235.

BlackMagic used to treat the codec as a proper RGB full-range codec, but finally gave up and set the default to legal simply to go along with Avid users for practical reasons even though it's "wrong" from a purely technical sense.

At this point, I would personally go with the Avid usage myself, but they don't let me say what's what, do they?

The chief Adobe color scientist Lars Borg is comfortable with his argument technically. And technically, I do think (as do many  of the tech-savvy colorists I know) he is correct. But being technically correct is not always the practical, sensible or most useful thing.

Practically ... I think they should give it up, go with the flow ... and set the default as legal. Not because it's "right", but because it's how way too many users expect to see it used.

Neil

[Waldorf & Statler]

Because Lars Borg has a different interpretation of 4: 4: 4,
companies that use AVID and ADOBE have to export footage twice.
1x for AVID
1x for ADOBE

I'm sorry I can't give up.
In my view, Blackmagic understood what is 4: 4: 4 and what is RGB and corrected it accordingly. I don't know Lars Borg's official arguments for the YUV Codec DNxHR 444.

In my opinion, he made two mistakes with ADOBE.
1. not properly dealing with the codec
2. Is it overdue for many many years that the ADOBE products in the case that Lars Borg is YUV 444 for his sake full range,
incorporates an interpretation for codecs into its software that correctly interprets how BM does it.
Then you could argue that you can also work with the wrong range in ADOBE.

It is true that all RGB codecs are full range,
not now, but always have been and always will be.

But that it is a new fashion division, the YUV is now full range, because some find it cool is not correct.
Lars is also welcome to come over for a beer.

Best wishes
Waldorf

[Waldorf & Statler]

PS: @Lars Autodesk Flame interpritate in the standart DNxHR 444 als legal, but you can cange in the Flame between Full and legal, looks like DaVinci Resolve.

[Waldorf & Statler]

Dear Neil,

I always enjoy exchanging ideas with you.

Basically, I would like to clarify Waldorf & Statler's position on Fullrange here in the forum.
We would have welcomed it when introducing HD TV
Legal range and interlace would have been abolished.
Unfortunately, this did not happen, as a service provider in the TV business it is important that you can rely on defined standards here!

At DNxHR 444 you prefer Neil and we have different opinions, ok, let's leave that in the room until ADOBE Lars has publicly commented on the topic.

If, according to Lars, DNxHR 444 is RGB and therefore full-range, what is ProRes 444?

In my opinion, ProRes from grading tools used to be correct as a full range or auto, e.g. reproduced in After Effects. After a test today, I have to say that this is not the case.
Here only an export with legal range in AE is correctly reproduced.

It would be super nice if Lars explains why 2 popular 444 codecs are given incorrectly in After Effects and certainly also in Premiere.

Have a nice evening
Charles Waldorf

[R Neil Haugen]

Hey there Waldorf, nice to 'see' you again!

Looking up the Apple pdf, they do say their 4444 codecs can be used either for RGB or Yuv.

And knowing how Mr. Borg looks at this, I would have guesstimated he'd go with RGB. But I see from some comments in the AE forum, Ae may be running YUV with this? I've not worked with this in Ae.

Now, inconsistency would be nothing new ... sigh. So, you're getting a legal range from ProRes 4444 in Ae? Sigh.

Neil

[Waldorf & Statler]

Hey Neil,

When they look up the Apple PDF, they say that their 4444 codecs can be used for either RGB or Yuv.
That would be ok for me!
Then ADOBE would have to interpret it correctly either way.

It's a little strange that Lars Borg has an AVID codec
absolutely wants to interpret RGB full range, although the designer of the codec sees it differently.

For an Apple Codec, where it could go through full range,
but he only uses legal range although the designer says both are ok.
Strange. Politics?

This point also leads to mistakes that can be avoided if you work with different tools and with several companies on a project.

Waldorf & Statler have long recommended packing test charts in front of them when exporting from tools, with which it is easy for the artists to then determine whether your material is interpreted correctly.

It's a shame that ADOBE cannot change the attributes for full and legal.

Have a nice evening

Charles Waldorf

[R Neil Haugen]

Hey, agreed. Although I've found that rather than hunting for 'reasons', it's often more accurate to just realize people tend inconsistent more often than not, once something is done one way by someone along the line (even if meant as just 'I'm getting this working for the moment while we puzzle details out later ... ') it likely gets stuck as "the" action, and stasis is the nature of many codewriters.

Makes things difficult for users at times, but ... humans have been humans for millenia, and we don't have a fix for that in sight.

Neil

[Waldorf & Statler]

Hey Neil,

hey ADOBE,

now we have the new Version from ADOBE 2021 Premiere Pro and After Effects,

but the Bug with the DNxHR 444 ist not Fixed.

Lars Borg say nothing, to his thinking about YUV, and the point to work with standarts.

We wait for anthers.

Greetings

Charles Waldorf

[R Neil Haugen]

No, we don't have the "2021" version yet, that would be a 15.x by their system. We're still on the 14.x 2020 build series.

But you're quite correct, they've not changed their practice with DNxHD/R 444.

Sigh.

Neil

[Waldorf & Statler]

Ok Neil 🙂

not 2021 but a new Full Version.

A good point for change old mistakes.

Have a nice day and stay healthy

Christian

[Andy 1968]

Could this solve the problem for you?

https://youtu.be/nN2XlWWd26Y

[Waldorf & Statler]

No!

[Waldorf & Statler]

It's not my problem,

it's an ADOBE problem!

This problem cannot be solved by doing something wrong in other software

to make it look right in ADOBE After Effects & Premiere.

If there is a standard and there is what DNxHR is about,
you have to stick to it.

DNxHR 444 is by design a YUV codec in legal range.

The advantage of a 444 codec is that I don't have chroma subsampling, but rather have information pixel by pixel.
Therefore, a conversion between YUV and RGB is possible without losses. But 444 is not just RGB !!!

RGB is always full range but DNxHR444 is not RGB otherwise it would be called DNxHR-RGB but it doesn't.

With yours, we tinker something right, the standard will be abandoned
and so there are problems with the transfer to other programs and artists who work according to the standard!

You must always include the information about your incorrectly converted material, incorrectly exported for ADOBE in full range, so that every artist knows that this footage is only suitable for ADOBE.

If such material from ADOBE is passed on to other tools, further processing errors can occur.

We know what the error is,
and we are aware of the wrong path in DaVinci or other tools.

But it is not the right way!

[Waldorf & Statler]

IBC 2023, the DNxHR 444 ADOBE error is not stopt!

It's nice to play with AI and AI.
The basic software should also run stably and codecs should be interpreted correctly after more than 6x years.

It's like always with ADOBE, you buy something,
now AI & AI and install it.
You don't know where, how and why things need to be repaired.
Technical understanding of film, video & audio technology is lacking at ADOBE.

However, people are certainly already thinking hard about how they can cheat customers in the future if, thanks to AI, fewer artists work with ADOBE.
I'm guessing that in the future you will have to pay for each rendered image, multiplied by the age of the artist + 20%

[R Neil Haugen]

Hey, great to see you again!

Please ... create a new post about this, I'll be happy to jump in on it, and we'll tag their format head for comments ...