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.
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.
Fixes issue #3451 Space invasion/AnyRGB: Luminance blend mode doesn't work
It might be faster to fetch the RGB luminance and do the computation
ourselves than looking up the same fish for each processing request, at
least now we're faster. (commit message and code slightly revised by pippin)
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.
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).
... 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.
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.
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.
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.
Issue #3436 Replace sRGB Y values with Y values from XYZ for the
image's actual RGB space
This patch is for Colors/Desaturate/Desaturate to Luminance or
Luma.
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.
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.
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.
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.
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.)
Add a new gimp:offset operation, which implements equivalent
functionality to gimp_drawable_offset(), in preparation for adding
an interactive offset tool.
To simplify things, add a GIMP_OFFSET_WRAP_AROUND value to the
GimpOffsetType enum, to avoid the need for a separate wrap-around
flag. This makes the gimp-drawable-offset procedure parameters a
little superfluous, but whatever.
In file-tiff, when not saving layers, avoid duplicating the image
to create the merged version if it's already been duplicated, and
make sure to delete the duplicated image otherwise.
Make sure to update the drawable after committing the Warp tool, if
high-quality-preview is disabled, and we use a non-nearest sampler.
Necessary after commit d928a80b7f.
...even when not supposed to
Don't use gimp_config_copy() to set the tool options from the ones
stored in the preset. Instead, add utility function
tool_manager_copy_tool_options() that only copies properties of
GimpToolOptions and its subclasses.
Simply set the tool, copy the tool options' context properties, then
copy the tool options' own properties and done. Much more obvious and
works.
In gimp_drawable_merge_filter(), add an "update" parameter, which
specifies whether to update the affected region of the drawable
after applying the filter. Avoid updating the drawable when
commiting a GimpDrawableFilter (and manually update the drawable if
filter application was cancelled), and when anchoring a floating
selection, since in both cases the relevant region of the drawable
has already been updated.
Connect GimpDisplayShell to GimpImage::mode-changed and update its
cached color transforms. Also get rid of a duplicate conection to
GimpImage::precision-changed.
In gimp:mask-components, add an "alpha" property, which controls
the masked-in alpha value in case there's no aux buffer. Set it to
0 by default, so that gimp:mask-components behaves normally in the
absence of an aux buffer (as if the aux buffer was empty). Set it
to 1 in the image's visible-mask node, to maintain the current
alpha-component visibility behavior.
This fixes incorrect results when the output bounding box of a
drawable filter is smaller than the drawable, which can lead to a
NULL aux buffer being fed to the filter's gimp:mask-components
node.
In GimpOperationLayerMode and GimpOperationReplace, make sure we
don't return a NULL output buffer, or forward a NULL input buffer,
but rather create an appropriate empty buffer in this case. This
avoids wrong results when the layer-mode op's output is connected
to the aux input of a subsequent op, as a result of the op behaving
differently with a NULL aux buffer (in particular, this can happen
when a drawable filter's output bounding box is smaller than the
drawable.)
There should never be an image using GIMP_TRC_PERCEPTUAL, but things
should work if one is encountered anyway.
In the Image -> Precision menu and the Convert Precision dialog, have
menu items / radio buttons for both non-linear and perceptual, but
hide the perceptual choice unless the image is in perceptual TRC mode.
This should eliminate the possibility to create perceptual TRC images
from the GUI.
...when generating "TRC variants"
When creating a new profile with different TRC from an existing
profile, keep all the original profile's description, model,
manufacturer and copyright strings around, but prefix them with "GIMP
from " or similar to indicate that they are different. Also make sure
we don't prefix strings with GIMP stuff multiple times when profiles
are generated repeatedly.
gimp_image_convert_precision(): if the conversion changes the TRC and
the image's profile is a built-in profile, don't create a profile from
it but instead simply use the new TRC's built-in profile.
Add "gboolean push_undo" parameters to gimp_image_parasite_attach()
and _detach() and use the API also from undo, instead of implementing
attaching/removing manually and forgetting about the signals.
Fixes updating of the image properties color profile page.
gimp_image_parasite_attach(): when we detected that a builtin profile
is about to be attached, actually bail out after removing the old
profile, instead of continuing to attaching the builtin profile
anyway. Gah...
Ell