Previously, paths from Photoshop TIFF files were appended via
gimp_image_insert_path(..., -1), which caused the displayed order to be
reversed. This change preserves the original ordering while keeping the
'Working Path' as the last element.
Resolves#12791 (again)
After cleaning up and separating the filter pop-up code
from GimpItemTreeView to GimpDrawableTreeView-Filters,
we accidentally lost the checks that prevent deleting filters
that have not yet been applied (thus causing a crash).
This patch restores the checks for the filter to not be temporary
before you can delete it.
Resolves#16018
This patch extends a2c5d70c to also apply to the
"Fit Canvas to Layers" action. It prevents the non-rasterized
vector layer from being shifted out of place when the
canvas is resized.
Resolves#16045
This patch extends a2c5d70c to also apply to the Crop Tool.
It prevents the non-rasterized vector layer from being shifted
out of place when cropped.
Closes: #16038
This may be related to how our babl relocatable heuristics works
on Linux: depending on the process path, which is tricky on Snap,
specially for 3P plug-ins which have their own sandboxed processes.
Ideally, we should fix it on babl but this workaround if good enough.
(Modified by CmykStudent from balooii's original merge request)
When performing image-level operations (resize, crop, scale, flip,
rotate, arbitrary transform), paths referenced by non-rasterized vector
layers were being transformed twice:
1. Via the vector layer's overrides, which explicitly transforms
the referenced path to keep it in sync
2. Via the image-level queue that processes all paths independently
This patch adds a check for whether the layer has been rasterized.
If so, we bypass the vector layer's transform so the path is not
transformed a second time.
While we want to try with the last tagged release (babl 0.1.124), we
still need the CI to work with the latest code. So let's add one more
temporary fix.
...in Histogram Editor.
The 2.10 Colorcube Analysis plug-in took into
account the selection when displaying the colors.
The Histogram Editor itself does as well, but our
unique color count did not.
This patch adds a check in gimp_histogram_unique_colors ()
to see if there's an active selection in the image.
If so, we get its area and use that as the bounds in
gegl_buffer_iterator_new () instead of setting it to NULL.
When loading layer metadata from TIFF 'ImageSourceData' Tag, don't assume
'Layr' is the first 8BIM block. Iterate over 8BIM/MIB8 blocks, skip non
'Layr' blocks, and rewind 4 bytes before calling read_layer_block() so it
can read the length field as expected. Limit mask_layer_len to the
selected block (including padding).
… rename for babl.
As we are doing test build for the release, we are in this in-between
situation where GEGL has the newly named option, but not babl (because
we don't have a new babl release).
I don't know if we'll have a babl release by the time we'll get GIMP
3.2.2 out, but for now, let's use the old option name.
This commit will have to be reverted later, after we release.
Multichannel PSD images reuse their first channel as the
main grayscale "layer". Our PSD plug-in did not take this
into account, resulting in the channels being off-by-one and
mislabeled.
This patch prevents chn_a[0].data from being freed after
it is used to load the layer, and then resets the counts so that
it is reused as the first imported channel.
In fact, the previous commit was unneeded and we could have done without
reverting the old commit. On the other hand, a buffer using another
buffer as "source" may be nicer in memory.
But the previous commit alone was not right as group boundaries were
wrong. In fact, right now, we can see that group boundaries are computed
using only the children layers (except for pass-through of course), not
including any effects they might have. And the buffer passed to
gimp_drawable_set_buffer_full() was the projection's buffer itself — it
was shared, which was also why copying at setting time was wrong —, in
the case of a group layer. That means that when we translated to (0, 0)
offset, either we would have moved the render to the wrong place, or
moved the boundaries to the wrong place.
The offset needs to stay what it is, even when it's not (0, 0), for
group layers.
Another alternative fix would be instead to fix layer groups' boundaries
to encompass the full projection's render. But I just went with this
special-casing of group layers instead.
Part of it reverts commit 3a53e4743e.
Another part is a fix to the CRITICAL mentioned in this commit.
This being said, it's clearly not entirely right yet. The boundaries of
the layer when the filter is merged are not correct, which is especially
visible when trying to draw on this layer afterwards.
Also the layer group boundaries (when reproducing the steps in #16010)
are clearly wrong too.
A crash could happen when a duplicate nick was found due to incorrectly
freeing the content of 'choice->keys' which holds the nicks and not
GimpChoiceDesc. Instead, the nick needs to be simply freed.
As said on cbe2f6be, Inno does not support modifying installations at
all, not even canceling/undoing modifications like reinstall and update.
This limitation become more apparent after the fix 24e42dd1 so
let's prevent the users being damaged by such major Inno pitfall.
968cf06a only loaded the rectangle area that the
selection was contained in, rather than the actual
channel data. This patch extended the code to
also read in the PSP_CHANNEL_BLOCK data, add
it to the selection GeglBuffer, and then shift it over
into the correct location.
