Output for dummies

Hi guys,

I'm a professional photographer, working to learn more about color grading for some personal video experiments that I'm embarking on.

I've done a lot of poking around online forums, but have been having trouble finding some straightforward notes on best practices for output.

I find that in my current workflow, the colors can appear VERY different colors depending on whether I view them in VLC, with MAC preview, or in a web browser. Some of the programs show them quite close to what I see while grading in DaVinci, but some are wildly different.

Mostly, I just want a somewhat consistent color experience between what I see when grading on my mac, and how the videos appear on the web.

I don't have specialized video editing equipment like a specific grading monitor, etc (I'm working on a calibrated Eizo monitor). Perhaps that's something for down the line. But in the meantime, I feel that my color output is so wildly inconsistent, that there must be some simple things I can be doing to get a more consistent result on my current equipment.

I *have* found some notes on unchecking “use mac display color profiles”, which seems to help gain some consistency between the grade and the output file, but there are still major inconsistencies depending on what program I'm viewing with.

There are SO many different options for export from DaVinci, and then so many ways to convert to MP4, I'm at a bit of a loss. I wonder if someone might be able to recommend an "output for dummies" kind of workflow to get my graded project from DaVinci into an MP4 file that will display as consistently as possible across different platforms?

Thank you!

If other programs show your results differently, it's their fault! Apple's QT player is notorious, while VLC doesn't change the look from your source.
Try to download a file from YT or Vimeo and look at it in different players. Always the same?
If not, how can you be consistent in Resolve? A calibrated monitor is not a bad start, but you need an interface that circumvents any interference by the operating system, like a Mini Monitor.

The work that I'm currently working on will be seen almost exclusively on the web, so even if the color shift is the "fault" of the browsers, I'm interested in mitigating it as much as possible. In terms of still photography, I can choose between saving an image in a color space that has a broad range of colors, but will look awful in your average web browser, OR I can choose to render in a color space that will look pretty consistent no matter what program is opening it. Is there a parallel in video?

Or at the very least, are there any best practices that will can at least get me closer? The shift feels pretty extreme in my case, so I wonder if maybe I'm just doing something wrong period.

If anyone can share their play-by-play when working on a project bound for the web... Starting with the "deliver" tab on Davinci and ending in a finished MP4 file being uploaded to the web, I'd love to compare to what I've been doing.

Thanks

Jacob, Uli is more than right : better focus on Resolve preferences and project settings to be sure you work in the good environment, than wasting your time with third parties interpretations.
Then, be sure YOU can check your own work on a monitor, a TV, another one etc...
You may see differences between QT7 and QTX, all is said...

And VLC default settings should indeed show "the truth", I know they've been working on ProRes and DNxHD for years (I know JBK, the president of VLC, who really wanted to be fine on pro codecs too, we talked a lot about this at least 6 years ago, we can assume it's quite ok now )

Output for dummies ? I dunno, but I can say I (always) firstly export the higher resolution in the less destructive codec, to have the better file out of Resolve. For me it's ProRes. Then I can treat it depending on the destinations. I wouldn't ever proceed another way.
And I think you shouldn't bother with mp4 : make the better file in prores, if you can send it to vimeo-YT aso. this way. If too big, make a deinterlaced mp4 from 8000 to 12000 kbps, but only if the prores is too big because these platforms will re-encode what you send to them.

I can understand your concerns, this is why I'm writing here, but since I'm making mp4s with Handbrake, it would become very tricky and specific to enter the settings zone here...

Thank you, this is extremely helpful.

Particularly the note about VLC showing the "truth" is very helpful, (and make me believe I'm at least somewhat on track, as the images in VLC appear much closer to what I see in Resolve)

Perhaps part of the challenge lies in the final step for me: I'm bypassing services like YT and Vimeo and hosting directly on Amazon S3. To me this seemed to be the best bet for short looping videos.

Could the way I'm hosting the work be part of my challenge? Is there anything that YouTube/Vimeo does in its encoding/playback that would somehow bring clips on the web closer to what I'm seeing in VLC or resolve?

Sounds like this isn't a huge issue as far as color goes, but would love any notes on the below question too...

There are many flavors of prores. From what I can tell from some online research, the highest fidelity would be 4444. Any reason I would consider using any other version before converting with handbrake or uploading to YT?

Thanks again for the feedback.

It all depends on your sources!

ProRes 4444 (even XQ) would be a good choice for archival copies if you come from a high-end camera RAW format, like Arri, Red or Sony.

If your sources are cheap drones, smartphones or just photographic cameras shooting some video too, even ProRes 422 HQ might be overkill.

ProRes 422 HQ is a good mid-level format.

But to host it for your clients is normally a bandwidth consideration, since you'l pay for that. I'd use a distribution format there, not an archival format. Encode your archival copy to a good H.264 file in the mp4 wrapper. Ffmpeg is a good option for that, but the encoding in DR 14 became much better than in former versions.

Note that different operating systems and different browsers will also yield different video levels. This is a problem with which you can endlessly chase your tail, since a lot of it involves factors totally beyond your control. If you can restrict your clients to using one specific browser and one specific website, you could tailor your renders to what they see. But you'll still be at the mercy of their displays, which are notoriously inconsistent.

Exactly! Just do your best and then send it out into a merciless reality of divergent displays.

Exactly! Just do your best and then send it out into a merciless reality of divergent displays.

Very well-said.

I have told this story before: about 12 years ago (not long after YouTube started), I did (literally) hundreds of trailers for Sony Pictures. At the time, they were just starting to post trailers to YouTube. The studio was unhappy at the widely-varying picture quality online, so we did a series of tests to try to determine if anything could be done to compensate for losses in the signal chain. After six months of tests, they finally decided... nothing did any good. All we could do was just make the very best Rec709 broadcast pictures we could, upload them online, and hope for the best. Computer displays, different websites, different operating systems, and different online codecs are such a chaotic combination, it's almost impossible to predict how things will ultimately look.

If the content creators have all these standards and tools to ensure repeatability in their look (at least in how things are defined such as with ACES), you would think after 12 years, these online distributors would either have standards they utilize in preparing your video at their site for viewing or they would publish what they do to your carefully coloured film. I get the impression the content distributors feel what they mysteriously do distinguishes them in the marketplace. What would really distinguish them would be either of the above alternatives so content creators would al least recognize their work. Sure at the final consumption of your film there's no consistency now and never will be from web content. Once someone comes along with something they propose as a standard (like Dolby Vision) then someone else will make their own alternative (like Samsung did to avoid royalty payments to Dolby).


Sent from my iPhone using Tapatalk

Thank you all, this is all extremely useful. I definitely appreciate the "endlessly chase your tail" analogy, so I think after a certain amount of time spent on this my time is better spent elsewhere in terms of learning and refining what I'm doing.

Having said that, I did also want to circle back with something that I *feel* is actually helping a bit in case it's helpful.

I experimented with going to Project Settings > Color Management Settings, and changing "Timeline Color Space" and "Output Color Space" to sRGB. It's definitely still not perfect, but it does feel like the shifts between web viewing platforms and what I see when grading in Resolve are a bit less drastic.

I'm guessing this may only a suitable solution for those who are grading ONLY for web (like I am), and not so interesting for the majority whose primary target is something else. But in case anyone else has tried this, or thinks it has some value, I'd love to hear if this newbie is potentially going in a good direction with that solution?

90% of our output ends up on the Web and our 'reference' is a calibrated Rec.709 monitor driven from 12G SDI Decklink via a SDI > Display Port converter (gamma set at 2.4) and the results look fine.

Although you say you use a correctly calibrated monitor (EIZO), what interface are you using between computer and monitor to eliminate graphics chain issues? Decklink?- SDI? - HDMI? - Display Port? TB?

I don't have a rec.709 monitor, and while I can understand the benefits of using one for, I'm afraid at this stage it's premature/overkill for me to be investing in additional hardware. (FWIW, when I say "calibrated" monitor, it's based on standards in the still photography industry, and it appears those are very different than a calibrated environment for grading video)

While I would love for this aspect of my work to evolve to an area where it's worth setting up a system like that, in the meantime, what I'm really interested are any ideas in terms of how to get my files looking as consistent as possible from web browser to web browser. I think I'm getting a bit closer when changing my color spaces for timeline and output to sRGB, but I would love to hear if there's anything else that I might consider that would help.

When you say "the results look fine", are you saying that your output on the web is looking very similar to your rec.709 monitor? If that's the case, could I ask if you have any specific pointers on anything you're doing to prep the web files that's helping with the consistency? It seems that even people much more experienced than me are having this same browser-to-browser inconsistency issue, so any light you could shed on how you're achieving consistent, or at least "fine" results could be informative for all.

The monitors we use for Video are actually designed for pre-press, soft proofing Still images and have 14bit 3D LUTs 'built in' for hardware calibration. For example, the BenQ PG2401PT is under US$800 and includes switchable sRGB, Adobe RGB and Rec.709 factory pre-sets. They are 16:10 monitors designed for Still images but if you are using Resolve or even PP, a simple and cheap BMD 'mini-monitor' hardware PCIe card (or TB box version) will give you a reliable Video output, bypassing potential Graphics chain issues. As we use SDI routing, the best 10bit 4:4:4 "Video" results were obtained on this monitor using an SDI to Display Port converter but even so, the combination of above items is not that expensive.

There is really very little difference between sRGB and Rec.709. I'd be surprised if Web Consumers could see the difference. We have set our Studio gamma to 2.4 and yes, maybe our web output could do with gamma 2.2 but we generally put a five second grey scale test pattern up on the head of our web clips. We always Master out of Resolve Uncompressed or better still, a .DPX image sequence then use optimised x264 encoders to convert the DPX Master to high bitrate H.264 (or H.265) for web upload.

Before we installed a Decklink card, our resulting images were all over the place. ie: Too many variables so IMO, if you want critical monitoring, even for the web, you need to eliminate all the variables and a Decklink or 'mini-monitor' at least guarantees you a reliable 'Video' output from a Computer device. Hope this helps!

Thank you! This is extremely helpful.

I have to admit, I was pretty opposed to the idea of adding additional hardware at this early stage, but I am definitely warming to it based on your feedback.

I looked up some specs on my current Eizo. It is "10 bit VA panel with a 12 bit 3D LUT". I am thinking that I can just use this monitor connected to my mac via a BM MiniMonitor. Am I getting that right?

I'm doing some research on the mini monitor. One confusion/hangup I'm having: As a still photographer, one critical part of setting up a color managed workflow was calibrating the monitor via a hardware puck like a Spyder or X-Rite. Am I correct in understanding this would not be part of the process with the mini monitor?

Thanks again for the extremely useful input!

the main benefit of using the graphic card for preview ahould be seen in the simple fact, that resolve usually isn't the only software you use on your machine. in this case it's much more comfortable, if you are able to switch between different applications without any need to change the input selection on your monitors or some other nasty video/audio routing arrangements.

you will not gain any additional color rendition accuracy, just by using a decklink card, as long as your monitor is calibrated and you send an expected video signal. in case of a computer monitor that's usually sRGB. and if you want a reliable color rendition for all of your applications, you simply have to prepare them to use sRGB color values as output (and not rec709!). that's the only really important requirement. it usually can be archived quite easy by some kind of display filters in nearly any useful video software. this kind of adaptation is much more common and compatible, than adaption of proprietary output hardware, which isn't always available -- especially in non-commercial editions of valuable other professional software...

the real hindrance in the case of resolve should be more seen in the fact, that you will not get any acceptable full screen preview (e.g. while editing) without purchasing a decklink card. that's a really unpleasant fact, but there is hardly any solution available to work around this limitation. that's why you will have to buy such a device sooner or later (or change the software), but concerning color rendition accuracy it will not bring any improvement(!), as long as you always configure your software and its display filters in an adequate way.

...the real hindrance in the case of resolve should be more seen in the fact, that you will not get any acceptable full screen preview (e.g. while editing) without purchasing a decklink card. that's a really unpleasant fact, but there is hardly any solution available to work around this limitation. that's why you will have to buy such a device sooner or later (or change the software), but concerning color rendition accuracy it will not bring any improvement(!), as long as you always configure your software and its display filters in an adequate way.

I thought recent editions of Resolve had indeed offered full screen preview (for say, editing on laptops etc) but either way, if Jacob considers Resolve is appropriate software for working with Still images, (we do but our 'Stills' output is entirely web delivered) then BMD's latest 4K 'mini monitor' PCIe card might be a worthwhile investment but he will need to research whether his particular Eizo model will run 10bit 4:4:4 via HDMI input or simply 8bit 4:2:2. Some Eizo users have written that they needed to convert the Decklink's SDI output to Display Port (using a HD Link converter or similar) to achieve the 10bit monitor display they were seeking.

In reference to Video, once we installed a Decklink card, shots I had considered unprofessional due to edge aliasing, noise, crushed blacks, etc, suddenly appeared as I shot them. Now there may have been issues with our original graphics chain setup (Quadro K600 > HDMI > 8bit PC Monitor) but as soon as we configured Decklink SDI > HD Link Display Port converter > calibrated 10bit 4:4:4 Monitor, we finally achieved a clean, stable and reliable Video image.

Jason Myres, a working Colorist and Moderator on the Lift/Gamma/Gain Forum recently explained the difference between 'GPU out' and 'Decklink out' so I will quote his thread to help clarify:

"GPU output (DP/HDMI) and a Decklink/mini monitor card output) ..are two very different things and it goes way beyond whether they are 8 or 10-bit. The first one is a standard graphics card output, the second (Mini Monitor) is a Baseband SDI/ HDMI video output. The difference comes from the fact that one is intended (and modified) to suit a computer display, and the other is a fully legitimate video signal intended for broadcast monitoring. They are two different signal types with different color spaces and signal paths. Don't try to compare them, as they literally have no relation to one another.

In certain cases it's possible for images to "look the same" on both graphics cards and video I/O cards, but they were really designed for two different purposes.

Graphics cards are based around computer signaling standards (VGA, DVI), and are purpose-built to render Graphical User Interfaces and text. They can display video, but that video has to be rasterized, or mapped to the appropriate pixels in your monitor, before it can be displayed. The output from graphics cards is generally limited to legal levels (16-235), which means no full range output (0-255), including sub-blacks and super whites. They also have no sense of interlacing.

Those things, along with any processing being applied by the graphics card, including sharpness, contrast, gamma, or color space adjustments (usually to sRGB), are what generally makes them unuseable for critical viewing. The signal has been embellished, so what you see is not what you get. And, even if you were to try, it's very difficult to completely defeat, especially in OS X.

Video I/O cards are built around SMPTE standards, and are designed for passing unaltered ("baseband"), video signals used in film and broadcast television, in and out of your computer. They are specifically designed not to modify the signal unless you specify it, and when they do it's usually limited to formatting tasks like changing frame rate, frame size, etc. They provide a "proper video signal", which is exactly what you want for critical monitoring."

well -- there would be a lot say about all the misinformation in this last post, but i'm really tired and do not want to elaborate again about all this simply rebuttable claims, which have bin debated and falsified in a plausible manner many times here in the forum.

but it's really a problem, that BMD doesn't just play a questionably game to increase decklink sales figures by artificial limitations in their software, they IMHO also support stupidity and delusion to a great extent by this policy!

I think everything that's said in Jason Myres' quote above holds true with what I know and makes sense to me. I don't see any issues there, certainly no misinformation.

From previously quoted Jason Myers's text:

Graphics cards are based around computer signaling standards (VGA, DVI), and are purpose-built to render Graphical User Interfaces and text. They can display video, but that video has to be rasterized, or mapped to the appropriate pixels in your monitor, before it can be displayed. The output from graphics cards is generally limited to legal levels (16-235), which means no full range output (0-255), including sub-blacks and super whites. They also have no sense of interlacing.

A digital RGB signal being on legal levels is a concept I can't really grasp here. What has video levels got to do with RGB data? The application, Resolve in this case, renders its gui including the preview window in RGB and video displayed there is transformed to RGB before output from graphics card to monitor comes into play. Where exactly would the video levels be re-introduced here?

Btw, if you display a digital video signal on a video monitor that does not have matching resolution, you also have to re-rasterize it if you want anything else than pixel per pixel view.

I think everything that's said in Jason Myres' quote above holds true with what I know and makes sense to me. I don't see any issues there, certainly no misinformation.

marc, you know, how i think about this topic.

i don't deny, that dedicated broadcast output still may make some sense in rare and specialized situations.
if you need SDI connectivity etc. it's simply the most natural choice.

but it's definitely not true, that you can not provide an equally accurate fullscreen preview for video (=moving pictures) related work on a modern high end computer graphic card resp. computer monitor.

most of us do not have any need do output broadcast signals to any external device anymore. what we exchange as final output nowadays, are only files resp. computer data! and proper colors in this files can be proved on different display devices. calibrated computer screens, using sRGB color space referred values on the communication channel, will work just as well and accurate as broadcast monitors and their rec709/bt1886 communication conventions. it's only important, that they really speak the same standard resp. correct and consistent encoding on both sides of the communication channel. in fact, computer monitors will even allow a more precise visual control, because the usually utilize 4:4:4 RGB rendition instead of lossy color subsampled YUV transport, which is more common in the broadcast world.

In reference to Video, once we installed a Decklink card, shots I had considered unprofessional due to edge aliasing, noise, crushed blacks, etc, suddenly appeared as I shot them. Now there may have been issues with our original graphics chain setup (Quadro K600 > HDMI > 8bit PC Monitor) but as soon as we configured Decklink SDI > HD Link Display Port converter > calibrated 10bit 4:4:4 Monitor, we finally achieved a clean, stable and reliable Video image.
...

Just change design in application to deliver "unaltered" signal from GPU and you can forget about this convoluted chains with many converters. It gets obsolete. Todays GPUs with HDMI/DP connections can deliver even more than pro video cards. It was not the case years ago. Mentioned so much YUV signal is just a middle man which is here to save bandwidth and help compression to be more efficient (RGB is more difficult to compresses due to luminance being bound with chrominance). It has not much to do with "proper" video chain. RGB is actually better video chain as it's 4:4:4 and avoid any conversion on the way. RGB pixels from Resolve internal processing are push as is to your monitor. YUV chain is always a double conversion RGB->YUV->RGB which is never 100% losses. It also introduces issue with chroma subsampling.

You are happy with chain with so many conversions (which start and end with RGB anyway), but refuse to acknowledge that this can be simplified to pure RGB chain, which allows even more accuracy and huge "complexity" reduction.
Whole YUV argument is very poor one when it comes to Resolve which works in RGB. You could argue that with some NLEs which operate with YUV you don't want to go to RGB in the middle, but even this becomes almost meaningless as at the end your signal has to be RGB in order to be displayed. Because your preview is just a last step so you actually at the end achieving the same result as with video card (just with less conversions on the way).
If you then use BM card just with HDMI/DP then this this so called "proper YUV video chain over SDI" totally losses its meaning. Exactly the same can be done over HDMI/DP or even more as now we have situation that consumer protocols offer more than pro ones. New HDMI is coming soon with 48GBit/s, where SMPTE is still no where with spec for quad 12G (this been started in 2013!). The only limiting factor for HDMI/DP is cable length, but for home or small studios this is not an issue.
SDI makes sense with bigger installations where signal has to travel longer distances. Even this is going to past as now video over IP is coming which with fibre links allows you to pass video as data over huge distances.
More and moe equipment (monitor/projectors) started to use HDMI or even DP ports as pro protocols are simply outdated and to slow.

If you say that for Resolve user you should stick to BM chain then fine (this is good suggestion, specially for someone who is not very technical), but this is not a "generic" rule. GPU preview can be "proper video" preview and it's not that difficult to achieve these days at all.

To answer original post: when you say inconsistency do you mean when you look at the same content through different means of preview: VLC, QT, different web browsers etc. on the same Eizo monitor?
You will never fully solve it and it's not your fault. If you grading to calibrated Eizo then this is already good thing. You may want to add BM card to avoid possible Resolve GUI "bad" preview. Once you done this not much what else you can do. You can verify if all is good when it comes to conversion chain, by e.g. downloading youtube version of your content and comparing it against original timeline in Resolve. It should look the same (except compression side effects). You will still find that in some players, browsers it looks different, but this is beyond your control.

Just done very plain and quick test.
1. "Use Mac display color profiles for viewers"= deselected.
I've connected my BM Ultrastudio to my Mac HDMI and recorded some bars out of Resolve GUI preview pretending that my BM device is 2nd monitor.
Loaded that file back to Resolve and everything is as it should (perfect alignment in vectroscope) meaning GUI preview over HDMI is accurate.

2. Done same test with "Use Mac display color profiles for viewers" enabled and result is not good.
It means as long as you have this option deselected and have calibrated monitor connected to your machine then there is no reason for GUI preview to be inaccurate.
By not using "Use Mac display color profiles for viewers" preview is no color managed and just pumps pixels out of Resolve internal to the display.

This is just very simple and quick test, so result maybe still somehow misleading. Next step is to try establish what can break accuracy of GUI preview- which OSX settings etc.

Just done very plain and quick test.
1. "Use Mac display color profiles for viewers"= deselected.
I've connected my BM Ultrastudio to my Mac HDMI and recorded some bars out of Resolve GUI preview pretending that my BM device is 2nd monitor.
Loaded that file back to Resolve and everything is as it should (perfect alignment in vectroscope) meaning GUI preview over HDMI is accurate.

that's in fact a very problematic result -- because it testifies, that resolves outputs rec709 data.
and that's not, what your computer screen usually expects... you would see wrong colors on your screen!

2. Done same test with "Use Mac display color profiles for viewers" enabled and result is not good.
It means as long as you have this option deselected and have calibrated monitor connected to your machine then there is no reason for GUI preview to be inaccurate.
By not using "Use Mac display color profiles for viewers" preview is no color managed and just pumps pixels out of Resolve internal to the display.

and what was you system wide resp. screen specific color space setting?
in this case you should be able to choose "rec709" or "sRGB", and in the first case, the output on ultrastudio should be correct again, and the other one should show correct colors on a common computer screen.

(see: https://blog.conradchavez.com/2015/10/2 ... a-support/
"Some of the new profiles can be useful as display profiles when you are certain that a monitor has been hardware-calibrated to a specific video standard, as is often found in video production. For example, if your Mac is connected to a video preview monitor that’s precisely hardware-calibrated to Rec. 709, you can assign the Rec. ITU-R BT.709-5 profile to it using the Displays system preference panel in OS X 10.11 or later.")

i'm not a mac user, so i can just guess... i do not know, if the color managment works sufficient on this particular os in practice...

DPX bars source->see it on my mac screen (regardless correct or not)- record this signal and compare to original bars. If they match then what Resolve sends to screen should be accurate- all what you need now is just calibrated screen. I'm not after auto detection/correction of profiles.
I'm after plain pipe where I know I'm sending Rec.709, I set calibrated screen to Rec.79 and done. If I then want to switch to e.g. sRGB, then I change Resolve setting and preset on my monitor. This is how you do it in studio- you now what you meant to be sending and you just set monitor to match it. Nothing fancy- plain and simple
I just want to check if Resolves GUI preview alters that signal in any way compared to BM card preview.

I have not enough equipment to test it properly

and what was you system wide resp. screen specific color space setting?
in this case you should be able to choose "rec709" or "sRGB", and in the first case, the output on ultrastudio should be correct again, and the other one should show correct colors on a common computer screen.
.

It was BM Ultrastudio own profile which is called HD 709-A.
I'm just trying to establish if Resolve GUI is accurate to source. If I feed BM with bars I know I will get correct bars at the other end. Other question: is there any part of Resolve display engine which affects BM card preview, but is not applied to GUI preview?

I'm after plain pipe where I know I'm sending Rec.709, I set calibrated screen to Rec.79 and done. If I then want to switch to e.g. sRGB, then I change Resolve setting and preset on my monitor.

hmm... i do not agree on this approach.

i think, the resolve project resp. file output settings should be always set to rec709 and not sRGB!
if we play around with this variable, any useful orientation for reliable playback on other devices gets lost!

and if we want to see reliable colors on our computer screen in all applications, we simply have to translate rec709 video data to a more common sRGB colorspace.

sure, reconfiguring your whole system to utilize only rec709 output, would be theoretically also possible. but i don't think, it makes much sense in practice. it's IMHO better to respect the common standards and compatibility requirements of the computer world in equal measure as compliance to standards belonging to the broadcast sphere.

I'm not trying to compensate for my non-Rec.709 screen. I don't care if I see correct image or not.
All what I'm trying to establish is if Resolve GUI preview is the same as BM preview by recoding it and comparing to original source.
Done the same for Scratch and it's HDMI full screen output to 2nd screen is not altered in any way.

@ Andrew Kolakowski & Martin Schitter: I'm sure the O.P was looking for a simple answer but if you two passionate tech-heads can't agree, what hope have the rest of us. Haha!

There is simple answer few posts above

To answer original post: when you say inconsistency do you mean when you look at the same content through different means of preview: VLC, QT, different web browsers etc. on the same Eizo monitor?
You will never fully solve it and it's not your fault. If you grading to calibrated Eizo then this is already good thing. You may want to add BM card to avoid possible Resolve GUI "bad" preview. Once you done this not much what else you can do. You can verify if all is good when it comes to conversion chain, by e.g. downloading youtube version of your content and comparing it against original timeline in Resolve. It should look the same (except compression side effects). You will still find that in some players, browsers it looks different, but this is beyond your control.
Small update:
Big post houses which charge huge money for projects have exactly the same issue. Client comes and says- it looks bad on my Mac laptop- to dark:) It didn't look like this during grading session. Answer is- yes it did, it's the same video. No- it's definitely not the same, there is something wrong with your workflow. No we sure everything is fine. No, it's not looking good. Ok- here is youtube version next to original timeline- do you see - it looks the same on Dolby monitor. Hmm...yes it does. But are you sure this is the same video as on web? Yes we are sure....
Never-ending saga Been there, spent months trying to "solve" it or at least convince clients it's just screen issue. Not so easy

I think everything that's said in Jason Myres' quote above holds true with what I know and makes sense to me. I don't see any issues there, certainly no misinformation.

I agree with Marc's view. There is a lot of confusion about monitoring with Resolve and even though I can get a close match betwwen the Mac display and a calibrated rec709 monitor fed from a BMD mini monitor, the important thing is that Resolve was never designed for accurate display on the computer screen. There are ways to acheive a good result but there is no simple way without having a good technical understanding of the issues that must be addressed.

Yeah i guess thats where the discussion always derails
Yes it is surely technically possible to get any software to output a proper video signal somehow via a standard graphics cards on the monitor if we can land a spaceship on a postage stamp on a comet moving trough space But BM never designed it to be like that and "recommend" you use BM hardware as part of the deal. So the discusion is mute ( around 100 bucks and you are done. Move on). Could they have designed it that way ? Probably as technically everything is possible nowadays beyond bringing back the dead (yet).
So if you want to use Resolve , just use it as it is designed to be used and dont bother trying to find all kinds of hoops to go through to prove your point.
Surely you can drive your car with 4 wheels sideways, but it works better if you use it as designed and spend your precious time elsewhere.

Yeah i guess thats where the discussion always derails
Yes it is surely technically possible to get any software to output a proper video signal somehow via a standard graphics cards on the monitor if we can land a spaceship on a postage stamp on a comet moving trough space But BM never designed it to be like that and "recommend" you use BM hardware as part of the deal. So the discusion is mute ( around 100 bucks and you are done. Move on).

no -- i don't think it's done by this simple approach, because even those ones utilizing decklink cards for their main reference screen will still see incorrect colors on other parts of the operating surface. that's IMHO very unsatisfying and more or less unacceptable if you really care about colors and sensible creative work in this field.

you can not blame other simple video players and web browsers, if they do not realize a more correct color rendition, as long as our beloved professional grade color grading software doesn't do it any better! [wasn't this the topic of this thread?]

and as a matter of fact even very simple player software, like mpv, nowadays comes with all the necessary technical capabilities to realize an adequate color representation on computer screens and on dedicated broadcast output hardware (mpv supports ICC-profiles, display filter LUTs and standard based color space transformation... = the same capabilities as resolve provides). you just have to be aware of the importance of this kind of features and utilize them in practice.

sure -- i understand, that everything looked different in the past. the possibilities were much more restricted and you had to accept some pragmatic compromises. but that's no excuse to do it in an insufficient manner till now resp. refuse any useful improvement over time!

as peter cave pointed out, it is in fact possible to archive a much more satisfying color rendition in resolves GUI viewers by proper configuration. and i'm really appalled, that some users here in this forum don't see the usefulness of this kind of manual fine tuning efforts and sneeringly argue against it. it's bad enough, that resolve doesn't come with more suitable and user friendly default settings/behaviour concerning this grave issues.

no -- it's not enough, that you see just the same colors in your software, if you reimport the data in the same software/setup, it's also necessary, that visible colors correspond to the actual values in your video files and its referred standard color space in a correct and reliable manner. anything else shouldn't be seen as acceptable for serious work in the field of color correction and color related artistic work.

"Resolve isn't designed this way" directly implies to me that there is something wrong in the way Resolve handles color data in chain from GPU to GUI screen. I wonder what it is, that is wrong?

In non-colormanaged YRGB decoded frame is converted from Y'CbCr to RGB using standard formula and if no effects are applied, it is directly drawn to screen. If frame is rec709 (gamut and transfer function) and screen is calibrated to rec709, what exactly fails here? The Y'CbCr conversion, the RGB path from GPU to screen or something else? Can't be the conversion because then dedicated output would be wrong too.

With ACES project, frame is decoded, converted to RGB, IDT is applied and with cc and cct, proper transfer curve is applied. After applying grade and effects, footage is linearized, RRT and ODT are applied and frame is drawn to screen. After applying ODT, frame is in the same state for both GUI and output card output, so having something wrong with GUI implies that path from that RGB buffer in GPU, from which both outputs originate, to screen is somehow distorted. How and why would that happen?

PS. I don't know about Macs, that world is alien to me, but on PC, getting an 8bit ramp of values 0-255 from GPU buffer to standard monitor screen through DVI connection is not rocket science. There are no video levels, clipping or any other futzing applied unless application specifically does it or GPU settings are messed up.

Actualy i even think BM is doing it very smart. They prioritise resources in such a way that whatever happens , gui may be slow , audio behind, bad rez etc, but what comes out of the BM device is proper, in sync etc etc.
For example the new performance setting will drop the viewer rez/quality when needed, but via the BM device you always have proper output. Its smart balancing resource towards what is important.
The viewer is there just for references, for putting your power windows in place etc. It the past i went through hoops to keep the color matching my outboard mon, but actual after seeing it as an example from some top graders, i now put it completely off putting colors. So there is no impulse/mistake to treat that viewer as color accurate but always look at my grading mon.

Its a matter of approach thats all. If you dont want to match the approach of the creators of the software or dont like it, or thik they programmed it wrong, either move to something else or accept it. Otherwise you just drive yourselve mad.
If there is a simple and cheap recommended way, why continue to push for an alternative approach.

Resolve Manual => Processing Pipeline: page 886

We see very well where "Color Page Display LUT" is located through a card BMD => monitor. Nothing for the GUI.

So GUI: nothing certifies that what we see has thoroughly covered all processing Pipeline. That's what I think.

If the workflow does not please: change for other software or accept it.

Actualy i even think BM is doing it very smart. They prioritise resources in such a way that whatever happens , gui may be slow , audio behind, bad rez etc, but what comes out of the BM device is proper, in sync etc etc.
For example the new performance setting will drop the viewer rez/quality when needed, but via the BM device you always have proper output. Its smart balancing resource towards what is important.

Well- if you debayer at half or quarter resolution (silently to manage performance) how suddenly your BM video output be full quality compared to GUI? It won't.
I'm not sure what exactly performance mode does, but it sounds like it just takes control over some settings which use to be up to user to choose. Now it's all automatically- it's as good as bad. At least you can turn off performance mode, but you can't for example assign per source debayering setting which is very annoying. You can only set it on whole project level. BM will have hard time trying to please pro users and "home" users. What works for one group quite often is not what other wants Whole idea of software which works best for home and pro users is a brave one. This debated GUI preview is very good example. Home users would love to have accurate GUI preview without need of buying BM card, where pro not necessarily.
I rather had Resolve with few bits included (like good h264 decoder) for price of e.g. 50$ than have free version.

Home users would love to have accurate GUI preview without need of buying BM card, where pro not necessarily.

no -- i don't think, any serious colorist likes incorrect color rendition anywhere, even if it 'only' affects the GUI.

that's IMHO more the proud enthusiast league, which have to convince everyone, that they use world class professional solution, which a priori can't be plagued by obvious design flaws....

Pros like SDI and don't really use GUI preview. GUI preview could simply not exist for them (which is also some idea).
Martin- you need a trip to some post houses to see how they work.

Hahahahaha, yeah sure indeed. In a post house while grading the next starwars, they look at the gui and think, damn that does not look like our 20.000$ sony grading monitor, lets spend a few weeks to correct that so we can also grade using the GUI.

This thread becomes funnier by the minute.

I rather had Resolve with few bits included (like good h264 decoder) for price of e.g. 50$ than have free version.

But at the same time you think taking the free version + 100$ for a BM mini monitor is too much ?

p.s. x264 is also free btw and you can create the best h264 as humanly possible from your master exported from resolve (a very common workflow as well)

Looking at this forum sometimes , It seems that it does not matter what you give for free. It can be an original thousands of dollars worth of software used to grade hollywood features, it does not matter, there will always be people that are not happy bacause it does not have their standard youtube export preset in there. Or it costs them a single USB port (yeezzzzzzz) You cant win it, even if you are as amazing as BM to give this flagship of a software away for free . Come on pleaseeeeeeeeeeeeee
(going tho throw up now and then enjoy R14 again. I am out of here)

Both Sony BVM and Dolby have HDMI (or DP) ports so can be used with GUI preview if you really want or need. If it's done properly then there is nothing wrong with it.
You didn't get my point.

I rather had Resolve with few bits included (like good h264 decoder) for price of e.g. 50$ than have free version.

But at the same time you think taking the free version + 100$ for a BM mini monitor is too much ?

Yes, but it's limited to HD 30p max.
As as in your own example it did not ended on just BM card. You have: Ultrastudio Mini mon TB SDI > HDlinkPro 6ch audio. This is not 50$ anymore.

At this moment by using pro solution 10it 4:4:4 60p 4K monitoring is basically impossible (as SMPTE is still no where in making final specs for dual/quad 12G SDI). You can do it over 8x 3G SDI, but this is just ridiculous. One DP cable sorts this out- yes it has to be fairly short, but in many case this is fine.
I worked for company where any more interesting project was always hold up by lack of proper pro solutions, but fortunately these days you can sort it by using "home" solutions. This was very different story year ago.

Yes, but it's limited to HD 30p max.
As as in your own example it did not ended on just BM card. You have: Ultrastudio Mini mon TB SDI > HDlinkPro 6ch audio. This is not 50$ anymore.
.

Ah i see you want 4K-6K UHD grading + 6 channel audio mixing (the reason for my HDLinkPro to de-embed 6 chan audio) for 50$ . Now i got it.

It's no secret that BMD subsidizes its software development with hardware sales. It would never be able to provide the Resolve NLE/grading/DAW engine for free, without that support.

Complaining about the trivial cost of output hardware is about the limit in thanklessness. Adobe will be happy to take your monthly subscription and output the GUI to your TV set "for free", if that's what you want.

It's no secret that BMD subsidizes its software development with hardware sales. It would never be able to provide the Resolve NLE/grading/DAW engine for free, without that support.

Complaining about the trivial cost of output hardware is about the limit in thanklessness. Adobe will be happy to take your monthly subscription and output the GUI to your TV set "for free", if that's what you want.

+1

No, no, I do not want to ..

But to be completely honest i am disappointed in Resolve 14 after such a hype that while i am grading it does not make my coffee and some toast, while playing back some live spotify as a welcome distraction.
Also i am going to put in a feature request for direct from my iphone wirelessly load into a new timeline, auto grade and upload to youtube and crossposting on facebook.
Its crappy software that it can not do that for all the zero euros i paid for it .

Did i mention using my iphone screen as grading monitor (wirelessly of course) should be included ?




barf


p.s. Just heard that premiere and fcpx apparently can do all of the above, so now i am really mad at BM

It's no secret that BMD subsidizes its software development with hardware sales. It would never be able to provide the Resolve NLE/grading/DAW engine for free, without that support.

Complaining about the trivial cost of output hardware is about the limit in thanklessness. Adobe will be happy to take your monthly subscription and output the GUI to your TV set "for free", if that's what you want.

I'm not only "not complaining", but I think there should be no free version of Resolve. There could be cheap version 50$ etc. but not free.

Also- I really doubt that sales of hardware which was bought just to be used with Resolve are able to cover cost of Resolve development. Is BM making that huge money when you buy 150$ BM Mini Monitor? Remember that you have to take costs of components, manufacturing etc. out of this. Not that much is left at all.

I'm not only "not complaining", but I think there should be no free version of Resolve. There could be cheap version 50$ etc. but not free.

Even worse. Now we can say "shut up it is free" . If its 50 they say, "hey but why does it not turn my iphone video into the matrix, as i did pay 50 for it "