After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 521433 - Heal tool doesn't respect the brush mask
Heal tool doesn't respect the brush mask
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: Tools
2.4.x
Other All
: Normal normal
: 2.4
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2008-03-09 19:15 UTC by Dori
Modified: 2008-10-30 20:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch for gimpheal.c, from rev 24324 of trunk (10.18 KB, patch)
2008-03-11 16:23 UTC, weskaggs
committed Details | Review

Description Dori 2008-03-09 19:15:14 UTC
When using the heal tool I've noticed that even the area outside of the brush outline gets modified. I don't think this should happen. If it is intended, it should show another outline besides the brush that tells you what area might be impacted by the use of the tool.

Thank you
Comment 1 david gowers 2008-03-09 22:42:08 UTC
Only the heal tool? If this is what I think it is, it would also apply to paintbrush, clone, and other paint tools.
IIRC 2.4.x smooth the brush before generating an outline. This generally means that the outline is less complex, and can be slightly smaller than the outline shown.
In any case, the outline only shows where the most paint will be applied.
Which is to say, the outline is based on a 50% threshold, not a 1% threshold.
Comment 2 Sven Neumann 2008-03-10 12:53:56 UTC
Exactly, just like the selection outline.
Comment 3 weskaggs 2008-03-10 17:25:46 UTC
This has already been fixed in trunk.  In the 2.4 code, the healing tool operates on the full rectangle that contains the brush, not just on the masked part.  This is of course wrong, but I didn't backport the fix because it was rather complex for the stable branch, and the difference is generally pretty subtle.

This is a genuine bug in 2.4, so it is wrong to resolve it as INVALID.  The two correct options are either to backport the fix, or to resolve it as WONTFIX.
Comment 4 Sven Neumann 2008-03-11 07:56:34 UTC
If that is the case, then this needs to be fixed in the stable branch as well. I don't quite understand why this didn't happen in the first place. Bill, please attach your patch here for review.
Comment 5 weskaggs 2008-03-11 16:21:01 UTC
I am attaching the diff below, generated using viewcv.  As you can see, it is rather complex, and I was concerned that it might break something.  The whole point of the healing tool is to make changes that blend smoothly at the edges, so it takes a user with keen eyes to see that the edges aren't quite where they ought to be -- that's why I thought backporting it to the stable branch probably wasn't worth the risk at the time.
Comment 6 weskaggs 2008-03-11 16:23:55 UTC
Created attachment 107070 [details] [review]
patch for gimpheal.c, from rev 24324 of trunk

This patch also includes some code cleanup, and contains a bit of debugging code that is still present in trunk.
Comment 7 Sven Neumann 2008-03-11 21:02:38 UTC
I think this can go in without the debug code and without the unneeded definition of the GimpBrushCore variable (it's only used once, as far as I can see). If possible, the same changes should be done in trunk then.
Comment 8 Sven Neumann 2008-03-30 13:39:29 UTC
2008-03-30  Sven Neumann  <sven@gimp.org>

	Merged Bill's changes for bug #521433 from trunk with some minor
	cleanups:

	* app/paint/gimpbrushcore.[ch]: made
	gimp_brush_core_get_brush_mask() public.

	* app/paint/gimpheal.c: respect the brush mask.