This is meant to obsolete GeglParamColor with at least an additional argument
has_alpha which we need in GIMP. It allows to advertize when a parameter wants
an opaque color, which in particular means we know when displaying a GUI to pick
colors with alpha or not.
While doing this, I could find a lot of problems in the algorithm:
1. It looks like the original intent (from GUI and code) is that you set hue and
saturation but not really the intended lightness, rather its increase or
decrease, relatively to every pixel current lightness. I.e. that every pixel
will be set to the selected hue and saturation, and only the lightness will
change. The "lightness" field is therefore a relative value (pixel per
pixel). The first problem is that instead of lightness, we compute the
luminance, which is related but different and set this in the lightness
field.
2. The second issue is that we were using gimp_hsl_to_rgb() which after testing
(because its documentation doesn't give any TRC/space info at all) looks like
it computes a color from HSL to non-linear RGB of the same space. Yet we were
outputting to a linear RGB space. So we compute the wrong values. On the
other hand, because of the first problem, I realize (after testing) that it
makes our render closer to the intended render by chance (at least when the
TRC is sRGB's). It's still wrong, but if we were to change the output to
"R'G'B'A float" instead, the render would be much darker. In both cases, it's
wrong anyway.
I would not say that the 2 problems are canceling each others, but they are
making the final result somewhat OK.
3. Ideally we should be using babl to convert colors, and this is the best way
to actually implement the original filter intent. Unfortunately so far, doing
this is much slower (though I save a lot of time by moving out of the samples
loop and processing data in chunks, it's still slower than the current,
nearly instant, implementation).
4. Because of all previous implementation irregularities, the render is
different depending on the actual image space. I.e. that the exact same image
filtered through Colorize with the exact same operation parameters will
render differently. I would need to test further, and maybe it's normal since
HSL is also space-dependant (and that's where we work on in this operation),
but I'm wondering if the result should not be independant of the working
space.
5. I implemented our own prepare() method because the one in
GimpOperationPointFilter parent seems to allow other input or output models.
Even though in all my tests, it was always linear RGB (which is what we want
here), let's make sure by having a custom prepare() method explicitly setting
these. It's also the opportunity to create some babl fishes.
In any case, I'm leaving the code as-is for now, because it's how this operation
has been since forever (at least for as long as I was around) and I don't think
it's the right idea to change it on a whim.
This raises even more the concern of versionning GEGL operation, which we have
been discussing with pippin on IRC lately, because if ever we want to change
this one, now that operations are not just applied, but possibly
non-destructively recreated at load, we need to make sure that we recreate the
render expected at the time of creation of a XCF while allowing us to have the
filters improving when needed.
