LittleCMS 2

LittleCMS 2.3 released

2011-12-16T09:54:00.000Z

I am glad to the announce the release 2.3 of the LittleCMS open source color engine.

Version 2.3 is a maintenance release which adresses several minor issues and increases compatibility. It fully implements the recently released ICC 4.3 standard.

See the changelog for further details.
http://www.littlecms.com/download.html

2011-11-02T12:55:00.002Z

I've uploaded a tarball with lcms2-2.3 release candidate:
http://www.littlecms.com/lcms2-2.3rc2.tar.gz

It is basically a maintenance release, with a number of bugs fixed.
If no issues are found, I plan to release it in a week.

LittleCMS 2.2 released

2011-06-10T10:49:00.000+01:00

I am glad to the announce the release 2.2 of the LittleCMS open source color engine.

Version 2.2 adds stability, fixes all know bugs, and adds support for dictionary metatag. Pascal unit now compiles under FPK Pascal as well as Delphi.

See the changelog for further details.

http://www.littlecms.com/download.html

Updated browser check images

2011-06-02T15:49:00.000+01:00

Still, Firefox does not work. But oh, surprise... check IE9!

lcms 2.2 release candidate

2011-05-30T14:56:00.001+01:00

I have setup a release candidate for lcms 2.2, which includes support for dictionary metatag and fixes all know issues. I am now removing all copyrighted profiles and including RTF for the documentation, in order to fulfill Debian requirements.

See here the release candidate:

http://www.littlecms.com/lcms2-2.2rc1.tar.gz

or in the GIT repository, tagged as lcms2-2.2rc

http://github.com/mm2/Little-CMS

Any feedback is very welcome

ICC/HP Digital Print Day

2011-03-10T11:12:00.001Z

15 June 2011

Co-sponsored by the Society for Imaging Science and Technology

The International Color Consortium, in association with HP Spain, is holding a Digital Print Day at HP's Sant Cugat facility. This will be an opportunity to review and discuss recent work on digital print, focusing primarily on colour management but also encompassing screening, workflow and other related topics.

Papers will be published on-line after the event on the ICC web site http://www.color.org/

Abstracts should be submitted to mailto:pj.green@lcc.arts.ac.ukby April 18 2011. Abstracts will be reviewed by a program committee and notification of acceptance sent by May 11 2011

Papers from students of print and color are especially welcome. ICC will provide a stipend of €100 to all students presenting. A prize of €500 sponsored by HP will be awarded for the best student paper, to be decided by a panel of expert judges.

2011-01-10T14:04:00.000Z

Happy new 2011!

I would like to begin this year with a comment for a recurrent question:

Can I use LittleCMS to create a profile for my camera/printer/scanner/etc?

Color management, at least ICC color management, is a two step process.

You need both, ICC profiles for each device you want to integrate in the workflow and a piece of software, called "CMM" that uses those profiles for doing color management.

ICC color management requires all "smarts" of gamut mapping to be placed in the profiles. Then actually, building a profile involves a lot of art.

LittleCMS is a CMM. It can use those profiles to perform color management. It does NOT create profiles. It can be used to create the physical files that contains the color mappings, but it does not compute the maps. I can tell you that creating good profiles is a very difficult task, and takes teams of color scientists to define algoriths and settings, taking into account things like memory colors, skin tones, primary preservation and so.

So, littlecms is useless for you if you need to create profiles from the end user point of view. As useless as it would be photoshop, which cannot create profiles neither, it only uses yet-exiting profiles.

For the programmer point of view, lcms can be used to create the files that contain the colormaps, and many people are using it in such way. That would be, lcms is the canvas artists may use to do their creations. lcms would take care of all details of the profile specification.

Having said that, please take a look on ArgyllCMS, a package that can create v2 profiles. Profiles created by Argyll can be used by LittleCMS without any problem.

Multithreading question

2010-12-17T15:37:00.002Z

Question: Do I need a rocket science degree to deal with lcms2 in multithreading mode? What are ContextID and THR functions?

Actually it is a lot more simple. ContexID is nothing else that a void pointer that user can associate to profiles and/or transforms. It has no meaning. Is just a sort of used defined cargo that you can use on your convenience. lcms does nothing with that . It has no relationship with threads, but can be used to store information about the thread. Obviously you can ignore it if wish so. Then, by default this void pointer is set to NULL when creating the transform or opening the profiles. Additionally, if the programmer wish, there are functions which end with THR that can set the this to values other than NULL. In this way the threads, processes or wathever that are using the profiles and transforms can retrieve the value. It is just a way to store a 32 bit value along the handles.

On the other hand we have the 1-pixel cache. This is very convenient on slow interpolation methods when most of the pixels in the image are similar. Obviously, caching means the transform should store the result of last processed pixel, then in the case two threads are using the same transform at the same time, memory read/write operations on this value may clash and therefore you need some sort of semaphore. Ok, you can use a semaphore (the pthreads) or just get rid of the cache enterely. Please note that in some situations the cache is not used at all, i.e., on matrix-shaper to matrix-shaper 8 bit, it is actually faster to do always the computations, so the cache schema is discarded on this case. On CMYK trilinear, cache is being used as interpolation tends to be slow.

So, to answer your questions: If you use redundant transforms, you need not to worry about anything as each transform is using different cache. May be fast, but this is big a waste of memory. If you share the same transform on several threads, which is very efficient, you have either to disable the cache or to enable pthreads. I would reccomend to disable the cache, the performance gain when using multiple threads is huge, the performance gain when using cache is small. If you need more performance, just add more threads. You have not to use cmsCreateTransformTHR, this is just a way to add a user-defined variable to the handle, and finally cmsDoTransform does not have any ContexID, the error reports the ContextID associated with the transform being used. As a hint, ContexID are more useful when you want write a memory management plug-in to specialize memory mangement for multithreading, as the memory management pluging does recive ContextID when a memory operation is requested. The testebed application does use this feature to check memory consistency.

Absolute colorimetric intent

2010-12-10T15:02:00.004Z

Kai-Uwe Behrmann has found a nasty bug in 2.1 on absolute colorimetric intent when display profiles are involved. :-( The issue is solved in GIT, but not in the 2.1 distribution. Too bad. Well, It is not so terrible because it only affects the combination of abs. colorimetric and display profiles, but anyway ...

The specs on ICC V4 are pretty messed out when regarding to absolute colorimetric intent. There is now something called "ICC absolute", which is same that relative on display profiles and preserves paper white on output profiles. Basically the observer is assumed to be fully adapted to whatever illuminant being used to create the profile, this has severe implications on monitor profiles, and no effect on printer profiles measured under D50. So right now we have the v2 absolute, wich says nothing about the observer adaptation state and v4 absolute which assumes full adaptation.

I tried to do my best in supporting all modes (v2 and v4) by implementing what the white paper below describes, a knob to adjust the degree of chromatic adaptation, a feature that may be useful for match-to-screen applications. See cmsSetAdaptationState() on the manuals.

http://www.color.org/ICC_white_paper_6_v2_and_v4_display_profile_differences.pdf

Many thanks Kai-Uwe for catching the bug!

LittleCMS 2.1 released

2010-12-01T17:03:00.000Z

Ok, so finally here is the release. It adds Delphi support, which is not a limited set like in lcms 1.x but a complete wrapper. Every single function in the lcms API is now accesible from Delphi.

lcms 2.1 fixes a number of bugs, adds support for duotone (thanks to a contributor who wants to remain anonimous), resurrects cmsChangeBufferFormat and some features like 2-channels formatters. See the changelog for a complete list of fixes and additions.
.
One important thing about 2.1 is that it has been reviewed for vulnerabilities(Thanks Chris!) so it may be a good idea to upgrade from 2.0 whatever possible. The transition should be smooth as 2.1 is backwards compatible with 2.0.

Now I'm ready for 2.2 :-)

Release candidate for 2.1

2010-11-03T21:57:00.000Z

CIC18 is coming and I wish to have some fresh release to introduce at that time, so here are two packages as tarball and zip holding the GIT code and some minor additions. Should solve all known glitches up to date. If all is ok, I will do the official release on monday, nov-8. I know, this is a short notice, but the release mostly contains GIT code that has been available for a while.

http://www.littlecms.com/lcms2-2.1.tar.gz

http://www.littlecms.com/lcms2-2.1.zip

Enjoy!

2.1 schedule

2010-09-18T19:12:00.002+01:00

It has been a long time since I posted the first littlecms 2 release. To my astonishment it has been reasonably stable and reliable. Sure, there have been bugs, any software has bugs, that is a fact that software developers already knows very well. But I have not been forced to do a quick release due to a killer bug, so I am happy on how is going all that lcms2 stuff.

Since the old days of lcms1.0, a fresh release of the engine has been available each 6 months, more or less. So now it is time to prepare the coming of 2.1. I plan to do it on November-2010. Then, I am presenting a paper on CIC18 which relates with lcms2 and its unbounded mode, so the new release would be available at that time. This will be a maintenance release, with the addition of Delphi wrapper, the Matlab wrapper and some minor tweaks. BTW, this is already on the git, the release woould only qualify this code and mark it as in the "stable side".

If anybody is interested, I will be also giving a talk in ICC DevCon, this time about on how to build a minimal V2 compliant ICC engine. I will be glad to discuss any questions you have, or just have a beer with you!

Delphi wrapper is here!

2010-07-17T20:09:00.000+01:00

Now from Embarcadero. I didn't code in Delphi since five or more years ago. Found interesting changes, like the unicode thing (all strings in Delphi 10 are unicode).

Otherwise I got some fun creating the wrapper unit. It encapsulates *all* LittleCMS 2 API, so probably this is a great improvement for Delphi folks.

See here the DLL, the unit and a small demo.
http://www.littlecms.com/lcms2_delphi10.zip

The Delphi wrapper will be officially included in lcms distribution in version 2.1, which is scheduled for November 2010. But you can already use this (unsupported) unit.

Enjoy.

Reusing same transform on different pixel types

2010-06-26T18:17:00.001+01:00

I got this question twice, so here are some comments.

cmsChangeBuffersFormat() is gone in 2.0

There is a good reason to do that: optimization

When you create a transform, you supply the profiles and the expected buffer format. Then, the engine, on depending on things like number of channels and bit depth can choose to implement such transform in different ways.

Let's take an example. If you create a AdobeRGB to sRGB transform using TYPE_RGB_8 for both input and output, the engine can guess that the maximum precision you would require is 8 bits, and then simplify the curve and matrix handling to, for example 1.14 fixed point.

This precision is enough for 8 bits but not for 16 bits, so if you change the format after creating the transform to TYPE_RGB_16, you would end either with artifacts or throughput loss.

Remember lcms 2 allows you to close the profiles after creating the transform. This is very convenient feature but prevents to recalculate the transform by reading the profile again. And there are situations, MPE for example when different precision means different tags.

Overall I think the balancing of losing "change format" versus optimization and early profile closing is good. Otherwise you can always create a new transform for each format. Since you can close the profiles after creation, the amount of allocated resources should remain low.

Web color management

2010-05-29T17:09:00.004+01:00

Please take a look to this small toy I've been working on:

What do you read? Ok, maybe you can read dark text as well, but I mean the brighter one.

If you have access to different web browsers, give a try to Internet explorer, Safari and Firefox for example.

I was suspicious about Firefox from a while ago, now that has confirmed my theory. Oh, you can save the JPEG file and open it with photoshop to see the "good" result if you care. hint: Little CMS also works as expected. I will go deeper on this stuff in incoming posts.

Interpolation wars

2010-05-22T10:19:00.001+01:00

15 days after the release, one issue in the packaging and some glitches on linkicc. Still no big bugs. At least the reported ones are not such big to need a 2.1 release... yet.

Little CMS releases have been historically dropped each 6 months, so 2.1 should come on October-November more or less. I have a talk on the ICC DevCon on November, so it would be nice to have 2.1 released to at that time.

Otherwise the git is alive and I'm periodically committing fixes to it. If you are using Little CMS code and don't have dependencies on linux distributions, I would recommend to use git code if possible.

One of those small glitches found is a weird error that was reported by a HP folk days ago. He was seeing
small differences on a CMYK profile when upgrading from 1.19 to 2.0

So, after investigation, I found the reason of those differences: Tetrahedral interpolation being used in 2.0 and Trilinear interpolation in 1.19. Tetrahedral was patented time ago, but now the patent has expired.

In fact, I did see such issue many years ago. On LUT elements being indexed by Lab colorspace, Tetrahedral does not work well. I suspect that's because Luma is uncentered (L is on one axis)

First thing to discard was a code bug. So I tried Max Derhak's SampleICC. To my astonishment, SampleICC is also using trilinear by default. Tried to modify Max code to do the interpolation as tetrahedral and... bingo! the same "bad" results as Little CMS. Up to four decimals. So here we go, the "bug" is in the interpolation algorithm. I checked PhotoShop CS4. It seems to be also using trilinear as well.

Now I have committed those changes to git. Note however, that your are not going to notice any difference but in very few profiles, and even in this case, maximum difference is about 2-3 digital counts (0.5 dE)

2010-05-08T19:16:00.000+01:00

I am pleased to the announce the release 2.0 of the LittleCMS open source color engine.

Version 2.0 is an important milestone, among other improvements, it delivers:

Full implementation of the ICC standard
Improved documentation
Better portability
Easier extensibility

Migration to 2.x branch is highly encouraged.

Little CMS intends to be a small-footprint color management engine, with special focus on accuracy and performance. It uses the International Color Consortium standard (ICC), which is the modern standard when regarding to color management. The ICC specification is widely used and is referred to in many International and other de-facto standards.

For more information, please take a look on:

Main site:

http://www.littlecms.com/
Downloads:
http://www.littlecms.com/download.html

LittleCMS 2.0 release date

2010-04-20T11:46:00.000+01:00

Beta 3 seems stable enough, so now I can set a final release date for lcms2.

LittleCMS 2.0 will hopefully be released on Saturday, May-8-2010

So, if you have found a bug, inconsistency, etc. Please let me know ASAP. Code is now frozen and I will start the final qualification phase. All change requests will be studied before commit, just to minimize risk. Thanks again to all people that has contributed to this project!

Beta3 and release candidate

2010-04-07T09:51:00.000+01:00

Here is beta3. We are almost done, so this is the release candidate.

All known bugs are fixed.
There are some improvements in CMYK interpolation, it is about 20% faster
jpgicc can now apply devicelinks without chrashing
Matlab support is there!

Final release will follow in a month, so if you want to check the CMM in your application, now is a good time to do so. The code seems stable enough, and you will catch small issues .

Beta 2 is ready

2010-03-04T16:45:00.000Z

Time for a new beta. First one was very successful and several important bugs were found and fixed.

Beta2 will focus on quality and documentation, and will rest for a month.

I will give frequent updates on the status of the beta. You can download it from the link on the right.

xput comparative 1.19 vs. 2.0

2010-03-01T16:59:00.001Z

Here is the comparative for the code in git. I will publish beta2 in a couple of days. As you can see the xput improvements are considerable.

1.19
-----

16 bits on CLUT profiles                     : 10.6667 MPixel/sec.
8 bits on CLUT profiles                      : 9.75015 MPixel/sec.
8 bits on Matrix-Shaper profiles             : 3.8638 MPixel/sec.
8 bits on SAME Matrix-Shaper profiles        : 4.28495 MPixel/sec.
8 bits on Matrix-Shaper profiles (AbsCol)    : 10.4507 MPixel/sec.
16 bits on Matrix-Shaper profiles            : 3.92349 MPixel/sec.
16 bits on SAME Matrix-Shaper profiles       : 3.96924 MPixel/sec.
16 bits on Matrix-Shaper profiles (AbsCol)   : 10.6667 MPixel/sec.
8 bits on curves                             : 4.33839 MPixel/sec.
16 bits on curves                            : 4.3944 MPixel/sec.
8 bits on CMYK profiles                      : 4.09626 MPixel/sec.
16 bits on CMYK profiles                     : 3.96924 MPixel/sec.
8 bits on gray-to-gray                       : 24.3902 MPixel/sec.
8 bits on SAME gray-to-gray                  : 24.3902 MPixel/sec.

2.0
----

16 bits on CLUT profiles                     : 10.1394 MPixel/sec.
8 bits on CLUT profiles                      : 10.6667 MPixel/sec.
8 bits on Matrix-Shaper profiles             : 26.2726 MPixel/sec.
8 bits on SAME Matrix-Shaper profiles        : 30.1318 MPixel/sec.
8 bits on Matrix-Shaper profiles (AbsCol)    : 10.5541 MPixel/sec.
16 bits on Matrix-Shaper profiles            : 10.2433 MPixel/sec.
16 bits on SAME Matrix-Shaper profiles       : 9.84615 MPixel/sec.
16 bits on Matrix-Shaper profiles (AbsCol)   : 10.6667 MPixel/sec.
8 bits on curves                             : 30.0752 MPixel/sec.
16 bits on curves                            : 35.3201 MPixel/sec.
8 bits on CMYK profiles                      : 4.19727 MPixel/sec.
16 bits on CMYK profiles                     : 4.26667 MPixel/sec.
8 bits on gray-to-gray                       : 40.9207 MPixel/sec.
8 bits on SAME gray-to-gray                  : 40.9207 MPixel/sec.
8 bits on CMYK profiles                      : 4.3573 MPixel/sec.
16 bits on CMYK profiles                     : 4.55192 MPixel/sec.
8 bits on gray-to-gray                       : 39.312 MPixel/sec.
8 bits on SAME gray-to-gray                  : 40.9207 MPixel/sec.

Speed measurements

2010-02-15T17:31:00.001Z

Here are some performance numbers, measured on my laptop. This is a pretty old compaq nc6400, Dual core T2300E (1.66GHZ) so it should rock in a modern machines. Note how fast transforms go when both profiles are implemented as matrix shaper. The measurements are using the code on git.

16 bits on CLUT profiles.. 5.95238 Mpixel/sec.
8 bits on CLUT profiles...10.5541 Mpixels/sec.
8 bits on Matrix-Shaper profiles..27.6817 Mpixels/sec.
8 bits on SAME Matrix-Shaper profiles...36.5297 Mpixels/sec.
8 bits on curves... 29.2505 Mpixels/sec.
8 bits on Matrix-Shaper profiles (AbsCol)...27.6817 Mpixels/sec.
16 bits on curves... 37.9147 Mpixel/sec.
8 bits on CMYK profiles... 8.90373 Mpixels/sec.
16 bits on CMYK profiles...4.45186 Mpixel/sec.
8 bits on gray-to-gray conversions.. 32.9897 Mpixels/sec.
8 bits on same gray-to-gray conversions ...39.312 Mpixels/sec.

Fixes on github

2010-02-14T18:24:00.000Z

Ok, that seems to be working. I have received a couple of bug reports. Very helpful .There are now two nasty bugs less in the code base. Gray profiles were broken. That didn't work at all. I wonder how that passed the regression tests... ok, there was no regression tests for gray profiles. Now that is fixed as well. I still have to review documentation for some typos, but I think this can wait.

The latest (fixed) code is in the git. Or you can wait for beta2, which will be available on March.

http://github.com/mm2/Little-CMS

LittleCMS 2 on github

2010-02-12T12:05:00.001Z

So here you go:

http://github.com/mm2/Little-CMS

You can review all files in a nice web page and also that makes fair easy to send patches. Many thanks to Richard Hughes for this nice idea!

You can also review the documentation in such way. It is located on 'doc' folder. The tutorial is a good starting point.

Little CMS 2.0 beta 1 is available!

2010-02-05T19:22:00.000Z

Yes, that is. After so much time, all code, documentation, testbed, utilities... all is in the box, and all is working!

In one day or two I will announce the beta availability to the lcms mailing list, but meanwhile, you can be the very first to try it.

http://www.littlecms.com/lcms2-2.0beta1.tar.gz

Enjoy!

Include files

2009-12-10T10:26:00.002Z

Any application using LittleCMS 2 has to include just one header.

#include “lcms2.h”

The header has been renamed to lcms2.h in order to improve the adoption of version 2. In fact, both Little CMS 1.x and 2.0 can coexist installed in same machine. This is very important on platforms like linux, where LittleCMS is nested deep in the dependency tree. Little CMS 2 no longer relies on icc34.h or any file coming from ICC. All costants are now prefixed by “cms” and there is one license for all package.

Lcms2.h does expose the API, and only the API. Unlike 1.xx series, all internal functions are no longer accesible for client applications.

A special case are the LittleCMS plug-ins. Those constructs can access more functions that the API, just because they are supposed to access Little CMS internals to add new functionality. There is a specialized include file for that:

#include “lcms2_plugin.h”

This file should only be included when defining plug-ins. It defines some additional functions and is described in the LittleCMS2.0 Plugin API document.

Requeriments

2009-12-05T16:56:00.000Z

In order to improve portability and minimize code complexity, LittleCMS 2.0 requires a C99 compliant compiler. This requirement has been relexed on Microsoft’s Visual Studio because its wide adoption by industry (VC is not fully C99 compliant). Borland C 5.5 (available for free) has been tested and found to work Ok. gcc and the Intel compiler does work ok.

Backwards compatibility

2009-11-30T19:01:00.000Z

Little CMS 2 is almost a full rewrite of 1.x series, so there is no guarantee of backwards compatibility. Having said this, if your application doesn’t make use of advanced features, probably all what you need to do is to change the include file from lcms.h to lcms2.h and maybe to do some minor tweaks on your code. Profile opening and transform creation functions are kept the same, but there are some changes in the flags. Little CMS 2 does offer more ways to access profiles, so it is certainly possible your code will get simplified. The basic parts where Little CMS 2 differs from 1.x series are:

· Transform flags
· Error handling
· Textual information retrieval
· New non-ICC intents
· Floating point modes
· Pipelines

On internal advanced functions, the underlying implementation has changed significantly. You still can do all what lcms1 did, but in some cases by using a different approach. There are no longer gamma curves or matrix-shaper functions. Even the LUT functions are gone. All that has been superseded by:

· Gamma functions -> Tone curves
· Matrix Shaper, LUT -> Pipelines
· LUT resampling -> Optimization engine

There is no one-to-one correspondence between old and new functions, but most old functionality can be implemented with new functions.

What is new from lcms 1.x

2009-11-29T17:25:00.000Z

First obvious question is “why should I upgrade to Little CMS 2.0”. Here are some clues:

Little CMS 2.0 is a full v4 CMM, which can accept v2 profiles. Little CMS 1.xx was a v2 CMM which can deal with (some) V4 profiles. The difference is important, as 2.0 handling of PCS is different, definitively better and far more accurate.

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.

Documentation strategy

2009-11-28T19:05:00.000Z

Little CMS documentation is hold in three different papers. First one is the tutorial. Its goal is to introduce the engine and to guide you in its basic usage. It does not, however, give details on all available functionality. For that purpose, you can use the API reference, which gives information on all the constants, structures and functions in the engine. The third document is the plug-in documentation. It details how to extend the engine to fit your particular purposes. You need some experience in the core API to write plug-ins, therefore, the plug-in API reference is somehow more advanced that the remaining two.

Aside documentation, there are sample programs that you can explore. Those are located in the “utils” folder. Those programs are also handy in isolation. This is the list of utilities, each one is documented elsewere.

TiffICC
JpegICC
TransICC
LinkICC
TiffDiff
psicc

Documentation!

2009-10-23T16:45:00.001+01:00

Back from vacation. Lots of fun and some time devoted to LittleCMS. As a result, we have now some incipient documentation. There is a tutorial you can read to explore the differences between LittleCMS 1 and 2. The plug-in API is also documented, but the documentation lacks some explanations and is mostly unfinished. The API reference is a work in progress...

Unbounded CMM

2009-09-19T17:22:00.002+01:00

With the drop I'm posting right now (September 19) most of the utilities are now working. You have a tifficc applier, a transicc calculator and a linkicc devicelink generator. As you can see, some names have changed. This is because icclink was clashing with Graeme Gill's icclink from Argyll. This latter is an outstanding utility, and many users may want to have both installed, so I changed the name and get an extra consistency bonus (now all lcms utility names are "whatever-icc")
Now you have transicc (former icctrans) and therefore you can check one of the new features of lcms2. That's what is called "unbounded CMM mode"

What is that? Well, with lcms2 you can use floating point values. That means, you are no longer limited to 0..255 on 8 bits or 0...65535 on 16 bits, but on some profiles you can get out of those bounds and the CMM still works.

Not all profiles does accept that. You need profiles that are implemented using enterly math expressions. Some very simple profiles works in such way, for example AdobeRGB. The sRGB profile does not work because it has curves implemented as tables, but the built-in sRGB does work as instead of tables it uses parametric curves. Also some advanced profiles for digital cameras using multiprocessing elements may work in unbounded mode. Right now it is hard to find any of those, as they are described in an addendum to the ICC spec.

Let's check this feature. Using AdobeRGB to the built-in Lab in transicc:

C:\lcms-2.0\bin>transicc -i AdobeRGB1998.icc -o *Lab
LittleCMS ColorSpace conversion calculator - 4.0 [LittleCMS 2.00]
Enter values, 'q' to quit

R? 10
G? 10
B? 10
L*=0.7287 a*=0.0000 b*=-0.0000

Nothing special, but let's try this one

R? 300
G? 300
B? 300

L*=114.6770 a*=0.0006 b*=-0.0005

Do you see where I'm going? 300 is above 8 bits, and L*=114.6 is a highlight, so here you have an example of what can be accomplised with this mode.

New drop

2009-09-02T19:43:00.006+01:00

Ok, so here is the september drop. That's functionality complete, that means all the functionality is already there and now it remains debugging and stabilizing. I am still in good shape for the schedule, so hopefully the first beta will be available on mid october.

New in this drop:

error logging supersedes error plug-in, which is no longer available (it was a bad idead, indeed)
black preservation intents are working
TAC detection is working.
All tags and tag types are correcly read/written
Gray/RGB/CMYK/Lab/XYZ
Info fns with localization, unicode
Segment maxima gamut boundary descriptor

... And now back to the documentation, that's what is taken most of my time. First documentation draft will be available on next drop.

Black is black (II)

2009-08-14T17:18:00.014+01:00

The second black thing has nothing to do with black point compensation, but is still black-fashioned. That are the black preserving intents. No, this does not belong to normal ICC workflow. ICC has tried to address such need but still there is nothing in the spec.

Let's see what the issue is. Suppose we work in press. Press are very tied to standards, US press uses SWOP and European folks are more toward FOGRA. Japanese people uses other standards like TOYO, for example. Each standard is very well detailed and presses are setup to faithfully emulate any of these standards.

Ok, let's imagine you got an image ad, looking like that. This is a very usual flier, now just imagine instead of getting it in PDF, you get it as a raster file. Say in a CMYK TIFF, ready for a SWOP press. And you want to print in on a FOGRA27!!

Maybe you see no issue over here, but take a look on this:

LittleCMS ColorSpace conversion calculator - 4.0 [LittleCMS 2.00]

Enter values, 'q' to quit
C (0..100)? 0
M (0..100)? 0
Y (0..100)? 0
K (0..100)? 50

C=48.21 M=38.71 Y=34.53 K=1.09

That means, if I convert from SWOP to FOGRA27, the ICC profiles totally mess up the K channel, so a portion of the picture that originally is using only black ink, after the conversion, gets Cyan, Magenta, Yellow and well, a little bit of black as well. Now please realize what happens on all the text in the Flier.

Ugly. I guess the vendor who pays the bill will not be very pleased, right?

So I've added two different modes to deal with that: Black-ink-only preservation and black-plane preservation. The first is simple and effective: do all the colorimetric transforms but keep only K (preserving L*) where the source image is only black. The second mode is fair more complex ans tries to preserve the WHOLE K plane. I'm still checking this latter. If you want to give it a try, please download the new snapshot and build the TIFFICC utility. It already implements those new intents.

Back in black

2009-08-12T19:28:00.004+01:00

I've been lately working hard in two black thingies. Namely, black point compensation and black preserving intents. Black preserving intents are worth of a post, and still there are some subtle bugs, so let's go fot the black point compensation first. BPC has been implemented in lcms for years. It works. So if ain't broken don't fix it. Well, not really. It seemed to me lcms2 would be a good chance to implement Adobe's BPC... oh, that's a nice story.

BPC is a sort of "poor man's" gamut mapping. It basically adjust contrast of images in a way that darkest tone of source device gets mapped to darkest tone of destination device. If you have an image that is adjusted to be displayed on a monitor, and want to print it on a large format printer, you should realize printer can render black significantly darker that the screen. So BPC can do the adjustment for you. It only makes sense on relative colorimetric intent. Perceptual and saturation does have an implicit BPC .

Works like magic but it is quite simple: just a plain linear scaling in XYZ space.

What turns out the real problem: It is easy to implement BPC as long as you can figure out what the black point is. The black point tag doesn't help. There is such quantity of bogus profiles that ICC has deprecated the tag in a recent addendum. It is up to the poor CMM to figure out what the black point is.

And it is a hard task tough. Ok, you may argue, just use the relative colorimetric in the input direction, feed RGB=(0, 0, 0) and ... wait, what about CMYK? Ok, CMY=(255, 255, 255,255)... Hum.. CMYK devices are ink limited, that is, the maximum amout of ink that a given paper can accept is limited (else ink will spread all over) so this doesn't work either. What lcms do, is to use perceptual intent to convert Lab of zero to CMYK and then this CMYK to Lab using rel. colorimetric. This works fine on all but some broken profiles. Well, Adobe's paper target those profiles.

The funny part is the complexity of Adobe's algorith. The perceptual trick is used as a seed on certain profiles, then black axis of a round-trip on L* is examined. If the difference is greater than 4, then a least-squares fitting of the curve to a quadratic curve should be done. The black point is the vertex.

In fact it is more complex as I'm ommiting constants depending on the intent and other gory details. Such complex. After the 6th time you read the paper, it begins to make sense.

But unfortunately it doesn't work to me. And unfortunately, it doesn't work for the ICC reference implementation CMM. We both get the same bad guess of L* = 625 for a given profile. And guess what? I've tried Photoshop CS4, and the reported black point does exactly match with my humble, perceptual to rel.col. algorith, so I will keep this one for a while.

New drop available

2009-08-04T17:47:00.002+01:00

August drop is here. Working features are CMYK, black point compensation, all profile I/O ...
Enjoy!

Sleep your bugs

2009-08-01T10:16:00.011+01:00

It hurts. Its a sort of burning... when you figure out where is the bug, you experience an urgent necessity of fixing it, NOW! Big mistake.

It is not clear if was Knuth or Hoare who coined the phrase:

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

It is indeed very true. I would like to add a humble corollary:

premature bugfixing is lame too.

So, here is my advice: Sleep your bugs.

I am not talking about typos. You know, misspelling 'l' and '1' for example (nobody should use 'le0' as var name, '1e0' is still a valid number) or failing to include a range check (last time I forget to place an 'if' I got a Pwnie nomination)

I am talking about logic bugs. Something wrong with the algorithm or the true logic of the program. Adding inconsistent features is another example.

Sleep those kind of bugs. Take good note of them, and wait a day or two in fixing. Probably you will find a neat way to deal with the issue without changing those hundreds of lines. Maybe not, but even in this case the solution is worth of the wait.

In my case the bug was black point detection. lcms2 is now an unbounded CMM that operates on floats. So the black point detection code was using floating point to do the calculations. Yep, it seems a nice feature: far more precision, etc. On the other hand, inks on floating point are represented as %, so the effective range is 0..100%, that is how Photoshop and others do work and I thought it makes sense to keep the feature in lcms2 as well.

Put both features together and you have a nice logic bug: extra code is needed on BP detection to deal with different ranges.

If you happen to be a professional programmer, you surely realize that my advice of postpone bug fixing goes against the schedule, the program manager and the planner. Sure, but that's lcms2, my pet project which has unlimited resources on time. Would be a dream for a commercial project, but this project is not commercial and therefore is not subjected to schedule tyranny.

By the way, a new drop of lcms2 is in the way and will be available in a day or two.

Less is more

2009-07-27T19:53:00.006+01:00

If you have devoted some time to review the new API, maybe you have discovered an odd thing: there are some functions missing. Ok, you can blame me for remove *that* function doing exactly what you need. Of course that may be my mistake. But please consider perhaps I have good reasons to do that.

Let's take one example:

cmsReadICCMatrixRGB2XYZ(LPMAT3 r, cmsHPROFILE hProfile);

This function no longer exists in lcms 2.0 API.

Well, many people were using this function to retrieve primaries of a profile. So, for example, if you want to know which are the AdobeRGB primaries, just call the function with the right profile and here you go.

Seems easy, and useful, but trust me, it is not. The real reason d'être of this function is somehow surprising. Not because it is handy but because is precise. Please consider this piece of pseudo-code:

cmsXYZTRIPLE Result;
hXYZ = cmsCreateXYZProfile()
xform = cmsCreateTransform(hProfile, TYPE_RGB_DBL, hXYZ, TYPE_XYZ_DBL, INTENT_RELATIVE_COLRIMETRIC, 0)
cmsDoTransform(xform, {{ 1, 0, 0}, {0, 1, 0}, {0,0,1}}, &Result, 3)

Do you follow it? I create a transform from the profile (in RGB) to XYZ. Then I convert max of R, and B to XYZ. I am obtaining the primaries! Despite it seems more complex, this method is much better because is guaranteed to work in *any* profile, not only on matrix-shaper ones.

So, what is the point of having the old function? Easy: lcms 1.x was precission-limited to 16 bits, so you cannot obtain primaries with enough precision with the method described above. But that does not apply with lcms2, where you have an outstanding 64-bit double precission. Less is more in this particular case!

Linking tags

2009-07-23T19:50:00.002+01:00

Implementing the tag link feature has been easier than I originally thought, but there are some caveats.

lcms2 does support some new features on read/writting profiles. You can use cmsReadTag/cmsWriteTag to read/write lcms objects like LUTs, tone curves and so. You can also use cmsReadRawTag/cmsWriteRawTag to read or write whatever you want, but poor library does not do any checking or understanding on whats going on.

You can also link tags to items created by any of those two methods. So far so good.

But wait, you can also write plug-ins to add more "understood" objects in cmsReadTag/cmsWriteTag and also you can write plug-ins to add new types for those objects.

In addition to all that, there is a brand new structure added as an addedum to ICC spec 4.2, that is the MPE or multi profile elements. This is worth of several comments in this blog. Basically that may make photographers and precission yonkies very happy as it includes *true* floating point numbers, among other things. There is a plug-in type devoted to MPEs. More to come.

So, if you consider all all those acess methods should be consistent, we have a nice mess. The good news are it seems to work, the bad news, we need more testing. But overall I see progress.

Fear not!, maybe I will even accomplish the schedule and realease the whole thing on November.

ZOO Doppelgänger and the Link feature

2009-07-22T20:18:00.006+01:00

To some extent, old'n'good lcms allowed profile editing. That was a "dangerous" feature in the sense people may abuse of it to grab copyrighted material. That is, you may open your favourite profile to remove the copyright tag, and here you go. Obviously preventing that by the hard way is just like killing the messanger, so this feature is working in lcms and is up to you to use -or abuse- it.

But reviewing the previous entry about the zoo, I had a wild idea: if the zoo test reads every single tag, what if then I try to rewrite all those tags? that would create a Doppelgänger version of every profile in the zoo, but not necesarely with same organization and size.

The test code was written in few minutes, and after I run it, poor lcms2 get into hyperspace and crashed badly.

Ok, five bugs ahead, I got the writting/copying feature working. But this also has unveiled how profile vendors abuse of the link feature. That is, since a tag is described by some block in the file, I can put two or more different entries in the tag directory pointing to the same location. Humm.. I have to add some code to deal with this case.

Profile ZOO

2009-07-17T19:00:00.006+01:00

The serialization part is now complete. That is, lcms2 should be able to read all tags it understands on all profiles in the wide world. Since it understands all tags that are, or have been part of any ICC spec, present or past, a lot of profiles should be readed by current code.

I have been lately worried about stability and qualification. If lcms2 want any success, it should be tolerant with ill-formed profiles. I say tolerant, not permissive, because crafted profiles may be used by the bad guys to introduce exploits. We don't want wargames again, right?

I have compiled along the +10 years of lcms life, a "Zoo" of profiles. This collection includes actually about 1500 assorted profiles, going from the widely distributed v2 sRGB to rare corner cases, like devicelinks holding 12-ink separations. Not to be very common.

Some of those profiles are broken. Well, not completely broken. They have slightly malformed tags, like colorants using a bad type, descriptions with wrong char count, bad sizes in the header...

To check how well lcms2 may deal with that, I wrote a small program that runs across every single profile in the Zoo and then reads every tag in the profile. The code should reject the unuseable tags and behave nicely if some information can be recovered. It cannot in anycase segfault or leak resources.

So, keeping my fingers crossed, I executed the program and ... almost! one segmentation fault. Ok, it was a bug, fixed. Run it again and .. success! no memory leaks, lots of tags discarded and a cool "all is ok" printf'd at the end. Pfew!

Same profile on both sides

2009-07-14T19:39:00.005+01:00

It is very convenient to detect whatever the source and destination profiles are same to instruct the CMM to do nothing. Seems quite simple but it is certaily complex.

The issue is on embedded profiles. You can't do a binary compare because embedded profiles may have changed attributes. That is, some fields in the profile header are different to reflect the preference on intent and the fact the profile is being used embedded.

V4 offersProfileID, which is an MD5 checksum of the profile avoiding those conflicting fields. Which is a good thing: if both source and destination profiles does have same ProfileID AND the intent is same on both profiles, then you can get rid of the whole transform as it is basically a no-op.

But sometimes (most of times, currently) you get AdobeRGB or sRGB embedded, which are v2 profiles. No Profile ID, and a very common case.

So, let's try to do some optimization. If both profiles are matrix-shaper, you can detect if the obtained matrix is an identity, and then if the curves are cancelling. We have room for improvement in 3 cases:

All different
Same primaries but different gamma
Same primaries and equal tone curves

Last case is a no-op, but is pretty frequent: untagged images assumed to be sRGB and uncalibrated monitor assumed to be sRGB. Handling this case separately is a big plus if you care about speed.

More on speed

2009-07-11T17:27:00.005+01:00

As promised, I have updated the snapshot. The performance numbers on matrix-shaper to matrix shaper should be close to what lcms2 is going to deliver when released. If you want to run the testbed, you would need to copy those profiles from Photoshop distribution, as I'm not allowed to redistribute that:

AdobeRGB1998.icc
CoatedFOGRA27.icc
UncoatedFOGRA29.icc
USWebCoatedSWOP.icc
USWebUncoated.icc

Put them on the "testbed" folder. Ok, now just type

./configure; make; make check

Then take a look on the numbers at the end of the testbed execution.

tifficc utility should also work to some extent, but there is a 1-pixel caché that may give bad performance. I have to turn caché off for such profiles as the caché code takes more than the transform itself.

It is funny to note that this is pure "C" code, and in some situations outperforms SSE2 hand-written assembly. That was the case when using the Intel compiler.

64-bits hardware is pretty untested, so if you manage to make it work on such architectures, please drop me a note, thanks!

about speed

2009-07-09T15:01:00.003+01:00

I'm getting outstanding results with lcms2 and matrix-shaper profiles. It is still not on the public preview, so you have to trust me, but here are some numbers. That's tested on my laptop which is an old 2GHz 2-core CPU:

lcms 2.0:
8 bits on Matrix-Shaper profiles...done.
[625 tics, 0.625 sec, 25.6 Mpixels/sec.]

lcms 1.18:
lcms is transforming full spectrum in 8 bits...done.
[3984 tics, 3.984 sec, 4.01606 Mpixels/sec.]

Thats a boost of about X 6.3. Please note that applies only to 8 bit matrix-shaper to matrix-shaper transforms, so RGB only! When primaries of both profiles are same, the performance is even better, it reaches about 30 Megapixel/second. I will put all this code available this weekend.

Tag plug-in

2009-07-06T13:32:00.004+01:00

Related with cmsReadTag, here comes one of the easier plug-ins to write: the tag plug-in.

Imagine you are a printer vendor and want to include in your profiles a private tag for storing the ink consumption. So, you register a private tag with ICC, and you get signature "inkc".

Ok, now you want to store this tag as a Lut16Type, so it will be driven by PCS and return one channel giving the relative ink consumption by color.

Writing a plugin in lcms2 will allow cmsReadTag and cmsWriteTag to deal with you new data exactly as any other standard tag.

To do so, you have to fill a cmsPluginTag structure to declare the plugin. This structure is formed by a base, which is common to all plug-ins.

plugin.base.Magic = cmsPluginMagicNumber;
plugin.base.ExpectedVersion = 2.0;
plugin.base.Type = cmsPluginTagSig;

That latter identifies your plug-in as "tag type". Now we need to define the tag signature

plugin.signature = 'inkc';

And some additional info about the type used by your tag:

How many instances of the type the tag is going to hold (usually one)
in how many different types the tag may come (again, usually one)
and then the needed type(s).

plugin.descriptor. ElemCount = 1;
plugin.descriptor. nSupportedTypes = 1;
plugin.descriptor.SupportedTypes[0] = cmsSigLut16Type;

That is all. You can setup the new functionality by calling

cmsPlugin(&plugin);

Advanced tag plug-ins may use polymorphic types, depending on the version of the profile for example. Instead of one type, you can declare several. Then the read tag logic will search for all supported types to find the suitable one. cmsSigLut16Type for v2 and cmsSigLutBtoAType for v4 for example. There is an optional callback function to decide which type to use when writing the tag.

cmsTagTypeSignature DecideType(double ICCVersion, const void *Data);

This plugin is most useful when combined with the tag type plugin, which will be discussed soon.

cmsReadRawTag

2009-07-04T17:40:00.002+01:00

Today I've finished the cmsReadRawTag/cmsWriteRawTag interface. It may seem a poor accomplishment, but in reality that means the serialization engine is now complete.
In lcms2 you can read a tag from an open profile by doing

tag = cmsReadTag(hProfile, TagSignature)

And lcms will return (if found) a pointer to a structure holding the tag. Simple, but not simpler as the structure is not the contents of the tag, but the result of parsing the tag. For example, reading a cmsSigAToB0 tag results as a LUT structure ready to be used by all the cmsLUT functions. The memory belongs to the profile and is set free on closing the profile. In this way there are no memory duplicates and you can safely re-use the same tag. Writing tags is almost same, you just specify a pointer to structure and the tag name and lcms2 does all serialization for you. Process under the hood may be very complex, if you realize v2 and v4 of the ICC spec are using different representations of structures.

Anyway, you may decide all that is useless and your want just to write/read bytes to the profile, in this case the Raw variants are for you.

Plug-ins

2009-07-03T10:02:00.004+01:00

One of the main improvements of lcms2 is the plug-in architecture. Plug-ins means you can use the normal API to access customized functionality. Licensing are another compelling reason, you can move all your IP into a proprietary plug-in and still be able to upgrade core revisions in open source. There are 10 types of plug-ins currently supported.

Memory management
Error management
Interpolation
Tone curve types
Formatters
Tag types
Tags
Rendering intents
Multi processing elements
Optimizations

I will discuss each type in incoming posts. Plug-ins are declared to lcms by a single function

cmsBool cmsPlugin(void* Plugin);

And the "Plugin" parameter may represent one or several plug-ins, as defined by the plug-in developer. To write plug-ins, there is an additional include file lcms2_plugin.h, which declares functions which are not in the public API but may be useful to this task. For example I/O access, matrix manipulation, and all the types needed to populate the plug-in structures. Those functions begins with "_cms" to denote those are extended functionality and should not be called the application by rather by the plug-in.

The probe profile

2009-07-02T13:40:00.005+01:00

"Jimmy Volatile" a Lcms user, suggested to incorporate test plots for the regression tests. In this way external apps using lcms could check if all is working as expected. I think this is a good idea, and maybe it is also feasible (all depends on the schedule).

An interesting check would be to use the ICC probe profile. This comes from the ICC site:

"The 'probe profile' (Probev1_ICCv2.icc) is syntactically a v2 ICC output device ('prtr') profile, and can be used in a workflow wherever such a profile is required. The color space of this profile is CMYK, and its PCS is Lab.

Colors processed via this profile are deliberately distorted in a systematic way, to enable visual determination of the rendering intent used when rendering ("BToA" or PCS to device transforms) and when proofing ("AToB" or device to PCS transforms). This is useful, in cases when color-management-aware software does not document the behavior."

Here are some examples

Regression tests

2009-06-30T10:30:00.004+01:00

Right now it is pretty clear lcms2 would need an exhaustive test bed if we want some sort of robustness in the code. I'm spending a lot of time with this program. It began as a small one and now it is a huge file of 5600 lines. Maybe I should split it in several modules...

My intent is to have a test on every single feature. Since this is close to impossible, the actual test is focused on usual cases. Now the question, what are usual cases? Sure, sRGB to screen and aRGB to printer output are pretty common, but there are people over there using lcms1 to do multi-ink separations on 12 channels. Why I should not check this case as well? Another big area that deserves careful testing are plug-ins. How should the code base react to a wrong plugin? is a segfault admissible in this particular case?

When/where to clip?

2009-06-29T14:03:00.006+01:00

An interesting effect I've found, you can reproduce it with Photoshop CS4 as well. Set the working space as sRGB, intent relative colorimetric, no BPC. Then using color picker enter this Lab value:

0, -120, 0

As you can see, the obtained RGB values are 0, 0, 0. So far so good. Or not? Try this other Lab value:

0, 0, -120

Oops! now we got 0, 27, 182! What's happening? The answer, as far as I can tell, is clipping. If you take the work (I did) of implementing Lab -> XYZ and then XYZ -> sRGB by using entirely floating point formulas, the second value of 0, 0, -120 getting converted to some color with lots of L* is just a consequence of the math. From where it comes all this L*?

lcms does clip negative XYZ numbers, so in both you will obtain 0, 0, 0. What makes me wonder is why photoshop does clip one axis (a) and does not clip the other (b) in the same fashion?

Maybe is just clipping XYZ negative numbers? Ok. lcms2 gives 0, 48, 0 for a Lab of 0, 0, -120. This is the result of not clipping anything at middle stages and letting XYZ negative numbers as well. Clipping happens only on the last stage or when is absolutely required (indexing LUTs, for example). I guess more experimentation is needed in this part...

Threads and cmsThreadID

2009-06-27T15:15:00.006+01:00

One of the things lcms 2 is different to lcms is multithreading support. That is, indeed, a difficult feature. One may argue that just avoiding global variables should be enough to support multiple threads, but I think this is not necessarily true. Sometimes some global settings have to apply to all threads. On the other hand, it would be desirable for error handling and memory allocation to have some clues on which are the thread currently active or the environment where the current operation takes place.

So the solution I've found is the cmsThreadID type. That is just a void pointer.

Most of the high-level functions in lcms2 does have two forms. The first one is defaulting the ThreadID parameter to zero, which means "user don't care about threads". The second form allows to specify the ThreadID. This ID will be passed to memory allocation, error handler and plug-ins, so the user code may be smart enough to react differently on different threads. One example is to use different memory pools, which is useful, among others, when a given thread crashes and you want to recover gracefully.

Related functions :

cmsThreadID cmsGetProfileThreadID()
cmsThreadID cmsGetTransformThreadID()

And all functions with THR ending the function name, for example:

cmsHPROFILE cmsCreateRGBProfileTHR();

Hello, World!

2009-06-27T12:47:00.003+01:00

Howdy and welcome. This is an informal blog dealing with color management stuff. More precisely, this blog will discuss all the gory details I am facing when writting the version two of littlecms. I think people over here would already know what am I talking about, but if it not your case, see here an abstract.
So what is the blog about? Mainly software architecture. I would like to discuss the reasons I'm designing the API in such way or why that specific limitation. To what extent this would be a good idea, time will tell... stay tuned!