New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 789181 link

Starred by 2 users

Issue metadata

Status: Closed
Owner:
Last visit > 30 days ago
Closed: Oct 17
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Strong Magenta Cast with Webm Videos in Chrome

Reported by aaron.ga...@nike.com, Nov 28 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36

Example URL:
https://www.nike.com/t/sportswear-tech-fleece-windrunner-mens-full-zip-hoodie-RRT9gXgJ/805144-091

Steps to reproduce the problem:
1. Open URL in Chrome.
2. View the auto-playing/looping product video.
3. Open the URL in Safari.
4. View the auto-playing/looping product video.
5. Compare the two side-by-side.
6. Note that the webm version in Chrome presents a strong magenta cast (most easily noticed in the background coloring).

What is the expected behavior?
Ideally the webm version presents a similar color profile to the mp4 version.

What went wrong?
We had our video delivery vendor on site recently and they did an extensive review of this with their senior devs and image experts and indicated that this color issue is related to the way the browser (in this case Chrome) processes the format, which is interesting since it’s Google’s format and browser. The magenta cast doesn’t show up when you view the webm file itself in the VLC player, for example.

We are seeing the magenta cast primarily in Chrome. We do not see it when viewing the files in VLC, Quicktime, Premiere or in other browsers such as Safari.

Our understanding is that the color difference is rooted to the color management differences between each browser and their support of ICC profiles.

Did this work before? No 

Is it a problem with Flash or HTML5? HTML5

Does this work in other browsers? Yes

Chrome version: 61.0.3163.100  Channel: stable
OS Version: OS X 10.12.6
Flash Version: 

Contents of chrome://gpu: 
Note: To properly save this page, select the "Webpage, Complete" option in the Save File dialog.
Graphics Feature Status
Canvas: Hardware accelerated
CheckerImaging: Disabled
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Multiple Raster Threads: Enabled
Native GpuMemoryBuffers: Hardware accelerated
Rasterization: Hardware accelerated
Video Decode: Hardware accelerated
Video Encode: Hardware accelerated
WebGL: Hardware accelerated
WebGL2: Hardware accelerated
Driver Bug Workarounds
adjust_src_dst_region_for_blitframebuffer
decode_encode_srgb_for_generatemipmap
disable_framebuffer_cmaa
disable_multimonitor_multisampling
get_frag_data_info_bug
msaa_is_slow
pack_parameters_workaround_with_pack_buffer
regenerate_struct_names
remove_invariant_and_centroid_for_essl3
scalarize_vec_and_mat_constructor_args
set_zero_level_before_generating_mipmap
unfold_short_circuit_as_ternary_operation
unpack_alignment_workaround_with_unpack_buffer
use_intermediary_for_copy_texture_image
use_unused_standard_shared_blocks
Problems Detected
Multisampling is buggy on OSX when multiple monitors are connected: 237931
Applied Workarounds: disable_multimonitor_multisampling
Unfold short circuit on Mac OS X: 307751
Applied Workarounds: unfold_short_circuit_as_ternary_operation
Always rewrite vec/mat constructors to be consistent: 398694
Applied Workarounds: scalarize_vec_and_mat_constructor_args
Mac drivers handle struct scopes incorrectly: 403957
Applied Workarounds: regenerate_struct_names
glGenerateMipmap fails if the zero texture level is not set on some Mac drivers: 560499
Applied Workarounds: set_zero_level_before_generating_mipmap
Pack parameters work incorrectly with pack buffer bound: 563714
Applied Workarounds: pack_parameters_workaround_with_pack_buffer
Alignment works incorrectly with unpack buffer bound: 563714
Applied Workarounds: unpack_alignment_workaround_with_unpack_buffer
copyTexImage2D fails when reading from IOSurface on multiple GPU types.: 581777
Applied Workarounds: use_intermediary_for_copy_texture_image
Limited enabling of Chromium GL_INTEL_framebuffer_CMAA: 535198
Applied Workarounds: disable_framebuffer_cmaa
glGetFragData{Location|Index} works incorrectly on Max: 638340
Applied Workarounds: get_frag_data_info_bug
Decode and encode before generateMipmap for srgb format textures on macosx: 634519
Applied Workarounds: decode_encode_srgb_for_generatemipmap
Insert statements to reference all members in unused std140/shared blocks on Mac: 618464
Applied Workarounds: use_unused_standard_shared_blocks
adjust src/dst region if blitting pixels outside read framebuffer on Mac: 644740
Applied Workarounds: adjust_src_dst_region_for_blitframebuffer
Mac driver GL 4.1 requires invariant and centroid to match between shaders: 639760, 641129
Applied Workarounds: remove_invariant_and_centroid_for_essl3
Disable KHR_blend_equation_advanced until cc shaders are updated: 661715
On Intel GPUs MSAA performance is not acceptable for GPU rasterization: 527565, 751919
Applied Workarounds: msaa_is_slow
Checker-imaging has been disabled via finch trial or the command line.
Disabled Features: checker_imaging
Version Information
Data exported	11/28/2017, 9:07:02 AM
Chrome version	Chrome/61.0.3163.100
Operating system	Mac OS X 10.12.6
Software rendering list version	13.10
Driver bug list version	10.29
ANGLE commit id	0d2ecb4ea992
2D graphics backend	Skia/61 0eefc0552cfb5ac077560b7c2630c5bd475ea585-
Command Line	/Applications/Google Chrome.app/Contents/MacOS/Google Chrome -psn_0_73746 --restore-last-session --flag-switches-begin --flag-switches-end
Driver Information
Initialization time	75
In-process GPU	false
Passthrough Command Decoder	false
Supports overlays	false
Sandboxed	true
GPU0	VENDOR = 0x1002, DEVICE= 0x67ef *ACTIVE*
GPU1	VENDOR = 0x8086, DEVICE= 0x191b
Optimus	false
Optimus	false
AMD switchable	true
Driver vendor	
Driver version	1.51.8
Driver date	
Pixel shader version	4.10
Vertex shader version	4.10
Max. MSAA samples	8
Machine model name	MacBookPro
Machine model version	13.3
GL_VENDOR	ATI Technologies Inc.
GL_RENDERER	AMD Radeon Pro 460 OpenGL Engine
GL_VERSION	4.1 ATI-1.51.8
GL_EXTENSIONS	GL_ARB_blend_func_extended GL_ARB_draw_buffers_blend GL_ARB_draw_indirect GL_ARB_ES2_compatibility GL_ARB_explicit_attrib_location GL_ARB_gpu_shader_fp64 GL_ARB_gpu_shader5 GL_ARB_instanced_arrays GL_ARB_internalformat_query GL_ARB_occlusion_query2 GL_ARB_sample_shading GL_ARB_sampler_objects GL_ARB_separate_shader_objects GL_ARB_shader_bit_encoding GL_ARB_shader_subroutine GL_ARB_shading_language_include GL_ARB_tessellation_shader GL_ARB_texture_buffer_object_rgb32 GL_ARB_texture_cube_map_array GL_ARB_texture_gather GL_ARB_texture_query_lod GL_ARB_texture_rgb10_a2ui GL_ARB_texture_storage GL_ARB_texture_swizzle GL_ARB_timer_query GL_ARB_transform_feedback2 GL_ARB_transform_feedback3 GL_ARB_vertex_attrib_64bit GL_ARB_vertex_type_2_10_10_10_rev GL_ARB_viewport_array GL_EXT_debug_label GL_EXT_debug_marker GL_EXT_depth_bounds_test GL_EXT_texture_compression_s3tc GL_EXT_texture_filter_anisotropic GL_EXT_texture_mirror_clamp GL_EXT_texture_sRGB_decode GL_APPLE_client_storage GL_APPLE_container_object_shareable GL_APPLE_flush_render GL_APPLE_object_purgeable GL_APPLE_rgb_422 GL_APPLE_row_bytes GL_APPLE_texture_range GL_ATI_texture_mirror_once GL_NV_texture_barrier
Disabled Extensions	GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent
Window system binding vendor	
Window system binding version	
Window system binding extensions	
Direct rendering	Yes
Reset notification strategy	0x0000
GPU process crash count	0
Compositor Information
Tile Update Mode	Zero-copy
Partial Raster	Enabled
GpuMemoryBuffers Status
ATC	Software only
ATCIA	Software only
DXT1	Software only
DXT5	Software only
ETC1	Software only
R_8	GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT
R_16	Software only
RG_88	Software only
BGR_565	Software only
RGBA_4444	Software only
RGBX_8888	Software only
RGBA_8888	GPU_READ, SCANOUT, SCANOUT_CPU_READ_WRITE
BGRX_8888	GPU_READ, SCANOUT, SCANOUT_CPU_READ_WRITE
BGRA_8888	GPU_READ, SCANOUT, SCANOUT_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT
RGBA_F16	GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT
YVU_420	Software only
YUV_420_BIPLANAR	GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT
UYVY_422	GPU_READ_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE_PERSISTENT

We are currently set to the default VP8 codec, but we're still seeing color issues with VP9 (though they seem to be less pronounced.

VP8(Default)
https://c.static-nike.com/a/videos/q_90/apdmd0mwvrmapvdrw0ag/video.webm

VP9
https://c.static-nike.com/a/videos/vc_vp9/q_90/apdmd0mwvrmapvdrw0ag/video.webm
 
Cc: hubbe@chromium.org ccameron@chromium.org
Labels: Needs-Milestone
Labels: -Needs-Milestone M-61
Owner: hubbe@chromium.org
Status: Assigned (was: Unconfirmed)
As discussed, PTAL.

Comment 4 by hubbe@chromium.org, Dec 7 2017

Some questions:
1) Does this happen on chrome canary as well?
2) Do you have an ICC profile? If so, could you attach it to the bug report?

This same color cast is observed in Chrome Canary as well.

The color profile in the mp4’s we're using is standard HD 1-1-1 (Rec.709).

Comment 6 by hubbe@chromium.org, Dec 8 2017

I was wondering what ICC profile is associated with your output monitor on your computer.


We use a custom preset on our primary monitors. The color calibration settings associated with our Eizo’s is attached titled "Screen Shot 2017-12-08 at 9.17.31 AM"

I've also attached a screen shot of the color profile from my monitor where I'm also observing this issue. That attachment is titled "LG Ultra HD Color Profile".
Screen Shot 2017-12-08 at 9.17.31 AM.png
238 KB View Download
LG Ultra HD Color Profile.jpg
320 KB View Download

Comment 8 by hubbe@chromium.org, Dec 11 2017

Could you attach the actual ICC/ICM files instead of screenshots of the color profile tool?

Also, screen shots of the color changes would be appreciated.

I'm following up on the ICC/ICM files. Here are some screenshots of the color differences we're seeing.

Color difference example 01 & 02 - file viewed in Quicktime on left, Chrome on right.

Color difference example 03 - Safari left, Chrome right (Safari is the more accurate color representation)
Color difference example 01.png
198 KB View Download
Color difference example 02.png
182 KB View Download
Color difference example 03.png
496 KB View Download
Color LCD.icc is typically the default display profile for our Macbooks

CG247X(22508106)_CN_StudioCAL- Custom preset used for our primary color managed monitors in studio which is where all video is qa’d and color validated.
Color LCD-1FBF2F7F-57EC-56E5-521F-556A305D1A61.icc
3.8 KB Download
CG247X(22508106)_CN_StudioCAL.icc
3.8 KB Download

Comment 11 by hubbe@chromium.org, Dec 13 2017

I think there are a few things going on here, but I haven't been able to confirm which one is causing what because I don't have a mac.

However, let me summarize my theories:

Most video players don't actually support any form of color management, but will get some color management automatically from OSX. However, OpenGL apps (like chrome) has to do their own color management.

This video does not have color tags, which means that it's unclear what color primaries and YUV->RGB matrix to use. Some apps will assume bt601, chrome will assume bt709.

I'm not sure why the mp4 file behaves differently. It may be because the video playback is hardware accelerated and goes through a different (not color correct) path in chrome, or it may be because the color tag is different.

If you run this command:

mkvmerge --color-matrix 6 --color-range 1 --color-transfer-characteristics 6 --color-primaries 6 -o video-601.webm video.webm

Does the resulting video-601.webm work better?

Comment 12 by hubbe@chromium.org, Dec 15 2017

Updated command line:  (Run this instead of the previous one, as the previous one didn't actually work.)

mkvmerge --colour-matrix 0:6 --colour-range 0:1 --colour-transfer-characteristics 0:6 --colour-primaries 0:6 -o video-601.webm video.webm

hubbe@ and I checked this locally on my Mac and it's still busted after that command; hubbe@ is looking into it further

Comment 14 by hubbe@chromium.org, Dec 15 2017

I studied the screenshots some more, and I have another theory:

I think Safari plays back video content with a 1.95 gamma (BT601/bt709 transfer function) while chrome uses a 2.2 / sRGB transfer function. Chrome does this intentionally to match what TVs do. (TVs generally use transfer functions very close to gamma 2.2)

If that is the case, the solution is probably to encode and tag the video using the  IEC 61966-2-1 (srgb) transfer function. Assuming that safari pays attention to the tagging, this should make both browsers behave the same.

We will test this on our end.
I'm back from vacation.
How did the tests turn out on your end?

The team that will test this hasn't provided results to me yet. I will get back to this thread when they do.
Status: ExternalDependency (was: Assigned)
Status: Closed (was: ExternalDependency)
No feedback in 6 months, closing bug.

Sign in to add a comment