Get a better native palette format.
Closed, ResolvedPublic

Description

GPL is nice and straight forward, but cannot handle anything more complicated than 8bit sRGB.

We need a format that can...

  1. Handle other spaces than (s)RGB
  2. Handle HDR values (2.0, 0.5 ,3.4)
  3. Embed ICC profiles.

We have two options:

Swatchbooker's big disadvantage is that there's no clear specification. There's a little outline on the website, but it's not quite right...

For example, according to the website, I should be able to specify the following:

<color usage="spot">
  <metadata>
    <dc:identifier>G5</dc:identifier>
    <dc:title>Gray 50%</dc:title>
  </metadata>
  <values model="Lab">50 0 0</values>
  <values model="GRAY">0.5<values>
  <values model="sRGB">0.5 0.5 0.5</values>
</color>

And it would be desirable to have such a thing: it allows fall back mechanisms for programs without color management.

But none of the existing swatchbooker files in the wild have this setup, probably because swatchbooker itself wasn't that flexible yet? At the least, the people at http://freecolour.org/ didn't seem to realise that identifier and title are different beasts.

Swatchbooker's other disadvantage is of course that it doesn't run on modern distros anymore, meaning we can't really test anything.

Other Issues

  • I also mentioned this in the palette docker task. but we should come up with a mechanism for differentiating and differently using spot colors as opposed to non-spot colors.
  • How to make use of localised strings inside the swatchbook?
  • Swatchbooker has groups, should we spent some time on making the docker able to display these groups nicely?

Comments:

We have two options:

SwatchColor, that would clearly be the (semantically) richest option available. However, localization support in either KoColor or KoColorSetEntry is needed - apart from an id field to support dc:identifier (see below).

But none of the existing swatchbooker files in the wild have this setup, probably because swatchbooker itself wasn't that flexible yet? At the least, the people at http://freecolour.org/ didn't seem to realise that identifier and title are different beasts.

AFAIK, in color swatches e.g. Pantone, dc:identifier is the name as well as the unique identifier of the color (i.e. it's non localizable). I guess the dc:title is for custom colors?

How to make use of localised strings inside the swatchbook?

From what I see in the SwatchBook spec, one specifies the locale with xml:lang. It should be possible to specify one dc:title per locale and then parse them as needed.

I also mentioned this in the palette docker task. but we should come up with a mechanism for differentiating and differently using spot colors as opposed to non-spot colors.

Scribus, SwatchColor and Corel all support spot colors, so parser support is also needed (I'd have to write it).

Note for future: we also need to be able to add translated names in the new palette format.

Swatchbooker's other disadvantage is of course that it doesn't run on modern distros anymore, meaning we can't really test anything.

I have it running in Ubuntu 16.04 LTS. As python-liblcms and liblcms1 are gone after Trusty, you need to manually download and install them from packages.ubuntu.com, then download SwatchBooker-0.7.3.noinstall.zip and run python swatchbooker.pyw.

Coming back to SwatchBooker, I'd like to add parsing support for it, but I don't know what to do with:

  • localization (how to store and access translated names?)
  • spot color management (same as Wolthera above)
  • a color with multiple definitions i.e. it has a value for sRGB, another for Lab, another for CMYK, and so on)
  • ICC color spaces inside the SBZ file (should they be recognised and loaded accordingly?)

Well, we're setting up a native file format similar to SBZ but then using our native KoColor object in the T4121 branch. It reads from a zip and extents the spot and saves icc... look at that code first. We're not sure about multiple definitions ourselves yet.

Probably, we should say that when faced with multiple definitions, we follow a list like this:

  1. Gray
  2. XYZ
  3. LAB
  4. RGB
  5. CMYK
  6. YCrCb
  7. sRGB

with the first one we find being the type of color we use of it.

@rempt makes :( faces whenever I mention the localisation... We will probably need to talk about it during a meeting.

rempt added a comment.Oct 29 2016, 6:56 PM

I think that we should just not allow multiple definitions for a color: I am not at all convinced it makes a much sense. Besides, we don't have internal support for that and adding that kind of support is going to cause big complications.

rempt added a comment.Oct 31 2016, 1:26 PM

When it comes to translation, there are two levels:

  • translate the resources that come with krita
  • share resources that contain translations

There are currently no resources in actual use whether from gimp, photoshop or krita that contain translations.

The first issue can be solved by putting i18n in the right places in the loading code and extracting messages like we do for gpl palettes.