Color shift in export

the clipping in highlights/lowlights suggest otherwise

In which examples are you referring to Walter? The difference between the Quicktime examples and Premiere/Resolve or the more extreme shifts of VLC and Chrome?

VLC 2.2.3, I edited the last post for clarity: I'm looking at the lower left image..

The gamma looks like a 2.2/2.4 issue but without the actual image I cannot be sure.

VLC 2.2.3, I edited the last post for clarity: I'm looking at the lower left image..

The gamma looks like a 2.2/2.4 issue but without the actual image I cannot be sure.

Unfortunately this one would be of least concern as this only occurs with the out of camera file in VLC, strangely enough it does display my exported files correctly, or at least it matches what I'm seeing in Resolve and Premiere.

does your 'Colour Grading Reel 2015' (which is most excellent by the way!) look the same to you as it does in Resolve when played back in Safari via Vimeo?
"

Thank you! (I like my 2016 one better)

Do they match? No, not really. It's magnified by safari interacting with the colour profile I am using under system prefs / displays. I changed that profile to "Apple RGB" and they looked closer, but still not matched.



However they are much closer when I view the output of an Apple TV playing the file from vimeo on my broadcast monitor over HDMI, with the same file being played through Resolve over SDI (I tried to photograph this for comparison but it proved too tricky - I did manage to photograph the onscreen waveform - not having frame by frame stepping on the apple tv it was hard to match the frames of the video precisely)



Did they match perfectly? No. But considering the different processes the file passed through to get on screen, all with the possibility of lending their own slight interpretation of the image data (the Apple TV OS and how it handles colour rendering, the Apple TV vimeo app, the Apple TV HDMI out hardware, differences between how the monitor handles HDMI and SDI input) I was satisfied with the match.

The human visual perception system is very good at colour comparisons. Put two very slightly different images side by side, and anyone will be able to tell you that they are different. However, show them one after the other, with a a couple seconds of black in between, and even a professional colourist will be hard pressed to identify small differences. Colour memory over time is poor. Colour vision is adaptive. The brain is essentially always white balancing. Combine this with a colourist's passionate and precise understanding of what an image is meant to look like: you will find the small variations your images undergo infuriating. Moreso, you will not realise that this is happening all the time, to every image, because you don't have the same strong sense of what is correct, when viewing other peoples work.

I don't expect colours to match perfectly when comparing the outputs of different programs or delivery mediums or file formats or monitors side by side (within reason, I am still alert for major shifts that indicate serious problems). I do expect a match between different calibrated environments. I do like to standardise and test workflows (file formats and delivery approaches for web services) to ensure I am not adding any error to an already fraught and error inducing process.

I understand the feeling (that all colourists would be familiar with) that "something horrible has happened to my work" is a side effect of having a strong sense of what the image is meant to look like, in a perfect, accurate calibrated environment. I recognise that these shifts are happening to everyones work, even though I can't perceive it, and that its not a technical failing on my part.

I used externally generated colour EBU bars to test the accuracy of my monitor vs the Flanders monitor and quicktime player. Everything matches on a retina iMac as long as I'm careful regarding Data/Video levels on output and check the media pool settings manually upon re-import.

On a Mac it is important to set the gamma correctly when using the Apple display calibration setup in System prefs. Use Option key when selecting Calibrate to access advanced options.

I used externally generated colour EBU bars to test the accuracy of my monitor vs the Flanders monitor and quicktime player. Everything matches on a retina iMac as long as I'm careful regarding Data/Video levels on output and check the media pool settings manually upon re-import.

On a Mac it is important to set the gamma correctly when using the Apple display calibration setup in System prefs. Use Option key when selecting Calibrate to access advanced options.

Hi Peter,

Please can you elaborate a little on that first paragraph.

My colour profile was generated by i1Profiler as opposed to the built in Apple calibration tool. My Gamma appears to be set to the iMac's native 2.2.

Thanks

does your 'Colour Grading Reel 2015' (which is most excellent by the way!) look the same to you as it does in Resolve when played back in Safari via Vimeo?
"

Thank you! (I like my 2016 one better)

Do they match? No, not really. It's magnified by safari interacting with the colour profile I am using under system prefs / displays. I changed that profile to "Apple RGB" and they looked closer, but still not matched.

Thanks Daniel, this is all very reassuring. I'm guessing the Vimeo example you posted was once you had switched your monitor profile as It appears to have increased contrast in Safari compared to your resolve timeline, whereas for me it shifts the other way. With the larger shift of your default/calibrated profile does it increase or decrease in contrast for you?

Just checked out the 2016 reel, very nice work! I love that sequence that start 01:24! Are those practical lights in the effect at the end of that clip or all post?

Just out of curiosity I booted into Windows 7 and had a quick look at Chrome, Firefox and Quicktime.

Interestingly enough under Windows 7 the load/preview screen of Vimeo in both Chrome and Firefox match each other, and while they both shift when you hit play they still match. However, during playback they look even flatter than Quicktime/Safari does in OSX.. the white highlights now appear grey.

And this is all on the same device/display.

https://www.dropbox.com/s/tjos8prn6ieu3 ... s.jpg?dl=0

With the larger shift of your default/calibrated profile does it increase or decrease in contrast for you?

Lower contrast, but also very noticeably yellow! This was using the profile for my EIZO interface monitor. I don't usually worry too much about my interface monitor, it's all about the reference monitor for me. I have the brightness, contrast and saturation turned down pretty low. I've gone as far as using a black and white LUT on the Resolve interface viewer before. Handy for clients who like to do things like compare the interface with reference monitor and ask you to "split the difference!"

Just checked out the 2016 reel, very nice work! I love that sequence that start 01:24! Are those practical lights in the effect at the end of that clip or all post?

From memory it was some practical flare in camera with some post flare and transition work over the top.


Sent from my iPhone using Tapatalk

I used externally generated colour EBU bars to test the accuracy of my monitor vs the Flanders monitor and quicktime player. Everything matches on a retina iMac as long as I'm careful regarding Data/Video levels on output and check the media pool settings manually upon re-import.

On a Mac it is important to set the gamma correctly when using the Apple display calibration setup in System prefs. Use Option key when selecting Calibrate to access advanced options.

Hi Peter,

Please can you elaborate a little on that first paragraph.

My colour profile was generated by i1Profiler as opposed to the built in Apple calibration tool. My Gamma appears to be set to the iMac's native 2.2.

Thanks

I use imported EBU colour bars to do a Resolve output and then re-import into Resolve to do a levels check with the scopes. I render to a variety of formats (QT Prores, QT DNxHD, MXF etc.) to check if there are any differences between original and Resolve rendered files. I also use both video and data levels to do my checks and manually set the range on the source clips in the Resolve media pool. YUV formats are generally decoded as video levels (rec709) so if the files are data range and YUV, they can be interpreted incorrectly if the Resolve setting is left at 'Auto'.

I have a perfect match on all formats.

Even if doing a monitor calibration with 3rd party software and a probe, it is worth trying the HD 709-A colour profile setting in the OSX Displays section of the System prefs. Recent Apple displays are surprisingly accurate with this setup. What will NOT match is if you compare the Resolve viewer with a rendered output using video levels. QT player and some other players will not always interpret the levels correctly and this can create a 'washed out' look, or an apparent gamma shift. There is an older issue of QT gamma shifts, but this is a seperate problem.
The 'Use Mac display profile for viewers' option can be used with the setup I use and it is quite accurate.

What will NOT match is if you compare the Resolve viewer with a rendered output using video levels. QT player and some other players will not always interpret the levels correctly and this can create a 'washed out' look, or an apparent gamma shift. There is an older issue of QT gamma shifts, but this is a seperate problem.
The 'Use Mac display profile for viewers' option can be used with the setup I use and it is quite accurate.

That is interesting Peter, I tried exporting Auto, Video and Full and none of these three matched my Resolve viewer. Auto and Video appeared to be the same in QT so I'm guessing Auto is just choosing video..

With 'Use Mac Display Color..' either checked or unchecked, all three exported files still appear brighter in QT than in Resolve.

Just out of curiosity are you working with H.264 footage? I'm guessing that the YUV import issue won't apply here because the 5D files are already Video/709?

Thanks for your help

What will NOT match is if you compare the Resolve viewer with a rendered output using video levels. QT player and some other players will not always interpret the levels correctly and this can create a 'washed out' look, or an apparent gamma shift. There is an older issue of QT gamma shifts, but this is a seperate problem.
The 'Use Mac display profile for viewers' option can be used with the setup I use and it is quite accurate.

That is interesting Peter, I tried exporting Auto, Video and Full and none of these three matched my Resolve viewer. Auto and Video appeared to be the same in QT so I'm guessing Auto is just choosing video..

With 'Use Mac Display Color..' either checked or unchecked, all three exported files still appear brighter in QT than in Resolve.

Just out of curiosity are you working with H.264 footage? I'm guessing that the YUV import issue won't apply here because the 5D files are already Video/709?

Thanks for your help

As I stated, the Resolve output will not match the Resolve viewer exactly. Rec709 video is gamma 2.4 and most computer screens are sRGB gamma 2.2. It's a complicated issue due to the interpretation of levels by different software and hardware, hence my testing using scopes to be sure that the issue is only a monitoring issue. Having done monitor line-up as part of my training at a national broadcaster, I know how to deal with most calibration issues. If you have a spare 3 months I can provide the same electronic systems training I received! Without a technical understanding of the way video signals and levels work, you really need to trust what the experts are saying on these forums. I have seen too many people jump to conclusions based on a poor understanding of what the technical terms (colour space, video/data range, bit depth etc.) are referring to.

As I work in the broadcast industry I work with these formats; RED RAW, Alexa RAW, Alexa log-c, XDCAM, ProRes 422 & 4444, Avid codecs in MXF & QT, H264, MPEG4, Sony log, Sony RAW, Cineform, and the list goes on.....

The "YUV issue" is not an issue.... it is only that Resolve will mostly interpret YUV codecs as video levels, as that is defined by the rec709 YUV specification. This is normal. What is not normal is H264 and other YUV codecs recording full range levels (Canon 5D and other DSLR style cameras). That is why these types of clips should have the video levels option set manually in the media pool.
The 5D files are Full Range sRGB not Video Range rec709, unless you are using the Magic Lantern hacks.

As I stated, the Resolve output will not match the Resolve viewer exactly. Rec709 video is gamma 2.4 and most computer screens are sRGB gamma 2.2. It's a complicated issue due to the interpretation of levels by different software and hardware, hence my testing using scopes to be sure that the issue is only a monitoring issue. Having done monitor line-up as part of my training at a national broadcaster, I know how to deal with most calibration issues. If you have a spare 3 months I can provide the same electronic systems training I received! Without a technical understanding of the way video signals and levels work, you really need to trust what the experts are saying on these forums. I have seen too many people jump to conclusions based on a poor understanding of what the technical terms (colour space, video/data range, bit depth etc.) are referring to.

As I work in the broadcast industry I work with these formats; RED RAW, Alexa RAW, Alexa log-c, XDCAM, ProRes 422 & 4444, Avid codecs in MXF & QT, H264, MPEG4, Sony log, Sony RAW, Cineform, and the list goes on.....

The "YUV issue" is not an issue.... it is only that Resolve will mostly interpret YUV codecs as video levels, as that is defined by the rec709 YUV specification. This is normal. What is not normal is H264 and other YUV codecs recording full range levels (Canon 5D and other DSLR style cameras). That is why these types of clips should have the video levels option set manually in the media pool.
The 5D files are Full Range sRGB not Video Range rec709, unless you are using the Magic Lantern hacks.

Sorry Peter I must have misread some of your original response, so are you saying then that on the same display it's impossible to get the exported file to match your Resolve viewer?

And for 5D footage I need to manually set video levels on both import and export?

Thanks again

The "YUV issue" is not an issue.... it is only that Resolve will mostly interpret YUV codecs as video levels, as that is defined by the rec709 YUV specification. This is normal. What is not normal is H264 and other YUV codecs recording full range levels (Canon 5D and other DSLR style cameras). That is why these types of clips should have the video levels option set manually in the media pool.
The 5D files are Full Range sRGB not Video Range rec709, unless you are using the Magic Lantern hacks.

Nope, what is not normal is that Resolve or other apps don't read full range flag in h264 files. Full range h264 is perfectly fine and covered by h264 spec. Even if many of these files have full range flag properly set, many software simply don't read this flag and it's up to user to manually overwrite it. It should be easily fixable. When flag is not present or set wrongly then you have to manually adjust it, but for many files it should work automatically. This is "poor coding" on the h264 decoder side.

So in the media pool for h.264 footage I should manually select 'full' as opposed to auto?

Clips with video levels (64 - 940 in 10 bit video) should be set to 'video' in Resolve media pool.
Clips with data levels (0 - 1023 in 10 bit video) should be set to 'full range' in Resolve media pool.
This is done by selecting a group of clips, right click, select 'Clip Attibutes' and setting the levels in the dialog box that is displayed.

Resolve processes all media in 32 bit float RGB full range. If the input clip range is not set correctly, black & white values will not be mapped to 0% & 100% correctly.

Waveform images show correct vs incorrect settings on video range colour bars clip. Note the level difference in the way it's mapped between 0% - 100% luminance. The colour bars have no black bar which is why there is nothing on the waveform scope at 0%.

You should check which levels the media has been recorded with and choose the appropriate option in Resolve.

Video Levels set correctly.png (63.42 KiB) Viewed 5518 times

Video Levels set to full range.png (58.47 KiB) Viewed 5518 times

The "YUV issue" is not an issue.... it is only that Resolve will mostly interpret YUV codecs as video levels, as that is defined by the rec709 YUV specification. This is normal. What is not normal is H264 and other YUV codecs recording full range levels (Canon 5D and other DSLR style cameras). That is why these types of clips should have the video levels option set manually in the media pool.
The 5D files are Full Range sRGB not Video Range rec709, unless you are using the Magic Lantern hacks.

Nope, what is not normal is that Resolve or other apps don't read full range flag in h264 files. Full range h264 is perfectly fine and covered by h264 spec. Even if many of these files have full range flag properly set, many software simply don't read this flag and it's up to user to manually overwrite it. It should be easily fixable. When flag is not present or set wrongly then you have to manually adjust it, but for many files it should work automatically. This is "poor coding" on the h264 decoder side.

Well, yes H264 and almost any other codec can be video or full range by specification. The main issue is that many clips do not have the 'flag' set by the camera. This is not poor decoding but poor encoding by the camera companies. Unfortunately there are media files with no flags, missing flags, incorrect flags and incorrectly decoded flagged files. I've seen it all and had to deal with it. The most important thing for Resolve users is to check & understand what is happening so the correct levels are decoded before grading. In Avid MC one must manually set levels range before importing any media. Fortunately in Resolve it's a simple setting change!

Codecs can hold such a data but many have no defined way of flagging such a case. H264 has, so this can be automatically detected.
Does Resolve read full range flag? I don't think so, neither eg. Premiere does.
Problem is that most people who use Resolve are not technical, so they trust software and assume everything is perfect (in reality hardly ever it's).

Having done monitor line-up as part of my training at a national broadcaster, I know how to deal with most calibration issues.

Peter, you brought me back 25 years in time: I was trained at RAI Italian broadcast for two months when I got hired, and the engineer that trained us was an old gentleman that in his youth was one of the founder of the PAL system. he basically came in add stated "let me show you how we did it"...

yes, 10 years there where a solid background...

So can anyone confirm which levels 5D clips need to be set to when importing in Resolve? And do the same levels need to be applied upon export?

Thanks

Hi Nick, if you just want easy answers, here goes:

Canon 5D standard H264 files should be imported and set to full range or data levels.
Your output choice is entirely up to you and your delivery specification. Most common setups are:

Broadcast = video range (gamma 2.4). Computer displays = data range (gamma 2.2).

There are exceptions to this, which is why understanding the previous posts is important.

Having done monitor line-up as part of my training at a national broadcaster, I know how to deal with most calibration issues.

Peter, you brought me back 25 years in time: I was trained at RAI Italian broadcast for two months when I got hired, and the engineer that trained us was an old gentleman that in his youth was one of the founder of the PAL system. he basically came in add stated "let me show you how we did it"...

yes, 10 years there where a solid background...

We had to train in every department including radio operations. My big moment of revelation was an old audio guy who asked our class to position a microphone on a grand piano. After we all showed our position choices he said, " Not one of you wanted to listen to the instrument before positioning a microphone". Wise words that I will remember. Always apply one's brain to the problem. Never use standard practices until the problem has been assessed properly. Trust your own judgement and challenge your own judgement. No matter how good you are, always strive to improve.

Full vs Auto (render settings)

FULL_AUTO.jpg (976.23 KiB) Viewed 4351 times

Full vs Auto (render settings)

FULL_AUTO.jpg (976.23 KiB) Viewed 4351 times

Tried out a test after reading a lot of this thread and it's been very helpful, thank you! What I've found most revealing, pertaining to the "Quicktime Gamma Shift" issue, is setting the data levels in the render page.

I discovered that setting my project and render settings to "full" produces exactly what I'm seeing on a calibrated grading monitor after rendering via UltraStudio Mini Monitor and has eliminated the issue for me altogether.

I rendered both ProRes 422HQ and H.264 in Auto, Video, Full. And both the ProRes and H.264 look identical color wise in "Full" I'm very happy about this!

The thing is, Resolve defaults to Auto. I also found no difference between Video and Auto.

So, to change this: (Render page-->Video-->Advance Settings-->select Full.)



Curious to hear what others think and hopefully this info is helpful.

(not sure why it attached the top pic twice:)