Open Bug 455077 Opened 16 years ago Updated 1 month ago

Enable full color_management by default (i.e. set gfx.color_management.mode = 1)

Categories

(Core :: Graphics: Color Management, enhancement, P3)

enhancement

Tracking

()

ASSIGNED

People

(Reporter: glennrp+bmo, Assigned: aosmond)

References

(Depends on 10 open bugs, Blocks 5 open bugs, Regressed 1 open bug, )

Details

(Keywords: dev-doc-needed, DevAdvocacy)

Attachments

(3 files)

Bug #418538 (eanble color_management by default) has been resolved FIXED; however only the "taggedonly" color_management mode has been set by default.  Eventually we should enable full color management (mode 1), to apply color management to untagged elements as well.
Don't we need to move some blocks/depends from bug #418538?
Depends on: 450923
Copying open depends from bug #418538
Depends on: 390697, 427713, 435628, 444659, 454747
Depends on: 75133
Depends on: 455169
Depends on: 449902
Depends on: 454688
Depends on: 460269
I've a problem with color management turned on and don't know if it is covered by any of the existing bugs.

With an older build the value of gfx.color_management.mode is set to 1. Running Firefox the warnings within the Error Console have a greenish yellow background. Even the top bar on the Wiki (http://wiki.mozilla.org/) has the same greenish background.

I made a screenshot of this issue which can be found here:
http://img527.imageshack.us/my.php?image=bild2xp2.png

Probably the mentioned colors will appear yellow to you. That also happens for me when I move the window from my external monitor to the MacBook one. Both have different color profiles and were calibrated 3 weeks ago by a professional tool. So do we have problems when using a multi-monitor setup?

Opening the above image with Firefox 3.0.4pre shows the same greenish color. But opening the Error Console and the Wiki with that build, the color is yellow. If I set gfx.color_management.mode to 2 (reset the value) it's also fine with the latest Firefox 3.1 nightly build.

Is it somehow known and already covered? Or should I file a new bug on that?
see bug 450923 comment #12

It seems that some monitors ship with poor ICC profiles driver on windows.
FWIW I'm on OS X 10.5. And this thing is only visible for Firefox. Other applications with color profile support e.g. Lightroom don't suffer from that.
Henrik -

We don't currently do very much to handle multiple monitors - we use whichever profile the system gives us and leave it at that. Vlad says that most apps really don't deal with this case at all, but I don't know about lightroom.

The thing with the yellows turning green should not happen on a default build from trunk - since we only color correct tagged images, there should be no color correction applied to the background of the download manager.
Attached image Yellow Green cast
Henrik, you mean like attachment above?


The left image has colour management enabled, right does not.

(In reply to comment #3)
Henrick -

cl just pointed out that this sounds suspiciously like bug 439704 where we were swapping color channels on big endian platforms. Would this platform happen to be ppc?
(In reply to comment #3)
 
> With an older build the value of gfx.color_management.mode is set to 1.

I don't have a preference gfx.color_management.mode in about:config. What is this preference again? I have a vague memory of it.


> Running Firefox the warnings within the Error Console have a greenish 
> yellow background.

For me, it appears reddish yellow (manilla folder yellow) 3.03 regardless of gfx.color_management.enabled is true or false.



> I made a screenshot of this issue which can be found here:
> http://img527.imageshack.us/my.php?image=bild2xp2.png


The profile embedded in this image is "Monitor_12.09.208_2.icc". So the CMS in FF is performing display compensation only on that display. Colors should look correct, on that display.

There are some peculiarities with this profile, however:

1. The primaries are a bit odd for an external display. I'm guessing that you're using an i1 Display, or i1 Display 2 and Eye One Match. Is this MacBook using an LED backlight?

If so, this colorimeter cannot correctly calibrate or profile this display. Its calibration matrix is predicated on CCFL as a backlight source, not LED. We're kinda in a bit of a train wreck with respect to these displays, as I'm unconvinced that the primaries reported by the display itself are correct either.

2. Luminance of the display is quite good, 140 cd/m^2, but I'm suspicious of this because a.) laptops normally aren't this bright; b.) the vcgt tag in the profile indicates a very aggressive and inappropriate curve has been applied to the video card look-up table to reduce the luminance of the display. Make sure you're using the latest and greatest version of the software, and start over from scratch. Make sure you're targeting an appropriate white luminance. If it's too high, you're going to kill the display luminance in a short amount of time. It's best to reduce the brightness of the display and the ambient environment, so that you have headroom to maintain consistent brightness as the display ages. For laptops, 100 cd/m^2 is OK, you may want to go a bit lower, but not lower than 80cd/m^2 for more color discerning applications.

I would like to know what software application and version number made this display profile. Feel free to forward this to me off line.

3. The tone reproduction curve of the display is set to gamma 2.3. This is not ideal for an Apple display. For Apple branded displays I'd suggest you use a gamma of 1.8 just because they seem to perform better with that TRC. You could use gamma 2.2. But I would steer you away from 2.3. It's probably minor but it just makes the video LUT curves more aggressive, and losing levels as a result.

4. The display appears to be very blue in its uncalibrated state. And it's being calibrated to 5000K or D50. I'd recommend backing off on that a bit, but I don't know your particular workflow. I think 5500K would require less aggressive display correction (obviously D65 or 6500K would require even less; but again, I'm not sure of your application).


> Probably the mentioned colors will appear yellow to you. That also happens for
> me when I move the window from my external monitor to the MacBook one. Both
> have different color profiles and were calibrated 3 weeks ago by a professional
> tool. So do we have problems when using a multi-monitor setup?

Unfortunately I don't think any apps get dual display color management for free, so a web site is only going to look correct on one display. By default I would expect this to be the primary display.

Chris Murphy
(In reply to comment #8)
> Henrik, you mean like attachment above?
> 
> The left image has colour management enabled, right does not.

Yes, that's exactly what I see with my trunk build and having set the gfx mode to 1.

(In reply to comment #9)
> cl just pointed out that this sounds suspiciously like bug 439704 where we were
> swapping color channels on big endian platforms. Would this platform happen to
> be ppc?

Bobby, no I'm on Intel and don't have a PPC platform.

Chris, thanks for your great comment. I'll contact you separately, so we don't spam this bug.
Depends on: 460629
No longer depends on: 460629
Depends on: 450520
Depends on: 460520
No longer depends on: 450520
Depends on: 466776
Component: GFX → GFX: Color Management
QA Contact: general → color-management
Target Milestone: Future → ---
Attached image untagged
BUMP...

What's the status on changing "gfx.color_management.mode" to "1" (all rendered graphics) from "2" (only tagged graphics)?

I'm working on gfx.color_management.mode = 1, for years and didn't have any problem with it.

Also gfx.color_management.mode = "1" aligns with the interpretations of the W3C recommendations that untagged images should assumed to be in the sRGB color space.
But today only Firefox doesn't use CMS for all rendered graphics.
So all other page elements and untagged images are rendered on the full monitor color gamut with inaccurate and over-saturated colors, specially on wide gamut displays.

image is from this site http://www.metalvortex.com/blog/2011/08/21/643.html
more info here http://cameratico.com/guides/firefox-color-management/
In reply to Virtual_ManPL [:Virtual] from comment #14)
> But today only Firefox doesn't use CMS for all rendered graphics.

I'm not sure what other web browsers you're referring to. Safari and Chrome do not assume sRGB for untagged images, they simply send the document's RGB values through the system untransformed. Neither Chrome nor Safari even have an option equivalent to FF mode 1 whereby untagged images are assumed to be sRGB, and are transformed to Display RGB.
I'm not the specialist here, but look on attachment I added. It's from site http://www.metalvortex.com/blog/2011/08/21/643.html and only Firefox have not enabled CMS for all rendered graphics or maybe I'm wrong understand description there... ;p
The article is showing untagged images in various web browsers, with FireFox's color management enabled (mode 1) causing the woman to look sensible, while all other browsers do not color manage the untagged image and therefore she looks over saturated. The oversaturation is expected on wide gamut displays.
Ahhhh, so I understand wrongly... reading multiple times this article seems you're right!
So this is another positive aspect to change "gfx.color_management.mode" to "1" :)
(In reply to Virtual_ManPL [:Virtual] from comment #18)

Well, it's a bit tricky because it can't color manage plug-in content. And most plug-ins aren't color managed. Even by default Flash isn't, although there are tags to cause it to assume sRGB for its content. If FF color manages by default but Flash doesn't, then you get a discrepancy in content, that's really obvious if the content are immediately adjacent to each other.

And it would lead to a lot of user confusion when they see the inevitable discrepancies between browsers. So it'd take a concerted effort of web content creator and user education to adjust expectations.
(In reply to Chris Murphy from comment #19)
> (In reply to Virtual_ManPL [:Virtual] from comment #18)
> 
> Well, it's a bit tricky because it can't color manage plug-in content. And
> most plug-ins aren't color managed. Even by default Flash isn't, although
> there are tags to cause it to assume sRGB for its content. If FF color
> manages by default but Flash doesn't, then you get a discrepancy in content,
> that's really obvious if the content are immediately adjacent to each other.

This reasoning sounds a lot like that which might have inspired the old saying "the perfect is the enemy of the good".
(In reply to Chris Lawson from comment #20)
More like merely a catch-22. I don't mean to indicate that mode 1 is perfection or even extreme. I actually think it's reasonable. It just comes with other consequences and I can't say how people will react to this. Without that mode, however, our display technologies continue to diverge from sRGB.
Right, that's exactly my point: there currently exists a solution that is probably good *enough* for most users and use-cases (standard image content), but that solution isn't being used because it isn't a *perfect* solution (can't handle, e.g., poorly written Flash or other plugin content).

I'd be curious to know how common the situation outlined in comment 19 is.

I'd also be curious to know if real-world users actually perceive having CM turned on to be a bug, but I'm guessing no one has actually done that research.
Try releasing a beta with it enabled and see what happens. Haha. I don't know if it's common for users to compare content between browsers. I suspect it's a small percentage, but it's a huge market so 1% translates into many thousands of users. If there is a way for FF to insert code into a stream of Flash content, and tie this to the color management mode, you could in effect cause all Flash content to become color managed.
Summary: Enable full color_management by default → Enable full color_management by default (i.e. set gfx.color_management.mode = 1)
With regards to the dupe issue's discussion, IMO, the only hard requirement for web compat is that CSS colours and untagged images agree. Both modes 1 and 2 have this property. With wide gamut (DCI-P3 and Adobe RGB) monitors becoming more prevalent, mode 1 makes way more sense.
fully agree mode 1 does make much more sense!
Relevant issue here: https://bugzilla.mozilla.org/show_bug.cgi?id=1250461
Setting to 1 correctly manages color as it's supposed to now. Only need to set value to 1.
Adding DevAdvocacy keyword per the link dbaron noted above. Significantly impacts designers, and looks like we're the outlier now.
Keywords: DevAdvocacy
The comments in this bug so far make it sound like we might not be making the right trade-off.

Hi David, you're the triage owner for this component - who is the decider on color management?

In bug 569814, Benoit mentions a "Jeff", probably jrmuizel?
Flags: needinfo?(dbolter)
More dev/designer discussion here too, after that initial post. https://twitter.com/SaraSoueidan/status/1000796656164630530
Wow, old bug report. Mike, seems like a web compat issue at this point.

JeffM is away and color management is not actively owned. We probably need someone to see what turning on full color management does to our benchmarks these days.

Need-infoing Bas for when he is back.
Flags: needinfo?(mitaylor)
Flags: needinfo?(dbolter)
Flags: needinfo?(bas)
We also need to check what the spec says about interpolation. IIRC when I was trying to turn this on 10 years ago, it wasn't clear what should happen for gradients with color management enabled. The naive and easy thing I'd just to interpolate the corrected RGB values, which is probably what the current code does, but I have no idea if that's the correct thing.
(In reply to David Bolter [:davidb] (NeedInfo me for attention) from comment #34)
> Wow, old bug report. Mike, seems like a web compat issue at this point.

Unless I misunderstand, things aren't broken, just different (I guess some designers would disagree with me....) So more of an interop thing. I don't have any strong feelings on this, but generally agreeing with the majority of major browsers is a good thing.
Flags: needinfo?(mitaylor)
I need to run some more tests, however as far as I can tell there is at least no considerable performance objections to enabling full color managements. Unit tests also seem to generally be green.
Flags: needinfo?(bas)
it is only a change of the default setting, nothing what has any impact.

And all users who want to see correct colors have to manually change this setting to 1, since 10 years.
Only because nobody got courage to change it to the for everyone most usable dafault value gfx.color_management.mode = "1".
Before enabling full color management, Firefox needs ICCv4 support everywhere: Mac, Windows, Linux. Linux Firefox is using qcms which does not fully support ICCv4 profiles; I suspect but don't know that the macOS version of Firefox uses ColorSync, and the Windows version of Firefox uses ICM, both of which fully support ICCv4.

Either qcms needs to support ICCv4. Or Firefox needs to replace it with lcms2, which has had ICCv4 support tested in production environments for a really long time (maybe around 10 years), and also has had some display related optimizations since qcms emerged.

Anyway, it's not OK in 2018 to lack support for ICCv4 profiles or treat them as if they're ICCv2 profiels. They're essentially the default everywhere. Even colord on GNOME (and other DEs) has been creating display profiles per the ICCv4 spec and file format for years now and it does this automatically, on-the-fly, at startup time, from display EDID chromaticities, even if the display is not manually calibrated/profiled by measurements.
gfx.color_management.enablev4 is false by default. That is not an acceptable default whether gfx.color_management.mode is 1 or 2 by default - but is incrementally worse if the default is changed from 2 to 1.

What you have right now with enablev4 = false is some weird half assed implementation. So no matter what devs and users are going to get something most of the time they don't expect that doesn't match other platforms or browers.

Just for some timing references, ICCv4 spec was finalized and published in 2001. The current version is profile format 4.3.0.0, defined in ICC.1:2010-12, which was 8 years ago.

a. If qcms properly supports ICCv4 these days, then enablev4 should be set to true and mode set to 1, in the nightlies so we can find out what sorts of new bugs we come across that have been masked because of of enabledv4 = false.

b. If qcms doesn't support ICCv4 still, then you need to prioritize getting v4 supported either in qcms or drop-in lcms2 before you go back to a.
Related bugs not in the dependency tree for this bug, and maybe blocking flipping the pref, eg option B in comment #40:

qcms doesn't support ICC version 4
https://bugzilla.mozilla.org/show_bug.cgi?id=488800

Turn on full color management to match Chrome/IE
https://bugzilla.mozilla.org/show_bug.cgi?id=999600
(In reply to Bobby Holley (:bholley) from comment #35)
> We also need to check what the spec says about interpolation. IIRC when I
> was trying to turn this on 10 years ago, it wasn't clear what should happen
> for gradients with color management enabled. The naive and easy thing I'd
> just to interpolate the corrected RGB values, which is probably what the
> current code does, but I have no idea if that's the correct thing.

This would almost be correct if not for gamma correction. Have a look at the CSS 'color-interpolation' property: https://www.w3.org/TR/2003/REC-SVG11-20030114/painting.html#ColorInterpolationProperty

If color-interpolation is 'auto' or color-rendering is not 'optimizeQuality', you can do whatever is most performant, so interpolating corrected RGB values (i.e. in the monitor colour space) is fine. optimizeQuality looks trickier and may involve correcting the entire framebuffer as a final step.

It's unclear to me how color-interpolation: sRGB is expected to treat out-of-gamut colours.
(In reply to Greg Edwards from comment #42)
> It's unclear to me how color-interpolation: sRGB is expected to treat
> out-of-gamut colours.

Short version: Ask chris@w3.org

Long version: My expectation of this section is that it's without regard to gamut. It's strictly about whether to compute blends using a linear tone curve, or the sRGB tone curve. Chromaticties don't matter. But my further my expectation is that in CSS, the color space can only ever be sRGB, I'm not aware of a way to optionally define CSS colors in something other than sRGB (I vaguely remember there was a proposal for this, but no UA's were using it, so it got dropped?).

Comment 40 still applies. But in addition, I'd like to see a test suite produced for web browsers, specifically to evaluate color rendering. I think this is important to help us discover and understand the different renderings in browsers, but also to use for regression testing. A big part of the reluctance of changing quite literally anything, is introducing regressions. Some of the most innocuous seeming regressions can have wide ranging consequences.

The test suite should include all supported image file formats by all browsers (a superset); untagged, tagged ICCv2, tagged ICCv4, tagged ICCv4+iccMAX, tagged other (e.g. PNG has color management support that predates ICC). And then CSS, where all possible combinations of features that can affect color rendering are used, i.e. comment 42 (which bothers me that we'd expect devs to know color can blow up in different ways on different browsers for "performant" reasons; I mean, I get it, but it's still a WTF moment, like a trap door). While colors defined in HTML and colors defined in CSS should render the same, those should be tested in all possible combinations so we know if that's true or not.

Things I'd like to catch are not just for strict compliance, but also practical rendering. Sometimes strict compliance could cause a visible mismatch when two different objects are right next to each other.

Another part of the test suite is the metric. How to test? Is it just visual comparison of objects side by side? What's the reference? How do we know what's correct? What if everything is rendered wrong in exactly the same way, they'd all match, but they're all wrong - how to catch that? It's almost like we need a simple cross platform tool that displays a fixed test pattern (no html or css rendering needed, just RGB values sent through the OS specific display pipeline - using the exact same pipeline that Firefox uses; or possibly a toggle between using the same display rendering pipeline as FF, but also a path that's as direct as the platform allows that way we can discover rendering pipeline bugs or regressions).

I'd like to think some of this exists somewhere already. I'm thinking of the web equivalent of the Ghent PDF output suite (piles of PDF files testing all kinds of basic and esoteric PDF functions, for display and print, designed to expose compliance for rendering engines).

Kornel's thingie isn't extensive, but closest test suite I know of: https://kornel.ski/en/color (lacks a lot of CSS/HTML features and eg. DCF EXIF-tagged JPEGs which aren't supported anywhere AFAIK, which forces bloating pics with embedded profiles).

Sometimes strict compliance could cause a visible mismatch when two different objects are right next to each other.

In current, partial, implementations - yes. But I think strict compliance should provide consistent experience. For every possible combination of objects (incl. SVG, video, whatnot), on any possible output device (eg. wide-gamut HDR display).

Type: defect → enhancement

This is continually frustrating to me. Every time I browse on a new profile the web is an oversaturated mess and I'm reminded that this is what we're subjecting every user on a wide gamut display to. I suspect that we are underprioritizing this, because it is not something that screams "broken" to an average user, and it might not even be something they directly notice - it's just something that generally makes the browsing experience feel unsatisfying.

(In reply to Doug Thayer [:dthayer] from comment #47)

This is continually frustrating to me. Every time I browse on a new profile the web is an oversaturated mess and I'm reminded that this is what we're subjecting every user on a wide gamut display to. I suspect that we are underprioritizing this, because it is not something that screams "broken" to an average user, and it might not even be something they directly notice - it's just something that generally makes the browsing experience feel unsatisfying.

Does setting the pref make things acceptable?

Flags: needinfo?(dothayer)

I don't notice anything as under or oversaturated or mismatched as far as colors go after setting the pref. I don't know how much that's worth, though.

Flags: needinfo?(dothayer)

And what platform/monitor do you see the badness on?

Flags: needinfo?(dothayer)

Windows 10 desktop on a Dell U2713H: Firefox (and Edge) colors noticeably oversaturated when compared to Chrome - (fixed with pref on)
OSX on 2018 MacBook Pro built-in display: Firefox still oversaturated when compared to Chrome (and Safari), but a bit less so (also fixed with pref on)
OSX on Asus MX27AQ: Firefox, Chrome, and Safari all feel oversaturated, however Firefox slightly moreso than the rest (Firefox feels best of the three with pref on)

Flags: needinfo?(dothayer)

I am terribly sorry if I will sound harsh, but couple of recent messages here made me almost cry. In the ancient times, Firefox used to be the best browser for correct colour because it had this obscure setting that made stuff look proper, now, for years, it’s been the worst.

Does setting the pref make things acceptable?

Yes. It always has. I’ve got it ON for years, so can’t judge a performance hit, but it cannot be a deal-breaker.

And what platform/monitor do you see the badness on?

Any gamut straying from sRGB. In practice: wider. The wider – the worse.

Safari (Webkit) was and is historically correct. IE/Edge converted to sRGB which is silly, but better than Firefox. Chrome (Blink) did an amazing leap and is working towards supporting intermediate, linear highbit compositioning space (through Canvas, last time I checked, but I’m not an engineer and I don’t know what I’m talking about).

Making gfx.color_management.mode = 1 the default is the least Firefox has to do. Making sure all new, swanky, webrender-whatevah things take colour management seriously is the only way forward, really.

Sorry. Without this setting Firefox is unusable on an increasing number of displays and with increasing number of artifacts to display.

Assignee: nobody → aosmond
Status: NEW → ASSIGNED

We should watch telemetry closely this nightly cycle to see how much of a hit we are going to take on decode time. My last estimation was we would roughly double decode image for untagged images. However it was made slightly faster with the AVX2 work that I have done previously. There is more we can do if it turns out to be a problem. This does not enable ICCv4 which has known bugs and is not accelerated -- I began work on an SSE2 version of the current algorithm, but we need to figure out the bugs first before shipping it. See bug 1602453 for more on that topic.

Priority: -- → P3

Attached file Bug 455077 - Enable color management for all images, not just tagged. — Details

This patch will also color manage everything else in the browser, particularly CSS colors, right?

(I seem to recall that enabling full color management caused lots of try failures in the gradient reftests, but that was 12 years ago, so things could well have changed).

I think Cameron was looking at this last week?

https://treeherder.mozilla.org/#/jobs?repo=try&revision=0528c8a7c9c2181d7e7781a28ce2deb2e6661967 didn't look too promising, though that also enabled another pref.

(Although as Emilio mentions, that sets both gfx.color_management.mode = 1 and gfx.color_management.enablev4 = true.)

See also [1] for some of the original context. The plugin thing is probably much less of an issue. IIRC I added a fair amount of bogus profile detection but it was by no means exhaustive. Modern displays may handle this better, but I wouldn't be surprised if we got a lot of edge-case bug reports from things looking wrong on old displays.

Most of the perf overhead was images, so off-main-thread image decoding probably made this a good bit better.

[1] https://bholley.wordpress.com/2008/09/12/so-many-colors/

(In reply to Bobby Holley (:bholley) from comment #56)

Attached file Bug 455077 - Enable color management for all images, not just tagged. — Details

This patch will also color manage everything else in the browser, particularly CSS colors, right?

Correct, I should amend the patch description. Windows hasn't finished running but I don't expect much in the way of reftest failures. The reftests currently force the setting to 2, and force it to sRGB which should produce fairly consistent results....

(In reply to Cameron McCormack (:heycam) from comment #60)

(Although as Emilio mentions, that sets both gfx.color_management.mode = 1 and gfx.color_management.enablev4 = true.)

Yes, ICCv4 will cause problems at present.

While I’m one of the many people direly waiting for proper color management setting on Firefox getting on par with other modern browsers on wide-gamut environments, I’ll have to note that there is a minor side effect of turning on the management setting manually (so that CSS colors are also contained within sRGB limits) - Copying image (pixel data) off Firefox to other applications will make the output look heavily desaturated. Easiest way to reproduce: Open any image in browser, and try either dragging the image out of browser to any other app / or choose Copy image from the context menu, paste elsewhere.

Something to mind before applying the settings wide by default.

Depends on: 1616444
Depends on: 1618345

(In reply to Hansol Kim (zvuc) from comment #65)

While I’m one of the many people direly waiting for proper color management setting on Firefox getting on par with other modern browsers on wide-gamut environments, I’ll have to note that there is a minor side effect of turning on the management setting manually (so that CSS colors are also contained within sRGB limits) - Copying image (pixel data) off Firefox to other applications will make the output look heavily desaturated. Easiest way to reproduce: Open any image in browser, and try either dragging the image out of browser to any other app / or choose Copy image from the context menu, paste elsewhere.

Something to mind before applying the settings wide by default.

Thanks for pointing this out. I filed bug 1615397 (metabug) to track a number of bugs with respect to color management, images and the clipboard. I don't think they are a significant amount of work to fix, so I will endeavour to resolve them at the same time.

Attachment #9125964 - Attachment description: Bug 455077 - Enable color management for all images, not just tagged. → Bug 455077 - Enable color management for all CSS/images, not just tagged images.
Pushed by aosmond@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/469e5a0fc374
Enable color management for all CSS/images, not just tagged images. r=jrmuizel
Depends on: 1628430
No longer depends on: 1628430
Pushed by aosmond@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6392325ec39e
Enable color management for all CSS/images, not just tagged images. r=jrmuizel
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla77
Blocks: 1519887
Regressions: 1631615
Regressions: 1632539
Regressions: 1637861

Does not seem to work as expected for me. See https://bugzilla.mozilla.org/show_bug.cgi?id=1639584

Regressions: 1639574

We decided to back this out in bug 1639574. It depends on work on canvas in order to reland.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Depends on: 1641229
Blocks: 1641232
Blocks: 1638048
Depends on: 1668536

I am not sure if this is fully released to this, but there is also this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1486371 It's about color management in videos.

Status: REOPENED → ASSIGNED
Target Milestone: mozilla77 → ---
Severity: minor → S4
Duplicate of this bug: 999600
Depends on: 1856701
Depends on: 1880729
You need to log in before you can comment on or make changes to this bug.