dallasgroot/Gimp
dallasgroot/Gimp
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
Gimp/app/operations/layer-modes/gimpoperationreplace.c

348 lines
12 KiB
C
Raw Normal View History

app: add back individual operation classes for the layer modes They are derived from GimpOperationPointLayerMode and are completely empty and unused, but can be filled with code and enabled one-by-one now.
2009-12-30 06:18:44 -08:00
/* GIMP - The GNU Image Manipulation Program
* Copyright (C) 1995 Spencer Kimball and Peter Mattis
*
app: move the remaining 3 layer modes to layer-modes/ Not exactly sure if all are correct, but the file moving is almost done now.
2017-01-11 03:55:13 -08:00
* gimpoperationreplace.c
app: add back individual operation classes for the layer modes They are derived from GimpOperationPointLayerMode and are completely empty and unused, but can be filled with code and enabled one-by-one now.
2009-12-30 06:18:44 -08:00
* Copyright (C) 2008 Michael Natterer <mitch@gimp.org>
*
Bug 721553 - License text contains obsolete FSF postal address These files were forgotten when changing license from GPL2 to GPL3.
2014-01-05 05:22:08 -08:00
* This program is free software: you can redistribute it and/or modify
app: add back individual operation classes for the layer modes They are derived from GimpOperationPointLayerMode and are completely empty and unused, but can be filled with code and enabled one-by-one now.
2009-12-30 06:18:44 -08:00
* it under the terms of the GNU General Public License as published by
Bug 721553 - License text contains obsolete FSF postal address These files were forgotten when changing license from GPL2 to GPL3.
2014-01-05 05:22:08 -08:00
* the Free Software Foundation; either version 3 of the License, or
app: add back individual operation classes for the layer modes They are derived from GimpOperationPointLayerMode and are completely empty and unused, but can be filled with code and enabled one-by-one now.
2009-12-30 06:18:44 -08:00
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
Change the license URL from http://www.gnu.org/licenses/ to https://
2018-07-11 14:27:07 -07:00
* along with this program. If not, see <https://www.gnu.org/licenses/>.
app: add back individual operation classes for the layer modes They are derived from GimpOperationPointLayerMode and are completely empty and unused, but can be filled with code and enabled one-by-one now.
2009-12-30 06:18:44 -08:00
*/
#include "config.h"
app: #include <string.h> in gimpoperationreplace.c ... for memset().
2019-02-14 08:08:45 -08:00
#include <string.h>
app: add back individual operation classes for the layer modes They are derived from GimpOperationPointLayerMode and are completely empty and unused, but can be filled with code and enabled one-by-one now.
2009-12-30 06:18:44 -08:00
#include <gegl-plugin.h>
app: move the remaining 3 layer modes to layer-modes/ Not exactly sure if all are correct, but the file moving is almost done now.
2017-01-11 03:55:13 -08:00
#include "../operations-types.h"
app: add back individual operation classes for the layer modes They are derived from GimpOperationPointLayerMode and are completely empty and unused, but can be filled with code and enabled one-by-one now.
2009-12-30 06:18:44 -08:00
app: change behavior of REPLACE mode for fully-transparent pixels When the result of compositing has an alpha value of 0, the corresponding color value is not mathematically defined. Currently, all out layer modes opt to preserve the destination's color value in this case. However, REPLACE mode is different enough to warrant a different behavior: Unlike the other layer modes, when the compositing opacity approaches 0 or 1, the output color value approaches the destination or source color values, respectively, regardless of the output alpha value. When the opacity doesn't approach 0 or 1, the output color value generally doesn't approach a limit as the output alpha value approaches 0, however, when both the destination and source alpha values are equal, the output color value is always a simple linear interpolation between the destination and source color values, according to the opacity. In other words, this means that it's reasonable to simply use the above linear interpolation for the output color value, whenever the output alpha value is 0. Since filters are commonly combined with the input using REPALCE mode with full opacity, this has the effect that filters may now modify the color values of fully-transparent pixels. This is generally desirable, IMO, especially for point filters. Indeed, painting with REPLACE mode (i.e., with tools that use gimp_paint_core_replace()) behaved excatly as described above, and had this property, before we switched gimp_paint_core_replace() to use the common compositing code; this created a discrepancy between painting and applying filters, which is now gone. A side effect of this change is that we can now turn gimp:replace into a NOP when the opacity is 100% and there's no mask, which avoids the compositing step when applying filters. We could previously only apply this optimization to PASS_THROUGH mode, which is a subclass of REPLACE mode. Note that the discussion above concerns the UNION composite mode, which is the only mode we currently use REPLACE in. We modify the rest of the composite modes to match the new behavior: CLIP_TO_BACKDROP always preserves the color values of the destionation, CLIP_TO_LAYER always preserves the color values of the source, and INTERSECTION always produces fully-zeroed pixels.
2019-02-14 07:31:29 -08:00
#include "gimp-layer-modes.h"
app: move the remaining 3 layer modes to layer-modes/ Not exactly sure if all are correct, but the file moving is almost done now.
2017-01-11 03:55:13 -08:00
#include "gimpoperationreplace.h"
app: add back individual operation classes for the layer modes They are derived from GimpOperationPointLayerMode and are completely empty and unused, but can be filled with code and enabled one-by-one now.
2009-12-30 06:18:44 -08:00
app: rename GimpOperationPointLayerMode to GimpOperationLayerMode and formatting cleanup.
2017-01-21 12:35:52 -08:00
app: in gimp:replace, implement GeglOperation::get_bounding_box() ... similarly to gimp:layer-mode, however, assume the destnation (backdrop) is not included when the layer's opacity is 1, and there's no mask.
2019-08-01 13:39:51 -07:00
static GeglRectangle gimp_operation_replace_get_bounding_box (GeglOperation *op);
app: fix compositing of layers with masks, outside the mask bounds In GimpOperationLayerMode, when the op has a mask connected, and we're processing an area outside the mask bounds, set the op's opacity to 0, so that the backdrop shows through. The actual process() function gets a NULL mask pointer in this case, and so would composite the layer as if it had no mask, exposing areas that should be masked out. Add a GimpOperationLayerMode::parent_process() function, which subclasses can override instead of GeglOperation::process(), and make sure to update the GimpOperationLayerMode::opacity field before calling this function (and, subsequently, before calling GimpOperationLayerMode::process()). Clean up the rest of the fields, and adjust the rest of the code.
2020-02-21 11:58:15 -08:00
app: change behavior of REPLACE mode for fully-transparent pixels When the result of compositing has an alpha value of 0, the corresponding color value is not mathematically defined. Currently, all out layer modes opt to preserve the destination's color value in this case. However, REPLACE mode is different enough to warrant a different behavior: Unlike the other layer modes, when the compositing opacity approaches 0 or 1, the output color value approaches the destination or source color values, respectively, regardless of the output alpha value. When the opacity doesn't approach 0 or 1, the output color value generally doesn't approach a limit as the output alpha value approaches 0, however, when both the destination and source alpha values are equal, the output color value is always a simple linear interpolation between the destination and source color values, according to the opacity. In other words, this means that it's reasonable to simply use the above linear interpolation for the output color value, whenever the output alpha value is 0. Since filters are commonly combined with the input using REPALCE mode with full opacity, this has the effect that filters may now modify the color values of fully-transparent pixels. This is generally desirable, IMO, especially for point filters. Indeed, painting with REPLACE mode (i.e., with tools that use gimp_paint_core_replace()) behaved excatly as described above, and had this property, before we switched gimp_paint_core_replace() to use the common compositing code; this created a discrepancy between painting and applying filters, which is now gone. A side effect of this change is that we can now turn gimp:replace into a NOP when the opacity is 100% and there's no mask, which avoids the compositing step when applying filters. We could previously only apply this optimization to PASS_THROUGH mode, which is a subclass of REPLACE mode. Note that the discussion above concerns the UNION composite mode, which is the only mode we currently use REPLACE in. We modify the rest of the composite modes to match the new behavior: CLIP_TO_BACKDROP always preserves the color values of the destionation, CLIP_TO_LAYER always preserves the color values of the source, and INTERSECTION always produces fully-zeroed pixels.
2019-02-14 07:31:29 -08:00
static gboolean gimp_operation_replace_parent_process (GeglOperation *op,
GeglOperationContext *context,
const gchar *output_prop,
const GeglRectangle *result,
gint level);
app: layer mode code shuffling Commit 3635cf04ab69bafb76d7583da804f580f2d5fbf3 moved the special handling of bottom-layer compositing to GimpOperationLayerMode. This required giving the op more control over the process() function of its subclasses. As a temporary workaround, the commit bypassed the subclasses entirely, using "gimp:layer-mode" for all modes. This is the reckoning :) Add a process() virtual function to GimpOperationLayerMode, which its subclasses should override instead of GeglOperationPointComposer3's process() functions. Reinstate the subclasses (by returning the correct op in gimp_layer_mode_get_oepration()), and have them override this function. Improve the way gimp_operation_layer_mode_process() dispatches to the actual process function, to slightly lower its overhead and fix some thread-safety issues. Remove the "function" field of the layer-mode info array, and have gimp_layer_mode_get_function() return the GimpOperationLayerMode::process() function of the corresponding op's class (caching the result, to keep it cheap.) This reduces redundancy, allows us to make the ops' process() functions private, and simplifies SSE dispatching (only used by NORMAL mode, currently.) Move the blend and composite functions of the non-specialized layer modes to gimpoperationlayermode-{blend,composite}.[hc], respectively, to improve code organization. Move the SSE2 composite functions to a separate file, so that they can be built as part of libapplayermodes_sse2, allowing libapplayermodes to be built without SSE2 compiler flags. This allows building GIMP with SSE acceleration enabled, while running the resulting binary on a target with no SSE accelration. Add a "blend_function" field to the layer-mode info array, and use it to specify the blend function for the non-specialized modes. This replaces the separate switch() statement that we used previously. Remove the "affected_region" field of the layer-mode info array. We don't need it anymore, since we can go back to using GimpOperationLayerMode's virtual get_affected_region() function. Last but not least, a bunch of code cleanups and consistency adjustments.
2017-08-17 07:26:49 -07:00
static gboolean gimp_operation_replace_process (GeglOperation *op,
void *in,
void *layer,
void *mask,
void *out,
glong samples,
const GeglRectangle *roi,
gint level);
static GimpLayerCompositeRegion gimp_operation_replace_get_affected_region (GimpOperationLayerMode *layer_mode);
app: move all special-case mode processing optimizations to GimpOperationLayerMode Stuff like passing "input" directly if "aux"'s opacity is 0, etc. Used to be partly handled by normal mode, even though it applies to other modes too. Adjust the logic for the new compositing modes. Add a GimpLayerModeAffectMask enum, and a corresponding get_affect_mask() function to GimpOperationLayerMode, which specifies which of the op's inputs, if any, are affected by the mode, apart from the overlapping regions. Most modes affect only the overlapping regions, but dissolve and replace also affect the rest of the input. This information is used for determining if the optimizations are applicable.
2017-02-02 07:53:09 -08:00
app: move the remaining 3 layer modes to layer-modes/ Not exactly sure if all are correct, but the file moving is almost done now.
2017-01-11 03:55:13 -08:00
G_DEFINE_TYPE (GimpOperationReplace, gimp_operation_replace,
app: rename GimpOperationPointLayerMode to GimpOperationLayerMode and formatting cleanup.
2017-01-21 12:35:52 -08:00
GIMP_TYPE_OPERATION_LAYER_MODE)
app: add back individual operation classes for the layer modes They are derived from GimpOperationPointLayerMode and are completely empty and unused, but can be filled with code and enabled one-by-one now.
2009-12-30 06:18:44 -08:00
app: change behavior of REPLACE mode for fully-transparent pixels When the result of compositing has an alpha value of 0, the corresponding color value is not mathematically defined. Currently, all out layer modes opt to preserve the destination's color value in this case. However, REPLACE mode is different enough to warrant a different behavior: Unlike the other layer modes, when the compositing opacity approaches 0 or 1, the output color value approaches the destination or source color values, respectively, regardless of the output alpha value. When the opacity doesn't approach 0 or 1, the output color value generally doesn't approach a limit as the output alpha value approaches 0, however, when both the destination and source alpha values are equal, the output color value is always a simple linear interpolation between the destination and source color values, according to the opacity. In other words, this means that it's reasonable to simply use the above linear interpolation for the output color value, whenever the output alpha value is 0. Since filters are commonly combined with the input using REPALCE mode with full opacity, this has the effect that filters may now modify the color values of fully-transparent pixels. This is generally desirable, IMO, especially for point filters. Indeed, painting with REPLACE mode (i.e., with tools that use gimp_paint_core_replace()) behaved excatly as described above, and had this property, before we switched gimp_paint_core_replace() to use the common compositing code; this created a discrepancy between painting and applying filters, which is now gone. A side effect of this change is that we can now turn gimp:replace into a NOP when the opacity is 100% and there's no mask, which avoids the compositing step when applying filters. We could previously only apply this optimization to PASS_THROUGH mode, which is a subclass of REPLACE mode. Note that the discussion above concerns the UNION composite mode, which is the only mode we currently use REPLACE in. We modify the rest of the composite modes to match the new behavior: CLIP_TO_BACKDROP always preserves the color values of the destionation, CLIP_TO_LAYER always preserves the color values of the source, and INTERSECTION always produces fully-zeroed pixels.
2019-02-14 07:31:29 -08:00
#define parent_class gimp_operation_replace_parent_class
app: add back individual operation classes for the layer modes They are derived from GimpOperationPointLayerMode and are completely empty and unused, but can be filled with code and enabled one-by-one now.
2009-12-30 06:18:44 -08:00
static void
app: move the remaining 3 layer modes to layer-modes/ Not exactly sure if all are correct, but the file moving is almost done now.
2017-01-11 03:55:13 -08:00
gimp_operation_replace_class_init (GimpOperationReplaceClass *klass)
app: add back individual operation classes for the layer modes They are derived from GimpOperationPointLayerMode and are completely empty and unused, but can be filled with code and enabled one-by-one now.
2009-12-30 06:18:44 -08:00
{
app: layer mode code shuffling Commit 3635cf04ab69bafb76d7583da804f580f2d5fbf3 moved the special handling of bottom-layer compositing to GimpOperationLayerMode. This required giving the op more control over the process() function of its subclasses. As a temporary workaround, the commit bypassed the subclasses entirely, using "gimp:layer-mode" for all modes. This is the reckoning :) Add a process() virtual function to GimpOperationLayerMode, which its subclasses should override instead of GeglOperationPointComposer3's process() functions. Reinstate the subclasses (by returning the correct op in gimp_layer_mode_get_oepration()), and have them override this function. Improve the way gimp_operation_layer_mode_process() dispatches to the actual process function, to slightly lower its overhead and fix some thread-safety issues. Remove the "function" field of the layer-mode info array, and have gimp_layer_mode_get_function() return the GimpOperationLayerMode::process() function of the corresponding op's class (caching the result, to keep it cheap.) This reduces redundancy, allows us to make the ops' process() functions private, and simplifies SSE dispatching (only used by NORMAL mode, currently.) Move the blend and composite functions of the non-specialized layer modes to gimpoperationlayermode-{blend,composite}.[hc], respectively, to improve code organization. Move the SSE2 composite functions to a separate file, so that they can be built as part of libapplayermodes_sse2, allowing libapplayermodes to be built without SSE2 compiler flags. This allows building GIMP with SSE acceleration enabled, while running the resulting binary on a target with no SSE accelration. Add a "blend_function" field to the layer-mode info array, and use it to specify the blend function for the non-specialized modes. This replaces the separate switch() statement that we used previously. Remove the "affected_region" field of the layer-mode info array. We don't need it anymore, since we can go back to using GimpOperationLayerMode's virtual get_affected_region() function. Last but not least, a bunch of code cleanups and consistency adjustments.
2017-08-17 07:26:49 -07:00
GeglOperationClass *operation_class = GEGL_OPERATION_CLASS (klass);
GimpOperationLayerModeClass *layer_mode_class = GIMP_OPERATION_LAYER_MODE_CLASS (klass);
app: new gegl replace mode that uses mask and opacity inputs
2012-04-24 08:36:31 -07:00
app: update GeglOps to new GEGL API
2012-03-29 11:22:22 -07:00
gegl_operation_class_set_keys (operation_class,
app: move the remaining 3 layer modes to layer-modes/ Not exactly sure if all are correct, but the file moving is almost done now.
2017-01-11 03:55:13 -08:00
"name", "gimp:replace",
app: code cleanup in the GEGL ops
2012-04-20 15:46:48 -07:00
"description", "GIMP replace mode operation",
NULL);
app: add back individual operation classes for the layer modes They are derived from GimpOperationPointLayerMode and are completely empty and unused, but can be filled with code and enabled one-by-one now.
2009-12-30 06:18:44 -08:00
app: in gimp:replace, implement GeglOperation::get_bounding_box() ... similarly to gimp:layer-mode, however, assume the destnation (backdrop) is not included when the layer's opacity is 1, and there's no mask.
2019-08-01 13:39:51 -07:00
operation_class->get_bounding_box = gimp_operation_replace_get_bounding_box;
app: change behavior of REPLACE mode for fully-transparent pixels When the result of compositing has an alpha value of 0, the corresponding color value is not mathematically defined. Currently, all out layer modes opt to preserve the destination's color value in this case. However, REPLACE mode is different enough to warrant a different behavior: Unlike the other layer modes, when the compositing opacity approaches 0 or 1, the output color value approaches the destination or source color values, respectively, regardless of the output alpha value. When the opacity doesn't approach 0 or 1, the output color value generally doesn't approach a limit as the output alpha value approaches 0, however, when both the destination and source alpha values are equal, the output color value is always a simple linear interpolation between the destination and source color values, according to the opacity. In other words, this means that it's reasonable to simply use the above linear interpolation for the output color value, whenever the output alpha value is 0. Since filters are commonly combined with the input using REPALCE mode with full opacity, this has the effect that filters may now modify the color values of fully-transparent pixels. This is generally desirable, IMO, especially for point filters. Indeed, painting with REPLACE mode (i.e., with tools that use gimp_paint_core_replace()) behaved excatly as described above, and had this property, before we switched gimp_paint_core_replace() to use the common compositing code; this created a discrepancy between painting and applying filters, which is now gone. A side effect of this change is that we can now turn gimp:replace into a NOP when the opacity is 100% and there's no mask, which avoids the compositing step when applying filters. We could previously only apply this optimization to PASS_THROUGH mode, which is a subclass of REPLACE mode. Note that the discussion above concerns the UNION composite mode, which is the only mode we currently use REPLACE in. We modify the rest of the composite modes to match the new behavior: CLIP_TO_BACKDROP always preserves the color values of the destionation, CLIP_TO_LAYER always preserves the color values of the source, and INTERSECTION always produces fully-zeroed pixels.
2019-02-14 07:31:29 -08:00
app: fix compositing of layers with masks, outside the mask bounds In GimpOperationLayerMode, when the op has a mask connected, and we're processing an area outside the mask bounds, set the op's opacity to 0, so that the backdrop shows through. The actual process() function gets a NULL mask pointer in this case, and so would composite the layer as if it had no mask, exposing areas that should be masked out. Add a GimpOperationLayerMode::parent_process() function, which subclasses can override instead of GeglOperation::process(), and make sure to update the GimpOperationLayerMode::opacity field before calling this function (and, subsequently, before calling GimpOperationLayerMode::process()). Clean up the rest of the fields, and adjust the rest of the code.
2020-02-21 11:58:15 -08:00
layer_mode_class->parent_process = gimp_operation_replace_parent_process;
app: layer mode code shuffling Commit 3635cf04ab69bafb76d7583da804f580f2d5fbf3 moved the special handling of bottom-layer compositing to GimpOperationLayerMode. This required giving the op more control over the process() function of its subclasses. As a temporary workaround, the commit bypassed the subclasses entirely, using "gimp:layer-mode" for all modes. This is the reckoning :) Add a process() virtual function to GimpOperationLayerMode, which its subclasses should override instead of GeglOperationPointComposer3's process() functions. Reinstate the subclasses (by returning the correct op in gimp_layer_mode_get_oepration()), and have them override this function. Improve the way gimp_operation_layer_mode_process() dispatches to the actual process function, to slightly lower its overhead and fix some thread-safety issues. Remove the "function" field of the layer-mode info array, and have gimp_layer_mode_get_function() return the GimpOperationLayerMode::process() function of the corresponding op's class (caching the result, to keep it cheap.) This reduces redundancy, allows us to make the ops' process() functions private, and simplifies SSE dispatching (only used by NORMAL mode, currently.) Move the blend and composite functions of the non-specialized layer modes to gimpoperationlayermode-{blend,composite}.[hc], respectively, to improve code organization. Move the SSE2 composite functions to a separate file, so that they can be built as part of libapplayermodes_sse2, allowing libapplayermodes to be built without SSE2 compiler flags. This allows building GIMP with SSE acceleration enabled, while running the resulting binary on a target with no SSE accelration. Add a "blend_function" field to the layer-mode info array, and use it to specify the blend function for the non-specialized modes. This replaces the separate switch() statement that we used previously. Remove the "affected_region" field of the layer-mode info array. We don't need it anymore, since we can go back to using GimpOperationLayerMode's virtual get_affected_region() function. Last but not least, a bunch of code cleanups and consistency adjustments.
2017-08-17 07:26:49 -07:00
layer_mode_class->process = gimp_operation_replace_process;
app: rename GimpLayerModeAffectMask to GimpLayerCompositeRegion ... so that we can use it for other functions that involve compositing regions (which we do in the next commit). Rename gimp_operation_layer_mode_get_affect_mask() and friends to _get_affected_region().
2017-05-07 12:42:22 -07:00
layer_mode_class->get_affected_region = gimp_operation_replace_get_affected_region;
app: add back individual operation classes for the layer modes They are derived from GimpOperationPointLayerMode and are completely empty and unused, but can be filled with code and enabled one-by-one now.
2009-12-30 06:18:44 -08:00
}
static void
app: move the remaining 3 layer modes to layer-modes/ Not exactly sure if all are correct, but the file moving is almost done now.
2017-01-11 03:55:13 -08:00
gimp_operation_replace_init (GimpOperationReplace *self)
app: add back individual operation classes for the layer modes They are derived from GimpOperationPointLayerMode and are completely empty and unused, but can be filled with code and enabled one-by-one now.
2009-12-30 06:18:44 -08:00
{
}
app: in gimp:replace, implement GeglOperation::get_bounding_box() ... similarly to gimp:layer-mode, however, assume the destnation (backdrop) is not included when the layer's opacity is 1, and there's no mask.
2019-08-01 13:39:51 -07:00
static GeglRectangle
gimp_operation_replace_get_bounding_box (GeglOperation *op)
{
GimpOperationLayerMode *self = (gpointer) op;
GeglRectangle *in_rect;
GeglRectangle *aux_rect;
GeglRectangle *aux2_rect;
GeglRectangle src_rect = {};
GeglRectangle dst_rect = {};
GeglRectangle result;
GimpLayerCompositeRegion included_region;
in_rect = gegl_operation_source_get_bounding_box (op, "input");
aux_rect = gegl_operation_source_get_bounding_box (op, "aux");
aux2_rect = gegl_operation_source_get_bounding_box (op, "aux2");
if (in_rect)
dst_rect = *in_rect;
if (aux_rect)
{
src_rect = *aux_rect;
if (aux2_rect)
gegl_rectangle_intersect (&src_rect, &src_rect, aux2_rect);
}
if (self->is_last_node)
{
included_region = GIMP_LAYER_COMPOSITE_REGION_SOURCE;
}
else
{
included_region = gimp_layer_mode_get_included_region (self->layer_mode,
self->composite_mode);
}
app: fix compositing of layers with masks, outside the mask bounds In GimpOperationLayerMode, when the op has a mask connected, and we're processing an area outside the mask bounds, set the op's opacity to 0, so that the backdrop shows through. The actual process() function gets a NULL mask pointer in this case, and so would composite the layer as if it had no mask, exposing areas that should be masked out. Add a GimpOperationLayerMode::parent_process() function, which subclasses can override instead of GeglOperation::process(), and make sure to update the GimpOperationLayerMode::opacity field before calling this function (and, subsequently, before calling GimpOperationLayerMode::process()). Clean up the rest of the fields, and adjust the rest of the code.
2020-02-21 11:58:15 -08:00
if (self->prop_opacity == 0.0)
app: in gimp:replace, implement GeglOperation::get_bounding_box() ... similarly to gimp:layer-mode, however, assume the destnation (backdrop) is not included when the layer's opacity is 1, and there's no mask.
2019-08-01 13:39:51 -07:00
included_region &= ~GIMP_LAYER_COMPOSITE_REGION_SOURCE;
app: fix compositing of layers with masks, outside the mask bounds In GimpOperationLayerMode, when the op has a mask connected, and we're processing an area outside the mask bounds, set the op's opacity to 0, so that the backdrop shows through. The actual process() function gets a NULL mask pointer in this case, and so would composite the layer as if it had no mask, exposing areas that should be masked out. Add a GimpOperationLayerMode::parent_process() function, which subclasses can override instead of GeglOperation::process(), and make sure to update the GimpOperationLayerMode::opacity field before calling this function (and, subsequently, before calling GimpOperationLayerMode::process()). Clean up the rest of the fields, and adjust the rest of the code.
2020-02-21 11:58:15 -08:00
else if (self->prop_opacity == 1.0 && ! aux2_rect)
app: in gimp:replace, implement GeglOperation::get_bounding_box() ... similarly to gimp:layer-mode, however, assume the destnation (backdrop) is not included when the layer's opacity is 1, and there's no mask.
2019-08-01 13:39:51 -07:00
included_region &= ~GIMP_LAYER_COMPOSITE_REGION_DESTINATION;
gegl_rectangle_intersect (&result, &src_rect, &dst_rect);
if (included_region & GIMP_LAYER_COMPOSITE_REGION_SOURCE)
gegl_rectangle_bounding_box (&result, &result, &src_rect);
if (included_region & GIMP_LAYER_COMPOSITE_REGION_DESTINATION)
gegl_rectangle_bounding_box (&result, &result, &dst_rect);
return result;
}
app: change behavior of REPLACE mode for fully-transparent pixels When the result of compositing has an alpha value of 0, the corresponding color value is not mathematically defined. Currently, all out layer modes opt to preserve the destination's color value in this case. However, REPLACE mode is different enough to warrant a different behavior: Unlike the other layer modes, when the compositing opacity approaches 0 or 1, the output color value approaches the destination or source color values, respectively, regardless of the output alpha value. When the opacity doesn't approach 0 or 1, the output color value generally doesn't approach a limit as the output alpha value approaches 0, however, when both the destination and source alpha values are equal, the output color value is always a simple linear interpolation between the destination and source color values, according to the opacity. In other words, this means that it's reasonable to simply use the above linear interpolation for the output color value, whenever the output alpha value is 0. Since filters are commonly combined with the input using REPALCE mode with full opacity, this has the effect that filters may now modify the color values of fully-transparent pixels. This is generally desirable, IMO, especially for point filters. Indeed, painting with REPLACE mode (i.e., with tools that use gimp_paint_core_replace()) behaved excatly as described above, and had this property, before we switched gimp_paint_core_replace() to use the common compositing code; this created a discrepancy between painting and applying filters, which is now gone. A side effect of this change is that we can now turn gimp:replace into a NOP when the opacity is 100% and there's no mask, which avoids the compositing step when applying filters. We could previously only apply this optimization to PASS_THROUGH mode, which is a subclass of REPLACE mode. Note that the discussion above concerns the UNION composite mode, which is the only mode we currently use REPLACE in. We modify the rest of the composite modes to match the new behavior: CLIP_TO_BACKDROP always preserves the color values of the destionation, CLIP_TO_LAYER always preserves the color values of the source, and INTERSECTION always produces fully-zeroed pixels.
2019-02-14 07:31:29 -08:00
static gboolean
gimp_operation_replace_parent_process (GeglOperation *op,
GeglOperationContext *context,
const gchar *output_prop,
const GeglRectangle *result,
gint level)
{
app: in gimp:replace, add fast path when compositing a layer over itself In gimp:replace, when compositing the same content over itself, i.e., when the input and aux buffers share the same storage and same tile alignment, pass the input buffer directly as output, instead of doing actual processing. In particular, this happens when processing a pass-through group outside of its actual bounds.
2020-02-20 02:52:44 -08:00
GimpOperationLayerMode *layer_mode = (gpointer) op;
GimpLayerCompositeRegion included_region;
included_region = gimp_layer_mode_get_included_region
app: fix compositing of layers with masks, outside the mask bounds In GimpOperationLayerMode, when the op has a mask connected, and we're processing an area outside the mask bounds, set the op's opacity to 0, so that the backdrop shows through. The actual process() function gets a NULL mask pointer in this case, and so would composite the layer as if it had no mask, exposing areas that should be masked out. Add a GimpOperationLayerMode::parent_process() function, which subclasses can override instead of GeglOperation::process(), and make sure to update the GimpOperationLayerMode::opacity field before calling this function (and, subsequently, before calling GimpOperationLayerMode::process()). Clean up the rest of the fields, and adjust the rest of the code.
2020-02-21 11:58:15 -08:00
(layer_mode->layer_mode, layer_mode->composite_mode);
app: change behavior of REPLACE mode for fully-transparent pixels When the result of compositing has an alpha value of 0, the corresponding color value is not mathematically defined. Currently, all out layer modes opt to preserve the destination's color value in this case. However, REPLACE mode is different enough to warrant a different behavior: Unlike the other layer modes, when the compositing opacity approaches 0 or 1, the output color value approaches the destination or source color values, respectively, regardless of the output alpha value. When the opacity doesn't approach 0 or 1, the output color value generally doesn't approach a limit as the output alpha value approaches 0, however, when both the destination and source alpha values are equal, the output color value is always a simple linear interpolation between the destination and source color values, according to the opacity. In other words, this means that it's reasonable to simply use the above linear interpolation for the output color value, whenever the output alpha value is 0. Since filters are commonly combined with the input using REPALCE mode with full opacity, this has the effect that filters may now modify the color values of fully-transparent pixels. This is generally desirable, IMO, especially for point filters. Indeed, painting with REPLACE mode (i.e., with tools that use gimp_paint_core_replace()) behaved excatly as described above, and had this property, before we switched gimp_paint_core_replace() to use the common compositing code; this created a discrepancy between painting and applying filters, which is now gone. A side effect of this change is that we can now turn gimp:replace into a NOP when the opacity is 100% and there's no mask, which avoids the compositing step when applying filters. We could previously only apply this optimization to PASS_THROUGH mode, which is a subclass of REPLACE mode. Note that the discussion above concerns the UNION composite mode, which is the only mode we currently use REPLACE in. We modify the rest of the composite modes to match the new behavior: CLIP_TO_BACKDROP always preserves the color values of the destionation, CLIP_TO_LAYER always preserves the color values of the source, and INTERSECTION always produces fully-zeroed pixels.
2019-02-14 07:31:29 -08:00
/* if the layer's opacity is 100%, it has no mask, and its composite mode
* contains "aux" (the latter should always be the case in practice,
* currently,) we can just pass "aux" directly as output.
*/
app: fix compositing of layers with masks, outside the mask bounds In GimpOperationLayerMode, when the op has a mask connected, and we're processing an area outside the mask bounds, set the op's opacity to 0, so that the backdrop shows through. The actual process() function gets a NULL mask pointer in this case, and so would composite the layer as if it had no mask, exposing areas that should be masked out. Add a GimpOperationLayerMode::parent_process() function, which subclasses can override instead of GeglOperation::process(), and make sure to update the GimpOperationLayerMode::opacity field before calling this function (and, subsequently, before calling GimpOperationLayerMode::process()). Clean up the rest of the fields, and adjust the rest of the code.
2020-02-21 11:58:15 -08:00
if (layer_mode->opacity == 1.0 &&
app: change behavior of REPLACE mode for fully-transparent pixels When the result of compositing has an alpha value of 0, the corresponding color value is not mathematically defined. Currently, all out layer modes opt to preserve the destination's color value in this case. However, REPLACE mode is different enough to warrant a different behavior: Unlike the other layer modes, when the compositing opacity approaches 0 or 1, the output color value approaches the destination or source color values, respectively, regardless of the output alpha value. When the opacity doesn't approach 0 or 1, the output color value generally doesn't approach a limit as the output alpha value approaches 0, however, when both the destination and source alpha values are equal, the output color value is always a simple linear interpolation between the destination and source color values, according to the opacity. In other words, this means that it's reasonable to simply use the above linear interpolation for the output color value, whenever the output alpha value is 0. Since filters are commonly combined with the input using REPALCE mode with full opacity, this has the effect that filters may now modify the color values of fully-transparent pixels. This is generally desirable, IMO, especially for point filters. Indeed, painting with REPLACE mode (i.e., with tools that use gimp_paint_core_replace()) behaved excatly as described above, and had this property, before we switched gimp_paint_core_replace() to use the common compositing code; this created a discrepancy between painting and applying filters, which is now gone. A side effect of this change is that we can now turn gimp:replace into a NOP when the opacity is 100% and there's no mask, which avoids the compositing step when applying filters. We could previously only apply this optimization to PASS_THROUGH mode, which is a subclass of REPLACE mode. Note that the discussion above concerns the UNION composite mode, which is the only mode we currently use REPLACE in. We modify the rest of the composite modes to match the new behavior: CLIP_TO_BACKDROP always preserves the color values of the destionation, CLIP_TO_LAYER always preserves the color values of the source, and INTERSECTION always produces fully-zeroed pixels.
2019-02-14 07:31:29 -08:00
! gegl_operation_context_get_object (context, "aux2") &&
app: in gimp:replace, add fast path when compositing a layer over itself In gimp:replace, when compositing the same content over itself, i.e., when the input and aux buffers share the same storage and same tile alignment, pass the input buffer directly as output, instead of doing actual processing. In particular, this happens when processing a pass-through group outside of its actual bounds.
2020-02-20 02:52:44 -08:00
(included_region & GIMP_LAYER_COMPOSITE_REGION_SOURCE))
app: change behavior of REPLACE mode for fully-transparent pixels When the result of compositing has an alpha value of 0, the corresponding color value is not mathematically defined. Currently, all out layer modes opt to preserve the destination's color value in this case. However, REPLACE mode is different enough to warrant a different behavior: Unlike the other layer modes, when the compositing opacity approaches 0 or 1, the output color value approaches the destination or source color values, respectively, regardless of the output alpha value. When the opacity doesn't approach 0 or 1, the output color value generally doesn't approach a limit as the output alpha value approaches 0, however, when both the destination and source alpha values are equal, the output color value is always a simple linear interpolation between the destination and source color values, according to the opacity. In other words, this means that it's reasonable to simply use the above linear interpolation for the output color value, whenever the output alpha value is 0. Since filters are commonly combined with the input using REPALCE mode with full opacity, this has the effect that filters may now modify the color values of fully-transparent pixels. This is generally desirable, IMO, especially for point filters. Indeed, painting with REPLACE mode (i.e., with tools that use gimp_paint_core_replace()) behaved excatly as described above, and had this property, before we switched gimp_paint_core_replace() to use the common compositing code; this created a discrepancy between painting and applying filters, which is now gone. A side effect of this change is that we can now turn gimp:replace into a NOP when the opacity is 100% and there's no mask, which avoids the compositing step when applying filters. We could previously only apply this optimization to PASS_THROUGH mode, which is a subclass of REPLACE mode. Note that the discussion above concerns the UNION composite mode, which is the only mode we currently use REPLACE in. We modify the rest of the composite modes to match the new behavior: CLIP_TO_BACKDROP always preserves the color values of the destionation, CLIP_TO_LAYER always preserves the color values of the source, and INTERSECTION always produces fully-zeroed pixels.
2019-02-14 07:31:29 -08:00
{
GObject *aux;
Revert "app: avoid NULL output in layer-mode ops" On a second thought... nope :) We'll fix it another way. This reverts commit 60947b7a34826657395ca485d334ccb302106e07.
2019-05-31 09:59:17 -07:00
aux = gegl_operation_context_get_object (context, "aux");
app: change behavior of REPLACE mode for fully-transparent pixels When the result of compositing has an alpha value of 0, the corresponding color value is not mathematically defined. Currently, all out layer modes opt to preserve the destination's color value in this case. However, REPLACE mode is different enough to warrant a different behavior: Unlike the other layer modes, when the compositing opacity approaches 0 or 1, the output color value approaches the destination or source color values, respectively, regardless of the output alpha value. When the opacity doesn't approach 0 or 1, the output color value generally doesn't approach a limit as the output alpha value approaches 0, however, when both the destination and source alpha values are equal, the output color value is always a simple linear interpolation between the destination and source color values, according to the opacity. In other words, this means that it's reasonable to simply use the above linear interpolation for the output color value, whenever the output alpha value is 0. Since filters are commonly combined with the input using REPALCE mode with full opacity, this has the effect that filters may now modify the color values of fully-transparent pixels. This is generally desirable, IMO, especially for point filters. Indeed, painting with REPLACE mode (i.e., with tools that use gimp_paint_core_replace()) behaved excatly as described above, and had this property, before we switched gimp_paint_core_replace() to use the common compositing code; this created a discrepancy between painting and applying filters, which is now gone. A side effect of this change is that we can now turn gimp:replace into a NOP when the opacity is 100% and there's no mask, which avoids the compositing step when applying filters. We could previously only apply this optimization to PASS_THROUGH mode, which is a subclass of REPLACE mode. Note that the discussion above concerns the UNION composite mode, which is the only mode we currently use REPLACE in. We modify the rest of the composite modes to match the new behavior: CLIP_TO_BACKDROP always preserves the color values of the destionation, CLIP_TO_LAYER always preserves the color values of the source, and INTERSECTION always produces fully-zeroed pixels.
2019-02-14 07:31:29 -08:00
Revert "app: avoid NULL output in layer-mode ops" On a second thought... nope :) We'll fix it another way. This reverts commit 60947b7a34826657395ca485d334ccb302106e07.
2019-05-31 09:59:17 -07:00
gegl_operation_context_set_object (context, "output", aux);
app: change behavior of REPLACE mode for fully-transparent pixels When the result of compositing has an alpha value of 0, the corresponding color value is not mathematically defined. Currently, all out layer modes opt to preserve the destination's color value in this case. However, REPLACE mode is different enough to warrant a different behavior: Unlike the other layer modes, when the compositing opacity approaches 0 or 1, the output color value approaches the destination or source color values, respectively, regardless of the output alpha value. When the opacity doesn't approach 0 or 1, the output color value generally doesn't approach a limit as the output alpha value approaches 0, however, when both the destination and source alpha values are equal, the output color value is always a simple linear interpolation between the destination and source color values, according to the opacity. In other words, this means that it's reasonable to simply use the above linear interpolation for the output color value, whenever the output alpha value is 0. Since filters are commonly combined with the input using REPALCE mode with full opacity, this has the effect that filters may now modify the color values of fully-transparent pixels. This is generally desirable, IMO, especially for point filters. Indeed, painting with REPLACE mode (i.e., with tools that use gimp_paint_core_replace()) behaved excatly as described above, and had this property, before we switched gimp_paint_core_replace() to use the common compositing code; this created a discrepancy between painting and applying filters, which is now gone. A side effect of this change is that we can now turn gimp:replace into a NOP when the opacity is 100% and there's no mask, which avoids the compositing step when applying filters. We could previously only apply this optimization to PASS_THROUGH mode, which is a subclass of REPLACE mode. Note that the discussion above concerns the UNION composite mode, which is the only mode we currently use REPLACE in. We modify the rest of the composite modes to match the new behavior: CLIP_TO_BACKDROP always preserves the color values of the destionation, CLIP_TO_LAYER always preserves the color values of the source, and INTERSECTION always produces fully-zeroed pixels.
2019-02-14 07:31:29 -08:00
return TRUE;
}
/* the opposite case, where the opacity is 0%, is handled by
* GimpOperationLayerMode.
*/
app: in gimp:replace, add fast path when compositing a layer over itself In gimp:replace, when compositing the same content over itself, i.e., when the input and aux buffers share the same storage and same tile alignment, pass the input buffer directly as output, instead of doing actual processing. In particular, this happens when processing a pass-through group outside of its actual bounds.
2020-02-20 02:52:44 -08:00
else if (layer_mode->opacity == 0.0)
{
}
/* if both buffers are included in the result, and if both of them have the
* same content -- i.e., if they share the same storage, same alignment, and
* same abyss (or if the abyss is irrelevant) -- we can just pass either of
* them directly as output.
*/
else if (included_region == GIMP_LAYER_COMPOSITE_REGION_UNION)
{
GObject *input;
GObject *aux;
input = gegl_operation_context_get_object (context, "input");
aux = gegl_operation_context_get_object (context, "aux");
if (input && aux &&
gegl_buffer_share_storage (GEGL_BUFFER (input), GEGL_BUFFER (aux)))
{
gint input_shift_x;
gint input_shift_y;
gint aux_shift_x;
gint aux_shift_y;
g_object_get (input,
"shift-x", &input_shift_x,
"shift-y", &input_shift_y,
NULL);
g_object_get (aux,
"shift-x", &aux_shift_x,
"shift-y", &aux_shift_y,
NULL);
if (input_shift_x == aux_shift_x && input_shift_y == aux_shift_y)
{
const GeglRectangle *input_abyss;
const GeglRectangle *aux_abyss;
input_abyss = gegl_buffer_get_abyss (GEGL_BUFFER (input));
aux_abyss = gegl_buffer_get_abyss (GEGL_BUFFER (aux));
if (gegl_rectangle_equal (input_abyss, aux_abyss) ||
(gegl_rectangle_contains (input_abyss, result) &&
gegl_rectangle_contains (aux_abyss, result)))
{
gegl_operation_context_set_object (context, "output", input);
return TRUE;
}
}
}
}
app: change behavior of REPLACE mode for fully-transparent pixels When the result of compositing has an alpha value of 0, the corresponding color value is not mathematically defined. Currently, all out layer modes opt to preserve the destination's color value in this case. However, REPLACE mode is different enough to warrant a different behavior: Unlike the other layer modes, when the compositing opacity approaches 0 or 1, the output color value approaches the destination or source color values, respectively, regardless of the output alpha value. When the opacity doesn't approach 0 or 1, the output color value generally doesn't approach a limit as the output alpha value approaches 0, however, when both the destination and source alpha values are equal, the output color value is always a simple linear interpolation between the destination and source color values, according to the opacity. In other words, this means that it's reasonable to simply use the above linear interpolation for the output color value, whenever the output alpha value is 0. Since filters are commonly combined with the input using REPALCE mode with full opacity, this has the effect that filters may now modify the color values of fully-transparent pixels. This is generally desirable, IMO, especially for point filters. Indeed, painting with REPLACE mode (i.e., with tools that use gimp_paint_core_replace()) behaved excatly as described above, and had this property, before we switched gimp_paint_core_replace() to use the common compositing code; this created a discrepancy between painting and applying filters, which is now gone. A side effect of this change is that we can now turn gimp:replace into a NOP when the opacity is 100% and there's no mask, which avoids the compositing step when applying filters. We could previously only apply this optimization to PASS_THROUGH mode, which is a subclass of REPLACE mode. Note that the discussion above concerns the UNION composite mode, which is the only mode we currently use REPLACE in. We modify the rest of the composite modes to match the new behavior: CLIP_TO_BACKDROP always preserves the color values of the destionation, CLIP_TO_LAYER always preserves the color values of the source, and INTERSECTION always produces fully-zeroed pixels.
2019-02-14 07:31:29 -08:00
app: fix compositing of layers with masks, outside the mask bounds In GimpOperationLayerMode, when the op has a mask connected, and we're processing an area outside the mask bounds, set the op's opacity to 0, so that the backdrop shows through. The actual process() function gets a NULL mask pointer in this case, and so would composite the layer as if it had no mask, exposing areas that should be masked out. Add a GimpOperationLayerMode::parent_process() function, which subclasses can override instead of GeglOperation::process(), and make sure to update the GimpOperationLayerMode::opacity field before calling this function (and, subsequently, before calling GimpOperationLayerMode::process()). Clean up the rest of the fields, and adjust the rest of the code.
2020-02-21 11:58:15 -08:00
return GIMP_OPERATION_LAYER_MODE_CLASS (parent_class)->parent_process (
op, context, output_prop, result, level);
app: change behavior of REPLACE mode for fully-transparent pixels When the result of compositing has an alpha value of 0, the corresponding color value is not mathematically defined. Currently, all out layer modes opt to preserve the destination's color value in this case. However, REPLACE mode is different enough to warrant a different behavior: Unlike the other layer modes, when the compositing opacity approaches 0 or 1, the output color value approaches the destination or source color values, respectively, regardless of the output alpha value. When the opacity doesn't approach 0 or 1, the output color value generally doesn't approach a limit as the output alpha value approaches 0, however, when both the destination and source alpha values are equal, the output color value is always a simple linear interpolation between the destination and source color values, according to the opacity. In other words, this means that it's reasonable to simply use the above linear interpolation for the output color value, whenever the output alpha value is 0. Since filters are commonly combined with the input using REPALCE mode with full opacity, this has the effect that filters may now modify the color values of fully-transparent pixels. This is generally desirable, IMO, especially for point filters. Indeed, painting with REPLACE mode (i.e., with tools that use gimp_paint_core_replace()) behaved excatly as described above, and had this property, before we switched gimp_paint_core_replace() to use the common compositing code; this created a discrepancy between painting and applying filters, which is now gone. A side effect of this change is that we can now turn gimp:replace into a NOP when the opacity is 100% and there's no mask, which avoids the compositing step when applying filters. We could previously only apply this optimization to PASS_THROUGH mode, which is a subclass of REPLACE mode. Note that the discussion above concerns the UNION composite mode, which is the only mode we currently use REPLACE in. We modify the rest of the composite modes to match the new behavior: CLIP_TO_BACKDROP always preserves the color values of the destionation, CLIP_TO_LAYER always preserves the color values of the source, and INTERSECTION always produces fully-zeroed pixels.
2019-02-14 07:31:29 -08:00
}
app: layer mode code shuffling Commit 3635cf04ab69bafb76d7583da804f580f2d5fbf3 moved the special handling of bottom-layer compositing to GimpOperationLayerMode. This required giving the op more control over the process() function of its subclasses. As a temporary workaround, the commit bypassed the subclasses entirely, using "gimp:layer-mode" for all modes. This is the reckoning :) Add a process() virtual function to GimpOperationLayerMode, which its subclasses should override instead of GeglOperationPointComposer3's process() functions. Reinstate the subclasses (by returning the correct op in gimp_layer_mode_get_oepration()), and have them override this function. Improve the way gimp_operation_layer_mode_process() dispatches to the actual process function, to slightly lower its overhead and fix some thread-safety issues. Remove the "function" field of the layer-mode info array, and have gimp_layer_mode_get_function() return the GimpOperationLayerMode::process() function of the corresponding op's class (caching the result, to keep it cheap.) This reduces redundancy, allows us to make the ops' process() functions private, and simplifies SSE dispatching (only used by NORMAL mode, currently.) Move the blend and composite functions of the non-specialized layer modes to gimpoperationlayermode-{blend,composite}.[hc], respectively, to improve code organization. Move the SSE2 composite functions to a separate file, so that they can be built as part of libapplayermodes_sse2, allowing libapplayermodes to be built without SSE2 compiler flags. This allows building GIMP with SSE acceleration enabled, while running the resulting binary on a target with no SSE accelration. Add a "blend_function" field to the layer-mode info array, and use it to specify the blend function for the non-specialized modes. This replaces the separate switch() statement that we used previously. Remove the "affected_region" field of the layer-mode info array. We don't need it anymore, since we can go back to using GimpOperationLayerMode's virtual get_affected_region() function. Last but not least, a bunch of code cleanups and consistency adjustments.
2017-08-17 07:26:49 -07:00
static gboolean
app: remove a trampoline in layer/paint mode dispatch Fully removes one trampoline level and passing fewer args through the remaining trampoline.
2017-01-20 16:37:37 -08:00
gimp_operation_replace_process (GeglOperation *op,
void *in_p,
void *layer_p,
void *mask_p,
void *out_p,
app: move the remaining 3 layer modes to layer-modes/ Not exactly sure if all are correct, but the file moving is almost done now.
2017-01-11 03:55:13 -08:00
glong samples,
const GeglRectangle *roi,
gint level)
app: add back individual operation classes for the layer modes They are derived from GimpOperationPointLayerMode and are completely empty and unused, but can be filled with code and enabled one-by-one now.
2009-12-30 06:18:44 -08:00
{
app: rename GimpOperationPointLayerMode to GimpOperationLayerMode and formatting cleanup.
2017-01-21 12:35:52 -08:00
GimpOperationLayerMode *layer_mode = (gpointer) op;
gfloat *in = in_p;
gfloat *out = out_p;
gfloat *layer = layer_p;
gfloat *mask = mask_p;
gfloat opacity = layer_mode->opacity;
const gboolean has_mask = mask != NULL;
app: change mask handling in GimpOperationReplaceMode to be like in the other modes, and proably speed it up a little.
2017-01-11 03:38:58 -08:00
app: fix compositing of layers with masks, outside the mask bounds In GimpOperationLayerMode, when the op has a mask connected, and we're processing an area outside the mask bounds, set the op's opacity to 0, so that the backdrop shows through. The actual process() function gets a NULL mask pointer in this case, and so would composite the layer as if it had no mask, exposing areas that should be masked out. Add a GimpOperationLayerMode::parent_process() function, which subclasses can override instead of GeglOperation::process(), and make sure to update the GimpOperationLayerMode::opacity field before calling this function (and, subsequently, before calling GimpOperationLayerMode::process()). Clean up the rest of the fields, and adjust the rest of the code.
2020-02-21 11:58:15 -08:00
switch (layer_mode->composite_mode)
app: add back individual operation classes for the layer modes They are derived from GimpOperationPointLayerMode and are completely empty and unused, but can be filled with code and enabled one-by-one now.
2009-12-30 06:18:44 -08:00
{
app, pdb, libgimp, plug-ins, menus: rename layer composite modes Our composite modes don't correspond directly to the Porter-Duff operators after which they're named, and these names aren't too descriptive anyway. Rename the composite modes as follows: Source Over => Union Source Atop => Clip to Backdrop Destination Atop => Clip to Layer Source In => Intersection Update relevant code, including UI text, enumerator names, function names, and action names.
2018-03-14 11:52:10 -07:00
case GIMP_LAYER_COMPOSITE_UNION:
app: implement the different composite modes for replace mode
2017-02-17 09:28:14 -08:00
case GIMP_LAYER_COMPOSITE_AUTO:
while (samples--)
{
gfloat opacity_value = opacity;
gfloat new_alpha;
app: change behavior of REPLACE mode for fully-transparent pixels When the result of compositing has an alpha value of 0, the corresponding color value is not mathematically defined. Currently, all out layer modes opt to preserve the destination's color value in this case. However, REPLACE mode is different enough to warrant a different behavior: Unlike the other layer modes, when the compositing opacity approaches 0 or 1, the output color value approaches the destination or source color values, respectively, regardless of the output alpha value. When the opacity doesn't approach 0 or 1, the output color value generally doesn't approach a limit as the output alpha value approaches 0, however, when both the destination and source alpha values are equal, the output color value is always a simple linear interpolation between the destination and source color values, according to the opacity. In other words, this means that it's reasonable to simply use the above linear interpolation for the output color value, whenever the output alpha value is 0. Since filters are commonly combined with the input using REPALCE mode with full opacity, this has the effect that filters may now modify the color values of fully-transparent pixels. This is generally desirable, IMO, especially for point filters. Indeed, painting with REPLACE mode (i.e., with tools that use gimp_paint_core_replace()) behaved excatly as described above, and had this property, before we switched gimp_paint_core_replace() to use the common compositing code; this created a discrepancy between painting and applying filters, which is now gone. A side effect of this change is that we can now turn gimp:replace into a NOP when the opacity is 100% and there's no mask, which avoids the compositing step when applying filters. We could previously only apply this optimization to PASS_THROUGH mode, which is a subclass of REPLACE mode. Note that the discussion above concerns the UNION composite mode, which is the only mode we currently use REPLACE in. We modify the rest of the composite modes to match the new behavior: CLIP_TO_BACKDROP always preserves the color values of the destionation, CLIP_TO_LAYER always preserves the color values of the source, and INTERSECTION always produces fully-zeroed pixels.
2019-02-14 07:31:29 -08:00
gfloat ratio;
app: implement the different composite modes for replace mode
2017-02-17 09:28:14 -08:00
gint b;
app: don't crash GimpOperationReplaceMode is mask is NULL
2012-04-24 12:42:41 -07:00
app: implement the different composite modes for replace mode
2017-02-17 09:28:14 -08:00
if (has_mask)
opacity_value *= *mask;
app: change mask handling in GimpOperationReplaceMode to be like in the other modes, and proably speed it up a little.
2017-01-11 03:38:58 -08:00
app: implement the different composite modes for replace mode
2017-02-17 09:28:14 -08:00
new_alpha = (layer[ALPHA] - in[ALPHA]) * opacity_value + in[ALPHA];
app: added initial gegl replace mode
2012-04-24 02:25:19 -07:00
app: change behavior of REPLACE mode for fully-transparent pixels When the result of compositing has an alpha value of 0, the corresponding color value is not mathematically defined. Currently, all out layer modes opt to preserve the destination's color value in this case. However, REPLACE mode is different enough to warrant a different behavior: Unlike the other layer modes, when the compositing opacity approaches 0 or 1, the output color value approaches the destination or source color values, respectively, regardless of the output alpha value. When the opacity doesn't approach 0 or 1, the output color value generally doesn't approach a limit as the output alpha value approaches 0, however, when both the destination and source alpha values are equal, the output color value is always a simple linear interpolation between the destination and source color values, according to the opacity. In other words, this means that it's reasonable to simply use the above linear interpolation for the output color value, whenever the output alpha value is 0. Since filters are commonly combined with the input using REPALCE mode with full opacity, this has the effect that filters may now modify the color values of fully-transparent pixels. This is generally desirable, IMO, especially for point filters. Indeed, painting with REPLACE mode (i.e., with tools that use gimp_paint_core_replace()) behaved excatly as described above, and had this property, before we switched gimp_paint_core_replace() to use the common compositing code; this created a discrepancy between painting and applying filters, which is now gone. A side effect of this change is that we can now turn gimp:replace into a NOP when the opacity is 100% and there's no mask, which avoids the compositing step when applying filters. We could previously only apply this optimization to PASS_THROUGH mode, which is a subclass of REPLACE mode. Note that the discussion above concerns the UNION composite mode, which is the only mode we currently use REPLACE in. We modify the rest of the composite modes to match the new behavior: CLIP_TO_BACKDROP always preserves the color values of the destionation, CLIP_TO_LAYER always preserves the color values of the source, and INTERSECTION always produces fully-zeroed pixels.
2019-02-14 07:31:29 -08:00
ratio = opacity_value;
app: implement the different composite modes for replace mode
2017-02-17 09:28:14 -08:00
if (new_alpha)
app: change behavior of REPLACE mode for fully-transparent pixels When the result of compositing has an alpha value of 0, the corresponding color value is not mathematically defined. Currently, all out layer modes opt to preserve the destination's color value in this case. However, REPLACE mode is different enough to warrant a different behavior: Unlike the other layer modes, when the compositing opacity approaches 0 or 1, the output color value approaches the destination or source color values, respectively, regardless of the output alpha value. When the opacity doesn't approach 0 or 1, the output color value generally doesn't approach a limit as the output alpha value approaches 0, however, when both the destination and source alpha values are equal, the output color value is always a simple linear interpolation between the destination and source color values, according to the opacity. In other words, this means that it's reasonable to simply use the above linear interpolation for the output color value, whenever the output alpha value is 0. Since filters are commonly combined with the input using REPALCE mode with full opacity, this has the effect that filters may now modify the color values of fully-transparent pixels. This is generally desirable, IMO, especially for point filters. Indeed, painting with REPLACE mode (i.e., with tools that use gimp_paint_core_replace()) behaved excatly as described above, and had this property, before we switched gimp_paint_core_replace() to use the common compositing code; this created a discrepancy between painting and applying filters, which is now gone. A side effect of this change is that we can now turn gimp:replace into a NOP when the opacity is 100% and there's no mask, which avoids the compositing step when applying filters. We could previously only apply this optimization to PASS_THROUGH mode, which is a subclass of REPLACE mode. Note that the discussion above concerns the UNION composite mode, which is the only mode we currently use REPLACE in. We modify the rest of the composite modes to match the new behavior: CLIP_TO_BACKDROP always preserves the color values of the destionation, CLIP_TO_LAYER always preserves the color values of the source, and INTERSECTION always produces fully-zeroed pixels.
2019-02-14 07:31:29 -08:00
ratio *= layer[ALPHA] / new_alpha;
for (b = RED; b < ALPHA; b++)
out[b] = (layer[b] - in[b]) * ratio + in[b];
app: implement the different composite modes for replace mode
2017-02-17 09:28:14 -08:00
out[ALPHA] = new_alpha;
in += 4;
layer += 4;
out += 4;
if (has_mask)
mask++;
app: added initial gegl replace mode
2012-04-24 02:25:19 -07:00
}
app: implement the different composite modes for replace mode
2017-02-17 09:28:14 -08:00
break;
app, pdb, libgimp, plug-ins, menus: rename layer composite modes Our composite modes don't correspond directly to the Porter-Duff operators after which they're named, and these names aren't too descriptive anyway. Rename the composite modes as follows: Source Over => Union Source Atop => Clip to Backdrop Destination Atop => Clip to Layer Source In => Intersection Update relevant code, including UI text, enumerator names, function names, and action names.
2018-03-14 11:52:10 -07:00
case GIMP_LAYER_COMPOSITE_CLIP_TO_BACKDROP:
app: implement the different composite modes for replace mode
2017-02-17 09:28:14 -08:00
while (samples--)
app: fix GimpOperationReplaceMode to not do two things different than legacy
2012-04-30 19:11:16 -07:00
{
app: implement the different composite modes for replace mode
2017-02-17 09:28:14 -08:00
gfloat opacity_value = opacity;
gfloat new_alpha;
gint b;
if (has_mask)
opacity_value *= *mask;
new_alpha = in[ALPHA] * (1.0f - opacity_value);
app: fix GimpOperationReplaceMode to not do two things different than legacy
2012-04-30 19:11:16 -07:00
for (b = RED; b < ALPHA; b++)
out[b] = in[b];
app: implement the different composite modes for replace mode
2017-02-17 09:28:14 -08:00
out[ALPHA] = new_alpha;
app: change behavior of REPLACE mode for fully-transparent pixels When the result of compositing has an alpha value of 0, the corresponding color value is not mathematically defined. Currently, all out layer modes opt to preserve the destination's color value in this case. However, REPLACE mode is different enough to warrant a different behavior: Unlike the other layer modes, when the compositing opacity approaches 0 or 1, the output color value approaches the destination or source color values, respectively, regardless of the output alpha value. When the opacity doesn't approach 0 or 1, the output color value generally doesn't approach a limit as the output alpha value approaches 0, however, when both the destination and source alpha values are equal, the output color value is always a simple linear interpolation between the destination and source color values, according to the opacity. In other words, this means that it's reasonable to simply use the above linear interpolation for the output color value, whenever the output alpha value is 0. Since filters are commonly combined with the input using REPALCE mode with full opacity, this has the effect that filters may now modify the color values of fully-transparent pixels. This is generally desirable, IMO, especially for point filters. Indeed, painting with REPLACE mode (i.e., with tools that use gimp_paint_core_replace()) behaved excatly as described above, and had this property, before we switched gimp_paint_core_replace() to use the common compositing code; this created a discrepancy between painting and applying filters, which is now gone. A side effect of this change is that we can now turn gimp:replace into a NOP when the opacity is 100% and there's no mask, which avoids the compositing step when applying filters. We could previously only apply this optimization to PASS_THROUGH mode, which is a subclass of REPLACE mode. Note that the discussion above concerns the UNION composite mode, which is the only mode we currently use REPLACE in. We modify the rest of the composite modes to match the new behavior: CLIP_TO_BACKDROP always preserves the color values of the destionation, CLIP_TO_LAYER always preserves the color values of the source, and INTERSECTION always produces fully-zeroed pixels.
2019-02-14 07:31:29 -08:00
in += 4;
out += 4;
app: implement the different composite modes for replace mode
2017-02-17 09:28:14 -08:00
if (has_mask)
mask++;
}
break;
app, pdb, libgimp, plug-ins, menus: rename layer composite modes Our composite modes don't correspond directly to the Porter-Duff operators after which they're named, and these names aren't too descriptive anyway. Rename the composite modes as follows: Source Over => Union Source Atop => Clip to Backdrop Destination Atop => Clip to Layer Source In => Intersection Update relevant code, including UI text, enumerator names, function names, and action names.
2018-03-14 11:52:10 -07:00
case GIMP_LAYER_COMPOSITE_CLIP_TO_LAYER:
app: implement the different composite modes for replace mode
2017-02-17 09:28:14 -08:00
while (samples--)
{
gfloat opacity_value = opacity;
gfloat new_alpha;
gint b;
if (has_mask)
opacity_value *= *mask;
new_alpha = layer[ALPHA] * opacity_value;
app: change behavior of REPLACE mode for fully-transparent pixels When the result of compositing has an alpha value of 0, the corresponding color value is not mathematically defined. Currently, all out layer modes opt to preserve the destination's color value in this case. However, REPLACE mode is different enough to warrant a different behavior: Unlike the other layer modes, when the compositing opacity approaches 0 or 1, the output color value approaches the destination or source color values, respectively, regardless of the output alpha value. When the opacity doesn't approach 0 or 1, the output color value generally doesn't approach a limit as the output alpha value approaches 0, however, when both the destination and source alpha values are equal, the output color value is always a simple linear interpolation between the destination and source color values, according to the opacity. In other words, this means that it's reasonable to simply use the above linear interpolation for the output color value, whenever the output alpha value is 0. Since filters are commonly combined with the input using REPALCE mode with full opacity, this has the effect that filters may now modify the color values of fully-transparent pixels. This is generally desirable, IMO, especially for point filters. Indeed, painting with REPLACE mode (i.e., with tools that use gimp_paint_core_replace()) behaved excatly as described above, and had this property, before we switched gimp_paint_core_replace() to use the common compositing code; this created a discrepancy between painting and applying filters, which is now gone. A side effect of this change is that we can now turn gimp:replace into a NOP when the opacity is 100% and there's no mask, which avoids the compositing step when applying filters. We could previously only apply this optimization to PASS_THROUGH mode, which is a subclass of REPLACE mode. Note that the discussion above concerns the UNION composite mode, which is the only mode we currently use REPLACE in. We modify the rest of the composite modes to match the new behavior: CLIP_TO_BACKDROP always preserves the color values of the destionation, CLIP_TO_LAYER always preserves the color values of the source, and INTERSECTION always produces fully-zeroed pixels.
2019-02-14 07:31:29 -08:00
for (b = RED; b < ALPHA; b++)
out[b] = layer[b];
app: implement the different composite modes for replace mode
2017-02-17 09:28:14 -08:00
out[ALPHA] = new_alpha;
in += 4;
layer += 4;
out += 4;
if (has_mask)
mask++;
app: fix GimpOperationReplaceMode to not do two things different than legacy
2012-04-30 19:11:16 -07:00
}
app: implement the different composite modes for replace mode
2017-02-17 09:28:14 -08:00
break;
app: added initial gegl replace mode
2012-04-24 02:25:19 -07:00
app, pdb, libgimp, plug-ins, menus: rename layer composite modes Our composite modes don't correspond directly to the Porter-Duff operators after which they're named, and these names aren't too descriptive anyway. Rename the composite modes as follows: Source Over => Union Source Atop => Clip to Backdrop Destination Atop => Clip to Layer Source In => Intersection Update relevant code, including UI text, enumerator names, function names, and action names.
2018-03-14 11:52:10 -07:00
case GIMP_LAYER_COMPOSITE_INTERSECTION:
app: change behavior of REPLACE mode for fully-transparent pixels When the result of compositing has an alpha value of 0, the corresponding color value is not mathematically defined. Currently, all out layer modes opt to preserve the destination's color value in this case. However, REPLACE mode is different enough to warrant a different behavior: Unlike the other layer modes, when the compositing opacity approaches 0 or 1, the output color value approaches the destination or source color values, respectively, regardless of the output alpha value. When the opacity doesn't approach 0 or 1, the output color value generally doesn't approach a limit as the output alpha value approaches 0, however, when both the destination and source alpha values are equal, the output color value is always a simple linear interpolation between the destination and source color values, according to the opacity. In other words, this means that it's reasonable to simply use the above linear interpolation for the output color value, whenever the output alpha value is 0. Since filters are commonly combined with the input using REPALCE mode with full opacity, this has the effect that filters may now modify the color values of fully-transparent pixels. This is generally desirable, IMO, especially for point filters. Indeed, painting with REPLACE mode (i.e., with tools that use gimp_paint_core_replace()) behaved excatly as described above, and had this property, before we switched gimp_paint_core_replace() to use the common compositing code; this created a discrepancy between painting and applying filters, which is now gone. A side effect of this change is that we can now turn gimp:replace into a NOP when the opacity is 100% and there's no mask, which avoids the compositing step when applying filters. We could previously only apply this optimization to PASS_THROUGH mode, which is a subclass of REPLACE mode. Note that the discussion above concerns the UNION composite mode, which is the only mode we currently use REPLACE in. We modify the rest of the composite modes to match the new behavior: CLIP_TO_BACKDROP always preserves the color values of the destionation, CLIP_TO_LAYER always preserves the color values of the source, and INTERSECTION always produces fully-zeroed pixels.
2019-02-14 07:31:29 -08:00
memset (out, 0, 4 * samples * sizeof (gfloat));
app: implement the different composite modes for replace mode
2017-02-17 09:28:14 -08:00
break;
app: add back individual operation classes for the layer modes They are derived from GimpOperationPointLayerMode and are completely empty and unused, but can be filled with code and enabled one-by-one now.
2009-12-30 06:18:44 -08:00
}
return TRUE;
}
app: move all special-case mode processing optimizations to GimpOperationLayerMode Stuff like passing "input" directly if "aux"'s opacity is 0, etc. Used to be partly handled by normal mode, even though it applies to other modes too. Adjust the logic for the new compositing modes. Add a GimpLayerModeAffectMask enum, and a corresponding get_affect_mask() function to GimpOperationLayerMode, which specifies which of the op's inputs, if any, are affected by the mode, apart from the overlapping regions. Most modes affect only the overlapping regions, but dissolve and replace also affect the rest of the input. This information is used for determining if the optimizations are applicable.
2017-02-02 07:53:09 -08:00
app: rename GimpLayerModeAffectMask to GimpLayerCompositeRegion ... so that we can use it for other functions that involve compositing regions (which we do in the next commit). Rename gimp_operation_layer_mode_get_affect_mask() and friends to _get_affected_region().
2017-05-07 12:42:22 -07:00
static GimpLayerCompositeRegion
gimp_operation_replace_get_affected_region (GimpOperationLayerMode *layer_mode)
app: move all special-case mode processing optimizations to GimpOperationLayerMode Stuff like passing "input" directly if "aux"'s opacity is 0, etc. Used to be partly handled by normal mode, even though it applies to other modes too. Adjust the logic for the new compositing modes. Add a GimpLayerModeAffectMask enum, and a corresponding get_affect_mask() function to GimpOperationLayerMode, which specifies which of the op's inputs, if any, are affected by the mode, apart from the overlapping regions. Most modes affect only the overlapping regions, but dissolve and replace also affect the rest of the input. This information is used for determining if the optimizations are applicable.
2017-02-02 07:53:09 -08:00
{
app: rename GimpLayerModeAffectMask to GimpLayerCompositeRegion ... so that we can use it for other functions that involve compositing regions (which we do in the next commit). Rename gimp_operation_layer_mode_get_affect_mask() and friends to _get_affected_region().
2017-05-07 12:42:22 -07:00
GimpLayerCompositeRegion affected_region = GIMP_LAYER_COMPOSITE_REGION_INTERSECTION;
app: move all special-case mode processing optimizations to GimpOperationLayerMode Stuff like passing "input" directly if "aux"'s opacity is 0, etc. Used to be partly handled by normal mode, even though it applies to other modes too. Adjust the logic for the new compositing modes. Add a GimpLayerModeAffectMask enum, and a corresponding get_affect_mask() function to GimpOperationLayerMode, which specifies which of the op's inputs, if any, are affected by the mode, apart from the overlapping regions. Most modes affect only the overlapping regions, but dissolve and replace also affect the rest of the input. This information is used for determining if the optimizations are applicable.
2017-02-02 07:53:09 -08:00
app: fix compositing of layers with masks, outside the mask bounds In GimpOperationLayerMode, when the op has a mask connected, and we're processing an area outside the mask bounds, set the op's opacity to 0, so that the backdrop shows through. The actual process() function gets a NULL mask pointer in this case, and so would composite the layer as if it had no mask, exposing areas that should be masked out. Add a GimpOperationLayerMode::parent_process() function, which subclasses can override instead of GeglOperation::process(), and make sure to update the GimpOperationLayerMode::opacity field before calling this function (and, subsequently, before calling GimpOperationLayerMode::process()). Clean up the rest of the fields, and adjust the rest of the code.
2020-02-21 11:58:15 -08:00
if (layer_mode->prop_opacity != 0.0)
app: rename GimpLayerModeAffectMask to GimpLayerCompositeRegion ... so that we can use it for other functions that involve compositing regions (which we do in the next commit). Rename gimp_operation_layer_mode_get_affect_mask() and friends to _get_affected_region().
2017-05-07 12:42:22 -07:00
affected_region |= GIMP_LAYER_COMPOSITE_REGION_DESTINATION;
app: move all special-case mode processing optimizations to GimpOperationLayerMode Stuff like passing "input" directly if "aux"'s opacity is 0, etc. Used to be partly handled by normal mode, even though it applies to other modes too. Adjust the logic for the new compositing modes. Add a GimpLayerModeAffectMask enum, and a corresponding get_affect_mask() function to GimpOperationLayerMode, which specifies which of the op's inputs, if any, are affected by the mode, apart from the overlapping regions. Most modes affect only the overlapping regions, but dissolve and replace also affect the rest of the input. This information is used for determining if the optimizations are applicable.
2017-02-02 07:53:09 -08:00
app: rename GimpLayerModeAffectMask to GimpLayerCompositeRegion ... so that we can use it for other functions that involve compositing regions (which we do in the next commit). Rename gimp_operation_layer_mode_get_affect_mask() and friends to _get_affected_region().
2017-05-07 12:42:22 -07:00
/* if opacity != 1.0, or we have a mask, then we also affect SOURCE, but this
* is considered the case anyway, so no need for special handling.
app: move all special-case mode processing optimizations to GimpOperationLayerMode Stuff like passing "input" directly if "aux"'s opacity is 0, etc. Used to be partly handled by normal mode, even though it applies to other modes too. Adjust the logic for the new compositing modes. Add a GimpLayerModeAffectMask enum, and a corresponding get_affect_mask() function to GimpOperationLayerMode, which specifies which of the op's inputs, if any, are affected by the mode, apart from the overlapping regions. Most modes affect only the overlapping regions, but dissolve and replace also affect the rest of the input. This information is used for determining if the optimizations are applicable.
2017-02-02 07:53:09 -08:00
*/
app: rename GimpLayerModeAffectMask to GimpLayerCompositeRegion ... so that we can use it for other functions that involve compositing regions (which we do in the next commit). Rename gimp_operation_layer_mode_get_affect_mask() and friends to _get_affected_region().
2017-05-07 12:42:22 -07:00
return affected_region;
app: move all special-case mode processing optimizations to GimpOperationLayerMode Stuff like passing "input" directly if "aux"'s opacity is 0, etc. Used to be partly handled by normal mode, even though it applies to other modes too. Adjust the logic for the new compositing modes. Add a GimpLayerModeAffectMask enum, and a corresponding get_affect_mask() function to GimpOperationLayerMode, which specifies which of the op's inputs, if any, are affected by the mode, apart from the overlapping regions. Most modes affect only the overlapping regions, but dissolve and replace also affect the rest of the input. This information is used for determining if the optimizations are applicable.
2017-02-02 07:53:09 -08:00
}
Reference in a new issue Copy permalink