Smoothing of fonts with 8-bit color per point

I do not know ... but that function has certain deficiencies or I have not understood something of 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 do not know but unless I have understood something wrong, I am not convinced by these 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 must occupy (the three components) ... in fact, this is reflected in the switch ( fc is defined in 1 byte)
• the first result starts badly ... loses a bit of blue like that
• the second goes completely ... has no blue component and should be gray. It draws attention to the fact that the G component is full ... ( 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 is the background color as is.

That function does not seem to be very fine since it invents colors ... which coincidentally is what happens to you.

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

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 place here the results of this excellent answer:

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

  

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

I can not say 100% but I think the formula you use is correct, what is not correct is the treatment of color.

I understand that if you are mixing black font color with white background, the result should be gray; 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 to 0: black).
• bc : 0xffffffff (all bits to 1: white).
• b : 0x7f (half 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 do not 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 (mix red and blue should be fuzzy).

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

On the one hand you say that fc and bc are of type uint32_t , which induces to think that they use 8 bits for each component, that is, it is RGB of 24 bits (and that therefore the target would be stored as 0xFFFFFF ).

In fact, the function that computes the color mix between fc and bc that you have provided is written assuming that both colors are RGB with 8 bits per component (see the masks you apply, such as 0xFF , 0xFF00 and 0xFF0000 ).

However, in the switch that you put later, it seems that in reality each color is 8 bits, because for example 0xF0 is labeled "orange".

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

It could also be the case that the ink and background colors really come to you in 24 bits, so your formula would be correct. In this case the color 0xFF does not represent white (as assumed by @eferion), but a very bright green ( 0x0000FF ), and the result of the formula for decreasing values of b would be fine, giving increasingly 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 in which those 24 bits become 8 (3: 3: 2) and it could be that out that step who does it the wrong way. If this were the case, we would not be seeing that step. Maybe the hardware does it.

You should clarify in what format the colors of ink and paper come from (if in 8 or 24 bits), and in what format you should generate the resulting color (if in 8 or 24 bits).