GNOME Bugzilla – Bug 123811
Tablet and pressure with a small brush leaves behind 'marks'
Last modified: 2004-05-21 15:25:16 UTC
When using tablet and pressure with opacity a small brush leaves behind 'marks'. At the end of the stroke it sometimes leaves behind a mark of a full opacity stroke (usually a strange '+' or square shape). This seems to only be noticable when using a small brush shape (3x3 or less) and with only opacity and/or hardness checked. If size pressure is checked then it doesn't seem to happen. This is most noticable when rapidly drawing many short vertical lines with not much pressure. Imagine cross-hatching to shade something in with many small lines next to each other. This problem also exists in the old stable 1.2.5 GIMP.
I can confirm this with my wacom Intuos2. I'll attach a screen shot. Someone else needs to change the state to NEW.
Created attachment 21746 [details] xcf of the brush mark problem. I thought this was cased by a jump in the brush pressure at the end of my stroke, but the mark is not brush shaped (using a 3x3 fuzzy brush)
Created attachment 24785 [details] example of artifacts created at low pressure
This bug is also present in GIMP 1.2.x and 2.0. It's a *major* showstopper for me, I have to multiboot and use Windows sw for my tablet work while this bug is still present. Is anyone working on fixing it ? (I'd do it myself if I had the time...)
I, too, can confirm this; I am using GIMP 2.0.1 with a Wacom Intuos 2 tablet (though I know it to occur with other tablets as well). I would reccomend that its priority be switched to high, as it is a very troublesome bug, and keeps myself (and some others I know) from being able to complete our work very easily. It has been around for a long time.. it does not make sense that it has not been fixed yet, when it is so critical. A few notes: this also happens with the eraser tool under the same settings, so I assume it comes from some property shared between them. It does not effect the airbrush. One can avoid the bug by turning off opacity while using the paintbrush/eraser with small brushes, but this eliminates much usefulness, and shouldn't be necessary anyway. I am submitting a much better example of the bug (produced by Ingo Ruhnke, not myself) for viewing as well. I hope this helps and that this bug is fixed soon.
Created attachment 27654 [details] Small paintbrush marks made with tablet These marks were made by using the paintbrush tool with one of the smaller brushes and opacity pressure sensitivity enabled, performed on an Intuos 2 (Wacom) tablet.
Of course you can request the priority of this bug report to be raised but that won't change the fact that someone needs to sit down and spend some of his/her free time on investigating this problem. Obviously none of the developers is willing to put work into this, probably because they aren't using tablets. I am not sure how this could be changed. Perhaps if someone offered a nice Intuos2 tablet for the GIMP developer that fixes the tablet problems...
I believe I've found the source of the the bug. It would seem that this hasn't even been looked into (probably due to the lack of tablet-owning developers), because it took me about 10 minutes to locate it after never having touched the GIMP code before. That's surprising, considering how long this bug has been around. Anyway, what I found: I inserted some code to monitor the pressure and opacity while making brushstrokes and I noticed that the pressure (and therefore the opacity) went negative when the artifacts appeared. Putting the following into app/paint/gimppaintbrush.c removes the artifacts: if (pressure_options->opacity) { opacity *= 2.0 * paint_core->cur_coords.pressure; if(opacity < 0.0) opacity = 0.0; } but of course the proper solution would be to keep the pressure from going negative before it even reaches this point in the code. Looking at app/paint/paint_tools_cmds.c it seems like that is being done for other tools such as the airbrush, but not the paintbrush and eraser. It's not clear to me how to implement this because I'm not familiar with the code, so hopefully one of the developers will read this and fix it.
Setting milestone to 2.0.2 so this is being looked at.
Created attachment 27798 [details] [review] clamp pressure in gimp_paint_core_paint This patch clamps pressure to 0.0 - 1.0 before it is passed to a paint tool's paint function. This is possibly a bit far down the chain but I didn't have much luck finding a better spot for it.
The code in app/pdb/paint_tools_cmds.c is not used when painting interactively. It only assures that the values passed from the PDB are valid. The point here is that we do clamp the values already in app/display/gimpdisplayshell-callbacks.c:gimp_display_shell_get_event_coords() so I wonder how negative values can ever reach the paint core. We should try to find out why this happens.
Created attachment 27817 [details] [review] negative check in gimp_paint_core_interpolate I tracked down the negative pressure - it's the result of some inaccuracy in gimp_paint_core_interpolate. I tried a number of solutions, but this is the only one that didn't produce undesirable effects. I think the only other solution would be to modify the spacing formulas.
Created attachment 27823 [details] [review] linearly interpolate pressure, tilt, wheel I think maybe I am too eager to submit patches. :x After reexamining the spacing algorithm, it occurred to me that it was only relevant to position, and that pressure, tilt and wheel should be interpolated linearly without any special treatment. I believe that was the problem.
Now fixed in CVS, both stable and development branch. Thanks a lot for you help with this problem. 2004-05-19 Sven Neumann <sven@gimp.org> * app/paint/gimppaintcore.c (gimp_paint_core_interpolate): make sure that pressure never becomes negative. Fixes bug #123811; thanks to Philip Lafleur for investigating this problem.
Uhm, your new patch came after I applied the other fix. Your new patch seems to make sense to me. I suggest that we apply it to the development branch only. What do you think?
hm... sorry about that. You must have applied it some time before you posted here? I'm not entirely clear on why you want to put this only in development. I'm pretty confident that using the spacing algorithm to interpolate pressure data is what was causing the negative pressure, especially when considering that it it might be intentionally done to the positional data in order to get brush marks in good-looking spots. The visual difference between the two patches is fairly small, though, so I doubt it will matter much to the user which one you use.
but to answer your question: I'd rather see it fixed properly in both versions. If you're unsure about the validity of the fix, I can only tell you that it makes the brush strokes look like they should, and I can't imagine any problems arising from it.
I've applied your improved patch to both branches: 2004-05-21 Sven Neumann <sven@gimp.org> * app/paint/gimppaintcore.c (gimp_paint_core_interpolate): better fix for bug #123811; patch provided by Philip Lafleur.