As a follow up to bug 16769, I believe we should set gfx.color_management.enabled to true by default. This is a tracking bug for discussing issues related to why we should or shouldn't enable support for color management.

we should turn it on as soon as it is fast enough.

If we're going to ship it in a release, I think we need to ship it in a beta.

The beta 5 codefreeze is in 5 days, so if this is going to be enabled by default it probably should be done quite soon.

we're not going to turn it on for firefox 3 release (it still isn't fast enough)

nominating for blocking just to get a wanted-next+

(In reply to comment #4) > it still isn't fast enough Are there any specific bugs on this that could be made blockers here for reference? We're trying to evaluate this pref for Camino, and having a better idea of what the specific tradeoffs are would be helpful.

(In reply to comment #1 and comment #4) > we should turn it on as soon as it is fast enough. > we're not going to turn it on for firefox 3 release (it still isn't fast > enough) Do you have an idea where the performance problem is? lcms, cairo, libpng, or somewhere else?

Reasking for blocking-1.9.1 as it was already set in bug 437300.

What's unfortunate is that a 3rd option was not explored, which is to perform color management by default on images that contain embedded ICC profiles. That would have been a good and logical first step but there isn't such an option to do this in FF. It's either all or nothing.

For example FF3 fails this test: http://www.color.org/version4html.xalter Safari passes. And yet it would not affect untagged images, CSS and Flash so they would remain unchanged. Only tagged content would be affected. And I think it's appropriate to honor that metadata rather than ignore it.

I've enabled gfx.color_management.enabled under the FF3 release version for OS X and it's not ready for primetime. There's color shifting going on in page content, though overall color rendering is better than with it disabled. Details: https://bugzilla.mozilla.org/show_bug.cgi?id=440940

I don't think this will block 1.9.1, but would be a wanted1.9.1+ P3. Do we have a clear path to improving perf here? Do we know where the hot spots are?

I've been working on the bugs and perf issues for color management for the past few days, but I forgot to accept the bug. Doing it now.

we're ready to turns CMS on by default for a2. Attaching a patch and flagging vlad for review.

where we at with flash color management? maybe this has been discussed elsewhere, but if FF could check for version of flash, if less than 10 keep color management off by default. if 10 or greater, then enable color management in ff by default, and also there is some sort of scripting that can be done to enable it in flash as well.

Comment on attachment 334370 [details] [diff] [review] patch to turn cms on by default we ended up with a bunch of reftest failures when color management was turned on (I had assumed that tor had already made sure the reftests passed back in the 3.0 days). As such we've pushed back turning color management on until the next milestone.

We're about ready to turn it on again. This patch is a combination of the mode switch patch and the patch from bug 453548 (r+ed by dolske) which must be applied at the same time. Flagging vlad for review.

Comment on attachment 337742 [details] [diff] [review] patch to turn cms on by default and update some reftests that depend on the cms mode Sure, let's give it a go... just, later tonight, if you can!

pushed as tagged-only in b0aaf69e714e more context in my blog post at http://bholley.wordpress.com/2008/09/12/so-many-colors/

Further general color management discussion should move to bug 455056

I don't understand why this is resolved/incomplete, did you set that by accident ?

I had assumed that 'incomplete' meant that the feature was partially implemented but not all the way and wouldn't be for the foreseeable future (the case with this bug - we settled on taggedonly). I just asked sdwilsh and apparently 'incomplete' means that the bug report was incomplete, which isn't correct. Changing to 'fixed', since it's the next best solution.

I opened a new bug #455077 for "full" color_managment support in the future, so we don't forget.

I guess we then need to move some of the blocks/depends from this bug to the new bug #455077.

Some stuff should be moved - I'm a bit short on time right now though (I'm heading out of town tomorrow morning). Anyone who has a sec to move any unresolved color management bugs to bug 455056 and any issues _specifically_ related to turning on full color management to bug #455077 should feel free to do so. It'd be much appreciated.