… gimp_drawable_curves_spline().
We can now run directly "gimp:curves" operation, both destructively or
non-destructively, but also setting the TRC, as well as individual point
types (when the curve is of type "smooth" instead of freehand).
This is much more powerful!
I have manually tested each and every of the deprecated functions,
making sure we don't lose any feature. As expected, we don't. Having
dedicated libgimp functions may feel a tiny bit easier to call but this
is not scalable. We can't do this forever, with one function per filter.
And fortunately we won't have to, since now we can call filters on any
drawable directly! It also comes with the following generic advantages:
* It works with any filter, even third-party ones;
* We can also append filters non-destructively for later removal or
edits (the deprecated functions were always merging the filters);
* If the filter evolves, e.g. with new arguments, it should not affect
the API (though we should implement GEGL operation versions);
* If we don't need to set all arguments (e.g. leaving many args with
default value), the filter API may even be simpler and shorter;
* The filter API will be much less "opaque" thanks to argument naming
(rather than a long list of integers, doubles, etc.).
Specifically to the now deprecated functions, I noted the following
weaknesses on the deprecated API when testing:
* gimp_drawable_colorize_hsl() was missing a "color" argument;
* gimp_drawable_extract_component() had the enum argument "component"
set as an integer, which is particularly opaque when re-reading
existing code. Whereas the filter API uses generate choice strings
which are self-explanatory! For instance choice RGB Red is 0 with the
deprecated function but "rgb-r" with the filter API.
* gimp_drawable_levels() was missing "trc" argument (as noted in
#15681).
And as expected, no features are lost.
Note that I didn't deprecate the curves functions yet, because we need
to implement the GimpCurve type in libgimp first.
There are a few more functions which I didn't deprecate yet, because
they don't use a filter directly, but some core functions, though for
some of them, it is very likely they can be efficiently reimplemented
with the filter API too. I'll have to look closer at it. It looks like
we may have to implement GimpHistogram in libgimp too though.
One point which was raised in #15681 is that the documentation is
lacking.
* Let's write down that the range of the point coordinates is in the [0,
1] range.
* Also let's rename num_points to num_coordinates because argument
points will actually contain 2 coordinates per points (so for 10
points, the points array will be of size 20). We also write that it
means that num_coordinates must therefore be even.
* Add more spacing in the docs and some better styling and annotations.
This reverts commit 246f9d284f.
This only reverts the part modifying libgimp* headers. All the part
switching to #pragma once in app/ was kept. See #14668.
Avoid the stack smashing bug from yesterday in other functions.
Additionally to fixing other functions, do not cast the pointer to size
in the PDB generation scripts so that we can quickly spot such bugs in
the future, through compilation time warnings, instead of hiding them.
(cherry picked from commit dbf9f277a2)
Committer's (Jehan) updates:
- Component type is now int32 (int8 is not a PDB type available anymore).
- PDB files re-generated to handle changes in API and types.
By default the new API will be used. But if we build with
GIMP_DEPRECATED_REPLACE_NEW_API macro, then the same function names will
call the old API with ids.
This way, we don't have to update all our plug-ins at once (which I
tried and is very tedious work).
Note that bindings won't have access to the deprecated API at all.
Add "clamp-input" (which clamps the input values to [0..1])
and "clamp-output" (which clips the final result to [0..1]),
properties, parameters and GUI to:
- GimpLevelsConfig
- GimpOperationLevels
- The levels tool dialog
- The gimp_drawable_levels() PDB API
The old deprecated gimp_levels() PDB API now sets both clamping
options to TRUE which restores the 2.8 behavior.
Also reorder some stuff in GimpLevelsConfig and elsewhere so the
levels parameters are always in the same order.
Remove the invert-linear and invert-non-linear variants and simply add
"gboolean linear" to gimp-drawable-invert. This should actually be an
enum but I didn't find a good name right now...
and add gimp_drawable_invert_linear(). Also, finally deprecate
gimp_invert() and port all its uses in plug-ins and scripts to
gimp_drawable_invert_non_linear() so the result is the same.
so the threshold can now be based on the GimpHistogramChannel enum.
Add a channel menu to the threshold dialog and a channel argument to
the PDB procedure (which is new in 2.10).
If I hadn't forgotten what the "RGB" channel is supposed to do I would
have implemented the RGB mode in GimpOperationThreshold correctly.
Right now I'm just guessing. Anyone?
They used to be 0..255, inherited from the old gimp_histogram() and
gimp_threshold() procedures. This commit deprecates these old
procedures and changes the ranges in the new gimp_drawable_histogram()
and gimp_drawable_threshold() to double with a 0.0..1.0 range.
Which contains all the API from the "color" group, but with a
gimp_drawable namespace and with support for high bit depths. The
group is actually a copy of "color" with cruft removed and some API
ported to using float instead of integer API.
Deprecated all "color" functions that already have a ported version in
"drawable_color".
This is unfinished WIP, some functions in "drawable_color" still have
the old API.
