We need to figure out a format for serializing wide-gamut and out-of-bounds gradient formats, if only because Krita needs that serialization in various places.

Our options...

Use what KoStop/SegmentGradient has in toXML/fromXML

Pros:

• These use KoColor::fromXML, etc. Also used by the saving of filter configuration.
• Also supports serializing the segment gradients.
• We can throw in our own nonsense.

Cons:

• There's some really odd things going on with the way these handle 32F cmyk and lab, the palettes are also affected by this:

KoColor c9 = KoColor::fromXML("<color channeldepth='F32'><Lab L='0.5' a='0.5' b='0.5' space=''/></color>");
    qDebug() << KoColor::toQString(c9);
    qDebug() << ppVar(c9);

Gives...

QDEBUG : TestKoColor::testSVGParsing() "Lightness 50 a* -0.5 b* -0.5 Alpha 1"
QDEBUG : TestKoColor::testSVGParsing() c9 = KoColor ("LABAF32", "Lightness":50, "a*":-0.5, "b*":-0.5, "Alpha":1)

(In general, our lab and cmyk handling is weird, and I suspect I need to spend some more time with the lcms manual, a lab description book and all of the css-color definitions to sus out what is going on here. We keep working around it with 'geez, our lab handling sure is weird', but I am getting sick and tired of that)

Todo:

• Decide on a mimetype and format.
• Decide whether or not we want to store the colorprofiles alongside the xml definition like we do for KPL.
• Write a lot of unittests (for KoColor)
• Unittests for the gradients.
• Solve the mysteries of LAB and F32 CMYK in Krita. I'd at the least want something coherent in the apidox.
• Write documentation for Create swatches. (Done: https://invent.kde.org/documentation/docs-krita-org/-/commit/198ac6cf6c5bf2ac95e45329732d66984684aa6e)
• Solve mystery of F32 CMYK or decide to always bound CMYK to U16. (or both!)

SVG11 on SVG gradients

MERGED

Pros

• Actual published standard.

Cons

• Not supported out of inkscape and scribus, and inkscape's lab handling is weird too but like, a different kind of weird, because we all use LCMS.
• No support for segment gradient related things.

Todo:

• MR 675 now has unittests and the like for this format, but I need to dig through the mysterious world of LAB (and or CMYK) before I am totally cool with this. We might even say that for now, we'll just not parse and serialize LAB specifically.
• Decide whether we really care about XYZ enough. As Inkscape has a really weird way of serializing it (X and Z are 0-2, according to them).
• Actually implement this in the gradients and stuff.

CSS-4-color on SVG2 gradients.

Pros

• Actually has a good definition for handling lab.
• THE FUTURE™, necessary for SVG2

Cons

• Draft
• REALLY BIG
• No support for segment gradient related things.

CSS4 supports...

• sRGB definitions through Hex, css-colornames, and RGB(50, 05, 10) (We already have the code for this)
• HSL (Formula already in Krita)
• HWB (Formula not yet in Krita)
• Lab (Same old problems)
• LCH (formula already in Krita)
• Color from profile. (Kinda what SVG11 does, but different syntax) Has the following default colorspaces (files are not expected to embed these and thus Krita may have to generate them if there's no ready profiles available. We have the same issue in T13556 with NCLX):
  • sRGB
  • XYZ
  • LAB
  • Rec2020 (with 1/2.4 transfer function)
  • Display-P3
  • Adobe 1998
  • Prophoto
• Color name from profile (we can pull this data from LCMS)
• Device-CMYK (that's cmyk that has a defined way of falling back to sRGB if there's no profile defined for it).

The HDR spec adds to this...

• More default colorspaces:
  • Rec2020 PQ (yay, we has this one)
  • Rec2020 HLG :(
  • Jzazbz, a PQ based LABesque model.
  • JzCzHz a PQ based LCHesque model.
  • ICtCp another perceptual model, but like, really fancy U GAIZ.

I'm not even sure how we'd tackle the last three with LCMS... like, one of them might be a separate lab profile, and another I could derive from that, but ICtCp is a mystery to me.