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.

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.

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

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 :-)