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 323921 - add support for color jitter in the paint tools
add support for color jitter in the paint tools
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: Tools
git master
Other All
: Normal enhancement
: 2.6
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2005-12-12 20:13 UTC by Adrian Likins
Modified: 2008-05-24 05:25 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch to add "color" jitter to the paint tools (18.21 KB, patch)
2006-11-21 22:57 UTC, Adrian Likins
none Details | Review
patch to add "color" jitter to the paint tools (using GRand this time) (18.25 KB, patch)
2006-11-22 02:45 UTC, Adrian Likins
none Details | Review
add color jitter support with GRand in gimpbrush core (17.65 KB, patch)
2006-11-22 20:21 UTC, Adrian Likins
none Details | Review
patch for color jitter against latest cvs with committed GRand/brushcore changes (15.33 KB, patch)
2006-11-22 20:34 UTC, Adrian Likins
none Details | Review
patch for color jitter including some opacity support (18.62 KB, patch)
2006-11-27 01:58 UTC, Adrian Likins
needs-work Details | Review
gimp-color-jitter-2008-04-13.patch (12.25 KB, patch)
2008-04-13 12:08 UTC, Martin Nordholts
none Details | Review

Description Adrian Likins 2005-12-12 20:13:52 UTC
Add support for jittering, or randomizing the current foreground color as
used in the paint tools, for an artistic effect. 

Patch, screenshot, and some example images available at
http://adrian.gimp.org/patches/gimp-color-jitter/
Comment 1 Michael Schumacher 2005-12-12 20:26:08 UTC
You made the same typo again :)
Comment 2 Adrian Likins 2005-12-12 21:29:58 UTC
heh, freudian slip perhaps ? ;->
Comment 3 david gowers 2006-01-26 07:22:53 UTC
This is mostly good. I love the effect it gives when it does work.

* The smudge ought to max at 0.999999. Pencil and Paintbrush merely put a single brush dab down and nothing else when smudge strength >= 1.0. 

* The initial brushstroke is maxed in opacity. This is wrong for airbrush and just plain looks weird. 

* maybe smudge should be named smear. It's a bit confusing to have an 'apply smudge' option in the options for the smudge tool.

* Some context doesn't match HEAD (mainly, #includes and PROP_*) so I had to apply some hunks manually.
Comment 4 Michael Schumacher 2006-01-26 09:37:37 UTC
AFAIK the smudge part isn't intended to be part of this patch, Adrian said that several patches were combined. We should try to seperate the two features, tracking both in one report will get messy.
Comment 5 Adrian Likins 2006-01-27 18:00:04 UTC
yeah, smudge is meant to be a seperate patch, though I appreciate the feedback on the smudge part as well ;-> Theres also a seperate bug for smudge at bug #163050

If these patches look interesting, I can put up split patches. 
Comment 6 david gowers 2006-02-04 08:46:35 UTC
A serious problem that i noticed later is that 'incremental' is always on (even when the 'incremental' checkbox is unchecked and nothing else is checked.). This should only be forced on when color-jitter is enabled (and maybe when smudge is enabled; i haven't checked its internal workings.)
Comment 7 Adrian Likins 2006-11-21 22:57:47 UTC
Created attachment 77000 [details] [review]
patch to add "color" jitter to the paint tools
Comment 8 Adrian Likins 2006-11-21 22:58:52 UTC
The above attachment is a new version of the patch, against cvs HEAD from today. It should be just the color jitter bits and the "incremental always on" should be fixed.
Comment 9 Adrian Likins 2006-11-22 02:45:13 UTC
Created attachment 77007 [details] [review]
patch to add "color" jitter to the paint tools (using GRand this time)

g_random_get_range() useage remove
also unused use_randome_color remove 

based on suggestions from mitch
Comment 10 Adrian Likins 2006-11-22 20:21:30 UTC
Created attachment 77037 [details] [review]
add color jitter support with GRand in gimpbrush core

latest color jitter, this time with GRand in gimpbrushcore, so it may overlap slightly with attachement #77035 for bug #377891. Also got rid of the get_sat, etc accessors since they didn't really seem necessary.
Comment 11 Adrian Likins 2006-11-22 20:34:31 UTC
Created attachment 77038 [details] [review]
patch for color jitter against latest cvs with committed GRand/brushcore changes

fix to the use the committed version of the GRand/brushcore addition
Comment 12 Adrian Likins 2006-11-27 01:58:13 UTC
Created attachment 77184 [details] [review]
patch for color jitter including some opacity support
Comment 13 Martin Nordholts 2008-03-30 10:26:04 UTC
This is very nice functionality to have and I think we should consider this for 2.6. The patch seems to work nicely (after some changes to make it apply on current SVN trunk) but I think it would make sense to gather all jittering options, including the color jittering options, under the 'Apply Jitter' expandable frame rather than having a separate 'Apply Color Jitter' frame.

Also the patch had quite some code style issues, like making use of the TAB-character and misaligned variables, defines, and function prototypes.
Comment 14 Martin Nordholts 2008-04-13 12:08:52 UTC
Created attachment 109165 [details] [review]
gimp-color-jitter-2008-04-13.patch

Here is a patch where the color jitter and jitter options have been merged. Still needs work, mostly cleanups.
Comment 15 Martin Nordholts 2008-05-22 16:57:25 UTC
The approach in this patch is obsolete as of the fix of bug #529431, and this in effect also OBSOLETEs the whole bug report.
Comment 16 david gowers 2008-05-23 00:52:25 UTC
I have to say, there is still a need for something like this.
I've just tried out the new dynamics and found that 
 a) the random color selection selects random samples of the current gradient, rather than producing variations of the drawing color. Gradient sampling seems a useful option, but IMO not as useful as normal color jitter.
 b) amount of randomness is not controllable (which is particularly significant in the case of size.)

Of course, it is still work in progress, and what hs been achieved is great. 
I just don't agree that this bug report is obsolete. The patches are, that's all.
I think the next step would be curve editing for defining the exact response to each of those dynamics variables, and then the active dynamics could sample from that curve and average the results to achieve the final eg. size used.

I was going to say that checking 'Use color from Gradient' could be considered as a toggle between gradient sampling position randomization and color randomization, but I see that toggling that on means that randomization is instead applied relative to the gradient sampling that would be produced by the 'Use color from Gradient'. So I don't know what to say about that.
Comment 17 Alexia Death 2008-05-23 16:20:52 UTC
You can set any range to the gradient. if you set it to FG->BG and set your FG and BG colors to exact variations you need you can have what you what and more with much more flexible options than any "color jitter" could offer.(Ie there are some color mode gradients that IIRC let you have the whole color range for random to pick from)

The curves are planned but will hardly be available by 2.6 I will however be adding a set of sliders to tone down each of the effects.

about your wish to mix random with the iterated gradient position... I will have to think/talk about that. the only sane way I see to do that is to make the iterator another dynamic just like random is... but I'm not sure if others will approve of a simply iterative dynamic. Tho it could be useful along with ie a sine dynamic.
Comment 18 david gowers 2008-05-24 05:25:13 UTC
I did wish to draw with random variations of the FG color, as in Adrian's patch.

I don't wish to mix random with the iterated gradient position AFAIK.. I was saying that is already what happens when you check the 'Use Color from Gradient' option if random color dynamics is also enabled; The position in the gradient is randomly perturbed while maintaining an overall iteration from start to end of the gradient. (unless I misunderstood you?). 

IMO it would be more useful if:
 1. Random color dynamics by itself, draws with colors randomly chosen from the range FG..BG
 2. Random color dynamics in conjunction with 'Use Color from Gradient', picks colors from the currently selected gradient (ie. the way it currently behaves when 'random->Color' is checked and 'Use color from gradient' is not.)
 3. This matches the existing behaviour of the 'Pressure -> Color' checkbox, 
    and velocity could be adjusted to match. If Pressure -> Color doesn't work like that anymore, then you have accidentally changed it.