1. 03 Mar, 2022 1 commit
    • Jehan's avatar
      app: make the "Automatic closure" a settings of its own. · d3686fdb
      Jehan authored
      This is the same thing as setting the max gap length to 0, except that
      it would mean constantly having to play with the gap length and possibly
      losing settings you carefully tweaked. Instead with this additional
      settings, we hide the gap length settings when automatic closure is
      disabled.
      
      Also it makes kind of a nice parallel with the "Manual closure" settings
      which can also be enabled/disabled similarly.
      d3686fdb
  2. 13 Aug, 2021 1 commit
  3. 03 Aug, 2021 1 commit
    • Jehan's avatar
      Issue #7115: properly chaining up finalize() methods. · cc578608
      Jehan authored
      Thanks to Massimo Valentini for finding these.
      Fixes:
      
      > GLib-GObject-CRITICAL **: 13:21:53.256: Object 0x5485140 of type GimpLineArt not finalized correctly.
      > GLib-GObject-CRITICAL **: 13:21:57.472: Object 0x231f520 of type GimpExtension not finalized correctly.
      
      Outputted when glib is built with -Dglib_debug=enabled and GIMP is run
      with GOBJECT_DEBUG=objects.
      cc578608
  4. 31 May, 2020 1 commit
  5. 01 Apr, 2020 1 commit
    • Niels De Graef's avatar
      Cleanup GObject signal marshallers · 878804fb
      Niels De Graef authored and Michael Natterer's avatar Michael Natterer committed
      * Don't generate our own marshallers if they are available in GLib
        already
      * Don't set the c_marshaller parameter in `g_signal_new()` if it's a
        default marshaller provided by GLib. See commit message of commit
        39e4aa3c on why this is the case.
      878804fb
  6. 13 Mar, 2020 1 commit
  7. 04 Nov, 2019 2 commits
    • Ell's avatar
      app: in GimpLineArt, ref input pickable · c8b5c81a
      Ell authored
      ... in particular, so that the GimpLineArt object can take
      ownership over newly-created GimpImageProxy inputs.
      c8b5c81a
    • Ell's avatar
      app: in GimpLineArt, add support for arbitrary buffer extents · bce96eb6
      Ell authored
      In GimpLineArt, add support for arbitrary input-buffer extents,
      by shifting/unshifting the input/output buffers before/after
      passing them to the main algorithm, so that the algorithm keeps
      working with buffers whose top-left corner is at (0, 0).
      bce96eb6
  8. 10 Oct, 2019 1 commit
  9. 27 Aug, 2019 1 commit
    • Jehan's avatar
      Issue #3263: fix critical error on bucket fill tool. · 6391b2bc
      Jehan authored
      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.
      6391b2bc
  10. 13 Aug, 2019 1 commit
  11. 03 Aug, 2019 1 commit
    • Niels De Graef's avatar
      Make sure to use % for constants · 746a72b9
      Niels De Graef authored and Jehan's avatar Jehan committed
      Documentation-wise in C, this doesn't matter a lot, but it allows
      GObject-Introspection based bindings to use their built-in versions when
      they want to render any kind of documentation (for example, docs for
      Python plugins can render `%NULL` as `None`).
      746a72b9
  12. 31 Jul, 2019 1 commit
  13. 30 Jul, 2019 1 commit
  14. 06 Mar, 2019 3 commits
    • Ell's avatar
      app: various fixes to last commit · caad9ca6
      Ell authored
      caad9ca6
    • Ell's avatar
      app: allow canceling line-art computation · d8e69d66
      Ell authored
      Line-art computation can take a long time, and it's therefore
      desirable for it to be interruptable.  While we do cancel the line-
      art async when its result is no longer needed, most parts of the
      computation don't respond to the cancelation request, leaving the
      async operation running in the background, blocking subsequent
      async operations.
      
      Implement cancelation support of line-art computation, by passing
      down the async object to the various functions, and periodically
      checking for its cancelation at various points.  When the async is
      canceled, we quickly abort the operation.
      
      Even though cancelation now happens relatively quickly, some parts
      of the computation are still uninterruptable and may incur some
      latency, so we avoid waiting for the async opration to be aborted
      after cancelation, as we did before.
      d8e69d66
    • Ell's avatar
      app: use gimp_gegl_buffer_copy() in various places · bb7f61c9
      Ell authored
      ... instead of gegl_buffer_copy().  The former parallelizes the
      format conversion.
      bb7f61c9
  15. 04 Mar, 2019 4 commits
    • Jehan's avatar
      app: improve line art filling when clicking on a line art closure. · f310db6c
      Jehan authored
      When clicking on a line art pixel, only this pixel gets colored, which
      is fine for actual (original) line art pixels. But on generated ones
      (closure pixels, which are internal only), you end up with a single
      pixel colored while the whole surrounding area is empty. This feels like
      a bug (even though it was not one technically) as you have no way to
      guess you are clicking on a closure pixel.
      Instead, when this happens, simulate clicks on all neighbour pixels,
      hence potentially coloring all surrounding regions, which is most likely
      what you wanted.
      f310db6c
    • Jehan's avatar
      app: fixing the line art GimpBusyBox visibility. · 3a317e72
      Jehan authored
      Commit bc187cc5 was a bit wrong as it was possible to get some race
      conditions when changing settings quickly in a short time frame.
      3a317e72
    • Jehan's avatar
      app: avoid useless line art closure recomputation. · c0996241
      Jehan authored
      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.
      c0996241
    • Jehan's avatar
      app: add a GimpBusyBox near the "Line Art Detection" label in… · bc187cc5
      Jehan authored
      … 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.
      bc187cc5
  16. 16 Feb, 2019 1 commit
    • Jehan's avatar
      app: some small improvements in line art code. · 248477a1
      Jehan authored
      Mostly I am adding a counter to the insignifiant zone fill, to be double
      sure we are not going to fill huge areas (this should not happen already
      anyway) and also it is no use to sample the line art buffer in such
      case.
      248477a1
  17. 14 Feb, 2019 1 commit
    • Jehan's avatar
      app: gimp_edgel_region_area() may return < 0 for non-closed zones. · 0636c302
      Jehan authored
      The algorithm to compute a zone area by following its border only works
      well for fully closed zones. It may return negative values otherwise.
      Let's just assume the created zone is big in this case (which may or may
      not be the case, but this is the safe case as it does not prevent
      closure creation).
      0636c302
  18. 11 Feb, 2019 2 commits
  19. 07 Feb, 2019 1 commit
    • Jehan's avatar
      app: improve line art bucket fill by filling unsignificant areas. · 72092fbd
      Jehan authored
      The line art imaginary segments/splines are not added when they create
      too small zones, unless when these are just too small ("unsignificant").
      Why the original algorithm keeps such micro-zones is because there may
      be such zones created when several splines or segments are leaving from
      a same key point (and we don't necessarily won't to forbid this). Also
      we had cases when using very spiky brushes (for the line art) would
      create many zones, and such micro-zones would appear just too often
      (whereas with very smooth lines, they are much rarer, if not totally
      absent most of the time).
      Also it is to be noted that the original paper would call these
      "unsignificant" indeed, but these are definitely significant for the
      artists. Therefore having to "fix" the filling afterwards (with a brush
      for instance) kind of defeat the whole purpose of this tool.
      
      I already had code which would special-case (fill) 1-pixel zones in the
      end, but bigger micro zones could appear (up to 4 pixels in the current
      code, but this could change). Also I don't want to use the "Remove
      Holes" (gimp:flood) operation as I want to make sure I remove only
      micro-holes created by the line art closure code (not micro-holes from
      original line arts in particular).
      
      This code takes care of this issue by filling the micro-holes with
      imaginary line art pixels, which may later be potentially bucket filled
      when water-filling the line art.
      72092fbd
  20. 17 Jan, 2019 1 commit
    • Jehan's avatar
      app: improved fix to commit 036ccc70. · aa042586
      Jehan authored
      After discussion with Sébastien Fourey and David Tschumperlé, it was
      decided that a better fix for the edge case raised in #2785 was to add a
      keypoint anyway, even if the point and none of its neigbours have a
      positive smoothed curvature, yet they have a positive raw curvature. In
      such case, we use the local maximum raw curvature instead of the local
      maximum smoothed curvature.
      aa042586
  21. 15 Jan, 2019 1 commit
    • Jehan's avatar
      app: add the concept of line art source to Bucket Fill tool. · c71b4916
      Jehan authored
      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).
      c71b4916
  22. 13 Jan, 2019 1 commit
  23. 11 Jan, 2019 1 commit
  24. 06 Jan, 2019 1 commit
  25. 27 Dec, 2018 1 commit
    • Ell's avatar
      app: in GimpLineArt, use "invalidate-preview" signal of input viewable · ef9b1f66
      Ell authored
      In GimpLineArt, use the "invalidate-preview" signal of the input
      viewable, instead of its "painted" or "rendered" signals, for
      asynchronously computing the line art.  Subsequently, remove the
      aforementioned signals from GimpDrawable and GimpProjection,
      respectively.  This simplifies the code, and reduces the number of
      signals.
      ef9b1f66
  26. 24 Dec, 2018 1 commit
    • Jehan's avatar
      app: rename and merge the spline and segment length properties... · 503775a5
      Jehan authored
      ... in GimpBucketFillOptions for the line art algorithm.
      
      Inside GimpLineArt, there are still 2 properties, but we don't show them
      anymore in the Bucket Fill tool options. One of the main reason is
      probably that it's hard to differentiate their usage. One is to close
      with curved lines, the other with straight segments. Yet we don't
      actually have any control on one or the other. All one knows is that you
      can have "holes" in your drawing of a given size and you want them
      close-like for filling. Only reason I can see to have 2 types of closure
      is whether you'd want to totally disable one type of closure (then you
      set it to 0). But this is a very limited reason for making the options
      less understandable overall, IMO.
      So for the time being, let's show up only a single option which sets
      both properties in GimpLineArt. As patdavid says "it makes sense as a
      first pass".
      
      Also rename the option to shorter/simpler "Maximum gap length". Thanks
      to patdavid and pippin for helping on figuring out this better label!
      
      Finally I am bumping the default for the gaps to 100px. The original
      values were ok for the basic small images used in demos, but not for
      real life image where it was always too short (even 100px may still be
      too short actually, but much better than the 20 and 60px from before!).
      503775a5
  27. 17 Dec, 2018 1 commit
    • Jehan's avatar
      app: allow setting line art spline and segment length to 0. · 0a2d0661
      Jehan authored
      Practically it means that the algorithm won't close line art anymore
      with both settings at 0. This can nevertheless still be a very useful
      tool when you have a drawing style with well-closed lines. In such a
      case, you will still profit from the color flooding under the line art
      part of the algorithm.
      Moreover with such well-closed zones from start, you don't get the
      over-segmentation anymore and the threaded processing will be faster
      obviously.
      0a2d0661
  28. 07 Dec, 2018 1 commit
    • Jehan's avatar
      app: reorganize the line art code inside a GimpLineArt object. · db18c679
      Jehan authored
      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.
      db18c679
  29. 02 Dec, 2018 1 commit
  30. 29 Nov, 2018 1 commit
  31. 27 Nov, 2018 1 commit
    • Jehan's avatar
      app: radius map actually not useful during smart colorization grow step. · 6bec0bc8
      Jehan authored
      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).
      6bec0bc8
  32. 26 Nov, 2018 1 commit
  33. 22 Nov, 2018 1 commit
    • Jehan's avatar
      app: properly (bucket) fill created splines and segments in line art. · 5a4754f3
      Jehan authored
      For this, I needed distmap of the closed version of the line art (after
      splines and segments are created). This will result in invisible stroke
      borders added when flooding in the end. These invisible borders will
      have a thickness of 0.0, which means that flooding will stop at once
      after these single pixels are filled, which makes it quick, and is
      perfect since created splines and segments are 1-pixel thick anyway.
      Only downside is having to run "gegl:distance-transform" a second time,
      but this still stays fast.
      5a4754f3