After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 163061 - "use color from gradient" should support using just hue/sat/value/etc
"use color from gradient" should support using just hue/sat/value/etc
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: General
git master
Other All
: Low enhancement
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2005-01-05 21:04 UTC by Adrian Likins
Modified: 2018-05-24 11:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
example of changes (16.95 KB, image/png)
2007-12-13 04:25 UTC, david gowers
Details

Description Adrian Likins 2005-01-05 21:04:49 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.
Comment 1 weskaggs 2005-02-25 19:06:56 UTC
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.
Comment 2 david gowers 2006-11-27 02:36:27 UTC
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.
Comment 3 weskaggs 2007-12-13 02:44:44 UTC
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?
Comment 4 david gowers 2007-12-13 04:18:33 UTC
"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.
Comment 5 david gowers 2007-12-13 04:25:27 UTC
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.
Comment 6 Joao S. O. Bueno 2007-12-14 12:31:43 UTC
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.

Comment 7 david gowers 2007-12-14 13:00:35 UTC
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.

Comment 8 GNOME Infrastructure Team 2018-05-24 11:22:00 UTC
-- 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.