GNOME Bugzilla – Bug 771020
Square artifacts using Clipboard feature to paint tools
Last modified: 2017-04-12 19:05:59 UTC
Created attachment 335015 [details] test clipboard feature on paintbrush with white canvas When we use the clipboard feature in the some paint tools, as paintbrush and airbrush, these are producing black artifacts around the border. I have tested 'pencil' and 'clone' and these are working without these artifacts.
Created attachment 335016 [details] test clipboard feature on paintbrush with transparent canvas
Created attachment 335017 [details] test clipboard feature to paint tools (artifacts on paintbrush and airbrush)
Created attachment 335129 [details] Square artifacts and relationship with Angle Parameter (Paint Dynamics) Redoing the tests, I have found that the 'Angle' parameter is causing the artifacts.
Does this happen only with master? If it's present also in gimp-2.8, it could be the same reported here: https://bugzilla.gnome.org/show_bug.cgi?id=703468
(In reply to Massimo from comment #4) > Does this happen only with master? If it's present also in > gimp-2.8, it could be the same reported here: > > https://bugzilla.gnome.org/show_bug.cgi?id=703468 Only in Git master. This bug (https://bugzilla.gnome.org/show_bug.cgi?id=70346) is the same. I have tested on gimp 2.8.18 but I don't have had success... was it fixed there?
I don't think the bug you linked is the same.
(In reply to jose americo gobbo from comment #5) > (In reply to Massimo from comment #4) > > Does this happen only with master? If it's present also in > > gimp-2.8, it could be the same reported here: > > > > https://bugzilla.gnome.org/show_bug.cgi?id=703468 > > Only in Git master. This bug > (https://bugzilla.gnome.org/show_bug.cgi?id=70346) is the same. > I have tested on gimp 2.8.18 but I don't have had success... was it fixed > there? So, bug 703468 is still present both in master and gimp-2.8 This 'bug' is present only in master. In master there is a new "force" paint option slider, setting its value to zero brings back gimp-2.8 behaviour. https://git.gnome.org/browse/gimp/tree/app/paint/gimppaintoptions.c#n954 The problem seems to be that when "force" > 0.0 the brush mask is pressurized, which among other things means it is subsampled (resampled with sub-pixel offset), but not its pixmap. This means one side of the brush is sub-pixel cropped and the opposite is sub-pixel extended where the transformed pixmap was filled with black. I don't know what's the meaning of the brush force, so I can't say if it is working as intended or not.
(In reply to Massimo from comment #7) > I don't know what's the meaning of the brush force, so I can't say > if it is working as intended or not. I understood that the 'Force' parameter main scope is be as gain factor curve over single input parameter. If is zero on disable, in theory, the curve is constant=0. If > 0, is used the curve of each Force x Input.
(In reply to jose americo gobbo from comment #8) > (In reply to Massimo from comment #7) > > I don't know what's the meaning of the brush force, so I can't say > > if it is working as intended or not. > > I understood that the 'Force' parameter main scope is be as gain factor > curve over single input parameter. If is zero on disable, in theory, the > curve is constant=0. If > 0, is used the curve of each Force x Input. See also this bug report about Force parameter and relation with Paint Dynamics Curves. https://bugzilla.gnome.org/show_bug.cgi?id=748060 So, I understand that the Force slider on Tool Options must be independent, if you have or not enabled the Force parameter on the Paint Dynamics. Now, if you modify the values on this slider it not produces any variation on the strokes. For instance, already, if you test the Hardness slider, this slider is working correctly... if you not have this parameter enabled on paint dynamic... the slider works as discrete control -- I have tested now with a soft brush... 0 => Original stain stroke; 1 => hardest brush.
(In reply to jose americo gobbo from comment #9) > See also this bug report about Force parameter and relation with Paint > Dynamics Curves. > > https://bugzilla.gnome.org/show_bug.cgi?id=748060 > > So, I understand that the Force slider on Tool Options must be independent, > if you have or not enabled the Force parameter on the Paint Dynamics. > Now, if you modify the values on this slider it not produces any variation > on the strokes. > > For instance, already, if you test the Hardness slider, this slider is > working correctly... if you not have this parameter enabled on paint > dynamic... the slider works as discrete control -- I have tested now with a > soft brush... 0 => Original stain stroke; 1 => hardest brush. The odd behavior is that the Force slider don't working for its scope but is producing this effect that you has related here: "The problem seems to be that when "force" > 0.0 the brush mask is pressurized, which among other things means it is subsampled (resampled with sub-pixel offset), but not its pixmap. This means one side of the brush is sub-pixel cropped and the opposite is sub-pixel extended where the transformed pixmap was filled with black."
Created attachment 346688 [details] Force Slider parameter on Tool Options - no dyna | artifacts When you have no paint dynamics and you use Tool Options Force Parameter > O the artifacts are visible. In my test I have used zero (no) and 100 (visible).
Created attachment 346689 [details] Force Slider of Tool Options with dyna | Artifacts When we have a dynamics on, with Force x Pressure (linear), the artifacts are always present (with Force = 0 or Force = 100).
This isn't fixed yet to to bug 764619, is it?
Created attachment 346947 [details] testing the clipboard brush with different layers Isn't fixed yet, apparently the bug 764619 doesn't have relation with this bug. I have verified again on the GIMP commit 58e5f38 and the bug is present yet. I have made another test using the clipboard in different kind layers: [1] sample-layer-no-alpha-white; [2] sample-with-alpha-white; [3] sample-transparent. So, to layers with background color, as white, the bug is present [1] and [2]. When you copy a sample in the transparent layer the bug is not present [3].
(In reply to jose americo gobbo from comment #14) > Created attachment 346947 [details] > testing the clipboard brush with different layers A reminder: the attachment 346947 [details] was made without dynamics.
The bug is resolved in the my last git master commit 0a42c6b. I am not sure, but the Ell commit fix the bug. https://bugzilla.gnome.org/show_bug.cgi?id=780950#c18 commit d4bb12d8b89e30e3f1cdfbe6fba16383a21fd93d Author: Ell <ell_se@yahoo.com> Date: Mon Apr 10 09:41:10 2017 -0400 See also Massimo comment: https://bugzilla.gnome.org/show_bug.cgi?id=771020#c7
Then we should resolve this as a duplicate. *** This bug has been marked as a duplicate of bug 780950 ***