GNOME Bugzilla – Bug 166628
Gradient on Hue specific Hue adjustment
Last modified: 2008-06-14 08:29:55 UTC
When using Tools - Color Tools - Hue Saturation - Specific Hue selected (Red Magenta Blue Cyan, etc.) the engine seems to sharply define the cutoff if a pixel is "Red" or not (i.e. is the pixel's Hue in the range 60-120 Y/N?) A preferred method would be to apply a gradient so (for example) pixels whose hue is in the range 50-70 would be partially hue-lightness-saturation adjusted, apply 0% adjustment to pixels at 50, 50% adjustment at 60, and 100% adjustment for the range 70-110, then slope down, 75% at 115, 25% at 125, and 0 at 130. This would eliminate the "hard edges" apparent in photo images when adjusting a single color like CYAN. The gradient could be simple, fixed, linear - requiring no new UI, or you could go hog wild with user definable range of gradient, selectable interpolation schemes (linear, sinusoidal, cubic, whatever). I feel that the value of a simple fixed linear scheme is about 70% of a "full blown" adjustable scheme, for about 7% of the effort. I'll jump on implementing this one myself someday if noone beats me to it, but with two kids, a day job, an old house, active hobbies, etc. it could be many years before I get this round tuit.
Sounds like a reasonable suggestion. Would be nice if you could find the time to give it a try. Let us know if you need any help.
Created attachment 37274 [details] [review] Proposition to implement requested feature Whoooaaa.... Easily implementable core features. People should ask more enhancements like these. BTW - I could not think of a better string for the UI - But I do not like "Feather Hue Threshold" either. Maybe it could be just "hue threshold"?
I would vote for something like "Feather Primary Color Ranges".
"Feather Primary Color Ranges" or "Hue Boundary Gradient" both work for me.
I see the new patch, is this something I can patch onto my existing 2.0.4 (which I use because it's "certified amd64 ready by gentoo", or is it better to wait for a release to incorporate it?
It looks like it'll work on 2.0.4, but gentoo certainly does a huge disservice to their users by calling things "certified". There are a number of bugs in 2.0.4 that are fixed in later versions, including a couple 64-bit issues. So they're basically making stuff up and recommending people use a buggy version. Just upgrade to 2.2.3.
I've wondered just how thoroughly the gentoo folks "test" these apps on various platforms before "certifying" them ready. I suppose it varies depending on the maintainer (and their mood that week.) S'pose I should learn how to override the emerge settings now.... Thanks for the patch.
2005-03-12 Sven Neumann <sven@gimp.org> * app/base/hue-saturation.[ch] * app/tools/gimphuesaturationtool.[ch]: applied a patch from Joao S. O. Bueno Calligaris and modified it a little. This adds a way to control the overlap between hue ranges in the Hue Saturation tool (bug #166628).
OK, this has been closed for years, but I still don't see it in the latest releases??? Any idea when it will make it "out the door?"
As you can easily see by looking at the Target Milestone, this feature is in 2.4.
So it is (just checked 2.4.5) - sorry for the noise, I thought I had current versions everywhere, but the machine I was looking for this feature on was out of date.