Gents,
Having watched the conversations that have gone on here in the past
couple of days about LCMS2 and possible things that people would like to
see happen with it, it seems a sensible time to break cover with an
announcement.
Artifex Software are about to fork LCMS2.
I'll go into the reasons for this now, and say a bit about why you might
care, and why you might not.
Artifex Software has used LCMS2 in Ghostscript for a while. It's served
us very well, and we are very happy with it. Marti worked with us to
make some changes when we incorporated it to ensure it could work with
Ghostscripts way of handling multiple threads. This work has been in
mainline LCMS2 for several releases.
Accordingly, when we were looking for a color management engine to use
in MuPDF (another of our projects), we wanted to use LCMS2 too.
Unfortunately, the way LCMS2 is currently set up to handle
multi-threading is not quite general enough.
(Technically, Ghostscript creates profiles/links etc from multiple
different threads, but only uses a given profile/link in the single
thread in which is is created. Objects are never shared between threads.
MuPDF has a more general approach to such things, and objects are
frequently created in one thread, and used in multiple ones, often at
the same time)
There is no way to fix this in LCMS2 without breaking the API.
We went ahead and changed the API in our own copy, and found that what
we ended up with was:
* a very small conceptual change (basically, all the functions are the
same as the 'cms...THR' functions were before, in that every function
that might allocate memory takes a ContextID).
* a smaller API overall (we no longer have the cms...THR variants of
the API functions)
* a cleaner implementation (IMHO) (we no longer ever store a ContextID
in an LCMS2 structure)
* One extra change; in lcms2, the number of 'extra' channels available
to a transform is limited to 7. We've tweaked the order of the
format specifier bits to lifted that to at least 63 (with room to
increase it further in future).
We offered these changes back to Marti, but he is (understandably, and
correctly) reluctant to break the API. One possibility would be to have
a new major LCMS release (LCMS3 ?) in which the new API became standard,
but Marti has plans of his own, and it's not clear how this fits in.
In the meantime, the release date for the new color-management capable
version of MuPDF is looming. Because MuPDF is open source, this means we
effectively need to do a release of our modified LCMS2.
In order to do this in the least intrusive way possible, we've decided
to call our release LCMS2.art. The plan is that every time Marti does a
release of LCMS2, we'll do a parallel release with our changes in.
We've renamed the include files to be lcms2art.h, so you can't
inadvertently mismatch the 2 versions. We've tweaked the version define
and the check for it, so that if you try and link an lcms2art with a
program that expects lcms2 (or vice versa), you'll get an error.
Our intent is to keep as close to mainline as we can, so we can share
fixes both ways, and hope that we can rejoin the 2 forks at some point
in future (on the next major release hopefully).
So, why should anyone other than us care?
Well, if you're wanting to use LCMS2 in a threaded environment, then it
might be worth considering using our fork rather than mainline LCMS2.
Otherwise, you probably want to stick with mainline.
It shouldn't take more than an hour or so to move from mainline LCMS2 to
our tweaked API (or vice versa), as they really are very close.
The latest version of our code can be found at:
git.ghostscript.com/thirdparty-lcms2.git
in the lcms2-art branch. Or via the web on:
http://git.ghostscript.com/?p=thirdparty-lcms2.git;h=lcms2-art
Robin
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user
