The halftones transfer mode of dodge/burn uses pow(), which produces
NaN for negative input values. This tool doesn't really have OOG
values in mind, but using an odd power function fixes this issue,
and is in line with the behavior of the other modes w.r.t. OOG
values.
Spotted by José Americo Gobbo: when using a pattern source
for the clone tool, the top left corner was picked
as starting control point, which made the "fixed" aligment
rather useless. Using the pattern center allows the
better control of a pattern source.
Add a "mask-only" property to GimpBrushClipboard. When TRUE, only
create a brush mask (not a pixmap brush with mask and image).
Keep two clipboard brushes around: one classic "Clipboard Image" one
to be used as "stamp", and one new "Clipboard Mask" one that turns the
clipboard into a brush mask.
Fix the edit-paste and edit-paste-as-new-image PDB wrappers to use
gimp_get_clipboard_object(), not just clipboard_buffer(), and deal
correctly with entire images in the clipboard.
The GNOME sdk runtime used to be built which flags not appreciated by
older CPUs. This has now been fixed. Let's get rid of our workaround.
See https://github.com/flatpak/flatpak/issues/143
Integer overflows allow out of boundary writes while reading GIH files.
The checks are copied from file-gbr.c. In turn, the necessary gsize
casts are added in file-gbr.c, too. These are important on 64 bit
systems. Without these casts, the precision of the calculation is still
32 bit, allowing overflows.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
SVG icons won't be properly displayed with an older GTK+. See:
https://bugzilla.gnome.org/show_bug.cgi?id=781020
Note: 2.24.32 is not out yet, but it will be the first stable release
with the right fix.
If a PCX file contains a bytesperline entry which is too small, it is
possible to trigger an out of boundary read, which can lead to a
segmentation fault.
The bytesperline validation is incomplete. While checking if enough
bytes per line exist, the integer truncation during the division must be
taken into account.
An example would be a 1x1 PCX file with a bpp of 1 (monochrome). The
current check allows a bytesperline field of 0, which in turn would lead
to a 0 byte allocation in load_1. Yet, the code would access index 0.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
If either width or height is 0, gimp won't process the PCX file.
Instead, a bunch of error messages are printed.
It's nicer to quit parsing the file early on with a good error message
which is straight to the point instead.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Fix brush shrinking used to compensate for the blur: avoid over-
shrinking the brush and changing its aspect ratio.
Change the way hardness maps to blur radius: hardness == 0 maps to
the largest radius such that, when the kernel is applied to the
middle pixel of the brush, the kernel is completely within the brush
bounds, taking brush shrinking into account, *assuming the brush is
a circle*.
Use the dimensions of the unrotated brush when calculating the blur
radius, so that rotation doesn't affect the blur amount (the blur
itself is not isotropic, though, and is applied after rotation, so
while the blur amount remains uniform, its effect does depend on the
brush angle.)
Get rid of the blur-radius upper limit -- it's fast enough to handle
large radii now.
A few additional minor speedups.
Also, make sure we don't overflow for large blur radii. Not a
problem yet, since the blur radius is capped, but soon...
Add a specialized convolution algorithm for the hardness blur. It
uses the same kernel as before, but performs the convolution in
(amortized) O(1)-per-pixel time, instead of O(n^2), where n is the
size of the kernel (or the blur radius).
Note that the new code performs the convolution in the input color
space, instead of always using a linear space. Since our brush
pixmaps (but the not masks) are currently perceptual, the result is
a bit different.
Add a debug procedure group, living in 'debug.pdb', which would host
useful debug helper functions. Functions in this group are not part
of the stable API, and may be changed at any point.
All procedures added to 'debug.pdb' should have a 'debug_' prefix,
and use the new std_pdb_debug() macro, which adds the proper "here be
dragons" warning to their description.
Add two debug procedures: gimp-debug-timer-start() and
gimp-debug-timer-end(), which measure elapsed time, a la
GIMP_TIMER_{START,END}, and can be used to profile script-fu
commands.
If the transformed item is a layer, and we are transforming the entire
layer (if there is now selection), hide the original layer during the
interactive transform. Based on a 2.8 patch from saulgoode.
Commit 9d4084c82f skips conversion and
blending of (some) transparent source and destination pixels. When
`blend_out == blend_layer`, it banks on the fact that the alpha values
of `blend_out` would be the same as those of `blend_layer`, and hence
the same as those of `layer`; thing is, we only copy those values from
`layer` to `blend_layer` for the pixels that we *don't* skip, so this
assumption is just wrong :P This leaves us with bogus alpha values in
`blend_out` for the skipped pixels, when the above equality holds.
For composite modes that use the alpha values of `blend_op` (aka `comp`)
even for transparent input pixels (i.e., src-atop and src-in), this may
result in artifacts.
Fix this by simply initializing the alpha values of `blend_out` for
skipped pixels unconditionally.
The expression `src_offset_x - coords->x + origin->x` is parsed as
`(src_offset_x - coords->x) + origin->x`; since floating point
arithmetic is not generally associative, even when
`coords->x == origin->x` (in particular, when there is no active
symmetry), it may still yield a different result than plain
`src_offset_x` if there's not enough precision for the intermediary
result (which is usually the case when `{origin,coords}->x` is
noninteger.) Since `src_offset_x` is an integer, and since the result
of this expression is rounded to an integer, if the error happens to
be in the direction of the rounding, it's magnified to a whole pixel,
which causes visible "jitter". (Ditto for `src_offset_y` and co.)
Regardless of this issue, we want to individually round `origin->[xy]`
and `coord->[xy]` down before taking their difference, since the
original offset is calculated according to rounded-down coordinates.
This solves the original issue along the way.
We don't support subpixel source sampling, so there's no use in
pretending that we do. Demoting everything to int as soon as
possible helps guarantee that these values are at least rounded
properly and in fewer places.
Make sure we always round coordinates down, and not toward zero.
Keep using floats only in the signatures of the relevant PDB
functions.
Copy TransInfo arrays around using memcpy(), use memcmp() to
compare them, add a function to allocate one. Clean up some
logic in gimp_transform_tool_check_active_item().
