The "update" signal on drawable or projection can actually be emitted
many times for a single painting event. Just add new signals ("painted"
on GimpDrawable and "rendered" on GimpProjection) which are emitted once
for a single update (from user point of view), at the end, after actual
rendering is done (i.e. after the various "update" signals).
Also better support the sample merge vs current drawable paths for
bucket fill.
(cherry picked from commit 047265333c)
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)
Previous algorithm was relying on strokes of small radius to detect
points of interest. In order to work with various sizes of strokes, we
were computing an approximate median stroke thickness, then using this
median value to erode the binary line art.
Unfortunately this was not working that well for very fat strokes, and
also it was potentially opening holes in the line art. These holes were
usually filled back later during the spline and segment creations. Yet
it could not be totally assured, and we had some experience where color
filling would leak out of line art zones without any holes from the
start (which is the opposite of where this new feature is supposed to
go)!
This updated code computes instead some radius estimate for every border
point of strokes, and the detection of end points uses this information
of local thickness. Using local approximation is obviously much more
accurate than a single thickness approximation for the whole drawing,
while not making the processing slower (in particular since we got rid
of the quite expensive erosion step).
This fixes the aforementionned issues (i.e. work better with fat strokes
and do not create invisible holes in closed lines), and also is not
subject to the problem of mistakenly increasing median radius when you
color fill in sample merge mode (i.e. using also the color data in the
input)!
Also it is algorithmically less intensive, which is obviously very good.
This new version of the algorithm is a reimplementation in GIMP of new
code by Sébastien Fourey and David Tschumperlé, as a result of our many
discussions and tests with the previous algorithm.
Note that we had various tests, experiments and propositions to try and
improve these issues. Skeletonization was evoked, but would have been
most likely much slower. Simpler erosion based solely on local radius
was also a possibility but it may have created too much noise (skeleton
barbs), with high curvature, hence may have created too many new
artificial endpoints.
This new version also creates more endpoints though (and does not seem
to lose any previously detected endpoints), which may be a bit annoying
yet acceptable with the new bucket fill stroking interaction. In any
case, on simple examples, it seems to do the job quite well.
(cherry picked from commit b00037b850)
Other bucket fills are now done as filter until committed, but basic
selection fill is still done automatically. So let's make sure the
canvas is updated immediately (as it used to be before my changes).
(cherry picked from commit 287d90ba9e)
I have not added all the options for this new tool yet, but this sets
the base. I also added a bit of TODO for several places where we need to
make it settable, in particular the fuzzy select tool, but also simply
PDB calls (this will need to be a PDB context settings.
Maybe also I will want to make some LineArtOptions struct in order not
to have infinite list of parameters to functions. And at some point, it
may also be worth splitting a bit process with other type of
selection/fill (since they barely share any settings anyway).
Finally I take the opportunity to document a little more the parameters
to gimp_lineart_close(), which can still be improved later (I should
have documented these straight away when I re-implemented this all from
G'Mic code, as I am a bit fuzzy on some details now and will need to
re-understand code).
(cherry picked from commit 824af12438)
Rather than just having a click interaction, let's allow to "paint" with
the bucket fill. This is very useful for the new "line art" colorization
since it tends to over-segment the drawing. Therefore being able to
stroke through the canvas (rather than click, up, move, click, etc.)
makes the process much simpler. This is also faster since we don't have
to recompute the line art while a filling is in-progress.
Note that this new behavior is not only for the line art mode, but also
any other fill criterion, for which it can also be useful.
Last change of behavior as a side effect: it is possible to cancel the
tool changes the usual GIMP way (for instance by right clicking when
releasing the mouse button).
(cherry picked from commit e1c4050617)
This makes the speed sensation of the tool much faster as line art can
be computed in dead time when you start the tool or when you move the
pointer.
(cherry picked from commit a3cda4abbe)
Right now, this is mostly meaningless as it is still done sequentially.
But I am mostly preparing the field to pre-compute the line art as
background thread.
(cherry picked from commit f246f40494)
The older labelling based off CImg code was broken (probably because of
me, from my port). Anyway I realized what it was trying to do was too
generic, which is why we had to fix the result later (labeling all
non-stroke pixels as 0, etc.). Instead I just implemented a simpler
labelling and only look for stroke regions. It still over-label a bit
the painting but a lot less, and is much faster.
(cherry picked from commit 93a49951a0)
I don't actually need to loop through borders first. This is what the
abyss policy is for, and I can simply check the iterator position to
verify I am within buffer boundaries or not.
This simplifies the code a lot.
(cherry picked from commit c4ff81540d)
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!
(cherry picked from commit 410c747509)
... labels buffer.
We can watershed directly the mask buffer being correctly flagged.
This commit relies on merge request gegl!8 being accepted and merged.
(cherry picked from commit e905ea7ba2)
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.
(cherry picked from commit 0c80f8a718)
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.
(cherry picked from commit 8502b4e743)
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)
Showing it was only displaying the top modes, with a lot of top space,
and you had to slowly scroll down the list. This is the same as #2642
(as Alexandre noted in a comment), so I just use the same "fix" though I
don't fully understand it. It feels more of a side effect of
gtk_combo_box_set_wrap_width() working around a bug of GtkComboBox. So
if anyone has a better fix and understand the issue, feel free to patch
(maybe GTK+ directly?). In the meantime, it works well enough. :-)
(cherry picked from commit 6dfca83c2a)
Update the definition of the "cache-compressed" and "swap-
compressed" dashboard variables, to reflect the changes made by
GEGL commit gegl@dc22e997757ab91c180244d5290d094d2ea8572f.
(cherry picked from commit fda53f9c18)
In the warp tool, when the warp is empty and the current behavior
has no effect as a result (i.e., when it's ERASE or SMOOTH), show
an error message in the status bar, and blink the behavior combo
widget in the tool options, to hint at the source of the error.
(cherry picked from commit 7958387d54)
In the warp tool, when no stroke events are selected, blink the
stroke frame widget in the tool options, in addition to showing an
error message in the status bar, to hint at the source of the
error.
(cherry picked from commit 17cc44a7be)
The enumerators of the GimpWarpBehavior enum, except for MOVE, had
a GEGL_ prefix, rather than a GIMP_ prefix, for some reason.
Change all of them to GIMP_.
(cherry picked from commit 2085cb4a37)
Since commit fe139e5662, when
blinking a widget, we cancel blinking for all its ancestors. Avoid
redrawing all the ancestors as a result, unless they're actually
blinking. This prevents some noticeable lag when blinking a
widget.
(cherry picked from commit 5a2dee29d7)
In all tools, when the current item can't be edited due to its lock
mask, use gimp_tools_blink_lock_box(), added in the previous
commit,to blink the lock box of the corresponding dockable, in
addition to showing an error message in the status bar, to hint at
the source of the error.
(cherry picked from commit 637105b962)
Add gimp_tools_blink_lock_box() utility function, in a new
gimptools-utils.c file, which takes a GimpItem, and blinks the
GimpItemTreeView lock-box of the corresponding dockable. This can
be used to hint that the item's lock toggles are preventing it from
being edited.
(cherry picked from commit 9bdaec3a49)
When blinking a widget using gimp_widget_blink(), cancel the
blinking of all its ancestors, to reduce visual clutter.
(cherry picked from commit fe139e5662)
In the paint tools, when the current paint mode is invalid, i.e.,
when it requires an alpha channel, but the the current drawable has
no alpha channel, or its alpha channel is locked, blink the paint-
mode box widget in the tool options, in addition to showing an
error message in the status bar, to hint at the source of the
error.
(cherry picked from commit 464bf1b0a9)
In the transform tools, when there is no item of the selected type
to transform, blink the move-type box widget in the tool options,
in addition to showing an error message in the status bar, to hint
at the source of the error.
(cherry picked from commit 17412aa234)
In the move tool, when there is no item of the selected type to
move, blink the move-type box widget in the tool options, in
addition to showing an error message in the status bar, to hint at
the source of the error.
(cherry picked from commit c9bc3d7a09)
In the selection tools, when the selected operation is invalid,
i.e., when trying to subtract-from or intersect-with an empty
selection, blink the selection-mode box widget in the tool options,
in addition to showing an error message in the status bar, to hint
at the source of the error.
(cherry picked from commit f990e41609)
In gimp_tool_compass_update_angle(), use fuzzy comparisson when
determining whether to update the angle properties, to avoid
infinite recursion due to floating-point inaccuracies. In
partcicular, on x86, when using the x87 FPU rather than SSE, the
floating-point registers are 80-bit, while the properties are
stored as 64-bit, which can create small discrepancies between the
calculated angles and the stored values.
(cherry picked from commit ad831dbc6d)
