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

<p>Nope little endian was developed as a performance optimization whern moving to multi byte words. <a href="https://en.wikipedia.org/wiki/Endianness#Optimization" rel="nofollow">https://en.wikipedia.org/wiki/Endianness#Optimization</a></p>

<p>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.</p>

CC BY-SA 3.0
2015-11-06T09:49:12.943Z
Thank you for pointing out the endianess performance and the patent matter ;)
user3450548
CC BY-SA 3.0
2015-11-05T18:03:47.950Z
2015-11-05T18:03:47.950Z
SlimSCSI
<p>The order of the components in RGB32 seems to do with <a href="https://www.ffmpeg.org/doxygen/0.5/pixfmt_8h.html" rel="nofollow">endianness</a>:</p>

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

<p>The descriptions of the various related formats enumerated on that page provide more details.</p>

CC BY-SA 3.0
2015-11-06T09:52:49.770Z
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
CC BY-SA 3.0
2015-11-06T10:07:02.993Z
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
CC BY-SA 3.0
2015-11-07T21:42:10.657Z
@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
CC BY-SA 3.0
2015-11-06T07:14:03.767Z
2015-11-06T07:14:03.767Z
Gyan
<p>I was wondering about the difference between <strong>rgb and bgr pixel formats</strong> available in many codecs.</p>

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

<p>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?</p>

<ul>
<li>It's still a matter of patents?  </li>
<li>Have something to do with <a href="https://en.wikipedia.org/wiki/BGR_%28subpixels%29" rel="nofollow">Subpixels Rendering</a> ?  </li>
<li>Why some codecs has alternate support of them like this huffyuv example here:</li>
</ul>

<blockquote>
  <p>Encoder huffyuv [Huffyuv / HuffYUV]:<br>
  Threading capabilities: no<br>
  Supported pixel formats: yuv422p <strong>rgb24 bgra</strong></p>
</blockquote>

<p>It has <strong>rgb24</strong> but then not <strong>rgba</strong> as I could expect. It jumps directly to <strong>bgra</strong>!  </p>

<p>Could be again a matter of patents that the codec author could not break ?</p>

<hr>

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

<ffmpeg><codec><color><colorspace>
ffmpeg bgr vs rgb and other similiar pixel formats
user3450548
# ffmpeg bgr vs rgb and other similiar pixel formats

(Asked by: username_0 on 2015-11-05)

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](https://en.wikipedia.org/wiki/BGR_%28subpixels%29) ?
* 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!

**Tags:** ffmpeg, codec, color, colorspace


---

## 2 answers

### Answer by username_2 on 2015-11-06. Score: 3 | Accepted answer

The order of the components in RGB32 seems to do with [endianness](https://www.ffmpeg.org/doxygen/0.5/pixfmt_8h.html):

> 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.

> **Comments:**
> **username_0**: 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.  
> **username_2**: 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.  
> **username_3**: @username_0: 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.  

---

### Answer by username_1 on 2015-11-05. Score: 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.

> **Comments:**
> **username_0**: Thank you for pointing out the endianess performance and the patent matter ;)  

---

