This argument should actually say "Do not store premultiplied channel
values", which is what the TIFF spec calls "Unassociated alpha" (vs.
"associated alpha" when values are stored premultiplied by alpha).
Now I can see where the current description is coming from, which is
that any color with alpha 0 (totally masked) ends up as RGBA value (0,
0, 0, 0), in other words, the color information is completely lost. Yet
this label is not very helpful to understand what the checkbox really
does. I decided to not just change it altogether as people would have
gotten used to this for years, but at least adding completary
information in API and tooltip in GUI.
When the "wrap" property of a GimpSpinButton is TRUE, wrap-around
out-of-range values entered through the spin-button's text entry,
instead of clamping them. Since we're using GimpSpinButton
everywhere since last commit, this applies to all our angle-entry
spin buttons (including spin scales).
(cherry picked from commit 8b3c7ae193)
Not sure what this @image_types parameter of gimp_install_procedure() is
used for. Exporting was working find with INDEXEDA image even when not
advertized by this function. Let's update this anyway.
In the unified-transform, scale, and perspective tools, take the
maximal transform-grid handle size into account when readjusting
the transform, so that the handles themselves are fully within view
under arbitrary rotation, rather than just the corners.
(cherry picked from commit 46e16e175c)
s/THREAD_MODE_ABOVE_NORMAL/THREAD_PRIORITY_ABOVE_NORMAL/
Thanks to Sylvie Alexandre for noticing and searching this.
(cherry picked from commit ebc3ef3c5e)
Do not take "Sample merge" into account when picking colors in a
single-layer image. The reason is to be able to get the index
information on indexed image. This information is lost otherwise when
using the whole image as a pickable.
Of course, other exceptions are possible, when you'd pick exactly a
colormap color, but I don't think it's worth making the code
extra-complicated for these. My previous commit will anyway already
select the right color in the colormap on common cases. Though it will
still fail to select the right index when several indexes store the same
color, on a multi-layer image, if you check "Sample merged" while the
right index was not the first one amongst the duplicates.
(cherry picked from commit 31b2b55b28)
The colormap saves colors as unsigned char, which can be very inaccurate
compared to high precision colors. When adding colors from GimpRGB into
the colormap, use the original value to fill the colormap palette
instead of making a round trip conversion from double to uchar, then
back to double.
This also fixes a direct bug I encountered when adding the current
foreground color in the image colormap. Yet the GimpFgBgEditor or the
GimpColorHistory would still show the color out-of-gamut in cases when
the returned RGB after the roundtrip was not close enough to the
original RGB (even despite using an epsilon in GimpPalette code).
(cherry picked from commit f1cca8ee2e)
In GimpTransformGridTool, reset both transform directions in
response to the "Reset" button, so that the overall transformation
is restored to the identity. Previously, we would only reset the
active transform direction (possibly compensating in the opposite
direction, if both directions are linked). This was intentional,
but it's probably a bit too confusing, especially in conjunction
with the newly added "Readjust" button. Let's just go back to
resetting everything.
(cherry picked from commit 2c67b29190)
Implement GimpTransformGridTool::radjust(), added in the previous
commit, in various transform tools:
The unified-transform, scale, and perspective tools readjust the
transformation such that the grid is centered relative to the view,
and its handles are fully within view under arbitrary rotation.
The rotate tool readjusts the transformation such that the pivot is
centered, and the grid is unrotated, relative to the view.
(cherry picked from commit 5e5118c1db)
Add an optional GimpTransformGridTool::radjust() virtual function,
which subclasses can implement to radjust the transformation based
on the current state of the display, such that it's easy to
control. This is especially useful when the image is zoomed-in,
and the transform handles, which are initially across the layer
bounds, are out of view.
When a transform tool implements radjust(), show a "Readjust"
button in the tool GUI. While readjusting the transformation, we
modify the opposite transformation such that the overall transform
remains unchanged, as if both transform-directions were linked, so
that only the transform grid is readjusted.
(cherry picked from commit 5055dd10d5)
In GimpToolGui, add gimp_tool_gui_add_button() and
gimp_tool_gui_add_buttons_valist(), which allow adding dialog
buttons after construction.
(cherry picked from commit b23fae86f0)
Line-art computation can take a long time, and it's therefore
desirable for it to be interruptable. While we do cancel the line-
art async when its result is no longer needed, most parts of the
computation don't respond to the cancelation request, leaving the
async operation running in the background, blocking subsequent
async operations.
Implement cancelation support of line-art computation, by passing
down the async object to the various functions, and periodically
checking for its cancelation at various points. When the async is
canceled, we quickly abort the operation.
Even though cancelation now happens relatively quickly, some parts
of the computation are still uninterruptable and may incur some
latency, so we avoid waiting for the async opration to be aborted
after cancelation, as we did before.
(cherry picked from commit d8e69d66bc)
... so that performance logs can be recorded during long-running
async operations, without those operations blocking the
finalization of the log.
(cherry picked from commit 652a2a90cf)
... which is equivalent to gimp_parallel_run_async_independent(),
except that it takes an additional "priority" parameter, which
specifies the task's priority, with 0 being the default priority,
and lower values indicating higher priority. Unlike
gimp_parallel_run_async_full(), the priority parameter doesn't
directly control the task's priority in a queue, but rather, we use
it to control the priority of the task's dedicated thread, on
supported platforms (previously, all independent async tasks would
run with low priority.)
Use low priority when loading fonts, which can take a long time, to
keep the existing behavior.
(cherry picked from commit fa2e4dcce0)
