GNOME Bugzilla – Bug 703468
Brush from Clipboard: Imperfections painting with some dynamics
Last modified: 2018-05-24 13:45:15 UTC
In this example: http://nsae01.casimages.net/img/2013/07/01/130701034929273527.png I used the colored brush from clipboard that you can see in the image to paint, and Paintbrush tool with brush "Spacing=1". The problem is noticeable when is used a colored brush from clipboard. The imperfections that can be seen are the blue lines on the red strip, and the red lines on the blue strip. The problem occurs with Dynamics Off and some other dynamics. I am using GIMP 2.8.6 on Kubuntu Linux 64 bits.
Created attachment 248242 [details] forcy_dynamics_artefacts
Confirmed. Notes: It seem that turning on any type of Angle dynamics fixes problem but then Force dynamics introduce artefacts. [Attachment]
Created attachment 248304 [details] Clipboard brush with and without transparent edges Some interesting information to add: - If the clipboard brush contains transparent pixels around its edge, the behavior is correct. - The bug only occurs if the clipboard brush contains different colors on opposing sides. (In the original example note it only occurs along the top and bottom edges; in this example it occurs along all four sides.)
Created attachment 248305 [details] Only occurs with different colors along opposing edges of tbe brush. With this brush, note there are no problems with the blue, only the red/green and yellow/magenta portions of the edges experience any problems.
Created attachment 248431 [details] [review] proposed patch A patch to force the external edges of the clipboard image to be transparent. With angle dynamics it works better than enlarging the image. Please test.
I still don't quite get *why* this is happening. That a 1px transparent border will fix it seems quite obvious.
Off-by-one / Lookup issues that wrap around? I'm pretty sure this happens with same colors and transparent parts as well, and just isn't noticeable (anyone tried transparent edges with different colors for different edges?).
Yes but I don't see it in the code :)
I added a printf here: https://git.gnome.org/browse/gimp/tree/app/paint/gimpbrushcore.c?h=gimp-2-8#n1580 and offsety was -1 which becomes pixmap_mask->height - 1 here: https://git.gnome.org/browse/gimp/tree/app/paint/gimpbrushcore.c?h=gimp-2-8#n1621 after https://git.gnome.org/browse/gimp/tree/app/paint/gimpbrushcore.c?h=gimp-2-8#n1590 for y = 0
Indeed. And it's apparently not limited to clipboard brushes. I suggest we fix the bug here.
When looking at bug 166622, it seems like the "weird code" that is causing this was actually supposed to fix it.
I'm observing artifacts with an odd size brush (23x93) and (25x95), so the "weird code" is not relevant. BTW, it is possible to write it more succintly like this: ulx = ROUND (coords->x - 0.5 * pixmap_mask->width); uly = ROUND (coords->y - 0.5 * pixmap_mask->height); which is no longer weird. if ROUND(a) was defined as 'floor (a + 0.5)' it would be identical in gimp ROUND is ((int) ((x) + 0.5)) and so it is identical only for positive values of coords->x - 0.5 * pixmap_mask->width
Did we forget to push this fix, or is it incomplete?
(In reply to comment #13) > Did we forget to push this fix, or is it incomplete? It was rejected in comment #10 where mitch volounteered to fix the general bug. My thought was that brushes are designed and if designing them with a surrounding transparent rectangle make them work better it is a once fix, OTOH clipboard brushes must be fixed on the fly and so makes sense to special case them. The general problem is that if you want hard edges then even sized brushes should have their center mapped to the corner of a pixel whereas odd brushes should have the center mapped to the center of a pixel. Conciliate this two cases preserving hard edges would make the code a little more complex. I'm not volounteering.
I did do something about this, will have to dig in my stashes...
mitch, any chance you cam across that in your stashes?
Mitch?
Comment on attachment 248431 [details] [review] proposed patch see comment #14
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/480.