[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Aw: Re: [documentliberation-discuss] Library for colour palette formats?

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.

Gesendet:Montag, 06. Oktober 2014 um 19:31 UhrVon:Inge Wallininge@lysator.liu.seAn:David Tardondtardon@redhat.comCc:discuss@documentliberation.org,Christoph Schferchristoph-schaefer@gmx.deBetreff:Re: [documentliberation-discuss] Library for colour palette formats?

On Monday, October 06, 2014 03:48:14 PM David Tardon wrote:


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


asked by pre-press professionals if open source graphics programmes


Pantone colours. As you may imagine, this required a complicated


because the question was already wrong. The correct question wouldve


Do they support colour palette formats that contain the colour values


names, as well as the colour models (RGB, CMYK, spot, CIE L*a*b*). So


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


use SwatchBooker to convert them (http://www.selapa.net/swatchbooker/)


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


formats. Swatchbookers author, Olivier Berten, has already documented


of them, so no re-engineering would be required. See:

http://www.selapa.net/swatches/colors/fileformats.phpA few less


formats are still missing, and I have sample files for them.

Since SwatchBooker is written Python and licensed under the GPL 3, its


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


about extremely simple formats, I think an experienced programmer might


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,


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:




Some documentation can be found here.


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.


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 calledkimageshop@kde.orgfor historical reasons.


To unsubscribe e-mail to: discuss+unsubscribe@documentliberation.org
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

Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.