I can't trust DaVinci anymore.

Since last update I have a strange problem.
ProeRes 4444 or HQ rendered in DaVinci opened in QuickTime has a different gamma than it has inside DaVinci. (The picture is lighter and has lower contrast)

I am working on DaVinci since version 8 and I have never saw such a case. I trusted DaVinci in 100%. But now something wrong is happening. I am not sure what I am looking at anymore.

Of course I tried all the settings in Color Managament.

The only solution I found is to set "Use separate Color Space and Gamma and then I use Gamma 2.2 in Timeline Color Space. On the other ones I have 2.4.

But maybe anyone knows what the hell had happened with DaVinci that it changes gamma by itself?
You can take a shot and render it without any grade and the gamma will change.

The problems occured on 3 different projects now - RED Epic, Sony FS7 and Sony F7

I had no such a problems before on previous versions of DaVinci.

I'm skeptical of your testing method, "Opened in QuickTime".

You should only use a calibrated display from a hardware device for quality control purposes. The OS, the GPU driver and even the playback software all can and often do alter the signal. You need to eliminate those variables.

viewtopic.php?f=21&t=68410

What you shouldn't trust is the Quicktime player. 99% of these cases are caused by the media player. Does the file look the same if you bring it back to Resolve and compare it to your timeline?

Do you have a proper viewing environment?
If you bring it back inn resolve, does it look right?

Of course I am using reference monitor with BM card, I made test on it through Premiere Pro, FCP7 outputs, QuickTime and Media Express.
Do not tell me that QT is so bad. I had no problems with it for last 10 years:)

Do you have a proper viewing environment?
If you bring it back inn resolve, does it look right?

If you bring it back it is still different.
It looks like some info about gamma is being embeded or something like that.
It is very strange as I haven't encountered such a problem before in my career and I did over 800 commercials.

There is no gamma info anymore in QT files. This has been deprecated quite a time ago. It's replaced by "colr" atom in QT headers.
"The 'colr' extension supersedes the previously defined 'gama' Image Description extension. Writers of QuickTime files should never write both into an Image Description, and readers of QuickTime files should ignore 'gama' if 'colr' is present."

QT X preview is OSX colour managed, so you will get different view compared to Resolve GUI preview (which is now by default not colour managed).

So your rendered file, brought back and put over original timeline gives you visible difference in Resolve GUI?
It should not.

Thanks. You were right.
I put back the settings in Color Management into DaVinci YRGB and there is no difference as you said.
But the difference is still visible through Premiere Pro both on computer monitor and reference monitor and QT.

I am not convinced to blame QT for it because I had no problems with it before.
But Premiere Pro is more important. I am usally bringing DaVinci renders back to PremierePro for finishing (ProRes4444)

I will check it on Monday at TV station how the MXF's and QT's look like on their screens and let you know.

Do not tell me that QT is so bad. I had no problems with it for last 10 years:)

QT player is the worst and I've only had problems with it for the last 10 years. If you bring the file back into Resolve and it doesn't match then there's something going on with the output. What are your project/color/deliver settings?

Thanks. You were right.
I put back the settings in Color Management into DaVinci YRGB and there is no difference as you said.
But the difference is still visible through Premiere Pro both on computer monitor and reference monitor and QT.

I am not convinced to blame QT for it because I had no problems with it before.
But Premiere Pro is more important. I am usally bringing DaVinci renders back to PremierePro for finishing (ProRes4444)

I will check it on Monday at TV station how the MXF's and QT's look like on their screens and let you know.

Well, it's not easy to say which one is correct- Premiere, QT or Resolve Out of those 3 BM preview is correct
When it comes to GUI preview I more trust Scratch Play as they use OpenGL surface which is totally separated from OSX colour engine.

When you put your masters to Vimeo or Youtube etc it's even less important as it will look very different on people's screens. You either use BM preview on calibrated monitor as reference or not. If you know you want to target e.g. Mac users then it's really up to you to make that decision that you don't care about correct preview but "main target" preview look. I've seen fairly big projects being adjusted to "final Vimeo/Youtube look" as this is where it going to exist. If this is the only place which people going to see it then this preview should be as good as possible (even if it looks not perfect on calibrated monitor). Mac screen in terms of "default look" are very decent- you don't have that much difference. I have old 13inch Mackbook Pro and now new 15 inch one and they are very close (new one is bit colder).

Check your setting:
Resolve/Preferences/System/Hardware Configuration: "Use Mac Display Color Profiles for Viewers"
Make sure it's unselected.

Resolve/Preferences/System/Hardware Configuration: "Use Mac Display Color Profiles for Viewers"

That's a big one. But there are also issues with the ProRes444 container not flagging RGB / linear (Y'CbCr) range correctly. Simply "eyeballing" this issue is not an analysis tool at all. Roundtrip some bars or a grey scale in linear/ or RGB full range and see what that does. Measure the differences with "Scopes."

And it is not wise to continue pursuing Quicktime Player as a valid analysis tool. Just went through this experience recently and converting my client's viewer to "Switch" solved a lot of verification issues.

jPo, CSI

And it is not wise to continue pursuing Quicktime Player as a valid analysis tool. Just went through this experience recently and converting my client's viewer to "Switch" solved a lot of verification issues.

Fair enough, but most clients still use Quicktime for viewing a project on their end. This issue has come up so often that I really feel like Blackmagic should do something to try to address is. At the very least pop-up some alert when rendering to ProRes that informs the user that gamma might look different in Quicktime than it does in Resolve. But fundamentally this really needs to be addressed one way or another (perhaps in the way Resolve encodes Quicktime files).

ProRes private headers have no way of flagging range, neither QT. You have to manually manage this on import/export. If you set it to full on export you have to manually set it to full when you ever import this file back to Resolve.
Resolve always assume video levels in ProRes file and this is regardless of file being 422 or 444.

But fundamentally this really needs to be addressed one way or another (perhaps in the way Resolve encodes Quicktime files).

Resolve encodes QT files properly, there is nothing wrong there, so nothing needs to be addressed.
If anything this is the preview window.

QT X preview is OSX colour managed (so it takes into account 'colr' atom headers), so this is the reason why it looks different than Resolve GUI preview.
What I don't understand is that when you turn on color management for Resolve GUI preview you still can't 100% match the view.

Since last update I have a strange problem.
ProeRes 4444 or HQ rendered in DaVinci opened in QuickTime has a different gamma than it has inside DaVinci. (The picture is lighter and has lower contrast)

I am working on DaVinci since version 8 and I have never saw such a case. I trusted DaVinci in 100%. But now something wrong is happening. I am not sure what I am looking at anymore.

Of course I tried all the settings in Color Managament.

The only solution I found is to set "Use separate Color Space and Gamma and then I use Gamma 2.2 in Timeline Color Space. On the other ones I have 2.4.

But maybe anyone knows what the hell had happened with DaVinci that it changes gamma by itself?
You can take a shot and render it without any grade and the gamma will change.

The problems occured on 3 different projects now - RED Epic, Sony FS7 and Sony F7

I had no such a problems before on previous versions of DaVinci.

Do you checked QuickTime gamma adjustment settings? There few things makes gamma shift

Отправлено с моего PRA-LA1 через Tapatalk

There is no QT "gamma" problem anymore. Old issue where it was really gamma tag is a past and current problems have nothing to do with "gamma" setting itself as there isn't anymore such a thing

Where is this gamma adjust setting? You only have control over data levels full v limited and that's it. For ProRes you should always keep limited as long as you don't have special need to have them full, but then you have to always remember that file is full range and keep manually interpreting it this way.

When you bring 444 back into resolve you have to manually tell it how to interpret the levels. I'm assuming you told it to use data levels when you created the file...so tell it to use data levels when you interpret the file as it returns to resolve. Don't use auto.

Trusting QuickTime over resolve is not the solution. These forums are littered with people having viewing issues in QuickTime. I'm sure some else will be posting a similar question or comment shortly...

It's not about trust
It's about fact that there is no data level flagging in MOV header (neither ProRes private frames header), so Resolve simply doesn't know what was used and it's up to you to set it correctly.

Interestingly enough DNxHR has a special flag for setting data range (AVID defined it) as described here:

https://community.avid.com/forums/t/136517.aspx

and Resolve does write it into MOV headers, but unformtunaltelly BM forgotten to set it properly and always uses value for limited levels

Code: Select all

472C27          Avid Color Sampling Type (24 bytes)
8472C27         Header (8 bytes)
8472C27         Size:                          24 (0x00000018)
8472C2B         Name:                          ACLR
8472C2F         Tag:                            ACLR
8472C33         Version:                        0001
8472C37         YUV range:                      1 (0x00000001)
8472C3B         Reserved:                       0 (0x00000000)


this is for export with Full level set It should be set to 2, but Resolve always writes 1.
This is all not magic, but in most cases simple lack of attention to details.

Surprisingly ffmpeg does set color range flag properly for DNxHR, so it's really all down to how well things are written. This is still not a big deal as Resolve simply won't read it anyway It always assumes limited levels like for ProRes. Loads of coding shortcuts.

Andrew, that seems a error in BM part...

How's your setting in export. auto/data/full or does not matter?

I did some tests on Windows:
If we force Full or Video or Auto in clip attribute:
render in auto or Full or video the flag YUV range is always 1

I tested from TMPGENC that uses the QT kernel:
DNXHR RGB:
YUV range = 2

DNXHR 709:
YUV range = 1

Extraction of the Header with mediaInfo:
Debug => Full Header
Debug => detail 10

Code: Select all

RGB
E6B8A22        Compressor name:                 DNxHR
E6B8A27        Padding:                         (26 bytes)
E6B8A41        Depth:                           24 (0x0018)
E6B8A43        Color table ID:                  65535 (0xFFFF)
E6B8A45        Avid Color Sampling Type (24 bytes)
E6B8A45         Header (8 bytes)
E6B8A45          Size:                          24 (0x00000018)
E6B8A49          Name:                          ACLR
E6B8A4D         Tag:                            ACLR
E6B8A51         Version:                        0001
E6B8A55         YUV range:                      2 (0x00000002)<===========
E6B8A59         Reserved:                       0 (0x00000000)

709
1992C926        Compressor name:                 DNxHR
1992C92B        Padding:                         (26 bytes)
1992C945        Depth:                           24 (0x0018)
1992C947        Color table ID:                  65535 (0xFFFF)
1992C949        Avid Color Sampling Type (24 bytes)
1992C949         Header (8 bytes)
1992C949          Size:                          24 (0x00000018)
1992C94D          Name:                          ACLR
1992C951         Tag:                            ACLR
1992C955         Version:                        0001
1992C959         YUV range:                      1 (0x00000001)<===========
1992C95D         Reserved:                       0 (0x00000000)


Hoping to support the YUV range flag in a future release

Andrew, that seems a error in BM part...

How's your setting in export. auto/data/full or does not matter?

It doesn't matter- Resolve always uses limited flagging and never actually reads this flag either.

Guys, thanks for the great discussion but we missed the point.
Maybe it's my fault. My question was not clear and might confuse some of us.

My setup: iMac 2013 max specification + 2nd Samsung monitor + MacOS 10.12.6 + BM Intensity + reference monitor + Tangent Ripple - Adobe CC are the only updates made in last 2 years.

I work on DaVinci 14 + Premiere Pro / FCP7 / Avid

My inputs are usually RED or Alexa and my outputs are ProRes4444 or DPX (vfx). I use ProRes4444 as a master and make MP4 (YouTube) or MXF (TV) out of it.

I always watch rendered files in some player like QT Pro, QT X or VLC and in my NLE to see it on reference monitor.

This is my home studio but I also work as a freelancer in 2 different post houses. Both of them are using DaVinci 12 and the problem I described above doesn't occur. So I reinstalled version 12 on my computer at home and the problem doesn't exist anymore.
It only happens on DaVinci 14 - and this is the point of discussion.

Some of you like QT some not but it doesn't matter. It is about probably some minor differences in new DaVinci.
I believe that it is connected with Color Management of Timeline. Once I am changing its gamma for 2.2 - my renders are OK. When it is back on 2.4 then brightness of renders goes up. The difference in brightness is small and you might not even see that until you compare it with file rendered i.ex. out of DaVinci 12.

According to Data/Video level. I can check it but in DaVinci 12 it is set on Auto and works fine.

I believe that there is very simple solution for that - some of options' default settings could be changed in new version and it causes the mismatch of my renders.

PS. Comparing the rendered file back in DaVinci is worthless because if DaVinci is changing gamma of my Timeline some how it will do it again with imported file. So they will match whatever the gamma would be.

I hope we can find a solution without telling others that QT, DaVinci sucks and we have to swap for FCPX and so on;)

All the best.

Marek,

Have you tested this on a Mac running 14 and the latest version of iOS? I ask b/c IIRC Mac had changed their "default" gamma setting a few years ago (I could be wrong on this). But it is possible that Resolve has been reconfigured to work properly with newer iOS.

That said, don't upgrade your machines to latest version, as the there is a bug with the Red SDK, High Sierra and some Macs that make Red footage unusable with GPU acceleration.

I do feel your pain, as I went through this with Avid years ago, and was told it's all QuickTime's fault. And maybe it is, but Adobe Media Encoder was able to make QT's that looked correct.

First of all this OLD 'QT gamma' problems is a past now. It doesn't affect 'modern' QT files as there is no anymore gamma tag used. As you said- this has been here for years now.
Whenever people have some preview issue with MOV files they call it "QT gamma" problem. Sorry but this is such a crap. There is no anymore such a thing like QT gamma problem.

There is no Resolve export problem either. Resolve does export correct MOV structure. They may be sometimes not perfect like in case of DNxHR range flagging, but overall Resolve MOVs are correct, specially when we talk about ProRes.

Main current preview discrepancies are due to very different reason. It's all down to the fact that QT X (and all Apple native apps) are color managed and most 3rd party app are not. This became a real issue specially now with new P3 screens. Older Macs with about Rec.709 gamut did not show big difference (only gamma was different) because screen were so close to Rec.709 gamut. Now with P3 native screen gamut it's all very different if preview is color managed or not.

Some of you like QT some not but it doesn't matter. It is about probably some minor differences in new DaVinci.
I believe that it is connected with Color Management of Timeline. Once I am changing its gamma for 2.2 - my renders are OK. When it is back on 2.4 then brightness of renders goes up. The difference in brightness is small and you might not even see that until you compare it with file rendered i.ex. out of DaVinci 12.
.

It has nothing to do with any of the settings you mentioned at all. It's not so called (non-existing anymore) QT gamma issue, nothing to do with export levels etc. It's just what you see and more precisely what Resolve feeds to screen and if there is any adjustment to it or not (managed v. unmanaged viewer).

Resolve preview should match Premiere, VLC, Scratch Play preview as they also unmanaged by color sync. With Scratch Play you can tell what screen you have and in my case when I set file=Rec.709 and screen=P3 D65 (this is what new screen are about) then I have 99% same preview as with QT X.
In Resolve I can simulate this also, by using unmanaged view and adding color space conversion on last node: Rec.709 2.4 (as this is what I'm trying to grade as) to P3 D65 (this is about new Macs native screen). I will also get correct (properly saturated) view, but for whatever reason it's slightly different than QT X or Scratch. This is what I don't get- it should be the same.

Above is exactly the same as if I would try to preview Rec.709 masters on P3 projector over SDI with the difference that I could do it as Monitor LUT, but as far as I understand GUI preview is not managed by those.
This is also what Apple color sync does in case of QT X preview- it takes QT data which is flagged as Rec.709 and converts it to screen (about P3 (D65) gamut), so all looks properly, not crazy oversaturated. In your case it will convert it to something which is very close to Rec.709 as old screens are 'standard' gamut.

QT X preview should be more correct overall and should better match your BM calibrated preview (assuming Mac screen is 99% Rec.709 accurate in your case). Resolve GUI preview (specially when unmanaged) is definitely not correct for every case and in case of P3 screens this is crazy obvious or Rec.709 work.

Your solution is simple (or not)- stop judging things on Apple screen as your GUI preview is inaccurate! It will be about correct (depending how close screen is to Rec.709) only for 1 specific project setting and this is most likely Rec.709 2.2 gamma based.
Hacked worked around is to always have a last node as a conversion from you working color space to Rec.709 2.2 gamma which is there just to give you correct Resolve GUI preview. You have to turn it off for any render!
(maybe there is a way to have this somehow just as a viewer 'LUT').

The same applies to Premiere preview which should perfectly match Resolve (v12 or v14 unmanaged). I've compared it to Scratch Play and both unmanaged previews matched perfectly. Problem starts with new P3 screens where any Rec.709 work is simply impossible without profiling screen to simulate Rec.709 gamut. There are some frustrated Premiere users if you search for this problem. Apple screens as much as great are not pro screens with hardware calibration where you can switch to desired gamut simply by changing monitor/calibration preset.


There is another danger here I think when it comes to actual QT X. It will read file flagging, so most likely it will be Rec.709 (color sync doesn't understand many more video formats), but as we know you can have Rec.709 file made with 2.2. or 2.4 (or even other gamma). QT X won't distinguish between them, so it will always use fixed math for any Rec.709 flagged file. This means only 1 setting will give you good conversion path to screen profile ( I think color sync uses same gamma curve as ITU-R BT.709-5 profile which is 2.22 based).

Whole tagging+ OSX color sync is no near good enough for real world, wild usage. It's far from being robust. To few profiles are specified (not even mentioning HDR files!), 3rd party apps are not color sync aware etc.

I always watch rendered files in some player like QT Pro, QT X or VLC and in my NLE to see it on reference monitor.

This is bad practice. Almost negates whole idea of having reference monitor. If it's not semi decent calibrated screen then this is pointless anyway.

Thanks a lot Andrew!

"Hacked worked around is to always have a last node as a conversion from you working color space to Rec.709 2.2 gamma which is there just to give you correct Resolve GUI preview. You have to turn it off for any render!"

So basically when I am changing Timeline Gamma for 2.2 in Color Management I am doing the same trick. Because this change is only for preview not for render. Am I right?

According to your suggestion that we should watch stuff only on reference - if we work for cinema or TV, then yes. But half of work now goes for YouTube and our clients watch MP4's. So I believe watching renders on other devices is important too. I use for preview reference monitor, standard computer monitor, standard TV, iPad, iPhone and Android device and MacAir but most of all I trust my scopes;)

https://soundcloud.com/mixinglight/mail-bag-ep1-part2

Thanks a lot Andrew!

"Hacked worked around is to always have a last node as a conversion from you working color space to Rec.709 2.2 gamma which is there just to give you correct Resolve GUI preview. You have to turn it off for any render!"

So basically when I am changing Timeline Gamma for 2.2 in Color Management I am doing the same trick. Because this change is only for preview not for render. Am I right?

According to your suggestion that we should watch stuff only on reference - if we work for cinema or TV, then yes. But half of work now goes for YouTube and our clients watch MP4's. So I believe watching renders on other devices is important too. I use for preview reference monitor, standard computer monitor, standard TV, iPad, iPhone and Android device and MacAir but most of all I trust my scopes;)

No- this will be affected o export also (at least by my understanding). Timeline setting is a project setting and changes whole math. Node can be on or off, so it's not exactly the same (only effect is the same). Ideally this should be Viewer setting, like you can do with SDI preview LUT.

Well- this has been debated many times. If project will be basically in 95%+ watched on the web it's your decision to abandon reference look and make it look good on web. Problem with this is that everyone has different screen, so it will look different anyway. If you use reference monitor then at least you are in the middle. If you use your screen which can be for example very blue, then end result will be crazy red for people with good or "red" screens. Reference preview allows you to be in the middle, so it always have it's value. Shadow details are also problematic as Apple screens crush them compared to most other monitors, so you will never please everyone. I spent years at big company fighting with those problems.

https://soundcloud.com/mixinglight/mail-bag-ep1-part2

Well, as you see "reference" monitor is not anymore always used a "main" reference.

They brought an idea about iPad as reference screen and this is not new idea. What is good about it, is that you can't change its view and that they are quite consistent. There were measurements done on many units and they were fairly consistent. They will be 10x more consistent than any other random 10xPC monitors, which will be miles from each other when it comes to default view!

Well if every company which makes monitors done at least decent job with Rec.709 gamut and accuracy then we would not need to have this discussion. Unfortunately this faaaar from true as even some reference monitors are not that "reference", specially by the default

You should also not get into some paranoia about accuracy. If you do projects for web you don't need Dolby or Sony reference monitors. Just use decent ones and calibrate them- this should be good enough. You need to be realistic and match your accuracy to level of your projects- otherwise you maybe simply wasting so much money without any real gain in quality of your work.

I pads are NOT consistent one you actually go down and measure them with the right instrument.

They are not grading monitors. It's about having fairly consistent look, which when you take random 10 PC monitors is all over the place. iPads will be 10x more consistent between different units.
It was done by company which makes high-end grading monitors, not by me

It's not about trust
It's about fact that there is no data level flagging in MOV header (neither ProRes private frames header), so Resolve simply doesn't know what was used and it's up to you to set it correctly.

Interestingly enough DNxHR has a special flag for setting data range (AVID defined it) as described here:

https://community.avid.com/forums/t/136517.aspx

and Resolve does write it into MOV headers, but unformtunaltelly BM forgotten to set it properly and always uses value for limited levels

Code: Select all

472C27          Avid Color Sampling Type (24 bytes)
8472C27         Header (8 bytes)
8472C27         Size:                          24 (0x00000018)
8472C2B         Name:                          ACLR
8472C2F         Tag:                            ACLR
8472C33         Version:                        0001
8472C37         YUV range:                      1 (0x00000001)
8472C3B         Reserved:                       0 (0x00000000)


this is for export with Full level set It should be set to 2, but Resolve always writes 1.
This is all not magic, but in most cases simple lack of attention to details.

Surprisingly ffmpeg does set color range flag properly for DNxHR, so it's really all down to how well things are written. This is still not a big deal as Resolve simply won't read it anyway It always assumes limited levels like for ProRes. Loads of coding shortcuts.

Just to update: Resolve 15b3 has this fixed- it does read color range flag and sets it on export properly as well.

There is still question regarding DNxHR 444 where it's still exported as YUV with limited range by default.
I would rather see it to be RGB with full levels, but not sure what DNxHR spec says.