This completes the GimpRGB API removal
project for the color space invasion.
Note that the GIMP_RGB_LUMINANCE macro is
temporarily moved to gimpcolor. It does not
require GimpRGB but was included in gimprgb.h.
We have a bunch of special-casing format passing through the PDB, but
either we were only passing the encoding, or else we were reconstructing
the full format through private intermediate functions. In the
space-invasion world, this is not right. Let's have a proper "format"
type for PDB which does all the relevant data-passing for us, once and
for all!
Note that I am creating a wrapper boxed type GimpBablFormat whose only
goal is to have recognizable GValue since Babl types don't have GType-s.
Moreover I'm not using the GeglParamSpecFormat either, because it just
uses pointers which again are a bit annoying in our various PDB code.
Having a simple boxed arg is better.
GimpRGB replaced with gdouble arrays.
Note that some temporary intermediate
GimpRGBs objects were added, which will
be removed when map-object and
gimpoperationgradient are fully converted
in a separate commit.
..with gimp_bilinear_rgb ().
This function takes in a double array of raw pixels,
a boolean to determine if the pixels have an alpha channel,
and a reference to return the final pixel to.
This abstract spec type is basically a GParamSpecObject with a default
value. It will be used by various object spec with default values, such
as GimpParamSpecColor, GimpParamSpecUnit and all GimpParamSpecResource
subtypes. Also it has a duplicate() class method so that every spec type
can implement the proper way to duplicate itself.
This fixes the fact that in gimp_config_param_spec_duplicate(), all
unknown object spec types (because they are implemented in libgimp,
which is invisible to libgimpconfig) are just copied as
GParamSpecObject, hence losing default values and other parameters.
As a second enhancement, it also makes it easier to detect the object
spec types for which we have default value support in
gimp_config_reset_properties().
As a side fix, gimp_param_spec_color() now just always duplicates the
passed default color, making it hence much easier to avoid bugs when
reusing a GeglColor.
This patch removes the two instances of
gimp_rgb_luminance_uchar () and one
instance of gimp_rgb_luminance () from
the codebase.
* plug-ins/common/checkerboard.c:
Use gegl_color_get_pixel () to get the
luminance value at the same time we're
getting the RGBA value from the GeglColor.
* plug-ins/gradient-flare/gradient-flare.c:
Replace with GIMP_RGB_LUMINANCE ()
macro, which does not use GimpRGB.
gimp_cairo_set_source_rgb () and
gimp_cairo_set_source_rgba () are no longer
used in the code base, so let's remove them
as part of the move to GeglColor.
This reverts commit f7e7f396aa.
See issue #8269.
For GIMP 2.10, I'll just revert this commit so that we get back to pre-2.10.32
situation. ~~For 3.0, we'll try to do something better.~~
-> Let's delay improving the situation even for GIMP 3.0, in which case
it's better to at least keep the same render as for the 2.10 series and
avoid confusion. I'll take more time after release to study better the
situation and see what we should actually do.
(cherry picked from commit 2fd738bb3e)
- gimp_rgb_list_names() ported as gimp_color_list_names() using NUL-terminated
GimpColorArray.
- GimpColorHexEntry uses the new function (and is therefore now GimpRGB free!).
- gimp_rgb_parse_name() deleted as it's unused since my previous commit.
With all this, gimprgb-parse.c is now deleted from the repository! \o/
… test-color-parser.c file.
The file libgimpcolor/test-color-parser.c was compiled but never actually called
by the build. Now that we have a nice infrastructure to test libgimp API, I am
moving it there with the new format. Doing this also allowed me to discover some
bugs in CSS parsing, as well as discover Python binding was failing here (cf.
the few previous commits).
Only one test is disabled so far, the one where 4 digits are used per channel in
hexadecimal notation: "#64649595eded". This format simply doesn't appear
anywhere in the spec, and also the result values in the samples listing don't
even fit. So far, I'm just unsure what to do with it, if we want to keep this
support (of some kind of higher precision hex notation, but not specified, so is
it even used by anyone?) or not.
All the other tests just work in both C and Python!
New functions with the same name as these functions are created, except without
the length argument (i.e. it's equivalent to calling these with -1).
The reason for this is that using strings with a length variant which may be
negative to switch to NUL-terminated strings are not bindable. At least in our
case, when testing in Python, the input string ended up as corrupted garbage and
GObject Introspection docs warns about such interfaces:
> In particular, avoid functions taking a const char * with a signed length that
> can be set to a negative value to let the function compute the string length
> in bytes. These functions are hard to bind, and require manual overrides.
(see: https://gi.readthedocs.io/en/latest/writingbindableapis.html#strings)
So instead, I create a simple version which runs on NUL-terminated strings only
and which is bound, whereas unbinding the generic length-version (making it
C-only, or maybe usable in some other bindings which ignore the (skip)
annotation; apparently some do this).
- "transparent" is now recognized. It was forgotten (probably because on the
GimpRGB interface, we separated the API in a _rgb_ and a _rgba_ variant).
- rgba() and hsla() formats are now fixed (implementation was there but the
function names were not recognized.
- Adding some comment about limitations of the hexadecimal notation (we don't
support the alpha channel which is now in the CSS specs, while we also support
some non-specified variant with every channel on 3 or 4 digits) for future
work.
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.
There are no plug-ins which uses GimpRGB for procedure argument, nor is there
any base PDB procedure. We don't pass this type anymore through from/to
core/plug-ins. So let's clean the whole code out as a next step to get rid of
GimpRGB from our codebase!
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.
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.
- 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.
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.
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.
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.
… 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).
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.
This is not the main reason for the specific output in #9994. These ones are
more probably because of similar usage in GTK (which updated its own calls to
g_file_info_get_is_hidden|backup() in version 3.24.38). But we should likely
also update the various calls we have to use the generic
g_file_info_get_attribute_*() variants.
To be fair, it is unclear to me when we can be sure that an attribute is set.
For instance, when we call g_file_enumerate_children() or g_file_query_info()
with specific attributes, docs say that it is still possible for these
attributes to not be set. So I assume it means we should never use direct
accessor functions.
The only exception is that I didn't remove usage of g_file_info_get_name(),
since its docs says:
> * Gets a display name for a file. This is guaranteed to always be set.
Even though it also says just after:
> * It is an error to call this if the #GFileInfo does not contain
> * %G_FILE_ATTRIBUTE_STANDARD_DISPLAY_NAME.
Which is very contradictory. But assuming that this error warning was
over-zealous documentation, I kept the direct accessors since they are supposed
to be slightly more optimized (still according to in-code documentation) so
let's priorize them when we know they are set for sure.
While `length` is always assigned a value by gimp_color_profile_get_icc_profile (),
some compilers don't recognize this and warn about it being uninitialized.
This assigns six instance of `length` to 0 when declared to remove the warnings.
Jehan