Please add Color conversion/manipulation tool

[mkalex777]

I think it will be useful to have color conversion and manipulation tool.
For example I need to change brightness of color, so I'm converting it to HSV format then change Value component and then converting back. I think it will be better to have standard class for such operations.

here is my code for HSV/RGB conversion:

        public static Color ToColor(float r, float g, float b)
        {
            return new Color((byte)(r * 255), (byte)(g * 255), (byte)(b * 255));
        }

        public static Color MakeDarken(Color color)
        {
            var rgb = new[] { color.R / 255F, color.G / 255F, color.B / 255F };
            var hsv = RgbToHsv(rgb);
            hsv[2] *= 0.8F;
            rgb = HsvToRgb(hsv);
            return ToColor(rgb[0], rgb[1], rgb[2]);
        }

        public static float[] RgbToHsv(float[] value)
        {
            var r = value[0];
            var g = value[1];
            var b = value[2];
            var min = r < g ? (r < b ? r : b) : (g < b ? g : b);
            var max = r > g ? (r > b ? r : b) : (g > b ? g : b);
            if (max == 0F)
            {
                // r = g = b = 0                // s = 0, v is undefined
                return new [] { -1F, 0F, max };
            }
            var delta = max - min;
            var v = max;
            var s = delta / max;
            var h = r == max ? (g - b) / delta :    // between yellow & magenta
                g == max ? 2F + (b - r) / delta :    // between cyan & yellow
                4F + (r - g) / delta;                // between magenta & cyan
            h *= 60F;                           // degrees
            h = h < 0 ? h + 360F : h;
            return new[] { h, s, v, };
        }

        public static float[] HsvToRgb(float[] value)
        {
            var h = value[0];
            var s = value[1];
            var v = value[2];
            if (s == 0)
            {
                return new[] { v, v, v }; // achromatic (grey)
            }
            h /= 60F;                   // sector 0 to 5
            var i = (int)Math.Floor(h);
            var f = h - i;                      // factorial part of h
            var p = v * (1F - s);
            var q = v * (1F - s * f);
            var t = v * (1F - s * (1F - f));
            switch (i)
            {
                case 0: return new[] { v, t, p };
                case 1: return new[] { q, v, p };
                case 2: return new[] { p, v, t };
                case 3: return new[] { p, q, v };
                case 4: return new[] { t, p, v };
                default: return new[] { v, p, q };
            }            
        }
 

[Mario]

Why don't you just create your own HSVColor class and add implicit conversion operators to get a sf::Color back? You could then directly access H, S, and V as properties rather than calling some fixed MakeDarken function.

[shadowmouse]

Doesn't that argument apply to everything the library does though? Why don't you just make your own? Maybe because it would benefit various people so isn't the point of a library to contain the functionality so you don't have to make it yourself? There are several good uses of HSV I can think of, such as increasing/decreasing brightness more easily, automatic colour palette is easier because you pick a single value of S and V and just use a formula to pick different hues, easier hue manipulation. The middle one is the most useful for me because I'm making a graph plotter so it should choose a default colour for any new graphs,which must be as different from all the other ones as possible, which is easier to do with a hue component.

[eXpl0it3r]

Doesn't that argument apply to everything the library does though? Why don't you just make your own?

The goal is to provide a clean, high-level API for low-level APIs, e.g. you don't have to deal with OpenGL for drawing a texture, or you don't have to understand OpenAL's API to play some music.
If a feature gets requested that's purely an extension on top of SFML, then there need to be compelling arguments for it.

SFML uses RGBA everywhere which is why sf::Color is designed after that. HSV conversion can easily be written as an extension and including it into SFML could cause more confusion than help the handful of people who really want it.

[Laurent]

Let's say we add it (which is not the case ), what interface do we use? It's generally difficult to make two different representations of the same thing (RGBA colors and HSV colors) coexist within the same scope.

[Hapax]

Then comes the problem of if you include HSV, you would also need to include HSL, CYM, CYMK etc..

[Jesper Juhl]

IMHO this is better done in user code than the library.
It's not even that complicated and it's code you write once - quite generic.
Not needed by most. Better kept out of the library IMHO.

[Nexus]

Doesn't that argument apply to everything the library does though? Why don't you just make your own? Maybe because it would benefit various people so isn't the point of a library to contain the functionality so you don't have to make it yourself?

We have explained this so often that it became part of the contributing guidelines

[shadowmouse]

Yeah, sorry. I understand your rationale for that, I just get kind of annoyed when useful features get left out of the library, and it is therefore prevented from being even more useful than it already is, purely because it would be possible for every person who needed that feature to do it themselves.

[Nexus]

I just get kind of annoyed when useful features get left out of the library [...] purely because it would be possible for every person who needed that feature to do it themselves.

That is by far not the only reason, as you can see from the extensive explanation in the guidelines