546579 - lcms was removed from tree -- should be re-added to allow testing/reselection

Status: RESOLVED DUPLICATE of bug 488800

(Core :: Graphics: Color Management, defect)

Description

[L A Walsh]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6

lcms was removed from tree with little discussion from those affected most -- those who use or want to use v2.44 profiles.  My v2.4 profiles can't be used with ff and this is a regression over previous ff behavior.

I understand there is a belief that qcms (suporting icc v2.2) was faster, smaller and by inference, thought more secure, but there wasn't an discussion of the tradeoffs of accuracy vs. speed.

Nvidia has accuracy vs. speed trade-offs in all of there graphics cards -- and the choice is left open to the user.  It is even selectable BY application.

I think it was a severe regression to remove this from FF, and it would have been a BEST OPTION to provide QCMS as perhaps a 'default', and make sure lcms was made into an easily included library that could just be 'updated' with latest source patches on an 'as is' basis from the lcms project.

Then tie an config-optin (w/gui or not -- preference w/gui), to choose which cms to use with trade-offs being known.  Let users choose their option quality or speed.

**IDEALLY***, users could choose the cms used on a per-website basis -- as on sites like news.google or slashdot, I might not care about quality as much as on an art site like deviantart, minitokyo, or animepaper, where color profiles (including iccv2.4 profiles) color profiles can make/break a picture.

URL shows breakage of v2.4 profiles.  These used to work when ff first enabled
profiles.  




Reproducible: Always

Steps to Reproduce:
1. Visit a site with 2.4 profiles (icc-v4) as in URL --
2. Notice image distortion.
3.
Actual Results:  
firefox downgraded icc support after advertising state-of-the art profile support.

This is bad and disingenuous, as this downgrade was done with very little public discussion or announcing in the release notes.  It's very much a 'bait & switch',
where ff was baited with best color profiling, and then 2nd-rate, not working profiling was slipped in later ... that's shoddy engineering if not downright dishonest.



Expected Results:  
Expect high standards to be maintained.  If there is a trade off -- "optionize" with safe defaults, and make ways to enable high quality behavior "well known" (gui option to enable would be best).

See what users pick...would guess: (~35:65 split +/-5).





This is a major bug that causes one to lose the ability to display images that previously displayed correctly.  One can no longer browse certain images correctly, if at all, because of this bug.  If these images were one's own that one put up on the web, one has lost the ability to display those images w/FF.

I would call that lost access to data.  Thus I am taking this as critical -- though would accept it as 'Severe' if deemed to be too isolated case of data lost.

It is breaking of a previous feature and is a regression.  So it is at least severe.

Comment 1

[Kevin Brosnan]

lcms was a security liability. The bug 481926 change shipped in the 3.5.x branch and reverting it at this point is not possible. Duping to the qcms needs icc 4 support bug.

Comment 2

[Insert Real Name]

(I've read the advice concerning comments and bug-spam, but inaccurate information about other people's code should not remain uncorrected in the record.)

In fairness to LittleCMS, the security liability could not have been used as an exploit: see http://www.mail-archive.com/[e-mail]/msg02611.html

The major reason for the change of color management appears to have been the desire to have color management code completely integrated and optimized for the rest of the Firefox graphics framework, no longer dependent on an external library.

LittleCMS, after all, is a general purpose color management library, with a breadth and depth of capabilities not needed in Firefox. Of course, dropping it means losing the color management knowledge and experience represented in the implementation. So, as the original bug poster points out, LittleCMS pretty much supports any valid display or embedded profile type in-the-wild, while the new Firefox code covers a smaller range of types (e.g. no cLUT or v4 profiles--although my own testing was done last year, not recently, so this might have changed).

My own view--not worth much!--is that the switchover to new code was premature. Firefox 3.0.x had the distinction of being just about the only widely available that did correct WWW color management: embedded profiles honored, other color data assumed to be in the sRGB color space. And Firefox 3.5+ added the option of transforming only image data with embedded profiles and assuming all other color data was in the unmanaged monitor color space, so that browser-rendered and plugin-rendered colors would remain equal, which probably a good default as long as Adobe does not enable color management by default in its Flash plugin.

Comment 3

[Kevin Brosnan]

The above comment would be best directed to https://lists.mozilla.org/listinfo/dev-tech-gfx or nntp://news.mozilla.org dev.tech.gfx