BGR Color Space

问题:

I understand RGB --- value (0-255)Red, (0-255)Green, (0-255)Blue to form a color.

What exactly is BGR color space?

How is it different from RGB color space?

回答1:

RGB stands for Red Green Blue. Most often, an RGB color is stored in a structure or unsigned integer with Blue occupying the least significant "area" (a byte in 32-bit and 24-bit formats), Green the second least, and Red the third least.

BGR is the same, except the order of areas is reversed. Red occupies the least significant area, Green the second (still), and Blue the third.

On some platforms (e.g. the Gamegear) a BGR model is used. However, for most, like your computer, RGB is used [citation-needed] (though BGR is supported by many graphic API's for compatability). I'm not sure why exactly it's used; probably historical.

Example: #FF0000 is pure red when read as an RGB hex color (#rrggbb), because the third area (numbers are read right to left!) is FF (maximum value, full color) and the other two areas are 00 (minimum value, no color). If #FF0000 were read as a BGR hex color, it'd be pure blue.

回答2:

Its about endianness.

RGB is a byte-order. But a deliberate implementation choice of most vanilla Graphics libraries is that they treat colours as unsigned 32-bit integers internally, with the three (or four, as alpha is typically included) components packed into the integer.

On a little-endian machine (such as x86) the integer 0x01020304 will actually be stored in memory as 0x04030201. And thus 0x00BBGGRR will be stored as 0xRRGGBB00!

So the term BGR (and BGRA etc) is a leaky abstraction where the graphics library is explaining how the integer is logically ordered, so as to make your code that is directly accessing the colour components individually more readable.

Remember that bitmaps are usually accessed by more parts of the hardware than your processor, and the endian that is specified by, say, conventional display adapters, is not necessarily the same as the endian of your CPU. At the level of manipulating the channels in the pixel its no problem for a CPU to extract the fields whatever their order; its purely a programmer understanding the labelling thing.

回答3:

It is about the way the color components are laid out in memory. For BGR the order is BGRBGRBGRBGR..., and for RGB the order is RGBRGBRGB... For BGR, the default order for OpenCV, it is like this:

(See the OpenCV documentation for How the image matrix is stored in the memory?)

Note the other answers have referred to certain colors being least or most significance, but that actually depends on the endianness of your machine. And the packing order of components in an unsigned int, e.g, actually depends on your software, or the library you are using. However, regardless of your library, or the endiannes of your machine, for BGR pixel the byte address of the B color component will be one less than for G and and two less than for R (and for RGB it is just the other way around).

回答4:

It's just RGB in a more tightly controlled order, independent of endianness. Converting between them is simple once you know the endianness of your environment.

The BGR is a 24-bit representation where the lower-addressed 8 bits are blue, the next-addressed 8 are green and higher-addressed 8 are red.

RGB values tend to be written as RGB(r,g,b) where the r/g/b values are between 0 and 255 inclusive or as #rrggbb, where rr/gg/bb are 8-bit hex values. All the BGR values I've seen tend to be simple integers between 0 and 16777215 (0xffffff).