So... As part of the palette changes in the palette format branch, I want to make it possible to always have a palette file that is possible to store inside the kra. What this is suppossed to solve is formalising a digital artist trick regarding palettes.
So... when an artist is managing their colors, especially when an artist is doing a limited palette, there's three ways this is done:
- Mixing palette. This is only really possible for situations where the colors can be mixed, glazed or scumbled(That's like, oil paints, watercolors/markers and crayons). The solution to this problem is a little scratchpad docker and is discussed in this forum thread,and this forum thread, and finally, in this bug report. It's been discussed in detail and not quite what this is about.
- A gamut mask. This is a method where we take a hue-sat slice of the total palette(representing the possible gamut in the current olorspace) and then we restrict the possible colors by using a geometrical shape that masks it. This is a very lighting-concious way of looking at colors. This is something that can be implemented in the internal color selector, at some point, or we can implement it in the artistic clor selector, or we can implement one in the other, or... etc etc etc bugreport
- Palettising. This is a method where the colors are carefully chosen beforehand, and necessary for situations where the colors cannot be mixed, such as vectors or flat/cel shading. This is usually what the palette docker specialises in. However, this is also used in mixing arts. Often artists will make a mini-palette on canvas. While the scratchpad docker can solve this, Krita itself doesn't understand the colors in the scratchpad docker as colors, but rather as an image, so forexample, you cannot use filters or something that analyses the colors on the canvas with the scratchpad image as an input. My point is, there's a benefit to being able to store definitive colors that are per-canvas, and it'd be super-convenient if we were able to store this within the kra itself.
Right now there's no actual resourcesystem-resources that are saved into the kra file. We can save resource-definitions into the kra file and the workspaces, but not for example, a palette file into a kra file in a way the resource system understands. (Saving things into kra files itself is quite simple)
So here then comes the problem with that:
- We have a palette that only exists during krita runtime, it doesn't have a corresponding file on harddisk, only in the kra file.
- This palette needs to be understood as linked to the kra file it is stored in.
- We make a change, what happens?
- The palette is saved, stored in the kra file, and the kra is saved? - This can become messy with autosaves.
- The palette is only remembered as changed, and only saved when the kra file changes? - This will need teaching the resource server that while this resource can be changed, it's saving will need to be handled by the kra-saver.
- Or, we temporarily store the palette file onto disk somewhere when the kra file is open, do everything to that, and save that to the kra file. - Then, where do we store it? And how do we make sure that it is deleted from disk when say, krita crashes?
- How do we name the palette? Like, we name it with the name of the document, like "<<Palette of Bla.kra>>", but then what if bla.kra is named to drawing.kra, how do we tell? How do we propagate this change? And, if we make kis_image the owner of the palette, how do we even get that information??? (The image doesn't know what it's name is, that's the document doing that)