This patch attempts to resolve #2011 (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.
- SwatchBooker sample.sbz
- FreieFabre 370+ Lab palettes
@Jehan Hello! I have several questions about implementation whenever you have time:
babl_format ("R'G'B' float)for the conversion format. 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(Same as above)
Fogra27L.icm, will I end up with 3 copies of Fogra27L stored in GIMP or are duplicates automatically discarded)?
My thought was to add a list of structs that hold the(Also implemented - hopefully the right way!)
GimpColorProfileand 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?
Currently I load the palette in the order they appear. There's a(I found similar code elsewhere in GIMP, so I just implemented it. Hopefully it's okay!)
<book>tag at the bottom that provides an order using the
dc:identifierinformation. My thought was to call
gimp_palette_get_colors ()once I reach the
<book>tag to get the
GimpPaletteEntrylist, 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?
On a related note,
GimpHSVfor palette conversions to RGB. Would you liked those switched to using babl in a future commit?
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.