## Color shift in export

• Author
• Message

Subrata Senn

• Posts: 581
• Joined: Sun Mar 09, 2014 5:22 am
• Location: Kolkata, India
JPOwens wrote:HD Rec709 is scaled 0-100% from values 64-940. Think about what your image would look like if you are viewing one display scaling being interpreted (incorrectly) as the other. If you assigned "black" to be "0", but it is being displayed as "64"... it will appear to be "washed out", or conversely, if "64" is being pushed down to "0", then clipped and/or too contrasty. This also affects the apparent saturation.
jPo

The exact question is not about this. It's the same monitor, with different outputs from Resolve, showing different results.

We understand this Rec 709 and the 0-100% from values 64-940, etc. The question was not about this.

Let's look at it from a "mathematical" point of view. I use this "mathematical" word because many people I find in this forum are very fond of this word.

Forget about the existing standards. Let's say, you have a new colour standard in your monitor which is not Rec 709, sRGB, or SMPTE. You have a new monitor, which does not comply to any of them. But assume, whatever standard is there in your monitor is the new standard. Let's call that "JPOwens" standard. Or call that standard "x", as would be more prudent in algebra (mathematics).

Now look at the colour you see in your Resolve after your final grade. Output in Prores 422 and run the clip in QTplayer. The colours are different.

That was the problem which was being discussed here. How can the same monitor having "JPOwens" colour standard (or "x" if you prefer algebra/mathematics) give different colours while viewing through different softwares? Can't be the problem of the monitor. Because you have used the same mathematical specs in both. So, who is wrong? Resolve? The Prores codec? Or the QT player interpreting the Prores movie?
Independent filmmaker/producer
Owner of post production facility for cinema including grading and creation of DCPs.

waltervolpatto

• Posts: 8132
• Joined: Thu Feb 07, 2013 5:07 pm
• Location: 1146 North Las Palmas Ave. Hollywood, California 90038 USA
Subrata Senn wrote:
JPOwens wrote:HD Rec709 is scaled 0-100% from values 64-940. Think about what your image would look like if you are viewing one display scaling being interpreted (incorrectly) as the other. If you assigned "black" to be "0", but it is being displayed as "64"... it will appear to be "washed out", or conversely, if "64" is being pushed down to "0", then clipped and/or too contrasty. This also affects the apparent saturation.
jPo

The exact question is not about this. It's the same monitor, with different outputs from Resolve, showing different results.

We understand this Rec 709 and the 0-100% from values 64-940, etc. The question was not about this.

Let's look at it from a "mathematical" point of view. I use this "mathematical" word because many people I find in this forum are very fond of this word.

Forget about the existing standards. Let's say, you have a new colour standard in your monitor which is not Rec 709, sRGB, or SMPTE. You have a new monitor, which does not comply to any of them. But assume, whatever standard is there in your monitor is the new standard. Let's call that "JPOwens" standard. Or call that standard "x", as would be more prudent in algebra (mathematics).

Now look at the colour you see in your Resolve after your final grade. Output in Prores 422 and run the clip in QTplayer. The colours are different.

That was the problem which was being discussed here. How can the same monitor having "JPOwens" colour standard (or "x" if you prefer algebra/mathematics) give different colours while viewing through different softwares? Can't be the problem of the monitor. Because you have used the same mathematical specs in both. So, who is wrong? Resolve? The Prores codec? Or the QT player interpreting the Prores movie?

I'm I correct in stating that RESOLVE will show always Data range in the GUI? If so, that could be one of the issues...
C9X299-PGF - DDR4-2400 16x4 GB
i9-7920xCPU 12c 2.90GHz Water cooled
2x 1080ti DeckLink Studio 4K (11.5.1)
W10-1903 - BMR St. 16.2.2.012
nvidia: 441.66 studio

JPOwens

• Posts: 1509
• Joined: Fri Apr 12, 2013 8:04 pm
• Location: Victoria, British Columbia, Canada
Subrata Senn wrote:How can the same monitor [having "JPOwens" colour standard (or "x" if you prefer algebra/mathematics)] give different colours while viewing through different softwares? Can't be the problem of the monitor. Because you have used the same mathematical specs in both. So, who is wrong? Resolve? The Prores codec? Or the QT player interpreting the Prores movie?

Resolve works in float, so it isn't limiting the input source values within the application and its processing.
Its not the monitor, necessarily, although there are obviously modes that will try to place incoming values incorrectly.

There are issues with the ProRes codec, yes - for some time now. Biggest is between ProRes 422 and ProRes4444 and RGB/Y'CbCr ambiguities.
Moreso, there are huge issues with Quicktime, VLC, WMV Player, et al., under the platform's ColorSync, so you can fairly easily load up the same QT file in various player software, and depending on what ColorSync profile has been assigned to it, you will get different values -- much bigger ones if the RGB/Y'CbCr scaling is messed up to begin with. This used to happen with round trips in and out of Apple COLOR, even if you were trying to keep things in "Uncompressed 10-bit" between Final Cut and Media Composer. "COLOR" would correctly interpret the scaling values and then promptly render the incorrect scaling, so that the resulting graded footage would do exactly what was being described in the original post. The fix was to work around the Quicktime container by exporting dpx files, and then converting those to Quicktime movies. The result was always consistently correct with no further intervention other than not rendering directly to Quicktime.

jPo

Subrata Senn

• Posts: 581
• Joined: Sun Mar 09, 2014 5:22 am
• Location: Kolkata, India
waltervolpatto wrote:I'm I correct in stating that RESOLVE will show always Data range in the GUI? If so, that could be one of the issues...

Not true. Video and Data levels change the GUI colour. So does the scope.

JPOwens wrote:
There are issues with the ProRes codec, yes - for some time now. Biggest is between ProRes 422 and ProRes4444 and RGB/Y'CbCr ambiguities.
More so, there are huge issues with Quicktime, VLC, WMV Player, et al., under the platform's ColorSync, so you can fairly easily load up the same QT file in various player software, and depending on what ColorSync profile has been assigned to it, you will get different values -- much bigger ones if the RGB/Y'CbCr scaling is messed up to begin with.
jPo

Yes, I think here lies the problem. QT retains the colour that we see in Resolve if the delivery is done in Prores 4444 in data level. Not in other Prores flavours or H.264.

So, the best way to go is to get the final out from Resolve in Prores 4444 (data level) and then convert to your required format through Compressor.
Independent filmmaker/producer
Owner of post production facility for cinema including grading and creation of DCPs.

Ed Rudolph

• Posts: 143
• Joined: Thu Apr 18, 2013 12:43 am
Subrata said, "the best way to go is to get the final out from Resolve in Prores 4444 (data level) and then convert to your required format through Compressor."

I'd like to hear some comments on this.

waltervolpatto

• Posts: 8132
• Joined: Thu Feb 07, 2013 5:07 pm
• Location: 1146 North Las Palmas Ave. Hollywood, California 90038 USA
jong joug wrote:Since we're not supposed to edit posts I'll give U a short answer.

I'm seeing all these rumors and they are ALL FALSE!
It's not necessary to convert to DPX or Apple ProRes 4444 because Resolve can compress anything with the same colors. The Resolve Deliver Tab is one of the best in the business.

There is no problem with the Resolve GUI and Apple Quicktime, it's just a code 18.

Good to know.

Care to share?
C9X299-PGF - DDR4-2400 16x4 GB
i9-7920xCPU 12c 2.90GHz Water cooled
2x 1080ti DeckLink Studio 4K (11.5.1)
W10-1903 - BMR St. 16.2.2.012
nvidia: 441.66 studio

JPOwens

• Posts: 1509
• Joined: Fri Apr 12, 2013 8:04 pm
• Location: Victoria, British Columbia, Canada
waltervolpatto wrote:Care to share?

That would be out of character if history is any indication, but for what its worth...

"Code 18"... according to "NetLingo"...
Refers to an error made by a user (as in the person who is 18 inches from the screen). It is an expression used by techies in tech support to disguise what they're really saying. For example, "Remember that issue I was working on yesterday morning? Turns out it was a simple code 18."

MacLaren F1 used to clarify unexplained glitches with their race cars (to the press) as having originated "somewhere between the steering wheel and the driver's seat", which is classic Ron-Dennis-speak for describing the same error source.

If I were an unsympathetic person, I would tend to agree somewhat with that assessment, but I am an artisan and realize that some people just don't want to know about the numbers -- unlike an engineer who needs to measure everything, with "tools" -- but likewise is immediately alarmed and can fix the situation because how it usually happens is totally obvious on a waveform.

jPo

waltervolpatto

• Posts: 8132
• Joined: Thu Feb 07, 2013 5:07 pm
• Location: 1146 North Las Palmas Ave. Hollywood, California 90038 USA
JPOwens wrote:
waltervolpatto wrote:Care to share?

That would be out of character if history is any indication, but for what its worth...

"Code 18"... according to "NetLingo"...
Refers to an error made by a user (as in the person who is 18 inches from the screen). It is an expression used by techies in tech support to disguise what they're really saying. For example, "Remember that issue I was working on yesterday morning? Turns out it was a simple code 18."

MacLaren F1 used to clarify unexplained glitches with their race cars (to the press) as having originated "somewhere between the steering wheel and the driver's seat", which is classic Ron-Dennis-speak for describing the same error source.

If I were an unsympathetic person, I would tend to agree somewhat with that assessment, but I am an artisan and realize that some people just don't want to know about the numbers -- unlike an engineer who needs to measure everything, with "tools" -- but likewise is immediately alarmed and can fix the situation because how it usually happens is totally obvious on a waveform.

jPo

I was aware of the "error 18" stuff. JJ has the habit to say stuff like: "It works, you guys do not know how to do it" without substantiate or explain that claim...

So, I take at face figure that JJ knows, and I'm asking very politely to share with the community...
C9X299-PGF - DDR4-2400 16x4 GB
i9-7920xCPU 12c 2.90GHz Water cooled
2x 1080ti DeckLink Studio 4K (11.5.1)
W10-1903 - BMR St. 16.2.2.012
nvidia: 441.66 studio

Lee Gauthier

• Posts: 940
• Joined: Wed Jul 16, 2014 10:51 pm
Subrata Senn wrote:How can the same monitor having "JPOwens" colour standard (or "x" if you prefer algebra/mathematics) give different colours while viewing through different softwares?

Because many software video players have their own color-handling code. Some of them do a better job than others. Have you tried playing the file back using several different apps, including Premiere or FCP? You might be surprised by how many different color interpretations you get.

Subrata Senn

• Posts: 581
• Joined: Sun Mar 09, 2014 5:22 am
• Location: Kolkata, India
Lee Gauthier wrote:Because many software video players have their own color-handling code. Some of them do a better job than others. Have you tried playing the file back using several different apps, including Premiere or FCP? You might be surprised by how many different color interpretations you get.

So true. And it gets confusing. Which colour should be the "correct" colour for deliverables? There lies the question.

Normally, here we need to deliver either all or at least one of the following:

1. DPX or DCP for cinema mastering
2. QT in Prores 422 (HQ) for television viewing. QT files are also needed for some film festivals for Inde films.
3. H.264 QT again for some film festivals for Inde films
4. A QT for web upload.

There is no problem for the deliverable listed at 1. The mastering and distribution labs always do a good job. DCP conversion that I do at my facility using Qubemaster Xport is also accurate.

I face problems with the rest three. I know there is a colour shift in different apps, also in the QT player caused by "Error 18" or whatever. But a viewer is not interested to know. He is interested to see the movie. And I'm interested to show the movie to the audience with its original colour. The colour that I render out in Prores 4444 from Resolve is the closest that I get. Rendering out in Prores 422 (HQ) or H.264 gives a perceptible colour shift. You can check that yourself. Render out from Resolve using these three codecs, run them side by side in the same QT player. The difference is noticeable. And I like the Prores 4444 render because that's so close to what I see in Resolve. Hence I always prefer Prores 4444 when rendering out from Resolve.

Unfortunately, Prores 4444 is not a deliverable codec for television. They need Prores 422 (HQ) or Prores 422. And again, Prores 4444 is not a deliverable codec for the Web. Herein comes the Compressor. I take the Prores 4444 .mov file to Compressor and render out in Prores 422 HQ (for tv) and h.264 (for web). Yes, there is a slight colour shift, but this time it's not so perceptible. So, this workflow works for me.

I am interested to know if you have a better alternative workflow. I am eager to try that.
Independent filmmaker/producer
Owner of post production facility for cinema including grading and creation of DCPs.

Subrata Senn

• Posts: 581
• Joined: Sun Mar 09, 2014 5:22 am
• Location: Kolkata, India
jong joug wrote:exporting h.264, prores 422, and prores 4444 Quicktimes

QTMarch.cube goes to HD/Library/Application Support/Blackmagic Design/Davinci Resolve/LUT
QTMatch.Icc goes to HD/You/Library/ColorSync/Profiles

Apple Quicktime setup:
no change needed

Apple FCPX:
no change needed

Resolve setup:
Project Settings >Master Project Setting >Video Monitoring >Data Levels
Project Settings >Lookup table >3d Color Viewer Look Up Table choose QTMatch.cube
Rendering settings >Video > Video/Data level check Auto

After Effects setup:
Project settings >Color settings >Working space >choose anything like sRGBIEC61966-2.1
View >Simulate Output > Custom Output Simulation > Convert to > check Preserve RGB >Simulate Profile choose QTMatch.icc
Render Quicktime

Photoshop setup:
View >Proof setup > Customize proof Condition > device to simulate choose QTMatch.icc >check Preserve RGB numbers.
Export > Render setting >Quicktime Apple Prores

PremierePro, Flame etc..

This is interesting. Need to try this. Thank you JJ
Independent filmmaker/producer
Owner of post production facility for cinema including grading and creation of DCPs.

waltervolpatto

• Posts: 8132
• Joined: Thu Feb 07, 2013 5:07 pm
• Location: 1146 North Las Palmas Ave. Hollywood, California 90038 USA
jong joug wrote:
JPOwens wrote:
waltervolpatto wrote:Care to share?

That would be out of character if history is any indication, but for what its worth...

"Code 18"... according to "NetLingo"...
Refers to an error made by a user (as in the person who is 18 inches from the screen). It is an expression used by techies in tech support to disguise what they're really saying. For example, "Remember that issue I was working on yesterday morning? Turns out it was a simple code 18."

MacLaren F1 used to clarify unexplained glitches with their race cars (to the press) as having originated "somewhere between the steering wheel and the driver's seat", which is classic Ron-Dennis-speak for describing the same error source.

If I were an unsympathetic person, I would tend to agree somewhat with that assessment, but I am an artisan and realize that some people just don't want to know about the numbers -- unlike an engineer who needs to measure everything, with "tools" -- but likewise is immediately alarmed and can fix the situation because how it usually happens is totally obvious on a waveform.

jPo

+1

QTMatch.cube
QTMatch.Icc

JJ, thanks for the reply, but can you explain me why you post something (that could be useful) and 5 minutes later you delete it?

I just do not understand the reasoning behind it....
C9X299-PGF - DDR4-2400 16x4 GB
i9-7920xCPU 12c 2.90GHz Water cooled
2x 1080ti DeckLink Studio 4K (11.5.1)
W10-1903 - BMR St. 16.2.2.012
nvidia: 441.66 studio

Scott Stacy

• Posts: 938
• Joined: Sun Apr 28, 2013 4:02 pm
• Location: Kansas City
This thread is very interesting and giving me a headache all at the same time. Perhaps, I am more artist than technician. Here is what I wanted guidance on back in my earlier post. I film and color my own work. Here is the workflow I and using and would like to know if I am on the right track instead of guessing and running a million experiments that provide yet additional color-related bafflement:

I shoot BMD raw or Alexa log footage and set source footage as "Data" in the media page. My monitor is 10 bit and I have it set to Rec. 709 color space. Because the source is 10 bit and the monitor is 10 bit, I have been of the assumption to set monitoring to "Data" (wrong? or right?). On the deliver page, I am almost always exporting ProRes 422 HQ (but find it interesting to try and export ProRes 4444) and then am either staying with ProRes 422HQ or using Compressor to generate an x.264 (I think it has a more accurate gamma that h.264) for the web. What should my output be with this workflow? Video or Data. I am assuming video. I am also guessing that the only "data" setting should be for the source material in the media page. So ... "Data" on the media page > Rec. 709 10 bit monitoring > "Data" or "Video" ? > deliver page > "Data" or "Video"?

I greatly appreciate all the professional colorist on the site. Perhaps, someday, I will become more technically capable from a colorist workflow standpoint with assistance from smart folks like you.
Scott Stacy, C.S.I.
scott@hppictures.com
Windows 10 1909
HP Z8
128 RAM 16 HP 8GB DDR4-2666 ECC Registered Memory
2x Intel Xeon Gold 18 Core 6154
2x Gigabyte RTX 2080Ti
4x 2TB NVME M.2 Samsung 970 (RAID10)

JPOwens

• Posts: 1509
• Joined: Fri Apr 12, 2013 8:04 pm
• Location: Victoria, British Columbia, Canada
Scott Stacy wrote:I shoot BMD raw or Alexa log footage and set source footage as "Data" in the media page. My monitor is 10 bit and I have it set to Rec. 709 color space. Because the source is 10 bit and the monitor is 10 bit, I have been of the assumption to set monitoring to "Data" (wrong? or right?)

Wrong. But it might not matter if you are at least grading and exporting it correctly. It has nothing whatsoever to do with 10-bit-edness. Data/Video has everything to do with where the defined 0-100% convention has been agreed to represent the data scaling of 0-1023 or 709 video scaling of 64-940. Where you start is not as critical as where you finish. You could get away with setting data levels on a log source, because it will build in some contrast -- but as you grade, you will re-assign those values anyway -- and as long as you can plainly see where your black and white levels are, within 0-100, you will be fine and dandy. If you are scoping/monitoring in 709 linear, exporting in 709 linear, you should get back what you expect. Everything else is variations in Display Profiles and ColorSync. And ambiguities in how ProRes4444 can carry both, but not necessarily communicate which is which--> Final Cut, for example can't automatically tell the difference.

There are some aviation analogies about flying blind -- Air France found out the hard way, and I expect Air Asia will turn out to be similar. Actually, one of the oldest risks in the book.

jPo

Scott Stacy

• Posts: 938
• Joined: Sun Apr 28, 2013 4:02 pm
• Location: Kansas City
JPOwens wrote:
Scott Stacy wrote:I shoot BMD raw or Alexa log footage and set source footage as "Data" in the media page. My monitor is 10 bit and I have it set to Rec. 709 color space. Because the source is 10 bit and the monitor is 10 bit, I have been of the assumption to set monitoring to "Data" (wrong? or right?)

Wrong. But it might not matter if you are at least grading and exporting it correctly. It has nothing whatsoever to do with 10-bit-edness. Data/Video has everything to do with where the defined 0-100% convention has been agreed to represent the data scaling of 0-1023 or 709 video scaling of 64-940. Where you start is not as critical as where you finish. You could get away with setting data levels on a log source, because it will build in some contrast -- but as you grade, you will re-assign those values anyway -- and as long as you can plainly see where your black and white levels are, within 0-100, you will be fine and dandy. If you are scoping/monitoring in 709 linear, exporting in 709 linear, you should get back what you expect. Everything else is variations in Display Profiles and ColorSync. And ambiguities in how ProRes4444 can carry both, but not necessarily communicate which is which--> Final Cut, for example can't automatically tell the difference.

There are some aviation analogies about flying blind -- Air France found out the hard way, and I expect Air Asia will turn out to be similar. Actually, one of the oldest risks in the book.

jPo

THANK YOU for making things perfectly clear. You have answered my question in a manner that did not go to a compulsive, numerical, mathematical (which is interesting but over my head), convoluted, mildly degrading dissertation. Now, that I have this cleared up, I can focus on beginning to understand more complicated and advance matters. Much appreciated, JP.
Scott Stacy, C.S.I.
scott@hppictures.com
Windows 10 1909
HP Z8
128 RAM 16 HP 8GB DDR4-2666 ECC Registered Memory
2x Intel Xeon Gold 18 Core 6154
2x Gigabyte RTX 2080Ti
4x 2TB NVME M.2 Samsung 970 (RAID10)

Jim Cullen

• Posts: 156
• Joined: Wed Jul 17, 2013 1:11 pm
• Location: Lancashire, England
With respect, a lot of the posts here don't reflect the problem of colour shift seen on the same monitor. I agee with your points below Larry, but we're talking here about the equivalent of listening to audio through the same monitoring system that shifts with different applications on the same system.

Larry Towers wrote:This whole thread is laughable. The visual world is way behind the sound world in understanding reality!

1-if you are not going to purchase a calibrated quality monitor then at the very least invest in a cheap Black magic mini monitor to use with a decent quality reference monitor. This will at the very least take some of the interaction between the OS, the applications, preview windows etc out of the equation. Video is decoded and sent directly to a display bypassing a lot of this interaction.

2-In the audio world we learned long ago that sound will never translate exactly the same on any two devices, even from the same manufacturer. That's why all good sound engineers test their mixes on multiple speakers. This practice should be adopted by visual people too. No matter what you think in theory no two displays will ever match, not for long anyway! More importantly, the biggest factor in this equation is people! Everyone's color perception drifts, far more than the relatively minor color shifts you are seeing on your outputs! And we also automatically white balance! Ambient lighting, what people are wearing, what they ate, even their culture affects color perception.

http://www.bbc.co.uk/programmes/b013c8tb

Don't be so anal retentive about minor color shifts and work to make sure you product translates well to many devices
Jim Cullen

Jim Cullen

• Posts: 156
• Joined: Wed Jul 17, 2013 1:11 pm
• Location: Lancashire, England
Thanks

Dan Finlayson wrote:IMPORTANT UPDATE

I have FINALLY discovered what the problem here is.

The issue revolves around color profiling. The common thread among those of us experiencing these green, washed out exports? We're all using wide gamut displays. Quicktime's color management does not compensate for AdobeRGB or similar wide gamut spaces. DaVinci seems to have some form of color management, but when it comes to wide gamut on OSX, their implementation appears half-assed at best. All my footage in the GUI when using a wide gamut display was over saturated and extra red. This skewed perception led to me letting the footage go a little green.

DaVinci isn't nearly as far off as quicktime is, but its significant.

I've now switched over both my monitors to sRGB and the problem is gone! My green/washed out exports now look identical to what I'm seeing in DaVinci, and this isn't terribly far off from where I thought my corrections were landing. Now that I know that my exports will match my work within the software, it'll be a quick fix.

So try switching over to sRGB on your primary monitors. It's working great for me.

I'd say Apple is mostly at fault here for not adapting to the display technology many artists are switching over to. But DaVinci's color management was definitely over saturating the GUI preview significantly.

Also, this solution isn't great if you use your wide gamut display to its fullest for still image editing on the same machine. And right now I'm running plain old sRGB - not sure what will happen once I recalibrate this monitor, though hopefully with sRGB as my target, things will go smoothly.

It would be great if BM could publish a short white paper titled "DaVinci, Color-Management, Quicktime, and You" because that would have saved me a lot of aggravation.
Jim Cullen

bob parker

• Posts: 4
• Joined: Thu Oct 30, 2014 8:44 pm

bob parker

• Posts: 4
• Joined: Thu Oct 30, 2014 8:44 pm
Anybody?

waltervolpatto

• Posts: 8132
• Joined: Thu Feb 07, 2013 5:07 pm
• Location: 1146 North Las Palmas Ave. Hollywood, California 90038 USA
bob parker wrote:Anybody?

Bob, John John seems to post and delete the posts right after, he/she might be banned for what I know.

edit:
I checked in another thread that I was involved, it seems that he/she got banned and hes/her posts removed.
That will make the second time thou...
RIP JJ...

w.

(welcome to the forum)
C9X299-PGF - DDR4-2400 16x4 GB
i9-7920xCPU 12c 2.90GHz Water cooled
2x 1080ti DeckLink Studio 4K (11.5.1)
W10-1903 - BMR St. 16.2.2.012
nvidia: 441.66 studio

Marc Wielage

• Posts: 6959
• Joined: Fri Oct 18, 2013 2:46 am
• Location: Hollywood, USA
I've said this before: all you can do is consider the destination for the delivery, and include standard SMPTE bars and a gray scale pattern as a test, then export that and see how it winds up in the 422 or H.264 render. Pull up the original 444 and play it side-by-side with the new export. If there is a perceptible difference, it should be possible to come up with a small global tweak (like a Post-Grade setting) that will adjust for it.

I've even done this with YouTube and Vimeo for VPC's (Very Picky Clients), and we've gotten reasonable results that way. At least we know the garbage we're getting out matches the garbage we're sending in.
marc wielage, csi • VP/color & workflow • chroma | hollywood

garrettgibbons

• Posts: 21
• Joined: Mon May 05, 2014 2:00 pm
• Location: Seattle, WA USA
Reading this thread a few years after it started, it's aggravating to see that only the original poster understood the true problem, and everyone else was just ranting about not having 10-bit displays, etc.... Though the information they gave was generally correct and important information, they refused to listen to what he was actually saying.

This issue is definitely a known gamma 1.8/2.2 issue that affects After Effects users frequently. The shift towards green, along with the desaturation, when exporting, is a dead giveaway that it's a color profile problem.
http://garrettgibbons.com

JPOwens

• Posts: 1509
• Joined: Fri Apr 12, 2013 8:04 pm
• Location: Victoria, British Columbia, Canada
garrettgibbons wrote:This issue is definitely a known gamma 1.8/2.2 issue that affects After Effects users frequently.

It is only one of the possible display ambiguities that could be responsible. This is not a single-issue problem.

jPo

Marc Wielage

• Posts: 6959
• Joined: Fri Oct 18, 2013 2:46 am
• Location: Hollywood, USA
JPOwens wrote:It is only one of the possible display ambiguities that could be responsible. This is not a single-issue problem.

I agree with Joe here. Do a Google search on "QuickTime Gamma Shift" or "H.264 Gamma Shift" and you'll get many, many thousands of complaints. This is not a Resolve issue, and it's not entirely a monitor issue -- it sometimes boils down to how a specific player interprets what gamma and color space are within a specific file.

It's for this reason that a show in Vimeo, YouTube, or just as a QuickTime file will often change. The sRGB 1.8 gamma vs. 2.2 Rec709 vs. 2.4 BT1886 gamma settings are also part of it. Things change.

You think it's bad for picture -- I think it's even worse for sound mixers, where they have no idea if their audience is going to listen to their work on an iPhone, through earbuds, on a computer display, or on large full-range speakers. Every one of them doesn't sound as it was intended; all of them are wrong. At least with picture, we have a known standard and can try to stick to that.
marc wielage, csi • VP/color & workflow • chroma | hollywood

Scott Stacy

• Posts: 938
• Joined: Sun Apr 28, 2013 4:02 pm
• Location: Kansas City
A bit off topic, but I find that you have less gamma shift problems when using x.264 for uploading to Vimeo.
Scott Stacy, C.S.I.
scott@hppictures.com
Windows 10 1909
HP Z8
128 RAM 16 HP 8GB DDR4-2666 ECC Registered Memory
2x Intel Xeon Gold 18 Core 6154
2x Gigabyte RTX 2080Ti
4x 2TB NVME M.2 Samsung 970 (RAID10)

David McLaren

• Posts: 3
• Joined: Thu Oct 01, 2015 9:15 pm
Hey Guys, I'm on Resolve 11 its 2015 and yet I'm still getting non matching renders tried all the above data vs video tried all flavours of QT. All encodes from the Qt are also incorrect. Only way the renders looks correct are to pull them back into Resolve. I have expensive calibrated monitors and scopes its not that its not on all outputs it just seems to be on this one project as you can see that is a very specific blue.

PS, To the jobs worth audio engineer earlier in this thread its more like someone messing with your EQ. We are all used to the multitude of platforms and devices in the world. We also except that only a small percentage will ever see/hear our work in its true glory. But I think thats why we have to make sure that what we ouput is as close to our intended work as possible.
Attachments
Screen Shot JPG.jpg (569.45 KiB) Viewed 15225 times

waltervolpatto

• Posts: 8132
• Joined: Thu Feb 07, 2013 5:07 pm
• Location: 1146 North Las Palmas Ave. Hollywood, California 90038 USA
how do you monitor your material?
color space of data?
final deliverable?

we do this for living and if something is wrong 99.9% of the time is a operator issue.

David McLaren wrote:Hey Guys, I'm on Resolve 11 its 2015 and yet I'm still getting non matching renders tried all the above data vs video tried all flavours of QT. All encodes from the Qt are also incorrect. Only way the renders looks correct are to pull them back into Resolve. I have expensive calibrated monitors and scopes its not that its not on all outputs it just seems to be on this one project as you can see that is a very specific blue.

PS, To the jobs worth audio engineer earlier in this thread its more like someone messing with your EQ. We are all used to the multitude of platforms and devices in the world. We also except that only a small percentage will ever see/hear our work in its true glory. But I think thats why we have to make sure that what we ouput is as close to our intended work as possible.
C9X299-PGF - DDR4-2400 16x4 GB
i9-7920xCPU 12c 2.90GHz Water cooled
2x 1080ti DeckLink Studio 4K (11.5.1)
W10-1903 - BMR St. 16.2.2.012
nvidia: 441.66 studio

Ericcgould

• Posts: 4
• Joined: Thu Dec 11, 2014 5:52 am
I do all my work on a MacBook Pro (Retina, 15-inch, Late 2013) and it is incredible frustrating that what I see in the Resolve app does not match my exports. There's got to be a way make them match - other wise it completely devalues Resolve as color correcting tool for me. Doe anyone have a fix that is 100% repeatable.

David McLaren

• Posts: 3
• Joined: Thu Oct 01, 2015 9:15 pm
waltervolpatto wrote:how do you monitor your material?
color space of data?
final deliverable?

we do this for living and if something is wrong 99.9% of the time is a operator issue.

David McLaren wrote:Hey Guys, I'm on Resolve 11 its 2015 and yet I'm still getting non matching renders tried all the above data vs video tried all flavours of QT. All encodes from the Qt are also incorrect. Only way the renders looks correct are to pull them back into Resolve. I have expensive calibrated monitors and scopes its not that its not on all outputs it just seems to be on this one project as you can see that is a very specific blue.

PS, To the jobs worth audio engineer earlier in this thread its more like someone messing with your EQ. We are all used to the multitude of platforms and devices in the world. We also except that only a small percentage will ever see/hear our work in its true glory. But I think thats why we have to make sure that what we ouput is as close to our intended work as possible.

Hey Walter, I usually don't have this type of problem its seems to happen only with certain tones/saturations. I monitor on a calibrated Sony OLED and have confidence from Broadcast, TVC's to DCP's on other projects. This Project is video levels all the way through standard Da Vinci resolve colourspace.
I Also do this for a living and know what i'm doing but I've never encountered a grade that couldn't be replicated in a delivery format before. This isn't user error (famous last words). I've even rendered out DPX (correct no colour shift) Brand new project and tried rendering out a Quicktime no love same result.

waltervolpatto

• Posts: 8132
• Joined: Thu Feb 07, 2013 5:07 pm
• Location: 1146 North Las Palmas Ave. Hollywood, California 90038 USA
yes, do a dpx will be my next suggestion. ..

explain better your pipe and connections.

I usually color looking at a reference monitor/projector, render the final, link that back and play out again in the same monitor: that usually works if the compression is not atrocious.

can you verify that this roundtrip works?
C9X299-PGF - DDR4-2400 16x4 GB
i9-7920xCPU 12c 2.90GHz Water cooled
2x 1080ti DeckLink Studio 4K (11.5.1)
W10-1903 - BMR St. 16.2.2.012
nvidia: 441.66 studio

Andrew Kolakowski

• Posts: 6735
• Joined: Tue Sep 11, 2012 10:20 am
• Location: Poland
Ericcgould wrote:I do all my work on a MacBook Pro (Retina, 15-inch, Late 2013) and it is incredible frustrating that what I see in the Resolve app does not match my exports. There's got to be a way make them match - other wise it completely devalues Resolve as color correcting tool for me. Doe anyone have a fix that is 100% repeatable.

The "correct" look is when you feed SDI out of Resolve to a broadcast monitor. Anything else is "half accurate".
Mac are full of accuracy problems in terms of gamma and black levels. Every Mac display clips shadow details even if you have proper playback software (if you use good external display than this is way better). I've spent days testing it and PCs are miles better for such a task. This is before we start talking about QT/players issues.

Real grading is done to a reference monitor (which later looks dark in shadows due to Apple "creative" displays). If you want video too look good on Mac screen than just grade for the make screen look, but this has not much to do with "real" grading, because it will look very different on all other displays (because yours is far from being reference).

Export to ProRes with Video Levels, make sure file is tagged with color info. Go to File Info and you should have color profile HD (1,1,1), which means Rec.709. Play file with QT X with Mac connected to good external monitor, e.g. NEC or EIZO calibrated to Rec.709 (so in Display settings your color profile is set by the calibration tool) and it should look good.
I quite well matched Eizo monitor to Sony OLED reference, but as I said- things can go very wrong in many places on Mac.

Cliff Secord

• Posts: 124
• Joined: Mon Jul 13, 2015 10:18 pm
Dan Finlayson wrote:I continuously get exports with bad gamma and a color shift out of Resolve 9. I only just got Resolve up and running on this machine (Mac Pro 2010 w/ ATI 5870) since the 10.8.3 update came out - could this be some sort of opencl problem? I saw there was a CUDA update - what about ATI cards?

I've exported h.264, prores 422, and prores 4444 quicktimes (and opened them in both quicktime and VLC) as well as 10 bit RGB DPX sequences and none of them look like the preview in Resolve. Put side-by-side on the same monitor (Dell U2410).

I'm running no LUTs. I've had good experiences with Resolve 8 but this sort of inaccuracy makes 9 unusable at the moment.

Oh man, I went through this fight for a year - here is the problem and the solution. YOU CANNOT under any circumstances use your main monitor to color correct. You also cannot under any circumstances use any monitor to color correct that is not connected by a blackmagic device/card. Doesn't matter if you calibrate your display using Colorman or Spyder, doesn't matter if you have a \$150,000 grading monitor running through the world's greatest video card - unless there is a BlackMagic interface card somewhere in the middle, you are wasting your time. As for CC'ing using your GUI - forget it. You'll never in a million years get the gamma right AND Resolve is not designed to reproduce accurate color in the GUI. You have to use a 2nd 10 bit grading display and you have to use a Backmagic interface/card/box of some sort to output to it. PERIOD.

If you need to do this cheap, the absolute cheapest way you can do it and still have accurate results; get yourself a Decklink Mini and an LG 27EA83 and use the sRGB or Rec 709 pre-sets.
Last edited by Cliff Secord on Thu Oct 08, 2015 7:32 pm, edited 3 times in total.

Andrew Kolakowski

• Posts: 6735
• Joined: Tue Sep 11, 2012 10:20 am
• Location: Poland
David McLaren wrote:Hey Guys, I'm on Resolve 11 its 2015 and yet I'm still getting non matching renders tried all the above data vs video tried all flavours of QT. All encodes from the Qt are also incorrect. Only way the renders looks correct are to pull them back into Resolve. I have expensive calibrated monitors and scopes its not that its not on all outputs it just seems to be on this one project as you can see that is a very specific blue.

PS, To the jobs worth audio engineer earlier in this thread its more like someone messing with your EQ. We are all used to the multitude of platforms and devices in the world. We also except that only a small percentage will ever see/hear our work in its true glory. But I think thats why we have to make sure that what we ouput is as close to our intended work as possible.

You problem is 10bit RGB codec. You video is not decoded properly- has wrong gamma and color space. This ill be down to QT (codec stage-> QT stage). It doesn't mean your video is wrong- it's just the way how QT displays it. If you would output Resolve timeline through SDI to some monitor and than play your RGB 10bit file through BM card to the same monitor they would most likely look the same So your file is most likely fine- it's just how you see it is not Try same video exporting to ProRes (video levels) and play it through QT X.

Ryan Earl

• Posts: 256
• Joined: Sun Jan 17, 2016 6:56 pm
I thought I would post a new reply to this thread after reading it and trying to find a solution to get the Quicktime Player to match the internal viewer of DaVinci Resolve 12.2 when displayed on a 5K iMac and editing shots made in Cinema DNG on the Blackmagic Production Camera.

I have a client located inside the Radio Wave Building in NYC and they were going to use a shot of the exterior as a screen saver for their office computers to that are viewable to their clients when they walk in and out. I chose the Blackmagic Production Camera 4K and Cinema DNG to maximize the dynamic range and detail.

When working professionally I am not doing my own color correcting or editing, usually I hand off the files from the card. This was a rare instance where I was talked into the above shot as an add on to another job for stills, so bringing in extra help wasn't in the budget.

Since their 5K iMac were set at factory default (mine too) I thought I would post the steps to change settings in Resolve to match the Quicktime player since changing their hardware to rec709 wasn't an option.

In Resolve if you load a new project with the default settings, then click over to "Project Settings." In the "Master Project Settings" tab change the "Video/Data Level" from "Video to Data."

Then in the "Color Management" tab change the "Timeline Color Space" from "Rec.709 to sRGB"

At this point you should see an image with less contrast similar to a Quicktime export if you had not changed the default settings.

Then in the Render you can leave settings at default or auto for any Quicktime export.

When you output your file from Resolve to Quicktime - ProRes 422HQ or 4444 you should see a result in Quicktime player that matches your Resolve Viewer. Also when you bring the file back in to Resolve the Waveform will match the original.

Michael Del Papa

• Posts: 159
• Joined: Sun Feb 07, 2016 2:21 am
New Resolve user here and first post. One of the first things I always test in a new tool to get comfortable with it is a lossless workflow. I don't apply any effects. I just want to know if I can process footage through it losslessly or not.

I always start with lossless SMPTE YCbCr (not RGB) color bars. I can round trip losslessly through most programs once I figure out the secret decoder ring. Resolve doesn't seem to be any different.

Resolve imports my color bars fine. They scope up great. There is no color shift.

However, there was an obvious color shift being applied upon export using Uncompressed YUV 422 8-bit. It took me a while unsuccessfully changing various settings before stumbling upon the Export Options setting of Video (64-940). Changing this from Auto to Video eliminated the color shift.

Maybe it is just me, but I find this non-intuitive. My first choice was to change it from Auto to Data (0-1023) which still produced the color shift. Referencing the manual didn't provide any additional insight. Also, the manual strangely calls it Data (4-1019). I am not sure why the manual and the program differ in this regard. Anyway, my color bars are full range, not clamped, and as a result, I would think that I would need to select Data to keep them full range. Not the other way around. Very strange behavior in my opinion.

Bottomline, I have not figured out a truly lossless pathway through Resolve just yet. The color shift disappears when I select Video (vs Auto or Data). However, there are some other minor differences, mostly in the greys, that grow intolerable as I process several generations.

I just thought I'd post my results since this thread seems to be long on "you're doing it wrong" and lite on "try this".

waltervolpatto

• Posts: 8132
• Joined: Thu Feb 07, 2013 5:07 pm
• Location: 1146 North Las Palmas Ave. Hollywood, California 90038 USA
422 is by definition video range. .. [64-940] has been engineered in that way when the digital TV signal and transmission standards where born in the '90 (or '80? my brain is foggy here ). it is a legacy.

(the true only almost lossless workflow is exr half float. ..)
C9X299-PGF - DDR4-2400 16x4 GB
i9-7920xCPU 12c 2.90GHz Water cooled
2x 1080ti DeckLink Studio 4K (11.5.1)
W10-1903 - BMR St. 16.2.2.012
nvidia: 441.66 studio

Andrew Kolakowski

• Posts: 6735
• Joined: Tue Sep 11, 2012 10:20 am
• Location: Poland
Michael Del Papa wrote:
Bottomline, I have not figured out a truly lossless pathway through Resolve just yet. The color shift disappears when I select Video (vs Auto or Data). However, there are some other minor differences, mostly in the greys, that grow intolerable as I process several generations.

I just thought I'd post my results since this thread seems to be long on "you're doing it wrong" and lite on "try this".

There is no problem exporting ProRes in Resolve. Exported file by default is scaled to Video Levels, which is correct (the only debate could be abut ProRes444, which maybe should be full scale by the default).
If you see it differently in QT7/X v Resolve preview than this is all down to the way how each of these players display your file. Problem is with what you see (ProRes YUV data needs to be converted to RGB and sent to the display), not what is stored in the actual file. Play file through some robust chain, good player or SDI card and I'm 99% sure everything will be fine Another test- import exported file back to Resolve and compare there- I bet you it will look the same
Other than this- all Apple screens crush shadow details due to Apple consumer orientated screen profile, so quite often it looks to dark (compared to broadcast monitor).
I went through these with many clients (complaining about fact that their clips look dark on youtube). Some of them had to see downloaded from youtube file on Dolby monitor (against DPX master) to finally understand and believe that it's display problem, not the file! Stop trusting QT7/X/Resolve preview, specially on Apple screens. Get a 100£ BM Mini Monitor and than monitor this way if you want to avoid these debates. Just don't be surprised that it looks differently (darker) on your Mac screen than on broadcast/other monitor/TV QT7 preview on Mac "default" screen is not a reference preview, so don't expect it to look the same!
Also, PC is 10x way more robust playing color accurately files mainly due to many free good players, which respect headers and don't mess things.
Last edited by Andrew Kolakowski on Tue Mar 29, 2016 9:11 pm, edited 4 times in total.

waltervolpatto

• Posts: 8132
• Joined: Thu Feb 07, 2013 5:07 pm
• Location: 1146 North Las Palmas Ave. Hollywood, California 90038 USA
. Get a 100£ BM Mini Monitor and than monitor this way if you want to avoid these debates.

that.
C9X299-PGF - DDR4-2400 16x4 GB
i9-7920xCPU 12c 2.90GHz Water cooled
2x 1080ti DeckLink Studio 4K (11.5.1)
W10-1903 - BMR St. 16.2.2.012
nvidia: 441.66 studio

Paul Willis

• Posts: 198
• Joined: Mon Feb 25, 2013 4:47 pm
Can't emphasise enough that everyone needs to ditch Quicktime, it simply gets it wrong. Most noticeable with gamma, and of course that in turn affects perceived contrast and saturation. Just please use VLC.

VLC playback of ProRes 422 files on my system (exported using video levels) is IDENTICAL to what's shown in the GUI and match my calibrated external monitor. Any colour shifts during Vimeo or Youtube conversion should be minor but acceptable.

There should be no need for LUTs or conversions when rendering, if you're converting gamma to satisfy quicktime you'll end up with something looking too dark when you upload to Vimeo and Youtube as they expect rec709 and play back srgb for computer displays.

Just always turn off 'use mac display profile for viewers' forever, and keeping checking it's off until someone explains why it even exists as a default setting. Don't use any colour management unless you really know what to do with it. Don't work in sRGB or mess with internal gamma. For a standard video workflow this really should be all good.
www.chief.tv
www.paulwilliscolour.com

Andrew Kolakowski

• Posts: 6735
• Joined: Tue Sep 11, 2012 10:20 am
• Location: Poland
Another myth- neither youtube nor Vimeo shifts gamma/black/colors when converting to h264, when ProRes is uploaded (or other common formats). To be safe- it didn't when I tested it few months ago. Download h264 file back, bring to NLE and compare to your master. It's softer, etc, but nothing is shifted in the amount to suggest conversion problem.

Very simple test for those who have broadcast reference monitors. Made a black video with 16 as background and bars at different levels near black (e.g. 12/20/24/28/32 for 8bit YUV levels) and than play it on Mac screen using different players. Do the same, but connect to Mac some external monitor. If you have PC, test it also (with WMP, VLC, Media Player Classic). Compare results- they are very interesting. Mac native screen are the worse, external screen on Mac (depending on player) may be fine, where PC in most cases is fine (fine means close to broadcast monitor look).

Paul Willis

• Posts: 198
• Joined: Mon Feb 25, 2013 4:47 pm
Andrew Kolakowski wrote:Another myth- neither youtube nor Vimeo shifts gamma/black/colors when converting to h264, when ProRes is uploaded (or other common formats). To be safe- it didn't when I tested it few months ago. Download h264 file back, bring to NLE and compare to your master. It's softer, etc, but nothing is shifted in the amount to suggest conversion problem.

You're right that the files aren't changed during conversion. I thought this might be the case, but it seems Vimeo and YouTube appear to play Rec709 as sRGB on playback, remapping legally scaled to full range, just like VLC does on the Mac. It's not a conversion, it's just correctly mapped and played back for computer displays. The files do appear to be left in tact, it just plays them back the way video levels should be played on a computer display.

Again, looking at the same frame on my GUI, VLC AND Vimeo is virtually indistinguishable in terms of contrast and colour when compared on the same display.
www.chief.tv
www.paulwilliscolour.com

DiDi Lin

• Posts: 5
• Joined: Tue Apr 05, 2016 12:13 am
I graded some footage shot in slog3 and colored under DaVinci with ACES. The color seems pretty consistent across media players (VLC and QT) and web browsers (Safari & Chrome). Not sure if anyone out there has experienced similar result?

I shot another project yesterday with Sony Cinegamma and still have the same issue of color shift across media players & browsers.

I wonder what is the reason behind it.

turn off 'use mac display profile for viewers' has no effect for the color shift issue.

philipbowser

• Posts: 16
• Joined: Tue Oct 14, 2014 11:53 pm
I decided to do a test with various settings to see where the gamma shift does and does not happen and what settings are ideal for QT delivery. For this test I rendered out HD SMPTE color bars from Resolve with various settings, opened each in QTx, VLC and back in Resolve again for playback on a computer monitor (typical client viewing experience). I would use my reference monitor to check by eye but was more interested in reading the scopes of each individual color bar in each .mov file to see what was shifting and when. All three softwares, QTx, VLC, and Resolve(GUI Viewer), would show a gamma shift with files that have this problem.

I hope this test is accurate and helpful. If anyone catches something that I’ve done wrong in my testing, I’d really appreciate any advice. To me this makes the most sense to determine how we can “fix” this gamma issue when you watch back rendered QT files on a consumer display using popular video players. I’m also sure this is only specific to Resolve and cannot be applied to any other software.

A quick note: This test has nothing to do with an external reference monitor, everything to do with QTx or VLC playback on a client computer monitor. Most clients don’t have a million dollar color system with a proper reference monitor to watch these files on, it’s usually a crappy computer monitor with QuickTime. Yes their monitors probably won’t be calibrated anywhere near your reference monitor, and they probably don’t have a DeckLink card or equivalent, but that shouldn’t mean they can’t watch a simple .mov file thats interpreting the correct intended gamma. I believe there IS a solution other than saying, “Well, it looks good on my expensive stuff!”

All renders have these default Project Settings:
- DaVinci YRGB Color Science
- Rec.709 Timeline Colorspace
- No output/input/monitor LUTs
- unchecked “Use Mac Display Color Profile for viewers”

ProRes422 (No Gamma Shift)
When I render these settings and playback in QTx, VLC, and Resolve, there is no gamma shift and they match my HD SMPTE bars on the scopes.

Project Settings:
- Video Levels OR Data Levels

Render Settings:
- Video Levels

ProRes422 (Gamma Shift)
Playback in QTx, VLC, and Resolve produce gamma shift (crushed blacks and whites). In Resolve, if I click on clip attributes and manually change levels to Data for the clip (as opposed to the default “Auto” setting), it will look normal, but otherwise the default has a gamma shift.

Project Settings:
- Video Levels OR Data Levels

Render Settings:
- Data Levels

ProRes4444 (No Gamma Shift)
Playback in QTx, VLC, and Resolve has no gamma shift. Scopes match perfectly.

Project Settings:
- Video levels OR Data levels

Render Settings:
- Data Levels

ProRes4444 (Gamma Shift)
Playback in QT, VLC, and Resolve produce gamma shift (raised blacks and lower whites). Manually changing levels to “Video” for the clip attributes in Resolve displays it properly, but QTx and VLC aren’t doing this automatically.

Project Settings:
- Video Levels OR Data Levels

Render Settings:
- Video Levels

So according to this test, if you need to deliver ProRes 422 HQ, set your render settings to “Video Levels”. And if you are delivering in ProRes 4444, set your render settings to “Data Levels”. Setting Data/Video levels in your Project Settings only affects your Display while coloring, it doesn’t alter the final render. The render settings will override whatever your Project Settings are. However you are probably going to want to display in Video levels for Legal Rec 709 delivery otherwise you will be over-correcting on your grade and your ProRes file will have a “gamma shift” from what you were seeing on your monitor.

It would be great if someone else has the time to run a test like this to determine if this is accurate. I don’t fully understand why ProRes 422 HQ and ProRes 4444 would need different settings, but if someone can help me understand the math/science behind that it would be greatly appreciated! I’m assuming because ProRes 422 HQ wants a legal range and ProRes 4444 doesn’t care.

I hope this is a little bit helpful. If this is correct, it really gives me more confidence in my QT renders. My apologies if this is completely wrong and I’m just adding to the confusion!

Cheers,
Philip

waltervolpatto

• Posts: 8132
• Joined: Thu Feb 07, 2013 5:07 pm
• Location: 1146 North Las Palmas Ave. Hollywood, California 90038 USA
a 422 yuv is video level by SMPTE definition. if you fill it with data range I'm expecting to look wrong.

and it is NOT a gamma issue, it is a [video level] vs [data level] issue. if you do scaling with the correct matrice (and is a gain+offset, not a gamma power function) it will look correct.

if you grab one of the "wrong" 422, link it in resolve, flag the clip [data lever] re-export aso [video level] it will fix that issue.
C9X299-PGF - DDR4-2400 16x4 GB
i9-7920xCPU 12c 2.90GHz Water cooled
2x 1080ti DeckLink Studio 4K (11.5.1)
W10-1903 - BMR St. 16.2.2.012
nvidia: 441.66 studio

philipbowser

• Posts: 16
• Joined: Tue Oct 14, 2014 11:53 pm
Thanks for clearing that up Walter.

Am I right in assuming that the ProRes "shift" problem which some people here are experiencing is caused by this data/video levels issue? Is it just wrong vocabulary? Or is there a different problem that people here are experiencing that I'm not following?

I've seen this talked about on other threads being attributed to a "gamma shift" issue. It's good to know that's not how we should talk about it.

waltervolpatto

• Posts: 8132
• Joined: Thu Feb 07, 2013 5:07 pm
• Location: 1146 North Las Palmas Ave. Hollywood, California 90038 USA
philipbowser wrote:Thanks for clearing that up Walter.

Am I right in assuming that the ProRes "shift" problem which some people here are experiencing is caused by this data/video levels issue? Is it just wrong vocabulary? Or is there a different problem that people here are experiencing that I'm not following?

I've seen this talked about on other threads being attributed to a "gamma shift" issue. It's good to know that's not how we should talk about it.

so far every time i saw one of those issues, it was 100% a "scaling" issue, also called [video/full] or [data/head] or else.

i cannot rule out that there could be a colour shift, but in my experience i did not see it yet. i saw a lot of the other. ...

if there a heavy compression, yes, there could be a magenta/green shift. . but being all the same, usually is not a gamma. ..
C9X299-PGF - DDR4-2400 16x4 GB
i9-7920xCPU 12c 2.90GHz Water cooled
2x 1080ti DeckLink Studio 4K (11.5.1)
W10-1903 - BMR St. 16.2.2.012
nvidia: 441.66 studio

philipbowser

• Posts: 16
• Joined: Tue Oct 14, 2014 11:53 pm
Walter! Thank you for finally clearing that up! You don't even understand the peace of mind I have now knowing it's not this mysterious "gamma shift" issue that everyone seems to have different ideas about. So much learning happening. Phew!

It's amazing how I haven't been able to find this explained anywhere quite as simply as that. I now know to be googling for "scaling" or "video/full" information instead of "gamma shift" issues when this happens.

Much appreciated!

John Hansen

• Posts: 1
• Joined: Tue Mar 24, 2015 9:12 pm
Just my two cents on this topic. I spent 12 years in Digital Prepress at a major Publication. We calibrated our monitors practically daily. We used Photoshop. At the time I left we stopped outputting proofs and had been on a completely digital pipeline for a few years. A properly calibrated monitor looked the same in photoshop as it did on the proofs as it did on the press. An improperly calibrated monitor looked a very tiny bit different but you could still tell that the changes you made in the grade were getting output. When I started doing videos for the architectural firm I work for now I found that a grade done in After Effects looked like what I got in QT and looked like what I saw on a bluray or even on a Youtube or Vimeo played for a client. It just did. A render in Resolve looks absolutely zero like what I graded in color. Video level this, data level that. just freaking tell me how to set up my input and output. Put all of those controls that have to do with making what you see during the grade correspond in at least a glancing way with what you get in the render in one place. Explain it all in a simple way (as you can in the publishing business if you aren't a self important prick)(there were at lot of those). So that when I grade a freaking piece of film the program shows me a display during the grade is from the same Universe as what I see after render. Until then it has been nice dipping my toes into this program. But for the non pro level I work at, I like the no nonsense , what you see is what you get of After Effects.

GeoffJohnston

• Posts: 17
• Joined: Wed Aug 12, 2015 11:13 am
Dan Finlayson wrote:IMPORTANT UPDATE

I have FINALLY discovered what the problem here is.

Dan Finlayson wrote:Now that I know that my exports will match my work within the software, it'll be a quick fix.

Quick Fix!?
But, didn't you have to go back and re-do your color correction on all your shots in your entire project just to match it to your now SRGB profile? Or am I missing something?

I mean, it took me a long time to get my skin tones right. Now it's gonna be a nightmare getting them all right again...

Marc Wielage

• Posts: 6959
• Joined: Fri Oct 18, 2013 2:46 am
• Location: Hollywood, USA
John Hansen wrote:A render in Resolve looks absolutely zero like what I graded in color. Video level this, data level that. just freaking tell me how to set up my input and output. Put all of those controls that have to do with making what you see during the grade correspond in at least a glancing way with what you get in the render in one place. Explain it all in a simple way (as you can in the publishing business if you aren't a self important prick)(there were at lot of those).

I am, in fact, a self-important prick but my brother works as a pre-press designer at a big color printing company, so I commiserate.

I often tell people to read p. 690 of the Resolve 12.5 manual: "Limitations When Grading With the Viewer on a Computer Display." This goes into some detail why you cannot accurately monitor directly from the computer and operating system. You have to have a color-managed output, like one from a Blackmagic card, going to a calibrated monitor. Without that, it falls apart very quickly. This has been a fact of life as long as I've been working in the video business (more than 40 years, sadly).

I wish this page was placed earlier in the manual and was stressed more thoroughly, but it's still no less true and is a very standard aspect of post-production.
marc wielage, csi • VP/color & workflow • chroma | hollywood
PreviousNext