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.
- New libgimpcolor functions: gimp_color_parse_hex() and gimp_color_parse_name().
- GimpColorHexEntry is now space-invaded. Though recognized color names
and hexadecimal syntax are sRGB only (because CSS and SVG
specifications explicitly say that this syntax is for sRGB values), it
is possible to enter non-sRGB values with
gimp_color_hex_entry_set_color().
- GimpColorSelection is now space-invaded.
We historically have both the colormap and palette concept in core GIMP,
though they are actually kinda the same concept, except that with
"colormap" we work with an array of raw data and it's a lot less
color-aware. It is still much more efficient in some specific cases,
such as when converting the image (we can then convert the whole palette
as a single buffer, because the image palette is space-restricted
anyway), when storing undo data or when storing/loading in XCF.
But for all the rest, let's use gimp_image_get_colormap_palette() and
work with the GimpPalette API.
By default a palette can contain any mix of color models and space. These new
internal API add a concept of format/space restriction. For now this will only
be used for indexed images whose palette should only contain colors for the
specific palette format and space (at least as currently implemented in GIMP).
I still see some limitations in GimpGradient, and in particular, they are still
always stored as RGB in GGR files. It would be nice if we could store the actual
color format. This way, if someone chooses a gradient stop as Lab or CMYK color,
that's what the gradient file would keep track of. But also even storing the
space of a color (instead of storing/loading always in sRGB, even though this
may still work fine as we store unbounded double values). This might warrant for
a v2 of GGR file format.
This commit also fixes loading of SVG gradient which was apparently broken
regarding hexadecimal color parsing.
Finally I improve gegl_color_set_alpha() by adding an alpha channel when the
initial format had none.
The invasion extended to some core widgets too, in particular GimpColorPanel (a
subclass of GimpColorButton). There was quite a lot of code depending on these
widgets.
This includes improvements on the out-of-gamut colored corner being shown for
unbounded component types out of the [0; 1] range (with some small margin of
error to avoid e.g. a -0.0000001 value to show as out-of-gamut).
There are still improvements to be made on the color rendering. In particular,
it still draws as CAIRO_FORMAT_RGB24 cairo surface. We should probably move to
draw as CAIRO_FORMAT_RGBA128F eventually (more precision and even allowing to
draw unbounded colors with a possible option, instead of always clipping).
Also adding the libgimpwidgets API gimp_widget_get_render_space().
This one is kind of a huge deal, because the info returned by the color frame
was kind of messy (even though it improved lately, but space associated to color
data had to be kept in-sync by hand, which was bug-prone).
Now the color frame stores the data as a GeglColor, always aware of its space
and therefore able to do much nicer conversion. Also RGB and Grayscale options
now display the profile name of the color space (until now, we had only this for
the CMYK option using the proofing profile).
I still wish to get more options. Typically some people may want to get
RGB/Grayscale/CMYK values to other spaces (maybe sRGB, one of their favorite
profile as set in Preferences or just any random profile which they could load
from disk). Giving such ability to basically live-convert their pixel data to
various other color space would be very nice. We'll see if this will be
implemented for GIMP 3 or for after.
- New function gimp_cairo_set_source_color() which is meant to replace
gimp_cairo_set_source_rgb(a?)() eventually. This new function sets the Cairo
source color, using the target monitor's profile of the widget where the Cairo
surface is meant to be drawn on. It also uses the color management settings
(such as whether a custom profile was set, instead of using system profile, or
also simply whether color management was disabled at all). It doesn't
soft-proof the color yet.
- Padding and out-of-gamut colors drawing now use the new
gimp_cairo_set_source_color(). These don't need any soft-proofing anyway.
- Out-of-gamut color property in GimpColorConfig is now a GeglColor property.
We pass 2 GeglColor through the wire now. Since it is passed very early
(when sharing the configuration), I had some issues with initialization
order of GEGL, and in particular when calling gegl_init() before
gegl_config() inside _gimp_config(), I had a bunch of such criticals:
> Plugin script-fu: GLib-GObject: CRITICAL: Two different plugins tried to register 'GeglOpPlugIn-transform-core'
Anyway in the end, I store the passed colors as raw bytes and strings in
the GPConfig object, and re-construct the GeglColor last minute in
_gimp_config().
This fixes weird behavior when changing only the alpha value of a color, e.g. in
the channel color GUI. The before and after colors were considered the same. Now
they won't.
In particular, let's accept small margin of errors to determine that a value is
out of the [0; 1] range of its color space.
The specific use case is about a component at -0.000001 (or at 1.000001) which
will even just show as 0 (respectively 1) in the GUI and will be marked as
out-of-gamut. We want to avoid such thing to happen.
I also took the opportunity to get rid of a bit more GimpRGB code.
One of the big improvement in this commit is that text layers are now much
better at space accuracy. They were already space-aware, yet rendered as sRGB u8
only before being converted to the image's space. It means that text layers had
the following limitations:
* Any color out of sRGB gamut were trimmed.
* Precision was always 8-bit (even if the image was high-bit depth).
Now GimpTextLayout keeps track of its source space (for RGB and CMYK only, this
won't be as easy when we will support more backend, since Cairo has only RGB
support for image data) and the image TRC (in case it bypasses the color space's
TRB) and it draws within this gamut and space.
It means first that we are not limited to sRGB colors; we will draw text main
color in the full image gamut, with still 2 remaining limitations:
* Unbounded colors are impossible because Pango format (to color text) uses
hexadecimal (so even with half/float images, you can't draw out-of-gamut text
unfortunately).
* Main color precision is still 8-bit, yet a tiny bit better than before as we
at least follow TRC (so we avoid some of the precision loss when converting,
even though the bit-depth is still the biggest loss).
The outline color on the other hand is drawn through Cairo API entirely, in
float. This means that the outline color will now be without any precision loss.
Note that this depends on CAIRO_FORMAT_RGBA128F which is only available since
Cairo 1.17.2 which is not in Debian bookworm (our current baseline for GIMP
3.0). It means that the old precision will still happen with older Cairo
version, as determined by #if code at compilation.
I moved the function to select a valid contextual RGBA format as a core API
gimp_context_get_rgba_format(). This same API is now used in context actions, as
well as in the GimpDeviceStatus widget.
The latter now shows per-device fg/bg colors relatively to the active image's
format. The tooltip will also display contextual information (i.e. either the
image's name whose space is used, or sRGB).
Of course, this all updates when switching images by connecting to the
image-changed signal.
In space invasion world, we want color-related code to be contextual. When we
say "Increase/Decrease the red/green/blue channel by X%", it would actually mean
something different if you are working on a sRGB space or a wider gamut space.
Furthermore, it means also something different if you work on linear/perceptual,
overriding the space's actual TRC.
This is why this new code takes the active image into account and uses this as a
base for the space and TRC you are working on. In case you have no active image,
it defaults to the current GeglColor space (though really this case should not
matter too much). In case your image is not RGB to begin with, it uses sRGB
space.
Some old config files will contain (color-rgb) contents. Also some data, such as
historical tool presets (.gtp files) will have such values in their
(tool-options).
- app: gimp_context_get_(foreground|background)() are now returning a GeglColor.
- libgimp: PDB functions named similarly in libgimp are returning a newly
allocated GeglColor too.
- A few other PDB functions (the ones using these functions) were updated and
their signature changed to use GeglColor too, when relevant. Plug-ins which
use any of the changed libgimp functions were fixed.
- GimpContext: signals "(foreground|background)-changed" are now passing a
GeglColor.
- libgimpconfig: new macro GIMP_CONFIG_PROP_COLOR using gegl_param_spec_color().
- GimpContext: properties "foreground" and "background" are now GeglParamColor
properties.
- app: All code interacting with GimpContext objects were updated to receive a
GeglColor (that they may still convert, or no, to GimpRGB for now).
- app: gimp_prop_gegl_color_button_new() was added as an alternative to
gimp_prop_color_button_new() when the property is a GeglParamColor. Eventually
the former should replace completely the latter.
- libgimpwidgets: gimp_prop_color_area_new() now works on GeglParamColor
properties only.
- libgimp: gimp_procedure_dialog_get_widget() will generate a GimpColorArea for
GeglTypeParamColor arguments.
Also the color is internally stored as GeglColor, though there are still get
APIs and signals using GimpRGB.
The equivalent PDB functions are also changed to use GeglColor, same as app/
functions.
… gimp_color_is_perceptually_identical().
gimp_color_is_perceptually_identical() is meant to replace gimp_rgb_distance()
which is anyway always used to decide whether 2 colors can be considered equal.
So rather than having a distance algorithm which we won't be able to change
later on (if people start relying on specific values), let's just give the
answer directly on what's a same color (perceptually) or not.
Also now the distance is computed through the intermediate color space LCh which
seems to be one of the most perceptually uniform space, therefore a good choice
for such an algorithm (comparing distances on a non-perceptual uniform space
doesn't make very much sense, since a same distance may be perceived differently
in different subspaces).
This is a first commit to really getting rid of GimpRGB within core and
PDB/plug-in code. This will make color conversion reliability a lot better as
GeglColor will handle conversions for us. The goal is that we should keep origin
color space (for instance when picking colors in a GimpPickable, or when storing
in the FG/BG colors or in paletters) until the last second and convert at use
only.
It's still very much work-in-progress.
These 2 functions were removed in commit 89c359ce. They were in fact used and
clearly this historical API seems interesting (though we can likely do the same
thing using the drawable GeglBuffer, but this way is much easier).
This is now reimplemented using GeglColor instead of raw data.
Eventually this is meant to fully replace GimpRGB (as well as GimpHSV, GimpHSL
and GimpCMYK), both in libgimp and in core code, as part of both the space
invasion and the API rework. For this first commit, I keep this new object side
by side to GimpRGB.
gimp_drawable_filter_apply () is affected
by the active selection. This causes display
glitches when merging all filters or
undoing a merge while an active selection
is on the image.
This patch saves the current selection,
clears it, merges/unmerges the filters,
then reapplies the selection to avoid the
problem. In the future, this should be
re-examined (when filter masks can be
edited).
Jehan