DNxHR export too dark

Hi All,

I try to use Handbrake to encode my material into h264/h265 as suggested quite often in this forum. Since I am on WIN, I've chosen DNxHR SQ as my intermediate format.
However, if I compare the DNxHR clip with a clip rendered with h264 in Davinci, the DNxHR clip looks significantly darker and more saturated.
I am using VLC Player for review. I am working in a color managed environment (DWG). My output color space is Rec709 2.4. My output settings are all default.

EDIT: Handbrake just finished. The h265 convert now looks as my pre-view. Doesn't appear to be a problem but somehow confuses me.

Any idea what goes wrong here?

VLC interpreting the metadata tags in video file differently. Different players do all kinds of funky things so their output isn't a good reference for correctness.

Long story short, video file contains both the data ("what is") and metadata (description of "what is"). Lets say data values in video file are encoded with colorspace X. Metadata tells that it is encoded as "something X-ish". Now, VLC reads the file and "thinks", allright, it is X-ish, so I'll apply an additional transform Y to it "for reasons". This makes the player show data to you differently than some other player that has its own reasoning over the metadata tags. Root cause of problem is both ambiguity in metadata tag meaning and different interpretations of this ambiguity in different softwares.

Thanks a bunch Hendrik. This somehow was my assumption but now I know. This video production journey is a long one I guess

It is important to choose a standard known accurate player for evaluation render output. For the Mac, I use either Cineplayer or QuickTime. In addition, your playback monitor should be calibrated to your delivery standard, for example rec 709. Without working in that environment you will end up chasing your tail trying to get acceptable client results.

And for the intermediate version I'd rather use DNxHR HQX 10 bit to avoid any visible losses.

I am using VLC Player for review.

That's fine for reviewing content.

I was trained with the idea that we can only review quality in a proper viewing environment. If any part of the signal chain alters the image, you won't see it as it really is.

Darren offers some really good info on how to get a proper viewing environment below. It's a good watch.

I am using VLC Player for review.

That's fine for reviewing content.

I was trained with the idea that we can only review quality in a proper viewing environment. If any part of the signal chain alters the image, you won't see it as it really is.

Darren offers some really good info on how to get a proper viewing environment below. It's a good watch.

Yep - I am watching Darren's & Cullen's channels on a regular base. I know about the difference between a clean feed device and my poor mans WIN color managed one. However, my screen is calibrated (as a windows screen of course), has an decent color reproduction (> 100% REC709) and I am talking about comparing all this material on this same screen. (BTW: I am a hobbyist - no client work).
Meanwhile I experienced some other strange behavior, which I need to investigate further. I will come back to this topic as soon as I see clearer.

And for the intermediate version I'd rather use DNxHR HQX 10 bit to avoid any visible losses.

Interesting point. I now use HQX 10 bit but noticed that I use BT709 as my export color space, which might make little sense here. What color spaced would you suggest for

a) creating an intermediate for later h264/5 conversion and/or
b) archiving a high quality master

My footage is a mix from h264, h265 10bit and DNG raw 12 bit in a DWG color managed workflow.

You can go for HQX 12 bit if you think the extra space needed is worth it and the camera shooting those DNGs is that good and contributes enough footage. For the other sources it’s overkill.

You can go for HQX 12 bit if you think the extra space needed is worth it and the camera shooting those DNGs is that good and contributes enough footage. For the other sources it’s overkill.

Thanks Uli. But what about the color space? I think BT709 is 8 bit so I will loose information here too.

Color Space has nothing to do with bit depth.

Color Space has nothing to do with bit depth.

Hm... Looks like I need to do some more homework. Being a software developer apparently doesn't help too much when you open this can of worms.

Color space is essentially the intended RGB definition points at X white balance. The Color range, perhaps.


Bit depth is how many levels the format stored. Eight bit is 256 levels, 10 bit 1064, 12 bit a LOT more. More levels means you can do more charges in tonality in post (typically) before artifacts occur.

Sent from my SM-S908U using Tapatalk

Bring file back to Resolve and lay over your timeline. It will most likely look the same which is proof of crap happening in VLC preview.
DNxHR holds key header regardless range- if app can't read it properly then you may have problem (eg. file is exported with legal range but app is hard coded with full). Resolve use to set DNxHR headers properly. Maybe last version broke it, but I dot think so.
Bit depth has no direct relation with colour space-this is true.
VLC is by o means any reference player. It's hard to actually find good software player on PC.
You can try Calibrated Tin Man player which allows to assign gammas etc. Other option is mpv but it's bit difficult to manage.

Possibly a data levels issue.

VLC Player reads DNxHR clips as video levels instead of full even if you write full out of Resolve. Resolve also reads DNxHR as video instead of full when importing the rendered clip. You can manually switch it to full instead of auto via the clip attributes.

Resolve use to set/read flag properly after BM made 2 rounds of fixes.
Maybe it's broken again.

Possibly a data levels issue.

VLC Player reads DNxHR clips as video levels instead of full even if you write full out of Resolve. Resolve also reads DNxHR as video instead of full when importing the rendered clip. You can manually switch it to full instead of auto via the clip attributes.

Will check this ASAP. BTW I am still on version 17.4.6. Currently I am very busy with other stuff but will examine this closer as soon as I have more time.
Thanks for ally your advise so far.

Ok, finally I had some time to investigate my issue, here're my findings:

First I decided to learn a bit more about color space, bit depth and everything that confused me until now. This guys YT channel is a gift for all who want to learn the essentials: https://www.youtube.com/@VideoTechExplained

Funny enough, after I digested all this information, I found that the problem I described above came from a forgotten Kodak LUT in the timeline section, which messed up my results.
I did some more tests where I rendered different formats, loaded them back into DR and compared them to the DNG footage. I decided to go with HQX10 as Uli suggested. I will use DIWG as my intermediate color space and REC709 for transcoding into H265 for delivery with Handbrake.

Thanks again for your tips.