3

I was wondering about the difference between rgb and bgr pixel formats available in many codecs.

It reminds me in some way the Big Endian and Little Endian flavours of computer processors.

While I always guessed that the big / little endian was more a matter of patents rather than performance, why we have both rgb and bgr?

  • It's still a matter of patents?
  • Have something to do with Subpixels Rendering ?
  • Why some codecs has alternate support of them like this huffyuv example here:

Encoder huffyuv [Huffyuv / HuffYUV]:
Threading capabilities: no
Supported pixel formats: yuv422p rgb24 bgra

It has rgb24 but then not rgba as I could expect. It jumps directly to bgra!

Could be again a matter of patents that the codec author could not break ?

Please feed my curiosity with some extended explaination here if possible, i want to know something more about this various pixel formats!

Improve this question

2 Answers 2

Reset to default
3

The order of the components in RGB32 seems to do with endianness:

PIX_FMT_RGB32 is handled in an endian-specific manner. An RGBA color is put together as: (A << 24) | (R << 16) | (G << 8) | B This is stored as BGRA on little-endian CPU architectures and ARGB on big-endian CPUs.

The descriptions of the various related formats enumerated on that page provide more details.

Improve this answer
3
  • Oh, i wasn't aware of it! Upvote. However my core question was closed to a detailed explaination of how this formats are born, pro vs cons, why some software or standards are in one direction instead of another, if they have also to do with subpixels rendering and as much detailed info's is possible. A sum of some topics + external references to feed all possible curiosity.
    – user3450548
    Nov 6, 2015 at 9:52
  • Do you mean why endianness or why different stacking orders? The latter seem tied to the existence of the former, for the sake of efficiency. Don't think it's any deeper than that.
    – Gyan
    Nov 6, 2015 at 10:07
  • @user3450548: More like, the designers of different systems made arbitrary choices differently. Maybe dating back to video memory / 3D texture layout. Maybe some hardware design choices made one ordering more efficient than the other. Although you're probably on to something with the endian argument. The other way to phrase it is: A raw pixmap file/block of memory with packed color components will be read one way by little endian CPUs, the other way by big-endian CPUs.
    – Peter Cordes
    Nov 7, 2015 at 21:42
3

While I always guessed that the big / little endian was more a matter of patents rather than performance,

Nope little endian was developed as a performance optimization whern moving to multi byte words. https://en.wikipedia.org/wiki/Endianness#Optimization

Nothing to to with patents. Different representation have different advantages and disadvantage. Hence different situations may use different representations. Codecs suffer from network effect. Nobody wants to use your encoder if nobody uses your decoder. And vice-versa. So codec designers go for maximum compatibility, and often support several formats. But the usually don't support them all, because there are dozens. So they use a combination of the most common, and easiest to include into the design.

Improve this answer
1
  • Thank you for pointing out the endianess performance and the patent matter ;)
    – user3450548
    Nov 6, 2015 at 9:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.