1. 16 Nov, 2018 1 commit
    • 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
  2. 14 Nov, 2018 10 commits
    • Jehan's avatar
      app: edit the bucket fill tool options with new line art options. · 824af124
      Jehan authored
      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).
      824af124
    • Jehan's avatar
      app: fix line art labellization. · 93a49951
      Jehan authored
      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.
      93a49951
    • Jehan's avatar
      app: better use GeglBufferIterator! · c4ff8154
      Jehan authored
      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.
      c4ff8154
    • Jehan's avatar
      app: use char array for temporary data (rather than a GEGL buffer). · 0c80f8a7
      Jehan authored
      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.
      0c80f8a7
    • Jehan's avatar
      app: use simpler allocated variables. · f975f15e
      Jehan authored
      Allocating double-level arrays is just very inefficient.
      f975f15e
    • Jehan's avatar
      f19181dc
    • Jehan's avatar
      app: fix stroke labels in gimp_lineart_estimate_stroke_width(). · 910d7934
      Jehan authored
      I must make sure that stroke pixels are labelled 0 and non-stroke other
      than 0.
      910d7934
    • Jehan's avatar
      app: use more GeglBufferIterator. · 1822ea39
      Jehan authored
      In this case, it makes the code a bit more messy, but hopefully more
      efficient.
      1822ea39
    • Jehan's avatar
    • Jehan's avatar
      app, libgimpbase: add GIMP_SELECT_CRITERION_LINE_ART selection type. · 8ed12b1b
      Jehan authored
      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.
      8ed12b1b