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
Friday, June 10, 2011
Thursday, June 2, 2011
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:
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
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 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
Monday, January 10, 2011
Happy new 2011!
I would like to begin this year with a comment for a recurrent question:
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.
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.
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.
http://www.color.org/ICC_white_paper_6_v2_and_v4_display_profile_differences.pdf
Many thanks Kai-Uwe for catching the bug!
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!
Wednesday, December 1, 2010
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 :-)
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 :-)
Wednesday, November 3, 2010
Release candidate for 2.1
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!
http://www.littlecms.com/lcms2-2.1.tar.gz
http://www.littlecms.com/lcms2-2.1.zip
Enjoy!
Saturday, September 18, 2010
2.1 schedule
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!
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!
Saturday, July 17, 2010
Delphi wrapper is here!
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.
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.
Saturday, June 26, 2010
Reusing same transform on different pixel types
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.
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.
Subscribe to:
Posts (Atom)