Inaccurate RGB color display on OS X

Older versions of the VLC 3.0 beta were capable of correctly displaying RGB colors (I'm using one from March 20, 2016). Newer builds seem to have an extra hint of blue for some reason. I am using OS X's built-in utility, Digital Color Meter, to see the native RGB values. Here are some screen shots:

VLC 3.0 current nightly build

VLC 3.0 March 20 nightly

Here are the native values shown:

VLC current nightly

VLC March 20

Can you open the file in question in QuickTime Player and check the colors?

assigned to @fkuehne

added Component::Video: macOS / iOS / tvOS / visionOS label

I tend to avoid QuickTime since it also has issues with colors, and it never displays low resolutions at actual size. That being said, it does still get the colors right (maybe since the codec is rawvideo?). For the record, playing the video in iTunes shows actual size and right colors. Anyway, here is QuickTime.

Can you share the sample file with us? feel free to email me with details at my nickname at videolan.org

Thanks!

I've sent an e-mail with the video and some additional info.

Received. Thanks a lot for your help!

changed milestone to %3.0 FF

Might be related to ticked #17692 (closed)

Original author: galad

I've spend a couples of days on researching this issue, and finally I found:

1. kCVImageBufferColorPrimariesKey may be set incorrectly when decoding from VideoToolbox
2. k​CGColor​Space​ITUR_709 may be not designed for displaying
3. QuickTime/AVFoundation use gamma 1.96 for video

---

Details:

1. VideoToolbox

I'm not sure whether VideoToolbox knows the correct color properties. I'll do more tests. But if we remove the VideoToolbox module, the color will be more close to the correct value.

2. BT.709

BT.709 defines OETF(Opto-Electronic Transfer Function) only, but no EOTF(Electro-Optical Transfer) Function, (because all legacy CRT devices has consistent characteristics). BT.1886 defines a EOTF for matching CRT. Use reverse function of OETF defined in BT.709 for displaying is not correct.

3.QuickTime

On Mac OS X 10.6 and later, the video will be processed by a 1.96 to 2.2 gamma conversion. TN2257 explains why QuickTime/AVFoundation use a value of approximately 1.96 as the gamma of video.

Major References:

1. 1080p Test Pattern MP4 file attached in #17692 (closed)
2. Technical Note TN2257(https://developer.apple.com/library/content/technotes/tn2257)

Replying to [comment:8 Bi11]:

I've spend a couples of days on researching this issue, and finally I found:

1. kCVImageBufferColorPrimariesKey may be set incorrectly when decoding from VideoToolbox
2. k​CGColor​Space​ITUR_709 may be not designed for displaying
3. QuickTime/AVFoundation use gamma 1.96 for video

Very informative.

IMHO, we should start fixing the normal decoding (no VT) behavior.

Also, using MP4 for testing is not a great idea, because of all the information that could be present in it (and not decoded), or at least, not using one created by Apple...

assigned to @tguillem and unassigned @fkuehne

Some more information:

VideoToolbox is guessing the color information, but the guess could be wrong. E.g., VideoToolbox returns following dictionary for test_patten.mp4:

{
    CGColorSpace = "<CGColorSpace 0x6080000359a0> (kCGColorSpaceICCBased; kCGColorSpaceModelRGB; Composite NTSC)";
    CVFieldCount = 1;
    CVImageBufferChromaLocationBottomField = Left;
    CVImageBufferChromaLocationTopField = Left;
    CVImageBufferChromaSubsampling = "4:2:0";
    CVImageBufferColorPrimaries = "SMPTE_C";
    CVImageBufferTransferFunction = "ITU_R_709_2";
    CVImageBufferYCbCrMatrix = "ITU_R_601_4";
    CVPixelAspectRatio =     {
        HorizontalSpacing = 1;
        VerticalSpacing = 1;
    };
    ColorInfoGuessedBy = VideoToolbox;
}

There is a ColorInfoGuessedBy key in the dictionary.

QuickTime may use a profile named HD 709-A for tagging HD video and SD 170M-A for tagging SD video. It has a gamma of 1.961, and produces same result as QuickTime does. The icc files are located in /System/Library/CoreServices/Resources/Profiles/. If there is no such files, try to connect a extern HDTV (not a monitor), the default selected color profile will be HD 709-A in System Preferences.

Beware of system provided Rec. ITU-R BT.2020-1 and Rec. ITU-R BT.709-5 icc profile. The response curve in incorrect. d should be 0.081 instead of 0.018. But if you take a look at /System/Library/CoreServices/Resources/Profiles/HD 709.icc (the profile is not listed in ColorSync Utility), you can see the correct value d as 0.081.

The corresponding colorspaces for video playback can be generated programmatically (e.g. copyColorSpaceWithColorPrimaries in https://github.com/cracksoft/HB/blob/master/macosx/HBCore.m#L364 ). I've tested that the colorspace created by CGColorSpaceCreateCalibratedRGB can be set into CALayer, and results correct (QuickTime like) images. But when I try to set the colorspace to a NSWindow, an assertion was triggered and the application terminated.

Colorspace created CGColorSpaceCreateWithICCProfile can be set to NSWindow. We may create some icc profile with gamma 1.961, like HD709-A.icc, to tagging our render window.

Incorrect ITU.R 709 ICC Profile

Added attachment:

• Screen Shot 2017-04-01 at 2.08.47 AM.png

The ideal place to do the color management might be direct in OpenGL. Changing NSWindow's color space might affect other unrated UI components.

Section 'OpenGL Options for Advanced Color Management' in TN2312 https://developer.apple.com/library/content/technotes/tn2313/_index.html suggested a way, which is used in OS X framework, is using a 3D lookup table.

Thanks again for all this information.

Milestone renamed

Delaying ticket with no assignee

changed milestone to %4.0

This is an unfortunate news. Right now VLC displays almost every video with the wrong color space. If it has to stay so broken in the official 3.0 release maybe it would be better to revert to the vlc 2 behaviour.

Original author: galad