Font anti-aliasing with 8-bit-per-point color

I don't know... but that function has certain shortcomings or I haven't understood something from the question:

using Color = unsigned int;

Color color(Color fc, Color bc, unsigned char b)
{
  return (((fc & 0xFF) * b + (bc & 0xFF) * (256 - b)) >> 8) & 0xFF |//Blue component
         (((fc & 0xFF00) * b + (bc & 0xFF00) * (256 - b)) >> 8)  & 0xFF00|//Green component
         (((fc & 0xFF0000) * b + (bc & 0xFF0000) * (256 - b)) >> 8) & 0xFF0000; //Red component
}

int main(int, char **)
{
  Color fc = 0xFF;
  Color bc = 0x00;
  unsigned char b = 255;

  std::cout << std::hex
            << color(fc,bc,255) << '\n'
            << color(fc,bc,125) << '\n'
            << color(fc,bc,0)   << '\n';
}

The output of the program is:

fe
7c
0

I don't know, but unless I've misunderstood something, I'm not convinced by those results:

• The first thing that draws attention is that the function works with 1 byte for each component... when 1 byte is what the color itself (the three components) should occupy... in fact, it is reflected in the switch( it fcis defined in 1 byte)
• the first result already starts badly... it loses a bit of blue just like that
• the second is gone altogether... it has no blue component and should be a grey. It is very striking that the G component is at its maximum... ( 7c= 011 111 00). Here I would rather expect a value similar to 6e( 011 011 10) or 6d.
• the third value is the only one that matches... it's the background color as is.

That function doesn't seem to go very well since it invents colors... which coincidentally is what happens to you.

I would start by replacing that algorithm with a slightly more predictable one:

typedef unsigned Color;

unsigned GetR(Color color)
{
  return color >> 5;
}

unsigned GetG(Color color)
{
  return (color >> 2) & 0x07;
}

unsigned GetB(Color color)
{
  return color & 0x03;
}

Color color1(Color fc, Color bc, unsigned char b)
{
  unsigned pfc = b;
  unsigned pbc = 255-b;

  Color color = (((GetR(fc) * pfc + GetR(bc) * pbc) / 255) << 5)
              | (((GetG(fc) * pfc + GetG(bc) * pbc) / 255) << 2)
              |  ((GetB(fc) * pfc + GetB(bc) * pbc) / 255);

  return color;
}

ADDED BY THE AUTHOR OF THE QUESTION

Since there is no way to test it without the proper hardware, I'm posting the results of this excellent answer here:

Although they are similar to the originally generated ones, they are darker tones in general, which makes those apparently incorrect points barely noticeable; in fact, on the actual display (remember that, to display on a PC, you have to map from 8bpp to 24bpp; that makes colors inaccurate), the results are nothing short of perfect.

What is the correct way to perform this type of smoothing?

I can't be 100% sure but I think the formula you use is correct, what is not correct is the color treatment.

I understand that if you are mixing black font color with white background, the result should be grays; The gray color has the particularity that all its RGB components have the same value, for example 50% black and white , 75% white 25% black , 25% white 75% black ...

Your color structure is r3g3b2 but the treatment you do is r8g8b8, so if I pass these values:

• fc: 0x00000000(all bits at 0: black).
• bc: 0xffffffff(all bits at 1: blank).
• b: 0x7f(half of the maximum of uint8_t: 50%).

With your formula I get the value 128, which if we interpret it as r3g3b2 is 57.14% red 0% green and 0% blue , that is: red.

What you need is to treat the components as r3g3b2, for this I suggest you create some functions that allow you to obtain each component (C++ code):

using color = std::uint8_t;

constexpr color R(color c) { return (c & 0b11100000) >> 5; } // 3 bits de mayor peso: R
constexpr color G(color c) { return (c & 0b00011100) >> 2; } // bits 2-4: G
constexpr color B(color c) { return (c & 0b00000011); }      // bits 0-1: B

I don't know exactly how the alpha blend works, but having these functions the operation could look like this:

color blend(color fc, color bc, color b)
{
    const float font = b / 255.f;         // % de color de fuente
    const float background = 1.f - font;  // % de color de fondo

    std::uint8_t red = (R(fc) * font) + (R(bc) * background);
    std::uint8_t green = (G(fc) * font) + (G(bc) * background);
    std::uint8_t blue = (B(fc) * font) + (B(bc) * background);

    /* R será los bits 5 a 7
       G será los bits 2 a 4
       B será los bits 0 a 1 */
    return (red << 5) | (green << 2) | blue;
}

The algorithm may not work with colors other than gray (mixing red and blue should come out fuzzy).

I think the sizes of the data types in which you store colors are not clear.

On the one hand, you say that fcand bcare of type uint32_t, which leads us to think that they use 8 bits for each component, that is, it is 24-bit RGB (and therefore white would be stored as 0xFFFFFF).

In fact, the function that computes the color mix between fcand bcthat you've provided is written assuming that both colors are RGB with 8 bits per component (look at the masks you apply, like 0xFF, 0xFF00and 0xFF0000).

However, in the switchone you put later, it seems to be deduced that each color is actually 8 bits, since for example it 0xF0is labeled "orange".

If this were the case, then @eferion's answer would be the one that correctly computes the color mix, with masks using the (3:3:2) split of bits per component.

It could also be the case that the ink and background colors actually come to you in 24 bits, so your formula would be correct. In that case the color 0xFF does not represent white (as @eferion supposed), but a very bright green ( 0x0000FF), and the result of the formula for decreasing values ​​of bwould be fine, giving darker and darker greens ( 0x0000FE, 0x00007C, 0x000000).

But since the formula produces a 24-bit RGB color and your display handles 8-bit colors, there would still be an extra step where those 24 bits are converted to 8 (3:3:2) and it might be that step who does it wrong. If this were the case, we would not be looking at that step. Maybe the hardware does it.

You must clarify in what format the ink and paper colors come to you (whether in 8 or 24 bits), and in what format you must generate the resulting color (whether in 8 or 24 bits).