We actually don't need to compute distance map. I just make the simplest
priority map, with 1 any line art pixel and 0 any other pixel (in mask
or not), lowest priority being propagated first.
And let the flooding begin!
... labels buffer.
We can watershed directly the mask buffer being correctly flagged.
This commit relies on merge request gegl!8 being accepted and merged.
Also use more GeglBufferIterator on input GEGL buffer.
Using a char array is much less expensive and accelerated the line
erosion a lot!
Moving to GeglBufferIterator is not finished, but I do in steps.
When filling colors in line arts, you don't want to leave space between
the strokes and the color, which usually happen with any of the current
selection methods.
A "KISS" trick is usually to grow your selection a few pixels before
filling (adding an additional step in colorization process), which
obviously does not handle all cases (depending on drawing style and
stroke size, you may need to grow more or less) as it doesn't take into
account actual stroke geometry.
Instead, I label the selection and the "rest" differently and leave the
pixel strokes unlabelled. Then I let these unlabelled pixels be flooded
by the "gegl:watershed-transform" operation.
Note that this second step is different from the second step from the
GREYC research paper, as they use their own watershed algorithm taking
color spots as sources to color the whole image at once. This is a
different workflow from the one using bucket fill with a single color
source.
This commit implements part of the research paper "A Fast and Efficient
Semi-guided Algorithm for Flat Coloring Line-arts" from the GREYC (the
people from G'Mic). It is meant to select regions from drawn sketchs in
a "smart" way, in particular it tries to close non-perfectly closed
regions, which is a common headache for digital painters and colorists.
The implementation is not finished as it needs some watersheding as well
so that the selected area does not leave "holes" near stroke borders.
The research paper proposes a new watersheding algorithm, but I may not
have to implement it, as it is more focused on automatic colorization
with prepared spots (instead of bucket fill-type interaction).
This will be used in particular with the fuzzy select and bucket fill
tools.
Note that this first version is a bit slow once we get to big images,
but I hope to be able to optimize this.
Also no options from the algorithm are made available in the GUI yet.
In gimp_drawable_transform_buffer_affine(), avoid modifying the
clipping mode when transforming layer masks, since this function is
used (among other things) to transform layer masks together with
their layer, in which case they should use the same clipping mode
as the layer.
This fixes a regression introduced by commit
2ae823ba2b, causing layer masks to be
transformed with a mismatched clipping mode during layer
transforms, leading to discrepencies between the transformed layer
and the transformed mask.
This commit merely reverts the necessary part of above commit,
fixing the regression, though note that this code is really up for
some serious refactoring: the logic for determining which clipping
mode to use when is spread all over the place.
Blacklist the "threaded-ml" thread, which seems to mask the
backtrace signal.
Improve signal-handler synchronozation, to avoid segfaulting when
giving up on waiting for all threads to handle the signal.
Furthermore, when one or more threads fail to handle the signal in
time, return a GimpBacktrace instance with backtraces for all the
other threads, and with empty backtraces for all the non-responding
threads, instead of returning NULL and leaking the allocated
instance. Don't blacklist threads that failed to handle the signal
in time, and instead shorten the wait period for handling the
signal, and yield execution during waiting to lower the CPU usage.
Connect GimpImage's gimp:mask-components node to the layers node
*before* connecting the channels node, so that the image's
component mask doesn't affect the channel colors, as is the case in
2.8.
... the second time you do a 180 degrees rotation
In gimp_transform_resize_adjust(), nudge the transformed layer
boundary by EPSILON toward the center, to avoid enlarging the layer
unnecessarily, as a result of numeric error amplified by rounding,
when the tranformed boundary should land on integer coordinates.
In particular, this avoids enlarging the layer when rotating by 180
degrees.
...via hover tooltips
Use the GtkWidget::query_tooltip() signal on GimpFgBgEditor to emit an
own signal "tooltip" that has the hovered widget area as parameter.
Connect to GimpFgBgEditor::tooltip() in gimptoolbox-color-area.c and
set separate tooltips on the widget's areas, including the shortcuts
for "Swap colors" and "Default colors".
Add xyY color space to the color spaces for sampling colors.
Also add code to xcf-load.c that makes sure the sample point loading
code handles unknown future GimpColorPickMode values (fall back to
PIXEL pick mode).
Add pattern offset parameters to gimp_fill_options_create_buffer() and
pass the selection's top-left corner so that pattern fills on the same
drawable are aligned.
In the GimpBacktrace Linux backend, always use libunwind, when
available, to find symbol names, even if dladdr() or libbacktrace
had already found one. libunwind provides more descriptive names
in certain cases, and, in particular, full symbol names for C++
lambdas.
Note that, in some cases, this can result in a discrepancy between
the reported symbol name, and the corresponding source location.
In the GimpBacktrace Windows backend, avoid reporting meaningless
symbol addresses when failing to retrieve meaningful ones.
Unfortunately, it seems that we never get symbol addresses for
symbols that have debug information, which negatively affects the
log viewer's call graph. We're going to have to work around this.
When initializing the GimpBacktrace Windows backend, set the name
of the current thread (which is assumed to be the main thread) to
the program's name, to match its name on Linux. We normally rely
on the SET_THREAD_NAME exception to set thread names on Windows,
which isn't raised for the main thread.
In the gimp_parallel_run_async() family of functions, allow the
async callback to return without completing the async operation, in
which case the callback will be called again, until the operation
is either completed, or canceled, in which case it is aborted
(previously, returning from the callback without completing the
operation would cause it to be aborted.) It is guaranteed that all
operations of the same priority will get a chance to run, even if
some of them contuinuosly return without completing.
This allows potentially time-consuming operations to yield
execution in favor of other same-priority operations, and, in
particular, of higher-priority operations, to avoid priority
inversion. Essentially, this allows a simple form of cooperative
multitasking among async operations.
It was not doing anything right since space invasion. We now treat the
built-in sRGB profile like any other profile and never bypass
conversions based on some weird toggle.
Instead, introduce a "Use sRGB Profile" toggle which, when enabled,
hides whatever profile away so the image actually uses the built-in
sRGB profile.
This is different from discarding and then re-assigning the same
profile only by being faster and more convenient.
Use a single segment with a "step" blending function, added in the
previous commit, instead of two separate segments, for the "FG to
BG (Hardedge)" internal gradient. This makes it simpler to change
its endpoint colors by modifying the gradient, instead of changing
the FG/BG colors.
... to make multi-color hard-edge gradient fills possible
Add a new "step" gradient-segment blending function, which is 0
before the midpoint, and 1 at, and after, the midpoint. This
creates a hard-edge transition between the two adjacent color stops
at the midpoint. Creating such a transition was already possible,
but required duplicating the same color at the opposing ends of two
adjacent stops, which is cumbersome.
When shutting-down gimp-parallel, cancel and/or abort any ongoing
and queued async operations, instead of finishing them (async
operations that already started executing will be canceled, but
execution will be blocked until they're finished.) This is
especially important since we're shutting down gimp-parallel before
the destruction of data factories. This commit causes any ongoing
async operations of the factories to be canceled on shutdown,
rather than waiting for them to finish normally.
Add a new GimpData::data_cancel() virtual function, and a
corresponding gimp_data_factory_data_cancel() function. This
function should cancel any ongoing async operations related to the
factory (i.e., included in its async set), and wait for the
operations to finish. Provide a default implementation that simply
cancels and waits on the factory's async set.
Use this function to cancel any ongoing operations during factory
destruction, and in gimp_data_factory_data_free().
Override this function in GimpFontFactory, for which we can't
really cancel font loading, and simply cancel and clear the
factory's async set without waiting for loading to finish, making
sure that nothing happens (and, in particular, that the factory
isn't being accessed, since it might be already dead) when loading
does finish.
In gimp_data_factory_data_foreach(), don't rely on internal
GimpData objects being sorted first (while this is currently true
for all types of GimpData, they may override the sort order.)
In gimp_drawable_real_{apply,replace}_buffer(), bail if the
applcation region, after intersection with the drawable and mask
extents, is empty. This avoids trying to create a GeglBuffer with
negative width/height.
... (some sort of corruption)
In gimp_drawable_real_replace_buffer(), adjust the processed buffer
and mask_buffer regions according to the changes made to the
application region, as calculated by intersecting it with the
drawable and mask extents. This fixes wrong application position
when painting using the heal, dodge/burn, smudge, or convolve
tools, on a drawable whose origin is above/to the left of the
image's origin, and there's a selection active.
... the XCF file
Add a "saving" signal to GimpImage, which is emitted when the image
is about to be saved or exported (but before it's actually saved/
exported). Connect to this signal in tool-manager, and commit the
current tool in response (unless its GimpToolControl::preserve is
TRUE).
... and G_TYPE_INSTANCE_GET_PRIVATE()
g_type_class_add_private() and G_TYPE_INSTANCE_GET_PRIVATE() were
deprecated in GLib 2.58. Instead, use
G_DEFINE_[ABSTRACT_]TYPE_WITH_PRIVATE(), and
G_ADD_PRIVATE[_DYNAMIC](), and the implictly-defined
foo_get_instance_private() functions, all of which are available in
the GLib versions we depend on.
This commit only covers types registered using one of the
G_DEFINE_FOO() macros (i.e., most types), but not types with a
custom registration function, of which we still have a few -- GLib
currently only provides a (non-deprecated) public API for adding a
private struct using the G_DEFINE_FOO() macros.
Note that this commit was 99% auto-generated (because I'm not
*that* crazy :), so if there are any style mismatches... we'll have
to live with them for now.
Even though chosen as a parameter to gimp_image_get_xcf_version() and
not a feature within the image itself, we also want to list this reason
in the compatibility list.
Improve out-of-range check in gimp_backtrace_find_thread_by_id().
Remove unnecessary #include <exchndl.h> in gimpbacktrace-windows.c,
and revert commit 644234e99d (the
DrMingw detection happens at runtime). The Windows backend can
work without DrMingw, it just can't find all the symbols, and
doesn't provide source-location information.
The "running" attribute (readable through
gimp_backtrace_is_thread_running(), and recorded in the performance
log) specifies if the thread was in a running or suspended state at
the time the backtrace was taken. It is accurate on Linux, but
only approximated on Windows.
Adapt the performance-log-expand.py tool to maintain this attribute
(and any future thread attributes we might add).
