With his recent GSoC work, Krisztian Pinter managed to add support to load LO's own .soc and Gimp's .gpl colour palette formats.
Another very popular format for colour palettes is Adobe's .ase format.
It's supported by Adobe Photoshop and Adobe Illustrator. A popular website to create colour palettes is https://kuler.adobe.com/.
To ease implementation, there are already some implementations available:
A GPL-licensend reader in Python: http://utilitymill.com/edit/ASE_File_Data_Reader
A new BSD-licensed reader in C++: https://code.google.com/p/gpick/source/browse/source/uiExport.cpp#277
We might just piggy back on the latter and reuse their code (if the license is compatible).
If you like this issue, please consider donating for it via FreedomSponsors.org: https://freedomsponsors.org/issue/570/add-adobe-ase-colour-palette-support
I'm interested in working on this bug. Just wanted to check what is required licensing-wise to port the C++ code Philipp linked to. According to this page, the licenses are compatible: https://www.mozilla.org/MPL/license-policy.html#Licenses_Compatible_with_the_MPL
.ase is a quite simple format - you can just write it from scratch and avoid license issues. Porting would probably need a half rewrite anyway. In  you can find all you need to implement support. All you need additionally is only an example file with known entries.
I see some entries can be in CMYK - you need to convert those to RGB like this is done in .
(In reply to Tomaz Vajngerl from comment #3)
> .ase is a quite simple format - you can just write it from scratch and avoid
> license issues. Porting would probably need a half rewrite anyway. In 
> you can find all you need to implement support. All you need additionally is
> only an example file with known entries.
> I see some entries can be in CMYK - you need to convert those to RGB like
> this is done in .
>  http://www.selapa.net/swatches/colors/fileformats.php#adobe_ase
Perfect, thanks. One other small thing. When I go to the Area menu and click the Color tab, I am not able to load .gpl files. I can only load .soc files based on the extension filters of the load file dialog. Is this a bug?
Support for .gpl was added only to the new color picker. What area tab has should be considered deprecated and will be removed once a global solution is in place (grown from the the color picker), but currently nobody works on that.
Gerrit change: https://gerrit.libreoffice.org/#/c/14661/
Thanks, looks good. I'll try and review the patch ASAP.
Chris Laplante committed a patch related to this issue.
It has been pushed to "master":
tdf#84002 Add support for .ase color palettes
It will be available in 4.5.0.
The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
Thanks Tomaz - I'll add a note about this in the 4.5.0 release notes. Should it go under Core or GUI?
Maybe GUI. If someone thinks it is wrong, he will move it to a "correct" place.
This bug fix is mentioned in the release notes of the coming LibreOffice 5.0 (see release notes https://wiki.documentfoundation.org/ReleaseNotes/5.0). Therefore it would be wonderful if this feature really worked well, otherwise it should not be mentioned in the release notes. In the notes it reads:
Support for reading Adobe Swatch Exchange (.ase) color palettes. Handles CMYK, RGB, and grayscale color models. LAB colors are not yet supported, and are replaced by black during import. (tdf#84002, sponsored by LibreOffice users through FreedomSponsors.org) (Chris Laplante)
Disregard the previous comment. That user has been spamming everyone with that comment, apologies.
(In reply to Adolfo Jayme from comment #12)
> Disregard the previous comment. That user has been spamming everyone with
> that comment, apologies.
Please consider my clarifying statement:
(In reply to Mike §chinagl from comment #11)
> (...) LAB colors are not yet supported, and are replaced by black during import.(...)
Why not interpreting the L-component at least making gray-scale (better than just black)?