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).
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.
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.
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.
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.
Commented out the inactive plug-ins registry: no point linking to a dead page.
Added links to the roadmap page, main wiki page, and the bug tracker. Placed
the link to the bug tracker one level up from '<Image>/Help/GIMP Online'
to make it more visible.
When constructing CC_VERSION, escape backslash characters in the
compiler version string, so that they don't get interpreted as
escape sequences by the compiler. This is especially important on
Windows, where the version string of MinGW may contain backslash
characters as part of paths.
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.
... as I would like it to.
Use GimpSpinButton, added in the previous commit, in GimpSizeEntry,
instead of GtkSpinButton. This avoids updating the spin-buttons'
adjustment values when they lose focus, truncating the value if it
can't be accurately displayed using the corresponding spin-button's
digit count. Since size-entries can have multiple spin-buttons
using different units, this prevents the value from changing when
entring a value using one unit, and then shifting the focus to, but
not changing, another unit.
GimpSpinButton is a drop-in replacement for (and a subclass of)
GtkSpinButton. Unlike GtkSpinButton, it avoids updating the
adjustment value when losing focus, unless the entry text has
changed. This prevents accidental loss of precision, when the
adjustment value can't be accurately displayed in the entry.
... only shows the color (and nothing else) when "Convert bitmaps to
vector graphics where possible" was set.
This is because gimp_drawable_histogram() only checks selected pixels.
So let's make sure we work on a duplicate of the image so that we can
safely remove the selection before processing the export.
(cherry picked from commit 679e341285)
Add devel-docs/performance-logs/performance-logs.md, which
describes how to record and view performance logs, and how to
report perofrmance-related issues.
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.
In sample-search predicates, remove the "exclusive" parameter of
the "function()" function, and replace it with optional "id" and
"state" parameters, which limit the match to the call-stacks of
matching threads, as per the "thread()" function.
Sort the backtrace thread-list by thread ID.
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.
Include instrumentation-variable descriptions in the var-defs
section of performance logs, so that they can be displayed
alongside their names when viewing the log.
Simplify gimp_view_renderer_drawable_render(), by consolidating
common code paths. In particular, when rendering the preview as
part of an image, always crop the preview to the bounds of the
image, even when downscaling, to avoid unnecessarily downscaling/
convering cropped-out regions. We previously only did this when
upscaling the preview by a factor of 2 or more; whatever the reason
for this used to be, it's no longer there.
In gimp_view_renderer_drawable_render(), avoid overflow in preview-
area calculation. This prevents erroneously setting 'scaling_up'
to FALSE while upscaling the drawable by a very large amount, which
can lead to the creation of a very large GimpTempBuf for the
preview, causing memory allocation to fail.
Add line data padding when necessary.
Additionally I realize we should convert to little-endian after checking
the bytesperline oddness (this bug was most likely unnoticed until now
as most desktop proc are little endian now anyway).
