GNOME Bugzilla – Bug 323921
add support for color jitter in the paint tools
Last modified: 2008-05-24 05:25:13 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/
You made the same typo again :)
heh, freudian slip perhaps ? ;->
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.
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.
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.
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.)
Created attachment 77000 [details] [review] patch to add "color" jitter to the paint tools
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.
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
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.
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
Created attachment 77184 [details] [review] patch for color jitter including some opacity support
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.
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.
The approach in this patch is obsolete as of the fix of bug #529431, and this in effect also OBSOLETEs the whole bug report.
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.
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.
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.