In 9e8499bb, we forced image and drawable
previews to be 8 bit integer for compatibility.
However, this affects image previews when
in higher precisions, leading to banding
and other conversion issues.
Since the color space invasion, the original
problem should have less of an impact
as GIMP now handles conversions between
profiles much better. Therefore, we will
just grab the existing format for Grayscale
and RGB images, rather than forcing a
precision change to 8 bit.
As discussed on IRC these ops mostly duplicate other gegl ops and
have some shortcomings: range and gui-range, among other things,
are currently not supported. This causes some issues changing values
of parameters in GIMP, see e.g.
https://gitlab.gnome.org/GNOME/gegl/-/issues/403
Since they bring nothing new, and have issues, we will blacklist them
from the GEGL tools interface in GIMP, at least until they have
better support in GEGL.
After discussing with NikcDC and Wormnest on IRC, we agreed that maybe a
default of being sensitive when one or more drawables are selected seems
better, since the run() signature now has an array of drawables. So most
plug-in developers will consider the case when there are several
selected drawables as an obvious possible case.
And if someone really doesn't want to handle this case, they can always
set the sensitivity mask explicitly.
In particular, when setting a sensitivity mask but no image types, the
procedure was always sensitive.
Also make gimp_plug_in_procedure_get_sensitive() more robust.
Resolves#12854
Previously when loading filters, we used gimp_drawable_filter_apply ().
If there was also an active selection, it affected the recreation of the filter
and distorted the display.
This patch switches to using gimp_drawable_filter_apply_with_mask () so
that the filter's mask is always used instead, no matter if there is an active
selection or not.
gegl:pack replaced gegl:hstack almost 5 years ago, but the blacklist
for not showing it in our list of ops in Gegl tool was never updated.
Since Pack is also causing issues in GIMP, see #12890 and #12902,
let's update the blacklist add it there and remove the old gegl:hstack
that has been removed from GEGL.
Following e653535e
The meson-generated 'compile_commands.json' file added by 793c9588 shows an
assumption that we are building in-source, and assumptions are not welcome in
this general file, according to Jehan comment: !1021 (comment 1801018)
On export, when GIMP_EXPORT_CAN_HANDLE_LAYERS is not set
but GIMP_EXPORT_NEEDS_ALPHA is, we merge all layers in the image.
If there's a floating selection however, its attached layer is not included
in the exported image.
This patch converts the floating selection to a regular layer so that both
are included in the final export.
While we blocked rearranging a floating selection in the NDE GUI,
we did not add a check to prevent another filter from being moved
into it. Since a floating selection is considered a GimpLayer, applying
GimpDrawableFilter operations to it caused a crash. This patch adds
more safeguards to prevent this.
This reverts commit 490c8e7dc4.
Actually, I forgot to add 'GITLAB_CI' as an authorized MS Entra app on
Partner Center. So, I just done that and submission from our CI worked.
Cropping relatively to the full image contents is a common usage (it is
in fact the "Crop to Content" feature we have in the Image menu) so I
found it a bit frustrating that these 2 functions only allow to crop
relatively to a single drawable.
Therefore, I make NULL an acceptable input which will default to
cropping to the full image content instead.
- Clean up a bit the 2 procedures' descriptions and add more info in
gimp_image_autocrop() description to explain how the input drawable is
used.
- Rename gimp_image_autocrop_layer() to gimp_image_autocrop_selected_layers(),
which makes it clearer.
Rename plug_in_compat.pdb to image_autocrop.pdb so we retain commit history.
All procedures defined there are related to autocrop.
- made internal, not plugins
- renamed from plug-in- to gimp-image-
- exposed in libgimp
If we need plugin compatibility PDB group in the future,
a starting template can be recovered from plug_in_compat.pdb 2.10 or late 2.99.
Fixed plugins that call. The C plugin now calls libgimp instead of a PDB procedure.
This is used by our release scripts on gimp-web.
Let's not generate for other pipelines, however, since they
don't have long life on GitLab and there is no permalinks yet.
