Normally, rewriting a large chunk of code from scratch is a bad idea. However, we were in a situation that made rewriting pretty attractive. First, we were only using a small portion of lcms's functionality, but we were paying for the large code base in both maintainability and threat surface. Second, we were already maintaining substantial modifications which was an additional maintenance burden. Finally, our requirements for a color management library are different then the goals of lcms: we need something fast and secure, while lcms seems more focused on functionality, completeness and correctness.
What's new?
qcms is made up of two main parts: the ICC profile parser and the transformation engine. The transformation engine reuses a lot of code from lcms. The ICC profile parser is completely new and written with security and robustness in mind.
The new parser has some key design differences compared to lcms. One of these is the I/O model. lcms has an I/O abstraction layer that abstracts reading from memory and reading from a file. It uses this layer to read what it needs from the profile as it's needed. This means that the full file or memory copy of the profile needs to be kept around for the lifetime of the profile object.1
qcms uses a simpler model. The entire profile is read into memory and then parsed to construct a profile object. We only keep the information that's needed to construct a transformation between color spaces. After parsing we can close the file or free the memory used to store the profile. Furthermore, since we only parse in-memory, we also don't have to deal with any possible read errors or other file I/O problems during parsing.
Error handling during parsing can be tricky and ridden with security holes. To help deal with this problem, qcms adopts an error handling strategy similar to cairo. Instead of trying to deal with the error immediately and returning an error result up the call stack, we often set a flag to note the brokenness, putting us into an error state, and continue on. To continue successfully, all of the following operations must be completable even while in an error state. However, ensuring this is usually easy, especially if the results will be discarded. When we do get to a place where it's convenient to return, we do so. The big advantage to this approach is that it keeps the error state control flow as similar to the normal control flow as possible. This makes the code easier to read, easier to reason about, and easier to test.
Speed
Last summer, Bobby Holley did a bunch of work to make lcms faster. I was able to reuse that work in qcms. The result is that qcms is one of the fastest color management systems around. Here's a simple test that transforms all the possible RGB components from one RGB colorspace to another. It compares lcms, qcms and ColorSync, the system color management system on OS X.
Current Limitations
qcms currently only supports transformations to and from RGB colorspaces. This covers the vast majority of uses on web; however, it means there's no support for CMYK and many additional profile types. If you are interested in making this code better, let me know!
18 comments:
The fact that qcms doesn't support ICC version 4 yet means a lot of people will check http://www.color.org/version4html.xalter and file unnecessary dupe bugs.
*Sigh*
Please check Bug 490700 - Let qcms directly transform to Cairo pixel format to save later conversions (https://bugzilla.mozilla.org/show_bug.cgi?id=490700).
And for ICC4: see:
Bug 488800 - qcms doesn't support ICC version 4 (https://bugzilla.mozilla.org/show_bug.cgi?id=490700).
Now that colour correction is "blazing fast™", is there any possibility of seeing it enabled by default in future builds? (full, not just for tagged images)
Can the ICC v4 support be fixed soon? This is a bad regression in FF3.5.
Do you have any late news on 3.5’s implementation of color management. It doesn't work well for me.
I use Photoshop CS3 and have been editing photos in the Pro Photo Color Space until recently when I started using LAB. In either case after editing a photo I use Convert to Profile to create an sRGB jpg image which I then upload to Flickr. Accordingly, all my Flickr photos show up as sRGB in the EXIF properties display. The profile I've been using in Photoshop is sRGB IEC61966-2.1 and I'm assuming that is v2, not v4.
Since upgrading to FF 3.5 my Flickr photos show up considerably darker and much more color intensive. (They are fine when viewed in Chrome or IE.) When I change about:config’s gfx.color_management.mode from 2 to 0 (disabling color management), the photos display correctly.
Based on what I've read. there is apparently a 3.5 problem using ICC sRGB profile v4 with the promise of a fix in the future. But since I'm not using v4, and since FF3.5 is supposed to handle v2, why doesn't it work correctly when the gfx parameter is set to either 1 or 2?
One other note - I modified gfx.color_management.display.profile to point to my monitor profile and then set gfx.color_management.mode to 2 and got the same darkened result. When I set the mode back to 0 and left the display string pointing toward my monitor, the picture displayed correctly.
I also tried changing the rendering intent to -1 and to 3. Neither resolved the problem.
One other confusing result. Although I have been using sRGB v2 as my ICC profile for photos uploaded to Flickr, I downloaded the sRGB v4 profile to my computer and used it to create a duplicate of a photo originally done in v2. To my amazement, Firefox 3.5 shows its colors correctly, although the v2 image is dark and overly saturated. This seems to be the opposite of the 3.5 bug regarding v4. I've also reloaded the Dell 2407 profile but that did not change the results.
Is there an estimated date as to when color correction in 3.5 will be working?
Does qcms support matrix RGB profiles only, or also table RGB profiles?
Thank you.
Mauro
Great job! Though the support of ICC v.4 is highly desirable as it would save many from an incompatibility headache with v.4 monitor profiles.
(Esp. non-tech guys who will hardly find their way to vote to rise the priority of this feature in bugzilla).
@John Weiss: Chrome and IE don't do color management, so they will have the same result as setting the color_management mode to 0.
If you provide me with your display profile and an image that you think is being miscorrected I can investigate the problem.
Jeff,
Thanks for getting back to me. Inexplicably, things have changed. I've had color management mode set to 2 for over a month and have seen no problems.
...The files are down ?...
ICC4 support should be made a priority and included as soon as possible. I'm sure there are enough rants and sighs about this in the blogosphere.
http://mynikonandcanon.blogspot.com/2009/11/firefox-3536-color-management-step.html
Um....since there is now a substantial support burden with firefox keeping up with correct color standards, maybe it would be better to go back to lmcs as it already supports v4 -- I want my working profiles back!
I keep wondering why so many images look bad, and i realize I have to switch browsers to see the web as it really is today on modern photo sharing sites. That's bad.
I wish FF would switch back to LCMS until QCMS works properly with v4. All the speed in the world is useless if it doesn't work properly.
Accordingly, all my Flickr photos show up as sRGB in the EXIF properties display. The profile I've been using in Photoshop is sRGB IEC61966-2.1 and I'm assuming that is v2, not v4.
I really appreciate the fact that Firefox is the only browser that allows users to interpret untagged images and page elements as sRGB, as the W3C recommends. This capability is more and more important as larger gamut displays come to market.
I've written about it, citing your work on the color management module.
http://gearoracle.com/guides/web-browser-color-management-guide/
If you provide me with your display profile and an image that you think is being miscorrected I can investigate the problem.
Post a Comment