Video Monitor LUT on Scopes...why?

I'm just curious as to why anyone would want to have a Video Monitor LUT also applied to the Scopes?

And as a follow up, why in the world does Resolve have this setting as the default setting?

I calibrate my external monitor fairly frequently and generate a corrective LUT that is applied to the 3D Video Monitor LUT setting. However I hadn't noticed until recently that the same LUT is also applied to my Scopes. Now why in the world would I want to do that? I was under the impression that the whole point of the Scopes is to give unaltered and objective information about the various levels of the image so that one can compare what they're seeing on their grading monitor to what they're seeing on their scopes.

Please enlighten me since I'm a bit confused by this default setting in Resolve.

I was wondering the same, but I found it useful today during calibration to compare 3D LUTS produced by the calibration software I'm using after spotting an anomaly. In general you'd presumably want it set to "No Lut" though. Would be interesting to hear of any other use cases.

This is a good case where it would be better to store the LUT in the monitor or in an external LUT box, and that way it won't affect the scopes.

Yes, but why should I pay 800$ for an external LUT-Box when Resolve has a "built-in LUT-Box" that only has to be made working correctly.
IMHO the developpers of Resolve should correct this to the next update.

I also stumbled on this and discribed it here:
viewtopic.php?f=21&t=55755

I also opened a support-call via contact-form but no answer yet.

@BMD: Please correct this. Actual behavior makes the 3D Video Monitor LUT useless.

Thanks a lot.
Peter

This is a good case where it would be better to store the LUT in the monitor or in an external LUT box, and that way it won't affect the scopes.

I didn't understand what is a good case here. I've got an eeColor box coming (just $300/£249 these days Peter) and expect to be using it somewhere, but the LUTs feature does work (at a cost of about 1fps per LUT on an overclocked i6800 with gtx 1070) so an external box isn't essential.

What seems wrong to me is:

1. The default for Scopes LUT is "Video Monitor Selection" whereas either "No LUT" or a new mode "Output Selection" would make more sense and definitely be safer.

2. There is no LUT for the Media view, so colours go really off with a wide gamut display. An external LUT box on DeckLink would address that.

What is great though is that my P2716D's now show images that under extreme scrutiny look the same, with no humanly visible uniformity issues (they are a disaster in modes where the uniformity calibration is unavailable), and calibration reporting a 99.5% or higher sRGB coverage and nearly the same for AdobeRGB.

Hey, can I tack something related on here?

I've been fooled by the scope lut "bug" before, and after much hair pulling, trying to figure out what what going on with my scopes, I am now in the habit of chucking the stock color bars in each new project to make sure everything falls where it should.
Ok, now, when I apply my monitor correction lut, and it also switches the scope lut, the color bars are off the marks. No surprise here. I switch off the scope lut, and everything goes back to normal. But, another one that gets me sometimes is "Hide UI overlays for optimum performance". When I switch that on, it acts exactly as if I applied my correction lut to my scopes. I don't understand why this should be happening. Is it a bug, or am I not understanding the pipeline? It would be nice to have this option available.

One other thing to note, and which on reflection makes me think that the LUT feature is fundamentally flawed, is that if you switch to the edit view, the video monitor LUT is applied to the same monitor that previously had the colour LUT applied.

So for example, suppose you have monitor A on DeckLink with a Video Monitor LUT for its correction, and a single monitor B for the resolve controls with its correction as the colour LUT. That works fine when doing the colour work, but switching to the edit view will apply the LUT for monitor A to monitor B. While accurate colour matters less when editing, this is clearly wrong.

At least as an optional way to set things up, better would surely be simply a LUT for each monitor. For those without external LUT boxes or monitors with internal LUTs, i.e. for most people who use Resolve, if they know about the LUT feature they'll be using it to set monitor calibrations. No matter what is shown on each monitor, they want a specific LUT for each monitor at all times because that's why they're using the LUT. It makes no sense for the calibration of the monitor on DeckLink to be applied to any of the other monitors, yet this is what Resolve will do.

It does at times, and this is one of them, feel as though some features are conceived and developed by people who do not use Resolve themselves, giving rise to the disconnect of "what the developers thought would be useful" vs. "what the end user actually needs." I doubt that this happens, but it would be ideal if the developers, sales people, support and marketing folks all have training courses in colour correction and editing, and all get to work (read are *made* to work) on 24-48 hour group film projects (internal competition even) from time to time so that they can experience the good and bad parts of the interface, and understand better the end user experience for themselves.

Yes, but why should I pay 800$ for an external LUT-Box when Resolve has a "built-in LUT-Box" that only has to be made working correctly.

The cost of having two outputs -- one with the LUT (for the monitor), one without the LUT (for the scopes) -- would cost you a lot more than it would for an external LUT.

One problem with asking questions on a public internet forum is that you'll sometimes get correct answers that you won't agree with, or you won't like. It doesn't make the advice less correct.

Yes, but why should I pay 800$ for an external LUT-Box when Resolve has a "built-in LUT-Box" that only has to be made working correctly.

The cost of having two outputs -- one with the LUT (for the monitor), one without the LUT (for the scopes) -- would cost you a lot more than it would for an external LUT.

One problem with asking questions on a public internet forum is that you'll sometimes get correct answers that you won't agree with, or you won't like. It doesn't make the advice less correct.

Hi Marc,
I'm writing about the built-in scopes in Resolve.

Resolve has built-in scopes
Resolve has built-in LUT for monitor output.

The only thing to do is NOT to set the monitor LUT to the built-in scopes.

I think it's only a little bug, because as Mike wrote, when set "Hide UI overlays for optimum performance" off, it obviously works correctly.

Thanks
Peter

I think it's only a little bug, because as Mike wrote, when set "Hide UI overlays for optimum performance" off, it obviously works correctly.

Applying the Video Monitor LUT to a screen other than the one used for the Video Monitor output when on the Edit page is surely wrong though, so Resolve isn't working correctly for some views. Given the odd behaviour with the LUTs, the choice of default setting for the Scopes LUT and lack of a LUT at all for the Media view, perhaps we are using this feature for the wrong purpose in trying to use them for correcting the colour on our displays. I wonder if the assumption behind the design of the feature or lack of a feature for correcting displays specifically is that we all have LUT capable monitors or LUT boxes, and while the LUTs feature can be misappropriated in some cases, (thankfully successfully for the colour page that we all care about the most), the LUTs feature is actually intended for a different use case entirely.

we are using this feature for the wrong purpose in trying to use them for correcting the colour on our displays.

If this is what you are actually doing, compensating for an inferior display, then maybe that approach might need to be re-evaluated.

The original intent of Look up Tables was to enable a predictable estimation of a cross-media transform, that is- how a dye-layer print might look when destined for a film-out cinema distribution (DI process). Arguably, pre-distorting your image values so that a bad monitor is forced into displaying a synthetic calibration doesn't really make sense to me.

If your display can't make enough "blue", for example, pumping a ton of it into your output isn't really helping, and if that is not carefully situated in your output chain, seems inevitable that where you set your measurement point is critical. In a software chain that might not provide enough test points, or they may be concatenated in such a way that your best approach is to get an independent modification through independent, external means. Its a bit like double-blind scientific testing. Don't let them see each other and they won't be able to bull$#it you.

Sympathetically, at one point, I had hoped to be able to use a BlackMagic HDLink as a LUTbox, but it is a miserable failure, and just barely okay as a surround-sound SDI-audio dis-embedder.

jPo, CSI

we are using this feature for the wrong purpose in trying to use them for correcting the colour on our displays.

If this is what you are actually doing, compensating for an inferior display, then maybe that approach might need to be re-evaluated.

I'm curious, how else do you calibrate your display? Even a $20k Flanders needs calibration. The calibration process creates a 3D LUT which in turn is placed in line before the image hits the display. I'm confused by your post.

Even a $20k Flanders needs calibration.

That's right. Use your calibration probe/software to develop a new CFE file, load it directly into the monitor and viola. This should be a part of your routine maintenance.

No LUT modification in the grade software or boxes in between.

http://www.flandersscientific.com/suppo ... -a-tpg.pdf

is how you do it.

jPo, CSI

I agree, an external LUT box is preferable to accomplishing the same task via software in Resolve's "Video Monitor Lookup Table." However, that assumes you have the budget for a LUT box (you probably should if you are using the Studio version of this software) -- and that you can find a LUT box that supports the resolution, framerate, and dynamic range of your output signal -- and physical video connector of your target display.

I'm am personally not sure why the default behavior of the Project Settings>Color Management>Lookup Tables has the 1D and 3D Scopes Lookup Table defaulting to following the settings of the the 1D and 3D Video Monitoring Lookup Table. In my mind, this is an incorrect default assumption to force on a user for almost every possible scenario.

In my opinion, it might be useful for Blackmagic to consider changing this default behavior -- especially in the context of the manual discussing the "ordinary" video scope behavior -- and the fact that the user can "choose" to have the software scopes use the Video Monitor LUT selection. In this case, the scopes are not behaving "ordinarily" and the user is not "choosing" to change their behavior -- that unconventional decision is being made for them.

Resolve 12.5.4 Manual Page 107
1D/3D Scopes Lookup Table: Ordinarily, Resolve's internal software video scopes provide an unbiased analysis of the actual video data levels within the Resolve image processing pipeline. However, you can choose to have the software scopes use the Video Monitor LUT selection, or any other LUT installed on your system, to transform this analysis to reflect the monitored output.

Resolve 12.5.4 Manual Page 106
See the default signal flow chart at the top of the page.

That's right. Use your calibration probe/software to develop a new CFE file, load it directly into the monitor and viola. This should be a part of your routine maintenance.

A CFE file is what FSI monitors use internally and basically a LUT in proprietary format. Using 3D LUTs as a way to correct a monitor's output based on the result of a calibration process is absolutely a useful way to do it, particularly for users with other types of monitors.

Using 3D LUTs as a way to correct a monitor's output based on the result of a calibration process is absolutely a useful way to do it, particularly for users with other types of monitors.

Exactly. You may lose around 1fps+ per LUT, but the principle is sound and works well, or at least well enough. The best thing IMO would be to add a Displays setting in Preferences so that it applies to the installation and not the project, and for each monitor detected have a setting for a correction LUT.

we are using this feature for the wrong purpose in trying to use them for correcting the colour on our displays.

If this is what you are actually doing, compensating for an inferior display, then maybe that approach might need to be re-evaluated.

I certainly agree that maximising display accuracy and mapping to a colour space in Resolve isn't ideal as it hurts performance, but from the existing LUT features we can see that it's perfectly viable, so worth adding as a feature because most users would be able to benefit.

What I found is that even though my monitors have internal LUT support, an external LUT produces a better result and is more flexible, so that's my preferred route. Being wide gamut, the LUT's are also needed to map to sRGB, giving a far better result than calibrating the monitors internal sRGB emulation.

I'm sure that if Resolve users were polled to ask if they would like a builtin feature that's designed and intended for applying a LUT for display correction purposes, the result would be overwhelmingly "yes!"

The other solution is to use external scopes. I loop my Scopebox through the HD-SDI monitor and see the same exact source the monitor sees. You could do this with Ultrascope or any number of hardware scopes if you wanted.

The 2 main advantages of using external scopes: 1) you can adjust them in ways not available in the daVinci scopes, and 2) it takes a little processing load off the main computer doing color processing.

Hi,

there's a third solution.

I opened a support call.
The support of BMD could replicate the issue, reported that the actual behaviour indeed is weird and they reported it to the development team.

Seems they will try to correct this.

Thanks
Peter

The other solution is to use external scopes.

I can imagine going that way Marc, probably with an ultrascope from what I've seen at this point. So far I've invested in order to get a productive home setup and not have easily avoidable impediments to a decent result; a high spec PC to get good render times and fast I/O (actually insanely fast with an M2 EVO 960), budget monitors that calibrate down to srgb well, Decklink card, Ripple (ugh), M570 trackball and a few other odds and ends has given a nice setup to work with. High CRI backlights and better chair to help eyes and posterior is the next essential upgrade!

While I agree that external scopes or external LUT boxes or Monitors with internal LUT capability are all ways around this, the scopes in Resolve are broken and essentially useless as they cannot be trusted.
We rarely get the issue as we run the hardware, but for laptop users, and situations where you don't have access to the necessary hardware, the scopes should work, but they don't.

Make sure you log it as a bug, as that is what it is. If you can't trust the scopes, it may as well not have them in the software, and frankly I expect better from an industry leading package.

[Peter Chamberlain]

Hi David, as you haven't commented above, what do you find broken about the scopes?

While I agree that external scopes or external LUT boxes or Monitors with internal LUT capability are all ways around this, the scopes in Resolve are broken and essentially useless as they cannot be trusted.
We rarely get the issue as we run the hardware, but for laptop users, and situations where you don't have access to the necessary hardware, the scopes should work, but they don't.

Make sure you log it as a bug, as that is what it is. If you can't trust the scopes, it may as well not have them in the software, and frankly I expect better from an industry leading package.

Curious to as to what is broken? I've always found them to match external sdi scopes perfectly.

While I agree that external scopes or external LUT boxes or Monitors with internal LUT capability are all ways around this, the scopes in Resolve are broken and essentially useless as they cannot be trusted.

I agree with Paul above: the internal scopes are OK and can be trusted. Where I would be careful would be if you're trying to check out-of-gamut errors, because a Vectorscope alone won't tell you the truth. Ideally, you'd need a diamond scope or something similar to show you those borderline cases that are just enough to get a file rejected in QC.

Ideally, you'd need a diamond scope or something similar to show you those borderline cases that are just enough to get a file rejected in QC.

And as I have pointed out repeatedly in related discussions, OOGs in RGB are not necessarily flagged as issues in YUV, CAV, Composite or other transformed combinations thereof or vice versa. The math is not straightforward, it is matrixed with different set boundaries, which really requires a more sophisticated analysis tool.

jPo, CSI

The Video Monitor LUT is shifting still the scopes in 14.3 when hiding UI overlay. It would be really nice to fix that.