Add a "gboolean edge_lock" parameter to GimpChannel::feather() and a
"Selected areas continue outside the image" toggle to the "Feather
Selection" dialog, just like they exist for shrink selection and
border selection. At the end, convert the boolean to the right abyss
policy for gegl:gaussian-blur.
(cherry picked from commit aace6b179b)
Note that I am using twice TIFFErrorHandler type. This is because
TIFFWarningHandler does not exist, despite what the docs says and
upstream code actually uses twice the same handler type.
(cherry picked from commit de866d8815)
Our TIFF loading code was not taking into account the case when extra
channels were stored in the TIFF file while ExtraSamples field is not
set. Yet as a side effect of a later channel count, we were setting
`alpha` to TRUE while `save_transp_pixels` was left uninitialized (hence
undefined behavior).
For now let's make sure we have no undefined behavior. When the
ExtraSamples field is missing and at least one extra channel is stored,
we will consider the first extra channel as non-premultiplied alpha
(this is also what we were doing when ExtraSamples was set to
"Unspecified data" and apparently according to Massimo, it would be a
common behavior in other software).
Note that it is an improvement from previous code (no undefined
behaviour anymore, instead we handle explicitly the TIFF error). Yet
this is not perfect yet. Ideally we should pop-up a dialog asking what
to do with this extra channel: either open as a channel (no alpha), or
as premultiplied or non-premultiplied alpha.
(cherry picked from commit b090bc5213)
... tiling window manager.
Completing commit e6364ffa81 by additionally making sure the search
dialog is non-modal. Otherwise it prevents positionning it wherever we
want and it stays in the center, potentially hiding the canvas and
darkening the main window.
(cherry picked from commit aa1171ada2)
In gimp_group_layer_translate(), when translating a nested group
layer, call gimp_drawable_update_all() to update the child-layers'
original area *before* updating the group's offset, at which point
the group parent's size is updated, causing subsequent area-updates
during translation to be clipped to the parent's new bounds,
preventing the original areas from being properly cleared.
(cherry picked from commit 4a20a75dc3)
Add a new GimpDrawable::update_all() virtual function, and a
corresponding gimp_drawable_update_all() function, which updates
the full contents of the drawable. Unlike calling
`gimp_drawable_update (drawable, 0, 0, -1, -1)`, which updates the
entire drawable area, gimp_drawable_update_all() only updates the
area that has actual content. While the default implentation does
simply update the entire drawable area, GimpGroupLayer overrides
this function to recursively update its child layers, rather than
the its entire area.
(cherry picked from commit 3e5cbb03d9)
Some blend funcs depend on constants from the specifc color space we are
operating in and needs the space or operation propagated to the worker function
of the operation as discovered in issue #3451.
This commit propagates the operation, leaving the specific blend functions
needing it to call gegl_operation_get_source_space or similar without needing
that overhead for the rest.
(cherry picked from commit 8e90468308)
While we tend to default to sRGB for 8-bit max formats (such as JPEG or
WebP) when no explicitly-assigned profile was set, there is no need to
do so for PNG too. Indeed since we have the ability to export 16-bit
PNG, let's consider this is ok to export 16-bit linear data when writing
GIMP's default linear profile.
Moreover let's follow the profile's (fallback to storage's) TRC also
when exporting to a specific precision (as chosen manually in the
dialog), not only when sticking to "Automatic", unless we are downsizing
a high bit depth work image to 8-bit without a manually assigned profile
(the only case we forcefully export as sRGB data, hence convert the
profile if linear storage).
(cherry picked from commit 24ed5870ad)
... in JPEG export.
Same as the WebP export, which is quite similar (8-bit max format), when
no profile was explicitly set, we want to convert any data from storage
format to non-linear (unlike when exporting high bit depth formats, such
as TIFF).
We only make an exception for 8-bit linear. This commit adds this
exception.
(cherry picked from commit 0461022198)
Similarly to other export dialogs, we don't consider anymore metadata or
profile writing as being advanced options. Since these were the only
options shown in our current WebP export dialog, I removed the expander
altogether and moved everything out.
See also commit 540cfa9611.
(cherry picked from commit 26ba915ca5)
Profile and output linearity decision was doubled as save_layer() and
save_animation() and I realize that I forgot to update the
save_animation() one in earlier commits.
To avoid code copy-paste and divergence, I added an internal
webp_decide_output() function which I use in both aforementionned calls.
(cherry picked from commit 6712228e5e)
Same as other formats, we make sure that an explicitly set profile TRC
is always followed. When no profile is set, we always export as sRGB
when there is precision downsizing to avoid shadow posterization, since
WebP stores 8-bit max per channel (as far as I know, or at least as far
as we implemented it in our plug-in).
We only take the storage format into account when it is 8-bit linear
with profile export. In such case, we avoid conversion from 8-bit linear
to 8-bit sRGB.
This is different to TIFF export for instance, where we fallback on
following storage format TRC as we are able to export all sort of
precisions, hence with minimum quality loss.
(cherry picked from commit 2a1eabc177)
Same as we did for PNG and JPEG, we want to always export data with the
TRC of a profile manually assigned, and in particular NOT the curve of
the storage in GIMP (i.e. you may work on 32-bit linear, yet if you
assigned a sRGB TRC profile, this is what you should export). The
storage format will only dictate the exported data TRC when writing out
the default profile (i.e. no explicit profile assignement).
As a last case, when no profile is saved, we always export as sRGB.
As for the export precision, we always follow the storage one's, except
sometimes for 8-bit images. We promote 8-bit images to 16-bit if and
only if the storage does not match the export data linearity, to avoid
too much quality loss during format conversion.
(cherry picked from commit 8d9e70011d)
Blacklist the "tools-offset" action in the GUI, and only keep
"filters-offset", to avoid duplication. Update gimp:offset's
description, so that "filters-offset" gets a proper tool-tip.
(cherry picked from commit 42d4255262)
Add a new GimpFilterTool::region_changed() virtual function, which
gets called whenever the filter region changes, either due to a
change to the tool's "region" option, or a change to the image
mask.
Override GimpFilterTool::region_changed() in GimpOperationTool and
GimpOffsetTool, instead of listening to a change to the "region"
option in GimpTool::options_notify(), so that the tools are
properly updated when the image mask changes.
(cherry picked from commit 066827e23c)
In gimp_filter_tool_get_drawable_area(), when the image mask
doesn't intersect the drawable, return a minimal area, instead of
an empty/invalid area.
(cherry picked from commit 428ee0e2ad)
Add a new Offset filter tool, as a front-end to gimp:offset. The
tool replaces, and provides the same interface as, the drawable-
offset dialog, while also providing live preview and on-canvas
interaction.
Note that we don't simply use a custom propgui constructor for
gimp:offset, since we need a little more control.
(cherry picked from commit 3a4a00c71e)
Implement gimp_drawable_offset() in terms of gimp:offset, added in
the previous commit. Other than avoiding duplication, this also
allows gimp_drawable_offset() to respect the current selection and
component mask (see issue #39.)
(cherry picked from commit 5b2f3980bd)
