I have a few questions/concerns about the Hue-Saturation tool because I've encountered a few very-specific cases where it simply does not work properly.

The first one I have filed as bug #644032 - "Color banding in Hue-Saturation tool with overlap" but have yet to receive any response.

https://bugzilla.gnome.org/show_bug.cgi?id=644032

Does anyone else (both on Windows and Linux builds) experience this? Take the attached test image as an example and go to the Hue-Saturation tool. Set an Overlap of 100% and adjust the Magenta channel hue by +60º. Everything from Magenta from Red should now be solid red, but when I attempt this I get a full HSV gradient instead, like it's cycling the wrong way across the HSV wheel.

The oddest part is that this is NOT bug #527088 -- that one was fixed years ago. Slowly adjust the Magenta Hue value and watch how the color bands just pop in and out -- at +20º, for example, there's a very sharp-edged switch from red-magenta (correct) to cyan-green (incorrect) and I can't explain how exactly that occurs. I've evev looked through the source code in the GNOME repository (gimpoperationhuesaturation.c) and can't locate anything that apparently might be causing it.

I originally encountered this one "in the wild" when I simply wanted to make a minor adjustment to an image containing pink (magenta-red) pixels that I felt were too "cold". Imagine my surprise when the Hue-Saturation tool yielded blues and cyans!

Now for the second bug - reset the Hue-Saturation tool. Set an Overlap of 100%, this time adjust the Cyan channel hue by +90º and the Blue channel hue by -90º (with 100% overlap). Everything looks fine, right? BUT shift the Blue channel a little more (to -100) and note the very sudden appearance of a full HSV band between the hues. Why? Because it just passed the half-circle threshold, causing GIMP to calculate the overlap regions the opposite direction around the HSV circle. This was specifically caused by the patch to #527088, where after calculating the primary and secondary hues, GIMP picks the "shortest distance on the circle". Which was necessary to compensate for magenta/red wraparound, but it breaks down in extreme cases. It's conceptually possible that the adjustments made to adjacent channels DO represent the "long way" around the HSV circle, and if that's the case we don't want GIMP to pick the "shortest" route -- but it does.

There may be another way to perform the hue calculations that preserves the fixed status of bug #527088 and possibly fixes #644032, let me know if this thinking is correct:

Currently, when performing a hue-saturation adjustment with overlap GIMP calculates the final hue by interpolating the results from both of the neighbboring Channels adjusted independently. I.e: (primary_hue) * (primary_intensity) + (secondary_hue * secondary_intensity), (given: primary_intensity + secondary_intensity = 1).

Also, Hue adjustment is a simple function of (mapped_hue = original_hue + hue_adjustment), with hue_adjustment including both the Master and given ranges. This means that algebraically, we could reorganize the hue calculation as follows:

final_hue = (primary_hue * primary_intensity) + (secondary_hue * secondary_intensity) = (original_hue + primary_hue_adjustment) * primary_intensity + (original_hue + secondary_hue_adjustment) * secondary_intensity = original_hue * (primary_intensity + secondary_intensity) + primary_hue_adjustment * primary_intensity + secondary_hue_adjustment * secondary_intensity = original_hue + (primary_hue_adjustment * primary_intensity) + (secondary_hue_adjusment * secondary_intensity)

Correct? Instead of calculating each channel individually and interpolating the result (because either channel could cross the red/magenta threshold and there is no easy way to predict whether or not one did), we essentially interpolate the adjustment that the current pixel shall receive.

-- Stratadrake strata_ranger@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth.