When changing the selected color, we have no reason to redraw the Z preview.
This preview should only be redrawn if the allocation size changed, or if we
change the previewed model or the Z component.
As for the XY preview, it should only be redrawn if the Z value is changed (and
of course, similarly, if the allocation changed or if model or Z component
changed).
With "HSVA" and a few others, the function was not returning the right value (it
could not see it was encoding alpha channel.
I had fixed it on babl directly with commit a28309c yet I had forgotten to push
it! Let's just add some #ifdef and a comment.
No custom conversion code anymore. This also fixes some bugs in HSV when
I was wrongfully multiplying the hue by 360 when mixing babl and custom
code paths.
It's actually not enough to get proper colors for inner text tags. The
main color is correct, but color for subtext is currently not managed.
This must be fixed.
In particular, the Curves, Levels and Operation tools method implemented
are updated. Also GeglColor arguments in GEGL operations are not
transformed into GimpRGB arguments anymore in GIMP. GeglColor GParamSpec
stay GeglColor now.
We don't try anymore to convert early from a pickable color to another
format/space. Now we are able to get a GeglColor and move it around,
doing only last-second (when needed) conversions.
I'm a bit unsure about the GimpMyBrushCore which doesn't have much
indication on which color space we are working in, but the new code
should not be worse than the old one (if wrong, color-wise, it should be
the same wrong as before).
Until now we only had the case of the CMYK color selector using the
soft-proofing profile. Yet this is also interesting for other color
selectors, in particular to show out-of-gamut colors. Indeed if we
enable soft-proofing on the active image, it is interesting to show the
intersection of the current RGB/Grayscale space gamut with the
soft-proofing gamut.
Right now, this is only used in GimpColorSelect when showing colors in
LCh color space.
This is used for the gimp_color_is_perceptually_identical() function,
because the Euclidean distance in LCH is extremely limited, if not wrong
in many cases. Indeed LCH is not perfectly perceptually uniform, and for
this exact reason, the CIE defined the specific Delta E algorithms.
Later versions are also based on LCH values, so my intuition to use it
for distance was on a good start, yet these algorithms were refined a
few times to allow for corrections in perceptual uniformity
imperfections.
This was in particular needed to verify if a color is out of a CMYK
space gamut. The idea is to compare the distance of the RGB (or other)
and the CMYK version, since we cannot just check if the CMYK color is
out of the [0; 1] range (it never is). Instead if both colors are
perceptually identical, then we consider that the RGB color was inside
the CMYK space gamut.
The naive algorithm was giving any (or nearly) color as out-of-gamut.
Now using CIEDE2000, I get a much nicer results.
This commit adds gimp_color_selector_set_format() which is meant to give
awareness of the target color format for which we are selecting colors.
Right now, I am only using this information on the Scales selection
method, which means that now colors you read and select are in the
target space. Even better, the out-of-gamut shown happens in the with
LCH scales is for the target space too. As tested, it already makes
quite a difference for an image in sRGB vs. say adobeRGB.
Note that right now, I only use the format information as a space, but
in fact, I made the API to be about a format because the actual format
can be used wisely too. First we may want to do different thing
depending on the color model itself (which the space may give away or
not, especially when using default spaces or when we'll have images
using models with no space in the future, such as CIE Lab). But also
whether the image is following the space TRC or is linear (or
perceptual) would change how we represent the data. If we were to show
non-linear values in the Colors dockable but when painting, the color
picker shows linear values for instance, it might be puzzling to people.
Only the color dialog was getting simulation updates when the active
image changed, or when the simulation profile changed (while the active
image stayed the same). Now the Colors dockable also get updates.
Somehow, in some cases, the event box is not getting button events. I
had the case when creating new images (though it was working fine when
loading images!). I could not yet understand the issue looking at both
GIMP and GTK code and could not even reproduce by creating simple code
sample reproducing a similar pattern (an inactive button inside an event
box placed above the button and meant to catch click events).
This works as a workaround for the time being.
What this commit does is keep the same code logic while moving to
GeglColor. Yet it's not **really** space-invaded yet. What we need to do
now:
1. Take into account the image space, and this is what we must navigate
through, in particular for various representations of RGB or HSV.
I.e. that if the active image is in anyRGB, the RGB values shown must
be within anyRGB. Right now, everything is still shown/used as sRGB
(even though it's properly retrieved and transformed to the target
space thanks to GeglColor).
2. Show space info to make things clear and explicit, by adding some
label somewhere.
3. Allow to switch between image and softproof spaces, regarding
out-of-gamut display. I.e. that while RGB/HSV must be shown within
the image space (assuming it's anyRGB), we may want to show
out-of-gamut area (pink areas) within the softproof space. This may
mean adding a checkbox. Or maybe simply taking into account whether
we are in softproof mode or not?
4. We can likely move off gimp_widget_get_color_transform() into using
gimp_widget_get_render_space() for display drawing. We don't need any
soft-proofing or black point compensation for any of these widgets so
pure babl is fine. Indeed we want to show any in-gamut color
correctly (and not transformed according to specific intents or
through soft-proofing). We will take care of the proofing case with
out-of-gamut area showing only.
5. In the various drawing functions, we should move to
CAIRO_FORMAT_RGBA128F. The color selection area might be wide enough
that it makes sense to be more accurate, especially as we are
essentially showing color gradients in 1 or 2 directions in these
various widgets.
I also changed a bit the new color serialization by adding a (color …)
symbol framing the contents, for cases where we don't have a specific
property name, e.g. for the color history list stored in colorrc, unlike
for GimpConfig GeglColor properties.
While doing this, I moved GeglColor property deserialization code into
gimp_scanner_parse_color() which is now able to recognize both older
(color-rgb|rgba|hsv|hsva with no color space) and newer serialization
formats ("color", color model agnostic and space aware).
Serializing palette colors is not possible right now as far too much
additional data are required, and anyway we likely wouldn't be able to
associate back the color to the right palette on deserialization,
removing any interest of keeping the index data anyway.
With that context in mind, let's just serialize palette data as basic
RGB within the palette's space.
Jehan