• Jehan's avatar
    app: improve end point detection for smart colorization. · b00037b8
    Jehan authored
    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.
    b00037b8
Name
Last commit
Last update
..
actions Loading commit data...
config Loading commit data...
core Loading commit data...
dialogs Loading commit data...
display Loading commit data...
file Loading commit data...
gegl Loading commit data...
gui Loading commit data...
menus Loading commit data...
operations Loading commit data...
paint Loading commit data...
pdb Loading commit data...
plug-in Loading commit data...
propgui Loading commit data...
tests Loading commit data...
text Loading commit data...
tools Loading commit data...
vectors Loading commit data...
widgets Loading commit data...
xcf Loading commit data...
.gitignore Loading commit data...
Makefile.am Loading commit data...
about.h Loading commit data...
app.c Loading commit data...
app.h Loading commit data...
errors.c Loading commit data...
errors.h Loading commit data...
gimp-debug.c Loading commit data...
gimp-debug.h Loading commit data...
gimp-intl.h Loading commit data...
gimp-log.c Loading commit data...
gimp-log.h Loading commit data...
gimp-priorities.h Loading commit data...
gimp-version.c Loading commit data...
gimp-version.h Loading commit data...
gimpcore.def Loading commit data...
language.c Loading commit data...
language.h Loading commit data...
main.c Loading commit data...
sanity.c Loading commit data...
sanity.h Loading commit data...
signals.c Loading commit data...
signals.h Loading commit data...
tests.c Loading commit data...
tests.h Loading commit data...
unique.c Loading commit data...
unique.h Loading commit data...