Programmatically Lighten a Color

As Wedge said, you want to multiply to make things brighter, but that only works until one of the colors becomes saturated (i.e. hits 255 or greater). At that point, you can just clamp the values to 255, but you'll be subtly changing the hue as you get lighter. To keep the hue, you want to maintain the ratio of (middle-lowest)/(highest-lowest).

Here are two functions in Python. The first implements the naive approach which just clamps the RGB values to 255 if they go over. The second redistributes the excess values to keep the hue intact.

def clamp_rgb(r, g, b):
    return min(255, int(r)), min(255, int(g)), min(255, int(b))

def redistribute_rgb(r, g, b):
    threshold = 255.999
    m = max(r, g, b)
    if m <= threshold:
        return int(r), int(g), int(b)
    total = r + g + b
    if total >= 3 * threshold:
        return int(threshold), int(threshold), int(threshold)
    x = (3 * threshold - total) / (3 * m - total)
    gray = threshold - x * m
    return int(gray + x * r), int(gray + x * g), int(gray + x * b)

I created a gradient starting with the RGB value (224,128,0) and multiplying it by 1.0, 1.1, 1.2, etc. up to 2.0. The upper half is the result using clamp_rgb and the bottom half is the result with redistribute_rgb. I think it's easy to see that redistributing the overflows gives a much better result, without having to leave the RGB color space.

For comparison, here's the same gradient in the HLS and HSV color spaces, as implemented by Python's colorsys module. Only the L component was modified, and clamping was performed on the resulting RGB values. The results are similar, but require color space conversions for every pixel.

I would go for the second option. Generally speaking the RGB space is not really good for doing color manipulation (creating transition from one color to an other, lightening / darkening a color, etc). Below are two sites I've found with a quick search to convert from/to RGB to/from HSL:

• from the "Fundamentals of Computer Graphics"
• some sourcecode in C# - should be easy to adapt to other programming languages.

In C#:

public static Color Lighten(Color inColor, double inAmount)
{
  return Color.FromArgb(
    inColor.A,
    (int) Math.Min(255, inColor.R + 255 * inAmount),
    (int) Math.Min(255, inColor.G + 255 * inAmount),
    (int) Math.Min(255, inColor.B + 255 * inAmount) );
}

I've used this all over the place.

ControlPaint class in System.Windows.Forms namespace has static methods Light and Dark:

public static Color Dark(Color baseColor, float percOfDarkDark);

These methods use private implementation of HLSColor. I wish this struct was public and in System.Drawing.

Alternatively, you can use GetHue, GetSaturation, GetBrightness on Color struct to get HSB components. Unfortunately, I didn't find the reverse conversion.

Convert it to RGB and linearly interpolate between the original color and the target color (often white). So, if you want 16 shades between two colors, you do:

for(i = 0; i < 16; i++)
{
  colors[i].R = start.R + (i * (end.R - start.R)) / 15;
  colors[i].G = start.G + (i * (end.G - start.G)) / 15;
  colors[i].B = start.B + (i * (end.B - start.B)) / 15;
}

Converting to HS(LVB), increasing the brightness and then converting back to RGB is the only way to reliably lighten the colour without effecting the hue and saturation values (ie to only lighten the colour without changing it in any other way).

A very similar question, with useful answers, was asked previously: How do I determine darker or lighter color variant of a given color?

Short answer: multiply the RGB values by a constant if you just need "good enough", translate to HSV if you require accuracy.

I've done this both ways -- you get much better results with Possibility 2.

Any simple algorithm you construct for Possibility 1 will probably work well only for a limited range of starting saturations.

You would want to look into Poss 1 if (1) you can restrict the colors and brightnesses used, and (2) you are performing the calculation a lot in a rendering.

Generating the background for a UI won't need very many shading calculations, so I suggest Poss 2.

-Al.

IF you want to produce a gradient fade-out, I would suggest the following optimization: Rather than doing RGB->HSB->RGB for each individual color you should only calculate the target color. Once you know the target RGB, you can simply calculate the intermediate values in RGB space without having to convert back and forth. Whether you calculate a linear transition of use some sort of curve is up to you.

I would have tried number #1 first, but #2 sounds pretty good. Try doing it yourself and see if you're satisfied with the results, it sounds like it'll take you maybe 10 minutes to whip up a test.

Technically, I don't think either is correct, but I believe you want a variant of option #2. The problem being that taken RGB 990000 and "lightening" it would really just add onto the Red channel (Value, Brightness, Lightness) until you got to FF. After that (solid red), it would be taking down the saturation to go all the way to solid white.

The conversions get annoying, especially since you can't go direct to and from RGB and Lab, but I think you really want to separate the chrominance and luminence values, and just modify the luminence to really achieve what you want.

This is based on Mark Ransom's answer.

Where the clampRGB function tries to maintain the hue, it however miscalculates the scaling to keep the same luminance. This is because the calculation directly uses sRGB values which are not linear.

Here's a Java version that does the same as clampRGB (although with values ranging from 0 to 1) that maintains luminance as well:

private static Color convertToDesiredLuminance(Color input, double desiredLuminance) {
  if(desiredLuminance > 1.0) {
    return Color.WHITE;
  }
  if(desiredLuminance < 0.0) {
    return Color.BLACK;
  }

  double ratio = desiredLuminance / luminance(input);
  double r = Double.isInfinite(ratio) ? desiredLuminance : toLinear(input.getRed()) * ratio;
  double g = Double.isInfinite(ratio) ? desiredLuminance : toLinear(input.getGreen()) * ratio;
  double b = Double.isInfinite(ratio) ? desiredLuminance : toLinear(input.getBlue()) * ratio;

  if(r > 1.0 || g > 1.0 || b > 1.0) {  // anything outside range?
    double br = Math.min(r, 1.0);  // base values
    double bg = Math.min(g, 1.0);
    double bb = Math.min(b, 1.0);
    double rr = 1.0 - br;  // ratios between RGB components to maintain
    double rg = 1.0 - bg;
    double rb = 1.0 - bb;

    double x = (desiredLuminance - luminance(br, bg, bb)) / luminance(rr, rg, rb);

    r = 0.0001 * Math.round(10000.0 * (br + rr * x));
    g = 0.0001 * Math.round(10000.0 * (bg + rg * x));
    b = 0.0001 * Math.round(10000.0 * (bb + rb * x));
  }

  return Color.color(toGamma(r), toGamma(g), toGamma(b));
}

And supporting functions:

private static double toLinear(double v) {  // inverse is #toGamma
  return v <= 0.04045 ? v / 12.92 : Math.pow((v + 0.055) / 1.055, 2.4);
}

private static double toGamma(double v) {  // inverse is #toLinear
  return v <= 0.0031308 ? v * 12.92 : 1.055 * Math.pow(v, 1.0 / 2.4) - 0.055;
}

private static double luminance(Color c) {
  return luminance(toLinear(c.getRed()), toLinear(c.getGreen()), toLinear(c.getBlue()));
}

private static double luminance(double r, double g, double b) {
  return r * 0.2126 + g * 0.7152 + b * 0.0722;
}