Printable View
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
Yes, it's the classic 24-bit RGB system.
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?
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
(8+8+8) mod 4 = 0 thus there can be no padding here.Quote:
Originally Posted by scarleton
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?Quote:
Originally Posted by wysota
Native Windows format is BMP which is vertically mirrored BGR 8b or 24b without any padding, as far as I remember.Quote:
Originally Posted by scarleton
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.Quote:
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:)