GNOME Bugzilla – Bug 163050
paint tools should support "smudging" as they paint.
Last modified: 2018-05-24 11:21:34 UTC
The idea for this RFE is to allow paint tools to "smudge" there brush strokes to allow a more realistic result. Ideally, this would allow the stroke to both paint normally, and "smudge" at the same time. I have a rough patch that allows paintbrush to paint on the first _motion() and then smudge on the rest. The result is a somewhat more interesting and realistic stroke than simply using a brush with a very low spacing. http://adrian.gimp.org/patches/gimp-smudge-brush/ has some example images of the prototype
the contents of the PATCH_STATUS file from above, just for completeness. just a prototype proof of concept. The idea is to paint a small dab of paint, then "smudge" it for the rest of the stroke. Proof of concept just does one dab of paint, then the rest smudges. Current issues include some weird artifacts from the "blend" (aka, paint-smudgeing white on a white image produces grey artifacts along the stroke). See gimp-brush-smudge-3.png for an example. useage with a tablet is totally horked for reasons I don't completely understand. One of the issues is the first "dab" might be scaled very small, etc. The code to do this is kind of ugly, but its a start. The smudge accumulating buffer probably needs to moved into GimpBrushCore. There seems to be a need for a seperate "spacing" value for the brush strokes and and the "smudge" strokes. We need some way to do the first few "dabs" then smear. Then do some more dabs. Also some concept of continuing to paint, while smudging is needed.
The pictures look cool. Is there some code for this that could go into cvs?
re comment#2 There is code, but it's horrible proof-of-concept code. I'll try to dig it up anyway.
theres a patch at http://adrian.gimp.org/patches/gimp-smudge-brush/gimp-smudge-paint-cvs.diff
Created attachment 77015 [details] [review] patch to add "smudge" support to paint tools against current cvs This is a patch against current cvs to add "smudge" support to the general paint tools. This should also adress some of the issues mentioned in comment #3 on bug #323921 (initial opacity being wrong, and should apply clean). Max value should be 99just wanted a clean patch for people to try out .9 now (though, that looks a bit odd in the ui). Initial value is set at 50. A few notes about the patch. It works best with brushes that have the spacing set to a low value (ditto for smudge in general). The best effects seem to come from pixmap brushes. Usually smudge value in the 50-90 range work best. "Pepper" brush with spacing set in the 1-5 range works good for an example.
Actually, on second look, it still make airbrush look a bit weird. I was setting the initial opacity based on brush context, it should probably be using the opacity straight from the brush core. But I need sleep now ;->
It makes every paint tool look a bit weird actually.. The following behaviour seems to be present: If opacity is < 100%, then apply paint to itself incrementally with 'normal' mode in the paint buffer, regardless of whether smudge or any other settings are active. This causes a number of problems. * The opacity of a paint stroke will be reduced (drawing with normal mode, pencil tool, 50% opacity with #000000 fgcolor on #ffffff bgcolor in one continuous stroke produces #c0c0c0 resultant color at 'solidest' points, where it should produce #808080 or possibly #7f7f7f) Note, this effect is easily formulated -- the opacity at solidest points is (master opacity * master opacity) -- so in this case 25% opacity results. * Extra colors are added. in the case of the pencil tool which is supposed to be hard edged, drawing without pressure sensitivity on a single color area should add at most one color; in my tests it has added up to 8, none of which are the right ones. Maybe that will help you work out something. It sounds related to your last comment (actually, hmm. yes. Brush core opacity should always be 100% when un-modulated by pressure, which would fix this. Time to go poking around and test this. argh, it baffles me. How can I get the paint core opacity?!)
I made a simple change to use the brush core opacity instead of hard coding to 100%, and it seems to behave better. I also set it up so the initial dab of paint that gets smudged is only done if smudge is enabled. This seems to have been what was causing airbrush to look weird (there was an extra dab at full brush core opacity that wasn't needed). It might be possible to make clone also support smudge, which could be cool. But my first try is segfaulting atm, so need to revisit that.
Created attachment 77519 [details] [review] patch to add smudge support (fixes some airbrush issues) fix opacity of initial color dab don't apply a redundant dab in the case of non-smudge (makes airbrush look odd)
Adrian your efforts are very much appreciated, but recent events is causing me to suggest closing this as WONTFIX and instead concentrate on getting equivalent functionality using the approach in Bug #522226 – PaintBrush extension framework Any objections?
Not before we haven't made a decision on bug #522226. So far this approach hasn't been extensively reviewed nor discussed. I don't think we should treat it as accepted yet. I have several strong objections against the approach taken in bug #522226.
Created attachment 109529 [details] [review] gimp-smudge-paint-2008-04-19.diff Here is a the above patch but modified to apply to current SVN trunk. It still needs work, for example it looks weird if one paints with a black Circle(11) using the Paintbrush Tool on white background, with a Smudge amount of 99.90.
-- 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/114.