Hi all, Thanks for the replies. I didnt have a look at Pigment, but since Krita can handle a huge amount of colour models, Im not sure whether its use would be overkill. A library would have to handle only three colour models, namely RGB, CMYK and CIE L*a*b*. Traditionally, palette files were either in RGB or CMYK. If they contained spot colours they were marked as such and were either stored as RGB or CMYK. As of Adobe CS 6, however, colours in palette files are being stored as CIE L*a*b* values. RAL and Digital Color Atlas had already practiced this for years. This means that colour transformations are only required in the following cases: - L*a*b* -sRGB profile -RGB (also necessary if its aCMYKpalette and the programme cant handle CMYK) - L*a*b* -document CMYK profile -CMYK - L*a*b* -sRGB / document CMYK profile -RGB/CMYK spot colour - pure L*a*b* if the programme supports it, otherwise fallback to sRGB Im no expert, but this could probably be done using lcms2. I also forgot two other wide-spread formats for palettes not documented by Olivier: EPS and AI (both EPS and PDF-based). These files are as complex as a recipe for meshed potatoes ;) Scribus includes code for importing both of them, and Im pretty optimistic Franz will re-license it under the MPL to DLP.
Christoph Gesendet:Montag, 06. Oktober 2014 um 19:31 UhrVon:Inge [email protected]:David [email protected]:[email protected],Christoph [email protected]:Re: [documentliberation-discuss] Library for colour palette formats? On Monday, October 06, 2014 03:48:14 PM David Tardon wrote: Hi, On Mon, Oct 06, 2014 at 02:07:37PM +0200, Inge Wallin wrote: On Monday, October 06, 2014 06:12:29 AM Christoph Schfer wrote: Hello Document Liberators, During a conference in Switzerland (http://swiss-publishing-week.ch/) I was asked by pre-press professionals if open source graphics programmes support Pantone colours. As you may imagine, this required a complicated answer, because the question was already wrong. The correct question wouldve been: Do they support colour palette formats that contain the colour values and names, as well as the colour models (RGB, CMYK, spot, CIE L*a*b*). So the answer was that some programs support some formats, and some support the relevant colour models, but on Windows and *nix (except Mac OS X) you can use SwatchBooker to convert them (http://www.selapa.net/swatchbooker/) into the necessary formats. Since most of them use Mac OS that wasnt an encouraging answer to them. Hence my idea to create a library which allows FLOSS programs to read these formats. Swatchbookers author, Olivier Berten, has already documented most of them, so no re-engineering would be required. See: http://www.selapa.net/swatches/colors/fileformats.phpA few less important formats are still missing, and I have sample files for them. Since SwatchBooker is written Python and licensed under the GPL 3, its not possible to reuse any code, but its possible to look at the code (and Swatchbooker itself) to see whats required (colour management and CIE L*a*b* support, among others). Im no coder myself, but since Im talking about extremely simple formats, I think an experienced programmer might be able to create something useable in a very short timeframe. Such a library would help users who want to switch to Free alternatives carry their Pantone, HKS, whatever, palettes over to the new software. Anyone interested? Kind regards, Christoph The paint program Krita, which is part of the Calligra suite, supports all of these color models (afaik) and many many more. This is supported by the Pigment library that you can look at here: http://quickgit.kde.org/?p=calligra.gita=treeh=6a06ba79d7ab5593931a29c98 f21b98259b8ec6dhb=a73d1228e5fbebdf8cb833c480a26ec22c026777f=libs%2Fpigme nt Some documentation can be found here. https://community.kde.org/Calligra/Libs/Pigment Please use and improve this and dont create an incompatible new library. Pigment is entirely irrelevant here, because the question was about parsing various color pallete file formats, not color space transformations. AFAICS Pigment does not do that. This shows a lack of forward-thinking. Pigment does not merely store the color spaces or transform them, there is naturally also code to load and store it from files. Tbh I am not sure if that code is in Krita or in pigment itself but rest assured that there is such code somewhere in Calligra. Also: 1. Pigment is a part of Calligra. AFAICS it cannot even be built separately -not usable for other projects. This is true. But if the choice is to look at Pigment and extract it from Calligra or something new from scratch I would think the choice to be easy. 2. Pigment depends on Qt -not really usable for projects that are not already built using Qt (especially for multiplatform ones -- noone is going to bundle Qt in Windows and OS X builds just as a dependency for an external library). This is also true. But again, it would be far far easier to transform Pigment into Qt-free code and add a Qt wrapper to it wherever needed than to write it from scratch. The Qt wrappers could be kept inside Calligra too if nobody else wants it, or they could be provided by a part of the new stand-alone Pigment release. I think the best way forward is to contact the Krita people who maintain Pigment and start a discussion with them. The place to do that is probably the Krita mailinglist which is [email protected] historical reasons. -Inge -- To unsubscribe e-mail to: [email protected] Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.documentliberation.org/www/discuss/ All messages sent to this list will be publicly archived and cannot be deleted
