GNOME Bugzilla – Bug 527085
Hue/Saturation (working improperly)
Last modified: 2012-06-01 16:05:08 UTC
This bug pertains to adjusting an image in GIMP using the Hue-Saturation module (adjusting a specific color... not the master). When you adjust the hue, it seems the overlap works correctly in only one direction. E.g., if you're increasing the hue of the Red's the overlap looks correct counter-clockwise, however, incorrect clockwise... And if you decrease the hue, the opposite happens. It's hard to notice the bug when running the filter on a regular image, but if using an image composed of the entire spectrum -- you start to notice a difference! Photoshop seems to handle this color wrapping properly.
Created attachment 108910 [details] Original Image
Created attachment 108911 [details] GIMP (w/ 50% overlap, and -30 hue shift to the reds)
Created attachment 108912 [details] Photoshop (w/ 50% overlap, and -30 hue shift to the reds)
This does indeed look like a bug in our code.
Created attachment 109459 [details] [review] find nearest hue when overlap
The bug exists also in 2.5 with normal code and GEGL code. I've made a patch (above) for current svn version for normal code. The correction is done when two hue are mixed. Instead of making it linearly, it checks what is the shortest path on the hue circle and adapt value to choose this path. I hope this is what is expected.
Just tested the code you submitted, and am happy to say, it works perfectly now! Thank you :)
So, how does this go about being added to the latest build?
Looks reasonable, will try this and apply the same to the gegl operation if it's correct. And Michael, there is no reason to push us. I was in fact writing this comment while I didn't see yours yet.
Why did you close this bug as FIXED? Reopening.
Sorry, I'll be sure to read the bugzilla manual more thoroughly. Just trying to become more involved, perhaps a bit over eager. I put a few hours into attempting to crack the bug, so was happy to find someone else had figured out the solution.
Bugs do get resolved as fixed if the code that fixed them has been committed to the subversion repository.
I have committed this change to both branches: 2008-04-28 Sven Neumann <sven@gimp.org> * app/base/hue-saturation.c (hue_saturation): applied patch from Michael Deal that fixes use of the overlap option (bug #527085). Leaving open as we still need to correct the GEGL code path.
Moving this to the 2.6 milestone as the problem has been addressed in gimp-2-4.
Created attachment 118147 [details] [review] gimp-gegl-hue-saturation-fix-2008-09-06.patch For reference, here is the patch I commited with the fix ported to the GEGL operation.
2008-09-06 Martin Nordholts <martinn@svn.gnome.org> Bug 527085 – Hue/Saturation (working improperly) * app/gegl/gimpoperationhuesaturation.c (gimp_operation_hue_saturation_process): Properly map the secondary hue. Based on patch by Michael Deal.
I have discovered some cases where the patch actually causes the tool to operate incorrectly. Take adjustments of: - Cyan: Hue + 120º - Blue: Hue - 120º - Overlap: 100% This is a 240º difference between the two channels (hue and secondary_hue), making it appear to be the "long way" around the HSV circle, but it's actually NOT: - Cyan + 120º = Magenta - Blue - 120º = Green - Actual difference: 120º The overlap region should show a magenta-blue-cyan-green gradient in this case, but GIMP actually paints it with a magenta-red-yellow-green gradient instead. Whoops! Alternate example: - Cyan: Hue + 180º - Blue: Hue - 90º - Overlap: 100% Slowly adjust the Blue channel all the way down to -180º and note a sudden appearance of an HSV band in the blue-magenta range that shouldn't even be there. Adjust the Blue channel back to 0 and note a sudden appearance of an HSV band in the cyan-blue range. I can't think of any actual cases where these would occur "in the wild", but they can be made to occur in theory and the sudden manner in which it occurs strongly implies it's incorrect. See also bug #644032, which might be related but is alive and well in the 2.8 release.