Talk:RGBA color model

message: This page should be merged with ARGB, as the only real difference between the two is the order of the components. --InvaderJim42 01:19, 16 June 2006 (UTC)

message: I think an illustration could be helpful here to grasp the concept only by a quick glance. Perhaps something like a regular RGB color wheel overlayed on a square grid (to illustrate the background shining through), but with an alpha channel increasing in value as you move farther out from the center of the wheel. The picture title could then tell it's an RGB color wheel with increasing alpha values as you move from its center. Just an idea. :-) It could be represented as a PNG since it supports alpha channels. Internet Explorer 7 will finally also support such images to reduce the problems for the vast majority of the web viewing such images. -- Northgrove 23:42, 5 October 2006 (UTC)
thread_title:  Illustration? 

message: Is this page really necessary? The topic is already discussed in the RGB article. Also, this article should be renamed 'RGBA color model', since we're not dealing with real light. Also, the RGB article states that RGBA is not a distinct color model. Alpha is also not a color. -SharkD 16:35, 26 October 2006 (UTC)
replies: text: I think it's necessary, but I think it's wrongly categorized; RGBA/ARGB aren't color spaces, just a modifier to the RGB color-space to add blending; I'm not sure how to define that in words, but ARGB/RGBA would be the full article name IMO. I'm also fixing the article to include the difference between pre- and post- multiplied alpha. 70.35.227.160 17:18, 10 January 2007 (UTC)
thread_title: Really necessary?

message: to many aRGB is refers to "adobe RGB" for cameras, so the redirect is misleading to them. 68.45.4.118 21:41, 13 July 2007 (UTC)
thread_title: aRGB redirect

message: This is incorrect! The (as of 2011) most used image format on the World Wide Web (PNG) uses the RGBA color byte order for its Truecolour with alpha image type: Each pixel is an R,G,B triple followed by an alpha sample. (Source: Table 11.1 from the PNG specification)
I have also verified myself that one indeed has to write the color components of the image in RGBA order into a (in my case hand-crafted) PNG file for them to be displayed correctly.
Alpha-blended TrueColor PNGs are by no means "obscure" (not even "relatively obscure").  — Preceding unsigned comment added by Alexander255 1100001 (talk • contribs) 20:48, 22 May 2015 (UTC)
replies: text:  Agreed.  This email seems to confirm that RGBA (in byte-order: where address of A is lower than address of G, etc) is by far the most common layout.  This article is rather misleading and should be corrected. --Fylwind (talk) 01:30, 25 December 2015 (UTC)
thread_title:  "It should be noted that RGBA is relatively obscure compared to ARGB" 

message: There are several problems with the existing article.  I tried to edit it to at least clarify the situation, thinking that it was just a problem of confusing notation, but the problems are actually quite deep and would require deleting a substantial amount of text as well as editing the images.
The key problem is that there's a conflation between two different concepts:
* Byte-ordering: one can specify how the bytes are laid out in some stream (e.g. a file, or a TCP connection).  This is useful when you want to discuss serialization.  In this case, when one says RGBA, it means R is followed by G, which is followed by B, which is followed by A.  It gets slightly tricky when the channels are, say, 16-bits, because then endianness becomes a factor.  However, I think it's typical to just default to network order, as typical of most formats/protocols.
* Word-ordering: one can specify how a given 32-bit word is to be interpreted as RGBA components.  So if I say RGBA (word-order), it means if I bit-wise AND the number with 0xff then I get A.  This convention only affects how the CPU should interpret a word, so that operations on the components can be performed via bit-operations.  Put in another way, it describes how a set of bytes are to be packed to or unpacked from a word.  This ordering should never manifest itself in a file or protocol, because when you do that then the result becomes inherently endian-dependent and that's just an awful design for any portable serialization format.  This is why I put the Disputed banner on the "RGBA hexadecimal" section: it talks about a file format (PAM) but uses word-ordering.  That just makes no sense, and I was not able to find any official documents on PAM that prescribe such a strange ordering.
TL;DR: Byte-ordering is used to describe serialization.  Word-ordering describes how components are packed in words.  They have very different purposes and shouldn't be confused with each other.
There's also the other problem that it claims ARGB (word-order) is more common.  I was not able to find any sources that reflect this.  If anything, given the ubiquity of little-endianness these days I would assume that ABGR (word-order) would be more typical since that corresponds to the common RGBA (byte-order) used in most image formats nowadays (like PNG).
I removed all claims that X is more common than Y for now.
--Fylwind (talk) 02:43, 25 December 2015 (UTC)
replies: text: ARGB is used in the raster paint-systems in Windows, OS X, and in the cross platform toolkit Qt, on top of that I know Chromium/Blink and WebKit uses it internally. It has caused BGRA to be a common OpenGL1 extension (before being included to 2.0), and when it was removed in OpenGLES, multiple (incompatible) vendor extensions to add BGRA to OpenGLES were created. Carewolf (talk) 11:53, 25 December 2015 (UTC)
thread_title:  Disputed: inaccuracies in the article