1. 04 Jan, 2019 1 commit
  2. 01 Jan, 2019 1 commit
    • Michael Natterer's avatar
      libgimp: fix gimp_drawable_get_format() to honor the drawable's space · dfe3e236
      Michael Natterer authored
      The raw PDB wrapper _gimp_drawable_get_format() only transfers the
      format's encoding, so we need to add the space from the image's color
      profile.
      
      Also fix handling of indexed formats: remove our own indexed format
      cache and rely on babl_new_palette_with_space() to return the same
      format for any (encoding, space) combination.
      
      Also update the PDB docs to reflect that most magic is happening in
      the libgimp C wrapper.
      dfe3e236
  3. 12 Dec, 2018 1 commit
    • Jehan's avatar
      app: do not make line art bucket fill a GimpSelectCriterion anymore. · cd924f45
      Jehan authored
      This was my initial choice, but the more I think about it, the less I am
      sure this was the right choice. There was some common code (as I was
      making a common composite bucket fill once the line art was generated),
      but there is also a lot of different code and the functions were filled
      of exception when we were doing a line art fill. Also though there is a
      bit of color works (the way we decide whether a pixel is part of a
      stroke or not, though currently this is basic grayscale threshold), this
      is really not the same as other criterions. In particular this was made
      obvious on the Select by Color tool where the line art criterion was
      completely meaningless and would have had to be opted-out!
      
      This commit split a bit the code. Instead of finding the line art in the
      criterion list, I add a third choice to the "Fill whole selection"/"Fill
      similar colors" radio. In turn I create a new GimpBucketFillArea type
      with the 3 choices, and remove line art value from GimpSelectCriterion.
      
      I am not fully happy yet of this code, as it creates a bit of duplicate
      code, and I would appreciate to move some code away from gimpdrawable-*
      and gimppickable-* files. This may happen later. I break the work in
      pieces to not get too messy.
      Also this removes access to the smart colorization from the API, but
      that's probably ok as I prefer to not freeze options too early in the
      process since API needs to be stable. Probably we should get a concept
      of experimental API.
      cd924f45
  4. 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
  5. 29 Nov, 2018 1 commit
  6. 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
  7. 22 Nov, 2018 2 commits
    • Jehan's avatar
      app: add "line-art-max-grow" property to the bucket fill options. · eb042e6c
      Jehan authored
      When flooding the line art, we may overflood it in sample merge (which
      would use color in the line art computation). And if having all colors
      on the same layer, this would go over other colors (making the wrong
      impression that the line art leaked).
      This new option is mostly to keep some control over the mask growth.
      Usually a few pixels is enough for most styles of drawing (though we
      could technically allow for very wide strokes).
      eb042e6c
    • Jehan's avatar
      app: replace gegl:watershed-transform with custom algorithm. · 3467acf0
      Jehan authored
      We don't really need to flow every line art pixel and this new
      implementation is simpler (because we don't actually need over-featured
      watershedding), and a lot lot faster, making the line art bucket fill
      now very reactive.
      For this, I am keeping the computed distance map, as well as local
      thickness map around to be used when flooding the line art pixels
      (basically I try to flood half the stroke thickness).
      
      Note that there are still some issues with this new implementation as it
      doesn't properly flood yet created (i.e. invisible) splines and
      segments, and in particular the ones between 2 colored sections. I am
      going to fix this next.
      3467acf0
  8. 19 Nov, 2018 1 commit
  9. 14 Nov, 2018 2 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: compute line art in advance. · f246f404
      Jehan authored
      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.
      f246f404
  10. 20 Oct, 2018 1 commit
  11. 09 Aug, 2018 1 commit
  12. 21 Jul, 2018 1 commit
    • Michael Natterer's avatar
      Initial space invasion commit in GIMP · e09e563a
      Michael Natterer authored
      All babl formats now have a space equivalent to a color profile,
      determining the format's primaries and TRCs. This commit makes GIMP
      aware of this.
      
      libgimp:
      
      - enum GimpPrecision: rename GAMMA values to NON_LINEAR and keep GAMMA
        as deprecated aliases, add PERCEPTUAL values so we now have LINEAR,
        NON_LINEAR and PERCPTUAL for each encoding, matching the babl
        encoding variants RGB, R'G'B' and R~G~B~.
      
      - gimp_color_transform_can_gegl_copy() now returns TRUE if both
        profiles can return a babl space, increasing the amount of fast babl
        color conversions significantly.
      
      - TODO: no solution yet for getting libgimp drawable proxy buffers in
        the right format with space.
      
      plug-ins:
      
      - follow the GimpPrecision change.
      
      - TODO: everything else unchanged and partly broken or sub-optimal,
        like setting a new image's color profile too late.
      
      app:
      
      - add enum GimpTRCType { LINEAR, NON_LINEAR, PERCEPTUAL } as
        replacement for all "linear" booleans.
      
      - change gimp-babl functions to take babl spaces and GimpTRCType
        parameters and support all sorts of new perceptual ~ formats.
      
      - a lot of places changed in the early days of goat invasion didn't
        take advantage of gimp-babl utility functions and constructed
        formats manually. They all needed revisiting and many now use much
        simpler code calling gimp-babl API.
      
      - change gimp_babl_format_get_color_profile() to really extract a
        newly allocated color profile from the format, and add
        gimp_babl_get_builtin_color_profile() which does the same as
        gimp_babl_format_get_color_profile() did before. Visited all callers
        to decide whether they are looking for the format's actual profile,
        or for one of the builtin profiles, simplifying code that only needs
        builtin profiles.
      
      - drawables have a new get_space_api(), get_linear() is now get_trc().
      
      - images now have a "layer space" and an API to get it,
        gimp_image_get_layer_format() returns formats in that space.
      
      - an image's layer space is created from the image's color profile,
        change gimpimage-color-profile to deal with that correctly
      
      - change many babl_format() calls to babl_format_with_space() and take
        the space from passed formats or drawables
      
      - add function gimp_layer_fix_format_space() which replaces the
        layer's buffer with one that has the image's layer format, but
        doesn't change pixel values
      
      - use gimp_layer_fix_format_space() to make sure layers loaded from
        XCF and created by plug-ins have the right space when added to the
        image, because it's impossible to always assign the right space upon
        layer creation
      
      - "assign color profile" and "discard color profile" now require use
        of gimp_layer_fix_format_space() too because the profile is now
        embedded in all formats via the space.  Add
        gimp_image_assign_color_profile() which does all that and call it
        instead of a simple gimp_image_set_color_profile(), also from the
        PDB set-color-profile functions, which are essentially "assign" and
        "discard" calls.
      
      - generally, make sure a new image's color profile is set before
        adding layers to it, gimp_image_set_color_profile() is more than
        before considered know-what-you-are-doing API.
      
      - take special precaution in all places that call
        gimp_drawable_convert_type(), we now must pass a new_profile from
        all callers that convert layers within the same image (such as
        image_convert_type, image_convert_precision), because the layer's
        new space can't be determined from the image's layer format during
        the call.
      
      - change all "linear" properties to "trc", in all config objects like
        for levels and curves, in the histogram, in the widgets. This results
        in some GUI that now has three choices instead of two.
        TODO: we might want to reduce that back to two later.
      
      - keep "linear" boolean properties around as compat if needed for file
        pasring, but always convert the parsed parsed boolean to
        GimpTRCType.
      
      - TODO: the image's "enable color management" switch is currently
        broken, will fix that in another commit.
      e09e563a
  13. 17 Jul, 2018 1 commit
    • Ell's avatar
      app, pdb: add gimp-register-file-handler-priority procedure · b4ac9568
      Ell authored
      Add a gimp-register-file-handler-priority procedure, which can be
      used to set the priority of a file-handler procedure.  When more
      than one file-handler procedure matches a file, the procedure with
      the lowest priority is used; if more than one procedure has the
      lowest priority, it is unspecified which one of them is used.  The
      default priority of file-handler procedures is 0.
      
      Add the necessary plumbing (plus some fixes) to the plug-in manager
      to handle file-handler priorities.  In particular, use two
      different lists for each type of file-handler procedures: one meant
      for searching, and is sorted according to priority, and one meant
      for display, and is sorted alphabetically.
      b4ac9568
  14. 15 Jul, 2018 1 commit
  15. 14 Jul, 2018 2 commits
  16. 11 Jul, 2018 1 commit
  17. 06 Jul, 2018 1 commit
  18. 05 Jun, 2018 1 commit
    • Jehan's avatar
      app: do not stop the measurement when straightening. · d56a8d43
      Jehan authored
      Instead just transform the measurement extremities appropriately to
      still map to the same points.
      To do so, I also added out parameters to gimp_image_resize_to_layers()
      so that calling code can get offsets from old origin (as well as new
      image dimensions).
      d56a8d43
  19. 02 Jun, 2018 1 commit
  20. 29 May, 2018 2 commits
  21. 27 May, 2018 1 commit
    • Jehan's avatar
      Issue #1211: Load fonts in background after startup. · 2484dec7
      Jehan authored
      Fonts should not be blocking startup as this provides a very bad
      experience when people have a lot of fonts. This was experienced even
      more on Windows where loading time are often excessively long.
      We were already running font loading in a thread, yet were still
      blocking startup (thread was only so that the loading status GUI could
      get updated as a feedback). Now we will only start loading and proceed
      directly to next steps.
      While fonts are not loaded, the text tool will not be usable, yet all
      other activities can be performed.
      2484dec7
  22. 20 May, 2018 3 commits
  23. 12 May, 2018 1 commit
  24. 07 May, 2018 3 commits
  25. 01 May, 2018 1 commit
  26. 26 Apr, 2018 1 commit
  27. 24 Apr, 2018 1 commit
  28. 23 Apr, 2018 4 commits
  29. 21 Apr, 2018 1 commit