12.5b1: New monitor - render does not match preview

Hi,

I got a strange issue. I bought a new monitor, edited a project and the render output does not match the preview in Resolve. The monitor is an Asus PB287Q 10Bit UHD monitor. The render result looks much flatter than the preview in Resolve, in VLC and when I upload it to Youtube (on the same monitor and on Windows and Linux). In Windows Media Player, it looks ok. I tried rendering to h.264, DNxHD and uncompressed YUV. When I set the Data Levels in the Render Settings to "full", the result looks almost OK but with clipped highlights. As I didn't have the same problem with my old Samsung TV/Monitor (which has only 8Bit capability), I suppose it has something to do with the monitor bit depth capabilities? Is there some configuration setting in Resolve that I should have changed?

-S

Bump... I have a bunch of videos on hold which are meant for YouTube so I'd really appreciate any insight or hint on that...

is a calibration issue.

do you use a blackmagic card to view your output of di you use the gui?

Also if connected through the GPU and not a BM card what GPU do you have as the one in your signature doesn't do 10bit out

@walter:
I use the GUI. I don't think it's a calibration issue because I watch the render output on the same monitor.

@Adam:
I wasn't aware the the GTX770 doesn't do 10Bit out.

So it actually isn't related to the new monitor but probably an issue with 12.5b1?

In the project in question I'm also using groups for the first time and group pre-clip grades. Could that be a bug in 12.5b1?

Example: http://home.gofferje.net/stuff/dr12.5-r ... smatch.png

You can see clearly how in the rendered version the contrast and saturation is lower...

Did some more testing... It's that &/#%#&""½$$ Quicktime!
I did a render to uncompressed YUV AVI and now all fits perfectly...

is not just quicktime, has been discussed at nauseum here: resolve is NOT designed to color with the gui. you can, if you are really careful and calibrated ( there is a section in the manual about that ).

@walter:
Yes, I am aware of that, however, calibration issued shouldn't account for a difference on the same monitor, least of all when I literally put the windows side by side. If you check the screenshot I linked, you will see the VLC window on top of the Resolve window on the same screen showing slightly different colors.

In this case it's really Quicktime which produces a "wrong" result. During my tests I also rendered to Quicktime YUV uncompressed and still got the different contrast levels while rendering to AVI YUV uncompressed produces a result which looks exactly like the Resolve GUI preview when / put the VLC window on top of the Resolve window again.

Have you tried playing back the files in another player to ensure that it's not VLC playing them back wrong? Wouldn't be the first time I've seen it do that.

Or try loading the file back into Resolve and put it over the original as a split screen

Windows Media Player plays is better but also not 100% correctly. Uploaded to Youtube as well as Facebook and then watched in Firefox and Internet Explorer, a bad file stays bad. All watch tests done on Windows 7 and kUbuntu 14.04 (minus Internet Explorer and Windows Media Player, obviously).

Here's my testing results so far:

Quicktime DNxHD: Bad
Quicktime h.264: Bad
Quicktime Uncompressed YUV 10 Bit: Bad

AVI Uncompressed YUV 10 Bit: Good
AVI Uncompressed YUV 10 Bit converted to h.264 4:2:0 with libx264: Good

It is notable that there is no visual difference in the contrast and colors between the Quicktime renders.
I'll try what you suggested - import it back into DR and do a split screen.

Are you using output LUTs or monitor LUTs?
That might be the problem...
If everything is untouched, than the rendered file should look the same as on GUI if watched in the same monitor. But there are a lot of settings that can make that derail, thats why a BM card comes in handy and proper calibration vital.

Nope, no LUTs and I agree - it SHOULD look the same . At the moment, I have no time for more experiments but I'll get back to that as soon as I have a bit air.

DNxHD and some other formats expect VIDEO range levels from 64-940. The main issue with rendering and reviewing on a computer monitor is that a computer monitor will display the DATA range by default unless the metadata is present in the file to tell the video player software which levels are embedded in the file. Video players can also use the codec information to 'guess' which range should be used for playback decoding.

If you are doing non-broadcast work and using a computer display, then use DATA levels for output files, but stay away from codecs that may be interpreted as video levels.

It's quite a complex issue and I would suggest you do a little research into the topic.

Resolve 12.5 has made it easier to color correct without an intensity card and external monitor in the default project settings. "Use the Mac Profile Display in the Viewer" box is checked is an example.

It also includes the YouTube and Vimeo presets that make it easier. I don't advise selecting "Auto" in the "Advanced Settings" section of the render settings, make sure it is on "Full" for YouTube or Quicktime, to emphasize Peter's point.

I think that is a good place to start that appears to match the internal GUI, high compression aside.

I've been experimenting with a 10 second clip from the 4K Production Camera Raw files and it puts out a 50mb file with the above YouTube settings.

ProRes422 - 600mb

ProRes 4444 XQ - 2 GB

What I don't understand, and have been tripping over lately, is why certain codecs (H264 in my case but I assume that there are others) "may be interpreted as video levels" when the stream metadata contains information on exactly how they should be interpreted. Why does Resolve not use this information, rather than making a guess or assumption?