Início / coding / Perguntas / 79126960
Accepted
Mike
Asked: 2024-10-26 02:38:42 +0800 CST

Conversão adequada de RGB888 para RGB565

  • 772

Encontrei três algoritmos de conversão de RGB888 para RGB565, mas não tenho certeza de qual é o mais correto. Os dois primeiros produzem os mesmos resultados. O terceiro produz um resultado diferente, mas concorda com uma calculadora online. E o terceiro faz sentido, já que faz escala. Mas os dois primeiros serão mais rápidos, já que não há multiplicação ou divisão de inteiros.

uint8_t r8, g8, b8;
uint16_t r5, g6, b5, val;

r8 = someredvalue;
g8 = somegreenvalue;
b8 = somebluevalue;


// first method:
b5 =  (b8  >> 3)        & 0x001F;
g6 = ((g8  >> 2) <<  5) & 0x07E0;
r5 = ((r8  >> 3) << 11) & 0xF800;
val = (r5 | g6 | b5);
printf("%d, %d, %d, %u\n", r8, g8, b8, val);


// second method:
val = ((r8 & 0b11111000) << 8) | ((g8 & 0b11111100) << 3) | (b8 >> 3);
printf("%d, %d, %d, %u\n", r8, g8, b8, val);


// third method:
r5 = r8 * 31 / 255;
g6 = g8 * 63 / 255;
b5 = b8 * 31 / 255;     
val =  (r5 << 11) | (g6 << 5) | (b5);
printf("%d, %d, %d, %u\n", r8, g8, b8, val);
c

2 respostas

  1. Best Answer

    Os dois primeiros produzem os mesmos resultados.

    Porque são equivalentes, pelo menos para compiladores que suportam 0bxxxconstantes binárias no estilo , que é uma extensão do C padrão. Ambos tomam os valores de cor do formato 565 como o número correto dos bits mais significativos do valor de cor correspondente no formato 888.

    O terceiro produz um resultado diferente, mas concorda com uma calculadora online.

    E a terceira faz sentido, pois faz dimensionamento.

    Todos eles fazem escala. O terceiro apenas usa fatores de escala ligeiramente diferentes dos outros.

    Considere o canal vermelho. Cinco bits podem representar valores de 0 a 31. Oito bits podem representar valores de 0 a 255. Matematicamente, o fator para escala linear do último intervalo para o primeiro é 31/255, como a terceira abordagem usa. Os outros dois estão dividindo por 8 (via deslocamento), que é o mesmo aritmeticamente que escalar por 32/256. Esses não são o mesmo fator de escala, é claro, mas são próximos.

    Mas antes de considerar o método 3 como mais correto, você deve considerar os efeitos da aritmética de inteiros. Por exemplo, quais valores vermelhos de 8 bits mapeiam para 31 na representação de 5 bits? Com ​​o método 3, apenas um o faz: 255. O valor 254 é dimensionado para um pouco menos que 31, que é truncado para 30. Essa variação na conversão é, portanto, não uniforme em relação a quantas cores RGB888 correspondem a cada cor RGB565.

    A abordagem de bit-shifting, por outro lado, é uniforme nesse sentido. Ao converter dessa forma, cada cor RGB565 corresponde ao mesmo número (256) de cores RGB888.

    Não tenho certeza de qual é o mais correto.

    No geral, os dois redimensionamentos produzem resultados muito semelhantes, dentro de 1 unidade por canal um do outro. Ambos são lineares, até o truncamento para inteiro. Nenhum é mais correto do que o outro em um sentido absoluto. As alternativas de deslocamento de bits são diferenciadas pela distribuição uniforme dos resultados no espaço RGB565. A outra alternativa é diferenciada pelo mapeamento apenas das intensidades máximas RGB888 para as intensidades máximas RGB565. Também pode haver uma diferença de desempenho, mas se isso for importante para você, então você deve medir. Para a maioria dos propósitos, eu estaria inclinado a escolher a uniformidade de uma das abordagens de deslocamento de bits, mas você pode pensar diferente.

    • 5

  2. @CraigEstey Eu executei o teste várias vezes, os resultados são os mesmos. O código roda em um RPi Pico. Eu também teria pensado que o método #2 era o mais rápido; surpreso que o #1 fosse. – Mike

    Hmm... Eu estava executando os testes em um PC x86 mais antigo (não tenho um RPi). Ainda assim...

    1. Eu entendo que o método 2 é o mais rápido (com gcc)
    2. Mas, m1 é mais rápido com clang. Mas, isso é porque ele usou instruções SIMD x86 não enroladas em loop.

    Para que estejamos em um ponto em comum (só por diversão), anexei meu programa de benchmark completo para seus algoritmos.

    Aqui está o programa de teste ( all.c):

    #include <stdio.h>
#include <stdlib.h>
#include <time.h>

#if USE_BYTE_ARG
typedef unsigned char arg_t;
#else
typedef unsigned int arg_t;
#endif

typedef unsigned short u8;
typedef unsigned short u16;
typedef unsigned int u32;

#ifndef MAX_Y
#define MAX_Y   1080
#endif

#ifndef MAX_X
#define MAX_X   1920
#endif

u8 bigbuf_888[MAX_Y * MAX_X * 3];
u16 bigbuf_565[MAX_Y * MAX_X];

#define inline_always static inline __attribute__((always_inline))

inline_always u32
m1(arg_t r8,arg_t g8,arg_t b8)
{
    u32 b5 = (b8 >> 3) & 0x001F;
    u32 g6 = ((g8 >> 2) << 5) & 0x07E0;
    u32 r5 = ((r8 >> 3) << 11) & 0xF800;
    u32 val = (r5 | g6 | b5);
    return val;
}

inline_always u32
m2(arg_t r8,arg_t g8,arg_t b8)
{
    u32 val = ((r8 & 0b11111000) << 8) | ((g8 & 0b11111100) << 3) | (b8 >> 3);
    return val;
}

inline_always u32
m3(arg_t r8,arg_t g8,arg_t b8)
{
    u32 r5 = r8 * 31 / 255;
    u32 g6 = g8 * 63 / 255;
    u32 b5 = b8 * 31 / 255;
    u32 val = (r5 << 11) | (g6 << 5) | (b5);
    return val;
}

inline_always u32
m4(arg_t r8,arg_t g8,arg_t b8)
{
    u32 r5 = (r8 * 31) / 256;
    u32 g6 = (g8 * 63) / 256;
    u32 b5 = (b8 * 31) / 256;
    u32 val = (r5 << 11) | (g6 << 5) | (b5);
    return val;
}

#define CAT(_a,_b) \
    _a##_b
#define DOTEST(_m) \
    CAT(dotest_,_m)

#define M   m1
#include "test.c"

#define M   m2
#include "test.c"

#define M   m3
#include "test.c"

#define M   m4
#include "test.c"

typedef struct tst {
    void (*tst_fnc)(u16 *dst,const u8 *src,u32 count);
    const char *tst_sym;
    double tst_elap;
} tst_t;

#define DEFTST(_sym) \
    { .tst_fnc = dotest_##_sym, .tst_sym = #_sym }

tst_t tstlist[] = {
    DEFTST(m1),
    DEFTST(m2),
    DEFTST(m3),
    DEFTST(m4),
};

#define FORALL \
    tst_t *tst = tstlist;  tst < &tstlist[countof(tstlist)];  ++tst

#define countof(_arr) \
    sizeof(_arr) / sizeof(_arr[0])

double
tscgetf(void)
{
    struct timespec ts;
    double sec;

    clock_gettime(CLOCK_MONOTONIC,&ts);
    sec = ts.tv_nsec;
    sec /= 1e9;
    sec += ts.tv_sec;

    return sec;
}

void
dotest(tst_t *tst)
{

    tst->tst_elap = 1e9;

    for (int iter = 1;  iter <= 10;  ++iter) {
        double tscbeg = tscgetf();
        tst->tst_fnc(bigbuf_565,bigbuf_888,MAX_Y * MAX_X);
        double tscend = tscgetf();

        tscend -= tscbeg;
        if (tscend < tst->tst_elap)
            tst->tst_elap = tscend;
    }

#if 0
    printf("%.9f %s\n",tst->tst_elap,tst->tst_sym);
#endif
}

int
tstcmp(const void *alhs,const void *arhs)
{
    const tst_t *lhs = alhs;
    const tst_t *rhs = arhs;
    int cmp;

    do {
        cmp = -1;
        if (lhs->tst_elap < rhs->tst_elap)
            break;

        cmp = 1;
        if (lhs->tst_elap > rhs->tst_elap)
            break;

        cmp = 0;
    } while (0);

    return cmp;
}

int
main(void)
{

    printf("%ux%u\n",MAX_X,MAX_Y);

    for (FORALL)
        dotest(tst);

    qsort(tstlist,countof(tstlist),sizeof(tst_t),tstcmp);

    tst_t *otst = tstlist;
    for (FORALL) {
        printf("%.9f %s (%.3fx slower than %s)\n",
            tst->tst_elap,tst->tst_sym,
            tst->tst_elap / otst->tst_elap,otst->tst_sym);
#if 0
        otst = tst;
#endif
    }

    return 0;
}

    Aqui está o que test.cele precisa (deve ser um arquivo separado):

    void
DOTEST(M)(u16 *rgb565,const u8 *rgb888,u32 count)
{

    for (u32 idx = 0;  idx < count;  idx += 1, rgb888 += 3)
        rgb565[idx] = M(rgb888[0],rgb888[1],rgb888[2]);
}

#undef M

    Compilado com gcc8.3.1:

    gcc -Wall -O3 -o all all.c

    A saída é:

    1920x1080
0.003618755 m2 (1.000x slower than m2)
0.003766094 m1 (1.041x slower than m2)
0.005401992 m4 (1.493x slower than m2)
0.007230262 m3 (1.998x slower than m2)

    Compilado com clang7.0.1:

    clang -Wall -O3 -o all all.c

    A saída:

    1920x1080
0.002214470 m1 (1.000x slower than m1)
0.002892669 m2 (1.306x slower than m1)
0.005501939 m4 (2.485x slower than m1)
0.007757501 m3 (3.503x slower than m1)
    • 2

relate perguntas