Calculating the Hue of a Color as a 0 - 255 range - wpf

Question

I am trying to write a method which will work on WPF's Color struct to return a byte representing the Hue of the Color. I am struggling with the formula, I have written unit tests for the hues of Black (255, 255, 255), Red (255, 0, 0), Green (0, 255, 0), Blue (0, 0, 255), Yellow (255, 255, 0), Cyan (0, 255, 255), Magenta (255, 0, 255) and White (255, 255, 255) - they all pass except Yellow (which returns 1 instead of 42) and Magenta (which tries to return -1 instead of 212 but fails as -1 won't cast into a byte).
My extension methods for GetHue appear as follows:
public static byte GetHue(this Color color)
=> GetHue(color.ToRgbDictionary(), color.GetMinComponent(), color.GetMaxComponent());
private static byte GetHue(Dictionary<ColorComponent, byte> rgbDictionary, ColorComponent minimumRgbComponent, ColorComponent maximumRgbComponent)
{
decimal chroma = rgbDictionary[maximumRgbComponent] - rgbDictionary[minimumRgbComponent];
return (byte)
(
chroma == 0
? 0
: thirdOfByte
* (byte)maximumRgbComponent
+
(
rgbDictionary[MathHelper.Wrap(maximumRgbComponent + 1)]
- rgbDictionary[MathHelper.Wrap(maximumRgbComponent - 1)]
)
/ chroma
);
}
ToRgbDictionary simply turns the Color into a dictionary of its red, green and blue components; ColorComponent is an enum used as the key for those components. MathHelper.Wrap is a method which wraps an enum back into its declared range if it overflows or underflows. GetMinComponent and GetMaxComponent are two other extension methods on Color which return the first lowest and first highest ColorComponents of the Color (where the ColorComponent order is: Red, Green, Blue). thirdOfByte is a constant equal to the byte.MaxValue / 3.
I have based this formula on another I found here (http://www.blackwasp.co.uk/rgbhsl_2.aspx) which looks like this:
private decimal GetH(RGB rgb, decimal max, decimal chroma)
{
decimal h;
if (rgb.R == max)
h = ((rgb.G - rgb.B) / chroma);
else if (rgb.G == max)
h = ((rgb.B - rgb.R) / chroma) + 2M;
else
h = ((rgb.R - rgb.G) / chroma) + 4M;
return 60M * ((h + 6M) % 6M);
}
The problem with that formula is it's mapped to a 0 - 360 hue range, not a 0 - 255 range which is what I need. I'm not sure what the constant numbers in this formula do but I'm guessing the 60 has something to do with 360 / 3 = 120 hence my third of byte constant to try to do something similar. As for the 6Ms I have no idea where they come from nor why they are added to and modulused with the hue value at that stage. Could anyone with a mind for maths help me out here?
UPDATE
The reason for the 0 - 255 range was that I thought that was all that was required having seen it used in another piece of software (as shown) for Hue, Saturation and Lightness. It is also where I obtained the 42 Hue value for Yellow. I am now trying to find the correct range for Hues to cover all possible different hues in a 16777216 (256 * 256 * 256) colour range.

Answer 1

Your "...except Yellow (which returns 1 instead of 42)" what's the logic behind expecting a 42?
It's "mapped to a 0 - 360 hue range" because there are 360 hues in the colour wheel. Even if you had an unsigned byte (holding 256 values), you'd be cropping off the other 104 possible hues. It won't be an accurate representation.
Why not just use a 2-byte short to hold the possible 360 hues instead of using 1 byte?
If you still want to fit 360 inside a 255 range, just do simple math :
byte_value = hue_value / (360/255); //where hue_value is the 0-360 amount.
Try involving Math methods like Math.round to get none fractions as final byte value.
Example 180 hue :
byte_value = Math.round( 180 / (360/255) ); //gives 127