Closed Bug 564041 Opened 14 years ago Closed 13 years ago

RFE: use Little CMS 2 (lcms) instead of qcms

Categories

(Core :: Graphics: Color Management, enhancement)

Product:
Core
Component:
Graphics: Color Management
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: earthsound, Unassigned)

Details

I know that a lot of work went into the move from lcms v1 to qcms, and for good reason. However, it is apparent that qcms has several shortfalls, including no support for ICC version 4 profiles (see bug 488800), or at best, reading ICC v4 profiles as v2 profiles.

I would like to request that an effort be made to determine whether lcms 2 would be a worthy replacement for color management. It is, mostly, a rewrite from version 1, according to Marti Maria.

http://littlecms2.blogspot.com/

Little CMS v2 is a full v4 CMM, which can accept v2 profiles. Marti listed a few differences in a post back in Nov. 2009:

* It does accept and understand floating point profiles (MPE) with DToBxx tags. (Yes, it works!) It has 32 bits precision. (lcms 1.xx was 16 bits)
* It handles float and double formats directly. MPE profiles are evaluated in floating point with no precision loss.
* It has plug-in architecture that allows you to change interpolation, add new proprietary tags, add new “smart CMM” intents, etc.
* Is faster. In some combinations, has a x 6 throughput boost.
* Some new algorithms, incomplete state of adaptation, Jan Morovic’s segment maxima gamut boundary descriptor, better K preservation…
* Historic issues, like faulty icc34.h, freeing profiles after creating transform, etc. All is solved.
What is the security status/policy for lcms2? One of the main reasons for switching to qcms was that Marti Maria didn't seem that interested in making sure lcms was hardened against attack.

I'm also concerned that switching to lcms2 would cause a significant performance regression.
(In reply to comment #1)
> I'm also concerned that switching to lcms2 would cause a significant
> performance regression.

I'll try to get some numbers for this.
(In reply to comment #2)
> (In reply to comment #1)
> > I'm also concerned that switching to lcms2 would cause a significant
> > performance regression.
> 
> I'll try to get some numbers for this.

A quick performance test using the lcms-compare utility in the qcms repository for converting from srgb to my monitors colorspace gives:
lcms: 732407
qcms: 269526

So qcms is about 2.7x faster
Jeff: thanks for taking the 1st look into this. In comment 3, I assume you were comparing qcms and lcms v2? 

Also (this question comes from ignorance of the lcms-compare utility), is the utility set up to take advantage of the differences between lcms v1 & lcms v2? Does it use any of the built-in profiles of lcms v2 (I'm not sure if lcms v1 or qcms have these). 

See, for example, http://github.com/mm2/Little-CMS/raw/master/doc/LittleCMS2.0%20tutorial.pdf#page=21.

Keep in mind that it is still in beta form. I would think more speed optimizations would be possible/probably before final release. 

I would also think that if moving over to lcms v2, completely, doesn't pan out, perhaps snipping what is needed from lcms2 may be beneficial. Any thoughts?
I have take the task of run the perfomance test by myself, and found that lcms2 is comparable to qcms without needing any SSE2/MMX assembly and therefore completely portable. See here the code I used.

http://www.littlecms.com/lcms_qcms.zip

Download and unpack the lcms2 distribution and then unzip over it this small zipfile. There is a windows project. The key is to move transform creation out of the measured loop, as this should happen only once. 

lcms: 625
qcms: 610
differing output(4): (0 2 0) -> l(5 9 0) vs. q(4 8 2)
[...]
differing output(4): (130 2 0) -> l(111 9 0) vs. q(110 8 2)
26840246 - 1.599803

That's not a 2.7x faster, at least on my machine. What worries me is the big amount of differences found.   

I will put an entry on my blog about this soon.
Regards, Marti Maria.
> What is the security status/policy for lcms2? One of the main reasons for
> switching to qcms was that Marti Maria didn't seem that interested in making
> sure lcms was hardened against attack.

??? I never said that. My point is that code should be fully tested and 
qualified before accepting a patch from dubious origins. See here a 
post in the lcms mailing list about this:

http://sourceforge.net/mailarchive/message.php?msg_name=49EB34E2.2040609%40littlecms.com

Regards, Marti
(In reply to comment #6)
> > What is the security status/policy for lcms2? One of the main reasons for
> > switching to qcms was that Marti Maria didn't seem that interested in making
> > sure lcms was hardened against attack.
> 
> ??? I never said that. My point is that code should be fully tested and 
> qualified before accepting a patch from dubious origins.

I was referring to this post:

http://sourceforge.net/mailarchive/message.php?msg_id=49E20E28.1050107%40littlecms.com

Where you say "Well, I'm certainly not happy about their decision, but maybe this would get kids playing war games away from lcms, so we could concentrate
on color quality and stability :-)"

Sorry if I interpreted that beyond what you intended. I'm glad to hear to that you're serious about the security of lcms2. How thoroughly has lcms2 been audited? Has it been fuzz tested? i.e. how comfortable would you be putting it up to determined attackers?
(In reply to comment #5)
> Download and unpack the lcms2 distribution and then unzip over it this small
> zipfile. There is a windows project. The key is to move transform creation out
> of the measured loop, as this should happen only once.

Transform creation is actually worth including for our use case where we're creating new transforms for every image that we decode. i.e. Once an image has been decoded and color corrected the transform is not often reused. How expensive is transform creation in lcms?
 
> lcms: 625
> qcms: 610
> differing output(4): (0 2 0) -> l(5 9 0) vs. q(4 8 2)
> [...]
> differing output(4): (130 2 0) -> l(111 9 0) vs. q(110 8 2)
> 26840246 - 1.599803
> 
> That's not a 2.7x faster, at least on my machine. What worries me is the big
> amount of differences found.   

It seems that you're using an older version of qcms. The sse code has since been rewritten and is noticeably faster. And yes, the differences are indeed interesting.
(In reply to comment #7)
> Where you say "Well, I'm certainly not happy about their decision, but maybe
> this would get kids playing war games away from lcms, so we could concentrate
> on color quality and stability :-)"

Sorry, that comment was not on Mozilla but about an incident with an Italian student that was distributing a patch for "security reasons". That patch was found to break functionality and open other possible vulnerabilities. 
It was my fault to put in the same bag what are legitimate security concerns 
with what I think was just desire of fame. Because that, I did send the second mail I'm pointing out, and tried to do a test on how a "good" security issue should be handled. The process went smooth and without problems. My actual policy on security is as described in the mail. I will put a page on the website
detailing that.
 
> Sorry if I interpreted that beyond what you intended. I'm glad to hear to that
> you're serious about the security of lcms2. 

Sure I am. Security was one of the reasons to do a full rewrite of the engine.

> How thoroughly has lcms2 been audited? 

It is in the process, as some companies are interested. It is, however, hard to get such level of security without any resources, and as you already know lcms is a non-profit project. Some people are collaborating with code reviews, but I'm afraid I cannot afford a  true professional security audit. At least not now. But that doesn't mean that nothing has been done in this field.

> Has it been fuzz tested? 

Yes. I have a collection of more than 2000 assorted ICC profiles, some are buggy, some are crafted to make some to CMM fail. Current code does read, rewrite and recover from errors on the full set. Please see an entry on my blog about that: http://littlecms2.blogspot.com/2009/07/profile-zoo.html

I wish to apologize if my comment on the mailing list sounded like I were not interested in security, I certainly am. But I think image quality and stability are equally important. A library that is very secure but it doesn't work is useless anyway, both parts of the equation are equally important.
(In reply to comment #8)
> Transform creation is actually worth including for our use case where we're
> creating new transforms for every image that we decode. i.e. Once an image has
> been decoded and color corrected the transform is not often reused. How
> expensive is transform creation in lcms?

It is expensive because it explores LUT precedence and possible optimization paths in order to optimize. I can understand tagged images should open a new transform each time, but in most cases that is not necessary. For example, 99% of images will come either with sRGB or AdobeRB as embedded profiles, then you could create two transforms, sRGB to monitor and aRGB to monitor. On opening the image and accessing the embedded profile, if the profile is binary  equal to aRGB or sRGB, then just use those transforms. Otherwise, for the remaining 1%, create a custom transform. I think that could represent a big speedup. 


> It seems that you're using an older version of qcms. The sse code has since
> been rewritten and is noticeably faster. And yes, the differences are indeed
> interesting.

I will be glad to check the latest code. Is it in the git? But anyway, lcms2 allows the use of plug-ins for replacing critical parts, so you could use your own SSE code without modifying any part of lcms, then you would have V4 support and your current throughput.
Just to throw in my 2C,

While I appreciate the work done on qcms, I would rather have the results be correct rather than fast, and I know this sentiment was echoed a lot at MozillaZine when qcms was first introduced.

Also, IIRC, while performance was a contributing factor, I don't recall it being a primary motivator for switching to qcms. Likewise, I do not think it should be a primary motivator for sticking with qcms. A 3x performance delta is a lot better than what it was:
http://muizelaar.blogspot.com/2009/10/qcms-now-faster.html

It sounds like there's plenty of room for performance improvement in lcms2. There's probably other method to improve performance as well. Perhaps a 2-pass render. Render the image, apply the color transform, re-render the image (or allow rendering of non/partially transformed images, and re-render them when the transform is complete).

Anyways, from my standpoint as a user, I'd say that the benefits of lcms2 outweigh the drawbacks.
Sorry for the noise, just curious as to whether any more work/investigation had been made in this area. Would love to see the benefits that lcms2 would bring. :)
I'm closing this bug as WONTFIX for now. I don't have any plans to switch to lcms right now and we can reopen it if that changes.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.