No need to do full back and forth RGB/HSV conversions.
Change the behavior such that fully desaturated values remain
desaturated, instead of saturating towards red.
Pixels whose source or destination alpha is zero are not blended, and
therefore do not need to be converted between the composite and blend
spaces (assuming a conversion is necessary to begin with.) When there
is a large enough segment of consecutive pixels that don't need
blending, split the conversion/blending process around it, so that
we don't convert too many unblended pixels unnecessarily.
For layers with lots of transparency, this can dramatically reduce
compositing time; for layers with no transparency, the added
overhead is rather negligible.
Merge mode lays the source layer on top of the destination, same as
normal mode, however, it assumes the source and destination are two
parts of an original whole, and are therefore mutually exclusive.
This is useful for blending cut & pasted content without artifacts,
or for replacing erased content in general.
Calculates the dot product of the two input colors, and uses that
as the value for all the output color's components. Basically,
a per-pixel mono mixer.
Useful for custom desaturation, component extraction, and crazier
stuff (bump mapping!)
Include erase mode in the menu for layers and general paint tools.
This makes the eraser tool somewhat unnecessary, but allows for
interesting use cases (e.g., airbrush eraser, etc.)
... possibly due to small win32 stack
Limit the number of samples processed in one go by gimp_composite_blend()
so that we don't overflow the stack when we alloca() buffers on it.
... and get rid of the dedicated op. This gives us support for all
the blend/composite options for this mode.
Rename COLOR_ERASE to COLOR_ERASE_LEGACY, with perceptual blending/
compositing and immutable everything, and add a new COLOR_ERASE
mode, defaulting to linear blending/compositing, with mutable
everything. Modify affected code.
These are more general, and more expensive, versions of the non-
subtractive compositing functions. They are used with modes that
specify the SUBTRACTIVE flag. This doesn't affect anything yet, but
the next commit ports color-erase mode to a blendfun.
Most modes only modify the *color* of overlapping dest/src regions,
however, erase and color-erase may also reduce their *alpha*, i.e.,
eliminate some of the overlapping content. Flag these modes with
the new SUBTRACTIVE flag, as they require more general compositing
code. The next commit adds the said code.
The mode group switching combo box is hard to discover, until we use the
default group instead of legacy group as default - it is better to make legacy
resemble the full old set to.
Need to provide the pixels in a format that matches the profile,
simply using "RGBA float" here was a brain bug of mine. Two profiles
and two formats are parameters the used GimpProfileTransform needs to
work correctly.
which returns an array of modes in the order they would appear in a
GimpLayerModeContext's UI (like tool options or the layers dialog),
without the separators.
Use it in context-commands.c and layers-commands.c instead of static
(and outdated) arrays for the actions that cycle through modes.
Instead, add a gimp_layer_mode_get_format() function, which takes
the layer mode, composite space, and blend space, and returns the
I/O format.
Currently, we always use the composite space format as the I/O
format. This simplifies gimp_composite_blend(), and gives us
composite-space support for the "special" layer mode ops for free.
Replace the 'with-behind' and 'with-replace' properties with a
single 'context' property, and use it to select the included
layer modes, according to their context mask.
Add a dummy GIMP_LAYER_MODE_SEPARATOR value to the GimpLayerMode
enum, and use it to explicitly mark the menu separators in the
layer-mode group arrays; add separators to the layer-mode menu
accordingly.
Update the rest of the code to use 'context' instead of 'with-behind'
and 'with-replace'. In particular, in the layers and layer options
dialogs, select the right context based on whether or not the
selected layer is a group.
A bitmask, specifying in which contexts a layer mode is applicable.
Can be a combination of:
- LAYER: usable as a layer mode for actual layers.
- GROUP: usable as a layer mode for layer groups. Currently, all
modes that specify LAYER also specify GROUP, and vice versa,
but the planned pass-through mode will be GROUP only.
- PAINT: can be used as a paint mode.
- FADE: can be used for fading.
Add a 'context' field to _GimpLayerModeInfo, and provide context
masks to all the modes.
Use the context mask for validation when setting a layer's mode.
The next commit will use the mask when populating the layer mode
menus.
Add a "paint_composite_mode" field to GimpLayerModeInfo and set the
mode of the eraser to SRC_ATOP. Defaulting to SRC_OVER for all
painting didn't quite do it for all modes.
set all legacy modes to completely immutable and the LAB modes'
blend mode to immutable. Change GimpLayer setters and the UI
accordingly. Remove the LAB color spaces from the GUI, they can
only be used with the LAB blend modes anyway and not changed.
They can be affected by the same problem described in
commit 4c3a772cd8, although in the
case of SRC_ATOP, the affected pixels are always fully transparent.
When the source alpha is zero, we don't calculate the blended color,
so `comp[b]` can be infinite or NaN, in which case the expression
`in[ALPHA] * (comp[b] - layer[b])` is NaN, rather than the expected
value of zero.
and to operations/layer-modes/, respectively.
Add gimp_layer_modes_init() which asserts on the correct order of the
GimpLayerModeInfo array, and switch to accessing the array directly in
gimp_layer_mode_info().
Similar to the Photoshop mode of the same name. Assigns
either 0 or 1 to each of the channels, depending on whether the
sum of source and destination channel values is less than, or
greater than (or equals to), one, respectively.
This is equivalent to inverting the source, and using it to perform
per-pixel, per-channel threshold against the destination, which is
useful for various effects.
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.
Some of the generic files still contain SSE2 code, in particular
gimpoperationlayermode.c. The reason why it often works without is that
native gcc will usually pre-define SSE macros by default.
To check this: gcc -dM -E - < /dev/null | grep SSE
Yet I had a case on a small netbook where the SSE macros were not
pre-defined even though supported. Consequently the build failed.
Largely based on a patch by Ell, with the enum type renamed and
various small changes. Adds another axis of configurability to the
existing layer mode madness, and is WIP too.
These variations on darken only and lighten only have the advantage over the
componentvise versions that they always use the full triplet of either original
or new layer - meaning no new colors/hues will be introduced. This is similar
to how these modes operated/operates in picture publisher and photo-paint.
The porting from 8bit per component scaled some 8bit fractions up to huge
floating point numbers, this works for most values but causes trouble for near
transparent pixel values. This commit copies the inner blend loop from the new
divide layer mode, but keeps the old compositing logic.
... is fully transparent, instead of just src.
The blend func results only affect the intersection of dest and src.
Run time is currently dominated by the compositing step for most modes,
so the difference in performance is pretty negligible, but it does make
a difference for the more expensive modes, like the HSV ones.
For operations needing to override default behavior sub-classes should still be
used.
This commit also enables pinligh, vividlight and linearlight blend mode modes
Since CIE Lab is one of the supported color spaces for doing the blending -
this enum is not only about transfer functions/curves or gamma. This finishes
already started cleanups.
It is used both for blending and compositing, the repeated use of the word
BLEND in code made the logic involving both blending and compositing hard to
read.
Note that in some cases the alloca may be unnecessary, but this keeps
the code clean, and we have to be able to *potentially* do the alloca
anyway, so what the hell.
Implement a common utility function gimp_blend_composite that uses utility
functions for implementing layer modes, with separate (possibly SIMD) optimized
loops for blending and compositing, with configured linear TRC, perceptual
gamma TRC or even using CIE Lab as the space.
like all other function typedefs and add GimpBlendFunc typedef which
will be needed soon. Also rename get_layer_mode_function() to
gimp_get_layer_mode_function().
with proper value names. Mark most values as _BROKEN because they use
weird alpha compositing that has to die. Move GimpLayerModeEffects to
libgimpbase, deprecate it, and set it as compat enum for GimpLayerMode.
Add the GimpLayerModeEffects values as compat constants to script-fu
and pygimp.
Make overlay, Lch color, Lch hue, Lch saturation and Lch lightness mode handle
alpha more like how normal does it. This is a change that we ideally might want
applied to other layer modes as well to get rid of MIN() calls.
When calculating an overlap between two ranges, interpolate the hue
adjustment from config->hue[primary_range] and
config->hue[secondary_range] BEFORE mapping it to the input value.
This fixes odd edge cases where only one of the ranges crosses the
red/magenta wraparound, or if adjustments to different channels yield
more than 180 degree difference from each other.
so the threshold can now be based on the GimpHistogramChannel enum.
Add a channel menu to the threshold dialog and a channel argument to
the PDB procedure (which is new in 2.10).
If I hadn't forgotten what the "RGB" channel is supposed to do I would
have implemented the RGB mode in GimpOperationThreshold correctly.
Right now I'm just guessing. Anyone?
This operation produces NAN (0 / 0) and division
by zero when a layer component is zero.
Inline CLAMP to make sure it swallows also NAN.
A NAN is mapped to 1 for backward compatibility.
[the 2variate function comp (in[b], layer[b]) is
discontinuous at layer[b] = 0]
Use cmsFLAGS_NOOPTIMIZE only for actual image buffer or single color
transforms, but not for previews or the image display. Makes things a
lot more responsive again.
Rather than just discovering them by chance, a simple grep and some
search and replace are much more efficient! :-)
Cleaning only done on C and automake files.
which encapsulates a cmsHTRANSFORM and does all the pixel format
conversion magic. It has API to create transforms and proofing
transforms, and to convert pixels arrays and GeglBuffers.
Before, each place which has a transform had to keep around the
transform and its input and output Babl formats, and had to implement
lots of stuff itself. Now all that lives in GimpColorTransform,
removing lots of logic from many places, and pretty much removing lcms
from the public API entirely.
This removes including <lcms2.h>, LCMS_LIBS and LCMS_CFLAGS from
almost all directories and potentially allows to replace lcms by
something else.
... layers with alpha channel
add an operation that selectively outputs aux
or source if out/inside the rectangle (x,y,width,height),
independently of the alpha channel and use it
in filters split preview.
mostly copied from gimp:mask-components
We must not dither the alpha channel if it is fully opaque or fully
transparent. 2.8 did the same but the dithering of these values was
apparently consumed be putting the result into 8 bit values.
Add more user friendly description to the PDB op.
Partially keep the technical description for the PDB op and add a
reference to the developer wiki.
Use the new "reference" key for the GEGL op.
Gamma correction refers to correcting how an image is displayed on
various devices. Gamma adjustment is a more general phrase that also
applies to adjusting gamma as a step in image enhancement in a
color-managed workflow.
and remove lots of labels from calls to gimp_prop_foo_new(). Also
had to manually remove some unwanted labels that are now added
automatically, fixes bug #761880.
Use a proper "progress" signal instead of a property "notify" one
to update the on-canvas progress widget.
This way the graph is not invalidated while processing it
This operation assigns to each pixel the minimum of the
maxima of all paths from it to the outside, as if the
input image represents a height map, and the operation
floods it with water.
which registers config classes for operations that don't want their
config objects to be auto-generated. Register all color tools' config
objects. Change gimp_gegl_config_sync_node() to correctly handle ops
that have an object property of the right config object type.
Add GIMP_DESATURATE_LUMINANCE to enum GimpDesaturateMode and rename
GIMP_DESATURATE_LUMINOSITY to GIMP_DESATURATE_LUMA.
Keep GIMP_DESATURATE_LUMINOSITY as deprecated compat value and add it
to the script-fo and pygimp compat constants.
Change GimpOperationDesaturate to process GIMP_DESATURATE_LUMINANCE
with linear "RGBA float".
GIMP's OVERLAY mode was identical to SOFTLIGHT. This commit fixes the
issue and introduces a NEW_OVERLAY mode and enum value.
- change gimp:overlay-mode to be a real (svg-ish) overlay mode
- when compositing, map OVERLAY to gimp:softlight-mode
- when compisiting, map NEW_OVERLAY to gimp:overlay-mode
- bump the XCF version when NEW_OVERLAY is used
- map OVERLAY to SOFTLIGHT when loading and saving XCF
- map OVERLAY to softlight in all PDB setters
- map OVERLAY to softlight when deserializing a GimpContext
- change all paint mode menus to show an entry for NEW_OVERLAY
instead of OVERLAY
- change PSP, PSD and OpenRaster to use NEW_OVERLAY
These changes should (redundantly) make sure that no OVERLAY enum
value is used in the core any longer because it gets mapped to
SOFTLIGHT at all entry points, with the downside of introducing a
setter/getter asymmetry when OVERLAY was set in a PDB api.
Implement GimpConfigInterface::equal() for the brightness-contrast,
colorize, and threshold config objects, to prevent the parent class'
timestamp being compared by the generic default implementation.
...and layer opacity
Use a temporary variable to store intermediate result instead of
writting 2 times to the output buffer, because input and output
buffer might be the same.
GimpOperationPosterize: also posterize the alpha channel. Seems like a
no-brainer to me, and is actually useful (see bug). The old behavior
is still available by simply disabling the alpha channel in the
channels dialog.
