PDA

View Full Version : Understanding RGB888



scarleton
29th August 2010, 16:51
Here is the info I have on my image source:

All images are raw byte data in order of RGBRGBRGB…. The pixel order is from left to right and from top to bottom. The size of image is fixed: 160 pixels x 120 pixels

So if I am understanding RGB888 correctly, 8-bits of R, 8-bits of G, 8-bits of B, repeat... The source images are in RGB888 format, would you agree?

Sam

wysota
29th August 2010, 16:53
Yes, it's the classic 24-bit RGB system.

scarleton
29th August 2010, 17:01
I know there is one RGB format that pads each scan line to 4 bits with zeros. I assume RGB888 does not do this, correct?

Talei
29th August 2010, 17:44
After RGB there is bit representation for each channel. 888 means 3x8bit = 24bit, 444 -> 3x4 = 12bit. http://en.wikipedia.org/wiki/RGB_color_model
If You see something like RGB 4:4:4 that means subsampling for one of channels in YCbCr: http://en.wikipedia.org/wiki/Chroma_subsampling

wysota
29th August 2010, 17:48
I know there is one RGB format that pads each scan line to 4 bits with zeros. I assume RGB888 does not do this, correct?

(8+8+8) mod 4 = 0 thus there can be no padding here.

scarleton
29th August 2010, 20:50
(8+8+8) mod 4 = 0 thus there can be no padding here.My bad, I ment bytes, not bits. I think it is Windows native image format that does this. I am guessing it is because 32-bit OS's work the quickest in 4 byte chuncks, though it is a pain to save out:) Further more I take it that this is not how RGB888 works, correct?

wysota
29th August 2010, 21:03
My bad, I ment bytes, not bits. I think it is Windows native image format that does this.
Native Windows format is BMP which is vertically mirrored BGR 8b or 24b without any padding, as far as I remember.


I am guessing it is because 32-bit OS's work the quickest in 4 byte chuncks, though it is a pain to save out:)
Honestly I never heard of such padding, it would be a pure waste of memory space. Padding usually occurs only at the end of some data, not in the middle of it. Of course I don't deny such formats may exist, I just never had any experience with those :) Image formats tend to have multiple of word length as their bit per gun anyway. Of course the word length might be different for different architectures.