Sunday, June 30, 2013

LittleCMS 2.5 released

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

Version 2.5 is a maintenance release focused on the error handling and non-happy path, implements the black point compensation algorithm as disclosed by the ICC and  adresses several minor issues.

See the changelog for further details.

Saturday, July 28, 2012

Why when I convert from linear space I got dark shadows posterization?

This question has been raised a number of times across the years. The first time I faced it was with JDK incorporating lcms1. They had a test profile that was somehow giving bad results when optimized. After close inspection, the profile was found to be operating in linear XYZ space. The complaint was almost the same: when I use linear space as input, optimization doesn’t work. Otherwise, all other combinations are ok. And this seems to be also the actual case; all other combinations are working fine. Try for example to reverse the transform going from regular sRGB to your linear space, you will find all the issue are now gone.

But anyway, there is this case that seems to fail. And that’s true: on this particular case, some dark shadows got a dE > 1.5 if using the default settings. Fine, it happens that for this extreme case, the defaults don’t work. This is the reason why there is called “default” and there is a setting to control it.

So, the short answer is: don’t optimize when using a linear XYZ space as input in 16 bits transforms.

But I guess you want also the long answer. So, here you go.

When you use lcms to create a color transform joining two or more profiles, you are creating a devicelink profile. You don’t see it as a file; it lives in memory, and is destroyed when you delete the transform. But it is there.

Devicelinks can be implemented in different ways, for example they can be implemented as a set of curves, or by a matrix, or by a 3D CLUT table, or by a combination of all elements above. Some of those ways are better than others in terms of xput, others are better in terms of image quality. CMMs have to “guess” which is the best combination of elements for a given set of profiles. There is balance between quality and performance. For some corner cases, optimizing for speed can effectively introduce defects on quality.

The best devicelink representation often depends on the true nature of the space described by the profiles. Specially the input space, But then… the profile only gives you a way to convert form/to Lab to its space, and gives no other clue about the space nature.

An example of ill-formed spaces are those that are operating in linear XYZ gamma space. You should NEVER user linear gamma to store your 8-bit images. Why? Because in 8 bits you have 256 levels, and in linear gamma the separation between those levels is not perceptually uniform. That means you have very few levels to encode the effective dynamic range of your image and many levels are wasted in highlights. Hold on, you would say, RAW images are encoded in linear gamma and they work quite well, isn’t it? You are right… but I said 8 bits, remember? If you move to 16 bits or floating point, you can still use linear encoding, but with some care.

Back to our methods to encode devicelinks. One used by lcms when the transform converts form 16 bits to 16 bits, is a CLUT table. This is just a 3D (or 4D in CMYK) grid with nodes. Pixel values are interpolated across nodes. For example, the distortion you get when going from sRGB to AdobeRGB is stored in a 3D grid of 17 nodes on each R, G, B side. When a pixel arrives, the corresponding nodes that enclose the value are selected and the result is interpolated. In our 17 node example, a value of, say, (100, 100, 100) will go on the 100*(17-1)/255 = 6.7 so the nodes 6 and 7 of each side will be taken for interpolation.

Le’s now take a linear space. Since as said, many colors are collapsed to a relatively few codes due to the gamma encoding, almost all dynamic range is confined to few nodes. That mean In a 17 nodes grid, most image dynamic range will fall in 5 or 6 nodes. And this is the reason you got posterization in shadows: most of dark tones falls in just 1-2 nodes and linear interpolation cannot deal with the non-linear nature of the transform linear-gamma 2.2.

How to solve this? The most evident way is to not use 3D CLUT optimization. The CMM already does that if you use floating point, or if you use 8 bits. In lcms2.03 there is some experimental flag that tries to solve this issue adding an extra tone curve cmsFLAGS_CLUT_POST_LINEARIZATION and cmsFLAGS_CLUT_PRE_LINEARIZATION. I have checked that and found to solve this issue as well.

So, that is the reason why you only see this issue when converting from 16 bits to 16 bits with default flags. Placing a NOOPTIMIZE in all transforms would prevent problems, but at big performance penalty that is hard to explain just to fix this specific case. It is like you have a Ferrari but you go always at 25Mph just because once upon a time you faced a winding road.

My recommendation for programmers would be to allow end user to turn optimization off for general usage, or at least to provide a specialized workflow for RAW handling with optimizations turned off, that is the only place when linear XYZ makes sense. For users, I would recommend to NEVER use linear XYZ spaces. They are good for nothing, nor for storage, nor for image processing. The very few algorithms that need to be done in linear can do and undo the conversion when processing. But anyway, there are people with strong opinions on this field and everybody is free to do whatever they want. This is just a recommendation, please don’t take it as a stone-engraved truth.

Hi and howdy!

After so much time I'm retaking this blog becuase release date of 2.4 is getting near. The new release has many improvements and maybe it would be interesting to comment those in detail. Stay tuned!

Friday, December 16, 2011

LittleCMS 2.3 released

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.

Wednesday, November 2, 2011

I've uploaded a tarball with lcms2-2.3 release candidate:

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.

Friday, June 10, 2011

LittleCMS 2.2 released

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.

Thursday, June 2, 2011

Updated browser check images

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

Monday, May 30, 2011

lcms 2.2 release candidate

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:

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

Any feedback is very welcome

Thursday, March 10, 2011

ICC/HP Digital Print Day

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

Abstracts should be submitted to 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.

Monday, January 10, 2011

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.

Friday, December 17, 2010

Multithreading question

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.

Friday, December 10, 2010

Absolute colorimetric intent

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.
Many thanks Kai-Uwe for catching the bug!