This is the same thing as setting the max gap length to 0, except that
it would mean constantly having to play with the gap length and possibly
losing settings you carefully tweaked. Instead with this additional
settings, we hide the gap length settings when automatic closure is
disabled.

Also it makes kind of a nice parallel with the "Manual closure" settings
which can also be enabled/disabled similarly.

Thanks to Massimo Valentini for finding these.
Fixes:

> GLib-GObject-CRITICAL **: 13:21:53.256: Object 0x5485140 of type GimpLineArt not finalized correctly.
> GLib-GObject-CRITICAL **: 13:21:57.472: Object 0x231f520 of type GimpExtension not finalized correctly.

Outputted when glib is built with -Dglib_debug=enabled and GIMP is run
with GOBJECT_DEBUG=objects.

Niels De Graef authored Jan 12, 2020 and Michael Natterer committed Apr 01, 2020

* Don't generate our own marshallers if they are available in GLib
  already
* Don't set the c_marshaller parameter in `g_signal_new()` if it's a
  default marshaller provided by GLib. See commit message of commit
  39e4aa3c on why this is the case.

... and move it to core-type.h, in preparation for next commit.

... in particular, so that the GimpLineArt object can take
ownership over newly-created GimpImageProxy inputs.

In GimpLineArt, add support for arbitrary input-buffer extents,
by shifting/unshifting the input/output buffers before/after
passing them to the main algorithm, so that the algorithm keeps
working with buffers whose top-left corner is at (0, 0).

luzpaz authored Oct 10, 2019 and Jehan committed Oct 10, 2019

Found via `codespell`

Fixes the error:
> Critical error: gimp_line_art_thaw: assertion 'line_art->priv->frozen'

This may happen in cases when we didn't actually freeze the line art at
pointer click, because we were in an invalid case (for instance,
clicking out of selection), hence we must not thaw the line art either
at button release.

Niels De Graef authored Aug 03, 2019 and Jehan committed Aug 03, 2019

Documentation-wise in C, this doesn't matter a lot, but it allows
GObject-Introspection based bindings to use their built-in versions when
they want to render any kind of documentation (for example, docs for
Python plugins can render `%NULL` as `None`).

which means that it's now included normally via gimpbase.h
and not any longer via gimpbasetypes.h which we only did out
of lazyness. A *lot* of files in libgimp* and app/ now need to

... instead of gegl_buffer_dup().

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.

... instead of gegl_buffer_copy().  The former parallelizes the
format conversion.

When clicking on a line art pixel, only this pixel gets colored, which
is fine for actual (original) line art pixels. But on generated ones
(closure pixels, which are internal only), you end up with a single
pixel colored while the whole surrounding area is empty. This feels like
a bug (even though it was not one technically) as you have no way to
guess you are clicking on a closure pixel.
Instead, when this happens, simulate clicks on all neighbour pixels,
hence potentially coloring all surrounding regions, which is most likely
what you wanted.

Commit bc187cc5 was a bit wrong as it was possible to get some race
conditions when changing settings quickly in a short time frame.

On various property changes, only recompute the line art when the
property actually changed. Also add a gimp_line_art_bind_gap_length() to
avoid computing twice the line art when changing both type of closure
(splines and segments) together, as is currently the case.

… Bucket Fill tool options.
This will provide feedback when the line art closure is being computed,
which may be useful on big images where it may take some time. Otherwise
painter may be left hanging without knowing what takes time.

Mostly I am adding a counter to the insignifiant zone fill, to be double
sure we are not going to fill huge areas (this should not happen already
anyway) and also it is no use to sample the line art buffer in such
case.

The algorithm to compute a zone area by following its border only works
well for fully closed zones. It may return negative values otherwise.
Let's just assume the created zone is big in this case (which may or may
not be the case, but this is the safe case as it does not prevent
closure creation).

Add some comments and string docs as it is not that obvious to
understand the whole logics, invert the return value (returning TRUE
when the closure line is accepted, instead of the opposite) and rename
it to more appropriate gimp_line_art_allow_closure().

It is just weird to return a negative area and multiply it by -1.
Just apply the proper signs from the start.

The line art imaginary segments/splines are not added when they create
too small zones, unless when these are just too small ("unsignificant").
Why the original algorithm keeps such micro-zones is because there may
be such zones created when several splines or segments are leaving from
a same key point (and we don't necessarily won't to forbid this). Also
we had cases when using very spiky brushes (for the line art) would
create many zones, and such micro-zones would appear just too often
(whereas with very smooth lines, they are much rarer, if not totally
absent most of the time).
Also it is to be noted that the original paper would call these
"unsignificant" indeed, but these are definitely significant for the
artists. Therefore having to "fix" the filling afterwards (with a brush
for instance) kind of defeat the whole purpose of this tool.

I already had code which would special-case (fill) 1-pixel zones in the
end, but bigger micro zones could appear (up to 4 pixels in the current
code, but this could change). Also I don't want to use the "Remove
Holes" (gimp:flood) operation as I want to make sure I remove only
micro-holes created by the line art closure code (not micro-holes from
original line arts in particular).

This code takes care of this issue by filling the micro-holes with
imaginary line art pixels, which may later be potentially bucket filled
when water-filling the line art.

After discussion with Sébastien Fourey and David Tschumperlé, it was
decided that a better fix for the edge case raised in #2785 was to add a
keypoint anyway, even if the point and none of its neigbours have a
positive smoothed curvature, yet they have a positive raw curvature. In
such case, we use the local maximum raw curvature instead of the local
maximum smoothed curvature.

Additionally to sample merge and active layer, now we can only use the
layer above or below the active layer as line art source.

The line art fill is meant to work on drawing lines. Though sample merge
still is ok in many cases, the more you fill with colors, the more the
line art computation becomes unecessarily complex. Also when you use a
lot of layers with some of them already filled with colors, it makes it
impossible to colorize some line art zones with the tool. Moreover you
just don't want to have to hide every layers out there to colorize one
layer (especially background layers and such as you may want to see the
result with your background).
Thus we want to be able to set the source as a unique layer, while it
not being necessarily the active one (because you want lines and colors
on different layers). In this case, I am assuming that the color and the
line layers are next to each other (most common organization).

... with some images.

This is sometimes asked, and myself also need to find it from time to
time. I may as well put the link inside the code comments, where it is
just easy to find!

In the bucket-fill tool, don't pre-calculate the line art when not
using a line-art fill area.  Also, misc. cleanup.

In GimpLineArt, use the "invalidate-preview" signal of the input
viewable, instead of its "painted" or "rendered" signals, for
asynchronously computing the line art.  Subsequently, remove the
aforementioned signals from GimpDrawable and GimpProjection,
respectively.  This simplifies the code, and reduces the number of
signals.

... in GimpBucketFillOptions for the line art algorithm.

Inside GimpLineArt, there are still 2 properties, but we don't show them
anymore in the Bucket Fill tool options. One of the main reason is
probably that it's hard to differentiate their usage. One is to close
with curved lines, the other with straight segments. Yet we don't
actually have any control on one or the other. All one knows is that you
can have "holes" in your drawing of a given size and you want them
close-like for filling. Only reason I can see to have 2 types of closure
is whether you'd want to totally disable one type of closure (then you
set it to 0). But this is a very limited reason for making the options
less understandable overall, IMO.
So for the time being, let's show up only a single option which sets
both properties in GimpLineArt. As patdavid says "it makes sense as a
first pass".

Also rename the option to shorter/simpler "Maximum gap length". Thanks
to patdavid and pippin for helping on figuring out this better label!

Finally I am bumping the default for the gaps to 100px. The original
values were ok for the basic small images used in demos, but not for
real life image where it was always too short (even 100px may still be
too short actually, but much better than the 20 and 60px from before!).

Practically it means that the algorithm won't close line art anymore
with both settings at 0. This can nevertheless still be a very useful
tool when you have a drawing style with well-closed lines. In such a
case, you will still profit from the color flooding under the line art
part of the algorithm.
Moreover with such well-closed zones from start, you don't get the
over-segmentation anymore and the threaded processing will be faster
obviously.

The code was too much spread out, in core and tool code, and also it was
made too specific to fill. I'll want to reuse this code at least in the
fuzzy select tool. This will avoid code duplication, and also make this
new process more self-contained and simpler to review later (the
algorithm also has a lot of settings and it is much cleaner to have them
as properties rather than passing these as parameters through many
functions).

The refactoring may not be finished; that's at least a first step.

... it's no longer needed, since GEGL commit
gegl@9dcd2cde.

Partially reverts commits:

6fca9959
cc10af72
49c53568
8edbc0d4
29f63616
3a201498
ee48ec68
4165a315
76408527
b7633c72
6ab12061
754a3c5b
22b4b647
55b34383
c6d23add
f03a84d6
822f9f0d
95358ca1
cdda37f4
41e80356
6761da42
fb5d7832
97ed7817
46e90365
ea9c5e6a
24fbdfb5
beb4ecb2
4b77831e
fcf113a3
567ffe94

In particular, make simpler code in a few places, taking abyss value
into account (rather than checking the position).

The distance map has all the information we need already. Also we will
actually grow up to the max radius pixel (middle pixel of a stroke).
After discussing with Aryeom, we realized it was better to fill a stroke
fully (for cases of overflowing, I already added the "Maximum growing
size" property anyway).

No need to go through an intermediate GeglBuffer when unneeded.

For this, I needed distmap of the closed version of the line art (after
splines and segments are created). This will result in invisible stroke
borders added when flooding in the end. These invisible borders will
have a thickness of 0.0, which means that flooding will stop at once
after these single pixels are filled, which makes it quick, and is
perfect since created splines and segments are 1-pixel thick anyway.
Only downside is having to run "gegl:distance-transform" a second time,
but this still stays fast.