- 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).
Resolves#10802.
Since the GimpProcedureDialog port, the Windows version
of the Screenshot plug-in has been missing the
"Screenshot Delay" option. This is because Windows did not
have the SCREENSHOT_CAN_DELAY_WINDOW_SHOT enum
set. Adding that back in restores the option.
Here, the instructions was hard to find in the middle of maintainer stuff.
Also, be able to build GIMP without dev-oriented distros is something very
desirable, and the gimp-web-devel is the suited place fot it.
Jehan