ffmpeg bgr vs rgb y otros formatos de píxeles similares

Me preguntaba acerca de la diferencia entre los formatos de píxeles rgb y bgr disponibles en muchos códecs.

Me recuerda de alguna manera los sabores Big Endian y Little Endian de los procesadores de computadora.

Si bien siempre supuse que el big/little endian era más una cuestión de patentes que de rendimiento, ¿por qué tenemos tanto rgb como bgr?

  • ¿Sigue siendo una cuestión de patentes?
  • ¿Tiene algo que ver con Subpixels Rendering ?
  • Por qué algunos códecs tienen soporte alternativo para ellos como este ejemplo de huffyuv aquí:

Codificador huffyuv [Huffyuv / HuffYUV]:
capacidades de subprocesos: no
Formatos de píxeles compatibles: yuv422p rgb24 bgra

Tiene rgb24 pero no rgba como podría esperar. Salta directamente a bgra !

¿Podría ser nuevamente una cuestión de patentes que el autor del códec no pudo romper?

Si es posible, alimenta mi curiosidad con una explicación ampliada aquí. ¡Quiero saber algo más sobre estos diversos formatos de píxeles!

Respuestas (2)

El orden de los componentes en RGB32 parece tener que ver con endianness :

PIX_FMT_RGB32 se maneja de una manera específica de endian. Un color RGBA se junta como: (A << 24) | (D<<16) | (G << 8) | B Esto se almacena como BGRA en arquitecturas de CPU little-endian y ARGB en CPU big-endian.

Las descripciones de los diversos formatos relacionados enumerados en esa página brindan más detalles.

¡Ay, no me había dado cuenta! Votar a favor. Sin embargo, mi pregunta principal se cerró a una explicación detallada de cómo nacen estos formatos, pros y contras, por qué algunos software o estándares están en una dirección en lugar de en otra, si también tienen que ver con la representación de subpíxeles y la mayor cantidad de información detallada posible. . Una suma de algunos temas + referencias externas para alimentar toda la curiosidad posible.
¿Quiere decir por qué endianness o por qué diferentes órdenes de apilamiento? Estos últimos parecen ligados a la existencia de los primeros, en aras de la eficiencia. No creas que es más profundo que eso.
@user3450548: Más bien, los diseñadores de diferentes sistemas tomaron decisiones arbitrarias de manera diferente. Tal vez se remonta a la memoria de video / diseño de textura 3D. Tal vez algunas opciones de diseño de hardware hicieron que un pedido fuera más eficiente que el otro. Aunque probablemente estés en algo con el argumento endian. La otra forma de expresarlo es: un archivo de mapa de píxeles sin formato/bloque de memoria con componentes de color empaquetados será leído de una manera por las CPU de Little Endian, y de la otra manera por las CPU de Big End.

Si bien siempre supuse que el big/little endian era más una cuestión de patentes que de rendimiento,

No, little endian se desarrolló como una optimización del rendimiento al pasar a palabras de varios bytes. https://en.wikipedia.org/wiki/Endianness#Optimización

Nada que ver con las patentes. Las diferentes representaciones tienen diferentes ventajas y desventajas. Por lo tanto, diferentes situaciones pueden usar diferentes representaciones. Los códecs sufren el efecto de red. Nadie quiere usar su codificador si nadie usa su decodificador. Y viceversa. Por lo tanto, los diseñadores de códecs buscan la máxima compatibilidad y, a menudo, admiten varios formatos. Pero por lo general no los admiten todos, porque hay docenas. Por lo tanto, utilizan una combinación de los más comunes y fáciles de incluir en el diseño.

Gracias por señalar el rendimiento de Endianess y el asunto de la patente;)
ffmpeg bgr vs rgb y otros formatos de píxeles similares
RespuestasAquíPolítica de privacidad1y, 0v