Issue #2011: Add support for SwatchBooker's SBZ color palette format

This patch attempts to resolve #2011 (closed) (and check an item off the roadmap) by letting users import SwatchBooker's SBZ palettes.

SBZ is a "zipped XML" format, with all palette information stored in an internal swatchbook.xml. Supported color models are RGB, Grayscale, CMYK, XYZ, HSL, HSV, and Lab. In practice, the only SBZ files you'll actually find in the wild use Lab. 😄

Scribus and Krita both support these palettes, although each has their own quirks. Scribus does not seem to render "GRAY" color models correctly (looking at their code, they don't check for it on import). Krita does not seem to render "CMYK" color models correctly (when I checked the latest version, colors listed as shades of cyan show up as white).

Edit: While working on this, I noticed that imported palette column information is ignored. I have added an additional small commit to let the Import Palette dialogue retrieve and set the number of columns if the file specified it.

Sample Files

• SwatchBooker sample.sbz
• FreieFabre 370+ Lab palettes

@Jehan Hello! I have several questions about implementation whenever you have time:

• I used babl_format ("R'G'B' float) to convert the palette colors from their Swatchbooker format to RGB (which is what GIMP currently expects the palette format to be I think). Is that correct (at the moment at least)?

• For CMYK color models, there's a profile folder in the .sbz with the *.icm files. A few questions about that:

  • Should these saved to the user's settings permanently (e.g. if I open an .sbz with 10 profiles, I now have those 10 profiles accessible in GIMP whenever I want)? (I immediately realized the same thing happens when we load images, haha)
  • Does GIMP create duplicate profiles if you load the same one multiple times (e.g. if I open three .sbz files with Fogra27L.icm, will I end up with 3 copies of Fogra27L stored in GIMP or are duplicates automatically discarded)? (Same as above)
  • My thought was to add a list of structs that hold the GimpColorProfile and a gchar * with the filename, and then reference that whenever loading CMYK palette colors (the metadata for CMYK colors includes the profile filename). Does that sound reasonable or am I overcomplicating it? (Also implemented - hopefully the right way!)

• Currently I load the palette in the order they appear. There's a <book> tag at the bottom that provides an order using the dc:identifier information. My thought was to call gimp_palette_get_colors () once I reach the <book> tag to get the GimpPaletteEntry list, then use gimp_palette_move_entry () with the list indexes to move entries into the right order. As with CMYK, does that sound reasonable or am I overcomplicating it? (I found similar code elsewhere in GIMP, so I just implemented it. Hopefully it's okay!)

• On a related note, gimp_palette_load_aco () uses GimpCMYK and GimpHSV for palette conversions to RGB. Would you liked those switched to using babl in a future commit? (Implemented with !849 (merged)).

I also have a question about a memory leak I think I'm causing when storing the tags, but I'll ask about that on IRC.