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.


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


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




-Inge




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