GNOME Bugzilla – Bug 163061
"use color from gradient" should support using just hue/sat/value/etc
Last modified: 2018-05-24 11:22:00 UTC
The paint tools can currently use a color from a gradient. However, at the moment, the exact color is used. It could be useful to allow hue/value/sat of the color in the gradient to be used in combo with whatever color the brush would normal be used. An example would be say, a pixmap brush of a rose. Since it's a pixmap, it's a single color, or the color from the gradient is applied to the brush mask and the original brush pixmap is ignore. Being able to apply the hue from the gradient to the value of the pixmap could allow a powerful way to humanize brush strokes.
It seems to me that a better approach would be to create a few new "virtual gradients", making use of the foreground and background colors but varying them in different ways. That way the paint tools themselves would not have to change.
You have misunderstood adrian's idea. No matter what gradients are used, the paint tools would have to change. "Being able to apply the hue from the gradient to the value of the pixmap could allow a powerful way to humanize brush strokes." -> the individual values of each pixel in the source pixmap. Like filling using 'hue' paint mode on the brush pixmap before applying it. The 'use color from gradient' merely discards the color information from the pixmap entirely, and uses only the alpha channel; it is not in any way comparable.
This bug report has been unconfirmed for too long. I am going to confirm it on the assumption that it is asking for new types of virtual gradients, as described in comment #2. If it is asking for something else, as comment #2 implies, I am completely unable to make sense of it. If somebody thinks so, could you please try to provide an example of what a brushstroke using this functionality might look like?
"and the original brush pixmap is ignore" is the key phrase here. When you select 'use color from gradient', the pixel data from the pixmap is discarded; Only the alpha channel is used (as a mask for applying the color at a given point in the gradient). Adrian's proposition would change things so, for pixmap brushes/brushpipes (the only type of brush that includes color info), one or more of the hue/saturation/value of the brush is also respected, with the remaining components taken from the gradients. I'll make an example.
Created attachment 100864 [details] example of changes Includes a comparison of old and new intended behaviours. The user has a choice to individually control whether the hue, saturation, or value of the color from the gradient is applied to the brush pixmap. All but one of the examples are done simply by applying hue, saturation, or value mode (sometimes in combination) to the pixmap. The bottom-left example shows something I decided while making this image -- an opacity control for each of (h,s,v) is more useful than just an on/off toggle, so I used 50% opacity to apply the color changes in the bottom-left example. I hope this helps you understand.
Got the idea. The thigns I want to put in place for bug #119240 would offer the UI and much of the structure for this. My idea there is allow the creation, for each brush pre-set of a curve associated with two variables. The bug request there asks for things like opacity or speed vs size or color. To imnplement the option "brush alpha" gvs "gradient <component>" would have to be avaliable on the configuration there. Adrian - are you around? Meanwhile some python scripts could be written to create new gradient mapped brushes with a few keystrokes.
I believe you have mostly understood; however, the curve in question would be "pressure"/"time" vs "gradient <component>" -- The proposition here only effects the color, not the alpha (though gradients provide alpha information too, that could be used as well.). The issue is that currently, only the alpha channel is respected for pixmap brushes being colorized using 'color from gradient' (and/or the 'color' pressure-sensitivity option), and ... control over which color components are effected and how much they are effected, would improve flexibility in a very natural way.
-- 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/116.