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.
(cherry picked from commit 6391b2bcff)
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.
(cherry picked from commit c0996241f6)
… 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.
(cherry picked from commit bc187cc5cc)
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).
(cherry picked from commit c71b4916af)
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.
(cherry picked from commit db18c679f3)
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).
(cherry picked from commit 6bec0bc82d)
We don't really need to flow every line art pixel and this new
implementation is simpler (because we don't actually need over-featured
watershedding), and a lot lot faster, making the line art bucket fill
now very reactive.
For this, I am keeping the computed distance map, as well as local
thickness map around to be used when flooding the line art pixels
(basically I try to flood half the stroke thickness).
Note that there are still some issues with this new implementation as it
doesn't properly flood yet created (i.e. invisible) splines and
segments, and in particular the ones between 2 colored sections. I am
going to fix this next.
(cherry picked from commit 3467acf096)
Since commit b00037b850, erosion size is not used anymore, as this step
has been removed, and the end point detection now uses local thickness
of strokes instead.
(cherry picked from commit 3f58a38574)
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.
(cherry picked from commit 8ed12b1b98)
