Davinci Resolve/Rendering

Just curious what settings do you guys render out as in Davinci Resolve? I've noticed my color grading always looks more vivid inside of resolve but when rendered out it doesn't look as colorful. On the deliver tab under the settings that say "auto, use data levels, use video levels" I leave that as auto (if that matters). Any tips for helping your color hold up when rendering? or is it common to lose a little bit of the color? Also what's the equivalent of 4K Prores on PC? Thanks.

I realize this is the cinematography forum.

This should technically be posted on the Resolve forum. I'm sure you'd get more advice there. But on Windows I would export as DNxHD

This should technically be posted on the Resolve forum. I'm sure you'd get more advice there. But on Windows I would export as DNxHD

DNxHD only goes up to 1080p though right?

"DNxHR".

-

"DNxHR".

-

..erm, yes that one.
My mistake

DNxHD goes up to 1080p. DNxHR has no dimensions limit.
Maybe the configuration you're using is too compressed, thus losing a bit of information/color. If you use the highest settings you should get pretty much identical results.

Thanks for the help, I'll update to the latest version of resolve and export as DNxHR.

What are you using to play back the DNxHR? With VLC I just get a black screen...

How did you get the DNxHR codec? I don't see a download for it and I don't want to purchase an AVID product that I won't use just for the codec.

I think it's contained in the latest Avid Codecs pack isn't it? (always really hard to find the most up to date version, dunno why it's so hard for Avid to make a page for it that's kept up to date?!)

Edit: Yeah just checked it.. I'm on Windows and after updating to the 2.6.0 pack I now can select DNxHR as a Quicktime codec!

Here are the direct links... (hope it's ok to link to them from here?)

Windows:
http://cdn.avid.com/Codecs/LE/2.6.0/Cod ... .0_Win.zip

Mac:
http://cdn.avid.com/Codecs/LE/2.6.0/Cod ... ac.pkg.zip

I think it's contained in the latest Avid Codecs pack isn't it? (always really hard to find the most up to date version, dunno why it's so hard for Avid to make a page for it that's kept up to date?!)

Edit: Yeah just checked it.. I'm on Windows and after updating to the 2.6.0 pack I now can select DNxHR as a Quicktime codec!

Here are the direct links... (hope it's ok to link to them from here?)

Windows:
http://cdn.avid.com/Codecs/LE/2.6.0/Cod ... .0_Win.zip

Mac:
http://cdn.avid.com/Codecs/LE/2.6.0/Cod ... ac.pkg.zip

Thank you! Any specific folder I should install the codecs to? Or it just has to be on the system and that's all?

Thank you! Any specific folder I should install the codecs to? Or it just has to be on the system and that's all?

If you're asking about Mac, unfortunately I have no idea... for Windows you just install it (of course requires Quicktime) and then the Codecs are available to every app that offers a QT export option...

Just curious what settings do you guys render out as in Davinci Resolve? I've noticed my color grading always looks more vivid inside of resolve but when rendered out it doesn't look as colorful. On the deliver tab under the settings that say "auto, use data levels, use video levels" I leave that as auto (if that matters). Any tips for helping your color hold up when rendering? or is it common to lose a little bit of the color? Also what's the equivalent of 4K Prores on PC? Thanks.

I realize this is the cinematography forum.

Had same problem and solved it by setting "use data levels", here now my renderings have the same colors that in color correction window, obviously using the Avid codec.

I installed the http://cdn.avid.com/Codecs/LE/2.6.0/Cod ... .0_Win.zip codec and it doesn't show up in Resolve. I wonder what could be the issue?

EDIT: For some odd reason I can only get DNxHR under the MFX and MFX OP1A video format.

I installed the http://cdn.avid.com/Codecs/LE/2.6.0/Cod ... .0_Win.zip codec and it doesn't show up in Resolve. I wonder what could be the issue?

EDIT: For some odd reason I can only get DNxHR under the MFX and MFX OP1A video format.

Same over here..Wonder what is mssing..

Resolve doesn't support QuickTime for encoding/decoding video - it has its own QuickTime 'flavours' baked in via .dlls that ship with Resolve - codecs only get updated when Resolve gets an update.

Resolve can only currently export DNxHR as an MXF (although not many apps can currently read that) and *can't* import QuickTime DNxHR - hopefully this will change in the next release.

This 'baked in' approach is why Resolve can't use any 3rd party Video For Windows codecs or QuickTime extensions.

Just curious what settings do you guys render out as in Davinci Resolve? I've noticed my color grading always looks more vivid inside of resolve but when rendered out it doesn't look as colorful.

I don't think that this is an issue of the codec as such, but of Gamma shifts and different interpretations of color spaces in Resolve's internal preview vs. external video playing software. Blackmagic clearly says that you need a professional grading monitor in order to judge color.

Resolve doesn't support QuickTime for encoding/decoding video - it has its own QuickTime 'flavours' baked in via .dlls that ship with Resolve - codecs only get updated when Resolve gets an update.

Resolve can only currently export DNxHR as an MXF (although not many apps can currently read that) and *can't* import QuickTime DNxHR - hopefully this will change in the next release.

This 'baked in' approach is why Resolve can't use any 3rd party Video For Windows codecs or QuickTime extensions.

what would you rate the Quicktime MP4 codec or the H.264 Codec for 4K rendering as far as quality? I'm trying to get as close to 4K prores as possible but I'm on PC at the moment.

what would you rate the Quicktime MP4 codec or the H.264 Codec for 4K rendering as far as quality? I'm trying to get as close to 4K prores as possible but I'm on PC at the moment.

Ugh. Terrible - MP4 or H.264 will destroy your footage. And whilst H.264 *can* be used for archival purposes, Resolve lacks the parameters necessary to export H.264 to that kind of quality.

In your position (and you're not gonna like this) I'd export either as an image sequence or as an uncompressed AVI and then compress it to DNxHR using QuickTime or some other package. It's the only current way (other than MXF/DNxHR) to get 4k out of Resolve without seriously comprising the quality. Note though that you won't be able to get QuickTime DNxHR back into Resolve (yet).

Personally, I only work with uncompressed 10-bit YUV AVIs when exporting out of Resolve now but for HD work you can use 10-bit DNxHD.

I don't think that this is an issue of the codec as such, but of Gamma shifts and different interpretations of color spaces in Resolve's internal preview vs. external video playing software. Blackmagic clearly says that you need a professional grading monitor in order to judge color.

Resolve's internal preview is just showing a full-range image (0-1023) which more often than not (but not always) maps studio-swing to full-swing. It's more predictable than most software I've used in how it treats different colour-spaces. Where you have to be careful is how you export footage - Resolve's 'auto' setting doesn't always get it right so it's important to know how your destination app (and codec) handles swing. ProRes 422 for instance is *always* YUV and should be interpreted at 'video' levels - some apps will bring it in as 'data' though which is where gamma/colour shifts start to happen. A better grading monitor will get you better grades but not knowing how your codecs work makes all that effort pointless.

Added to this, Mac-originated footage (particularly ProRes) may come in at the wrong gamma on PCs(1.8 vs 2.2 - Fusion does this, Resolve doesn't) and have to be compensated for before doing any further work on the footage.

In the screengrab below you can see the original TIFF (RGB) images on the left and a Mac-created ProRes HQ version on the right - Fusion's correctly remapped from YUV to RGB but hasn't caught the gamma difference which is why the two look different. Resolve handles the gamma correctly and both sequences look identical when viewing them in Resolve.



Here's another example - on the left is the same TIFF RGB sequence, on the right is a DNxHD sequence rendered out of Resolve at 'video' levels - Fusion expects the DNxHD to be at data levels (presumably, that's what the Avid codec is telling QuickTime's decoder) and consequently the footage looks wrong. It's easily fixed with an Auto-Gain but that doesn't make it any less wrong Once again, Resolve handles the footage transparently and both clips look identical when viewed in Resolve.



The moral of this story being: just because it looks right in Resolve, it doesn't mean your rendered footage will look right when it gets to wherever it's going. External H.264/MP4 encoding in particular is a minefield since some encoders expect footage to be input in a certain way (studio/full swing) - Sony Vegas *must* have footage in Studio-Swing otherwise it encodes incorrectly, ffmpeg/x264 examine the video stream and internally convert RGB to YUV 420.

And even assuming your footage is correctly encoded, you final video may look different when played back on a Mac or a PC since QuickTime wants/expects gamma information to be tagged in the .mov

One last example:



The clip on the left was rendered as an MP4 out of Vegas at studio levels and matches the source footage. The bottom clip was at data (or 'computer' as Vegas calls it) levels and has crushed the blacks. On the right is the (correct) studio version on the Mac - notice that the gamma's out.

That post was very helpful! Thanks to everyone who replied.

Bottomline ... the video preview window in Resolve is not a calibrated solution. What you see is not what you get. If you want to see what you get, then use a properly calibrated monitoring and playback solution https://www.blackmagicdesign.com/produc ... hunderbolt). If you focus only on your export medium as your problem, you will be missing the main problem: Resolve's video preview window was never designed to be "accurate." FCPX and Premiere do a better job approaching a Rec. 709 color space than Resolve because what your are seeing in Resolve in a inaccurate floating 32 bit signal trying to be represented in a perhaps poorly calibrate GUI monitor. Never trust Resolve's preview monitor. In fact, I wish we could have the option to make it monochrome.

Whilst I'd agree that in a professional workflow having a calibrated 10-bit reference monitor is a requirement, it's not always an option - and it's not as big a deal as you make it out to be Scott.

The RGB and Rec.709 colour-spaces are identical and the only real difference between the two is in the gamma (2.2 vs 2.0) - yes, that's a perceptible difference but not one that's going to suddenly make your movie unwatchable.

Inadvertently allowing codec-created gamma and colour-space issues to pollute your footage is a real problem that can cause major downstream issues and potentially render your film unwatchable - especially in a Windows workflow which is hampered by a crippled QuickTime decoder, the archaic Video for Windows framework and the lack of a standardized intermediate format.

There are literally tens of thousands of posts on the internet with people looking for solutions to the QuickTime 'gamma shift' and asking why their video looks crushed on YouTube or Vimeo - these problems have nothing to do with working with a calibrated monitor or not.

Or is that 2.4 versus 1.8 gamma. I've seen different numbers used by different people over the years to think there isn't an industry consensus on gamma.


Rick Lang
Sent using Tapatalk HD

Or is that 2.4 versus 1.8 gamma. I've seen different numbers used by different people over the years to think there isn't an industry consensus on gamma.

Thanks for that Rick - got me off my ass to double-check It seems gamma wasn't specified in the HDTV spec until ITU-R BT.1886 (2.4):

The problem is the current "rulebook" for HDTV, that is Rec. 709, actually makes no mention of gamma. Because of legacy technologies - NTSC, sRGB, and others - we've arrived at a defacto "average" display gamma of 2.2. Despite this number not ever being specified by the ITU in Rec. 709, it is the display gamma you are likely to find on virtually any HDTV found in the home, on laptop and LCD computer displays, and many tablets and smart phones. And again, this number of 2.2 is a ballpark figure with many devices measuring at odd numbers such as 2.15 for the iPad Mini for example.

The reality is, if you're monitoring and mastering at 2.4, contrast in these images will always seem slightly lifted on 2.2 displays. So for example, if the room we're coloring in has a Sony OLED using a gamma of 2.4, then our deliverables will look quite a bit different when seen on our client's 2.2 gamma iPad or MacBook Air. Rec. 1886 was needed but is far from universal implementation. Ask many a technician in both the field or in post if they had even heard of it and you would likely hear "no" more often than not. My own personal rule of thumb is that in situations where I'm handling the deliverables myself and those deliverables are for 2.2 displays, I set my monitors to 2.2. When I'm working with a facility and a colorist whose monitor is set to 2.4, then my monitors are 2.4.

Good article: http://www.negativespaces.com/blog/2013 ... gamma.html

Thanks for the ITU-R BT.1886 spec. I've seen other forum discussions with various values including posts from colourists and think your approach to match what your client is expecting is wise. Sorry I was too lazy to look that one up myself!


Rick Lang
Sent using Tapatalk HD

Whilst I'd agree that in a professional workflow having a calibrated 10-bit reference monitor is a requirement, it's not always an option - and it's not as big a deal as you make it out to be Scott.

The RGB and Rec.709 colour-spaces are identical and the only real difference between the two is in the gamma (2.2 vs 2.0) - yes, that's a perceptible difference but not one that's going to suddenly make your movie unwatchable.

Inadvertently allowing codec-created gamma and colour-space issues to pollute your footage is a real problem that can cause major downstream issues and potentially render your film unwatchable - especially in a Windows workflow which is hampered by a crippled QuickTime decoder, the archaic Video for Windows framework and the lack of a standardized intermediate format.

There are literally tens of thousands of posts on the internet with people looking for solutions to the QuickTime 'gamma shift' and asking why their video looks crushed on YouTube or Vimeo - these problems have nothing to do with working with a calibrated monitor or not.

I may be mistaken, but the OP is wondering why things look one way in the Resolve preview window and then vastly different upon export. It really does not matter what codec you export to, it's not going to look like what one sees in the Resolve preview window. Anyway ... I agree that various codecs pollute what one sees (especially, h.264 the codec from hell that has major gamma problems) even in a 10 bit, calibrated system upon export. It drives me nuts. I suppose I was trying to help the OP address a potential major cause of his problem. I have graded many a timeline in a FCPX and Premiere using the preview window with reasonable results for upload to Vimeo, the Resolve preview window is entirely inaccurate and overly saturated, as it is squeezing its floating 32 bit signal into, likely, the OP's sRGB color space (GUI monitor). Everything in the Preview window might look great but the export - even ProRes 422 HQ - will look flat and too light.

I ended up getting a pretty clean render.

Glad you got everything to work for you Brian!

I have graded many a timeline in a FCPX and Premiere using the preview window with reasonable results for upload to Vimeo, the Resolve preview window is entirely inaccurate and overly saturated, as it is squeezing its floating 32 bit signal into, likely, the OP's sRGB color space (GUI monitor). Everything in the Preview window might look great but the export - even ProRes 422 HQ - will look flat and too light.

Look at the .PNG below - original ProRes HQ footage from a Sony NEX-VG10 in Resolve's preview which has been further rendered to uncompressed 10-bit-YUV. This has then been encoded to H.264 via x264 and played back in VLC. I sampled the darkest area under the cheekbone in Photoshop on both the preview and the x264 video - not entirely scientific and I can't say I got exactly the same pixel since Resolve's footage is 1080p and the render is 720p (and a 422->420 conversion has taken place during H.264 encoding) but the two images are close enough that you need to sample values to tell them apart.



Maybe it's different on the Mac, but on the PC, Resolve's preview is pretty much 'what you see *is* what you get'. Of course a calibrated reference monitor is going to be more accurate for viewing grades but what Resolve is sending to the preview still seems pretty accurate.

And just for fun - here's that same H.264 in Windows Media Player, VLC and QuickTime Player:



Sadly, no matter how carefully we manage our footage, renders and codecs, we're still at the mercy of the software and/or device playing it *sigh*

Glad you got everything to work for you Brian!

I have graded many a timeline in a FCPX and Premiere using the preview window with reasonable results for upload to Vimeo, the Resolve preview window is entirely inaccurate and overly saturated, as it is squeezing its floating 32 bit signal into, likely, the OP's sRGB color space (GUI monitor). Everything in the Preview window might look great but the export - even ProRes 422 HQ - will look flat and too light.

Look at the .PNG below - original ProRes HQ footage from a Sony NEX-VG10 in Resolve's preview which has been further rendered to uncompressed 10-bit-YUV. This has then been encoded to H.264 via x264 and played back in VLC. I sampled the darkest area under the cheekbone in Photoshop on both the preview and the x264 video - not entirely scientific and I can't say I got exactly the same pixel since Resolve's footage is 1080p and the render is 720p (and a 422->420 conversion has taken place during H.264 encoding) but the two images are close enough that you need to sample values to tell them apart.



Maybe it's different on the Mac, but on the PC, Resolve's preview is pretty much 'what you see *is* what you get'. Of course a calibrated reference monitor is going to be more accurate for viewing grades but what Resolve is sending to the preview still seems pretty accurate.

And just for fun - here's that same H.264 in Windows Media Player, VLC and QuickTime Player:



Sadly, no matter how carefully we manage our footage, renders and codecs, we're still at the mercy of the software and/or device playing it *sigh*

Nice little study! Very interesting ... I use a nMP and a calibrated Rec. 709 Cinema Display as GUI and Eizo calibrated 10 bit CG277 for grading. Maybe there is a difference in the Resolve preview in Windows vs. Mac. Never considered that ... hmmm. The VLC looks good and, of course, the QuickTime looks flat. I use x.264, too, for uploads to the web and for deliverables that require that format because the gamma is more accurate. BUT ... yes … we are at the mercy of many variables that make our hard work look like junk. A pity. Then again, this has always been the dilemma in the sound engineering world, which is a part of my history.

I appreciate your demonstration!

Hey Scott!

'interesting' isn't necessarily the word I'd use for all this - sometimes I feel more colourful metaphors are appropriate

But yeah, Resolve's preview is a handy ballpark (on Windows at any rate, can't comment on Mac) but no substitute for a setup such as yours (I'm a big fan of Eizo monitors btw) - must be nice to have confidence in what your display is showing you and not have to second-guess how it's going to look on delivery

My lo-fi approach is to target web-stuff at the iPad since there's more of those in use than any single brand of PC/Mac monitor on the market. If it's on the web, chances are most viewers will be watching it on an iDevice (or Android). My preference is embedded HTML5 as opposed to YouTube and Vimeo since that gives the most control over how the final video's going to look.

For Blu-ray, well - checking my stuff on a PlayStation hooked up to a cheap-ass Samsung HDTV at factory settings is about as generic as it gets. I haven't had to do any projected/DCP stuff (yet) but that's a whole other ballgame with its own rules. Were I mastering for that I'd want to see it played back on the same (or similar) equipment before committing to a final deliverable.

Hopefully all of this has proven of some use to the OP and others that might have an interest in it - this kind of knowledge is (as I'm sure you know) hard-won and I've done a ton of research and testing during the course of making my film looking for better/more reliable workflows.

How do you render x.264 please? I've been interested in this for a while but haven't been able to find an option for doing it...it may well be right under my nose! I use an 2014 iMac / Resolve / FCX. When I looked into it I saw that there had been some software that is now not available.

Resolve's preview is a handy ballpark (on Windows at any rate, can't comment on Mac).

I wish the preview window would work for me. Maybe it's my Cinema Display. However, my i1 Display Pro indicates that I am in the right neighborhood.

I'm a big fan of Eizo monitors btw - must be nice to have confidence in what your display is showing you and not have to second-guess how it's going to look on delivery.

HA! I second guess all the time ... that's why I use your approach.

My lo-fi approach is to target web-stuff at the iPad.).

Funny, I did a theatrical release (a short documentary) and before I released it, I split hairs between my Eizo, my Cinema Display, my iPhone, and iPad. If it doesn't look good on my iPad, I keep working till it does.

How do you render x.264 please? I've been interested in this for a while but haven't been able to find an option for doing it...it may well be right under my nose! I use an 2014 iMac / Resolve / FCX. When I looked into it I saw that there had been some software that is now not available.

Are you a Mac or windows user? I am a Mac user and use x.264 in Compressor. If you are a Mac user. The following might help:

x.264 codec: http://www.macupdate.com/app/mac/24173/x264encoder

Here is Larry Jordan's blog and instructions. However, they are dated: http://www.larryjordan.biz/compressor-x ... ove-video/

I use:
Under Compressor Quality use: Best (on the slider) and Best quality (multi-pass)
Under Data Rate use: 10-20,000 Kbits/sec

You can play around with the gamma setting adjustment and Color Mid-Tone section to taste, as YouTube and Vimeo do different weird stuff to gamma.

Hope this helps.

Whilst somewhat more technical, I've found this a great resource for getting good encodes out of x264 (I encode straight out of QuickTime Player rather than use Compressor):

http://www.lighterra.com/papers/videoencodingh264/

Also, the x264 project has recommended profiles (Criterion Collection approved no less!) for Blu-ray encoding here:

http://www.x264bluray.com/home

I use these for Blu-ray mastering and for creating Blu-ray quality MKVs.

Hi guys,

Excuse me but if you wanna avoid QT/Compressor encoding to make H264, please use Handbrake : lib always up to date, good implementation aso...
https://handbrake.fr/
It uses the last x264 codecs too, and matches what you really need in the field of exports for the web for ex. I think you know Compressor is slow with 264, doesn't use great modern features like 8x8 or cabac... You won't change back from Handbrake I think.


About the rest of your interesting topic, a way of approaching the WYSIWYG may be to connect Resolve directly on a correct balanced plasma TV to grade. I found this to be a good deal on a 32" Sony, and appears (for me on my mac) to be the best way for RGB/Rec. 709 considerations...

Nice little study! Very interesting ... I use a nMP and a calibrated Rec. 709 Cinema Display as GUI and Eizo calibrated 10 bit CG277 for grading. Maybe there is a difference in the Resolve preview in Windows vs. Mac. Never considered that ... hmmm. The VLC looks good and, of course, the QuickTime looks flat. I use x.264, too, for uploads to the web and for deliverables that require that format because the gamma is more accurate. BUT ... yes … we are at the mercy of many variables that make our hard work look like junk. A pity. Then again, this has always been the dilemma in the sound engineering world, which is a part of my history.

I appreciate your demonstration!

Just asking. Which Quicktime Player are you using? I have noticed that if I use Quicktime Player 7, with colour preference set at "Final Cut colour" and if I deliver out from Resolve at "Data level" in Prores 4444, the colour shown in Resolve GUI monitor and the output look the same. The GUI, in my case is calibrated Rec 709 with gamma 2.4. I am talking about Mac system here.